Cómo mover datos cifrados de extremo a extremo a través de Kafka

El complemento de Confluent para Ockam Orchestrator permite flujos de mensajes cifrados de extremo a extremo a prueba de manipulaciones a través de Confluent Cloud, sin cambios de código. La solución directa permite a las empresas superar los requisitos comunes de seguridad y cumplimiento sin necesidad de costosos trabajos de rediseño o desarrollo.

Las implementaciones de Kafka suelen combinar tokens de autenticación y seguridad de la capa de transporte (TLS) para proteger los datos que entran y salen de los temas de Kafka. Si bien esto protege los datos en tránsito a través de Internet, no proporciona una solución completa para proteger los datos mientras viajan a través de Kafka. El corredor de Kafka podrá ver temporalmente los datos de texto sin formato.

Cifrar la comunicación dentro y fuera de su agente de Kafka combinado con el cifrado de datos en reposo, dentro de Kafka, no será suficiente protección contra una violación de datos si el agente de Kafka o la infraestructura en la que se ejecuta están comprometidos, ya que los datos de texto sin formato y las claves para descifrar los datos están disponibles en la memoria. Ockam resuelve estos problemas, al mismo tiempo que brinda beneficios adicionales de mitigación de riesgos y garantías de integridad de datos, a través del complemento Confluent para Ockam Orchestrator.

Confíe en sus datos en movimiento

Su equipo ha decidido que integrar una plataforma de procesamiento de flujo en sus sistemas es la mejor manera de satisfacer las necesidades de escala y agilidad de su negocio, y Apache Kafka era la opción obvia para usar la plataforma. También decidió aprovechar el uso de una plataforma administrada experimentada en Confluent Cloud para que su equipo pueda concentrarse en agregar valor en lugar de ejecutar la infraestructura. El desarrollo está completo, el equipo tiene una solución funcional en la que los productores pueden enviar datos a Confluent Cloud y los consumidores pueden recibirlos del otro lado. La comunicación entre sus productores, consumidores y Confluent Cloud está encriptada y segura mediante Transport Layer Security (TLS), por lo que está a punto de pasar a la producción.

Una revisión de seguridad y cumplimiento ha surgido un problema. Si bien confía en Confluent Cloud, el mayor enfoque en reducir el riesgo de la cadena de suministro significa que tener datos que se mueven a través de sus sistemas sin cifrar ya no cumple con sus requisitos de seguridad. ¿Cómo mitiga el riesgo para su negocio en caso de que algún otro proveedor en su cadena de suministro tenga una brecha de seguridad? Debe poder asegurarse de que:

1. No hay posibilidad de que un tercero lea los datos mientras están en tránsito
2. Un tercero no puede modificar los datos mientras están en tránsito
3. Solo las partes autenticadas y autorizadas pueden producir datos

Sin soluciones para ambos, existe el riesgo de que una brecha de seguridad en su propia cadena de suministro no solo exponga sus datos confidenciales, sino que también provoque escalamientos inesperados posteriores.

Integrar sin cambios de código

Permítame mostrarle un ejemplo de trabajo completo de cómo, en solo unos minutos, puede configurar e integrar una solución completa de extremo a extremo que garantiza que sus datos estén siempre encriptados y a prueba de manipulaciones mientras están en movimiento a través de Kafka y Confluent. .

Nota: Los ejemplos de código a continuación pueden cambiar a medida que continuamos mejorando la experiencia del desarrollador. Consulte https://docs.ockam.io/ para obtener la documentación más actualizada.

Configuración inicial de Ockam

Si ya configuró Ockam, puede omitir esta sección y pasar directamente a los dos ejemplos a continuación.

 brew install build-trust/ockam/ockam

(si no está utilizando brew para la gestión de paquetes, tenemos instrucciones de instalación para otros sistemas en nuestra documentación)

Una vez instalado, debe registrar su identidad local con Ockam Orchestrator, ejecute el siguiente comando y siga las instrucciones proporcionadas:

 ockam enroll

Configurar el complemento Confluent

Suponemos aquí que ya tiene un clúster en funcionamiento en Confluent Cloud (y las herramientas de línea de comandos de Kafka que vienen con el última distribución de Kafka ), por lo que el primer paso es configurar su proyecto Ockam para usar el complemento Confluent apuntándolo a la dirección de su servidor de arranque:

 ockam project addon configure confluent \ --bootstrap-server YOUR_CONFLUENT_CLOUD_BOOTSTRAP_SERVER_ADDRESS

Luego necesitaremos guardar la configuración de nuestro proyecto Ockam para que podamos usarla más tarde para registrar a nuestros productores y consumidores, así que guarde la salida en un nombre de archivo project.json :

 ockam project information default --output json > project.json

Como administrador del proyecto Ockam, puede controlar qué otras identidades pueden inscribirse en su proyecto mediante la emisión de tokens de inscripción únicos de un solo uso. Comenzaremos creando uno para nuestro consumidor:​

 ockam project enroll --project-path project.json --attribute role=member > consumer.token

... y luego uno para el primer productor:

 ockam project enroll --project-path project.json --attribute role=member > producer1.token

El último archivo de configuración que necesitamos generar es kafka.config , que será donde almacenará el nombre de usuario y la contraseña que usa para acceder a su clúster en Confluent Cloud:

 cat > kafka.config <<EOF request.timeout.ms=30000 security.protocol=SASL_PLAINTEXT sasl.mechanism=PLAIN sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="YOUR_CONFLUENT_CLOUD_USER_NAME" \ password="YOUR_CONFLUENT_CLOUD_PASSWORD"; EOF

Configurar consumidores para recibir mensajes cifrados

En su nodo de consumidor, comenzará creando una nueva identidad (necesitará tener instalado el comando Ockam, así que repita las instrucciones de instalación si está haciendo esto en un host separado):

 ockam identity create consumer

Copie los archivos project.json y consumer.token de la sección anterior y luego utilícelos para autenticar e inscribir esta identidad en su proyecto Ockam:

 ockam project authenticate \ --project-path project.json \ --identity consumer \ --token $(cat consumer.token)

Un nodo Ockam es una forma de conectar de forma segura diferentes servicios entre sí, por lo que crearemos uno aquí que usaremos para comunicarnos a través del clúster de Confluent Cloud usando la identidad que acabamos de crear:

 ockam node create consumer \ --project project.json --identity consumer

Una vez que se complete, ahora podemos exponer nuestro servidor de arranque Kafka. Esto es como el servidor de arranque Kafka remoto y los intermediarios se han vuelto prácticamente adyacentes en localhost:4000 :

 ockam service start kafka-consumer \ --node consumer \ --project-route /project/default \ --bootstrap-server-ip 127.0.0.1 \ --bootstrap-server-port 4000 \ --brokers-port-range 4001-4100

Copie el archivo kafka.config y utilícelo para crear un nuevo tema que usaremos para enviar mensajes entre el productor y el consumidor en esta demostración (en este caso, llamamos al tema demo-topic )

 kafka-topics.sh \ --bootstrap-server localhost:4000 \ --command-config kafka.config \ --create \ --topic demo-topic \ --partitions 3

El paso final es iniciar nuestro script de consumidor, apuntándolo a localhost:4000 como nuestro servidor de arranque:

 kafka-console-consumer.sh \ --topic demo-topic \ --bootstrap-server localhost:4000 \ --consumer.config kafka.config

El código del consumidor enviará toda la comunicación al proceso del nodo Ockam que se ejecuta en el host local. Ese proceso local de Ockam administrará automáticamente la generación de claves criptográficas, estableciendo un canal seguro para la comunicación con cualquier nodo productor y luego recibiendo, descifrando y reenviando cualquier mensaje que se reciba del corredor que se ejecuta en nuestro clúster de Confluent Cloud.

Envíe mensajes encriptados de múltiples productores

Para tener mensajes para que nuestro consumidor los procese, necesitamos tener algo que los produzca. Pasaremos por un proceso muy similar ahora, pero en su lugar crearemos las partes necesarias para un productor. Comenzamos una vez más creando una identidad en el host del productor (nuevamente, instale Ockam Command en ese host si es necesario):

 ockam identity create producer1

Copie los archivos project.json y producer1.token de la sección anterior y utilícelos para autenticarse e inscribirse en nuestro proyecto Ockam:

 ockam project authenticate \ --project-path project.json \ --identity producer1 \ --token $(cat producer1.token)

