暗号化の重要性と AWS による支援

本ブログは 2025 年 2 月 12 日に公開された AWS Blog “The importance of encryption and how AWS can help” を翻訳したものです。オリジナルの記事は、2020 年 6 月 11 日の初回公開以降にリリースされた新しいサービスや機能を含めて再公開されました。

暗号化は、多層防御セキュリティ戦略の重要な要素であり、複数の防御メカニズムを活用してワークロード、データ、資産を保護します。組織が顧客との信頼を築きながらイノベーションを推進するには、重要なコンプライアンス要件を満たし、データセキュリティを向上させる必要があります。暗号化を正しく使用すると、不正アクセスに対する保護層が追加され、データ保護の強化、法規制や業界標準への準拠、通信セキュリティの向上に役立ちます。

暗号化の仕組みと重要性

暗号化とは、アルゴリズムと鍵を使用してデータを読み取り不可能なデータ (暗号文) に変換し、正しい鍵がある場合にのみ再び読み取り可能にする仕組みです。例えば、「Hello World!」のような単純なフレーズは、暗号化すると「1c28df2b595b4e30b7b07500963dc7c」のようになります。暗号化アルゴリズムにはいくつかの種類があり、それぞれ異なる種類の鍵を使用します。強力な暗号化アルゴリズムは、数学的特性を利用して、正しい鍵なしには実質的にどのような計算能力を使っても復号できない暗号文を生成します。そのため、鍵の保護と管理があらゆる暗号化ソリューションの要となります。

セキュリティ戦略を支える暗号化

効果的なセキュリティ戦略は、厳格なアクセス制御と、データにアクセスする人やシステムに必要な最小権限を定義する継続的な取り組みから始まります。AWS クラウドを使用する場合、責任共有モデルを採用することになります。お客様は自身のアクセス制御ポリシーを管理する責任があります。暗号化は、アクセス制御だけでは防ぎきれない弱点を補うことができるため、多層防御戦略の重要な要素です。アクセス制御メカニズムが失敗し、ディスク上の生データやネットワーク上を流れるデータへのアクセスを許可してしまった場合はどうなるでしょうか？データが強力な鍵で暗号化されていれば、復号鍵がデータと同じシステム上にない限り、悪意のある攻撃者がデータを復号することは現実的に不可能です。

これがいかに不可能かを確認するために、256 ビット鍵を使用した Advanced Encryption Standard (AES-256) を考えてみましょう。これは、業界で広く採用され、米国政府 (NIST) をはじめ各国で標準として承認された、データ暗号化のための最も強力なアルゴリズムです。AES-256 は、AWS でデータを暗号化するために使用している技術で、Amazon Simple Storage Service (Amazon S3) のサーバー側の暗号化などで使われています。現在の (および予見可能な将来の) コンピューティング技術を使用して解読するには、少なくとも 1 兆年かかります。現在の研究では、将来量子コンピューティングが利用可能になっても、AES-256 暗号化を解読するのにかかる時間を十分に短縮することはできないと考えられています。

しかし、誤ってアクセス権限を広く設定しすぎてしまった場合はどうでしょうか？適切に設計された暗号化と鍵管理システムは、復号鍵へのアクセスとデータへのアクセスを分離するため、これが問題になることを防ぐこともできます。

暗号化ソリューションの要件

暗号化ソリューションを最大限に活用するには、2 つのことを考慮する必要があります。

保管中の鍵の保護: 暗号鍵を使用するシステムは、鍵がシステム外で使用されることがないように保護されていますか？また、暗号化アルゴリズムが正しく実装され、正しい鍵がなければ復号できない強固な暗号文が生成されていますか？
独立した鍵管理: 暗号鍵へのアクセス制御は、データへのアクセス制御から分離されていますか？

これらの要件を満たすために AWS に導入できるサードパーティソリューションがあります。ただし、これらのシステムは大規模に運用するのが難しく、コストがかかる場合があります。AWS は、暗号化と鍵管理を簡素化するためのさまざまなオプションを提供しています。

保管中の鍵の保護

サードパーティの鍵管理ソリューションを使用する場合、平文の暗号鍵が漏洩してソリューション外で使用されるリスクを評価することが難しい場合があります。鍵はどこかに保存する必要があり、それらのストレージシステムが不正アクセスからどのように保護されているかをすべて把握したり監査したりできるとは限りません。鍵管理ソリューションは技術的に複雑なうえ、パフォーマンスや可用性を損なわずに運用する必要があるため、選択と運用には難しいトレードオフが伴います。鍵のセキュリティを最大化するためのベストプラクティスは、ハードウェアセキュリティモジュール (HSM) を使用することです。HSM は専用のコンピューティングデバイスで、暗号鍵がデバイス外に流出して攻撃者に悪用されることを防ぐための複数のセキュリティ制御が組み込まれています。

