AI APIセキュリティに最適な暗号化手法

一言でまとめるなら、こうです。TLS 1.3がベースラインであり、mTLSがマシンのアイデンティティを証明し、ペイロード暗号化がTLS終了後もなお重要なデータをカバーします。

AI APIへの攻撃は、2022年上半期から2023年上半期にかけて681%急増しました。ですから、AI APIを保護するなら、私は1つの解決策を探しません。_レイヤー_で見ます。この記事では、最も重要なポイントにわたって7つの暗号化手法を比較します。

• セキュリティ範囲
• パフォーマンスコスト
• 鍵管理の労力
• トランスポート層とアプリケーション層のカバー範囲
• 米国展開への適合性

要点はこうです。

• 対称暗号化は、大きなペイロードと保存データに最適です。
• 公開鍵暗号化は、鍵交換と署名に最適です。
• ハイブリッド暗号化は両方を混ぜるため、ほとんどのアプリ層のユースケースに適合します。
• TLS 1.2/1.3は転送中のデータを保護し、TLS 1.3がデフォルトです。
• mTLSは接続の両端をチェックします。
• フィールドレベル暗号化は、隠しておく必要のあるフィールドだけを保護します。
• エンベロープ暗号化は、大規模な鍵ローテーションをはるかに容易にします。

要点はこうです。 トランスポートセキュリティはTLS終了で止まります。プロンプト、画像、音声、ログ、キュー、バックアップがその時点以降も保護を必要とするなら、私は別のレイヤーが必要です。

AIアプリの機密データを保護する

簡易比較

短い答えが欲しいなら、こうです。デフォルトでTLS 1.3を使い、サービスのアイデンティティにはmTLSを追加し、データが接続そのものを超えて保護されなければならないときは、フィールドレベル、ハイブリッド、またはエンベロープ暗号化を使う。

1. 対称暗号化

対称暗号化は、一括データを保護する高速な方法です。しかし、それ自体では鍵交換を解決しません。暗号化と復号の両方に1つの共有鍵を使うため、AI APIセキュリティの中核部分となります。通常の選択は**AES-256-GCM**です。高速で、組み込みの整合性チェックを備えているからです ^[4][10]。

セキュリティ範囲

AES-256-GCMは2つの場面でうまく機能します。保存時のデータと転送中のデータです。これには、保存された学習セット、モデルの重み、アーカイブされた出力、そしてTLS 1.3内部で使われる一括暗号化が含まれます ^[3][2]。GCMはAEADモードであるため、機密性を保護し、プロンプトやマルチモーダルペイロードの改ざんを検出するのに役立つ認証タグを追加します ^[4]。

無視できない制限が1つあります。対称暗号化は、データがモデルに到達するまでしか保護しません。推論中、モデルはプレーンテキストで処理せざるを得ません。つまり、プレーンなデータは依然としてRAMやGPUメモリ内で露出する可能性があります ^[7]。

パフォーマンスへの影響

AES-256-GCMは、AES-NIをサポートする標準的なサーバーCPUで4.2 GB/sに達することができます ^[8]。平たく言えば、小さなプロンプトの暗号化はマイクロ秒単位で済み、これはネットワーク遅延やモデルのランタイムよりもはるかに小さいです ^[8]。

AES-NIのないモバイルクライアントやエッジデバイスでは、通常**ChaCha20-Poly1305の方が適しています。ソフトウェア性能に最適化されており、Apple A17 Proのようなハードウェアで3.4 GB/s**に達し、同じ256ビットのセキュリティレベルを提供します ^[8]。

鍵管理

ここに落とし穴があります。両側が同じ秘密を必要とするのです。ですから難しいのは、その鍵を安全に共有することであり、これには通常、非対称暗号を持ち込むことになります。

大規模には、チームはしばしば対称鍵をKEKでラップし、ペイロード全体を再暗号化することなくデータを再鍵化できるようにします ^[2][11]。KEKのローテーションは自動化されるべきで、鍵は**FIPS 140-3 Level 3で検証されたHSM**か専用のシークレットマネージャーに置くべきです。設定ファイルやアプリのソースコードには置きません ^[11][10]。

その共有鍵の問題こそが、まさに次に非対称暗号化が来る理由です。

最適なAI APIのユースケース

対称暗号化は、一括ペイロードに適しています。高解像度画像、動画ファイル、長い音声クリップ、大きなJSONリクエストボディなどです ^[4]。また、長期アーカイブや、DEKをテナント固有の鍵でラップしてデータを分離するテナント単位の分離にもよく機能します ^[2][10]。

