AES-256と公開鍵暗号の連携が機密データをどう守るのか

AES-256暗号化は、現在利用可能な対称暗号アルゴリズムの中で最も強固だと広く認識されています。しかし、この方式単独では解決できない課題があります。それは、データを復号する鍵を、どうやって当事者間で安全に共有するかという問題です。保護されていない経路でAES-256の鍵を送信してしまえば、そもそもデータを暗号化する意味がなくなってしまいます。

そこで登場するのが公開鍵暗号方式です。この2つは対になって機能します。AES-256は保存データおよび転送中データの暗号化という重い処理を担い、公開鍵・秘密鍵のペアは安全な鍵交換と本人認証を担当します。この連携の仕組みを理解することは、あらゆるプラットフォームの暗号化に関する主張を評価する上で欠かせません。また、CMMC、FedRAMP、HIPAAといったコンプライアンス要件にも直結する重要なテーマです。

エグゼクティブサマリー

要点: AES-256(対称暗号方式)と公開鍵・秘密鍵暗号方式(非対称暗号方式)は競合する規格ではありません。両者は補完し合うレイヤーであり、組み合わせることで機密データのやり取りにおけるパフォーマンスとセキュリティを両立させています。

なぜ重要なのか: CMMC 2.0やFedRAMPをはじめとするコンプライアンスフレームワークは、単に「暗号化していること」を求めているわけではありません。健全な鍵管理を伴う、FIPS認証済みの暗号化を求めているのです。AES-256を正しく実装していても、鍵管理レイヤーが脆弱であれば審査に落ちる可能性があります。この2種類の暗号方式がどう連携しているかを理解することで、あるプラットフォームの暗号化アーキテクチャが本当に堅牢なのか、それとも表面的なチェックボックス対応に過ぎないのかを見極められるようになります。

重要なポイント

1. AES-256は対称暗号方式であり、暗号化と復号に同じ鍵を使う

AES-256は暗号化と復号の両方に単一の256ビット鍵を使用します。その処理速度と計算効率の高さから、保存データや転送中データなど大容量データの暗号化に適した方式となっています。NISTはAESを連邦政府の暗号化標準に選定しており、現在も政府機関や規制業界における暗号モジュール認証の基準であるFIPS 140-3で必須とされているアルゴリズムです。

2. 公開鍵暗号方式は、AES-256では解決できない鍵配布の問題を解決する

暗号化されていない経路でAES-256の鍵を送ることはできません。公開鍵暗号方式(非対称暗号方式とも呼ばれます)はこの課題を解決します。一方が相手の公開鍵を使ってAESセッション鍵を暗号化し、対応する秘密鍵を持つ相手だけがそれを復号できる仕組みです。これはTLSがデータ送信前に安全な接続を確立する際の基本原理でもあります。

3. 2種類の暗号方式は独立してではなく、連携して機能する

実際の運用では、公開鍵暗号方式がハンドシェイク(本人認証と対称鍵の交換)を担当し、その後実際のデータ転送はAES-256が引き継ぎます。このハイブリッド方式によって、非対称暗号のセキュリティ面の強みと、対称暗号のパフォーマンス面の強みの両方を活かすことができます。

4. 暗号化の強度は鍵管理の強度で決まる

鍵管理が脆弱であれば、AES-256を使っていても安全なシステムとは言えません。暗号鍵が暗号化データと同じサーバーに保存されていれば、1回の侵害で両方が漏洩してしまいます。CMMCの審査官は、暗号化の有無だけでなく、鍵の生成・保管・ローテーション・廃棄のプロセスまで精査します。鍵を誰が所有し、誰が管理しているかが、実質的なセキュリティ境界を決定づけるのです。

5. 真の差別化要因はアルゴリズムそのものではなく、顧客が鍵を保有しているかどうか

多くのエンタープライズ向けプラットフォームはAES-256を採用しています。差がつくのは、鍵を誰が管理しているかという点です。顧客が暗号鍵を保有していれば、たとえ法的な要求があってもベンダー側は技術的にデータを復号できません。この違いは、CMMCレベル3、FedRAMP High、そしてSchrems II判決後のGDPR要件において非常に重い意味を持ちます。

AES-256にできること、できないこと

AES-256は対称ブロック暗号です。平文を256ビット鍵で14ラウンドの置換・転置・混合処理にかけ、その鍵なしでは計算量的に解読が事実上不可能な暗号文を生成します。復号にも同じ鍵を使用します。

