データ暗号化に関する推奨事項

以下の Well-Architected フレームワーク セキュリティ チェックリストの推奨事項に対応します。

データが保護されていない場合、悪意を持って変更され、整合性と機密性が失われる可能性があります。

このガイドでは、データの暗号化と保護に関する推奨事項について説明します。 暗号化とは、暗号化アルゴリズムを使用してデータを読み取り不可能にし、キーでデータをロックするプロセスです。 暗号化された状態では、データを解読できません。 暗号化キーとペアになっているキーを使用することによってのみ暗号化を解除できます。

定義

主要な設計戦略

組織の規定または規制要件により、暗号化メカニズムが強制される場合があります。 たとえば、データは選択したリージョンのみに保持される必要があり、データのコピーはそのリージョンに保持されるという要件がある場合があります。

これらの要件は、多くの場合は最低ラインです。 より高いレベルの保護を目指します。 外部ユーザー データであろうと従業員データであろうと、機密データの漏えいや改ざんを防止する責任があります。

暗号化メカニズムでは、多くの場合、次の 3 つのステージでデータをセキュリティで保護する必要があります。

• 保存データとは、ストレージ オブジェクトに保持されるすべての情報です。

  保存データをセキュリティで保護する例としては、BitLocker を使用してディスク上のストレージに保存されているデータを暗号化することが挙げられます。

• 転送中のデータとは、コンポーネント、場所、またはプログラム間で転送される情報です。

  転送中のデータをセキュリティで保護する例としては、パブリックおよびプライベート ネットワークを介して移動するパケットがセキュリティで保護されるように、TLS を使用してデータを暗号することが挙げられます。

• 使用中のデータとは、メモリ内でアクティブに処理されているデータです。

  使用中のデータをセキュリティで保護する例としては、処理中のデータを保護するために、機密コンピューティングを使用して暗号化することが挙げられます。

上記の選択肢は相互に排他的ではありません。 これらは、ソリューション全体のコンテキストで一緒に使用されることがよくあります。 1 つのステージが補完的な制御として機能する場合があります。 たとえば、メモリからデータを読み取るときに、改ざんを防ぐためにデータを分離する必要がある場合があります。

暗号化の要件を決定する

データを目的と秘密度レベル別に分類し、暗号化する必要があるデータを決定します。 暗号化する必要があるデータについては、必要な保護レベルを決定します。 転送中のすべてのデータにエンドツーエンドの TLS 暗号化が必要ですか? 保存データの場合、Azure のどの機能が要件を満たせますか? すべてのストレージ ポイントでデータを二重に暗号化する必要がありますか? 情報保護をどのように実装しますか?

大きなトレードオフがあるため、暗号化に関する決定のバランスを取ることが重要です。

トレードオフ: 暗号化ホップごとにパフォーマンスの待ち時間が発生する可能性があります。 トラブルシューティングと可観測性に関連して、運用上の複雑さが発生する可能性があります。 復旧が困難な場合があります。

これらのトレードオフの範囲を設定します。 機密として分類されるデータに対するトレードオフを予測します。 要件によってトレードオフが決まる場合もあります。たとえば、特定の種類のデータを暗号化しますが、特定のしきい値内のものは保存する必要がある場合などがあります。

技術的な制限、投資額、またはその他の理由により、暗号化が不可能な場合があります。 これらの理由が明確かつ有効であり、文書化されていることを確認します。

強力な暗号化メカニズムだけが唯一の防御手段であってはなりません。 データ盗難防止プロセス、適切なテスト方法、異常検出を実装します。

分類については、「データ分類に関する推奨事項」を参照してください。

ネイティブ暗号化メカニズムを使用する

ほとんどの Azure サービスでは、基本レベルの暗号化が提供されます。 プラットフォーム提供の暗号化オプションを確認します。

独自の機能を開発するためにプラットフォームの機能を無効にしないことを強くお勧めします。 プラットフォームの暗号化機能は、最新の業界標準を使用し、専門家によって開発され、厳しくテストされています。