ただし、転送と鍵交換については、対称暗号化はスタックの一部にすぎません。

2. 非対称暗号化

非対称暗号化は、対称暗号化がうまく扱えない部分をカバーします。安全な鍵交換とアイデンティティチェックです。これは2つの連携した鍵を使います。

• 誰でもアクセスできる公開鍵
• 所有者だけが保持する秘密鍵

データが公開鍵で暗号化された場合、対応する秘密鍵だけがそれを復号できます。

セキュリティ範囲

非対称暗号化が重要なのは、TLS終了後も機密ペイロードを保護し続けられるからです。TLSは最初のホップのトラフィックを保護します。しかしトラフィックがそれを超えて移動すると、そのレイヤーはなくなります。

そこでメッセージレベルの暗号化が登場します。非対称鍵でデータを暗号化すると、プロンプト内のPIIのような機密コンテンツが、内部のロギングシステム、サービスメッシュ、分散トレーシングのパイプラインを通過する間も暗号化されたままでいられます ^[4][12]。

デジタル署名もサポートします。それらの署名は、プロンプトが主張された送信者から来たことを検証し、否認防止を提供するのに役立ちます ^[4]。

トレードオフはシンプルです。このレベルの保護は、計算コストがはるかに高くつきます。

パフォーマンスへの影響

非対称暗号化は、画像、動画、音声のような大きなペイロードには遅すぎます。一括データではなく、鍵と署名に使いましょう ^[14]。

署名には、ECCと**Ed25519**がRSAより性能が良く、最新のAI API認証によりよく適合します ^[14]。

鍵管理

秘密鍵は、FIPS 140-3 Level 3で検証されたHSMか、Trusted Execution Environment（TEE）に置くべきです ^[10]。公開鍵はしばしば**JWKS（JSON Web Key Set）エンドポイント**を通じて共有され、APIパートナーが鍵を自動的に見つけて確認できるようにします ^[5]。

鍵のローテーションは、鍵が侵害された場合の被害を抑えるため、90日周期で行うべきです ^[5]。

ここでのコスト差は無視しがたいものです。AWS KMSでは、非対称RSAの操作が10,000リクエストあたり最大$12.00かかることがある一方、対称の操作は10,000リクエストあたり約$0.03です ^[14]。

最適なAI APIのユースケース

非対称暗号化は、鍵交換と認証に最適です。マルチテナントのAI APIでは、対称鍵をラップしたり、プロンプトの真正性を検証したりするために最もよく使われます ^[4]。また、mTLSを通じたクライアント認証もサポートします ^[1]。

チームが今から計画しておくべきもう1つの課題があります。ポスト量子への移行です。標準的なRSAとECCは、将来の量子攻撃に対して脆弱になります。NISTは最初のポスト量子暗号標準であるFIPS 203、204、205を2024年8月に確定させ、初期のベンチマークでは、標準的なサーバーハードウェア上で**ML-KEMがRSA-2048と比べて5%未満**のパフォーマンスオーバーヘッドを追加することが示されています ^[3][10]。

実際には、非対称暗号化が鍵を保護し、対称暗号化がペイロードを保護します。

3. ハイブリッド暗号化

ハイブリッド暗号化は、ランダムな対称DEKでペイロードを保護し、そのDEKを非対称の公開鍵でラップします。端的に言えば、データそのものには暗号化の高速な部分を使い、鍵には公開鍵の部分を使います。これはTLS終了後、データが依然として内部システムを通過する可能性があるときに最も重要になります。

セキュリティ範囲

ハイブリッド暗号化は、TLS終了後も、サービスメッシュ、プロキシ、ログの内部を含めて、ペイロードを暗号化されたまま保ちます。各リクエストは独自の短命なDEKを得るため、1つの鍵が露出したときの影響範囲が縮小します。

AES-256-GCMを使うと、認証タグも追加されます。そのタグは、AIシステムがペイロードに触れる前に改ざんを検出するのに役立ちます。転送については、このレイヤーはTLSの_代わり_ではなく、TLS_と共に_機能します。

パフォーマンスへの影響

ハイブリッドのセットアップでは、非対称のステップはDEKをラップするだけです。ペイロード自体の重い処理はAESが担います。そのため、このモデルは、動画、高解像度画像、音声ストリームのような大きなマルチモーダルリクエストでも、大規模でも動作を遅らせることなくうまく機能します。