モダンな HSM におけるそのような制御の 1 つが改ざん検知応答です。これは、デバイスが平文の鍵への不正アクセスの物理的または論理的な試みを検出し、攻撃が成功する前に鍵を破棄するものです。AWS データセンターにお客様独自のハードウェアを設置して運用することはできないため、AWS はお客様の鍵を保護するために改ざん検知応答を備えた HSM を使用する 2 つのサービスを提供しています。1 つはAWS Key Management Service (AWS KMS) でお客様に代わって AWS が HSM のフリートを管理します。もう 1 つは、AWS CloudHSM でお客様が独自の HSM を管理する機能を提供します。どちらのサービスも、鍵を新規作成することも、オンプレミスシステムから既存の鍵をインポートすることも可能です。

AWS KMS または AWS CloudHSM の鍵は、データの直接暗号化に使用できるほか、アプリケーションがデータ暗号化に使用する鍵 (データキー) を保護するためにも使用できます。暗号鍵を暗号化する技術はエンベロープ暗号化と呼ばれ、毎回データを HSM に送信して暗号処理するのではなく、平文のお客様データが存在するコンピュータ上で暗号化と復号を行うことができます。非常に大きなデータセット (データベースなど) の場合、読み取り/書き込み操作のたびにデータセットと HSM の間でギガバイトのデータを移動することは現実的ではありません。代わりに、エンベロープ暗号化により、必要なときにデータキーをアプリケーションに払い出すことができます。HSM 内に保存された暗号鍵は、データキーのコピーを暗号化するために使用され、アプリケーションはその鍵で暗号化されたデータと一緒に暗号化された鍵を保存できます。アプリケーションがデータを暗号化すると、コピーされた平文のデータキーはメモリから削除できます。データを復号する唯一の方法は、わずか数百バイトのサイズの暗号化されたデータキーを HSM に送り返して復号することです。

エンベロープ暗号化のプロセスは、パフォーマンスの低下を最小限に抑えるために、お客様に代わってデータが暗号化される AWS サービス (サーバー側の暗号化) で使用されています。独自のアプリケーションでデータを暗号化する場合 (クライアント側の暗号化)、AWS KMS または AWS CloudHSM でエンベロープ暗号化を使用することをお勧めします。両方のサービスは、アプリケーションコードに暗号化機能を追加し、各サービスの暗号化機能を使用するためのクライアントライブラリと SDK を提供しています。AWS Encryption SDK は、AWS で実行されているアプリケーションだけでなく、どこでも使用できるツールの例です。Amazon DynamoDB などのデータベースでデータを暗号化することをお客様にとってより簡単にするために、AWS は AWS Database Encryption SDK を開発しました。AWS Database Encryption SDK は、データベースでクライアント側の暗号化を使用できるようにするソフトウェアライブラリのセットで、データベースアイテムのレコードレベルの暗号化にも対応しています。現在、AWS Database Encryption SDK は Amazon DynamoDB の属性単位の暗号化をサポートしています。

暗号化アルゴリズムと HSM の実装を正しく行うことが重要であるため、HSM のすべてのベンダーは、信頼できる第三者による製品の検証を受ける必要があります。AWS KMS と AWS CloudHSM の両方の HSM は、暗号モジュールを評価するための標準である米国国立標準技術研究所 (NIST) の FIPS 140 プログラムに基づいて検証されています。これにより、ポートとインターフェース、認証メカニズム、物理的セキュリティと改ざん検知応答、運用環境、暗号鍵管理、電磁干渉/電磁両立性 (EMI/EMC) に関連する機能を含む、暗号モジュールの安全な設計と実装が検証されます。FIPS 140 レベル 3 で検証された暗号モジュールを使用した暗号化は、米国の FedRamp や HIPAA-HITECH、または国際的なペイメントカード業界標準 (PCI-DSS) などの他のセキュリティ関連のコンプライアンススキームの要件であることが多いです。

独立した鍵管理