まれに、プラットフォーム提供の暗号化を置き換える必要がある場合は、長所と短所を評価し、業界標準の暗号アルゴリズムを使用します。

開発者は、プラットフォーム以外の暗号化ライブラリではなく、オペレーティング システムに組み込まれている暗号化 API を使用する必要があります。 .NET の場合は、「.NET 暗号モデル」に従ってください。

暗号化キーのアプローチを選択する

既定では、Azure サービスは Microsoft が管理する暗号化キーを使用してデータの暗号化と暗号化解除を行います。 キー管理は Azure が担当します。

カスタマー マネージド キーを選択することもできます。 Azure では引き続きお客様のキーが使用されますが、キー操作についてはお客様が責任を負います。 必要に応じてキーを柔軟に変更することができます。 暗号化解除は、カスタマー マネージド キーを使用する大きな理由です。

強力な暗号化と強力な暗号化解除をペアにする必要があります。 セキュリティの観点からは、キーが侵害された場合に影響範囲を制御する一般的な方法はローテーションであるため、暗号化解除キーを保護することが重要です。 アクセスを監視して異常なアクセスやアクティビティを検出します。

暗号化されたデータとは別にキーを保存します。 この分離により、一方のエンティティの侵害が他方に影響を及ぼさないようにすることができます。 カスタマー マネージド キーを使用する場合は、そのキーをキー ストアに格納します。 機密性の高いデータをマネージド ハードウェア セキュリティ モジュール (HSM) に保存します。

どちらのストアも ID ベースのアクセスで保護されています。 この機能を使用すると、プラットフォームへのアクセスも拒否できます。

標準暗号化アルゴリズムを使用する

カスタム実装を作成するのではなく、十分に確立され、業界標準に準拠した暗号化アルゴリズムを使用します。

アルゴリズムの業界標準では、暗号化スキームに一定レベルのエントロピが必要です。 エントロピ ソースは、暗号化中に挿入されます。 エントロピによりアルゴリズムが強化され、攻撃者が情報を抽出することが困難になります。 エントロピの許容可能なしきい値を決定します。 暗号化手順では、プロセッサが集中的に使用されます。 コンピューティング要求の全体的なパフォーマンス目標に対して、暗号化に費やされるコンピューティング サイクルを最大化するために適切なバランスを見つけます。

トレードオフ: 非常に複雑なアルゴリズムを選択した場合や適切な量を超えるエントロピを挿入した場合は、システムのパフォーマンスが低下します。

ハッシュとチェックサムを使用する

一般的に、ハッシュはエラー検出技術です。 ハッシュは、改ざんによって生じる可能性のあるデータの変更を検出するので、セキュリティのために使用することもできます。 ハッシュ関数は暗号化に基づいていますが、キーは使用しません。 ハッシュ関数はアルゴリズムを使用してチェックサムを生成します。 チェックサムはデータを比較してその整合性を検証できます。

アプリケーションでは、SHA-256、SHA-384、SHA-512 などの SHA-2 ファミリのハッシュ アルゴリズムを使用する必要があります。

保存データを暗号化

内部および外部のコンプライアンス要件に従って、情報ストレージ オブジェクトを分類して保護します。 次の推奨事項を参照してください。

• ストレージ サービス、データ ストア、およびデータの保存に使用されるその他のリソースに対して提供されているネイティブ オプションを使用してデータを暗号化します。 これらのストレージ サービスまたはリソースにデータを一時的にのみ保存する場合でも、このデータを暗号化します。 また、バックアップ データも暗号化して、元のソースと同じレベルのセキュリティを維持します。

  詳細については、「保存データの保護」を参照してください。