鍵管理

KEKをHSMに保管し、各リクエストごとに短命なDEKを生成し、key_idを付与して、ペイロードを再暗号化することなくDEKを再ラップできるようにします。そのセットアップは、鍵のローテーションをはるかに苦痛の少ないものにします。

マルチテナントのAIプラットフォームでは、**暗号消去（crypto-shredding）**もサポートします。テナントのマスター鍵を破棄すると、リンクされたすべての暗号化ペイロードが、各レコードやバックアップを1つずつ処理することなく読み取り不能になります。

最適なAI APIのユースケース

ハイブリッド暗号化は、TLS終了後にデータが信頼境界を越えるAI APIのパスに適しています。たとえば以下です。

• マルチホップアーキテクチャ
• リバースプロキシ
• ロードバランサー
• サービスメッシュ

また、プロバイダーがプレーンテキストを一切扱わないゼロ知識のワークフローにも適合します。

ポスト量子への移行では、ラッピングレイヤーだけを変更すれば済みます。RSAやECDHをML-KEM（FIPS 203）に置き換えることで、後で復号され得る保存済み暗号文を保護するのに役立ち、一方でAES-256の対称レイヤーはそのままです ^[10]。ハイブリッド暗号化はTLSを超えたペイロード保護を扱います。次のレイヤーは、TLSとmTLSによるトランスポート認証です。

4. TLS 1.2/1.3

TLSは、あらゆるAI APIのベースラインとなるトランスポートセキュリティレイヤーです。TLS 1.3をデフォルトにすべきです。 ハイブリッド暗号化がネットワークエッジを超えてデータを保護するなら、TLSはネットワークそのものを渡る道のりを保護します。端的に言えば、TLSは転送中のデータを保護し、ペイロード暗号化はTLS終了後もなお露出し得るものをカバーします。

セキュリティ範囲

TLS 1.3は、RC4、DES、3DESのような弱いレガシー暗号スイートを削除します。TLS 1.2は、自分で無効にしない限り、依然としてそれらを許可することがあります ^[10][18]。TLS 1.3はまた、Perfect Forward Secrecy（PFS）を要求し、ハンドシェイク中にクライアント証明書を暗号化するため、内部サービス関係の受動的な監視をはるかに困難にします ^[15][17]。

パフォーマンスへの影響

TLS 1.3は、ハンドシェイクを2 RTTから1に削減します ^[15][9]。小さく聞こえるかもしれませんが、リアルタイム音声や動画ストリーミングのような高頻度のワークロードでは、p99レイテンシを削減しCPU負荷を軽減するのに役立ちます。

TLS 1.3はまた、0-RTTの再開を許可するため、再開されたセッションはすぐにデータを送信できます。それは高速ですが、トレードオフがあります。0-RTTにはリプレイのリスクがあります。機密性の高いAPIルートでは、0-RTTを無効にしてください ^[16]。

鍵管理

証明書の扱いは、多くのチームが緊張感を保つか、あるいはずさんになるかの分かれ目です。より安全な道はシンプルです。

• 証明書を90日ごとにローテーションする ^[16][9]
• Let's Encryptのような公開エンドポイント向けに自動発行を使う ^[1]
• 秘密鍵を、エクスポート可能なPEMファイルではなく、HSMやTEEに保管する ^[3][10]
• 規制環境では、FIPS 140-3で検証されたモジュールを使う ^[10]
• TLS 1.2をアップグレードできない場合は、ECDHEベースの暗号スイートのみを許可し、forward secrecyを維持する ^[10]
• OCSPステープリングを有効にして、証明書チェックを高速化し、ハンドシェイク中にネットワークの往復を追加しないようにする ^[9]

最適なAI APIのユースケース

TLS 1.3は、公開エンドポイント、ブラウザアプリ、リアルタイムのマルチモーダルWebSocketストリームに適したデフォルトです ^[15][16]。TLS 1.2は、古いエンタープライズ統合の互換性の下限として依然として許容できますが、PFSのみの暗号スイートにロックダウンされている場合に限ります ^[10]。

サービス間トラフィックには、mTLSがアイデンティティ検証を追加します。

5. 相互TLS（mTLS）

mTLSはTLSの上に構築され、アプリのデータが送信される前に、証明書でクライアントとサーバーの両方をチェックします。

セキュリティ範囲

これはAPIキーが残すギャップを埋めます。APIキーは秘密を証明します。それは、どのワークロードが呼び出しを行っているかを証明しません。

