¿Cómo garantiza la seguridad de los datos Apache Kafka?

En la era actual de la información, donde los datos son el activo más valioso de una organización, la seguridad se ha convertido en una preocupación capital en todos los ámbitos. Desde el intercambio de información personal hasta los datos más confidenciales, mantener la integridad y la confidencialidad de estos datos resulta esencial.

Dado este contexto, en Apache Kafka, como para cualquier otra tecnología que trabaje con datos, la seguridad es una consideración fundamental que no puede ser pasada por alto.

En esta serie de artículos explicaremos en detalle los pilares fundamentales de la seguridad en Apache Kafka y cómo se pueden implementar para crear un entorno seguro y confiable para la integración y el procesamiento de datos en tiempo real.

¿Por qué la seguridad en Apache Kafka es esencial?

Antes de sumergirnos en las complejidades técnicas, es importante comprender los riesgos y desafíos asociados con la falta de seguridad en Apache Kafka.

Si en nuestro clúster no se ha implementado ninguna política de seguridad, cualquier cliente externo puede acceder al clúster para poder publicar datos incorrectos o robar datos claves de negocio, por lo que se tiene la necesidad de tener una política de autenticación.

Por otro lado, aunque un cliente cumpla con la política de autenticación, podría publicar o consumir datos a partir de cualquier topic, independientemente si está destinado para ello o no, por lo que también existe la necesidad de tener una política de autorización.

Finalmente, aunque se dispongan de las políticas de autenticación y autorización, toda la información que se envía y recibe del clúster no está cifrada y permanece visible en los servidores que enrutan dicha información a través de Internet, permitiendo que alguien pueda interceptarla y hacer un uso malintencionado de los datos. Por ello, tenemos la necesidad de completar las políticas de seguridad con una política de encriptación.

Como vemos, son conceptos muy sencillos y familiares a toda la comunidad tecnológica pero con una gran importancia. Desde la interceptación no deseada de datos hasta la manipulación maliciosa de flujos de información, los peligros potenciales pueden ser devastadores para cualquier organización y se ha podido ver en casos de uso del mundo real donde una seguridad insuficiente tuvo como consecuencia las violaciones de datos y la pérdida de confianza.

Para no tener este problema, Apache Kafka dispone de una serie de mecanismos que permiten implementar este tipo de políticas que garanticen la confidencialidad, integridad y autenticidad de los datos que fluyen a través de esta plataforma para salvaguardar sus flujos de datos críticos.

En este artículo, vamos a centrarnos en cómo implementar la política de encriptación que nos ayude a construir un sistema de confianza en Apache Kafka.

¿Cómo implementar una política de encriptación en Apache Kafka?

Ya hemos visto la necesidad de implementar una política de encriptación para garantizar el intercambio de información seguro entre los clientes y el clúster de Apache Kafka, pero ¿cómo podemos hacerlo?

Pues bien, para poder implementar nuestra política de encriptación vamos a usar un protocolo de seguridad muy conocido a la hora de establecer conexiones seguras y cifradas en redes de computadoras, TLS (Transport Layer Security). En el contexto de Apache Kafka, la encriptación TLS se utiliza para garantizar que los datos transmitidos entre los clientes y brokers de Apache Kafka estén protegidos contra interceptaciones y manipulaciones de datos no autorizados, lo que ayuda a salvaguardar la integridad y la privacidad de los datos.

Antes de ver cómo habilitar la encriptación para Apache Kafka, vamos a introducir brevemente el funcionamiento del protocolo TLS para que ayude a entender posteriormente la implementación de esta política.

Funcionamiento de TLS

El uso de este protocolo implica una serie de pasos, que van desde garantizar la autenticidad de las partes involucradas hasta el intercambio de claves criptográficas durante la comunicación.

En primer lugar, tenemos que generar un par de claves (pública y privada) y un certificado asociado a la entidad servidor, el cual se tiene que enviar a una Autoridad de Certificación (CA) que valida la identidad del servidor y que la información del certificado sea la correcta. Una vez hecho, envía de vuelta un certificado que incluye, entre otra información, la firma digital de CA y la clave pública para su instalación en el servidor junto a su clave privada.

Para configurar la entidad cliente y poder realizar una conexión segura usando TLS, podríamos seguir los pasos de la entidad servidor, pero esto suele darse en situaciones específicas donde se requiere de una autenticación bidireccional. En la mayoría de los casos, no se requiere que el cliente genere su propio certificado, sino que puede utilizar un almacén de confianza (Trust Store) que contenga los certificados de la CA confiable y así verificar la autenticidad de los certificados presentados por los servidores a los que se conecta.

De esta manera, ambas entidades ya están preparadas para iniciar el proceso de negociación TLS para establecer una comunicación segura entre ellas. En modo resumido, una vez iniciada la conexión, el cliente verifica el certificado presentado por el servidor usando su Trust Store y, si es válido, genera claves de sesión y las envía cifradas al servidor para que este las descifre y establecer la conexión segura donde los datos intercambiados ya estarán encriptados.