• 二重暗号化を使用します。 ビジネス要件でより高い保証が求められる場合は、二重暗号化を実行できます。 独立したカスタマー マネージド キーを使用して、2 つ以上のレイヤーのデータを暗号化します。 マネージド HSM にデータを保存します。 データを読み取るには、両方のキーにアクセスする必要があります。 一方のキーが侵害された場合でも、もう一方のキーによってデータは保護されます。 この手法は、攻撃者のコストを増やすことを目的としています。

  プラットフォーム提供の暗号化を使用して、データを二重に暗号化することもできます。 プラットフォーム提供の暗号化により、インフラストラクチャ レベルでストレージ メディアが保護され、データ レベルで別の暗号化レイヤーが適用されます。 たとえば、メッセージ ブローカー サービスには、メッセージ パイプを保護する Microsoft マネージド キーを使用したプラットフォーム提供の暗号化があります。 この方法では、カスタマー マネージド キーを使用してメッセージを暗号化できます。

  複数の暗号化キーを使用します。 キー暗号化キー (KEK) を使用して、データ暗号化キー (DEK) を保護します。

• ID ベースのアクセス制御を使用して、データへのアクセスを制御します。 ネットワーク ファイアウォールを追加して、予期しない安全でないアクセスをブロックするセキュリティ レイヤーを追加します。

  詳細については、「ID およびアクセス管理に関する推奨事項」をご覧ください。

• 最小特権アクセス制御を持つマネージド HSM にキーを保存します。 データとデータのキーを分離します。

• 限られた量のデータだけを保存し、必要なものだけを暗号化します。 データは、暗号化サイクルより長く存続すべきではありません。 データが不要になったら、暗号化解除サイクルを消費せずに暗号化されたデータを削除します。

転送中のデータを暗号化する

• クライアントとサーバー間の通信にはセキュリティで保護されたプロトコルを使用します。 トランスポート プロトコルには、セキュリティ レイヤーが組み込まれています。 TLS は、クライアントとサーバーのエンドポイント間でデータを交換するための業界標準です。

  TLS 1.2 より前のバージョンは使用しないでください。 TLS 1.2 をサポートするようにソリューションを移行し、既定でこのバージョンを使用します。 すべての Azure サービスは、パブリック HTTPS エンドポイントで TLS 1.2 をサポートしています。

  リスク: 下位互換性がサポートされていない場合、TLS 1.2 をサポートしていない古いクライアントは正常に動作しない可能性があります。

  転送データの秘密度に関係なく、すべての Web サイトの通信で HTTPS を使用する必要があります。 クライアントとサーバーのハンドシェイク中に、HTTP Strict Transport Security (HSTS) ポリシーの使用をネゴシエートして、HTTPS トランスポートが維持され、通信中に HTTP にドロップされないようにします。 このポリシーは中間者攻撃から保護します。

  HSTS のサポートは新しいバージョン向けです。 古いブラウザーとの下位互換性が損なわれる可能性があります。

  Note

  プロトコルを暗号化して、セキュリティで保護されたデータベース接続を確立することもできます。 たとえば、Azure SQL Database では、TLS ハンドシェイクを統合する表形式データ ストリーム (TDS) プロトコルがサポートされています。

  暗号スイートは、クライアントとサーバーの間のハンドシェイクを標準化するために使用される一連のアルゴリズムです。 暗号により、交換が暗号化されて認証されることが保証されます。 暗号の選択は、サーバーが使用する TLS バージョンによって異なります。 Azure Application Gateway などの一部のサービスでは、サポートする TLS のバージョンと暗号スイートを選択できます。 Advanced Encryption Standard (AES) を対称ブロック暗号として使用する暗号スイートを実装します。 AES-128、AES-192、AES-256 を使用できます。