高速で実績も豊富であり、NSAが機密情報の保護に承認しているアルゴリズムでもあります。現行の連邦政府暗号モジュール標準であるFIPS 140-3は、保存データの暗号化にAESを要求しています。主要なコンプライアンスフレームワークはすべてこのアルゴリズムを指定しています。

しかしAES-256には構造的な限界が1つあります。それは、両当事者が同じ鍵を持つ必要があるという点です。自分だけがアクセスする自社サーバー上のデータを暗号化する分にはこれで問題ありません。しかし他者と暗号化データをやり取りする必要が生じた瞬間、鍵配布の問題に直面します。相手に鍵を渡す際、転送途中で漏洩させずにどう届けるか、という課題です。

そこで公開鍵暗号方式の出番となります。

公開鍵暗号方式の仕組み

公開鍵暗号方式は、数学的に関連付けられた鍵のペアを使用します。公開鍵は誰でも自由に入手できる形で配布されます。一方、秘密鍵は所有者だけが保持する非公開の鍵です。公開鍵で暗号化されたデータは、対応する秘密鍵でしか復号できません。

これにより鍵配布の問題が解決します。取引先に機密性の高い鍵を送りたい場合、相手の公開鍵を使って暗号化すればよいのです。復号できるのは、対応する秘密鍵を持つ相手だけです。公開鍵は保護されていない経路でやり取りしても問題ありません。仮に攻撃者がそれを傍受しても、何の役にも立たないからです。

RSAアルゴリズムは、公開鍵暗号方式の実装として最も広く普及しています。これは非常に大きな数の素因数分解が計算量的に極めて困難であるという数学的性質に基づいており、現在使用されている鍵長では、既存の技術で解読することは事実上不可能とされています。

公開鍵暗号方式はデジタル署名も可能にします。送信者はメッセージのハッシュ値を自分の秘密鍵で暗号化します。受信者は送信者の公開鍵を使ってこの署名を検証でき、送信者の身元と、メッセージが転送中に改ざんされていないことの両方を確認できます。これはTLS証明書の検証、コード署名、S/MIMEによるメール認証の基盤となっている仕組みです。

実際の運用における両者の連携

ブラウザがHTTPSサイトに接続するたびに、次のような手順が実行されています。

1. サーバーが、信頼された認証局(CA)によって署名され、公開鍵を含むデジタル証明書を提示します。
2. クライアントがその証明書を検証し、サーバーの公開鍵を使って共有対称鍵を安全に取り決めます。
3. それ以降、そのセッションにおける全データはAESで暗号化されます。高速かつ効率的で、当事者2者だけが保持する鍵によって保護されます。

これがDiffie-Hellman鍵交換であり、その派生形は現在使われているほぼすべての安全な通信プロトコル—TLS、IPsec、SSH、S/MIME—の基盤となっています。公開鍵暗号方式が認証と鍵交換を担い、AES-256がデータそのものを暗号化するのです。

この役割分担が行われる理由はパフォーマンスにあります。非対称暗号は計算コストが高く、大容量ファイルや継続的なデータストリームの暗号化には現実的ではありません。AES-256は大量データの暗号化を桁違いに高速に処理できます。このハイブリッドモデルによって、両方式のセキュリティ上の利点を同時に得られるのです。

鍵管理がコンプライアンス上の課題になる理由

暗号化が「鍵交換」と「データ暗号化」という2つのレイヤーで成り立っていることを理解すると、コンプライアンスフレームワークが単に「AES-256を使っていますか?」とは尋ねない理由が見えてきます。実際に問われるのは、誰が鍵を管理しているか、どのように保管されているか、どのようにローテーションされているか、そして廃棄時にどう処理されるか、という点です。

CMMC 2.0の管理策SC.L2-3.13.8およびSC.L2-3.13.16では、転送中および保存中のCUI(管理対象非機密情報)を、FIPS認証済みモジュールを用いて暗号学的に保護することが求められています。CMMCの審査官は、使用しているアルゴリズムだけでなく、システムセキュリティ計画(SSP)に記載された鍵管理に関する文書まで精査します。CUIをAES-256で暗号化していても、暗号鍵を同じサーバー上の設定ファイルに保存しているようなシステムは安全とは言えず、審査を通過することはできません。