Es importante tener en cuenta que el proceso mostrado es una simplificación del flujo real de TLS, ya que puede incluir más pasos y detalles técnicos, como pueden ser el envío de parámetros de cifrado, la creación de claves de intercambio de claves de sesión o el cifrado de dichas claves.

Una vez entendido el funcionamiento del protocolo TLS, podemos intuir que también nos puede ayudar a implementar nuestra política de autenticación (lo veremos más adelante en próximos artículos), aunque en este artículo vamos a centrarnos exclusivamente en cómo habilitar la política de encriptación en Apache Kafka.

Configuración de la CA

Para habilitar la política de encriptación necesitamos de un CA que, como hemos visto anteriormente, es la entidad que nos va a permitir firmar los certificados del broker de Apache Kafka para que los clientes que se conecten a él puedan verificar su identidad y establecer conexiones seguras.

En un escenario real, las empresas cuentan con un CA de confianza para la firma de los certificados, pero para entender mejor el flujo de configuración, vamos a crear nuestra propia CA que nos permita firmar los certificados. Para ello, vamos a hacer uso del comando openssl.

openssl req -new -newkey rsa:4096 -days 365 -x509 -subj “/CN=Kafka-Security-CA” -keyout ca-key -out ca-cert -nodes

Este comando se utiliza para generar una CA que emite un certificado autofirmado, el cual se usará para firmar y emitir certificados para otros componentes, como los brokers y/o los clientes. El certificado autofirmado y la clave privada de la CA se guardan en los archivos ca-cert y ca-key que usaremos más adelante.

Lo más reseñable es la marca de clave privada en el fichero ca-key, alertando de que esta clave contiene información muy confidencial que nunca habría que ponerla a disposición del público. Esto contrasta con el fichero ca-cert, donde no encontramos ninguna marca sobre una clave privada, lo que significa que el certificado público se puede distribuir a quien necesite confiar en la CA.

Una vez hecho esto, ya tendríamos disponible nuestra CA para emitir certificados digitales para establecer una comunicación segura entre entidades, como los brokers y los clientes de Apache Kafka.

Configuración del servidor

Ahora, es el momento de poner foco a la parte del broker. Para generar el par de claves y el certificado necesario haremos uso de keytool, un comando que permite gestionar claves y certificados en Java.

keytool -genkey -keystore kafka.broker.keystore.jks -validity 365 -storepass <password> -keypass <password> -dname “CN=kafka-broker” -storetype pkcs12 -keyalg RSA

Este comando genera un nuevo par de claves RSA y un certificado asociado que se almacenan en un almacén de claves (KeyStore) con el nombre kafka.broker.keystore.jks. Para ver el contenido de nuestro almacén de claves también nos apoyaremos de la herramienta keytool (keytool -list -v -keystore kafka.broker.keystore.jks).

Como datos relevantes, el almacén de claves se crea en formato PKCS12, lo que permite tener tanto claves privadas como certificados en un solo archivo. Además, el almacén de claves tiene una única entrada, correspondiente a la acción que acabamos de realizar, y también se define un aspecto muy importante, como es el Common Name, que representa el nombre distintivo de la entidad a la que se le emite el certificado.

Una vez generados el par de claves y el certificado, el siguiente paso es el de firmar dicho certificado a través de nuestra CA. Para ello, volvemos a hacer uso de la herramienta keytool para generar una solicitud de firma de certificado (Certificate Signing Request, CSR).

keytool -keystore kafka.broker.keystore.jks -certreq -file cert-file -storepass <password> -keypass <password>

El comando genera un archivo de CSR, cert-file, con la información necesaria para solicitar la emisión de un certificado digital de confianza.

La parte más relevante del contenido del fichero es la marca de petición de emisión de un nuevo certificado, cuyo contenido se define a partir de las claves y el certificado almacenados en el almacén de claves kafka.broker.keystore.jks.

Una vez creada la CSR, hay que enviarla a nuestra CA confiable para que la firme y proporcione el certificado digital que sea reconocido y aceptado por los clientes y sistemas que confíen en dicha CA. De nuevo, vamos a hacer uso del comando openssl.

openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-file -out cert-signed -days 365 -CAcreateserial -passin pass:<password>

Este comando emite un nuevo certificado digital usando la CSR, el certificado y la clave privada de la CA. El certificado resultante, que es el certificado firmado, se guarda en el archivo cert-signed.

Como aspecto importante, podemos ver que el certificado generado ya no tiene como emisor al propio broker, sino a nuestra CA que ha validado a la entidad.

Ahora quedaría importar los certificados, tanto el propio de la CA como el emitido por esta, a nuestro almacén de claves para su posterior uso.

keytool -keystore kafka.broker.keystore.jks -alias CARoot -import -file ca-cert -storepass <password> -keypass <password> -noprompt
keytool -keystore kafka.broker.keystore.jks -import -file cert-signed -storepass <password> -keypass <password> -noprompt

Como dato a tener en cuenta, en nuestro almacén de claves kafka.broker.keystore.jks quedarían dos entradas correspondientes a los certificados importados, ya que la anterior entrada referente al broker se sustituye por el certificado firmado al poseer la misma clave.