• 証明書のライフサイクルを管理します。 証明書には、事前に決められた有効期間があります。 有効期間の長い証明書を保持しないでください。また、証明書が勝手に期限切れにならないようにしてください。 許容できる頻度で証明書を更新するプロセスを実装します。 短い間隔で発生する更新のプロセスを自動化できます。

  Note

  証明書のピン留めを使用する場合は、機敏性と証明書管理の制限について十分に理解しておいてください。

  ワークフローでは、環境内で無効な証明書が受け入れられないようにする必要があります。 証明書のピン留めプロセスでは、証明書を検証し、その検証チェックを実施する必要があります。 アクセス ログを監視して、署名キーが適切なアクセス許可で使用されていることを確認する必要があります。

  キーが侵害された場合、証明書をすぐに取り消す必要があります。 証明機関 (CA) は、有効期限が切れる前に無効になっている証明書を示す証明書失効リスト (CRL) を提供します。 検証チェックでは、CRL を考慮する必要があります。

  トレードオフ: 証明書の検証プロセスは煩雑な可能性があり、通常は CA が関与します。 証明書による暗号化が必要なデータを決定します。 その他の種類の通信については、ローカライズされた補完的な制御を実装してセキュリティを強化できるかどうかを判断します。

  制御をローカライズする方法の 1 つは、相互 TLS (mTLS) を使用することです。 これにより、クライアントとサーバーの間で双方向の信頼関係が確立されます。 クライアントとサーバーの両方が独自の証明書を持ち、各証明書は公開キーまたは秘密キーのペアで認証されます。 mTLS を使用すると、外部 CA に依存する必要がなくなります。 トレードオフは、2 つの証明書を管理する複雑さが増すことです。

• 必要に応じて VPN 接続を二重に暗号化します。 二重暗号化を実行して、VPN トンネルに多層防御を追加します。 2 つの VPN サーバーを使用すると、サーバー間で IP アドレスを隠すことができ、サーバーと宛先間でも IP アドレスを隠すことができます。 このプロセスでは、転送中のデータも 2 回暗号化されます。

  トレードオフ: 単一の VPN 設定に比べ、二重の VPN 設定は多くの場合、コストが高くなり、接続速度が遅くなります。

• ログ記録および監視プロセスを実装します。 ソース IP、ポート、プロトコルなど、クライアントに関する情報を保存するアクセス サインイン リソースを追跡します。 この情報を使用して異常を検出します。

使用中のデータを暗号化する

セキュリティの高いワークロードでは、セグメント化、分離、および最小特権が推奨される設計パターンです。

使用中の保護のコンテキストでは、VM、ホスト管理コード、およびその他のコンポーネントを確実に分離するために、ハードウェア境界において物理 CPU とメモリで使用中のデータの暗号化が必要になる場合があります。 データの暗号化と暗号化解除は、これらの分離境界内でのみ行う必要があります。

より厳格なセキュリティまたは規制の要件では、使用中のデータが暗号化されているというハードウェア ベースの暗号署名付きの証拠が必要になる場合もあります。これは、構成証明を通じて取得できます。 機密コンピューティングは、そのような要件をサポートするテクノロジの 1 つです。 Azure の特定のサービスでは、計算中のデータを保護する機能が提供されています。 詳細については、「Azure ファシリテーション: Azure Confidential Computing」を参照してください。

保護するデータのエンドツーエンドのライフサイクルを考慮します。データは多くの場合、その存続期間中に複数のシステムを移動するため、ソリューションのすべてのコンポーネントが必要なレベルの保護を提供できるように注意するか、データ管理戦略で適切なセグメント化またはマスキングが提供されるようにします。

Azure ファシリテーション

次のセクションでは、データの暗号化に使用できる Azure サービスと機能について説明します。

カスタマー マネージド キー

Azure Key Vault または Key Vault マネージド HSM にカスタマー マネージド キーを保存します。

Key Vault では、キーは他のシークレットと同様に扱われます。 Azure ロールベースのアクセス制御 (RBAC) は、アクセス許可モデルを通じてキーにアクセスします。 この ID ベースの制御を、Key Vault アクセス ポリシーとともに使用する必要があります。

詳細については、「RBAC を使用して Key Vault のキー、証明書、シークレットへのアクセス権を付与する」を参照してください。

Azure Key Vault Premium とマネージド HSM は、機密コンピューティング機能とセキュリティで保護されたキー リリース (これにより、高信頼実行環境 (TEE) 内で実行されていることを暗号的に証明可能なワークロードにのみキーがリリースされるようにするためのポリシーがサポートされます) を追加することで、オファリングをさらに強化します。

保存データの保護

