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   Kafka. Le courtier Kafka pourra voir temporairement les données en clair. par  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   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 : vous  Il n'y a aucune possibilité pour un tiers de lire les données pendant qu'elles sont en transit  Un tiers ne peut pas modifier les données pendant qu'elles sont en transit  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   pour la documentation la plus à jour. https://docs.ockam.io/   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  ), 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 :   dernière distribution Kafka   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   , 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 : kafka.config   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   et   de la section précédente, puis utilisez-les pour authentifier et inscrire cette identité dans votre projet Ockam : project.json consumer.token   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   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   ) kafka.config 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   en tant que serveur d'amorçage : localhost:4000   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   et   de la section précédente et utilisez-les pour vous authentifier et vous inscrire à notre projet Ockam : project.json producer1.token   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   afin que nous puissions commencer à envoyer des messages via Confluent Cloud : 5000   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   et démarrez votre producteur : kafka.config   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   de producteurs en générant un nouveau jeton d'inscription pour chacun, puis en répétant les étapes de cette section. N  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 :    : 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. Clés uniques par identité    : 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. Transfert de données infalsifiable    : 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. Fenêtre d'exposition réduite  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  gratuitement en suivant les instructions de notre documentation.   commencer à utiliser Ockam  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  ou sur  .   Construire un serveur Discord de confiance   GithubGenericName  Également publié   . ici

Build Applications That Trust Data-in-Motion

Cet audio est produit dans la langue originale de l'histoire !

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

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps