新しいストレージ アカウント用のクロステナントのカスタマー マネージド キーを構成する

Azure Storage は、保存されているストレージ アカウント内のすべてのデータを暗号化します。 規定では、データは Microsoft のマネージド キーで暗号化されます。 暗号化キーをさらに制御するために、独自のキーを管理することができます。 カスタマー マネージド キーは、Azure Key Vault または Azure Key Vault Managed Hardware Security Model (HSM) に格納する必要があります。

この記事では、新しいストレージ アカウントを作成するときにカスタマー マネージド キーによる暗号化を構成する方法について説明します。 クロステナントのシナリオでは、ストレージ アカウントは ISV によって管理されるテナントに存在する一方、そのストレージ アカウントの暗号化に使用されるキーは、顧客が管理するテナントのキー コンテナーに存在します。

既存のストレージ アカウントのカスタマー マネージド キーを構成する方法については、「既存のストレージ アカウント用のクロステナントのカスタマー マネージド キーを構成する」を参照してください。

注意

Azure Key Vault と Azure Key Vault マネージド HSM では、カスタマー マネージド キーの構成用に同じ API と管理インターフェイスがサポートされています。 Azure Key Vault でサポートされているすべてのアクションが、Azure Key Vault マネージド HSM でもサポートされます。

クロステナントのカスタマー マネージド キーについて

Azure でサービスとしてのソフトウェア (SaaS) オファリングを構築している多くのサービス プロバイダーは、顧客に独自の暗号化キーを管理するオプションを提供したいと考えています。 カスタマー マネージド キーを使用すると、サービス プロバイダーは、サービス プロバイダーの顧客によって管理され、サービス プロバイダーからアクセスできない暗号化キーを使用して、顧客のデータを暗号化できます。 Azure では、サービス プロバイダーの顧客は Azure Key Vault を使って、独自の Microsoft Entra テナントとサブスクリプションで暗号化キーを管理できます。

サービス プロバイダーが所有し、サービス プロバイダーのテナントに存在する Azure プラットフォーム サービスとリソースでは、暗号化/暗号化解除操作を実行するために、顧客のテナントからキーにアクセスする必要があります。

次の図は、サービス プロバイダーとその顧客にまたがるクロステナントの CMK ワークフローでフェデレーション ID を使用した保存時のデータ暗号化を示しています。

Screenshot showing a cross-tenant CMK with a federated identity.

上の例では、独立したサービス プロバイダーのテナント ("テナント 1") と顧客のテナント ("テナント 2") の、2 つの Microsoft Entra テナントがあります。 "テナント 1" は Azure プラットフォーム サービスをホストし、"テナント 2" は顧客のキー コンテナーをホストします。

サービス プロバイダーによって、"テナント 1" 内にマルチテナント アプリケーションの登録が作成されます。 ユーザー割り当てマネージド ID を使用して、このアプリケーションにフェデレーション ID 資格情報が作成されます。 次に、アプリの名前とアプリケーション ID が顧客と共有されます。

適切なアクセス許可を持つユーザーは、顧客テナント "テナント 2" にサービス プロバイダーのアプリケーションをインストールします。 次にユーザーは、インストールされているアプリケーションに関連付けられているサービス プリンシパルに、顧客のキー コンテナーへのアクセス権を付与します。 顧客はまた、暗号化キー (カスタマー マネージド キー) をキー コンテナーに格納します。 顧客は、キーの場所 (キーの URL) をサービス プロバイダーと共有します。

これでサービス プロバイダーには次の情報があります。

  • 顧客のテナント内にインストールされ、カスタマー マネージド キーへのアクセスが許可されている、マルチテナント アプリケーションのアプリケーション ID。
  • マルチテナント アプリケーション上の資格情報として構成されたマネージド ID。
  • 顧客のキー コンテナー内のキーの場所。

この 3 つのパラメーターを使用して、サービス プロバイダーは "テナント 2" のカスタマー マネージド キーで暗号化できる "テナント 1" 内の Azure リソースをプロビジョニングします。