• Azure Storage は、データがストレージ アカウントに保存されるときに、ブロック暗号を使用してデータを自動的に暗号化します。 Azure Blob Storage および Azure Queue Storage の場合、Storage はライブラリを介してクライアント側の暗号化も提供します。

  詳細については、「Storage の暗号化」を参照してください。

• Azure Virtual Machines には、仮想ストレージ ボリュームとして機能するディスク ファイルがあります。 仮想ディスク ファイルを暗号化して、コンテンツにアクセスできないようにすることができます。

  マネージド ディスクはポータルからエクスポートできます。 サーバー側暗号化とホストでの暗号化では、エクスポート後にのみデータを保護できます。 ただし、エクスポート プロセス中はデータを保護する必要があります。 Azure Disk Encryption を使用すると、エクスポート プロセス中にデータを保護および安全に保つことができます。

  Azure には、マネージド ディスクに対して複数の暗号化オプションが用意されています。 詳細については、「マネージド ディスク暗号化オプションの概要」を参照してください。

• SQL Database では、ページ レベルでデータベース ファイルを暗号化するために使用される Transparent Data Encryption 機能が提供されます。

転送中のデータの保護

Key Vault を使用すると、パブリックおよびプライベートの Secure Sockets Layer (SSL) または TLS 証明書をプロビジョニング、管理、および展開できます。 証明書は、Azure および内部の接続されているリソースで使用できます。

使用中のデータの保護

Azure の特定のサービスでは、Azure Confidential Computing を使用してホストの物理 CPU とメモリ内で計算されているデータを保護する機能が提供されます。

• 機密の仮想マシンは、TEE 内で実行される仮想マシン全体を提供します。仮想マシンのメモリと実行中の CPU コンテンツは暗号化され、高度なセキュリティ要件を持つ未変更のアプリケーションを Azure に移動するためのシンプルな 'リフト アンド シフト' アプローチを提供します。 各 Azure 機密 VM には、専用の仮想トラステッド プラットフォーム モジュール (TPM) が含まれています。 暗号化は、オペレーティング システム コンポーネントが安全に起動している間に実行されます。

• 機密 AKS ワーカー ノード、AKS 上の機密コンテナー、または Azure Container Instances (ACI) 上の機密コンテナーは、TEE 内で未変更のコンテナーを実行および管理する機能を提供します。これにより、お客様は使用中のデータの保護からのメリットを享受できます。 コンテナー オファリングは機密の仮想マシン上に構築され、同じ保護からのメリットを享受します。

• アプリケーション エンクレーブ ソリューションは、Intel Software Guard Extensions (SGX) をサポートする仮想マシン SKU で提供される特定の CPU 拡張機能を活用する特別に構築されたアプリケーションです。これらでは非常にきめ細かいトラステッド コンピューティング ベース (TCB) が提供されますが、機能を活用するにはアプリケーションを特別にコーディングする必要があります。

• セキュリティで保護されたキー リリースをこれらのテクノロジと組み合わせることで、TEE 内でのみ暗号化されたデータが暗号化解除されるようにすることができます。これにより、構成証明と呼ばれるプロセスを通じて必要なレベルの保護が提供されていることが証明されます。

シークレットの管理

Key Vault を使用すると、トークン、パスワード、証明書、API キー、その他のシークレットを安全に保存し、それらへのアクセスを制御できます。 Key Vault をキーおよび証明書管理ソリューションとして使用します。 Premium SKU では HSM がサポートされます。

例

次の例は、キー、証明書、およびシークレットを管理するために使用できる暗号化ソリューションを示しています。

関連リンク

• .NET 暗号化モデル
• Azure Disk Encryption
• 保存データに対する Storage 暗号化
• Azure サービスでの証明書のピン留め
• RBAC を使用して Key Vault のキー、証明書、シークレットへのアクセス権を付与する
• マネージド ディスク暗号化オプションの概要
• 透過的なデータ暗号化
• トラステッド プラットフォーム モジュールの概要
• Azure Confidential Computing

コミュニティ リンク

• Key Vault の概要

セキュリティ チェックリスト

レコメンデーションの完全なセットを参照してください。

セキュリティ チェックリスト