AIエージェント、マイクロサービス、その他のワークロードのアイデンティティに対して、mTLSは検証済みのサービスにアクセスを限定します。それは、機密性の高いモデルエンドポイントや、システムが画像や音声のようなマルチモーダルデータを交換するときに重要です ^[15][13][20]。

パフォーマンスへの影響

主な欠点は、余分なハンドシェイク作業です。mTLSは通常、標準TLSと比べて約1〜2ミリ秒のレイテンシと5〜10%多いハンドシェイク時間を追加します ^[21]。

その負担を減らす一般的な方法は、APIゲートウェイやエッジファイアウォールでmTLSを終端することです。それにより、非対称暗号の作業をモデルのランタイムから遠ざけられます ^[17][15]。コネクションプーリングとキープアライブヘッダーも、そのコストを毎回ゼロから支払うのではなく、多くのリクエストにわたって分散させるのに役立ちます ^[21]。

鍵管理

mTLSは、証明書の発行、ローテーション、失効のための強力なPKIプロセスを必要とします ^[6][19]。この部分は気軽に扱えません。証明書の更新を見逃すと、サービス間トラフィックがその場で失敗しかねません ^[19]。

自動化されたPKIツールを使って、発行、ローテーション、失効を大規模に扱いましょう。秘密鍵には、PKCS#11を通じたHSMやTPMのようなハードウェアバックのストレージが、鍵をエクスポート不可に保つのに役立ちます ^[13]。短命な証明書もリスクを減らします。SPIFFEは、ワークロードのアイデンティティに対して1時間という短さの有効期間を推奨しています ^[21]。

最適なAI APIのユースケース

mTLSは、マシン間トラフィックに最適です。内部データベースを呼び出すAIエージェント、機密性の高いマルチモーダルデータを受け渡すマイクロサービス、そして起源の暗号学的証明を必要とする規制対象の統合などです。これらのセットアップでは、mTLSはAPIキー認証と並ぶ追加の認証レイヤーとして機能します ^[15][20]。

接続レイヤーでのアイデンティティにはmTLSを使いましょう。特定のフィールドが転送後も保護されたままでなければならないときは、フィールドレベル暗号化を使いましょう。

6. フィールドレベル暗号化

mTLSは誰が呼び出しているかを教えてくれます。フィールドレベル暗号化は、彼らが送るものの中の機密値を保護します。

重要な違いはシンプルです。ペイロード全体を暗号化する代わりに、フィールドレベル暗号化は、転送が終わった後も隠しておく必要のあるフィールドだけをカバーします。つまり、TLSとmTLSが役割を終えた後でも、その保護は依然として重要なのです。

セキュリティ範囲

TLSは転送中のデータを保護します。フィールドレベル暗号化は、TLS終了後のデータそのものを保護します。

このアプローチは、社会保障番号、医療メモ、クレジットカード番号全体など、特別な注意が必要なフィールドだけを暗号化します。その結果、それらの値は、ログ、キュー、バックアップ、データベースダンプなど、データがしばしば残る場所で暗号化されたままになります。

ただし、トレードオフがあります。モデルはプレーンテキストのまま残されたフィールドしか扱えません。ですから、モデルが仕事をするために値を必要とする場合、そのフィールドは推論時に暗号化されたままにできません。実際には、モデルが必要としないものだけを暗号化すべきということです。また、保護される各フィールドには小さな処理コストがあります。

パフォーマンスへの影響

フィールドレベル暗号化は通常、5%〜10%のレイテンシを追加します。保護される各フィールドを個別に暗号化・復号する必要があるからです。

そのコストは通常問題ありませんが、鍵の扱いとフィールドIDがクリーンに保たれている場合に限ります。そうでない場合、オーバーヘッドはすぐに積み上がります。

鍵管理

フィールドレベル暗号化には、最も重要な3つの制御が伴います。

• テナント単位の鍵分離を使う。 すべてのテナントが1つの鍵を共有すると、1件の侵害で全員のデータが露出しかねません ^[10]。
• 各暗号化フィールドと共にKey IDまたはバージョンタグを含める ことで、ローテーション後もレガシーデータを既存レコードを壊すことなく復号できます ^[1]。
• テナント単位のフィールド鍵を使う ことで、1つのテナントが侵害された場合の露出を限定します。

最適なAI APIのユースケース