上記のエンド ツー エンド ソリューションを 3 つのフェーズに分割しましょう。

  1. サービス プロバイダーは ID を構成します。
  2. 顧客は、サービス プロバイダーのマルチテナント アプリに対し、Azure Key Vault 内の暗号化キーへのアクセス権を付与します。
  3. サービス プロバイダーは、CMK を使用して Azure リソース内のデータを暗号化します。

フェーズ 1 の操作は、ほとんどのサービス プロバイダー アプリケーションに対して 1 回限りの設定となります。 フェーズ 2 とフェーズ 3 の操作は、顧客ごとに繰り返されます。

フェーズ 1 - サービス プロバイダーが Microsoft Entra アプリケーションを構成する

Step 説明 Azure RBAC の最小ロール Microsoft Entra RBAC の最小ロール
1. 新しいマルチテナント Microsoft Entra アプリケーションの登録を作成するか、既存のアプリケーションの登録から始めます。 Azure portalMicrosoft Graph APIAzure PowerShell、または Azure CLI を使用して、アプリケーション登録のアプリケーション ID (クライアント ID) をメモします なし アプリケーション開発者
2. ユーザー割り当てマネージド ID を作成します (フェデレーション ID 資格情報として使用されます)。
Azure portal / Azure CLI / Azure PowerShell/ Azure Resource Manager テンプレート
マネージド ID 共同作成者 なし
3. アプリケーションの ID を借用できるように、アプリケーションのフェデレーション ID 資格情報としてユーザー割り当てマネージド ID を構成します。
Graph API リファレンス/ Azure portal/ Azure CLI/ Azure PowerShell
なし アプリケーションの所有者
4. アプリケーション名とアプリケーション ID を顧客と共有し、顧客がアプリケーションをインストールして承認できるようにします。 なし なし

サービス プロバイダーに関する考慮事項

  • Microsoft Entra アプリケーションの作成に Azure Resource Manager (ARM) テンプレートを使用することは推奨されていません。
  • 同じマルチテナント アプリケーションを使用して、"テナント 2"、"テナント 3"、"テナント 4" など、複数のテナント内のキーにアクセスすることができます。 各テナントでは、アプリケーション ID は同じだがオブジェクト ID は異なるアプリケーションの独立したインスタンスが作成されます。 したがって、このアプリケーションの各インスタンスは個別に承認されます。 この機能に使用されるアプリケーション オブジェクトを使用して、すべての顧客間でアプリケーションをパーティション分割する方法を検討します。
    • 1 つのアプリケーションで使用できるフェデレーション ID 資格情報は最大 20 個なので、サービス プロバイダーはフェデレーション ID を顧客間で共有する必要があります。 フェデレーション ID の設計に関する考慮事項と制限について詳しくは、「外部 ID プロバイダーを信頼するようにアプリを構成する」をご覧ください。
  • サービス プロバイダーが顧客ごとに 1 つのアプリケーション オブジェクトを使用するシナリオもまれにありますが、この場合は、すべての顧客で大規模にアプリケーションを管理するための多額のメンテナンス コストが必要になります。
  • サービス プロバイダー テナント内では、発行者の確認を自動化することはできません。

フェーズ 2 - 顧客がキー コンテナーへのアクセスを承認する