AWS KMS と AWS CloudHSM はお客様に代わって平文の暗号鍵を保護できますが、どの暗号鍵をどのような条件で誰が使用できるかを決定するアクセス制御の管理は、お客様の責任です。AWS KMS を使用する利点の 1 つは、鍵のアクセス制御を定義するために使用するポリシー言語が、他のすべての AWS リソースへのアクセスを定義するために使用するものと同じであることです。ただし、言語が同じであっても、実際の認可制御は同じではないことに注意してください。データへのアクセス管理に使用するものとは異なる、鍵へのアクセス管理メカニズムが必要です。AWS KMS は、鍵の管理のみを行う管理者のセットと、基盤となる暗号化データへのアクセス管理のみを行う別の管理者のセットを割り当てることができるメカニズムを提供します。このような鍵管理の仕組みを採用することで、職務分離を実現し、意図しない復号権限の付与を防ぐことができます。さらに制御を分離するために、AWS CloudHSM は鍵へのアクセスを定義するための独立したポリシーメカニズムを提供しています。

2022 年に、AWS KMS は外部キーストア (XKS) のサポートを開始しました。これは、オンプレミスまたは任意の場所で運用する HSM に AWS KMS カスタマーマネージドキーを保存できる機能です。仕組みとしては、AWS KMS は暗号化と復号のリクエストをお客様の HSM に転送します。鍵マテリアルがお客様の HSM から外に出ることはありません。これにより、暗号鍵を AWS データセンター外で保存および使用する必要がある、一部の高度に規制されたワークロードのユースケースにも対応できます。ただし、XKS では責任共有モデルにおける責任範囲が大きく変わります。KMS キーの耐久性、スループット、レイテンシー、可用性についてはお客様が責任を負うことになります。その鍵が紛失または破壊された場合、データへのアクセスを永久に失う可能性があり、XKS 鍵が利用できなくなった場合、その XKS 鍵に依存する AWS 内のすべてのワークロードにアクセスできなくなります。

AWS では、鍵管理とデータ管理を分離する機能があっても、暗号鍵へのアクセスが正しく設定されていることを検証できます。AWS KMS は AWS CloudTrail と統合されているため、誰がどの鍵を、どのリソースに対して、いつ使用したかを監査できます。これにより、暗号化管理プロセスをきめ細かく可視化でき、通常はオンプレミスの監査メカニズムよりもはるかに詳細な情報を得られます。AWS CloudHSM からの監査イベントは、AWS で運用するサードパーティソリューションの監視とアラームを行う AWS サービスである Amazon CloudWatch に送信できます。

保管中のデータと転送中のデータの暗号化

お客様のデータを扱う AWS サービスは、システム間で送信されるデータ (転送中のデータ) と保管中のデータの両方を暗号化するオプションを提供しています。AWS KMS または AWS CloudHSM を使用した保管時の暗号化を提供する AWS サービスは、AES-256 を使用しています。これらのサービスはいずれも、平文の暗号鍵を保管時に保存しません。これは、FIPS 140 レベル 3 で検証された HSM を使用する AWS KMS と AWS CloudHSM が担う機能です。このアーキテクチャにより、鍵の不正使用リスクを最小限に抑えることができます。

転送中のデータの暗号化では、AWS サービスは Transport Layer Security (TLS) プロトコルを使用して、アプリケーションと AWS サービス間の通信を暗号化します。ほとんどの商用ソリューションは、TLS の実装に OpenSSL というオープンソースプロジェクトを使用しています。OpenSSL には約 50 万行のコードがあり、そのうち少なくとも 7 万行が TLS の実装に使用されています。コードベースは大規模で複雑なため、監査が困難です。さらに、OpenSSL にバグが見つかった場合、グローバルな開発者コミュニティは修正とテストを行うだけでなく、その修正自体が新たな欠陥を導入しないことも確認しなければなりません。

OpenSSL の TLS 実装に関するこれらの課題に対応するため、AWS は s2n (signal to noise の略) として知られる独自の TLS 実装を開発しました。AWS は 2015 年 6 月に s2n をリリースしました。s2n は小さく高速になるように設計されており、理解しやすく完全に監査可能なネットワーク暗号化を提供することを目標としています。Apache 2.0 ライセンスの下でリリースされ、GitHub でホスティングされています。

また、s2n は数学的論理を使用して安全性と正確性をテストする自動推論で分析できるように設計されています。形式手法として知られるこのプロセスにより、コードを変更するたびに s2n コードベースの正確性を検証しています。さらに、これらの数学的証明を自動化し、コードの新しいリリースでも望ましいセキュリティ特性が維持されていることを確認するために定期的に再実行しています。数学的証明による正確性の自動検証はセキュリティ業界で注目を集めている先進的な手法であり、AWS はミッションクリティカルなソフトウェア全般でこのアプローチを採用しています。

