Azure Information Protection の Bring Your Own Key (BYOK) の詳細

注

Microsoft Purview Information Protection (旧称 Microsoft Information Protection (MIP) をお探しですか?

Azure Information Protection アドインは 廃止され 、 Microsoft 365 アプリとサービスに組み込まれているラベルに置き換えられます。 他の Azure Information Protection コンポーネントのサポート状態の詳細を確認します。

Microsoft Purview Information Protection クライアント (アドインなし) は一般提供されています。

Azure Information Protection サブスクリプションを持つ組織は、Microsoft によって生成された既定のキーではなく、独自のキーを使用してテナントを構成できます。 多くの場合、この構成は BYOK (Bring Your Own Key) と呼ばれます。

BYOK と 使用状況ログ は、Azure Information Protection によって使用される Azure Rights Management サービスと統合されるアプリケーションとシームレスに連携します。

サポートされているアプリケーションは次のとおりです。

• Microsoft SharePoint や Microsoft 365 などのクラウド サービス

• RMS コネクタを介して Azure Rights Management サービスを使用する Exchange および SharePoint アプリケーションを実行するオンプレミス サービス

• Office 2024 や Office 2021 などのクライアント アプリケーション。

ヒント

必要に応じて、追加のオンプレミス キーを使用して、特定のドキュメントに追加のセキュリティを適用します。 詳細については、「 二重キー暗号化 (DKE) 保護 (統合ラベル付けクライアントのみ)」を参照してください。

Azure Key Vault キー ストレージ

BYOK 保護のために、顧客が生成したキーを Azure Key Vault に格納する必要があります。

注

Azure Key Vault で HSM で保護されたキーを使用するには、 Azure Key Vault Premium サービス レベルが必要です。この場合、サブスクリプションの月額料金が追加で発生します。

キーボールトとサブスクリプションの共有

テナント キーには専用のキー コンテナー を使用することをお勧めします。 専用キー コンテナーは、他のサービスによる呼び出しによって サービスの制限を 超えないようにするのに役立ちます。 テナント キーが格納されているキー コンテナーのサービス制限を超えると、Azure Rights Management サービスの応答時間の調整が発生する可能性があります。

さまざまなサービスにさまざまなキー管理要件があるため、Microsoft では、キー コンテナーに 専用の Azure サブスクリプション を使用することもお勧めします。 専用の Azure サブスクリプション:

• 構成の誤りから保護する

• 異なるサービスに異なる管理者がいる場合のセキュリティが強化されます

Azure Key Vault を使用する他のサービスと Azure サブスクリプションを共有するには、サブスクリプションが共通の管理者セットを共有していることを確認します。 サブスクリプションを使用するすべての管理者がアクセスできるすべてのキーを確実に理解していることを確認すると、キーが正しく構成されていない可能性が低くなります。

例: Azure Information Protection テナント キーの管理者が Office 365 カスタマー キーと CRM オンラインのキーを管理するのと同じ個人である場合に、共有 Azure サブスクリプションを使用する。 これらのサービスの主要な管理者が異なる場合は、専用サブスクリプションを使用することをお勧めします。

Azure Key Vault を使用する利点

Azure Key Vault は、暗号化を使用する多くのクラウドベースおよびオンプレミス サービス向けに、一元化された一貫性のあるキー管理ソリューションを提供します。

Azure Key Vault では、キーの管理に加えて、暗号化を使用する他のサービスやアプリケーションの証明書とシークレット (パスワードなど) の格納、アクセス、管理を行うのと同じ管理エクスペリエンスがセキュリティ管理者に提供されます。

テナント キーを Azure Key Vault に格納すると、次の利点があります。

長所	説明
組み込みインターフェイス	Azure Key Vault では、PowerShell、CLI、REST API、Azure portal など、キー管理用の組み込みインターフェイスが多数サポートされています。 他のサービスやツールは、監視などの特定のタスク用に最適化された機能のために Key Vault と統合されています。 たとえば、Operations Management Suite のログ分析を使用して主要な使用状況ログを分析したり、指定した条件が満たされたときにアラートを設定したりします。
役割の分離	Azure Key Vault は、認識されたセキュリティのベスト プラクティスとしてロールの分離を提供します。 ロールの分離により、Azure Information Protection 管理者は、データの分類と保護の管理、特定のセキュリティまたはコンプライアンス要件の暗号化キーとポリシーなど、最優先事項に集中できます。
マスター キーの場所	Azure Key Vault はさまざまな場所で利用でき、マスター キーを使用できる制限のある組織をサポートしています。 詳細については、Azure サイトの リージョン別の利用可能な製品 に関するページを参照してください。
分離されたセキュリティ ドメイン	Azure Key Vault では、北米、EMEA (ヨーロッパ、中東、アフリカ)、アジアなどのリージョンのデータ センターに個別のセキュリティ ドメインが使用されます。 Azure Key Vault では、Microsoft Azure Germany や Azure Government など、さまざまな Azure インスタンスも使用されます。
統合されたエクスペリエンス	Azure Key Vault を使用すると、セキュリティ管理者は、暗号化を使用する他のサービスの証明書やシークレット (パスワードなど) を格納、アクセス、管理することもできます。 テナント キーに Azure Key Vault を使用すると、これらの要素をすべて管理する管理者にシームレスなユーザー エクスペリエンスが提供されます。

最新の更新プログラムや、他のサービス で Azure Key Vault を使用する方法については、 Azure Key Vault チームのブログを参照してください。

BYOK の使用状況ログ

使用状況ログは、Azure Rights Management サービスへの要求を行うすべてのアプリケーションによって生成されます。

使用状況ログは省略可能ですが、Azure Information Protection のほぼリアルタイムの使用状況ログを使用して、テナント キーが使用されている方法とタイミングを正確に確認することをお勧めします。

BYOK のキー使用状況ログの詳細については、「 Azure Information Protection からの保護の使用状況のログ記録と分析」を参照してください。

ヒント

追加の保証のために、Azure Information Protection の使用状況ログは 、Azure Key Vault のログ記録と相互参照できます。 Key Vault ログは、キーが Azure Rights Management サービスでのみ使用されていることを個別に監視するための信頼性の高い方法を提供します。

必要に応じて、キー ボールトのアクセス許可を削除して、キーへのアクセスを即座に取り消します。

キーを作成して格納するためのオプション

注

Managed HSM オファリングの詳細と、コンテナーとキーを設定する方法については、 Azure Key Vault のドキュメントを参照してください。

キー承認の付与に関するその他の手順については、以下で説明します。

BYOK では、Azure Key Vault またはオンプレミスで作成されるキーがサポートされます。

オンプレミスでキーを作成する場合は、Key Vault にキーを転送またはインポートし、キーを使用するように Azure Information Protection を構成する必要があります。 Azure Key Vault 内から追加のキー管理を実行します。

独自のキーを作成して格納するオプション:

• Azure Key Vault で作成されます。 HSM で保護されたキーまたはソフトウェアで保護されたキーとして、Azure Key Vault にキーを作成して格納します。

注

Azure Key Vault で直接生成されたキーは、Azure Key Vault の外部で使用するために エクスポートできません 。 組織でキーがエクスポート可能で所有している必要がある場合は、オンプレミスでキーを作成し、Azure Key Vault にインポートし、キーのバックアップをオンプレミスに維持する必要があります。 ディザスター リカバリーの計画とテストには、これらのキーの復旧を定期的にテストするための対策を含める必要があります。 キーは Azure Key Vault からバックアップできますが、元のサブスクリプションにのみインポートできます。

• オンプレミスで作成されました。 オンプレミスでキーを作成し、次のいずれかのオプションを使用して Azure Key Vault に転送します。

  • HSM で保護されたキー。HSM で保護されたキーとして転送されます。 最も一般的な方法を選択します。

    この方法は管理オーバーヘッドが最も高くなりますが、組織が特定の規制に従う必要がある場合があります。 Azure Key Vault で使用される HSM には FIPS 140 検証があります。

  • HSM で保護されたキーとして Azure Key Vault に変換および転送される、ソフトウェアで保護されたキー。 この方法は、 Active Directory Rights Management Services (AD RMS) から移行する場合にのみサポートされます。

  • ソフトウェアで保護されたキーとしてオンプレミスで作成され、ソフトウェアで保護されたキーとして Azure Key Vault に転送されます。 このメソッドには、.PFX 証明書ファイルが必要です。

たとえば、オンプレミスで作成されたキーを使用するには、次の操作を行います。

1. 組織の IT ポリシーとセキュリティ ポリシーに従って、オンプレミスでテナント キーを生成します。 このキーはマスター コピーです。 オンプレミスのままであり、バックアップの責任はユーザーが負います。

2. マスター キーのコピーを作成し、HSM から Azure Key Vault に安全に転送します。 このプロセスを通じて、キーのマスター コピーがハードウェア保護境界から離れることはありません。

転送されると、キーのコピーは Azure Key Vault によって保護されます。

信頼された発行ドメインのエクスポート

Azure Information Protection の使用を停止する場合は、信頼された発行ドメイン (TPD) を使用して、Azure Information Protection によって保護されたコンテンツを復号化する必要があります。

ただし、Azure Information Protection キーに BYOK を使用している場合、TPD のエクスポートはサポートされません。

このシナリオに備えるために、事前に適切な TPD を作成してください。 詳細については、「 Azure Information Protection の "クラウド出口" プランを準備する方法」を参照してください。

Azure Information Protection テナント キーの BYOK の実装

BYOK を実装するには、次の手順に従います。

1. BYOK の前提条件を確認する
2. Key Vault の場所を選択する
3. キーを作成して構成する

BYOK の前提条件

BYOK の前提条件は、システム構成によって異なります。 必要に応じて、システムが次の前提条件に準拠していることを確認します。

要件	説明
Azure サブスクリプション	すべての構成に必要です。 詳細については、「 BYOK と互換性のある Azure サブスクリプションがあることを確認する」を参照してください。
Azure Information Protection 用の AIPService PowerShell モジュール	すべての構成に必要です。 詳細については、 AIPService PowerShell モジュールのインストールを参照してください。
BYOK の Azure Key Vault の前提条件	オンプレミスで作成された HSM で保護されたキーを使用している場合は、Azure Key Vault のドキュメントに記載されている BYOK の前提条件 にも準拠していることを確認してください。
Thales ファームウェア バージョン 11.62	ソフトウェア キーをハードウェア キーに使用して AD RMS から Azure Information Protection に移行し、HSM に Thales ファームウェアを使用している場合は、Thales ファームウェア バージョン 11.62 が必要です。
信頼された Microsoft サービスのファイアウォール バイパス	テナント キーを含むキー コンテナーで Azure Key Vault の Virtual Network サービス エンドポイントが使用されている場合は、信頼された Microsoft サービスにこのファイアウォールのバイパスを許可する必要があります。 詳細については、「 Azure Key Vault の仮想ネットワーク サービス エンドポイント」を参照してください。

BYOK と互換性のある Azure サブスクリプションがあることを確認する

Azure Information Protection テナントには、Azure サブスクリプションが必要です。 まだお持ちでない場合は、 無料アカウントにサインアップできます。 ただし、HSM で保護されたキーを使用するには、Azure Key Vault Premium サービス レベルが必要です。

Microsoft Entra 構成と Azure Rights Management カスタム テンプレート構成へのアクセスを提供する無料の Azure サブスクリプションでは、 Azure Key Vault を使用するには不十分です。

BYOK と互換性のある Azure サブスクリプションがあるかどうかを確認するには、 Azure PowerShell コマンドレットを使用して次の手順を実行して確認します。

1. 管理者として Azure PowerShell セッションを開始します。

2. Connect-AzAccountを使用して、Azure Information Protection テナントのグローバル管理者としてサインインします。

3. 表示されたトークンをクリップボードにコピーします。 次に、ブラウザーで https://microsoft.com/devicelogin に移動し、コピーしたトークンを入力します。

   詳細については、「Azure PowerShell を使用してサインインする」を参照してください。

4. PowerShell セッションで、「 Get-AzSubscription」と入力し、次の値が表示されていることを確認します。

   • サブスクリプション名と ID
   • Azure Information Protection テナント ID
   • 状態が有効になっていることを確認する

   値が表示されず、プロンプトに戻った場合は、BYOK に使用できる Azure サブスクリプションがありません。

キー コンテナーの場所の選択

Azure Information のテナント キーとして使用するキーを格納するキー コンテナーを作成する場合は、場所を指定する必要があります。 この場所は、Azure リージョンまたは Azure インスタンスです。

最初にコンプライアンスを選択してから、ネットワーク待ち時間を最小限に抑えます。

• コンプライアンス上の理由から BYOK キーの方法を選択した場合、これらのコンプライアンス要件では、どの Azure リージョンまたはインスタンスを使用して Azure Information Protection テナント キーを格納できるかも義務付けられている可能性があります。

• Azure Information Protection キーに対するすべての暗号化コールは、保護チェーンを備えています。 そのため、Azure Information Protection テナントと同じ Azure リージョンまたはインスタンスにキー コンテナーを作成することで、これらの呼び出しに必要なネットワーク待機時間を最小限に抑えることができます。

Azure Information Protection テナントの場所を識別するには、 Get-AipServiceConfiguration PowerShell コマンドレットを使用し、URL からリージョンを識別します。 例えば次が挙げられます。

LicensingIntranetDistributionPointUrl : https://5c6bb73b-1038-4eec-863d-49bded473437.rms.na.aadrm.com/_wmcs/licensing

リージョンは rms.na.aadrm.com から識別でき、この例では北米にあります。

次の表に、ネットワーク待ち時間を最小限に抑えるために推奨される Azure リージョンとインスタンスを示します。

Azure リージョンまたはインスタンス	キー ボールトの推奨場所
rms.na.aadrm.com	米国中北部 または 米国東部
rms.eu.aadrm.com	北ヨーロッパ または 西ヨーロッパ
rms.ap.aadrm.com​	東アジア または 東南アジア
rms.sa.aadrm.com	米国西部 または 米国東部
rms.govus.aadrm.com​	米国中部 または 米国東部 2
rms.aadrm.us	US Gov バージニア または US Gov アリゾナ
rms.aadrm.cn	中国東部 2 または 中国北部 2

キーを作成して構成する

Von Bedeutung

マネージド HSM に固有の情報については、 Azure CLI を使用した Managed HSM キーのキー承認の有効化に関するページを参照してください。

Azure Key Vault と、Azure Information Protection に使用するキーを作成します。 詳細については、 Azure Key Vault のドキュメントを参照してください。

Von Bedeutung

Azure Key Vault を作成したら、すぐに論理的な削除と消去の両方の保護を有効にします。 これにより、ボールトとキーが誤って削除されるのを防ぐことができます。 十分なバックアップなしでキーが失われると、暗号化されたファイルと電子メールの完全なデータ損失が発生します。 詳細については、Azure Key Vault: ソフト削除の概要をご参照ください。

BYOK 用に Azure Key Vault とキーを構成する場合は、次の点に注意してください。

• キーの長さの要件
• HSM で保護されたキーをオンプレミスで作成し、キー コンテナーに転送する
• キー ID を使用した Azure Information Protection の構成
• キーを使用するための Azure Rights Management サービスの承認

キーの長さの要件

キーを作成するときは、キーの長さが 2048 ビット (推奨) または 1024 ビットであることを確認します。 その他のキーの長さは、Azure Information Protection ではサポートされていません。

注

1024 ビット キーは、アクティブなテナント キーに対して適切なレベルの保護を提供するとは見なされません。

Microsoft は、1024 ビット RSA キーなどの下位のキー長の使用と、SHA-1 などの不適切なレベルの保護を提供するプロトコルの関連する使用を保証していません。

HSM で保護されたキーをオンプレミスで作成し、キー コンテナーに転送する

HSM で保護されたキーをオンプレミスで作成し、HSM で保護されたキーとしてキー コンテナーに転送するには、Azure Key Vault のドキュメント「 Azure Key Vault の HSM で保護されたキーを生成および転送する方法」の手順に従います。

転送されたキーを Azure Information Protection で使用するには、次のようなキーに対するすべての Key Vault 操作を許可する必要があります。

• 暗号化する
• 復号化する
• wrapKey
• unwrapKey
• 署名
• 確かめる

既定では、すべての Key Vault 操作が許可されます。

特定のキーに対して許可されている操作を確認するには、次の PowerShell コマンドを実行します。

(Get-AzKeyVaultKey -VaultName <key vault name> -Name <key name>).Attributes.KeyOps

必要に応じて、 Update-AzKeyVaultKey と KeyOps パラメーターを使用して、許可される操作を追加します。

キー ID を使用した Azure Information Protection の構成

Azure Key Vault に格納されているキーには、それぞれキー ID があります。

キー ID は、キー コンテナーの名前、キー コンテナー、キーの名前、キーのバージョンを含む URL です。 例: https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333

キー コンテナーの URL を指定して、キーを使用するように Azure Information Protection を構成します。

キーを使用するための Azure Rights Management サービスの承認

キーを使用するには、Azure Rights Management サービスが承認されている必要があります。 Azure Key Vault 管理者は、Azure portal または Azure PowerShell を使用してこの承認を有効にすることができます。

Azure portal を使用したキー承認の有効化

1. Azure portal にサインインし、 [キー コンテナー]><ご使用のキー コンテナー名>>[アクセス ポリシー]>[新規追加]に移動します。

2. [ アクセス ポリシーの追加 ] ウィンドウの [ テンプレートから構成する (省略可能)] リスト ボックスで、[ Azure Information Protection BYOK] を選択し、[OK] をクリック します。

   選択したテンプレートの構成は次のとおりです。

   • [ プリンシパルの選択] の値は Microsoft Rights Management Services に設定されます。
   • 選択した キーのアクセス許可 には、 Get、 Decrypt、Sign が含 まれます。

PowerShell を使用したキー承認の有効化

Key Vault PowerShell コマンドレット Set-AzKeyVaultAccessPolicy を実行し、GUID 00000012-0000-0000-c000-000000000000 を使用して Azure Rights Management サービス プリンシパルにアクセス許可を付与します。

例えば次が挙げられます。

Set-AzKeyVaultAccessPolicy -VaultName 'ContosoRMS-kv' -ResourceGroupName 'ContosoRMS-byok-rg' -ServicePrincipalName 00000012-0000-0000-c000-000000000000 -PermissionsToKeys decrypt,sign,get

Azure CLI を使用したマネージド HSM キーのキー承認の有効化

Managed HSM Crypto ユーザーとして Azure Rights Management サービス プリンシパル ユーザーのアクセス許可を付与するには、次のコマンドを実行します。

az keyvault role assignment create --hsm-name "ContosoMHSM" --role "Managed HSM Crypto User" --assignee-principal-type ServicePrincipal --assignee https://aadrm.com/ --scope /keys/contosomhskey

場所は:

• ContosoMHSM はサンプル HSM 名です。 このコマンドを実行するときは、この値を独自の HSM 名に置き換えます。

Managed HSM Crypto User ユーザー ロールを使用すると、ユーザーはキーの暗号化解除、署名、アクセス許可の取得を行うことができます。これらはすべて Managed HSM 機能に必要です。

キーを使用するように Azure Information Protection を構成する

上記のすべての手順を完了したら、このキーを組織のテナント キーとして使用するように Azure Information Protection を構成する準備ができました。

Azure RMS コマンドレットを使用して、次のコマンドを実行します。

1. Azure Rights Management サービスに接続し、サインインします。

   Connect-AipService
   

2. キー URL を指定して、 Use-AipServiceKeyVaultKey コマンドレットを実行します。 例えば次が挙げられます。

   Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://contosorms-kv.vault.azure.net/keys/contosorms-byok/<key-version>"
   

   Von Bedeutung

   この例では、 <key-version> は使用するキーのバージョンです。 バージョンを指定しない場合、キーの現在のバージョンが既定で使用され、コマンドが機能しているように見える場合があります。 ただし、キーが更新またはリニューアルされた場合、Use-AipServiceKeyVaultKey コマンドをもう一度実行しても、Azure Rights Management サービスはテナントで機能しなくなります。

   必要に応じて Get-AzKeyVaultKey コマンドを使用して、現在のキーのバージョン番号を取得します。

   例: Get-AzKeyVaultKey -VaultName 'contosorms-kv' -KeyName 'contosorms-byok'

   Azure Information Protection のキー URL が正しく設定されていることを確認するには、Azure Key Vault で Get-AzKeyVaultKey コマンドを実行してキー URL を表示します。

3. Azure Rights Management サービスが既にアクティブになっている場合は、 Set-AipServiceKeyProperties を実行して、このキーを Azure Rights Management サービスのアクティブなテナント キーとして使用するように Azure Information Protection に指示します。

Azure Information Protection は、テナント用に既定で作成された Microsoft のキーではなく、ご自身のキーを使用するように構成されました。

次のステップ

BYOK 保護を構成したら、引き続き テナント ルート キーの 概要に進み、キーの使用と管理の詳細を確認してください。