Parte 3: Integración perimetral
En las partes 1 y 2 presentamos un enfoque de seguridad federada para autenticar usuarios en varios inquilinos usando OAUTH2 y OIDC. En la parte 3, discutiremos como conectar sistemas de sensores locales a los servicios de datos de la nube.
C-Insight es un sistema multisensor y nuestros clientes utilizan sensores locales para la gestión segura e inteligente de la infraestructura de la ciudad. Los sensores envían datos operativos y estados de salud. Los datos operativos son almacenados en bases de datos con capacidad de búsquedas, usadas para construir tableros de BI y generar varias reglas de análisis de datos. Los estados de salud son usados para presentar tableros y reportes del estado de salud de los sensores en tiempo real. En los escenarios de implementación locales, ninguno de estos datos deja los límites de los centros de datos, sin embargo, en un modelo de implementación híbrida, los datos operativos y los estados de salud se envían a los servicios backend en la nube para ser procesados. Esto significa que solo los servicios de una capa de integración ligera son implementados localmente y los datos que generan viajan a través de WAN hacia el entorno de la nube. Esto presenta un par de retos:
- Retos de seguridad, ya que estos servicios deben ser contactados desde los centros de datos en la nube y abrir puertos en un firewall en el centro de datos para la comunicación entrante es una brecha de seguridad.
- Retos de implementación, ya que el equipo de operaciones tiene que configurar manualmente las direcciones IP y puertos para cada ubicación local para que se pueda acceder a ellos desde el segmento de IP en la nube.
- Retos de comunicación, ya que los datos son enviados a través de WAN y necesita protocolos capaces de atravesar firewalls.
Nosotros dirigimos estos retos usando el protocolo de túnel basado en TCP. Desde Wikipedia en inglés:
“En redes informáticas, un protocolo de túnel es un protocolo de comunicación que permite el movimiento de datos desde una red a otra, explotando la encapsulación. Involucra permitir que la comunicación de redes privadas sea enviada a través de una red pública (como el Internet) a través de un proceso llamado encapsulación.”
Cada implementación local usa un servicio de Host de Integración Perimetral (EIH, por sus siglas en inglés) que es capaz de alojar cualquier tipo de integración de sensores (como LPR, luces inteligentes, control de tráfico, etc.). Una vez que empieza, el servicio abre una conexión segura bidireccional con una dirección predefinida en el centro de datos en la nube donde otro servicio llamado Puerta de enlace de Integración Perimetral (EIG, por sus siglas en inglés) está escuchando tales conexiones. Una vez que el canal seguro se establece, sus metadatos persisten y cualquier servicio que se ejecute en el centro de datos en la nube puede enviar consultas y comandos al EIH local a través de este canal seguro usando cualquier protocolo de mensajería de elección y, como el canal es bidireccional, EIH puede enviar eventos relacionados con sensores a la nube. Se necesita una sola conexión desde cada centro de datos local para toda la operación del sistema y solo se debe abrir un puerto de salida en el firewall local.
Una vez que se establece una conexión, los mensajes JSON fluyen en ambas direcciones: ya sea sus eventos generados por sensores o consultas o comandos enviados por servicios backend implementados en la nube. Cada mensaje JSON se firma digitalmente y se cifra mediante un certificado de cliente y toda la comunicación TCP se cifra mediante un certificado de servidor.
A diferencia de las aplicaciones cliente que usan tokens de corta duración para llamar a las API, en el escenario Puerta de enlace de Integración Perimetral – Host utilizamos cookies de sesión para la autenticación. Cada sesión se inicia mediante una solicitud de conexión que presenta un certificado del cliente y metadatos de implementación local. Una vez autenticada, se crea una sesión y permanece activa mientras la conexión esté abierta y los mensajes fluyan en cualquier dirección. Si no se envían mensajes en un tiempo de espera predeterminado, la conexión finaliza. Este mecanismo de autenticación es más adecuado para la comunicación de servidor a servidor, ya que no se produce ninguna autorización.
Desde la perspectiva de la implementación en la nube, la EIG se implementó de la misma manera que la puerta de enlace de la API (descrita en la parte 2). Todas las solicitudes de conexión llegan a L4 NLB, que reenvía el tráfico a una de las instancias en buen estado de EIG. Ninguno de los servicios basados en la nube necesita conocer la dirección EIH para enviarle mensajes, ya que el canal se identifica mediante los metadatos de implementación del cliente.
Este estilo de comunicación versátil y seguro permite conectar varias ubicaciones locales sin problemas para formar un clúster híbrido masivo de múltiples inquilinos que atiende a un número ilimitado de clientes locales.
Eso es todo para esta serie de artículos. Nos encantaría escuchar sus pensamientos sobre lo que le gustaría escuchar de nosotros a continuación.