Cree un nodo y vincúlelo tanto al proyecto como a la identidad que hemos creado:

 ockam node create producer1 \ --project project.json \ --identity producer1

Y exponga nuestro servidor de arranque Kafka en el puerto 5000 para que podamos comenzar a enviar mensajes a través de Confluent Cloud:

 ockam service start kafka-producer \ --node producer1 \ --project-route /project/default \ --bootstrap-server-ip 127.0.0.1 \ --bootstrap-server-port 5000 \ --brokers-port-range 5001-5100

Asegúrese de copiar el archivo kafka.config e inicie su productor:

 kafka-console-producer.sh \ --topic demo-topic \ --bootstrap-server localhost:5000 \ --producer.config kafka.config

Su código de productor existente ahora se estará ejecutando, comunicándose con el corredor a través del portal seguro que hemos creado que ha expuesto el servidor de arranque de Kafka y los corredores de Kafka en los puertos locales, y enviando mensajes al consumidor que se configuró en el paso anterior. Sin embargo, todas las cargas de mensajes se cifrarán de forma transparente cuando entren en el nodo del productor y no se descifrarán hasta que salgan del nodo del consumidor. En ningún momento del tránsito, el corredor puede ver la carga útil del mensaje de texto sin formato que envió inicialmente el productor.

Para continuar con este ejemplo, podría repetir este paso para N cantidad de productores generando un nuevo token de inscripción para cada uno y luego repitiendo los pasos en esta sección.

Si observa los mensajes cifrados dentro de Confluent Cloud, se representarán como caracteres irreconocibles como en la siguiente captura de pantalla:

Flujos de mensajes cifrados de extremo a extremo

Un ejemplo que solo toma unos minutos para implementar significa que puede ser fácil pasar por alto varias de las importantes mejoras en la seguridad y la integridad que se derivan de este enfoque:

• Claves únicas por identidad : cada consumidor y productor genera sus propias claves criptográficas y recibe sus propias credenciales únicas. Luego los usan para establecer un canal seguro de confianza mutua entre ellos. Al eliminar la dependencia de un servicio de terceros para almacenar o distribuir claves, puede reducir su área de superficie de vulnerabilidad y eliminar los puntos únicos de falla.

  
  

• Transferencia de datos a prueba de manipulaciones : al llevar el control de las claves a los bordes del sistema, donde se produce el cifrado y descifrado autenticado, ninguna otra parte de la cadena de suministro puede modificar los datos en tránsito. Puede estar seguro de que los datos que recibe del consumidor son exactamente los que le enviaron sus productores. También puede estar seguro de que solo los productores autorizados pueden escribir en un tema, lo que garantiza que los datos de su tema sean altamente confiables. Si tiene requisitos aún más estrictos, puede tomar el control de su autoridad de credenciales y aplicar políticas de autorización detalladas.

  
  

• Ventana de exposición reducida : los canales seguros de Ockam rotan regularmente las claves de autenticación y los secretos de sesión. Este enfoque significa que si uno de esos secretos de sesión estuvo expuesto, su ventana de exposición total de datos se limita a la pequeña duración que estuvo en uso ese secreto. La rotación de las claves de autenticación significa que incluso cuando las claves de identidad de un productor se ven comprometidas, no se compromete ningún dato histórico. Puede eliminar de forma selectiva el productor comprometido y sus datos. Con los enfoques centralizados de distribución de claves compartidas, existe el riesgo de que no se pueda confiar en todos los datos actuales e históricos después de una violación porque pueden haber sido manipulados o robados. El enfoque de Ockam elimina el riesgo de datos históricos comprometidos y minimiza el riesgo de datos futuros utilizando claves rotativas automáticas.

  
  

Todos estos beneficios son posibles hoy en día, sin cambios de código y cambios mínimos de configuración en las implementaciones existentes.

Próximos pasos

• Si aún no ha seguido el ejemplo de esta guía, puede empezar a usar Ockam de forma gratuita siguiendo las instrucciones de nuestra documentación.
• Si desea hablar específicamente sobre este u otros posibles casos de uso de Ockam, el equipo estará más que feliz de chatear contigo .
• Alternativamente, puede unirse a nosotros y a una comunidad cada vez mayor de desarrolladores que desean generar confianza creando aplicaciones que son seguras por diseño, en el Construir un servidor Trust Discord o en Github .