Azure Information Protection での Bring Your Own Key (BYOK) の詳細
Note
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 2019、Office 2016、Office 2013 などのクライアント アプリケーション
ヒント
必要に応じて、追加のオンプレミス キーを使用して、特定のドキュメントに追加のセキュリティを適用します。 詳細については、二重キー暗号化 (DKE) (統合ラベル付けクライアントのみ) に関するページを参照してください。
Azure Key Vault キー ストレージ
お客様が生成したキーは、BYOK 保護のため Azure Key Vault に格納する必要があります。
Note
Azure Key Vault で HSM で保護されたキーを使用するには、Azure Key Vault の Premium サービス レベルが必要です。この場合、追加の月額サブスクリプション料金が発生します。
キー コンテナーとサブスクリプションの共有
テナント キーには専用のキー コンテナーを使用することをお勧めします。 専用キー コンテナーは、他のサービスによる呼び出しによってサービス制限を超えないようにするのに役立ちます。 テナント キーが格納されているキー コンテナーのサービス制限を超えた場合、Azure Rights Management サービスの応答時間の調整が発生する可能性があります。
さまざまなサービスでキー管理要件が異なっているので、Microsoft ではキー コンテナーに専用の Azure サブスクリプションを使用する方法もお勧めしています。 専用 Azure サブスクリプション:
構成の誤りから保護する
サービスごとに管理者が異なる場合、セキュリティが高い
Azure Key Vault を使用する他のサービスと Azure サブスクリプションを共有するには、サブスクリプションで管理者の共通セットを共有しているようにします。 サブスクリプションを使用しているすべての管理者が、アクセスできるすべてのキーを完全に理解していることを確認すると、キーが正しく構成されていない可能性が低いことになります。
例: Azure Information Protection テナント キーの管理者が、Office 365 カスタマー キーと CRM Online のキーを管理する人と同じ場合に共有された Azure サブスクリプションを使用する場合です。 これらのサービスのキー管理者が異なる場合は、専用サブスクリプションを使用することをお勧めします。
Azure Key Vault を使用する利点
Azure Key Vault は、暗号化を使用するさまざまなクラウドベースのサービスおよびオンプレミス サービスに対して一元的かつ一貫した管理ソリューションを実現します。
Azure Key Vault では、キーの管理に加えて、暗号化を使用する他のサービスやアプリケーションの証明書とシークレット (パスワードなど) を保存、アクセス、管理するための同じ管理エクスペリエンスをセキュリティ管理者に提供します。
テナント キーを Azure Key Vault に格納すると、次の利点があります。
| 長所 | 説明 |
|---|---|
| 組み込みインターフェイス | Azure Key Vault では、PowerShell、CLI、REST API、Azure ポータル など、キー管理用の組み込みインターフェイスが多数サポートされています。 監視などの特定のタスク用に最適化された機能のために、Key Vault には他のサービスやツールも統合されています。 たとえば、Operations Management Suite Log Analytics でキーの使用状況ログを分析したり、指定した条件が満たされたときにアラートを設定したりすることができます。 |
| 役割の分離 | 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 サービスでのみ使用されていることを独立して監視する信頼性の高い方法が提供されます。
必要な場合、キー コンテナーに対するアクセス許可を削除することにより、キーへのアクセスをすぐに取り消すことができます。
キーを作成して格納するためのオプション
Note
マネージド 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 に転送します。
HSM で保護されたキーとして転送される、HSM で保護されたキー。 選択される最も一般的な方法です。
この方法は管理オーバーヘッドが最も多い一方で、組織が特定の規制に従う必要がある場合があります。 Azure Key Vault で使用される HSM には FIPS 140 検証があります。
HSM で保護されたキーとして変換され、Azure Key Vault に転送されるソフトウェアで保護されたキー。 この方法がサポートされるのは、Active Directory Rights Management サービス (AD RMS) から移行する場合のみです。
オンプレミスでソフトウェアで保護されたキーとして作成され、ソフトウェアで保護されたキーとして Azure Key Vault に転送されます。 この方法には .PFX 証明書ファイルが必要です。
たとえば、次の手順に従って、オンプレミスで作成されたキーを使用します。
組織の IT ポリシーとセキュリティ ポリシーに沿って、オンプレミスでテナント キーを作成します。 このキーはマスター コピーです。 オンプレミスのままであり、バックアップを行う必要があります。
このマスター キーのコピーを作成して、HSM から Azure Key Vault に安全に転送します。 このプロセス全体で、このキーのマスター コピーがハードウェア保護境界の外に置かれることはありません。
転送されると、キーのコピーは Azure Key Vault で保護されます。
信頼された発行ドメインのエクスポート
Azure Information Protection の使用を停止する場合は、Azure Information Protection によって保護されたコンテンツの暗号化を解除するために、信頼された発行ドメイン (TPD) が必要になります。
ただし、Azure Information Protection キーに BYOK を使用している場合、TPD のエクスポートはサポートされません。
このシナリオに備えるには、事前に適切な TPD を作成してください。 詳細については、「Azure Information Protection の "クラウド退出" プランを準備する方法」を参照してください。
Azure Information Protection テナント キーの BYOK の操作
BYOK を実装するには、次の手順に従います。
BYOK の前提条件
BYOK の前提条件は、システムの構成によって異なります。 必要に応じて、システムが次の前提条件を満たしていることを確認します。
| 要件 | 説明 |
|---|---|
| Azure サブスクリプション | すべての構成に必要です。 詳細については、BYOK と互換性のある Azure サブスクリプションがあることの確認に関するページを参照してください。 |
| Azure Information Protection 用の AIPService PowerShell モジュール | すべての構成に必要です。 詳細については、「AIPService PowerShell モジュールのインストール」を参照してください。 |
| Azure Key Vault の BYOK の前提条件 | オンプレミスで作成された HSM で保護されたキーを使用している場合は、Azure Key Vault のドキュメントに記載されている BYOK の前提条件も満たしていることを確認してください。 |
| Thales ファームウェア バージョン 11.62 | HSM に Thales ファームウェアを使用していて、ソフトウェア キーとハードウェア キーを使用して AD RMS から Azure Information Protection への移行を行う場合は、Thales ファームウェアのバージョンが 11.62 が必要です。 |
| 信頼された Microsoft サービスに対するファイアウォールのバイパス | テナント キーを含むキー コンテナーにより Azure Key Vault の仮想ネットワーク サービス エンドポイントが使用されている場合は、信頼された 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 コマンドレットを使用し、次の手順を実行して確認します。
管理者として Azure PowerShell セッションを開始します。
Connect-AzAccountを使用して、Azure Information Protection テナントのグローバル管理者としてサインインします。表示されたトークンをクリップボードにコピーします。 次に、ブラウザーで https://microsoft.com/devicelogin にアクセスし、コピーしたトークンを入力します。
詳細については、「Azure PowerShell を使用してサインインする」を参照してください。
PowerShell セッションで
Get-AzSubscriptionを入力し、次の値が表示されることを確認します。- サブスクリプションの名前と ID
- Azure Information Protection テナント ID
- 状態が有効であることの確認
値が表示されず、プロンプトに戻った場合は、BYOK に使用できる Azure サブスクリプションがありません。
キー コンテナーの場所の選択
Azure Information のテナント キーとして使用するキーを格納するキー コンテナーを作成する場合は、場所を指定する必要があります。 この場所は、Azure リージョンまたは Azure インスタンスです。
最初にコンプライアンスを選択してから、ネットワーク待ち時間を最小限に抑えます。
コンプライアンス上の理由で BYOK キー 手法を選択した場合、コンプライアンス要件により、Azure Information Protection テナント キーを格納するために使用できる Azure リージョンまたはインスタンスが要求される可能性もあります。
すべての暗号化では、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 |
キーを作成、構成する
重要
マネージド HSM に固有の情報については、Azure CLI を使用したマネージド HSM キーのキー承認の有効化に関するページを参照してください。
Azure Information Protection に使用する Azure Key Vault とキーを作成します。 詳しくは、Azure Key Vault のドキュメントをご覧ください。
BYOK の Azure Key Vault とキーを構成するには、次の点に注意してください。
- キーの長さの要件
- オンプレミスで HSM で保護されたキーを作成してキー コンテナーに転送する
- キー ID を使用して Azure Information Protection を構成する
- キーを使用するために Azure Rights Management サービスを承認する
キーの長さの要件
キーを作成するときは、キーの長さが 2048 ビット (推奨) または 1024 ビットのどちらかであることを確認してください。 その他のキーの長さは、Azure Information Protection ではサポートされていません。
Note
1024 ビットキーは、アクティブなテナント キーに対して適切なレベルの保護を提供するものとは見なされません。
Microsoft では、1024 ビットの RSA キーなどの短いキー長の使用と、それに伴う、提供する保護のレベルが不十分な SHA-1 などのプロトコルの使用を支持していません。
オンプレミスで HSM で保護されたキーを作成してキー コンテナーに転送する
オンプレミスで HSM で保護されたキーを作成し、HSM 保護されたキーとして Key Vault に転送する場合は、Azure Key Vault ドキュメント「Azure Key Vault の HSM で保護されたキーを生成し、転送する方法」の手順に従ってください。
Azure Information Protection で転送されたキーを使用するには、キーに対して次の Key Vault のすべての操作が許可される必要があります。
- encrypt
- 復号化
- wrapKey
- unwrapKey
- sign
- verify
既定では、すべての 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 は、Key Vault の名前、キー コンテナー、キーの名前、およびキーのバージョンが含まれる 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 を使用したキー承認の有効化
Azure portal にサインインし、[キー コンテナー]><ご使用のキー コンテナー名>>[アクセス ポリシー]>[新規追加] に移動します。
[アクセス ポリシーの追加] ペイン、[テンプレートからの構成] (省略可能) リスト ボックスから [Azure Information Protection BYOK] を選択し、[OK] をクリックします。
選択したテンプレートの構成は次のとおりです。
- [プリンシパルの選択] 値は、[Microsoft Rights Management サービス] に設定されています。
- 選択された [キーのアクセス許可] には、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 ユーザー ロールを使用すると、ユーザーはキーの暗号化の解除、署名、およびアクセス許可の取得を行うことができます。これは、マネージド HSM 機能に必要なすべての機能です。
キーを使用するように Azure Information Protection を構成する
上記のすべての手順を完了したら、このキーを組織のテナント キーとして使用するように Azure Information Protection を構成することができます。
Azure RMS コマンドレットを使用して、次のコマンドを実行します。
Azure Rights Management サービスに接続し、サインインします。
Connect-AipServiceUse-AipServiceKeyVaultKey マンドレットを実行して、キー URL を指定します。 次に例を示します。
Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://contosorms-kv.vault.azure.net/keys/contosorms-byok/<key-version>"重要
この例で、
<key-version>は使用するキーのバージョンです。 バージョンを指定しない場合、規定で現在のバージョンのキーが使用され、コマンドが機能しているように見えます。 しかし、キーを後で更新または新たにする場合、Use-AipServiceKeyVaultKey コマンドをもう一度実行した場合でも、Azure Rights Management サービスはテナントの機能を停止します。必要に応じて Get-AzKeyVaultKey コマンドを使用して、現在のキーのバージョン番号を取得します。
例:
Get-AzKeyVaultKey -VaultName 'contosorms-kv' -KeyName 'contosorms-byok'キーの URL が Azure Information Protection に対して正しく設定されていることを確認するには、Azure Key Vault で、Get-AzKeyVaultKey コマンドを実行して、キーの URL を表示します。
Azure Rights Management サービスが既にアクティブ化されている場合は、Set-AipServiceKeyProperties を実行して、Azure Rights Management サービスのアクティブなテナント キーとしてこのキーを使用するように Azure Information Protection に指示します。
テナント用に自動的に作成された既定の Microsoft 作成のキーの代わりに、独自のキーを使用するように Azure Information Protection が構成されました。
次のステップ
BYOK の保護の構成が完了した後、キーの使用と管理の詳細については、テナント ルート キーの使用開始に関するページに進んでください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示