AES-256暗号化がCMMCコンプライアンスを支援する方法

サイバーセキュリティ成熟度モデル認証（CMMC）2.0の取得を目指す防衛請負業者には、根本的な要件があります。それは、連邦暗号化規格に準拠した暗号化で制御されていない分類情報（CUI）を保護することです。AES-256暗号化は、FIPS認証済み暗号モジュールを通じて実装される場合、この要件を満たしますが、暗号化アルゴリズム単体ではコンプライアンスを保証しません。CMMC評価者は、暗号化が存在するかどうかだけでなく、適切に実装されているか、妥当性が検証されているか、そして確かな鍵管理の実践によって支えられているかも確認します。

防衛産業基盤（DIB）のほとんどの組織は、NIST SP 800-171の110のセキュリティ管理策すべてを組み込んだCMMCレベル2認証を目指します。これらの管理策のいくつかは、CUIの保存時および転送時の暗号化による保護を明示的に要求しています。AES-256暗号化がこれらの具体的な要件にどのように対応しているか、そして実装上のギャップがどこで発生しやすいかを理解することは、認証の取得と維持に不可欠です。

本ガイドでは、CMMCレベル2における暗号化要件を解説し、AES-256が適切に実装された場合に連邦規格を満たす理由、そしてCUIがクラウドインフラ上に存在する場合の暗号鍵管理という重要な課題について説明します。

主なポイント

1. CMMCレベル2では、CUIの保存時および転送時の保護にFIPS認証済み暗号化が必要であり、NIST SP 800-171管理策SC.L2-3.13.8およびSC.L2-3.13.16で具体的な要件が定義されています。
2. 防衛請負業者は、単にFIPS承認アルゴリズムを使用するのではなく、FIPS認証済み暗号モジュールを使用しなければなりません。FIPS 140-3認証は現行の規格であり、将来を見据えたコンプライアンスを示します。
3. AES-256暗号化は、認証済みモジュール内で実装され、CUIが存在するすべてのシステムや通信チャネルに一貫して適用されている場合、CMMCの暗号化要件を満たします。
4. CUIがFedRAMP認証済みクラウドインフラ上にある場合、暗号鍵の所有モデルがCMMCコンプライアンス体制に直接影響します。顧客所有の鍵（自社のみが鍵にアクセスできる場合）は、顧客管理鍵（クラウドプロバイダーがアクセス権を保持する場合）と比べて、明確な管理境界を提供します。
5. 暗号鍵管理の実践はCMMC評価時に厳しく精査され、鍵の生成、保管、ローテーション、破棄手順の文書化がシステムセキュリティ計画（SSP）に含まれている必要があります。

認証レベル別CMMC暗号化要件

CMMC 2.0は、保護対象情報の機密性に応じて異なる要件を持つ3つの認証レベルを定めています。レベル2はCUIを取り扱う組織に適用され、防衛産業基盤の多くの請負業者が目指す認証階層です。

CMMCレベル1は、連邦契約情報（FCI）のみを取り扱う組織を対象とし、17の基本的な保護策が含まれます。これらの基本管理策には明示的な暗号化要件は含まれていませんが、機密データの保護には暗号化が推奨されます。

CMMCレベル2は、NIST SP 800-171リビジョン2の110の管理策すべてを組み込み、暗号化による保護のための具体的な要件も含まれています。システムおよび通信の保護（SC）管理策群が主な暗号化義務を担います。SC.L2-3.13.8管理策はCUIの転送時の暗号化機構を、SC.L2-3.13.16管理策はCUIの保存時の保護を要求しています。これらの管理策はAES-256を名指ししているわけではありませんが、FIPS認証済み暗号モジュールを用いた暗号化の実装を求めています。