同様に、2022 年に AWS は s2n-quic をリリースしました。これは QUIC プロトコルの Rust によるオープンソース実装であり、AWS 暗号化オープンソースライブラリのセットに追加されました。QUIC はパフォーマンスを重視して設計された暗号化トランスポートプロトコルであり、HTTP/3 の基盤となっています。2021 年 5 月に批准された一連の IETF 標準で規定されています。Amazon CloudFront の HTTP/3 サポートは s2n-quic の上に構築されています。これは、パフォーマンスと効率性を重視しているためです。s2n-quic の詳細については、こちらの Security Blog の記事をご覧ください。

TLS を実装するには、暗号鍵とデジタル証明書が必要です。デジタル証明書は公開鍵の所有者を証明します。AWS Certificate Manager と AWS Private Certificate Authority を使用すると、TLS エンドポイントを提供するインフラストラクチャ全体でデジタル証明書の発行とローテーションを簡素化できます。両方のサービスは、AWS KMS と AWS CloudHSM の組み合わせを使用して、発行するデジタル証明書で使用される鍵を生成および保護します。

使用中のデータの暗号化

複数の組織が共同でトレーニングする機械学習モデルやその他のアプリケーションでアクティブに使用されているデータを保護するユースケースもあります。暗号コンピューティングは、暗号化されたデータに対して計算を実行できる技術のセットであり、機密データを公開せずに使用中のデータを保護する方法論です。

保険詐欺検出のための機械学習モデルを開発するために他の企業と協力する保険会社の例を考えてみましょう。モデルのトレーニングデータとして顧客に関する機密データを使用する必要があるかもしれませんが、顧客データを平文で他の企業と共有することは避けたいところです。暗号コンピューティングにより、組織は顧客に関する平文データを互いに、または AWS のようなクラウドプロバイダーに公開することなく、共同でモデルをトレーニングできます。暗号コンピューティングの詳細については、こちらの AWS Security Blog の記事をご覧ください。

現在、暗号コンピューティングは AWS Clean Rooms で実際に使用されています。AWS Clean Rooms は、企業とそのパートナーが互いの基盤となるデータを共有またはコピーすることなく、集合的なデータセットをより簡単かつ安全に分析およびコラボレーションできるようにするサービスです。AWS Clean Rooms には Cryptographic Computing for AWS Clean Rooms (C3R) という機能があり、AWS Clean Rooms のコラボレーションで処理されている間もデータを暗号的に保護します。

セキュアな通信におけるエンドツーエンド暗号化の役割

エンドツーエンド暗号化 (E2EE) は、2 者以上の間でセキュアな通信を行う方法であり、転送中の暗号化と保管中の暗号化を組み合わせて、不正アクセス、盗聴、改ざんからデータを保護します。復号は通信相手のみで行われ、その間のサービスプロバイダーでは行われません。すべての通話、メッセージ、ファイルは一意の秘密鍵で暗号化され、転送中も保護されたままです。権限のない第三者はデータを復号するために必要な秘密鍵を持っていないため、通信内容にアクセスできません。

AWS Wickr は、1 対 1 およびグループメッセージング、音声およびビデオ通話、ファイル共有、画面共有、位置情報共有を 256 ビット暗号化で保護するエンドツーエンド暗号化メッセージングおよびコラボレーションサービスです。Wickr では、各メッセージに一意の AES 秘密暗号鍵と、受信者との鍵交換をネゴシエートするための一意の楕円曲線ディフィー・ヘルマン (ECDH) 公開鍵が割り当てられます。テキスト、ファイル、音声、ビデオを含むメッセージコンテンツは、メッセージ固有の AES 鍵を使用して送信デバイス (例: iPhone) で暗号化されます。この鍵は ECDH 鍵交換メカニズムを使用して交換されるため、正当な受信者のみがメッセージを復号できます。

量子コンピューティングとポスト量子暗号

量子コンピューティングは、量子力学を使用して従来のコンピュータよりも高速に複雑な問題を解決する技術分野です。量子コンピュータは、重ね合わせや量子干渉などの量子力学的効果を利用することで、特定の種類の問題をより高速に解決できます。暗号化においては、これは公開鍵暗号方式などの従来の暗号化メカニズムに影響を与えます。公開鍵暗号方式は、転送中のデータの保護 (TLS) や、メッセージやファイルの整合性と真正性を検証するためのハッシュベースの署名の作成によく使用されます。量子コンピュータが十分な性能と安定性を持つようになれば、理論的には RSA、楕円曲線暗号 (ECC)、ディフィー・ヘルマン鍵合意方式などの公開鍵暗号アルゴリズムのセキュリティを危険にさらす可能性があります。現在の研究に基づくと、AES のような対称鍵アルゴリズムは量子コンピュータによるリスクは低いと考えられています。256 ビットの鍵長であれば、量子アルゴリズムによる暗号強度の低下を補うのに十分だからです。