フィールドレベル暗号化は、プロンプトのごく一部だけを秘密に保つ必要があり、残りは依然としてモデルが利用可能なままである必要があるときに最適です。

• マルチテナントのAI SaaS - テナント単位の鍵が、1つのテナントが侵害された場合の影響範囲を限定します。
• 外部ロギングパイプライン - ログがプラットフォーム外に送られても、PIIは暗号化されたままです。
• ヘルスケアや金融のAI API - 機密フィールドは、ログ、データベースダンプ、キュー、バックアップの中で暗号化されたままです。
• 部分推論ワークフロー - モデルは機密でないフィールドだけを読みます。

7. エンベロープ暗号化

エンベロープ暗号化は、鍵のローテーションを悪夢にすることなく、大きなペイロードを保護する実用的な方法です。考え方はシンプルです。データをDEKで暗号化し、そのDEKをKEKで暗号化します。

平たく言えば、こう機能します。ランダムなData Encryption Key（DEK）が、テキスト、画像、動画ファイルのいずれであっても、実際のAIペイロードを、AES-256のような高速な対称暗号化を使って暗号化します。次に、KMSやHSMに保管されたKey Encryption Key（KEK）が、DEK自体を暗号化します。保存または送信するオブジェクトには2つのものが含まれます。暗号化されたペイロードと、ラップされたDEKです。そのセットアップは、フィールド単位の制御よりもペイロードのサイズと鍵のローテーションが重要なときに、エンベロープ暗号化を良い選択にします。

セキュリティ範囲

エンベロープ暗号化は、アプリケーション層でデータを保護します。ですから、TLS終了後でも、ペイロードはログ、キュー、バックアップのような場所で保護されたままです。

無視できない制限が1つあります。データはAI推論中に依然としてメモリ内で復号されなければなりません。エンベロープ暗号化をTEEのようなConfidential Computingと組み合わせない限り、GPUやCPUのメモリ内にプレーンテキストが存在する隙間は依然として残ります ^[3][7]。それがトレードオフです。大きなメリットは、大規模なデータを扱っていて、鍵が変わるたびに膨大な量を再暗号化したくないときに現れます。

パフォーマンスへの影響

エンベロープ暗号化は、直接的な非対称暗号化よりもはるかに実用的です。なぜでしょうか。AES-GCMがペイロードの重い処理を担い、非対称暗号は小さなDEKだけを保護するからです。

そのセットアップは、環境によっては約3%〜7%のオーバーヘッドを追加します ^[5]。

高解像度画像や動画を処理するマルチモーダルAI APIにとって、AES-GCMは強力な選択です。認証付き暗号化、すなわちAEADを提供するからです。端的に言えば、ペイロードが転送中に改変されなかったことを確認するのに役立ちます ^[4]。

鍵管理

ここがエンベロープ暗号化が輝くところです。AIの学習コーパスは、テラバイト、あるいはペタバイトにまで膨らむことがあります ^[2]。鍵が変わるたびにデータセット全体を再暗号化するのは、過酷な運用作業になるでしょう。

エンベロープ暗号化なら、ペイロードには手を触れません。小さなDEKを新しいKEKで再ラップするだけです ^[2]。

ここではいくつかの基本ルールが重要です。

• KEKは、アプリケーションの環境変数ではなく、クラウドネイティブなKMSかHSMに保管する。
• 長期保存レコードにバージョンメタデータを追加し、鍵の変更後も古いデータを復号できるようにする ^[1]。

最適なAI APIのユースケース

エンベロープ暗号化は、大きなペイロード、マルチテナントの分離、そして鍵のローテーションを健全に保つ必要がある長期保存データにうまく機能します。ペイロードが大きい、長期間保存される、あるいは再処理にコストがかかる場合、このパターンは通常理にかなっています。

展開シナリオ別の長所と短所

すべてのケースに合う単一の暗号化手法はありません。適切な選択は、何を保護するか（テキスト、画像、音声、動画、規制対象のメタデータ）、そのデータがどこへ動くか、どれだけのレイテンシを許容できるかによります。下のマトリクスは、前のセクションと同じレンズを使います。範囲、レイテンシ、鍵管理、そして終了後も保護が保たれるか、です。

この表は、前の手法ごとの比較を、展開の選択へと変換します。

これらのシナリオは1つのことを明確にします。トランスポートセキュリティには停止点がある、そしてアプリケーション層の保護はトランスポートが終わるところから始まる、ということです。