CMMCレベル3は、最も機密性の高いCUIを取り扱う組織に適用され、NIST SP 800-172の管理策が追加されます。これらの強化要件には、より厳格な鍵管理手順や、より頻繁な暗号化評価、高度な持続的標的型攻撃への追加対策などが含まれる場合があります。レベル3を目指す組織は、暗号化アーキテクチャや鍵管理の実践について、より厳しい審査を受けることを想定すべきです。

なぜAES-256がCMMCレベル2基準を満たすのか

256ビット鍵のAdvanced Encryption Standard（AES-256）は、米国国立標準技術研究所（NIST）によって、機密および非機密の連邦情報の保護に承認されています。この承認により、AES-256はCMMCコンプライアンスに最適な選択肢となりますが、実装が評価要件を本当に満たしているかどうかを左右する重要な違いがあります。

CMMC評価者は、FIPS認証済み暗号モジュールを通じて暗号化が実装されているかを確認し、単にFIPS承認アルゴリズムが使われているだけでは不十分です。組織が非認証のソフトウェアライブラリでAES-256暗号化を実装した場合、正しいアルゴリズムを使っていてもCMMC評価に不合格となる可能性があります。暗号モジュール自体（ソフトウェア、ファームウェア、ハードウェア問わず）が有効なFIPS 140認証を保持している必要があります。

連邦政府は、暗号モジュールの認証規格をFIPS 140-2からFIPS 140-3へと移行しています。FIPS 140-2認証は有効期限まで有効ですが、新規認証はFIPS 140-3で発行されています。暗号化ソリューションを選定する際は、現行の連邦暗号化要件に合致し、契約期間中に失効するリスクを避けるためにも、FIPS 140-3認証済み製品を優先すべきです。

256ビット鍵長は、CUIを保護するのに適切なセキュリティマージンを提供します。AES-128もNISTの承認を受けていますが、AES-256は将来の暗号解析技術の進歩に対してより強い耐性を持ち、機密性の高い防衛情報保護におけるDoDの推奨とも一致します。

CMMCコンプライアンスのためのCUI保存時の暗号化

NIST SP 800-171管理策SC.L2-3.13.16は、組織がCUIの保存時の機密性を保護することを要求しています。この要件は、CUIが保存されるすべての場所（ファイルサーバー、データベース、エンドポイント、バックアップシステム、メールアーカイブ、クラウドストレージ）に適用されます。

防衛請負業者は、CUIが存在するすべての場所を特定し、各リポジトリが暗号化で保護されていることを確認しなければなりません。暗号化が必要となる一般的な保存シナリオには、ファイル共有に保存された設計図や技術仕様書、文書管理システム内の契約書ややり取り、政府機関やサブコントラクターとやり取りしたCUIを含むメールアーカイブ、制御技術情報を含むデータベース記録、バックアップテープや災害復旧システム、CUIにアクセスする従業員が使用するノートパソコンなどのエンドポイントデバイスが含まれます。

保存時の暗号化は、複数のレベルで実装できます。フルディスク暗号化はストレージボリューム全体を保護し、ファイルレベル暗号化は保存場所や移動先に関係なく個々のファイルを保護します。データベース暗号化は、データベース管理システム内の構造化データを保護します。多くの組織は、ボリュームレベルとファイルレベルの保護を組み合わせた多層防御を実施しています。

暗号化の実装には、FIPS認証済みモジュールを使用しなければなりません。自己暗号化ドライブ、OSの暗号化機能、サードパーティの暗号化ソリューションも、CMMC要件を満たすにはFIPS 140認証が必要です。各暗号化製品のFIPS認証番号を環境ごとに文書化しておくべきです。

CMMCコンプライアンスのためのCUI転送時の暗号化

NIST SP 800-171管理策SC.L2-3.13.8は、CUIの転送時に不正な開示を防ぐ暗号化機構を要求しています。この要件は、CUIを転送するすべての通信チャネル（ネットワーク接続、メール、ファイル転送、API通信）に適用されます。

