Ockam Orchestrator の Confluent アドオンを使用すると、Confluent Cloud を介して改ざん防止されたエンド ツー エンドの暗号化されたメッセージ ストリームを、コードの変更なしで実現できます。このドロップイン ソリューションにより、企業はコストのかかる再構築や開発作業を必要とせずに、一般的なセキュリティおよびコンプライアンスの要件を超えることができます。
Kafka デプロイメントは通常、認証トークンと Transport Layer Security (TLS) を組み合わせて、Kafka トピックに出入りするデータを保護します。これはインターネット経由で転送中のデータを保護しますが、Kafka を通過するデータを保護するための完全なソリューションを提供するものではありません。 Kafka ブローカーは、プレーンテキスト データを一時的に見ることができます。
Kafka ブローカーとの間の通信の暗号化と、Kafka 内部の保存データの暗号化を組み合わせても、Kafka ブローカーまたはそれが実行されているインフラストラクチャが侵害された場合、データ侵害から十分に保護されません。データを復号化するためのキーはメモリ内にあります。 Ockam は、Ockam Orchestrator の Confluent アドオンを介して、追加のリスク軽減の利点とデータ整合性の保証を提供しながら、これらの問題を解決します。
あなたのチームは、ストリーム処理プラットフォームをシステムに統合することが、ビジネスの規模と俊敏性の両方のニーズを満たす最善の方法であると判断しました。Apache Kafka は、使用するプラットフォームとして当然の選択でした。また、チームがインフラストラクチャの実行ではなく付加価値に集中できるように、Confluent Cloud で経験豊富なマネージド プラットフォームを使用することを決定しました。開発が完了し、チームはプロデューサーが Confluent Cloud にデータを送信し、コンシューマーが反対側でデータを受信できる実用的なソリューションを手に入れました。プロデューサー、コンシューマー、および Confluent Cloud 間の通信は暗号化され、Transport Layer Security (TLS) を使用して安全に保護されているため、本番環境での使用に移行しようとしています。
セキュリティとコンプライアンスのレビューにより、問題が表面化しました。 Confluent Cloud を信頼していても、サプライ チェーンのリスクを軽減することに重点が置かれているということは、暗号化されていないシステムを介してデータを移動させることは、もはやセキュリティ要件を満たしていないことを意味します。サプライチェーン内の他のベンダーがセキュリティ違反を起こした場合、ビジネスへのリスクをどのように軽減しますか?次のことを確認できる必要があります。
これらの両方に対するソリューションがなければ、自社のサプライ チェーンのセキュリティ侵害によって、機密データが公開されるだけでなく、予期しないダウンストリームのエスカレーションが発生するリスクがあります。
ほんの数分で、Kafka と Confluent を介して移動中にデータが常に暗号化され、改ざん防止されていることを保証するエンド ツー エンド ソリューション全体を構成および統合する方法の完全な実用例を紹介します。 .
注: 以下のコード例は、開発者のエクスペリエンスを改善し続けるため、変更される可能性があります。最新のドキュメントについては、 https://docs.ockam.io/を確認してください。
以前に Ockam をセットアップしたことがある場合は、このセクションをスキップして、以下の 2 つの例に直接進むことができます。
brew install build-trust/ockam/ockam
(パッケージ管理にbrewを使用していない場合は、
インストールしたら、ローカル ID を Ockam Orchestrator に登録する必要があります。以下のコマンドを実行し、表示される指示に従います。
ockam enroll
ここでは、Confluent Cloud 上で動作するクラスター (および、
ockam project addon configure confluent \ --bootstrap-server YOUR_CONFLUENT_CLOUD_BOOTSTRAP_SERVER_ADDRESS
次に、Ockam プロジェクト構成を保存して、後でプロデューサーとコンシューマーを登録できるようにする必要があるため、出力をファイル名project.json
に保存します。
ockam project information default --output json > project.json
Ockam プロジェクトの管理者は、一意の 1 回限りの登録トークンを発行することで、プロジェクトに登録できる他の ID を制御できます。コンシューマー用に作成することから始めます。
ockam project enroll --project-path project.json --attribute role=member > consumer.token
...そして、最初のプロデューサー用に 1 つ:
ockam project enroll --project-path project.json --attribute role=member > producer1.token
最後に生成する必要がある構成ファイルはkafka.config
です。これは、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
コンシューマー ノードで、新しい ID を作成することから始めます (Ockam コマンドをインストールする必要があるため、別のホストでこれを行う場合は、インストール手順を繰り返します)。
ockam identity create consumer
前のセクションからproject.json
ファイルとconsumer.token
ファイルをコピーし、それらを使用してこの ID を認証し、Ockam プロジェクトに登録します。
ockam project authenticate \ --project-path project.json \ --identity consumer \ --token $(cat consumer.token)
Ockam ノードは、さまざまなサービスを相互に安全に接続する方法です。そのため、ここで作成したノードを作成して、作成したばかりの ID を使用して Confluent Cloud クラスターを介して通信するために使用します。
ockam node create consumer \ --project project.json --identity consumer
それが完了すると、Kafka ブートストラップ サーバーを公開できます。これは、リモートの Kafka ブートストラップ サーバーとブローカーが実質的に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
kafka.config
ファイルをコピーし、それを使用して、このデモでプロデューサーとコンシューマーの間でメッセージを送信するために使用する新しいトピックを作成します (この場合、トピックをdemo-topic
と呼びます)。
kafka-topics.sh \ --bootstrap-server localhost:4000 \ --command-config kafka.config \ --create \ --topic demo-topic \ --partitions 3
最後のステップは、ブートストラップ サーバーとしてlocalhost:4000
を指すコンシューマー スクリプトを開始することです。
kafka-console-consumer.sh \ --topic demo-topic \ --bootstrap-server localhost:4000 \ --consumer.config kafka.config
コンシューマー コードは、ローカル ホストで実行されている Ockam ノード プロセスにすべての通信をプッシュします。そのローカルの Ockam プロセスは、暗号化キーの生成を自動的に管理し、任意のプロデューサー ノードと通信するための安全なチャネルを確立し、その後、Confluent Cloud クラスターで実行されているブローカーから受信したすべてのメッセージを受信、復号化、および転送します。
消費者がメッセージを処理するには、メッセージを生成するものが必要です。ここでは非常によく似たプロセスを実行しますが、代わりにプロデューサーに必要なパーツを作成します。もう一度、プロデューサーのホストに ID を作成することから始めます (必要に応じて、そのホストに Ockam コマンドをインストールします)。
ockam identity create producer1
前のセクションからproject.json
およびproducer1.token
ファイルをコピーし、それを使用して認証し、Ockam プロジェクトに登録します。
ockam project authenticate \ --project-path project.json \ --identity producer1 \ --token $(cat producer1.token)
ノードを作成し、作成したプロジェクトと ID の両方にリンクします。
ockam node create producer1 \ --project project.json \ --identity producer1
そして、ポート5000
で Kafka ブートストラップ サーバーを公開して、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
必ずkafka.config
ファイルをコピーして、プロデューサーを開始してください。
kafka-console-producer.sh \ --topic demo-topic \ --bootstrap-server localhost:5000 \ --producer.config kafka.config
既存のプロデューサー コードが実行され、ローカル ポートで Kafka ブートストラップ サーバーと Kafka ブローカーを公開している、作成した安全なポータルを介してブローカーと通信し、前の手順で設定したコンシューマーにメッセージを送信します。ただし、すべてのメッセージ ペイロードは、プロデューサーのノードに入るときに透過的に暗号化され、コンシューマー ノードを出るまで復号化されません。プロデューサによって最初に送信されたプレーンテキストのメッセージ ペイロードは、転送中のどの時点でも、ブローカには表示されません。
この例をさらに進めるには、 N個のプロデューサーに対してこの手順を繰り返すことができます。それぞれに対して新しい登録トークンを生成し、このセクションの手順を繰り返します。
Confluent Cloud 内の暗号化されたメッセージを見ると、次のスクリーン キャプチャのように認識できない文字として表示されます。
実装に数分しかかからない例は、このアプローチから得られるセキュリティと整合性の多くの重要な改善を見逃す可能性があることを意味します。
ID ごとの一意のキー: 各コンシューマとプロデューサーは独自の暗号化キーを生成し、独自の一意の資格情報を発行します。次に、これらを使用して、相互に信頼できる安全なチャネルを相互に確立します。キーを保存または配布するためのサードパーティ サービスへの依存を取り除くことで、脆弱性の表面領域を減らし、単一障害点を排除することができます。
改ざん防止データ転送: 認証された暗号化と復号化が行われるシステムのエッジにキーの制御をプッシュすることにより、サプライ チェーンの他の関係者が転送中のデータを変更することはできません。コンシューマーで受け取るデータは、プロデューサーによって送信されたものとまったく同じであることが保証されます。また、承認されたプロデューサーのみがトピックに書き込むことができるため、トピック内のデータの信頼性が高くなります。さらに厳しい要件がある場合は、資格証明機関を制御して、きめ細かな承認ポリシーを適用できます。
公開期間の短縮: Ockam セキュア チャネルは、認証キーとセッション シークレットを定期的にローテーションします。このアプローチは、これらのセッション シークレットの 1 つが公開された場合、データ公開ウィンドウの合計がそのシークレットが使用されていたわずかな期間に制限されることを意味します。認証キーをローテーションするということは、プロデューサーの ID キーが侵害された場合でも、履歴データが侵害されないことを意味します。侵害されたプロデューサーとそのデータを選択的に削除できます。集中型の共有キー配布アプローチでは、現在および過去のすべてのデータが改ざんまたは盗難された可能性があるため、侵害後に信頼できなくなるリスクがあります。 Ockam のアプローチは、履歴データが危険にさらされるリスクを排除し、自動ローテーション キーを使用して将来のデータへのリスクを最小限に抑えます。
現在、これらの利点はすべて、コードを変更せず、既存の展開に対する最小限の構成変更で実現できます。
ここにも掲載されています。