Comment déplacer des données chiffrées de bout en bout via Kafka

Le module complémentaire Confluent pour Ockam Orchestrator permet des flux de messages inviolables et chiffrés de bout en bout via Confluent Cloud, sans aucun changement de code. La solution instantanée permet aux entreprises de dépasser les exigences courantes en matière de sécurité et de conformité sans nécessiter de coûteux travaux de réarchitecture ou de développement.

Les déploiements Kafka combinent généralement des jetons d'authentification et Transport Layer Security (TLS) pour protéger les données entrant et sortant des rubriques Kafka. Bien que cela sécurise les données en transit sur Internet, cela ne fournit pas une solution complète pour sécuriser les données lorsqu'elles transitent par Kafka. Le courtier Kafka pourra voir temporairement les données en clair.

Le chiffrement des communications entrantes et sortantes de votre courtier Kafka combiné au chiffrement des données au repos, à l'intérieur de Kafka, ne constituera pas une protection suffisante contre une violation de données si le courtier Kafka ou l'infrastructure sur laquelle il s'exécute est compromis, car les données en clair et les clés pour déchiffrer les données sont disponibles en mémoire. Ockam résout ces problèmes, tout en offrant des avantages supplémentaires d'atténuation des risques et des garanties d'intégrité des données, via le module complémentaire Confluent pour Ockam Orchestrator.

Faites confiance à vos données en mouvement

Votre équipe a décidé que l'intégration d'une plate-forme de traitement de flux dans vos systèmes était le meilleur moyen de répondre à la fois aux besoins d'échelle et d'agilité de votre entreprise, et Apache Kafka était le choix évident pour la plate-forme à utiliser. Vous avez également décidé de tirer parti de l'utilisation d'une plate-forme gérée expérimentée dans Confluent Cloud afin que votre équipe puisse se concentrer sur l'ajout de valeur plutôt que sur la gestion de l'infrastructure. Le développement est terminé, l'équipe dispose d'une solution de travail où les producteurs peuvent envoyer des données à Confluent Cloud, et les consommateurs peuvent les recevoir de l'autre côté. La communication entre vos producteurs, vos consommateurs et Confluent Cloud est cryptée et sécurisée à l'aide de Transport Layer Security (TLS). Vous êtes donc sur le point de passer à l'utilisation en production.

Un examen de la sécurité et de la conformité a révélé un problème. Bien que vous fassiez confiance à Confluent Cloud, l'accent accru mis sur la réduction des risques de la chaîne d'approvisionnement signifie que le fait que les données circulent dans leurs systèmes sans chiffrement ne répond plus à vos exigences de sécurité. Comment atténuez-vous le risque pour votre entreprise si un autre fournisseur de votre chaîne d'approvisionnement avait une faille de sécurité ? Vous devez être en mesure de vous assurer que :

1. Il n'y a aucune possibilité pour un tiers de lire les données pendant qu'elles sont en transit
2. Un tiers ne peut pas modifier les données pendant qu'elles sont en transit
3. Seules les parties authentifiées et autorisées peuvent produire des données

Sans solutions à ces deux problèmes, il existe un risque qu'une faille de sécurité dans votre propre chaîne d'approvisionnement puisse non seulement exposer vos données sensibles, mais aussi provoquer des escalades inattendues en aval.

Intégration sans changement de code

Laissez-moi vous montrer comment, en quelques minutes seulement, vous pouvez configurer et intégrer une solution complète de bout en bout qui garantit que vos données sont toujours chiffrées et inviolables lorsqu'elles sont en mouvement via Kafka et Confluent .

Remarque : Les exemples de code ci-dessous peuvent changer à mesure que nous continuons à améliorer l'expérience des développeurs. Veuillez consulter https://docs.ockam.io/ pour la documentation la plus à jour.

Configuration initiale d'Ockam

Si vous avez déjà configuré Ockam, vous pouvez ignorer cette section et passer directement aux deux exemples ci-dessous.

 brew install build-trust/ockam/ockam

(si vous n'utilisez pas brew pour la gestion des packages, nous avons instructions d'installation pour d'autres systèmes dans notre documentation)

Une fois installé, vous devez inscrire votre identité locale auprès d'Ockam Orchestrator, exécutez la commande ci-dessous et suivez les instructions fournies :

 ockam enroll

Configurer le module complémentaire Confluent

Nous supposons ici que vous avez déjà un cluster fonctionnel sur Confluent Cloud (et les outils de ligne de commande Kafka fournis avec le dernière distribution Kafka ), la première étape consiste donc à configurer votre projet Ockam pour utiliser le module complémentaire Confluent en le faisant pointer vers l'adresse de votre serveur d'amorçage :

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

Nous devrons ensuite enregistrer la configuration de notre projet Ockam afin de pouvoir l'utiliser plus tard pour enregistrer nos producteurs et nos consommateurs. Enregistrez donc la sortie dans un nom de fichier project.json :

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

En tant qu'administrateur du projet Ockam, vous pouvez contrôler quelles autres identités sont autorisées à s'inscrire dans votre projet en émettant des jetons d'inscription uniques à usage unique. Nous allons commencer par en créer un pour notre consommateur :​

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

... puis une pour le premier producteur :

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

Le dernier fichier de configuration que nous devons générer est kafka.config , qui sera l'endroit où vous stockerez le nom d'utilisateur et le mot de passe que vous utilisez pour accéder à votre cluster sur 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

Configurer les consommateurs pour recevoir des messages chiffrés

Sur votre nœud consommateur, vous commencerez par créer une nouvelle identité (vous aurez besoin de la commande Ockam installée, alors répétez les instructions d'installation si vous le faites sur un hôte séparé) :

 ockam identity create consumer

Copiez les fichiers project.json et consumer.token de la section précédente, puis utilisez-les pour authentifier et inscrire cette identité dans votre projet Ockam :

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

Un nœud Ockam est un moyen de connecter en toute sécurité différents services les uns aux autres, nous allons donc en créer un ici que nous utiliserons pour communiquer via le cluster Confluent Cloud en utilisant l'identité que nous venons de créer :

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

Une fois cela terminé, nous pouvons maintenant exposer notre serveur d'amorçage Kafka. C'est comme si le serveur d'amorçage Kafka distant et les courtiers sont devenus virtuellement adjacents sur 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

Copiez le fichier kafka.config et utilisez-le pour créer un nouveau sujet que nous utiliserons pour envoyer des messages entre le producteur et le consommateur dans cette démo (dans ce cas, nous avons appelé le sujet demo-topic )

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

La dernière étape consiste à démarrer notre script consommateur, en le faisant pointer vers localhost:4000 en tant que serveur d'amorçage :

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

Le code consommateur poussera toutes les communications dans le processus de nœud Ockam qui s'exécute sur l'hôte local. Ce processus Ockam local gérera automatiquement la génération de clés cryptographiques, établissant un canal sécurisé pour la communication avec tous les nœuds producteurs, puis recevant, déchiffrant et transférant par la suite tous les messages reçus du courtier s'exécutant sur notre cluster Confluent Cloud.

Envoyez des messages cryptés à partir de plusieurs producteurs

Pour que nos consommateurs puissent traiter des messages, nous devons avoir quelque chose qui les produise. Nous allons maintenant suivre un processus très similaire, mais créer à la place les pièces nécessaires à un producteur. Nous recommençons une fois de plus en créant une identité sur l'hôte du producteur (encore une fois, installez la commande Ockam sur cet hôte si nécessaire) :

 ockam identity create producer1

Copiez les fichiers project.json et producer1.token de la section précédente et utilisez-les pour vous authentifier et vous inscrire à notre projet Ockam :

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

Créez un nœud et liez-le à la fois au projet et à l'identité que nous avons créés :

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

Et exposez notre serveur d'amorçage Kafka sur le port 5000 afin que nous puissions commencer à envoyer des messages via 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

Assurez-vous de copier le fichier kafka.config et démarrez votre producteur :

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

Votre code de producteur existant sera maintenant en cours d'exécution, communiquant avec le courtier via le portail sécurisé que nous avons créé et qui a exposé le serveur d'amorçage Kafka et les courtiers Kafka sur les ports locaux, et envoyant des messages via le consommateur qui a été configuré à l'étape précédente. Cependant, toutes les charges utiles des messages seront cryptées de manière transparente lorsqu'elles entrent dans le nœud du producteur et ne sont décryptées qu'à leur sortie du nœud consommateur. À aucun moment du transit, le courtier ne peut voir la charge utile du message en clair qui a été initialement envoyée par le producteur.

Pour aller plus loin dans cet exemple, vous pouvez répéter cette étape pour un nombre N de producteurs en générant un nouveau jeton d'inscription pour chacun, puis en répétant les étapes de cette section.

Si vous regardez les messages chiffrés dans Confluent Cloud, ils s'afficheront sous forme de caractères non reconnaissables, comme dans la capture d'écran suivante :

Flux de messages chiffrés de bout en bout

Un exemple qui ne prend que quelques minutes à mettre en œuvre signifie qu'il peut être facile de passer à côté d'un certain nombre d'améliorations importantes de la sécurité et de l'intégrité qui découlent de cette approche :

• Clés uniques par identité : chaque consommateur et producteur génère ses propres clés cryptographiques et reçoit ses propres informations d'identification uniques. Ils les utilisent ensuite pour établir entre eux un canal sécurisé de confiance mutuelle. En supprimant la dépendance à un service tiers pour stocker ou distribuer des clés, vous pouvez réduire votre surface de vulnérabilité et éliminer les points de défaillance uniques.

  
  

• Transfert de données infalsifiable : en poussant le contrôle des clés vers les bords du système, là où le chiffrement et le déchiffrement authentifiés se produisent, aucune autre partie de la chaîne d'approvisionnement n'est en mesure de modifier les données en transit. Vous pouvez être assuré que les données que vous recevez chez le consommateur sont exactement celles qui ont été envoyées par vos producteurs. Vous pouvez également être assuré que seuls les producteurs autorisés peuvent écrire dans un sujet, garantissant que les données de votre sujet sont hautement fiables. Si vous avez des exigences encore plus strictes, vous pouvez prendre le contrôle de votre autorité d'identification et appliquer des politiques d'autorisation granulaires.

  
  

• Fenêtre d'exposition réduite : les canaux sécurisés d'Ockam alternent régulièrement les clés d'authentification et les secrets de session. Cette approche signifie que si l'un de ces secrets de session a été exposé, votre fenêtre d'exposition totale des données est limitée à la courte durée d'utilisation du secret. La rotation des clés d'authentification signifie que même lorsque les clés d'identité d'un producteur sont compromises, aucune donnée historique n'est compromise. Vous pouvez supprimer de manière sélective le producteur compromis et ses données. Avec les approches centralisées de distribution de clés partagées, il existe un risque que toutes les données actuelles et historiques ne soient plus fiables après une violation, car elles peuvent avoir été falsifiées ou volées. L'approche d'Ockam élimine le risque de données historiques compromises et minimise le risque pour les données futures à l'aide de clés à rotation automatique.

  
  

Tous ces avantages sont possibles, aujourd'hui, sans aucun changement de code et sans changement de configuration minimal des déploiements existants.

Prochaines étapes

• Si vous n'avez pas encore suivi l'exemple de ce guide, vous pouvez commencer à utiliser Ockam gratuitement en suivant les instructions de notre documentation.
• Si vous souhaitez parler spécifiquement de cela ou d'autres cas d'utilisation potentiels pour Ockam, l'équipe serait plus qu'heureuse de vous discuter avec toi .
• Vous pouvez également nous rejoindre, ainsi qu'une communauté toujours croissante de développeurs qui souhaitent instaurer la confiance en créant des applications sécurisées dès la conception, dans le Construire un serveur Discord de confiance ou sur GithubGenericName .