トランスポート層セキュリティ（TLS）は、ほとんどの転送暗号化の基盤です。TLS 1.2およびTLS 1.3は、AES-256によるバルク暗号化をサポートしており、CUI保護に必要な暗号強度要件を満たします。システムはTLS 1.2以上を必須とし、既知の脆弱性を含む古いプロトコルバージョンは無効化すべきです。TLS 1.3はTLS 1.2よりもセキュリティとパフォーマンスが向上しており、CUI転送時の保護における現行のベストプラクティスです。

メールは、防衛請負業者にとって特に課題となります。標準的なメール転送では、メッセージ内容がエンドツーエンドで暗号化されず、メールサーバーを経由する際にCUIが露出します。メッセージ内容自体にAES-256暗号化を適用するセキュアメールソリューション（単なる転送チャネルの暗号化ではなく）が、CUIを含むメールに対してCMMCが求める保護を実現します。

ファイル転送操作も同様の注意が必要です。セキュアファイル転送プロトコル（SFTP）やFTPSは暗号化転送をサポートしますが、FIPS認証済み暗号モジュールが使われていることを確認しなければなりません。防衛請負業者、サブコントラクター、政府機関間の大容量ファイル転送はCUIを含むことが多く、一貫した暗号化保護が必要です。

システム間のAPI通信も転送時暗号化要件の対象です。政府システムとの連携や自動化インターフェースを通じてCUIをやり取りする場合、これらの接続が適切に暗号化されたチャネルを使用していることを確認する必要があります。

FedRAMP認証済みインフラにおける暗号鍵管理

多くの防衛請負業者は、CUIの保存や処理にFedRAMP認証済みクラウドサービスを活用しています。FedRAMP認証はクラウドサービスプロバイダーが連邦セキュリティ要件を満たしていることを示しますが、請負業者自身のCMMC義務を自動的に満たすものではありません。CUIへのアクセスを適切に管理できていることを証明する責任は、請負業者側にあります。

暗号鍵管理は、CUIがどこに保存されていても、実際に誰が暗号化されたCUIにアクセスできるかを決定します。クラウド上のデータに対する鍵管理モデルには3つあり、それぞれCMMCコンプライアンスへの影響が異なります。

プロバイダー管理鍵は最も単純な実装で、クラウドプロバイダーが暗号鍵を生成・保管・管理します。データは暗号化されますが、プロバイダーは技術的に復号可能です。このモデルは、CMMC評価時に請負業者がCUIアクセスを十分に管理できているか重大な疑問を招きます。

顧客管理鍵（BYOKとも呼ばれる）は、請負業者が鍵の生成やライフサイクルの意思決定を行えますが、鍵自体はクラウドプロバイダーの鍵管理サービスにアップロード・保管されます。プロバイダーはこれらの鍵に技術的にアクセスでき、CLOUD法やその他の法的手続きにより、顧客に通知せずにデータを復号することが可能です。CMMCの観点では、このモデルはCUIアクセスの管理主体が曖昧になります。

顧客所有鍵（HYOK）は、真の分離を実現します。請負業者が自社の鍵管理システムやハードウェアセキュリティモジュール（HSM）で暗号鍵を独占的に管理し、クラウドプロバイダーは鍵を一切保持しません。たとえプロバイダーが政府から召喚状を受け取っても、鍵がないためCUIを復号できません。このモデルは、CMMC評価者の審査を満たす明確な管理境界を確立します。

FedRAMP認証済みであることはクラウドプロバイダーのセキュリティ体制を示しますが、請負業者の鍵管理アプローチを決定するものではありません。CMMC評価者は、請負業者がCUIへのアクセスをどのように管理しているかを確認します。請負業者のみがCUIを復号できる顧客所有暗号鍵は、その管理を証明する決定的な証拠となります。顧客管理鍵は、名称こそ安心感を与えますが、クラウドプロバイダーが技術的にアクセスできるため、コンプライアンス説明を複雑にします。

よくあるCMMC暗号化の不備