同じ論理がFedRAMPやHIPAAにも当てはまります。HIPAAの侵害通知セーフハーバーが適用されるのは、PHI(保護対象保健情報)が暗号化されており、かつ暗号鍵が安全に保たれていた場合のみです。クラウドプロバイダーが暗号鍵を保持している場合、そのプロバイダーが侵害を受けたり、法的命令の対象になったりすれば、AES-256を導入していてもデータが露出する可能性があります。

だからこそ、顧客が暗号鍵を保有することは単なる付加機能ではありません。規制業界の組織にとって、それはコンプライアンス上の必須条件なのです。

本当に堅牢な暗号化アーキテクチャとは何か

プラットフォームの暗号化に関する主張を評価する際は、「保存データはAES-256、転送中はTLS」という表面的な説明にとどまらず、その先を見る必要があります。本質的に問うべき質問は次の通りです。

鍵は誰が所有しているか? プロバイダーが鍵を管理している場合、ベンダーは顧客のデータを復号できる状態にあります。一方、顧客が鍵を保有していれば、契約上だけでなく技術的にもベンダーは復号できません。政府からベンダーに召喚状が届いても、顧客が鍵を保有していれば、ベンダー側には提出できるものが何もないのです。

そのプラットフォームはどの暗号モジュール認証を取得しているか? FIPS 140-2はすでにFIPS 140-3に置き換えられています。いまだにFIPS 140-2認証のみを謳っているプラットフォームは、より高い機密度のCUIやPHIを扱うシステムに求められる現行の連邦政府要件を満たしていない可能性があります。

鍵交換レイヤーは保護されているか? TLS 1.0や1.1には既知の脆弱性が存在します。NISTの現行ガイドラインでは、TLS 1.2を最低基準とし、TLS 1.3を推奨としています。最低限のTLSバージョンを強制していないプラットフォームは、たとえAES-256がデータ自体を保護していても、鍵交換レイヤーが露出したままになります。

すべてのチャネルで一貫して暗号化が適用されているか? ファイル共有は暗号化していてもメールは平文で送信していたり、アップロードには暗号化を適用していてもAPI通信には適用していなかったりするプラットフォームには、使用しているアルゴリズムに関係なく、実質的なリスクとなる隙間が存在します。

Kiteworksが暗号化スタック全体で実現していること

Kiteworksは、セキュアメール、セキュアファイル共有、マネージドファイル転送、SFTP、セキュアWebフォームなど、すべてのチャネルにおいて保存データにAES-256暗号化、転送中データにTLS 1.2(TLS 1.3の強制適用も可能)を実装しています。このプラットフォームの暗号モジュールは、旧規格のFIPS 140-2ではなく、現行標準であるFIPS 140-3 Level 1認証を取得しています。

Kiteworksは二重暗号化を採用しており、データはファイルレベルとディスクレベルの両方で暗号化されます。メールはEmail Protection Gatewayを通じて自動的に暗号化・復号され、受信者は追加のソフトウェアやトレーニングなしに普段使っているメールクライアントでそのまま利用できます。すべてのファイル転送には、MD5ハッシュによるデジタルフィンガープリントを用いた完全性チェックが含まれています。

鍵の所有権について:Kiteworksの顧客は自らの暗号鍵を保有します。Kiteworksが鍵を保持することは一切なく、顧客データの提出を強制されることもありません。技術的に復号自体が不可能だからです。このアーキテクチャは、鍵の管理主体が暗号化の実効性を左右する重要な局面—CMMCレベル3、FedRAMP High、Schrems II判決後のGDPRデータ主権要件—に直接対応するものです。

さらに高度な鍵保護を必要とする組織向けに、Kiteworksはタレス(Thales)およびAWS Key Management Serviceのハードウェアセキュリティモジュール(HSM)と連携しています。これは、サーバーが完全に侵害された場合でも鍵の抽出を防ぐ、耐タンパー性を備えたハードウェアです。

その結果として実現されているのは、単なるアルゴリズムではなく、暗号化アーキテクチャそのものが規制業界向けに設計されたプラットフォームです。KiteworksはCMMCレベル2要件の約90%を標準機能だけで満たし、FedRAMP Moderate認証を取得済みで、High Ready(High認証取得準備完了)のステータスも有しています。

貴社固有のコンプライアンス要件に対してKiteworksがどのように暗号化を実現するかご覧いただくには、カスタムデモをご予約ください。