AWS は、従来のアルゴリズムと併せてポスト量子アルゴリズムを利用できるオプションをお客様に提供しています。これは、従来の暗号化と、量子コンピュータの脅威に耐性を持つように設計された新しいポスト量子暗号 (PQC) アルゴリズムの両方を使用するハイブリッド方式によるものです。AWS は、AWS-LC (AWS のオープンソース FIPS-140-3 検証済み暗号ライブラリ) 内に ML-KEM (モジュール格子ベースの鍵カプセル化メカニズム) を実装し、PQC の展開をさらに推進しています。AWS-LC は AWS 全体で使用されるコア暗号ライブラリです。具体的には、AWS-LC は s2n-tls で使用されています。s2n-tls は HTTPS ベースのエンドポイントを持つ AWS サービス全体で使用される AWS のオープンソース TLS 実装です。

AWS は、AWS KMS、AWS Certificate Manager (ACM)、AWS Secrets Manager の TLS エンドポイントにポスト量子対応の s2n-tls を導入しました。これにより、AWS SDK でハイブリッドポスト量子 TLS を有効にしてこれらのサービスに接続するお客様は、ポスト量子暗号のメリットを享受できます。AWS Transfer Family も、ポスト量子ハイブリッド SFTP ファイル転送をサポートしています。より多くの AWS マネージドサービスエンドポイントを TLS 経由の PQC に移行する取り組みの詳細については、こちらの AWS Security Blog の記事をご覧ください。また、Amazon Science Blog で暗号研究と改善における Amazon と AWS の取り組みに関する情報もご覧いただけます。

Encrypt everything, everywhere

AWS は、Encrypt everything, everywhere (すべてを、どこでも暗号化) する機能をお客様に提供しています。AWS マネジメントコンソールで数回クリックするか、AWS API コールを使用するだけで、保管中、転送中、メモリ内のデータを暗号化できます。Amazon Simple Storage Service (Amazon S3) などのサービスは、デフォルトで新しいオブジェクトを暗号化し、暗号鍵をより細かく制御したい場合は、お客様が管理する AWS KMS キーの使用もサポートしています。重要なのは、AWS KMS がエンベロープ暗号化や高度にスケーラブルな鍵管理インフラストラクチャなどの技術を使用して、Amazon S3 や Amazon Elastic Block Store (Amazon EBS) などの AWS サービスが、アプリケーションのパフォーマンスへの影響を最小限に抑えながらデータを暗号化できるようにしていることです。

AWS は、ネットワークやデバイス間を移動するデータのパフォーマンスとセキュリティを継続的に改善しています。2024 年 6 月時点で、すべての AWS API エンドポイントは TLS 1.3 をサポートし、少なくとも TLS 1.2 以上を必要としています。TLS 1.3 を使用することで、接続リクエストごとに 1 回のネットワークラウンドトリップを削減して接続時間を短縮でき、現在利用可能な最新かつセキュアな暗号スイートのメリットを享受できます。

メモリ暗号化が必要な場合は、ARM ベースのカスタムビルトプロセッサファミリーである AWS Graviton を使用できます。AWS Graviton2、AWS Graviton3、AWS Graviton3E では、メモリ暗号化が常に有効になっています。暗号鍵はホストシステム内でセキュアに生成され、ホストシステムから外に出ることはなく、ホストが再起動または電源オフされると破棄されます。メモリ暗号化は他のインスタンスタイプでもサポートされています。詳細については、EC2 ドキュメントをご覧ください。

AWSのデジタル統制に関するお客様との約束の一環として、お客様が AWS クラウド内外で管理する暗号鍵を使用して、Encrypt everything, everywhere (すべてを、どこでも暗号化) できるよう、革新と投資を継続することをお約束します。

まとめ

AWS では、セキュリティが最優先事項です。AWS は、お客様がデータの使用・アクセス・保護を制御できるようにすることにコミットしています。クラウド上でもクラウド外でも機能する暗号化ツールを提供およびサポートすることで、データを保護し、環境全体でコンプライアンスを実現できるよう支援しています。AWS は、セキュリティをすべての取り組みの中核に置き、最高水準のセキュリティ技術でコスト効率よくデータを保護できるようにしています。

この記事についてご質問がある場合は、AWS KMS フォーラムまたは AWS CloudHSM フォーラムで新しいスレッドを開始するか、AWS サポートにお問い合わせください。

Amazon Web Services ブログ