CMMC評価では、暗号化に関連する不備が頻繁に指摘され、認証取得を妨げています。これらの一般的なギャップを理解することで、組織はより効果的に準備できます。

非認証暗号モジュールの使用は、よく見られる指摘事項です。組織がFIPS 140認証を受けていないライブラリや製品でAES-256暗号化を実装している場合、アルゴリズムが正しくても認証済みモジュール要件を満たせません。

暗号化の適用範囲が不完全な場合、CUIが存在するすべての場所で暗号化されていないギャップが生じます。メールシステム、コラボレーションプラットフォーム、エンドポイントデバイスは、コアファイルストレージが保護されていても暗号化されていないことが多いです。

システムセキュリティ計画（SSP）の文書化が不十分だと、技術的な管理策が適切に実装されていても評価で指摘されます。SSPには、暗号化方式、FIPS認証番号、鍵管理手順、暗号化管理策が適用されるシステムを文書化する必要があります。

クラウドプロバイダーの暗号化に依存し、鍵管理の意味合いを理解していない場合、CUIアクセス管理が曖昧になります。評価者は、最終的に請負業者とクラウドプロバイダーのどちらが暗号化CUIへのアクセスを管理しているかを確認します。

FIPS認証証明書の有効期限切れは、契約期間中に証明書が失効した場合、コンプライアンスリスクとなります。組織は、環境内のすべての暗号化製品について証明書の有効期限を管理すべきです。

データ移動時の暗号化ギャップは、CUIが保存時や外部転送時には保護されていても、内部システム間の移動時に暗号化されていない場合に発生します。評価者は、ストレージや外部通信だけでなく、データフロー全体を確認します。

Kiteworksの堅牢な暗号化機能でCUIを保護

CMMCレベル2認証では、防衛請負業者がCUIを保存時・転送時ともにFIPS認証済み暗号化で保護し、鍵管理の実践を文書化していることを証明する必要があります。AES-256暗号化は、適切に認証されたモジュールで実装され、CUIを取り扱うすべてのシステムで一貫して適用されている場合、暗号化要件を満たします。

鍵の所有モデルの選択は、特にCUIがクラウドインフラ上にある場合、CMMCコンプライアンス体制に大きな影響を与えます。顧客所有の暗号鍵（自社のみが鍵を保持し、クラウドプロバイダーもアクセスできない場合）は、CUIアクセスの管理について評価者の審査を満たし、曖昧さを排除する明確な管理境界を確立します。

Kiteworksは、CMMCレベル2要件の約90%を標準機能でサポートしています。これには、現行の連邦認証規格であるFIPS 140-3認証済み暗号化（旧FIPS 140-2ではなく）によるCUIの保存時・転送時の保護が含まれます。プラットフォームはプライベートデータネットワークであり、TLS 1.3暗号化（現時点で最強のトランスポート層プロトコル）により、メール、ファイル共有、マネージドファイル転送、ウェブフォームなど、データの移動を保護します。

CUIを含むメール通信については、Kiteworksのメール保護ゲートウェイが送信メールに自動的にAES-256暗号化を適用し、エンドユーザーの判断に依存せず、防衛サプライチェーン全体で一貫した保護を実現します。

Kiteworksの顧客所有鍵アーキテクチャにより、防衛請負業者はFedRAMP認証済みインフラ上であっても暗号鍵を独占的に所有できます。クラウドプロバイダーは復号に必要な鍵を一切保持しないため、CUIアクセス管理の明確な証拠をCMMC評価者に提供できます。

最高レベルの鍵保護が必要な組織は、Kiteworksをハードウェアセキュリティモジュール（HSM）と統合し、FIPS 140-3認証要件を満たす耐タンパー性の鍵保管を実現できます。

KiteworksがFIPS 140-3認証済みの顧客所有暗号鍵でCMMC 2.0コンプライアンスをどのように支援するかについては、防衛請負環境に合わせたカスタムデモをご予約ください。