Maksim Kabakou - stock.adobe.com

Confluent renforce la sécurité de sa plateforme Kafka

Confluent poursuit le déroulement du projet Metamorphosis visant à améliorer la gestion, parfois compliquée, d’Apache Kafka. L’éditeur renforce la sécurité de sa plateforme… en s’appuyant fortement sur les services des fournisseurs cloud.

Après avoir introduit une solution pour faciliter les déploiements multicloud du système de messagerie Kafka, l’éditeur ajoute des fonctionnalités de sécurité.

« Le véritable pouvoir du streaming d’événements réside dans la connexion de toutes les données pour créer un système nerveux central accessible en temps réel pour toute l’entreprise », déclare Jay Kreps, co-fondateur et PDG de Confluent dans un communiqué de presse. « Cependant, plus une plateforme peut accéder à des données, plus il faut les protéger pour les garder en sécurité ».

Apache Kafka serait utilisé par 80 % du Fortune 100 pour traiter des données financières, de fabrication ou encore de santé. Pour répondre à cet enjeu de cybersécurité, Confluent entend muscler les capacités de sa plateforme.

Cela commence par l’ajout en préversion d’un RBAC (Role-based access control) afin de gérer les rôles des utilisateurs de Kafka et de ses fonctionnalités : Schema Registry, Kafka Connect et son data store ksqlDB. Confluent rappelle qu’il propose déjà le support du protocole SASL PLAIN pour authentifier les appels API vers ses services, tandis que les clients peuvent utiliser son SSO compatible avec les identifiants basés sur le standard SAML.

Également en préversion, Confluent Cloud dispose d’une fonctionnalité de gestion des audits des logs afin de surveiller les activités potentiellement suspectes. Cela permet de suivre les modifications des clusters, des topics ou encore des listes de contrôle d’accès (ACL).

Ces deux fonctionnalités sont d’ores et déjà en disponibilité générale dans Confluent Platform.

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.

Pour approfondir sur Gestion d’identités (IGA, PAM, Bastion, PASM, PEDM)

Close