手順 説明 最小特権の Azure RBAC ロール 最小特権の Microsoft Entra ロール
1.
  • 推奨: アプリにサインインするようにユーザーを送信します。 ユーザーがサインインできる場合は、アプリのサービス プリンシパルがテナントに存在します。
  • Microsoft GraphMicrosoft Graph PowerShellAzure PowerShell、または Azure CLI を使用して、サービス プリンシパルを作成します。
  • 管理者の同意 URL を作成し、アプリケーション ID を使用してサービス プリンシパルを作成するためのテナント全体にわたる同意を付与します。
  • なし アプリケーションをインストールするアクセス許可を持つユーザー
    2. カスタマー マネージド キーとして使用されるキーと Azure キー コンテナーを作成します。 キー コンテナーを作成するには、ユーザーに Key Vault Contributor ロールを割り当てる必要があります

    キー コンテナーにキーを追加するには、ユーザーに Key Vault Crypto Officer ロールを割り当てる必要があります
    なし
    3. Key Vault Crypto Service Encryption User ロールを割り当てることで、同意したアプリケーション ID に、Azure キー コンテナーへのアクセス権を付与します Key Vault Crypto Service Encryption User ロールをアプリケーションに割り当てるには、ユーザー アクセス管理者ロールが割り当てられている必要があります。 なし
    4. キー コンテナーの URL とキー名を、SaaS オファリングのカスタマー マネージド キー構成にコピーします。 なし なし

    Note

    CMK を使用した暗号化のためにマネージド HSM へのアクセスを承認するには、こちらのストレージ アカウントの例を参照してください。 マネージド HSM を使用したキーの管理の詳細については、「Azure CLI を使用してマネージド HSM を管理する」を参照してください

    サービス プロバイダーの顧客に関する考慮事項

    • 顧客テナント "テナント 2" で、管理者は、管理者以外のユーザーがアプリケーションをインストールできないようにポリシーを設定できます。 これらのポリシーによって、管理者以外のユーザーがサービス プリンシパルを作成できないようにすることができます。 そのようなポリシーを構成した場合は、サービス プリンシパルを作成するアクセス許可を持ったユーザーの関与が必要になります。
    • Azure Key Vault へのアクセスは、Azure RBAC またはアクセス ポリシーを使用して承認できます。 キー コンテナーへのアクセスを許可する場合は、キー コンテナーのアクティブなメカニズムを使用するようにしてください。
    • Microsoft Entra アプリケーションの登録には、アプリケーション ID (クライアント ID) が使用されます。 アプリケーションがテナントにインストールされると、サービス プリンシパルが作成されます。 サービス プリンシパルでは、アプリ登録と同じアプリケーション ID が共有されますが、独自のオブジェクト ID が生成されます。 アプリケーションにリソースへのアクセスを承認するには、サービス プリンシパル Name または ObjectID プロパティの使用が必要になる場合があります。

    フェーズ 3 - サービス プロバイダーがカスタマー マネージド キーを使用して Azure リソース内のデータを暗号化する

    フェーズ 1 と 2 が完了すると、サービス プロバイダーは、顧客のテナント内のキーとキー コンテナーと ISV のテナント内の Azure リソースを使用して、Azure リソース上の暗号化を構成できます。 サービス プロバイダーは、その Azure リソースでサポートされているクライアント ツール、ARM テンプレート、または REST API を使用して、クロステナントのカスタマー マネージド キーを構成できます。

    クロステナントのカスタマー マネージド キーを構成する

    このセクションでは、クロステナントのカスタマー マネージド キー (CMK) を構成し、顧客データを暗号化する方法について説明します。 Tenant2 のキー コンテナーに格納されている CMK を使用して、Tenant1 のリソース内の顧客データを暗号化する方法について説明します。 Azure portal、Azure PowerShell、または Azure CLI を使用できます。

    Azure portal にサインインして、次の手順を実行します。

    サービス プロバイダーが ID を構成します

    次の手順は、サービス プロバイダーのテナント Tenant1 のサービス プロバイダーによって実行されます。

    サービス プロバイダーが新しいマルチテナント アプリ登録を作成します

    新しいマルチテナント Microsoft Entra アプリケーションの登録を作成するか、既存のマルチテナント アプリケーションの登録から始めることができます。 既存のアプリケーション登録から始める場合は、アプリケーションのアプリケーション ID (クライアント ID) をメモします。

    新しい登録を作成するには、次の手順に従います。

    1. 検索ボックスで Microsoft Entra ID を検索します。 Microsoft Entra ID 拡張機能を見つけて選びます。

    2. 左ウィンドウで、[管理] > [アプリの登録] を選択します。

    3. [+ 新規登録] を選択します。

    4. アプリケーションの登録の名前を指定して、[任意の組織ディレクトリ内のアカウント (任意の Microsoft Entra ディレクトリ - マルチテナント)] を選びます。

    5. [登録] を選択します。

    6. アプリケーションの ApplicationId/ClientId を メモします。

      Screen shot showing how to create a new multi-tenant application registration.

    サービス プロバイダーは、ユーザー割り当てマネージド ID を作成します

    フェデレーション ID 資格情報として使用されるユーザー割り当てマネージド ID を作成します。

    1. 検索ボックスで「マネージド ID」を検索します。 マネージド ID 拡張機能を見つけて選択します。

    2. [+ 作成] を選択します。

    3. マネージド ID のリソース グループ、リージョン、名前を指定します。

    4. [Review + create](レビュー + 作成) を選択します。

    5. デプロイが成功したら、ユーザー割り当てマネージド ID の Azure ResourceId をメモします。この ID は [プロパティ] にあります。 次に例を示します。

      /subscriptions/tttttttt-0000-tttt-0000-tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ConsotoCMKDemoUA

      Screen shot showing how to create a resource group and a user-assigned managed identity.

    サービス プロバイダーは、ユーザー割り当てマネージド ID をアプリケーションのフェデレーション資格情報として構成します

    アプリケーションの ID を借用できるように、アプリケーションのフェデレーション ID 資格情報としてユーザー割り当てマネージド ID を構成します。

    1. [Microsoft Entra ID] > [アプリの登録] > 自分のアプリに移動します。

    2. [証明書とシークレット] を選択します。

    3. [フェデレーション資格情報] を選択します。

      Screen shot showing how to navigate to Certificate and secrets.

    4. [資格情報の追加] を選択します。

    5. [フェデレーション資格情報のシナリオ] で、[カスタマー マネージド キー] を選択します。

    6. [マネージド ID の選択] をクリックします。 ウィンドウからサブスクリプションを選択します。 [マネージド ID] で、[ユーザー割り当てマネージド ID] を選択します。 [選択] ボックスで、先ほど作成したマネージド ID を検索し、ウィンドウの下部にある [選択] をクリックします。

      Screen shot showing how to select a managed identity.

    7. [資格情報の詳細] で、資格情報の名前と説明 (省略可能) を指定し、[追加] を選択します。

      Screen shot showing how to add a credential.

    サービス プロバイダーがアプリケーション ID を顧客と共有する

    マルチテナント アプリケーションのアプリケーション ID (クライアント ID) を見つけて、顧客と共有します。

    顧客がサービス プロバイダーのアプリにキー コンテナー内のキーへのアクセスを許可する

    次の手順は、顧客のテナント Tenant2 の顧客によって実行されます。 顧客は Azure portal、Azure PowerShell、または Azure CLI を使用できます。

    手順を実行するユーザーは、アプリケーション管理者クラウド アプリケーション管理者グローバル管理者などの特権ロールを持つ管理者である必要があります。

    Azure portal にサインインして、次の手順を実行します。

    顧客が顧客テナントにサービス プロバイダー アプリケーションをインストールする

    サービス プロバイダーの登録済みアプリケーションを顧客のテナントにインストールするには、登録済みアプリからのアプリケーション ID で、サービス プリンシパルを作成します。 サービス プリンシパルは、次のいずれかの方法で作成できます。

    顧客がキー コンテナーを作成する

    キー コンテナーを作成するには、ユーザーのアカウントに Key Vault Contributor ロール、またはキー コンテナーの作成を許可する別のロールを割り当てる必要があります。

    1. Azure portal メニューまたは [ホーム] ページで、[+リソースの作成] を選択します 検索ボックスに「Key Vaults」と入力します。 結果の一覧から [キー コンテナー] を選択します。 [キー コンテナー] ページで、[作成] を選択します。

    2. [基本] タブで、サブスクリプションを選択します。 [リソース グループ] で、[新規作成] を選択し、リソース グループ名を入力します。

    3. キー コンテナーの一意の名前を入力します。

    4. リージョンと価格レベルを選択します。

    5. 新しいキー コンテナーの消去保護を有効にします。

    6. [アクセス ポリシー] タブで、[アクセス許可モデル][Azure ロールベースのアクセス制御] を選びます。

    7. [確認および作成][作成] の順に選択します。

      Screen shot showing how to create a key vault.

    キー コンテナーの名前と URI を記録しておきます。キー コンテナーにアクセスするアプリケーションは。この URI を使う必要があります。

    詳細については、「クイックスタート - Azure portal を使用して Azure キー コンテナーを作成する」を参照してください。

    顧客は、Key Vault Crypto Officer ロールをユーザー アカウントに割り当てます

    この手順により、暗号化キーを作成できるようになります。

    1. キー コンテナーに移動し、左側のウィンドウから [アクセスの制御 (IAM)] を選択します。
    2. [このリソースへのアクセス権の付与][ロールの割り当ての追加] を選択します。
    3. Key Vault Crypto Officer を検索して選択します。
    4. [メンバー] タブで、[ユーザー、グループ、またはサービス プリンシパル] を選択します。
    5. [メンバー] を選択し、ユーザー アカウントを検索します。
    6. [レビューと割り当て] を選択します。

    顧客が暗号化キーを作成する

    暗号化キーを作成するには、ユーザーのアカウントに Key Vault Crypto Officer ロール、またはキーの作成を許可する別のロールを割り当てる必要があります。

    1. Key Vault のプロパティ ページで、[キー] を選択します。
    2. [Generate/Import](生成/インポート) を選択します。
    3. [キーの作成] 画面で、キーの名前を指定します。 他の値は既定値のままにしておきます。
    4. [作成] を選択します
    5. キー URI をコピーします。

    顧客がサービス プロバイダー アプリケーションにキー コンテナーへのアクセスを許可する

    キー コンテナーにアクセスできるように、Azure RBAC ロール Key Vault Crypto Service Encryption User をサービス プロバイダーの登録済みアプリケーションに割り当てます。

    1. キー コンテナーに移動し、左側のウィンドウから [アクセスの制御 (IAM)] を選択します。
    2. [このリソースへのアクセス権の付与][ロールの割り当ての追加] を選択します。
    3. [Key Vault Crypto Service Encryption User] を検索して選択します。
    4. [メンバー] タブで、[ユーザー、グループ、またはサービス プリンシパル] を選択します。
    5. [メンバー] を選択し、サービス プロバイダーからインストールしたアプリケーションのアプリケーション名を検索します。
    6. [レビューと割り当て] を選択します。

    これで、キー コンテナーの URI とキーを使用して、カスタマー マネージド キーを構成できます。

    別のテナントのキーで暗号化された新しいストレージ アカウントを作成する

    ここまでで、ISV のテナントにマルチテナント アプリケーションを構成し、顧客のテナントにアプリケーションをインストールし、顧客のテナントにキー コンテナーとキーを構成しました。 次に、ISV のテナントに新しいストレージ アカウントを作成し、顧客のテナントのキーを使用してカスタマー マネージド キーを構成できます。

    ストレージ アカウントの作成時にカスタマー マネージド キーを構成する場合は、キー コンテナーへのアクセスの承認に既存のユーザー割り当てマネージド ID を使用する必要があります。 ユーザー割り当てマネージド ID には、キー コンテナーにアクセスするための適切なアクセス許可が必要です。 詳細については、Azure Key Vault に対する認証に関する記事を参照してください。

    既存のストレージ アカウントでカスタマー マネージド キーを使用して暗号化を構成する場合は、関連付けられているキー コンテナーで新しいバージョンが使用可能になるたびに、Azure Storage 暗号化に使用するキー バージョンを自動更新することを選択できます。 これを行うには、キー URI からキーのバージョンを省略します。 または、キーのバージョンが手動で更新されるまで暗号化に使用するキーのバージョンを明示的に指定できます。 キー URI にキーのバージョンを含めると、キーのバージョンを手動で更新するようにカスタマー マネージド キーが構成されます。

    重要

    キーを交換するには、Azure Key Vault でキーの新しいバージョンを作成します。 Azure Storage はキー交換の処理を行わないため、キー コンテナー内のキーの交換を管理する必要があります。 Azure Key Vault でキーの自動交換を構成するか、またはキーを手動で交換することができます。

    Azure Storage では、新しいキー バージョンの確認のため、キー コンテナーが 1 日に 1 回だけチェックされます。 Azure Key Vault のキーを交換するときは、必ず 24 時間待って、古いバージョンを無効化するようにしてください。

    Azure portal で新しいストレージ アカウント用のクロステナントのカスタマー マネージド キーを構成するには、次の手順を実行します。

    1. Azure portal で、ISV のテナントの [ストレージ アカウント] ページに移動し、[作成] ボタンを選択して新しいアカウントを作成します。

    2. ストレージ アカウントを作成する」に示されている手順に従って、[基本][詳細設定][ネットワーキング][データ保護] の各タブのフィールドに入力します。

    3. [暗号化] タブの [カスタマー マネージド キーのサポートを有効にする] フィールドで、カスタマー マネージド キーのサポートを有効にするサービスを指定します。

    4. [Encryption type] (暗号化の種類) フィールドで、[Customer-managed keys (CMK)] (カスタマー マネージド キー (CMK)) を選択します。

    5. [暗号化キー] フィールドで、[Enter key from key vault] (キー コンテナーからキーを入力する) を選択し、キー URI を指定します。 Azure Storage で新しいキー バージョンを自動的にチェックして更新する場合は、URI からキーのバージョンを省略します。

    6. [ユーザー割り当て ID] フィールドで、ISV のテナントで以前に作成したユーザー割り当てマネージド ID を検索します。

    7. [詳細設定] セクションを展開し、ISV のテナントで以前に作成したマルチテナント登録済みアプリケーションを選択します。

      Screenshot showing how to configure cross-tenant customer-managed keys for a new storage account in Azure portal.

    8. [確認] ボタンを選択して検証し、アカウントを作成します。

    新しいストレージ アカウントの作成時にキー バージョンを手動で更新して、カスタマー マネージド キーを構成することもできます。 これを行うには、キー URI を指定するときにキーのバージョンを含めます。

    キーを変更する

    Azure Storage 暗号化に使用しているキーは、いつでも変更できます。

    注意

    キーまたはキー バージョンを変更すると、ルート暗号化キーの保護は変わりますが、Azure Storage アカウント内のデータは常に暗号化されたままです。 データを確実に保護するための追加のアクションは必要ありません。 キーを変更するかキー バージョンをローテーションしても、パフォーマンスには影響しません。 キーの変更かキー バージョンのローテーションに関連するダウンタイムはありません。

    Azure portal でキーを変更するには、次の手順を実行します。

    1. お使いのストレージ アカウントに移動し、 [暗号化] の設定を表示します。
    2. キー コンテナーを選択し、新しいキーを選択します。
    3. 変更を保存します。

    カスタマー マネージド キーを使用するストレージ アカウントへのアクセスを取り消す

    カスタマー マネージド キーを使用しているストレージ アカウントへのアクセスを一時的に取り消すには、キー コンテナーで現在使用されているキーを無効にします。 キーの無効化と再有効化に関連するパフォーマンスへの影響やダウンタイムはありません。

    キーが無効化されると、クライアントは BLOB またはそのメタデータとの間で行われる読み取りまたは書き込み操作を呼び出すことができません。 失敗する操作の詳細については、 カスタマー マネージド キーを使用するストレージ アカウントへのアクセスを取り消すを参照してください。

    注意事項

    キー コンテナーでキーを無効にすると、Azure Storage アカウント内のデータは暗号化されたままになりますが、キーを再度有効にするまでアクセスできなくなります。

    Azure portal でカスタマー マネージド キーを無効にするには、以下の手順に従います。

    1. キーを含むキー コンテナーに移動します。

    2. [オブジェクト][キー] を選択します。

    3. キーを右クリックし、[無効] を選択します。

      Screenshot showing how to disable a customer-managed key in the key vault.

    Microsoft マネージド キーに切り替える

    Azure portal、PowerShell、または Azure CLI を使用して、カスタマー マネージド キーから Microsoft マネージド キーにいつでも戻すことができます。

    Azure portal でカスタマー マネージド キーから Microsoft マネージド キーに戻すには、以下の手順に従います。

    1. ストレージ アカウントに移動します。

    2. [セキュリティとネットワーク] で、[暗号化] を選択します。

    3. [暗号化の種類][Microsoft マネージド キー] に変更します。

      Screenshot showing how to switch to Microsoft-managed keys for a storage account.

    関連項目