Además, vamos a crear también un almacén de confianza (Trust Store) para el broker. Esto es necesario porque varios componentes del propio broker necesitan comunicarse entre sí, por lo que también debe de confiar en el certificado CA.

keytool -keystore kafka.broker.truststore.jks -alias CARoot -import -file ca-cert -storepass <password> -keypass <password> -noprompt

Este comando crea el almacén de confianza con el nombre kafka.broker.truststore.jks. y además ya le importa el certificado de nuestra CA de confianza.

De esta manera, la gestión de certificados para nuestro broker estaría terminada. Para finalizar con la configuración del broker, solo queda añadir la configuración necesaria en el fichero de configuración server.properties.

listeners=PLAINTEXT://0.0.0.0:9092,SSL://0.0.0.0:9093
advertised.listeners=PLAINTEXT://kafka-broker:9092,SSL://kafka-broker:9093
…
ssl.keystore.location=<path>/kafka.broker.keystore.jks
ssl.keystore.password=<password>
ssl.key.password=<password>
ssl.truststore.location=<path>/kafka.broker.truststore.jks
ssl.truststore.password=<password>

Simplemente, habría que reiniciar Apache Kafka del sistema y ya estaría el servidor preparado para poder realizar conexiones cifradas bajo TLS.

En este punto, ya tenemos disponible nuestro broker para crear comunicaciones seguras con los distintos clientes.

Configuración del cliente

Para finalizar vamos a ver cómo configurar el cliente. Como hemos visto cuando hemos comentado el funcionamiento de TLS, el cliente necesita un almacén de confianza que le permita aceptar y verificar el certificado TLS del broker con el que se quiere comunicar.

keytool -keystore kafka.client.truststore.jks -alias CARoot -import -file ca-cert -storepass <password> -keypass <password> -noprompt

Este comando crea el almacén de confianza con el nombre kafka.client.truststore.jks. e importa el certificado de nuestra CA de confianza.

Una vez hecho esto, creamos un fichero de propiedades, client.properties, que debemos proporcionar como parámetro adicional a los clientes.

security.protocol=SSL
ssl.truststore.location=<path>/kafka.client.truststore.jks
ssl.truststore.password=<password>

La manera de proporcionar este fichero como parámetro en la ejecución del cliente puede depender del tipo de cliente que implementemos o usemos, pero el contenido que hay que proporcionar es similar.

A modo de ejemplo, si lanzamos un cliente de Apache Kafka por consola, la manera de proporcionar el fichero de propiedades del cliente sería en su propia ejecución.

~/kafka/bin/kafka-console-producer.sh –broker-list kafka-broker:9093 –topic kafka-security-topic –producer.config <path>/client.properties

De esta forma, ya tendríamos preparado al cliente para poder realizar comunicaciones encriptadas y seguras con TLS.

¿Y ahora qué?

A partir de aquí, ya tendríamos realizada toda la configuración necesaria para que la comunicación entre cliente y servidor de Apache Kafka esté encriptada bajo el protocolo TLS y así poder garantizar la seguridad de la información.

Para probar esta implementación de un protocolo de encriptación para Apache Kafka os aconsejamos realizar una prueba end-to-end a través de las propias utilidades de consola que ofrece la tecnología para poder completar lo que hemos visto en el artículo y ver en más detalle algunos puntos de interés.

¿Qué conclusiones sacamos en claro? Próximos pasos

La implementación de políticas de encriptación en Apache Kafka mediante el uso de TLS (Transport Layer Security) es esencial para garantizar la seguridad y confidencialidad de las comunicaciones en un entorno de procesamiento y transmisión de datos. Mediante la aplicación de certificados digitales y el establecimiento de canales de comunicación seguros, se logra proteger la integridad de los datos transmitidos, prevenir la interceptación no autorizada y mitigar riesgos como el acceso no autorizado a los datos sensibles.

La utilización de TLS en Apache Kafka proporciona una capa adicional de seguridad, permitiendo la autenticación de los componentes de la infraestructura y asegurando que solo los participantes legítimos puedan acceder y participar en el flujo de datos. Además, el cifrado de extremo a extremo garantiza que, incluso en el caso de una posible intrusión en la red, los datos interceptados permanezcan inaccesibles para terceros no autorizados.

Al incorporar políticas de encriptación en Apache Kafka mediante TLS, las organizaciones no solo cumplen con los estándares de seguridad recomendados, sino que también fortalecen su postura en cuanto a privacidad y confidencialidad de datos. Sin embargo, es importante resaltar que la configuración y gestión adecuada de los certificados, así como la supervisión continua de la infraestructura, son aspectos críticos para mantener la eficacia y robustez de esta estrategia de seguridad en evolución constante en el entorno tecnológico actual.

Si bien en este artículo hemos visto la manera de implementar una política de encriptación, en próximos artículos vamos a implementar otras políticas que garanticen la seguridad de nuestro sistema con Apache Kafka. ¡No os lo perdáis!