Confluent renforce la sécurité de sa plateforme Kafka

Des options supplémentaires pour gérer les connexions aux VPC

Ce nouveau volet du projet Metamorphosis apporte aussi une nouvelle manière de gérer les connexions VPC (Virtual Private Cloud). Outre les possibles problèmes de sécurité, l’éditeur veut faciliter la gestion des connexions et des différents VPC à traverser, quand il s’agit d’envoyer des données de sources multiples vers Confluent Cloud. Pour cela, Confluent propose habituellement une capacité d’appairage (VPC/Vnet) avec les différents VPC des fournisseurs cloud et Amazon Transit Gateway, qui doit permettre de connecter des comptes AWS et des réseaux sur site dans une passerelle unique.

L’éditeur ajoute une compatibilité avec AWS Privatelink, un service dont le but est de fournir une connexion privée entre les services cloud AWS et ceux hébergés sur site. Confluent prendra prochainement en charge Azure Private Link et Private Service Connect, les équivalents de cette solution chez Microsoft Azure et GCP.

En outre, Confluent Cloud est désormais compatible avec AWS KMS, le service de gestion de clés de chiffrement du fournisseur cloud. L’éditeur considère ainsi qu’il offre un service BYOK (Bring your own Key) pour ses utilisateurs. Seulement, cela induit une dépendance au cloud d’AWS, et les gestionnaires de clés de chiffrement des autres fournisseurs de cloud ne sont pour l’instant accessibles que par le biais d’une offre de support.

Dans le cadre de ses services professionnels payants, l’éditeur propose ainsi un framework de chiffrement et de tokenisation afin d’obtenir un chiffrement bout en bout côté client applicatif. « Le framework comprend des composants tels qu’un sérialiseur/désérialiseur personnalisé, le support de ksqlDB, l’intégration aux gestionnaires de clés sur site ainsi qu’aux services KMS d’AWS, GCP et Azure », peut-on lire dans un livre blanc de l’éditeur.

Une dépendance forte aux services tiers

À noter que les données dans Confluent Cloud sont déjà chiffrées au repos à l’aide du standard de chiffrement AES 256, selon l’éditeur. En transit, il utilise TLS 1.2 pour Apache Kafka et la couche SSL pour le trafic HTTP.

Cependant, beaucoup de ces mécanismes dépendent de fournisseurs tiers. La communauté open source derrière Kafka, elle, perçoit un manque de standardisation pour stocker les clés SSL et les clés privées. S’il est déjà possible de stocker ces éléments chiffrés dans un espace de stockage tiers, la KIP 651 (Kafka Improvement Proposals) propose de gérer la configuration dynamique de mots de passe de manière chiffrée depuis Zookeeper ou dans un coffre externe via le format PEM (Privacy-Enhanced Mail).

Ce format auparavant utilisé pour sécuriser des mails sert désormais d’enveloppe chiffrée pour les clés SSL dans le standard OpenSSL. Cette technique s’ajoute à la combinaison JKS/PKCS12 déjà présente dans Apache Kafka. La proposition KIP 651 a été acceptée et sera introduite dans la version 2.7.0 de la plateforme de streaming de données, dont la disponibilité est prévue pour le début du mois de novembre 2020.

Le reste de la feuille de route de Kafka 2.7.0 est davantage tournée vers des optimisations des performances, notamment l’amélioration du comportement des topics après un arrêt anormal d’une tâche (timeout).

Dans un même temps, Instaclustr, concurrent de Confluent, vient d’annoncer la disponibilité générale de Managed Mirroring via Kafka Connect, un équivalent de Cluster Linking reposant sur le protocole open source Apache Kafka Broker. Il met également à disposition de ses clients l’accès à des nœuds dédiés pour Apache Zookeeper, composant dont le mainteneur principal du projet, Confluent, veut se débarrasser dans la version 3.0 du broker de messages en temps réel.