WO/2011/133073 | Method and apparatus for machine communication |
WO/2016/000033 | COMMAND INJECTION PROTECTION FOR JAVA APPLICATIONS |
JPH11259423 | SECURITY SYSTEM FOR TRANSMITTING DEVICE |
REIVINDICACIONES [Reivindicación 1] Un método de comunicación segura por proxificación de sockets de red que comprende: • establecer una sesión (110) de comunicaciones seguras que permita efectuar proxificaciones de sockets entre dos dispositivos denominados “dispositivo_A” (106) y “dispositivo_B” (101), donde el primero utilice para ello un servidor proxy-firewall (111) que albergue y el segundo utilice un agente del servidor proxy-firewall denominado“agente_B” (109) que inicie el establecimiento de dicha sesión, empleando un cliente proxy stand-alone (112) que implemente un protocolo de comunicación segura usando unos datos de configuración y credenciales de una cuenta de usuario denominada“usuario_AB” definidos por un perfil de configuración del dispositivo_B denominado“perfil_BA” que le permiten conectarse a la cuenta del usuario_A del dispositivo_A; • establecer unas proxificaciones denominadas“proxificaciones directas” (114) si estas se producen desde los sockets de aplicaciones que se encuentran escuchando en el dispositivo_A, como lo son los denominados“socket_A” (123), y según se describa en el perfil_BA; • establecer unas proxificaciones denominadas“proxificaciones reversas” (115) si estas se producen desde los sockets de las aplicaciones que se encuentran escuchando en el dispositivo_B denominados“socket_B” (118) y según se describa en el perfil_BA; • proteger a instancias del servidor proxy-firewall del dispositivo_A las comunicaciones de los sockets_A y las proxificaciones reversas en el dispositivo_A mediante la configuración de contextos de seguridad configurados con reglas de marcado y filtrado de paquetes de red de esas comunicaciones locales, utilizando como parámetro delimitador del contexto el usuario del proceso del sistema operativo del dispositivo_A origen de cada comunicación local; y • proteger a instancias del agente del dispositivo_B las comunicaciones de los sockets_B y las proxificaciones directas en el dispositivo_B mediante la configuración de contextos de seguridad configurados con reglas de marcado y filtrado de paquetes de red de esas comunicaciones locales, utilizando como parámetro delimitador de dichos contextos el usuario del proceso del sistema operativo del dispositivo_B origen de cada comunicación local. [Reivindicación 2] El método según la reivindicación 1 , donde se establecen unos contextos de seguridad para las proxificaciones directas y las reversas, además comprende: • registrar las proxificaciones reversas en una base de datos (122) de un connection-broker (121) del dispositivo_A como un registro denominado“registro_socket” donde se guarda la información relativa de cada proxificación reversa que comprende: o una variable denominada“id_DispSocket” que almacena el id de dispositivo con el socket a proxificar, y que según esta reivindicación correspondería con el id del dispositivo_B denominado“id_B”; o una variable denominada “id_DispProxy”, que identifica el dispositivo con el que mantiene la sesión que habilita el socket protegido al que hace referencia este registro_socket, y que según esta reivindicación correspondería con el id_B; o una variable denominada“alias”, que en esta reivindicación guardaría el alias del socket a proxificar del id_DispSocket; o una variable denominada“socket” que según esta reivindicación guardaría el socket local libre, reservado por el sistema operativo del dispositivo_A para la proxificación y que dispone de un valor de dirección de red perteneciente a un pool de direcciones de red locales del dispositivo_A reservadas para este método; y o una variable denominada“tipo_socket” que determina la clase de socket a la que hace referencia este registro, y que según esta reivindicación sería“socket_B”; • el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A, de una regla general de marcado de paquetes a través de su framework de red (107) por parte del servidor proxy-firewall que determine eliminar cualquier posible marcado de paquetes de red en cualquier comunicación, producida entre sockets locales del dispositivo_A, con direcciones locales pertenecientes al pool de direcciones locales reservado para este método; • el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A, de una regla general de filtrado de paquetes por parte del servidor proxy-firewall que determine descartar cualquier paquete con origen y destino un socket local del dispositivo_A que carezca de un marcado, siempre y cuando alguno de los sockets utilice una dirección de red local perteneciente al pool de direcciones locales reservado para este método; • el ingreso, durante la secuencia de arranque del sistema operativo (102) del dispositivo_B y a través del framework de red de este último, de una regla general de filtrado por cada socket_B y proxificación directa en el dispositivo_B que determine el descarte de paquetes entrantes con ese destino y con origen una dirección de red no local; • el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A y a través de un framework de red (107) de este último, de una regla general de filtrado de paquetes por parte del servidor proxy-firewall que determine descartar cualquier paquete con origen o destino una dirección local del pool de direcciones locales reservado para este método que tenga como origen o destino una dirección no local; • el ingreso, si no existe, durante la secuencia de arranque del sistema operativo del dispositivo_A, de un registro_socket en la base de datos del dispositivo_A relativo a cada socket_A del dispositivo_A recogido en el perfil de configuración denominado“perfi l_A”, conteniendo cada registro_socket información que comprende: o el id_DispSocket, que en esta reivindicación sería igual al id del dispositivo_A denominado“id_A”; o el id_DispProxy, que en esta reivindicación sería también igual al id_A; o el alias, que en esta reivindicación sería igual al empleado por el socket_A a registrar; o el socket, que en esta reivindicación sería igual al es igual al socket local utilizado por el proceso_A para el socket_A definido en el perfil_A; y o el tipo_socket, que en esta reivindicación sería igual a“socket_A”; • el ingreso, si no existe, durante la secuencia de arranque del sistema operativo del dispositivo_A, de al menos un registro denominado“registro_acceso_A” en la base de datos del dispositivo_A relativo a cada socket_A del dispositivo_A recogido en el perfi l_A, conteniendo cada registro_acceso_A información que comprende: o una variable denominada“conjd” que almacena el identificador del acceso con el mismo nombre, o una variable denominada“socket” que almacena el socket_A, y o una variable denominada “id_Grupo” que almacena el id del grupo del usuario del sistema operativo del dispositivo_A correspondiente al usuario_A del proceso_A origen de la petición de comunicación al que se le ha concedido acceso; • el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A, a través del connection-broker (121), a instancias del servidor proxy-firewall y según la configuración marcada en el perfi l_A, de unos permisos_Ac en la base de datos (122) que comprenden: o el id_Grupo, que almacena el id del grupo de usuarios del sistema operativo del dispositivo_A al que se otorga el permiso de acceso; o el alias, que almacena el alias del socket_A; o el socket, que almacena el valor del socket_A; • el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A, a través del framework de red (107) y a instancias del servidor proxy-firewall de unas reglas de marcado prioritarias sobre las generales y que son respectivas a los permisos_Ac registrados en esta reivindicación para cada socket_A para conceder accesos permanentemente a los grupos de usuarios del dispositivo_A relativos a los anteriores permisos según se defina en el perfi l_A; y • la supresión, durante la secuencia de arranque del sistema operativo del dispositivo_A, de cada registro_acceso, de sus permisos respectivos de la base de datos relativos a los registros_socket cuyo tipo_socket sea “socket-proxy” y la supresión del propio registro_socket. [Reivindicación 3] El método según las reivindicaciones anteriores, donde se establece una comunicación segura entre sockets de red, en la que un recurso de red que es ofrecido por el socket_B de un proceso denominado“proceso_B” (118) del dispositivo_B es solicitado por un proceso denominado“proceso_A” (302) de un usuario denominado“usuario_A” del sistema operativo del dispositivo_A y cuyo recurso es accesible a través de un socket-proxy reverso (301), además comprende: • solicitar (305) por parte del proceso_A al servidor proxy-firewall mediante una llamada al sistema la resolución del socket protegido a partir del id_B y del alias del socket_B para obtener el socket-proxy reverso local por el que poder acceder al socket_B; • solicitar (307) al connection-broker de parte del servidor proxy-firewall la comprobación de existencia de un permiso de acceso del usuario_A denominado“permiso_Au” que lo habilite para acceder al socket-proxy reverso requerido, la solicitud de resolución del socket-proxy reverso y la concesión de un acceso al socket-proxy reverso denominado“registro_acceso”; • comprobar (308) por parte del connection-broker en la base de datos la existencia del permiso_Au y realizar la resolución del socket-proxy reverso; • generar (311) el registro_acceso, si aún no existe en la base de datos, en el que se asigna por parte del connection-broker un identificador de acceso de comunicación al socket-proxy reverso denominado“conjd” relativo al usuario_A y al socket protegido; • guardar (312), o actualizar si procede, en la base de datos por parte de connection-broker el registro_acceso generado, el cual comprende: o el conjd relativo del acceso concedido, o el socket al que se concede el acceso y que está formado por la dirección de red local y el puerto, o una variable denominada“id_Usuario” que almacena el id del usuario del sistema operativo del dispositivo_A correspondiente al usuario_A del proceso_A origen de la petición de comunicación al que se le ha concedido acceso; y o una variable denominada“última_actividad” que guarda el momento en el que se le ha concedido el acceso que se actualizará por un monitor de accesos reflejando su estatus de actividad; • habilitar (315) una regla específica prioritaria sobre las reglas generales de marcado de paquetes para el sistema operativo del dispositivo_A por parte del servidor proxy-firewall, que determine que a todos paquetes de comunicaciones locales entre el usuario_A que ejecuta el proceso_A y el socket-proxy reverso, se les incluya el identificador del acceso asignado conjd definido en el registro_acceso correspondiente al socket-proxy reverso y al usuario_A; • instanciar (318) por parte del servidor proxy-firewall un monitor de accesos que verifique si hay tráfico por el acceso hacia el socket-proxy reverso periódicamente y actualice el valor de última_actividad; y • proceder con la comunicación (320) entre proceso_A y el socket_B que ofrece el recurso a través del socket-proxy reverso existente en el dispositivo_A; [Reivindicación 4] El método según las reivindicaciones anteriores, donde el proceso_A del usuario_A en el dispositivo_A solicita la proxificación de forma directa en el dispositivo_A de varios sockets protegidos de un dispositivo_A foráneo denominado“dispositivo_AF”, además comprende: • solicitar (606) por parte del proceso_A al servidor proxy-firewall una resolución de las proxificaciones directas a realizar, requiriendo una respuesta con los sockets locales asignados; • solicitar (607) al connection-broker por parte del servidor proxy-firewall una reserva de sockets locales sin usar para utilizarlos como socket-proxies directos, una vez se resuelvan los sockets protegidos del dispositivo_AF que se requieren proxificar de forma directa por medio del agente_A; • registrar (609) en la base de datos, por parte del connection-broker, los permisos_Au y registros_acceso pertinentes que permitan al usuario_A acceder a los socket-proxies directos; • registrar (609) en la base de datos cada registro_socket generado por cada reserva de socket a proxificar de forma directa, y el cual comprende: o el id_DispSocket, que en esta reivindicación guardaría el id del dispositivo del socket protegido correspondiente y que conoce el proceso_A; o el id_DispProxy, que en esta reivindicación guardaría el id del dispositivo_AF denominado“id_AF”; o el alias, que en esta reivindicación guardaría el alias del socket que el proceso_A desea proxificar y que también conoce el proceso_A; o el socket, que en esta reivindicación guardaría el socket local libre que queda asignado para realizar cada proxificación directa y que dispone de un valor de dirección de red perteneciente al pool de direcciones de red locales del dispositivo_A reservados para este método; y o el tipo_socket, que en esta reivindicación sería igual a‘socket_proxy’; • solicitar (613) al agente_A el establecimiento de una sesión de comunicaciones con el dispositivo_AF utilizando unas credenciales de acceso al dispositivo_AF del usuario_A provistas por el servidor proxy-firewall, sesión a través de la cual se realice la resolución de los sockets protegidos del dispositivo_AF a proxificar de forma directa en el dispositivo_A; • solicitar (614) al dispositivo_AF a través de la sesión establecida en esta reivindicación la resolución y el establecimiento de los accesos para los sockets protegidos requeridos del dispositivo_AF indicados en la solicitud; • establecer (618) por parte del servidor proxy-firewall la regla de marcado pertinente a cada permiso_Au por medio del framework de red que permitan al usuario_A acceder a los socket-proxies directos; • solicitar el establecimiento de cada proxificación directa (604) en el dispositivo_A hacia cada socket protegido correspondiente del dispositivo_AF tal y como requiere el proceso_A; • responder (620) al proceso_A por parte del servidor proxy-firewall con la resolución de sockets solicitada; y • instanciar, por parte del servidor proxy-firewall, un monitor de accesos (621) que actualice periódicamente el valor última_actividad de cada registro_acceso insertado en la base de datos en esta reivindicación. [Reivindicación 5] El método según las reivindicaciones anteriores, donde varios sockets protegidos del dispositivo_A son a su vez proxificados de forma directa hacia un dispositivo_AF por un agente del dispositivo_AF denominado“agente_AF” usando unos datos de configuración y credenciales de una cuenta de usuario denominada“usuario_AAF” definidos por un perfil de configuración del dispositivo_A denominado“perfil_UAAF” que le permiten a dicho agente_AF conectarse a la cuenta del usuario_AAF del dispositivo_A, además comprende: • establecer una sesión segura entre el agente_AF y el servidor proxy-firewall del dispositivo_A por iniciativa del agente_AF; • solicitar en el establecimiento de dicha sesión una resolución de cada socket protegido del dispositivo_A que sea requerido por el agente_AF; • instanciar un fork del servidor proxy-firewall en la cuenta usuario_AAF denominado“fork_AAF”; • solicitar al connection-broker por parte del fork_AAF una resolución de los sockets protegidos a partir del alias y del id_A de cada socket_A, y del alias y del id_B de cada socket_B indicados por el agente_AF; • verificar por parte del connection-broker del dispositivo_A la existencia de permisos suficientes para el usuario_AAF en la base de datos para poder acceder a los sockets protegidos; • solicitar al connection-broker por parte del fork_AAF un acceso de comunicación por cada socket protegido para la cuenta del usuario_AAF del sistema operativo del dispositivo_A para todos aquellos sockets protegidos requeridos por el agente_AF con los que el usuario_AAF aún no cuente con acceso; • registrar cada registro_acceso de cada acceso concedido en la base de datos del connection-broker; • establecer por parte del fork_AAF la regla de marcado relativa a cada registro_acceso por medio del framework de red del sistema operativo del dispositivo_A que permitan al usuario_AF acceder a cada socket protegido; • responder al agente_AF con el valor de cada socket protegido requerido para que posteriormente, el agente_AF pueda efectuar las proxificaciones directas; e • instanciar un monitor de accesos por parte del fork_AAF para actualizar periódicamente el valor última_actividad de cada registro_acceso insertado en la base de datos en esta reivindicación. [Reivindicación 6] El método según las reivindicaciones 1-3, donde varios sockets protegidos del dispositivo_A son proxificados de forma reversa en el dispositivo_AF por requerimiento del proceso_A del usuario_A del dispositivo_A a través del agente_A, además comprende: • solicitar por parte del proceso_A al servidor proxy-firewall la realización de una proxificación reversa de unos sockets locales protegidos a los que tiene acceso; • solicitar al connection-broker la resolución de los sockets locales requeridos en la proxificación solicitada por el proceso_A; • comprobar, por parte del connection-broker, si el usuario_A dispone de los permisos necesarios para acceder a los sockets locales protegidos requeridos en la solicitud de proxificación; • insertar en la base de datos, por parte del connection-broker, unos accesos de comunicación a los sockets protegidos para la cuenta del usuario_A por todos aquellos sockets protegidos con los que aún no cuente con un acceso; • registrar los accesos de comunicación en la base de datos del connection-broker como registro_accesos; • establecer, por parte del servidor proxy-firewall, la regla de marcado pertinente a cada registro_acceso insertado en la base de datos en esta reivindicación que permita al usuario_A acceder a todos los sockets fuente de las proxificaciones reversas; • solicitar al agente_A, por parte del servidor proxy-firewall, el establecimiento de una sesión de comunicaciones con el dispositivo_AF utilizando unas credenciales de acceso al dispositivo_AF del proceso_A provistas por el servidor proxy-firewall; • solicitar, por parte del agente_A en el establecimiento de dicha sesión, una reserva de un socket protegido del dispositivo_AF por cada socket a proxificar de forma reversa hacia ese dispositivo; • instanciar, por parte del servidor proxy-firewall, un monitor de accesos para actualizar periódicamente el valor última_actividad de todos los registros_acceso del usuario_A necesarios en este método; y • enviar al dispositivo_AF por parte del agente_A la solicitud de establecimiento de las proxificaciones reversas. [Reivindicación 7] El método según las reivindicaciones 1-3 y 6 donde varios sockets protegidos del dispositivo_AF son proxificados de forma reversa en el dispositivo_A por acción del agente_AF usando unos datos de configuración y credenciales de una cuenta“usuario_AAF” definidos por un “perfil_UAAF” que le permiten conectarse a la cuenta del usuario_AAF del dispositivo_A, además comprende: • establecer una sesión segura entre el agente_AF y el servidor proxy-firewall del dispositivo_A por iniciativa del agente_AF; • solicitar en el establecimiento de dicha sesión la reserva de sockets locales protegidos del dispositivo_A para la realización de una proxificación reversa en el dispositivo_A de sockets del dispositivo_AF; • instanciar un fork_AAF del servidor proxy-firewall en la cuenta de usuario_AAF; • solicitar al connection-broker, por parte del fork_AAF, una reserva de sockets locales sin usar para utilizarlos como los socket-proxies reversos indicados en la solicitud recibida; • registrar en la base de datos, por parte del connection-broker, los registros_socket y registros_acceso relativos a los sockets reservados para cada proxificación reversa; • agregar, por parte del connection-broker, un permiso_Au a la base de datos por cada socket reservado para el usuario_AAF; • insertar en el sistema, por parte del fork_AAF, una regla de marcado por cada permiso_Au por medio del framework de red; • instanciar, por parte del fork_AAF, un monitor de accesos para mantener los accesos activos relativos a la proxificación reversa; y • establecer las proxificaciones reversas, por parte del fork_AAF, empleando los sockets reservados. [Reivindicación 8] El método según las reivindicaciones 3-7, además comprende la actualización de la variable última_actividad a instancias del monitor de accesos en cada registro_acceso involucrado en el método en diferentes escenarios: • si el registro_acceso se crea según la reivindicación 3, la variable última_actividad del registro_acceso se actualizará a instancias del monitor de accesos instanciado por el servidor proxy-firewall siempre que haya tráfico de la cuenta del usuario_A hacia el socket- proxy; y • si el registro_acceso se crea según la reivindicación 4,5,6 o 7, la variable última_actividad de cada registro_acceso se actualizará a instancias del monitor de accesos instanciado por el servidor proxy-firewall siempre que se mantenga en ejecución el proceso que solicitó la proxificación que causó la creación de cada registro_acceso en la base de datos. [Reivindicación 9] El método de las reivindicaciones 1-3, donde un proceso denominado “proceso_C” de un dispositivo denominado“dispositivo_C” cursa una petición segura del recurso ofrecido por el socket_B del dispositivo_B a un proxy ejecutado por el usuario_A, además comprende: • La utilización de subdominios de red del dominio principal del proxy como parámetros de la petición que requiere el proxy para poder solicitar la resolución del socket protegido por medio del connection-broker; • un certificado wildcard X.509 configurado adecuadamente para ofrecer seguridad a los subdominios del proxy; • recibir las credenciales del proceso_C en los encabezados de la petición que permiten al proxy verificar la identidad del proceso_C y comprobar si dispone del permiso_Au requerido para cursar la petición; • establecer una comunicación segura entre el proceso_C y el proxy empleando un protocolo de comunicaciones seguro conocido por el proceso_C y el proxy; • suprimir los encabezados de la petición; y • establecer una comunicación entre el proxy y el socket protegido que comunique con el socket_B según la reivindicación 3. [Reivindicación 10] El método según las reivindicaciones 3-9, donde se cierra el acceso de comunicación relativo al registro_acceso cuando la inactividad supera un umbral denominado “umbraljnactividad” en el perfil_A, además comprende: • eliminación de la regla de marcado del sistema operativo del dispositivo_A relativa al registro_acceso; • eliminación del registro_acceso de la base de datos del connection-broker del dispositivo_A; y • eliminación del permiso_Au relativo al registro_acceso en caso de que éste sea relativo a un socket-proxy directo. [Reivindicación 11] El método según la reivindicación 3, donde se requiere actualizar la seguridad en las comunicaciones entre el cliente proxy stand-alone y el servidor proxy stand-alone, además comprende: • solicitar, a través de la sesión de comunicaciones establecida entre el agente_B y el servidor proxy-firewall, el inicio de un procedimiento de la actualización del cliente proxy del agente_B por iniciativa del servidor proxy-firewall; • recibir, por parte del agente_B, la nueva versión del cliente proxy y actualizar el perfil_BA; • probar, por parte del agente_B, la nueva versión del cliente proxy con el perfil_BA actualizado estableciendo una nueva sesión de comunicaciones; y • en caso de establecerse correctamente esta nueva sesión, eliminar la versión anterior del cliente proxy y reemplazarlo con la nueva versión. [Reivindicación 12] Un sistema para comunicar de forma segura sockets de red que comprende: • un módulo software denominado “servidor proxy-firewall” albergado en un dispositivo denominado“dispositivo_A” y que está configurado para: o recibir las solicitudes de establecimiento de sesión de otros dispositivos a través de un protocolo seguro por medio de un servidor proxy stand-alone, o configurar contextos de seguridad estrictos y amplios mediante llamadas al sistema al framework de red del sistema operativo del dispositivo_A, o procesar solicitudes de proxificación o“socket-proxy” a través de sesiones establecidas o de llamadas al sistema de procesos locales, o monitorizar los accesos a sockets locales mediante monitores de acceso, o gestionar las actualizaciones de seguridad de los dispositivos con los que mantenga una conexión, y o establecer, mediante llamadas al sistema hacia el framework de red, la protección de los sockets locales utilizados en las proxificaciones en el dispositivo_A; • un tipo de perfil de configuración del servidor proxy-firewall para definir los aspectos relativos al funcionamiento del servidor proxy-firewall y al connection-broker denominado“perfi l_A”; • un módulo software, que funciona como agente del servidor proxy-firewall, configurado para: o iniciar las solicitudes de establecimiento de sesión hacia el servidor proxy-firewall a través de un módulo software denominado“cliente proxy stand-alone” y que implementa un protocolo seguro, o realizar solicitudes de proxificación de sockets de forma directa y reversa, y o establecer la protección de los sockets locales; siendo este software denominado como: o agente_A, si se encuentra en un dispositivo_A; o agente_AF, si se encuentra en un dispositivo_A foráneo denominado a si vez dispositivo_AF; o agente_B, si se encuentra en un dispositivo denominado“dispositivo_B”; • un tipo de perfil de configuración del agente denominado: o perfi I_BA, si el perfil es para configurar la sesión que el agente del dispositivo_B realiza en el dispositivo_A o o perfil_UAAF, si el perfil es para configurar la sesión que el agente del dispositivo_A realiza con el dispositivo_AF a instancias del usuario_A; • un módulo software denominado“monitor de accesos” empleado para mantener un registro y control sobre las proxificaciones realizadas y los accesos a las mismas en el dispositivo_A; • un tipo de registro del dispositivo_A denominado“registro_socket” relativo a un socket protegido y el cual comprende: o una variable denominada“socket” que guarda el socket protegido al que hace referencia el presente registro_socket y que puede ser de tres tipos: - socket_B, si el socket a registrar es un socket-proxy que ofrece un recurso de un dispositivo_B; - socket_A, si el socket a registrar ofrece un recurso de un proceso del propio dispositivo_A y no es resultado de ningún tipo de proxificación; - socket-proxy; o una variable denominada“alias” que guarda el alias del socket protegido, el cual puede ser de dos tipos: - el alias de un socket_B denominado“alias_B”, y - el alias de un socket_A denominado“alias_A”; o una variable denominada“id_DispSocket” que guarda el id del dispositivo que tiene el socket local protegido y que puede ser de tres tipos: - el id de un dispositivo_B denominado“id_B” si el registro_socket es de tipo socket_B, - el id de un dispositivo_AF denominado“id_AF” si el registro_socket es de tipo socket-proxy, y - el id de un dispositivo_A denominado “id_A” si el registro_socket es de tipo socket_A; o una variable denominada“id_DispProxy” que identifica el id del dispositivo al que conduce el socket protegido; y o una variable denominada“tipo_socket” que determina el tipo de socket protegido al que hace referencia este registro pudiendo encontrarse entre: socket_A, socket_B y socket-proxy. • un tipo de registro denominado“registro_acceso” de un usuario del sistema operativo del dispositivo_A generado por cada acceso concedido a un socket protegido de tipo socket- proxy directo o reverso, el cual comprende: o una variable denominada “conjd” que guarda el identificador del acceso de comunicación al socket-proxy de un usuario_A, o una variable denominada“socket” que almacena el socket protegido al que se concede el acceso que está formado por la dirección de red local y el puerto, o una variable denominada“id_Usuario” que almacena el identificador del usuario_A del proceso_A origen de la petición de comunicación al que se le ha concedido acceso, y o una variable denominada“última_actividad” que guarda el momento en el que se le ha concedido el acceso y que se actualizará por un monitor de accesos reflejando su estatus de actividad; • un tipo de registro denominado“registro_acceso_A” de un grupo de usuarios del sistema operativo del dispositivo_A generado por cada acceso concedido a un socket protegido de tipo socket_A, el cual comprende: o una variable denominada“conjd” que almacena el identificador del acceso con el mismo nombre, o una variable denominada“socket” que almacena el socket_A, y o una variable denominada“id_Grupo” que almacena el id del grupo del usuario del sistema operativo del dispositivo_A correspondiente al usuario_A del proceso_A origen de la petición de comunicación al que se le ha concedido acceso; • un tipo de registro para definir el permiso de acceso denominado“permiso_Au”, que define un contexto de seguridad estricto al otorgar al usuario_A del dispositivo_A la posibilidad de acceder a un socket protegido de tipo socket-proxy directo o reverso, el cual comprende: o una variable denominada“id_Usuario” que guarda el id del usuario_A del sistema operativo del dispositivo_A, o una variable denominada“alias” que almacena el alias del socket protegido de otro dispositivo que se proxifica como socket-proxy en el dispositivo_A, y o una variable denominada“id_DispSocket” que almacena el id del dispositivo con el socket_B o socket_A relativo al alias del socket que ofrece el recurso a través del socket-proxy; • un tipo de registro para definir el permiso de acceso denominado“permiso_AG” que define un contexto de seguridad amplio al otorgar la posibilidad de acceso de un grupo de usuarios del dispositivo_A a un socket_A y que comprende: o una variable denominada“id_Grupo” que almacena el id del grupo de usuarios del sistema operativo del dispositivo_A, o una variable denominada“alias” que almacena el alias del socket_A, y o una variable denominada“socket” que guarda el valor del socket_A; • un módulo software denominado connection-broker empleado para mantener un registro y control sobre las proxificaciones realizadas y los accesos a las mismas en el dispositivo_A pudiendo cerrarlas si se encuentran inactivas; • un pool de direcciones locales del dispositivo_A reservadas específicamente para este sistema y que son protegidas al arrancar el sistema operativo del dispositivo_A por el framework de red a instancias del servidor proxy-firewall por medio de las siguientes reglas generales: o una regla general de marcado de paquetes que determine eliminar cualquier posible marcado de paquetes de red en cualquier comunicación, producida entre sockets locales del dispositivo_A, con direcciones locales pertenecientes al pool de direcciones locales reservado; o una regla general de filtrado de paquetes que determine descartar cualquier paquete con origen y destino un socket local del dispositivo_A que carezca de un marcado, siempre y cuando alguno de los sockets utilice una dirección de red local perteneciente al pool de direcciones locales reservado; y o una regla general de filtrado de paquetes que determine descartar cualquier paquete con origen o destino una dirección local del pool de direcciones locales reservado para este método que tenga como origen o destino una dirección no local; • un tipo de contexto de seguridad denominado“contexto de seguridad estricto” llevado a cabo por una configuración del framework de red que realiza un marcado en los paquetes del tráfico utilizando el conjd asignado en el registro_acceso relativo al socket protegido destino del dispositivo_A, el usuario origen de la comunicación también del dispositivo_A y el permiso_Au que habilita el registro_acceso; • un tipo de contexto de seguridad denominado“contexto de seguridad amplio” llevado a cabo por una configuración del framework de red que realiza un marcado en los paquetes del tráfico utilizando el conjd asignado en el registro_acceso relativo al socket protegido destino del dispositivo_A, y el grupo del usuario origen de la comunicación también del dispositivo_A y el permiso_Ac que habilita el acceso; y • una base de datos del connection-broker configurada para almacenar distintos tipos de registros que comprenden: registro_socket, registro_acceso, registro_acceso_A, permiso_Au y permiso_AG. [Reivindicación 13] El sistema de la reivindicación 12, en donde los dispositivos utilizan un sistema operativo de tipo POSIX, además emplea un cliente proxy y un servidor proxy stand-alone basado en el protocolo seguro SSH y donde Netfilter, el framework de red utilizado, realiza el marcado y filtrado de paquetes utilizando el campo TOS del protocolo IP. [Reivindicación 14] El sistema de la reivindicación 12 y 13, en donde un dispositivo_B también dispone de un servidor proxy-firewall que permite incluir en el perfil_BA aspectos de configuración que extienden el control que dispone el servidor proxy-firewall del dispositivo_A sobre todos los módulos software del dispositivo_B para facilitar el desarrollo de servicios que impliquen llamadas al sistema, como es la actualización de módulos software del dispositivo_B. [Reivindicación 15] El sistema de las reivindicaciones 12 y 13, en el que el socket_B del dispositivo_B ofrece un recurso utilizando el protocolo HTTP y el dispositivo_A utiliza un proxy como módulo software de tipo HTTPS-HTTP para poder aceptar y procesar las solicitudes externas de comunicación hacia el socket protegido que se cursen en HTTPS, además comprende: • la configuración de un certificado SSL wildcard para proteger el dominio principal del proxy HTTPS-HTTP del dispositivo_A y todos sus subdominios posibles; « la configuración de un servidor web en el dispositivo_A para poder redirigir la petición de comunicación del recurso del socket_B de forma transparente a la URL principal del proxy HTTPS-HTTP aprovechando los subdominios como campos para identificar el socket-proxy destino de dicha petición y utilizando como subdominios el alias del socket_B y el identificador del dispositivo_B; y · una configuración adecuada del proxy HTTPS-HTTP que permita obtener de los encabezados de la petición las credenciales requeridas para validarla y eliminarlos de la misma antes de transmitirla hacia el socket-proxy. |
Título de la invención: Método y sistema de comunicación segura por
proxificación de sockets de red
Sector técnico
La presente invención se refiere al sector de las telecomunicaciones y particularmente al área telemática.
Técnica anterior
El constante y creciente número de dispositivos y automatismos derivados del auge del Internet de las Cosas (loT), junto con el despegue de la Industria 4.0, ponen de manifiesto la importancia de simplificar el control de las comunicaciones y la gestión de su seguridad. Anteriormente, el número de dispositivos desatendidos en cualquier tipo de proyecto era sensiblemente inferior, lo que presuponía una interacción directa entre los dispositivos con el usuario final o el operador de red en mayor o menor grado. Sin embargo, el elevado número de elementos que conforman estas redes y su previsión de crecimiento exponencial en el tiempo modifica este tipo de interacción directa, ya que resultaría inviable en la mayoría de las ocasiones y va en contra de una tendencia de automatización generalizada. Por ese motivo, se requiere que determinados aspectos de seguridad funcionen de forma sólida, estandarizada y confiable para evitar que, por ejemplo, un supervisor de red tenga que analizar continuamente elemento a elemento el estatus de cada dispositivo; a la par que se favorezca la escalabilidad e interconectividad, potenciando las funcionalidades de esta tecnología.
La seguridad en las comunicaciones en el loT, particularmente en dispositivos de alto nivel con capacidad de ser actualizados, generalmente se plantea como una prestación que debe proporcionar el software/firmware de cada dispositivo en conjunción con la plataforma software que se encargue de gestionarlos, administrarlos y de la que deriven recursos y servicios. Independientemente del protocolo de comunicaciones empleado para ello, la solución actual utilizada implica embeber el software de autenticación y encriptación de las comunicaciones en el propio firmware del dispositivo o en la aplicación principal que éste utiliza. Dicho software proporciona una protección criptográfica del canal de comunicaciones para evitar ataques a la seguridad en algún punto intermedio de la misma evitando, entre otros:
• Que la información que se intercambia pueda ser escuchada (eavesdropping).
• Que la información intercambiada pueda modificarse, replicarse, alterarse su orden o falsificarse sin que este hecho sea detectado por el receptor de la comunicación (tampering). • Que el receptor con el que se comunica el emisor de la comunicación suplante la identidad del auténtico receptor de la misma, y este agente usurpador, a su vez, se haga pasar por el emisor de la comunicación de cara al receptor (man in the middle).
Este tipo de protección criptográfica se consigue, en la mayoría de las ocasiones, utilizando un framework de seguridad en el desarrollo de las aplicaciones que utilice Transport Layer Security (TLS) o algún protocolo de seguridad propietario. En ambos casos, una modificación que requiera actualizar algoritmos o determinadas configuraciones de los aspectos de seguridad suele requerir actualizar la aplicación completa y, en muchos casos, también el firmware del dispositivo. Algunos ejemplos de este tipo de implementaciones se encuentran en dispositivos que utilicen COAP, MQTT, HTTP o HTTP/2 con seguridad.
Este tipo de diseños, en los que el protocolo de seguridad se encuentra integrado en el software, conduce a la necesidad de mantener activos los equipos de desarrollo de ese software para todas sus versiones y para cada modelo de dispositivo que actualmente haga uso de ello; por lo que las empresas fabricantes tienden a limitar en el tiempo el soporte que dan a los productos que comercializan animando a sustituir el dispositivo completo por su nueva versión en caso de quedarse obsoleto su firmware o la seguridad de la aplicación. En el medio plazo, esta idea frecuentemente no representa una alternativa real para el consumidor final; ya que debe contemplar como coste, no sólo el importe de los nuevos dispositivos, sino la sustitución de los antiguos por los nuevos, formación para los empleados y actualización de sus procesos internos entre otros.
La falta de previsión en estos costes por parte de las empresas fabricantes de tecnología loT conduce a que los consumidores opten por seguir trabajando con dispositivos obsoletos en aspectos relativos a su seguridad. En muchas ocasiones, estos dispositivos no requieren manejar información sensible (ciertas redes de sensores) por lo que, aún en el caso de reconocerse esos dispositivos como vulnerables, el usuario final opta por mantenerlos ya que no le suponen ningún riesgo real. Todo esto, conduce a un escenario en el que infraestructuras críticas ajenas acaban corriendo el riesgo de ser amenazadas (comúnmente a través de ataques de denegación de servicio o DoS) por botnets creadas a raíz precisamente de estos dispositivos loT vulnerables que han logrado ser infectados con código malicioso, pero que aparentemente continúan funcionando con normalidad.
Resumen de la invención
La presente invención queda caracterizada por las reivindicaciones independientes y las reivindicaciones dependientes exponen ejemplos de realización de distintos aspectos de la invención. El presente método y sistema presentados aportan soluciones para los problemas del estado del arte proponiendo un sistema de comunicación segura basado en proxificación que permita a las aplicaciones de los dispositivos delegar las funcionalidades de seguridad en módulos de software independientes y stand-alone que se puedan actualizar sin afectar al resto del software de los dispositivos. Este objetivo, se consigue combinando una comunicación segura basada en proxificaciones entre dispositivos junto con un control de las comunicaciones locales, empleando para esto último contextos de seguridad que permiten restringir el acceso a dichas proxificaciones en función del origen de la comunicación. Esta estrategia permite simplificar enormemente el desarrollo de las aplicaciones y el mantenimiento de la seguridad a medio y largo plazo, aun cuando el soporte de dichas aplicaciones deje de realizarse. Esto es posible gracias a que el sistema descrito en la invención no forma parte de las aplicaciones y puede actualizarse sin afectarlas.
En los dibujos y diagramas que se acompañan, se ilustran a modo de ejemplo distintos aspectos de posibles realizaciones de la presente invención. Para facilitar la comprensión de la invención, se adjunta la interpretación de los conceptos más relevantes utilizados en este documento:
• Proxificar: Acción de ofrecer el servicio o recurso provisto por un socket de red en otro socket de red diferente, pudiendo este socket ubicarse en un dispositivo remoto.
• Proxificación o socket-proxy: Resultado de la acción de proxificar en el que se define un nuevo socket de red, por medio del cual es posible acceder al socket origen de la proxificación de forma transparente y obtener los recursos o servicios ofrecidos por el mismo.
• Servidor proxy-firewall: (1 11) Un módulo software que está configurado para:
o Recibir las solicitudes de establecimiento de sesión de otros dispositivos a través de un protocolo seguro por medio de un servidor proxy stand-alone
o Configurar contextos de seguridad estrictos y amplios mediante llamadas al sistema (427) al framework de red del sistema operativo del dispositivo_A.
o Procesar solicitudes de proxificación denominadas“socket-proxy” a través de sesiones establecidas o llamadas al sistema de procesos locales
o Monitorizar los accesos a sockets locales mediante monitores de acceso
o Gestionar las actualizaciones de seguridad de los dispositivos con los que mantenga una conexión.
o Establecer, mediante llamadas al sistema hacia el framework de red, la protección de los sockets locales utilizados en las proxificaciones en el dispositivo_A.
• Proxificación directa: (114) Un tipo de proxificación que se produce cuando el socket-proxy resultado de la misma se genera en el dispositivo que inicia la sesión para ello, y ese socket-proxy ofrece recursos o servicios de un socket del dispositivo a donde se dirige el establecimiento de sesión. • Proxificación reversa: (115) Un tipo de proxificación que se produce cuando el socket-proxy resultado de la misma se genera en el dispositivo a donde se dirige el establecimiento de sesión para ello, y este socket-proxy ofrece recursos o servicios de un socket del dispositivo que inicia el establecimiento de sesión.
• Espacio del usuario: (418) Área de memoria donde operan los procesos de los usuarios del sistema operativo.
• Espacio del kernel: (419) Área de memora donde operan exclusivamente los procesos del núcleo del sistema operativo.
• Entorno del usuario: Entorno del sistema operativo en el que aplican o tienen efecto las configuraciones y privilegios asociados al usuario de dicho entorno.
• Framework de red: (107) (420) Conjunto de herramientas que interactúan con el sistema operativo o que forman parte de él y que permiten configurar el tratamiento que reciben los paquetes de las comunicaciones que se cursan del espacio usuario al espacio del kernel y viceversa.
• Socket protegido: Socket de red local cuyo acceso se encuentra restringido en base a reglas de filtrado del framework de red del sistema operativo del dispositivo.
• Contexto de seguridad: Entorno de red local caracterizado por unos permisos de acceso a ciertos sockets de red protegidos.
• Contexto de seguridad estricto: Contexto de seguridad aplicado entre un socket protegido y el espacio usuario de un usuario concreto del mismo sistema operativo. En la presente invención, se genera un contexto de seguridad estricto cuando se aplica un permiso_Au en un socket-proxy del dispositivo_A por medio de reglas del framework de red. También se generan en el dispositivo_B cuando se aplican las reglas descritas en el pefil_B A .
• Contexto de seguridad amplio: Contexto de seguridad aplicado entre un socket protegido y el espacio usuario de múltiples usuarios del mismo sistema operativo pertenecientes a un mismo grupo. En la presente invención, se genera un contexto de seguridad amplio cuando se aplica un permiso_Ac en un socket protegido.
• Agente: un módulo software que actúa como agente del servidor proxy-firewall desde un dispositivo remoto. Este software está configurado para:
o Iniciar las solicitudes de establecimiento de sesión de comunicación hacia el servidor proxy-firewall a través de un protocolo seguro
o Realizar solicitudes de proxificación de sockets de forma directa y reversa
o Establecer, mediante llamadas al sistema hacia el framework de red, la protección de los sockets locales utilizados en las proxificaciones en el dispositivo_B.
El agente se denomina de distintas maneras según sea el dispositivo en el que se encuentre: o Agente_A: (408) si se encuentra en un dispositivo_A. Sólo es necesario en el dispositivo_A si éste requiere realizar proxificaciones con otros dispositivos_A.
o Agente_AF, si se encuentra en un dispositivo_AF. o Agente_B: (109) si se encuentra en un dispositivo dispositivo_B.
• Cliente proxy: (112) (409) Módulo software complementario de cualquier agente que implementa el protocolo de comunicaciones seguro que se usa para el establecimiento de la sesión de comunicaciones y para realizar las proxificaciones, tanto directas como reversas.
• Servidor proxy: (113) (422) Módulo software complementario del servidor proxy-firewall que implementa el protocolo de comunicación seguro que se usa para el establecimiento de sesión y que recibe y procesa las solicitudes de proxificaciones; tanto directas como reversas.
• Connection-broker: (121) (415) Módulo software empleado para mantener un registro y control sobre las proxificaciones realizadas y los accesos a las mismas en el dispositivo_A. También se ocupa de cerrar periódicamente los accesos inactivos.
• Dispositivo_A: (106) (405) Elemento hardware que alberga al menos: un servidor proxy-firewall, un connection-broker, un framework de red, una base de datos, un perfil_A y opcionalmente un agente_A. En la presente invención, si algún proceso requiere de dos dispositivos_A, el dispositivo sobre el que se describe el procedimiento principal se constituye como el dispositivo_A y el otro como dispositivo_AF.
• Dispositivo_AF: Elemento hardware equivalente en funcionalidades a un dispositivo_A. La razón de diferenciarlo como dispositivo_AF persigue el facilitar la explicación de las comunicaciones que se puedan producir entre dos dispositivos_A.
• Dispositivo_B: (101) Elemento hardware que alberga al menos un framework de red, un agente_B y un perfil_BA. En caso de albergar también un servidor proxy-firewall, la configuración de operación de este módulo software se incluye también en el perfil_BA, pues este servidor proxy-firewall tendrá funciones reducidas y orientadas a extender el control que el servidor proxy-firewall del dispositivo_A dispone de los módulos software del dispositivo_B, particularmente para procesos de actualización.
• Base de datos: (122) (414) Módulo software configurado para guardar y consultar distintos tipos de registros utilizados en la invención, entre los cuales se encuentran: registro_socket, registro_acceso, registro_acceso_A, permiso_Au y el permiso_Ac.
• Perfil_B A : Perfil de configuración del agente del dispositivo_B para configurar la sesión de conexión al servidor proxy-firewall del dispositivo_A. En este perfil también se encuentran las credenciales para conectarse al dispositivo_A utilizando la cuenta de usuario usuario_A B del sistema operativo del dispositivo_A. Así mismo, también incluye información relativa a la capacidad del usuario_A B de solicitar proxificaciones en el dispositivo_A, siendo dicha capacidad validada por el servidor proxy-firewall tras cada solicitud de proxificación.
• Perfil_A: Perfil de configuración del servidor proxy-firewall y del connection-broker del dispositivo_A. • Perfil_UAAF: Perfil de configuración para el agente del dispositivo_A para configurar la sesión de conexión al proxy-firewall del dispositivo_AF. Este perfil pertenece al usuario_A y en él, también se encuentran las credenciales para conectarse al dispositivo_AF utilizando la cuenta de usuario usuario_AAF del sistema operativo del dispositivo_AF. En este perfil también se encuentra información relativa a la capacidad del usuario_AAF de solicitar proxificaciones en el dispositivo_AF, siendo dicha capacidad validada por el servidor proxy- firewall del dispositivo_AF tras cada solicitud de proxificación.
• Usuario_AB: Usuario del sistema operativo del dispositivo_A que es utilizado por el agente_B cuando éste se conecta al dispositivo_A utilizando las credenciales definidas en el perfil_BA.
• Usuario_AAF: Usuario del sistema operativo del dispositivo_AF que es utilizado por el agente_A cuando éste se conecta al dispositivo_AF utilizando las credenciales definidas en el perfil_UAAF.
• Socket_A: (123) Socket protegido del dispositivo_A que ofrece recursos o servicios a procesos locales y dispositivos remotos por medio de proxificaciones directas o reversas.
• Socket_B: (118) Socket protegido del dispositivo_B que ofrece recursos o servicios a dispositivos remotos a través de un socket-proxy reverso en el dispositivo_A.
• Socket_AF: Socket protegido del dispositivo_AF que ofrece recursos o servicios a procesos locales y dispositivos remotos por medio de proxificaciones directas o reversas.
• Alias: identificador referido a un socket concreto que sirve para nombrar el socket de un dispositivo. Es importante remarcar que el alias hace referencia al socket original que ofrece un servicio o recurso. Todas sus proxificaciones heredarán este alias, el cual puede ser de varios tipos:
o Alias_B: si el alias hace referencia a un socket_B de un proceso del dispositivo_B. o Alias_A: si el alias hace referencia a un socket_A de un proceso del dispositivo_A.
• ld_DispSocket: Variable relativa al registro_socket de un socket protegido que identifica, junto con el alias del socket de dicho registro, el socket protegido del dispositivo. Esta variable hace referencia al id del dispositivo con el proceso que originó el socket que ofrece el recurso o servicio y puede almacenar tres tipos de identificadores:
o Un id_B, si el alias del registro_acceso refiere a un socket_B.
o Un id_AF, si el socket del registro_acceso comunica con un socket_proxy.
o Un id_A, si el alias del registro_acceso refiere a un socket_A.
• ld_DispProxy: Variable relativa al registro_socket de un socket protegido que identifica el id del dispositivo con el que se mantiene una sesión para poder acceder al socket referido por el alias y el id_DispSocket del registro. En el caso particular de que el registro_socket se refiera a un socket-proxy de otro socket-proxy, el id_DispSocket se referirá al id del dispositivo del segundo socket-proxy. • Tipo_socket: Variable relativa al registro_socket de un socket protegido que identifica el tipo de socket al que hace referencia dicho registro pudiendo ser socket-proxy reverso, socket-proxy directo o socket_A. Los socket-proxy reversos y directos a su vez pueden ser también de tipo socket_A, socket_B y socket-proxy, indicando este último que el socket protegido es una proxificación de otro socket-proxy.
• Registro_socket: un tipo de registro del dispositivo_A relativo a un socket protegido. Se guarda en la base de datos del connection-broker y comprende de:
o Una variable denominada socket, que guarda el socket protegido al que hace referencia el presente registro_socket.
o Un alias del socket al que hace referencia el presente registro_socket.
o Un id_DispSocket relativo al dispositivo con el socket al que hace referencia el alias o Un id_DispProxy que identifica el dispositivo al que conduce la sesión en la que se genera el socket protegido
o Un tipo_socket.
• Con_ld: Identificador del macado realizado en el tráfico de red relativo a la comunicación con un socket protegido. Este id determina la cuenta de usuario o el grupo de usuarios fuente de dicha comunicación, registrada en la base de datos del connection-broker con destino ese socket protegido específico.
• ld_Usuario: Identificador de un usuario o de la cuenta relativa al mismo en el sistema operativo del dispositivo_A. Este identificador representa unívocamente al usuario y su cuenta de usuario, pudiéndose utilizar estos dos conceptos de forma indistinta en escenarios relativos a los contextos de seguridad del dispositivo_A.
• Última_actividad: Variable relativa a un registro_acceso de un usuario_A a un socket-proxy que define el último momento en el que hubo actividad relacionada con el socket protegido al que se hace referencia en el registro_acceso.
• Registro_acceso: un tipo de registro relativo a una cuenta de usuario del sistema operativo del dispositivo_A y que se genera por cada acceso concedido a un socket protegido de tipo socket-proxy directo o reverso, el cual comprende:
o Un conjd, que guarda el id del acceso relativo a este registro.
o Una variable denominada“socket” que almacena el socket protegido al que se concede acceso y está formado por la dirección de red local y puerto
o Un id_Usuario, que guarda el id del usuario al que se concede el acceso
o Una última_actividad que inicialmente guarda el momento en el que se crea el registro y posteriormente se actualiza periódicamente (si procede) por el monitor de accesos.
• Registro_acceso_A: un tipo de registro relativo a un grupo de usuarios del sistema operativo del dispositivo_A, que se genera por cada acceso concedido a un socket protegido de tipo socket_A, y el cual comprende:
o Un conjd, que guarda el id del acceso relativo a este registro. o Una variable denominada“socket” que almacena el socket_A.
o Un id_Grupo, que guarda el id del grupo del usuario al que se concede el acceso.
• Monitor de accesos: Módulo software empleado para mantener un registro y control sobre las proxificaciones realizadas y los accesos a las mismas en el dispositivo_A. Éste puede funcionar de dos maneras:
o Verificando periódicamente si existe tráfico relativo a un socket protegido, y en cuyo caso, actualiza el estatus de última_actividad del registro_acceso pertinente
o Actualizando periódicamente el estatus de última_actividad del registro_acceso de los accesos que monitoriza para garantizar la accesibilidad a los sockets protegidos respectivos mientras el proceso que solicitó los accesos siga en ejecución.
Cuando un monitor de accesos termina, bien al no haber actividad a lo largo de un periodo de tiempo determinado o porque el proceso responsable de las proxificaciones ha terminado, se dejan de actualizar los registros_acceso de los que se encargaba. Esto provoca que la inactividad de esos registros_acceso se incremente y eventualmente sean cerrados por el connection-broker. Cuando esto ocurre, el servidor proxy-firewall es notificado para que borre las reglas de marcado pertinentes y cierre los accesos relativos a los registros_acceso borrados. Si los registros_acceso borrados se referían a una proxificación entre un dispositivo_A y un dispositivo_AF, el connection-broker también elimina el registro_socket y el permiso_Au relativo a cada registro_acceso.
• Permiso_Au: Este tipo de permiso sirve para otorgar acceso al usuario_A a un socket protegido que sea un socket-proxy a través de un contexto de seguridad estricto. Se guarda como registro en la base de datos del connection-broker y dicho registro comprende las siguientes variables:
o id_Usuario, que guarda el id del usuario del sistema operativo del dispositivo_A.
o alias, que almacena el alias del socket protegido que se proxifica como socket-proxy en el dispositivo_A.
o id_DispSocket, que almacena el id del dispositivo con el socket_B o socket_A relativo al alias del socket que ofrece el recurso a través del socket-proxy.
• Permiso_Ac: Este tipo de permiso sirve para otorgar el acceso de un grupo de usuarios del dispositivo_A a un socket_A a través de un contexto de seguridad amplio y comprende las siguientes variables:
o id_Grupo, que almacena el id del grupo de usuarios del sistema operativo del dispositivo_A al que se le otorga el permiso de acceso
o alias, que almacena el alias del socket_A.
o socket, que guarda el valor del socket_A.
• Sandbox-jail: Conjunto de reglas de filtrado de paquetes que configuran una protección de acceso a los sockets protegidos. También restringe los destinos de las comunicaciones. • Acceso concedido a un socket protegido: se denomina acceso concedido a un socket protegido, o simplemente“acceso concedido” a la configuración de un contexto de seguridad que habilite a un usuario de un sistema operativo para acceder a un socket protegido local. Un solo acceso concedido es aplicable a cualquier número de conexiones concurrentes realizadas desde la cuenta de ese usuario al socket protegido al que hace referencia dicho acceso.
• Aplicación final: Aplicación utilizada por un usuario final.
• Usuario final: Persona física que requiere a través de una aplicación final un recurso o solicita un servicio de una plataforma.
• Plataforma: (105) (413) Módulo software que permite monitorizar y administrar la información y servicios que son ofrecidos por otros dispositivos de la red. Esta información y servicios que ofrece la plataforma, principalmente se obtienen a partir de los dispositivos_B. La función principal de la plataforma consiste en procesar estos datos y servicios para ponerlos a disposición de los usuarios finales en forma de recursos propios. Por otro lado, también puede actuar de forma directa sobre los elementos de la red que gestione para modificar su configuración o requerir actuaciones de los mismos utilizando los sockets protegidos locales a los que tenga acceso.
• Host: Máquina física o virtual con sistema operativo multiusuario que alberga una o varias plataformas.
• Proxy: (410) (423) Módulo software utilizado por cada tipo de protocolo empleado por las solicitudes de comunicación dirigidas a un socket protegido que no emplee el mismo tipo de protocolo de comunicación que el utilizado por el proceso origen de la solicitud. El proxy funciona como traductor entre protocolos para hacer la comunicación transparente y entre sus funciones figuran las siguientes:
o Autenticar las solicitudes de comunicación con credenciales de algún usuario del sistema operativo del dispositivo_A que disponga de permiso_Au o que pertenezca a un grupo con permiso_Ac que le permita acceder al socket protegido
o Habilitar un registro_acceso en caso de ser necesario mediante llamadas al sistema o Retirar las credenciales de autenticación de la comunicación para que ésta pueda enviarse al socket protegido y dicho proceso de autenticación sea transparente a este último;
Esta invención permite que los procesos establezcan comunicación entre ellos utilizando proxificaciones sin tener que depender directamente de protocolos de seguridad. De este modo, los dos procesos que requieren comunicarse entre sí pueden realizar dicha comunicación de forma local en un contexto de seguridad que permite que dicha comunicación sea además transparente gracias a la proxificación. Contextos de seguridad:
La comunicación entre los procesos mediante proxificación entre dos dispositivos consta de tres segmentos: El segmento intermedio, que comunica ambos dispositivos y queda protegido por la sesión de comunicación entre el agente y el servidor proxy-firewall; y los dos segmentos locales, que comunican cada extremo de la proxificación con los procesos respectivos. Cada uno de estos dos segmentos, son vulnerables si no se aplica un contexto de seguridad, puesto que cualquier proceso puede acceder a los puertos que estén en escucha, lo cual resulta inseguro ya que las aplicaciones que se comunican delegaron toda responsabilidad de seguridad en el agente y el servidor proxy-firewall. Por ese motivo, la presente invención define el concepto de socket protegido y de contexto de seguridad.
Los contextos de seguridad consisten en reglas aplicadas por medio del framework de red de dos tipos: Reglas de marcado y reglas de filtrado de tráfico de red. Las reglas, a su vez, pueden ser generales o prioritarias y su combinación permite proteger las comunicaciones locales entre procesos y proxificaciones. Estos contextos son un tipo de sandbox-jail que impiden que se procesen las comunicaciones con sockets ajenos a los encontrados dentro del mismo.
La definición de las reglas de marcado y filtrado que configuran los sockets protegidos y los contextos de seguridad utilizan dos elementos: El socket local destino de la comunicación y el usuario o grupo cuyo proceso es origen de la comunicación de los paquetes de red. Este último dato se debe insertar en el tráfico de red mediante el marcado de los paquetes ya que, en la mayoría de los protocolos de red, no existe una traslación de este dato al mismo. Por consiguiente, es necesario utilizar un framework de red que configure el sistema operativo para que introduzca ese dato en forma de marcado. Por otro lado, aclarar que el intentar identificar el origen de la comunicación por el socket origen resulta generalmente complicado debido a que las aplicaciones utilizan un socket diferente cada vez que solicitan establecer una comunicación. El contexto de seguridad, se define por tanto con el socket destino y el id de usuario origen o del grupo de usuarios origen de la comunicación. Esa información se traduce a un identificador de conexión al socket destino que se añade a cada paquete de tráfico de red para poder identificar el flujo de comunicación.
Una vez queda definido el procedimiento de marcado para las comunicaciones permitidas, el procedimiento de filtrado es sencillo: los sockets protegidos deben ser únicamente accesibles por comunicaciones marcadas por el sistema operativo en base a reglas del framework de red y dichas comunicaciones sólo pueden ser locales y pertenecientes a un rango de direcciones locales reservado y protegido. En este escenario, la vulnerabilidad de las comunicaciones queda restringida a la posibilidad de que un usuario o proceso pueda obtener privilegios elevados que le permitan controlar el framework de red.
Protección del pool de direcciones reservadas: Un pool de direcciones locales del dispositivo_A queda reservado en el perfi l_A específicamente para este sistema. Estas direcciones son protegidas al arrancar el sistema operativo del dispositivo_A por el framework de red a instancias del servidor proxy-firewall por medio de las siguientes reglas generales:
• Una regla general de marcado de paquetes que determine eliminar cualquier posible marcado de paquetes de red en cualquier comunicación, producida entre sockets locales del dispositivo_A, con direcciones locales pertenecientes al pool de direcciones locales reservado.
• Una regla general de filtrado de paquetes que determine descartar cualquier paquete con origen y destino un socket local del dispositivo_A que carezca de un marcado siempre y cuando alguno de los sockets utilice una dirección de red local perteneciente al pool de direcciones locales reservado.
• Una regla general de filtrado de paquetes que determine descartar cualquier paquete con origen o destino una dirección local del pool de direcciones locales reservado para este método que tenga como origen o destino una dirección no local.
Además, se debe realizar la supresión, durante la secuencia de arranque del sistema operativo del dispositivo_A, de cada registro_acceso y permiso_Au de la base de datos relativo a cada registro_socket cuyo tipo_socket sea socket-proxy, y la supresión del propio registro_socket; ya que esos registros_acceso y registros_socket son relativos a proxificaciones entre dispositivos_A y son considerados temporales.
Método de comunicación segura por proxificación de sockets de red:
A continuación, se expone el método que permite realizar comunicaciones seguras entre procesos por medio de proxificaciones de sockets de red. Para ello, inicialmente se establecen los sockets protegidos en el dispositivo_B y en el dispositivo_A y todo ello comprende las siguientes acciones:
• Durante el arranque del dispositivo_A, el servidor proxy-firewall ingresa unas reglas de marcado y filtrado a través del framework de red al sistema operativo del dispositivo_A para proteger el pool de direcciones asignado en el perfil_A. Estas reglas de carácter general comprenden:
o Eliminar cualquier posible marcado de paquetes de red generado por los procesos en cualquier comunicación, producida entre sockets del dispositivo_A, con direcciones de red pertenecientes al pool de direcciones locales reservado para este método
o Descartar cualquier paquete con origen y destino un socket local del dispositivo_A que carezca de un marcado, siempre y cuando alguno de los sockets utilice una dirección de red local perteneciente al pool de direcciones reservado para este método. o Durante el arranque del dispositivo_B, el agente_B ingresa al menos, una regla al framework de red del sistema operativo del dispositivo_B para proteger cada socket_B definido en el perfil_BA. Esta regla de carácter general consiste en descartar cualquier paquete de red que tenga una dirección origen no local y el destino sea alguno de los sockets_B.
o Ingresar, durante la secuencia de arranque del sistema operativo del dispositivo_A y a través de un framework de red de este último, una regla general de filtrado de paquetes por parte del servidor proxy-firewall que determine descartar cualquier paquete con origen o destino una dirección local del pool de direcciones locales reservado para este método que tenga como origen o destino una dirección no local.
Una vez se han establecido las reglas de protección del pool de direcciones en el dispositivo_A, se registran los sockets_A en la base de datos que aún no lo estén y se aplican las reglas de marcado pertinentes que definan los contextos de seguridad amplios que correspondan en el dispositivo_A para conceder acceso permanente a los grupos de usuario del dispositivo_A que se definan en el perfil_A. Todo ello comprende de las siguientes acciones:
• El ingreso, si no existe, durante la secuencia de arranque del sistema operativo del dispositivo_A de un registro_socket en la base de datos del dispositivo_A relativo a cada socket_A del dispositivo_A recogido en el perfi l_A conteniendo cada registro_socket información que comprende:
o El id_DispSocket, que en este caso sería el id_A.
o El id_DispProxy, que en este caso sería también igual al id_A.
o El alias, que en este caso sería igual al empleado por el socket_A a registrar
o El socket, que en este caso sería igual al socket local utilizado por el proceso_A para el socket_A definido en el perfi l_A.
o El tipo_socket, que en este caso sería igual a“socket_A”.
• El ingreso, si no existen, de los permisos_A G y de cada registro_acceso_A tal y como se contemplen en el perfi l_A.
• El ingreso de unas reglas de marcado prioritarias respectivas a cada registro_acceso_A de cada socket_A concedidas permanentemente a los grupos de usuarios del dispositivo_A según esté definida cada una en forma de permiso en la base de datos del connection- broker.
Tras esto, el servidor proxy-firewall verifica a través del connection-broker que en la base de datos no existan accesos en vigor relativos a registros_socket de tipo socket_proxy. En caso de existir, borrará cada registro_acceso asociado a dicho registro_socket incluyendo el propio registro_socket. Estos registros son relativos a proxificaciones entre el dispositivo_A y dispositivos_AF son consideradas temporales y durante el inicio del sistema operativo del dispositivo_A deben suprimirse.
El proceso continúa cuando el servidor proxy-firewall del dispositivo_A recibe una petición de establecimiento de sesión del agente_B para realizar unas proxificaciones, todo lo cual comprende las siguientes acciones:
• Establecer una sesión de comunicaciones segura que permita efectuar proxificaciones de sockets entre el dispositivo_A y el dispositivo_B, donde el primero utilice para ello un servidor proxy-firewall que alberge y el segundo utilice un agente_B que inicie el establecimiento de dicha sesión empleando un cliente proxy stand-alone que implemente un protocolo de comunicación segura usando unos datos de configuración y credenciales del usuario_A B definidos por su perfil_B A . De este modo, el dispositivo_B establece la sesión con el dispositivo_A utilizando la cuenta usuario_A B .
• Posteriormente, proceder con el establecimiento de las proxificaciones directas. Éstas, permiten acceder a cada socket_A requerido desde el dispositivo_B. Dichas proxificaciones las solicita el agente_B según el perfil_B A y quedan protegidas por el protocolo seguro utilizado en la sesión de comunicaciones entre el agente_B y el servidor socket-proxy.
• Establecer las proxificaciones reversas. Éstas, permiten que cada socket_B sea accesible por las aplicaciones del dispositivo_A de forma local siempre y cuando el usuario del sistema operativo que las ejecuta tenga permiso para ello. Cada socket_B que debe proxificarse está definido también en el perfil_B A .
• Registrar las proxificaciones reversas en una base de datos de un connection-broker del dispositivo_A generando un registro_socket por cada una de ellas.
Una vez seguido este método, los procesos del dispositivo_B pueden acceder a cada socket_A proxificado de forma local y los procesos del dispositivo_A que dispongan de permiso_AU pueden acceder a los socket-proxy reversos una vez soliciten la resolución al servidor proxy-firewall del dispositivo_A y se configuren los contextos de seguridad estrictos pertinentes.
Breve descripción de las figuras:
• Figura 1 : Ejemplo de realización de un dispositivo_B y un dispositivo_A en el que el agente_A y el servidor socket-proxy mantienen una sesión por la que se efectúan proxificaciones. A través de estas proxificaciones, el proceso_B y la plataforma pueden comunicarse entre sí.
• Figura 2: Ejemplo de establecimiento de una proxificación directa de un socket_A en un dispositivo_B y de una proxificación reversa de un socket_B en un dispositivo_A.
• Figura 3: Ejemplo de comunicación del proceso_A con un socket de red protegido.
• Figura 4: Ejemplo de realización de un dispositivo_A. • Figura 5: Ejemplo de URL usada en la petición de un recurso de un socket protegido a través de un proxy del dispositivo_A.
• Figura 6: Ejemplo de solicitud de proxificación directa de sockets protegidos de un dispositivo_AF por parte de un proceso_A de un dispositivo_A.
Descripción detallada de la invención
A continuación, se describe la realización preferente y varios ejemplos de la realización de distintos aspectos de la presente invención haciendo referencia a las figuras adjuntas para ilustrar su funcionamiento en diferentes escenarios.
Realización preferente de la invención:
Un ejemplo de la realización de la invención puede encontrarse en la Figura 1. Esta realización está orientada a un ecosistema loT. En este escenario, un ejemplo de dispositivo_B (101) correspondería con todos aquellos dispositivos loT del ecosistema que sean considerados nodos del mismo. En este ejemplo, los dispositivos pueden funcionar con firmwares o sistemas operativos (102) de tipo POSIX (Portable Operating System Interface). Un ejemplo de este tipo de sistemas operativos son los de la familia Linux o alguna de sus variantes. En todo caso, disponen de un kernel que puede hacer uso de un framework de red como Netfilter, que puede estar en el Kernel o ser cargable mediante módulos externos y a través del cual se ingresan reglas de marcado y filtrado (103). Este dispositivo_B posee al menos un proceso_B (104) que desarrolla la funcionalidad principal del dispositivo y que requiere de comunicación con un software de gestión como lo puede ser una plataforma (105) de un dispositivo_A (106).
En el ecosistema loT que se presenta, un ejemplo de dispositivo_A correspondería con el host loT al que se conectan los nodos loT. En este ejemplo, el dispositivo_A cuenta con un sistema operativo también tipo POSIX y también de la familia Linux, pero esto es algo que no resulta imprescindible, ya que al ser sistemas operativos de tipo POSIX, la interoperabilidad entre ellos es factible. En todo caso, el sistema operativo del dispositivo_A, al ser también de la familia Linux en este ejemplo, también cuenta con un kernel con framework Netfilter (107) mediante el que también se ingresan reglas de marcado y filtrado (108). El sistema operativo del dispositivo_A, al ser utilizado en un host loT, es necesario que sea multiusuario y con capacidad de separación de privilegios. De ese modo, cada dispositivo_B que se conecte al mismo podrá utilizar una cuenta de sistema operativo diferente en el dispositivo_A. Esto permite a Netfilter diferenciar los flujos de comunicación y crear contextos de seguridad que extiendan la protección de las comunicaciones en el área local para cada dispositivo.
La seguridad en las comunicaciones entre el dispositivo_A y el dispositivo_B la proporciona un agente_B (109) del dispositivo_B que establece una sesión segura (1 10) con un servidor proxy-firewall (1 11) del dispositivo_A. Esta sesión segura, utiliza un protocolo de seguridad que se ejecuta entre un cliente proxy stand-alone (112) y un servidor proxy stand-alone (1 13). El primero forma parte del agente_B y el segundo, del servidor proxy-firewall. La sesión que establecen entre ellos permite realizar proxificaciones entre los dos dispositivos. Un ejemplo de este tipo de protocolos es SSH, el cual dispone de implementaciones que funcionan como cliente proxy stand-alone y servidor proxy stand-alone como las requeridas en este ejemplo. Algunos ejemplos de estas implementaciones son las de OpenSSH y Dropbear.
El agente_B, utiliza la sesión establecida para proxificar conexiones entre ambos dispositivos según esté especificado en el perfil_BA que utilice dicho agente para establecer la sesión. De este modo, y según la información contenida en dicho perfil, el agente_B crea los socket-proxies directos (114) en el dispositivo_B y socket-proxies reversos (115) en el dispositivo_A que correspondan. El establecimiento de proxificaciones, por tanto, puede realizarse en ambos sentidos, aunque la sesión entre el agente y el servidor proxy-firewall la inicie el agente_B.
Una vez establecidas las proxificaciones, tanto el proceso_B como la plataforma loT pueden comunicarse utilizando los socket-proxies. Si la comunicación la inicia el proceso_B, utilizará el socket-proxy directo local (1 14) que genera el agente_B para comunicarse con el socket_A (123). Dicha comunicación segura tiene tres partes:
• La primera (116), es un segmento local que comprende la comunicación entre el proceso_B y el socket-proxy directo del agente_B. Este segmento de comunicación queda protegido por el contexto de seguridad estricto configurado por el agente_B al arrancar el sistema operativo del dispositivo_B por medio de Netfilter.
• La segunda, entre el dispositivo_B y el dispositivo_A, está encriptada por la sesión SSH (110).
• La tercera (1 17), entre el servidor proxy-firewall y el socket_A de la plataforma queda protegida por un contexto de seguridad amplio configurado por el servidor proxy-firewall a través del Netfilter (107) del dispositivo_A.
Cuando la plataforma loT requiere iniciar una comunicación con el socket_B(118) del proceso del dispositivo_B entonces utiliza uno de los socket-proxies reversos (115) generados en el dispositivo_A; el correspondiente al alias del socket_B y al id_B del dispositivo_B (id_DispSocket) al que pretende acceder la plataforma loT. Esta comunicación también consta de tres partes: la primera (119), entre la plataforma loT y el socket-proxy reverso, queda protegida por un contexto de seguridad estricto configurado por Netfilter en el dispositivo_A. La segunda, entre el dispositivo_B y el dispositivo_A se encuentra protegida por la sesión segura (110) y finalmente la tercera (120), entre el agente y el socket_B (1 18) del proceso_B del dispositivo_B se encuentra protegida por otro contexto de seguridad estricto del dispositivo_B. La gestión de todas las sesiones establecidas, socket-proxies asignados y permisos de acceso a los mismos para usuarios del sistema operativo del dispositivo_A, son manejados por el connection-broker (121) y su base de datos (122) a instancias del servidor proxy-firewall.
El acceso a los sockets_B en el dispositivo_B o a los sockets protegidos del dispositivo_A se facilita mediante unas reglas de marcado prioritarias que definen los respectivos contextos de seguridad estrictos. Las reglas de marcado en este ejemplo se aplican incluyendo el conjd en el campo TOS del protocolo IP. El marcado de tráfico siguiendo esta estrategia facilita la operación de Netfilter y la implementación del servidor proxy-firewall, pero limita a 255 contextos de seguridad distintos aplicables a cada socket protegido. Esta cifra, en el caso de los socket- proxies reversos, es suficiente debido a que los dispositivos loT, suelen ser dispositivos de recursos limitados que no suelen estar preparados para permitir múltiples conexiones simultaneas: la información y los servicios que ofrece se presentan al usuario final o a la aplicación final a través de recursos propios de la plataforma a la que se conectan.
Los sockets_A, son también sockets protegidos y también requieren de permisos de acceso para las cuentas de cada dispositivo_B con procesos que requieran conectarse. El número de contextos estrictos de seguridad necesario en este caso por cada socket_A sería tan grande como el número de dispositivos_B que requieran comunicación dicho socket, y en la mayoría de los proyectos loT sí se superan los 255. Por ello, en este caso, se aplica un solo contexto de seguridad amplio a todo un grupo de usuarios del dispositivo_A, de modo que las cuentas de usuario del dispositivo_A que utiliza cada dispositivo_B al conectarse, compartan el permiso_Ac; para lo cual se incluyen esas cuentas de usuario en un mismo grupo con dicho permiso.
Ejemplo 1 : Establecimiento de una proxificación directa de un socket A en un dispositivo B y de una proxificación reversa de un socket B en un dispositivo A
En la figura 2, se describe un diagrama de secuencia en el que, en una realización de la invención, el dispositivo_B requiere proxificar dos puertos: un socket_A de forma directa y un socket_B de forma reversa. En este ejemplo intervienen un dispositivo_B con un agente_B (201) y un dispositivo_A con un servidor proxy-firewall (202), un connection-broker (203) y una base de datos (204). Este ejemplo es generalizable para establecer cualquier número de proxificaciones directas y/o reversas en la misma sesión sin necesidad de realizarse recurrentemente.
En primer lugar, el agente_B inicia la sesión (205) en el servidor proxy-firewall utilizando la configuración definida en un perfil_B A . Durante el proceso de autenticación (206), el servidor proxy-firewall determina qué tipo y número de proxificaciones son las que el agente_B puede realizar a partir del perfil_B A usado en el establecimiento de sesión. Una vez se realiza la autenticación y se establece la sesión, el servidor proxy-firewall realiza un fork de sí mismo (207) en la cuenta usuario_A B . De este modo, se genera una nueva instancia del servidor proxy-firewall como fork (208) en esa cuenta, lo que permite una separación de privilegios. Este fork solicita (209) al connection-broker la reserva de un socket libre para establecer el socket-proxy reverso para el socket_B. Así mismo, dicha solicitud también contiene un requerimiento de resolución del socket_A para obtener el socket protegido asignado a dicho socket_A. El connection-broker consulta (210) en la base de datos si existe el permiso_Ac para el socket_A e inserta o actualiza el registro_socket para el socket_B según el perfil_B A . Si este registro_socket existía previamente, se verifica si también existe algún registro_acceso en vigor relativo a ese registro_socket. En caso de existir, se mantiene el valor de socket asignado en el registro_socket. Si no existe, el valor de socket para el registro_socket se actualiza con otro nuevo que sea local; perteneciente siempre y en todo caso al pool de direcciones reservadas para este método y que el socket se encuentre disponible. En caso de no existir el registro_socket o en el caso de tener que generar un registro_acceso completo, el socket se elige aleatoriamente entre los que se encuentren libres en el pool de direcciones reservadas.
Una vez terminadas estas acciones, se procede con la respuesta (211). Esta respuesta incluye la resolución del socket_proxy (el valor del socket asignado en el registro_socket para el socket_B) y la resolución del socket_A (el valor asignado en el registro_socket relativo al socket_A) en forma de registros_socket. Tras esto, se notifica al fork de ello (212) y éste a su vez hace lo propio con el agente_B (213). Éste último, cursa una solicitud (214) al fork para que inicie un socket protegido en escucha que corresponda al socket-proxy reverso (215) previamente asignado. Así mismo, el agente_B inicia en escucha un socket local protegido del dispositivo_B que corresponde al socket-proxy directo (216).
Ejemplo 2: Solicitud de un recurso de un socket protegido del dispositivo A por un proceso A
A continuación, se describe a modo de ejemplo un procedimiento por el que se concede un acceso a un socket protegido del dispositivo_A al usuario del proceso_A para que éste pueda comunicarse con dicho socket protegido. Este procedimiento se ilustra con un diagrama de secuencia representado en la Figura 3. El registro_acceso y el contexto de seguridad se aplican en la cuenta de usuario local del dispositivo_A relativo al usuario_A. Los sockets protegidos nunca pueden ser accesibles directamente desde máquinas remotas y sus accesos siempre son locales y por usuarios dentro del contexto de seguridad. Esto es posible gracias a la separación de privilegios de sistemas POSIX que permite configurar los contextos de seguridad.
Para poder acceder al socket protegido (301), la cuenta usuario_A en la que se ejecuta el proceso_A (302) que requiere el acceso, debe disponer del permiso de usuario para ello en la base de datos (303) del connection-broker (304). El proceso_A realiza una solicitud (305) al servidor proxy-firewall (306) para proceder con la resolución del socket protegido a partir del alias del socket y de su id_DispSocket y de ese modo saber a qué socket local dirigir la petición del recurso. Dicha solicitud (305) se produce en este ejemplo mediante una llamada al sistema. El origen de esta llamada no requiere del manejo de credenciales de usuario_A ante el servidor proxy-firewall en la propia solicitud ya que se aprovecha la separación de privilegios del sistema tipo POSIX mediante la cual, el servidor proxy-firewall puede identificar unívocamente la cuenta de procedencia de dicha llamada.
Esta solicitud se valida (307) por el connection-broker, el cual inicialmente realiza una consulta (308) en la base de datos para verificar con su respuesta (309) si el usuario_A tiene permiso. Si el permiso es de tipo permiso_Ac no se requiere de la concesión de un acceso y se procede con la respuesta (310) al servidor proxy-firewall en la que se indica que se dispone de acceso y cuál es el socket protegido. Sin embargo, si el permiso es de tipo permiso_Au, el connection-broker debe de conceder antes el acceso para el usuario_A al socket protegido. Para ello, el connection-broker genera un registro_acceso (31 1) y lo registra en la base de datos (312). Una vez recibida la confirmación (313) de la base de datos de que el registro se guardó correctamente y de que no existía uno previo, se comunica (314) al servidor proxy-firewall la necesidad de configurar el contexto de seguridad estricto para el usuario_A.
El servidor proxy-firewall utiliza la información del registro_acceso para definir la regla de marcado necesaria que conceda el acceso de las comunicaciones del usuario_A al socket protegido. Estas reglas de marcado se insertan (315) en el sistema operativo por medio del framework de red (316). Si hubiese un registro previo válido, no es necesario generar otro registro_acceso para el usuario_A porque el usuario_A ya dispone de acceso. Tras recibir confirmación (317) de la inserción de las reglas (en caso de haber sido necesario), el servidor proxy-firewall instancia un monitor de acceso (318) para actualizar periódicamente el estatus de la variable última_actividad del registro_acceso. En este ejemplo, la monitorización se hace a intervalos de 5 minutos. Este monitor de acceso, al igual que las reglas de marcado y que el registro_acceso sólo se lleva a cabo si no existía otro registro_acceso válido anterior.
Una vez se confirma que el usuario_A dispone de un acceso al socket protegido, el servidor proxy-firewall notifica (319) al proceso_A cuál es el socket protegido al que requiere acceder para que pueda enviar la solicitud (320) del recurso al socket protegido y recibir su respuesta (321).
Ejemplo 3: Acceso a un socket-proxy reverso por un proceso remoto a través de un proxy local del dispositivo A que convierte peticiones del protocolo de aplicación https a peticiones http de forma transparente
En la figura 4 se muestra un ejemplo de realización del dispositivo_A que permite poder acceder (401) (402) (403) a los socket-proxies (404) en el dispositivo_A (405) desde un proceso en un dispositivo diferente al dispositivo_A a través de conexiones proxificadas (406) en sesiones (407) establecidas con dispositivos remotos. El primer caso (401) es un ejemplo de este tipo de comunicación en el que las aplicaciones que utilizan HTTPS acceden a recursos del socket_B, pero sin requerir que el proceso del socket_B de este dispositivo_B tenga que contar con soporte para HTTPS ni esquema de autenticación. Este acceso se realiza a través de un socket-proxy reverso en el dispositivo_A de un socket_B de un dispositivo_B que tiene una sesión establecida con el dispositivo_A.
La comunicación como tal entre la aplicación y el proceso del dispositivo_B es transparente y se efectúa a través de un proxy intermedio (410) que además convierte comunicaciones que utilizan HTTPS en comunicaciones HTTP. En primer lugar, la aplicación final solicita un recurso del dispositivo_B ofrecido por un socket_B proxificado en el dispositivo_A y dirige esta petición (401) hacia el proxy intermedio. Este software, que convierte la petición (501) de HTTPS a HTTP, puede estar implementado en multitud de lenguajes de programación del lado del servidor (41 1); como son por ejemplo PHP, Node.js, Go, Python, etc. Para posibilitar un acceso al socket-proxy correspondiente, el proxy recibe la información del destino de la comunicación por medio de subdominios (502) y también recibe las credenciales que use la aplicación final para conseguir un acceso al socket proxy; estas últimas incluidas en encabezados de la petición.
El servidor web (412) debe estar configurado para redireccionar todas las peticiones en todos los subdominios posibles del proxy hacia la URL principal del proxy intermedio, incluyendo los subdominios como parámetros. De los encabezados, el proxy intermedio obtiene la credencial que la aplicación final adjunta y que permiten al proxy intermedio validar la petición y solicitar acceso al socket_proxy. Las credenciales van protegidas por HTTPS al estar en los encabezados. La petición que recibe el proxy intermedio cuenta con los siguientes elementos:
• El id_DispSocket, que en este caso corresponde con el id_B (503) del socket_B al que conduce el socket-proxy reverso, y que permite identificarlo junto al alias.
• El alias (504) del socket_B que permite identificar el socket-proxy junto al id_DispSocket.
• El dominio (505) del proxy.
• El recurso (506) que se solicita al socket_B.
La protección de las comunicaciones en cualquiera de los subdominios dinámicos que se requieran es posible con un único certificado wildcard SSL basado en certificados X.509 que habilita la protección de HTTPS para el dominio principal del proxy y de todos los subdominios posibles. Por otro lado, la comunicación extremo a extremo también es transparente e independiente de otras comunicaciones que pueda tener la aplicación final con otros socket-proxy al necesitar cada uno un subdominio diferente.
Las credenciales que van en los encabezados, son utilizadas por el proxy intermedio para validar el acceso al socket-proxy para la cuenta de usuario en la que se ejecuta el proxy intermedio según los permisos en la base de datos (414) para esa cuenta de usuario. Este acceso se puede solicitar directamente al connection-broker (415) a través del servidor proxy-firewall (416) o requerir antes una validación previa de la plataforma. Una vez realizada la conversión de HTTPS a HTTP y haberse habilitado el acceso al socket-proxy para la cuenta de usuario que ejecuta el proxy intermedio, éste suprime los encabezados con las credenciales para hacer transparente el proceso de autenticación y envía la petición web HTTP (417) hacia el socket-proxy que corresponda. Esta petición, al pasar del espacio de usuario (418) al espacio del kernel (419) es marcada por el framework de red (420) si el acceso se concedió correctamente y se insertó la regla de marcado correspondiente. Posteriormente, esta petición es enrutada y dirigida (421) hacia el socket-proxy y será cursada o descartada según las reglas de filtrado, pudiendo únicamente ingresar de nuevo al espacio usuario si posee un marcado válido.
Tanto las reglas de marcado como de filtrado se introducen en el framework de red del sistema operativo por iniciativa del servidor proxy-firewall siguiendo las indicaciones descritas en los ejemplos 1 y 2. Finalmente, la petición es recibida por el socket-proxy del servidor proxy stand-alone (422) y transmitida como comunicación proxificada hacia el dispositivo_B.
Ejemplo 4: Acceso a un socket-proxy por un proceso remoto a través de un proxy intermedio del dispositivo A en el que el proxy convierte las peticiones entrantes de la versión segura de un protocolo de aplicación a la versión insegura del mismo:
En este ejemplo, se generaliza el ejemplo anterior. Siguiendo el mismo esquema, el ejemplo 3 se puede aplicar a otros protocolos del nivel de aplicación utilizados por programas de dispositivos_B que requieren de seguridad pero que no la implementan. Algunos ejemplos de estos protocolos pueden ser HTTP/2, MQTT y COAP. Todos ellos tienen también una versión segura de sí mismos, y con un proxy que convierta de forma transparente peticiones seguras a peticiones inseguras resulta factible que los dispositivos_B utilicen la versión insegura del protocolo junto con el sistema expuesto en la presente invención para conseguir una comunicación segura extremo a extremo.
Ejemplo 5: Acceso a socket-proxies por una plataforma que recopila información de ellos, la procesa, almacena y luego la ofrece a las aplicaciones finales en forma de recursos propios
La comunicación (424) representa una modalidad de operación muy común en ecosistemas loT. En este caso, la aplicación final no requiere un“acceso directo” a los recursos de los sockets proxificados, sino a la información y servicios que la plataforma elabora a partir de esos recursos que obtiene de forma autónoma. La plataforma, para ello sí establece comunicaciones periódicas con los sockets protegidos a los que tiene permiso de acceso y de los que recopila información con la que luego elabora sus recursos y servicios propios, los cuales podría seguir ofreciendo aun cuando todas las sesiones (407) estuviesen caídas temporalmente. El modo de operar del sistema propuesto por la presente invención en este caso es análogo al del ejemplo 2. En particular, el proceso_A (302) es aquél que ejecute la plataforma para comunicarse con el socket local que requiera en cada momento. La plataforma debe de disponer para ello de una cuenta de usuario del dispositivo_A con permisos_AU suficientes para poder acceder a todos los socket-proxy relativos a los dispositivos configurados en la plataforma y de los que obtiene los recursos periódicamente. Por otro lado, la plataforma también puede ofrecer información necesaria a otros dispositivos por medio de sockets protegidos de tipo socket_A (425).
Ejemplo 6: Solicitud de acceso a sockets protegidos de un dispositivo AF por medio de proxificaciones directas y a instancias de un proceso A
Este ejemplo ilustra cómo el dispositivo_A, a instancias del proceso_A (601), solicita por medio del servidor proxy-firewall (602) y del agente_A (603) una proxificación directa (604), (426) de unos sockets protegidos de un dispositivo_AF (605). Esto permite que el proceso_A pueda acceder de forma segura a recursos de sockets protegidos en ese dispositivo remoto. Para ello, el proceso_A solicita (606) al servidor proxy-firewall una resolución de sockets remotos suministrando el alias, el id_DispSocket y el id_DispProxy de cada socket protegido al que se desea acceder. En este caso, el id_DispSocket es distinto al id_DispProxy y por ese motivo, el servidor proxy-firewall determina que se requieren proxificar de forma directa esos proxies desde otros dispositivos_AF. En el ejemplo, todos los sockets a proxificar provienen del mismo dispositivo, pero no necesariamente tiene por qué ser así en otros casos.
La solicitud de proxificación directa realizada por el proceso_A al servidor proxy-firewall se realiza mediante una llamada al sistema que instancia el servidor proxy-firewall como proceso de ese entorno de usuario. Para proceder con la proxificación directa, el servidor proxy-firewall inicialmente solicita (607) al connection-broker (608) que reserve y registre (609) en la base de datos (610), unos sockets locales libres que pertenezcan al pool de direcciones protegido para asignar los socket-proxy directos. La reserva de estos sockets implica además la inserción de un registro_socket de tipo socket-proxy, y un registro_acceso por cada socket reservado si dispone de permisos_Au para cada uno de ellos.
Una vez se confirma la reserva (611) de esos sockets locales, el servidor proxy-firewall recibe en la respuesta (612) del connection-broker los sockets reservados y solicita (613) al agente_A el establecimiento (614) de una sesión con el dispositivo_AF para resolver los sockets protegidos que se requieren proxificar. El agente_A utilizará un perfil_UAAF relativo al usuario_A que se autentica en la cuenta usuario_AAF del dispositivo_AF y que es suministrado por el servidor proxy-firewall.
Una vez se establece la sesión usando dichas credenciales, el dispositivo_AF realiza las acciones pertinentes (615) descritas en el ejemplo 7 para procesar la solicitud de proxificación recibida. Cuando el dispositivo_AF responde (616) al agente_A con los sockets protegidos resueltos, el agente_A notifica (617) al servidor proxy-firewall y procede a establecer las proxificaciones directas (604). Aunque los socket-proxy directos ya se encuentran establecidos, el acceso a los mismos no es posible al ser sockets protegidos. Para poder conceder acceso al usuario_A del proceso_A es necesario aplicar los permisos_Au respectivos de la base de datos. Estos permisos, son traducidos por el servidor proxy-firewall en reglas de marcado que se insertan (618) a través del framework de red. Una vez se confirma (619) este ingreso, el servidor proxy-firewall responde
(620) la petición del proceso_A con los sockets-proxy directos resueltos para que pueda conectarse a ellos. Paralelamente, el servidor proxy-firewall instancia un monitor de accesos
(621) que mantiene activos los accesos mientras esté funcionando el proceso_A.
Ejemplo 7: Ejemplo de comunicación en el que un dispositivo AF consigue acceso a unos sockets protegidos de un dispositivo A por proxificación directa
Este ejemplo está vinculado con el anterior: en el ejemplo 6, un dispositivo_A se conectaba con un dispositivo_AF para requerir proxificaciones directas y este ejemplo ilustra lo que ocurre en ese dispositivo_AF. Sin embargo, para mantener la coherencia descriptiva, en el presente ejemplo ese dispositivo_AF será referido como dispositivo_A y el dispositivo que se conecta al dispositivo_A será referido como dispositivo_AF. Una vez aclarado este detalle, se procede a exponer cómo se concede en este ejemplo la proxificación directa de sockets protegidos a un dispositivo_AF.
La primera parte del proceso es similar a la descrita en el ejemplo 1 , con la salvedad de que el dispositivo que inicia la sesión esta vez es un dispositivo_AF (en vez de ser un dispositivo_B) y que la solicitud consiste únicamente en proxificaciones directas. Para ello, El dispositivo_AF dispone de un agente_AF y de un perfil de conexión para conectarse al dispositivo_A que le permite establecer una sesión en la que se solicita la resolución de los sockets protegidos requeridos por el dispositivo_AF. Dicho dispositivo_AF utiliza sus credenciales del perfil_UAAF para conectarse a la cuenta del usuario_AAF en el sistema operativo del dispositivo_A. Esta cuenta debe tener permiso de acceso a los sockets protegidos que se quieren proxificar. Una vez autenticadas las credenciales por el servidor proxy-firewall del dispositivo_A, este software se instancia con un fork de sí mismo bajo la cuenta de usuario_AAF.
Una vez llegado a este punto, el fork del servidor proxy-firewall debe evaluar si el usuario_AAF del dispositivo_A dispone de los permisos necesarios para acceder a los sockets protegidos requeridos por el agente_AF. En el dispositivo_A, el procedimiento de comprobación, marcado y asignación de cada registro_acceso es igual al descrito en el ejemplo 2 y que comprende el diagrama de secuencia de la figura 3 desde (307) hasta (319). Una vez confirmados los permisos y en su caso, concedidos los accesos a los socket-proxies requeridos y definidas e insertadas las reglas de marcado pertinentes, se devuelven los sockes resueltos al agente_AF para que pueda proceder con el inicio de la proxificación directa. Para garantizar que la cuenta de usuario_AAF del dispositivo_A disponga del acceso constantemente mientras dure la sesión, se instancia un monitor de accesos que periódicamente actualice todos los accesos a los sockets- proxy aun si no ha habido tráfico. Esto lo realizará mientras dure la sesión entre el dispositivo_AF y el dispositivo_A.
Ejemplo 8: Establecimiento de una proxificación de sockets protegidos desde un dispositivo A hacia otro dispositivo AF de forma reversa a instancias del proceso A del dispositivo A
Existe la posibilidad de que una plataforma de un dispositivo_AF requiera el acceso a recursos proxificados de dispositivos_B con los que no mantiene sesión, o que esos dispositivos_B requieran de recursos de un dispositivo_A foráneo con el que tampoco mantienen sesión. En este caso, el dispositivo_A que mantiene sesión con los dispositivos_B, toma la iniciativa e inicia un proceso de proxificación reversa de puertos protegidos locales hacia el dispositivo_AF; bien por instancias de algún proceso o por algún tipo de configuración de red establecido que así lo indique. Con la proxificación reversa, el dispositivo_A pone a disposición del dispositivo_AF los sockets protegidos que proxifique. Para ello, el agente_A establece una sesión de comunicación con el dispositivo_AF utilizando un perfil_UAAF suministrado por el servidor proxy-firewall a instancias de un proceso_A.
En este ejemplo, el proceso_A solicita la proxificación reversa al servidor proxy-firewall del dispositivo_A. Al igual que en el ejemplo 2, es imprescindible que el servidor proxy-firewall del dispositivo_A se asegure de que el usuario_A que ejecuta el proceso_A cuente con los permisos necesarios para poder acceder a los sockets protegidos que solicita proxificar y que, cuando corresponda, conceda y registre los accesos pertinentes y elabore e inserte las reglas de marcado oportunas. El procedimiento es idéntico al descrito en el ejemplo 2 en el diagrama de secuencias que comprende desde el (307) hasta el (319). También se requiere que el servidor proxy-firewall instancie un monitor de accesos que verifique que los accesos permanezcan abiertos mientras se esté ejecutando el proceso_A, actualizando periódicamente el estatus de cada registro_acceso para evitar que se cierren automáticamente por inactividad. Tras esto, el servidor proxy-firewall comunica al proceso_A los sockets protegidos resueltos de modo que, cualquier proceso del usuario_AAF del dispositivo_AF pueda acceder a los sockets protegidos del dispositivo_A a través de los socket-proxy reversos establecidos. Para ello, el servidor proxy-firewall se ha instanciado desde la cuenta de usuario_A, y por tanto puede lanzar el agente_A utilizando el perfil_UAAF que inicie el procedimiento de proxificación reversa de los sockets protegidos ya accesibles.
Ejemplo 9: Proxificación de sockets protegidos desde un dispositivo AF hacia un dispositivo A de forma reversa a instancias del agente AF del dispositivo AF:
Este ejemplo 9 está muy vinculado con el ejemplo anterior, el 8. En dicho ejemplo, un dispositivo_A a instancias de un proceso_A inicia el establecimiento de proxificaciones reversas hacia un dispositivo_AF. En el presente ejemplo, se muestra lo que ocurre en ese dispositivo_AF, en el que de nuevo, y en aras de conservar la coherencia descriptiva, ese dispositivo_AF será referido como dispositivo_A y viceversa.
Por consiguiente, el servidor proxy-firewall del dispositivo_A recibe una solicitud de establecimiento de sesión de un dispositivo_AF que utiliza un perfil_UAAF por la que se solicita la realización de una proxificación reversa de determinados sockets protegidos del dispositivo_AF hacia el dispositivo_A. Esta solicitud fuerza al servidor proxy-firewall a instanciarse como fork_AAF en la cuenta de usuario_AAF del dispositivo_A cuyas credenciales utilizó el agente_AF del dispositivo_AF para conectarse en el dispositivo_A. El fork_AAF requiere solicitar al connection-broker la reserva de sockets protegidos locales en el dispositivo_A para poder realizar la proxificación reversa.
Este procedimiento es similar al seguido en el ejemplo 1 por el dispositivo_A en el que el dispositivo_A debe reservar unos sockets locales para las proxificaciones reversas que solicita realizar el dispositivo_B. La principal diferencia, es que estos sockets locales protegidos resultado de la proxificación son nuevos y no existen permisos relativos en la base de datos que den acceso a ellos de algún modo. Por ello, el connection-broker, además de reservar esos sockets, debe insertar registros_socket y permisos_Au por cada socket-proxy reverso que habiliten al usuario_A AF del dispositivo_A de acceso a cada socket resultado de la proxificación de forma similar a como se realiza en el ejemplo 6 (607), (609), (61 1) y (612). Esta reserva, no obstante, se realiza únicamente para socket-proxies reversos.
Una vez reservados los sockets e insertados los permisos correspondientes, se deben generar las reglas de marcado pertinentes e insertarlas en el sistema para que el usuario_AAF tenga acceso a esos sockets protegidos. El servidor proxy-firewall instancia un monitor de accesos para garantizar que los registros_acceso relativos a cada proxificación mantengan una inactividad baja que impida su cierre automático mientras el proceso_A siga en ejecución. El servidor proxy-firewall, al estar instanciado desde la cuenta del usuario_AAF, forma parte del contexto de seguridad configurado al insertar las reglas de marcado y, por tanto, esta instancia dispone de acceso a los sockets protegidos reservados en este ejemplo para la proxificación reversa. Una vez terminadas estas acciones, el servidor proxy-firewall procede con la proxificación reversa solicitada por el agente_AF utilizando los sockets reservados para ello.
Ejemplo 10: Actualización remota de elementos software:
Una de las principales ventajas de la presente invención es el desacoplo de las funcionalidades de seguridad de las aplicaciones de los dispositivos_B y su correspondiente simplificación en su diseño y mantenimiento. En los dispositivos_A, los procesos que hacen uso del sistema propuesto por la invención, no requieren tampoco de frameworks de seguridad, pero sí deben incorporar en su programación el método descrito en este documento para poder comunicarse con los sockets protegidos. No obstante, la interfaz de comunicación se basa en llamadas al sistema y mareaje de paquetes, por lo que es independiente de los protocolos de seguridad y, por consiguiente, es factible actualizar en el dispositivo_A el sistema descrito en la presente invención también sin afectar a las aplicaciones del dispositivo_A.
En dispositivos_A y dispositivos_B similares a los propuestos en la realización preferente de la invención, es posible actualizar el agente del dispositivo_B desde el dispositivo_A sin afectar al resto del software. Para ello, es necesario que el dispositivo_B cuente con una versión simplificada del proxy-firewall que disponga del servidor proxy stand-alone y de una configuración adecuada en el perfil_BA que permita al dispositivo_A utilizar un socket-proxy reverso para actualizar el agente del dispositivo_B. Esta estrategia puede generalizarse para proporcionar servicios de actualización a otros elementos software ajenos al sistema descrito por la invención. En el caso particular de la actualización del cliente proxy stand-alone, el proceso comprende:
• Solicitar, a través de la sesión de comunicaciones establecida entre el agente_B y el servidor proxy-firewall el inicio de un procedimiento de la actualización del cliente proxy stand-alone del agente_B por iniciativa del servidor proxy-firewall.
• Recibir, por parte del agente_B, la nueva versión del cliente proxy y actualizar el perfil_BA.
• Probar, por parte del agente_B, la nueva versión del cliente proxy con el perfil_BA actualizado estableciendo una nueva sesión de comunicaciones.
• En caso de establecerse correctamente esta nueva sesión, eliminar la versión anterior del cliente proxy y reemplazarlo con la nueva versión.