トランスポートのみの保護は、データが信頼境界内にとどまり、TLS終了後に保護を必要としない場合にのみ使いましょう。TLSが終わると、プレーンテキストはそれを処理するサービスに届きます。それが、アプリケーション層の暗号化が埋めようとするギャップです。

規制対象のマルチモーダルワークロードでは、デフォルトのスタックは通常こうです。

• トランスポートにはTLS 1.3
• アイデンティティにはmTLS
• 終了後も保護されたままでなければならないデータにはフィールドレベルまたはエンベロープ暗号化

そのレイヤー化されたスタックが、規制対象のAI APIにとって実用的なデフォルトです。

モデルがフィールドのコンテキストを必要とするが生の値そのものは必要としないときは、暗号化ではなくマスキングを使いましょう。マスキングは意味を保ちます。暗号化は意味を取り除きます。たとえば、[email protected]を[EMAIL]に置き換えても、モデルは実際のアドレスを一切見ることなく、文を正しく読み取れます。

結論

すべてをこなす単一の暗号化手法はありません。選択は、範囲、レイテンシ、そして1つのシンプルな問いに集約されます。TLS終了後、あなたのデータはどこでまだ露出しているのか? 実際には、その決定は3つのレイヤーに落ち着きます。トランスポート、アイデンティティ、そしてペイロード保護です。

TLS 1.3は、AI APIのデフォルトのトランスポート層です。TLS 1.2は、レガシーシステムのフォールバックとしてのみ使うべきです。そこから、他の手法がTLSの残すギャップをカバーするために出番になります。ハイブリッド暗号化は、一括暗号化を遅らせることなく鍵の配布を解決するため、アプリケーション層で最も実用的なモデルです。マシンのアイデンティティを検証するにはmTLSを使いましょう。次に、TLS終了後も保護されたままでいる必要があるデータには、フィールドレベルまたはエンベロープ暗号化を使いましょう。エンベロープ暗号化は、KEKのローテーションがペタバイトのデータの再暗号化を回避するため、大規模なAIワークロードに特に有用です ^[2]。

これらのレイヤーを組み合わせると、リクエストのパス全体を保護します。高セキュリティの展開では、レイヤー化は任意ではありません。TLSがトランスポートを扱い、mTLSがアイデンティティを扱い、フィールドレベルまたはエンベロープ暗号化が、TLS終了後も安全なままでいる必要があるデータを保護します。

よくある質問

TLS 1.3では不十分なのはいつですか?

TLS 1.3は、データがシステム間を移動する間、それを保護するのに役立ちます。しかしその保護は、サーバー境界で止まります。

データがAIサーバーに到達すると、モデルが処理できるように復号されなければなりません。そしてそれがギャップを生みます。データはその後、メモリ、ログ、キャッシュ内で露出し得るのです。

だからこそ、データが転送を超えた保護を必要とするとき、TLS 1.3だけでは不十分なのです。

それはまた、他のいくつかの問題も扱いません。

• ペイロードのライフサイクル全体にわたるデータの整合性
• 誰がデータを処理しているかを知るための、計算する側の真正性
• 量子ベースの攻撃に対する長期的な保護

ですから、より厳格な制御が必要なら、ペイロードレベルの暗号化や署名付きトークンのような追加のレイヤーを、TLS 1.3の上に重ねたくなるでしょう。

すべてのAI APIにmTLSを使うべきですか?

いつもではありません。すべてのAI APIにmTLSを使うべきかどうかは、あなたのセキュリティ要件と、セットアップがどれだけの複雑さを扱えるかによります。

それは価値の高い接続に最も理にかなっています。内部のサービス間トラフィック、管理用API、そして機密データを含む転送などです。多くの場合、階層化されたセットアップが最も効果的です。一般的なトラフィックには標準のTLS 1.3を使い、機密性の高いルートにのみmTLSを要求するのです。

フィールドレベル暗号化とエンベロープ暗号化のどちらを選べばよいですか?

APIトークンや個人識別子のような、特定の機密値を厳密に保護する必要があるときは、フィールドレベル暗号化を選びましょう。それらの値が、ログ、キャッシュ、バックアップに現れても暗号化されたままに保ちます。それは侵害による被害を限定するのに役立ち、コンプライアンス要件をサポートできます。

より大きなペイロードを効率的に保護する必要があるときは、エンベロープ暗号化を選びましょう。データをDEKで暗号化し、その鍵をKEKでラップします。このセットアップは、鍵のローテーションと鍵管理を容易にします。