次の方法で共有

Azure Rights Management サービスのルート キーの管理

Azure Rights Management テナント キーは、Microsoft Purview Information Protectionのメイン暗号化サービスのorganizationのルート キーです。 他のキーは、ユーザー キー、コンピューター キー、ドキュメント暗号化キーなど、このルート キーから派生できます。 Azure Rights Management サービスがorganizationにこれらのキーを使用するたびに、Azure Rights Management サービスのテナントのルート キーに暗号化的にチェーンされます。

テナント ルート キーに加えて、organizationでは、特定のドキュメントに対してオンプレミスのセキュリティが必要になる場合があります。 通常、オンプレミスのキー暗号化は少量のコンテンツに対してのみ必要であるため、テナント ルート キーと共に構成されます。

Azure Rights Management テナント キーのオプションと管理方法については、次のセクションを参照してください。

会社の合併後など、テナント間で移行する場合は、合併 とスピンオフに関するブログ記事 を読んで詳細を確認することをお勧めします。

サービスのキーの種類

Azure Rights Management サービスのルート キーは、次のいずれかになります。

オンプレミスで追加の保護を必要とする機密性の高いコンテンツがある場合は、 ダブル キー暗号化 (DKE) を使用することをお勧めします。

Microsoft によって生成されたテナント ルート キー

Microsoft によって自動的に生成される既定のルート キーは、テナント キーライフ サイクルのほとんどの側面を管理するために Azure Rights Management サービス専用に使用される既定のキーです。

Azure Rights Management サービスを特別なハードウェア、ソフトウェア、または Azure サブスクリプションなしですばやく使用する場合は、既定の Microsoft キーを引き続き使用します。 たとえば、主要な管理に関する規制要件のないテスト環境や組織などがあります。

既定のキーでは、構成手順は必要ありません。

注:

Microsoft によって生成される既定のルート キーは、管理オーバーヘッドが最も低い最も簡単なオプションです。

ほとんどの場合、Microsoft Purview Information Protectionの暗号化設定を構成でき、キー管理プロセスは Microsoft によって処理されるため、テナント キーがあることを知らない場合もあります。

独自のキーを持ち込む (BYOK) オプション

BYOK では、Azure Key Vaultまたは顧客organizationのオンプレミスで、顧客によって作成されたキーが使用されます。 これらのキーは、さらに管理するために Azure Key Vaultに転送されます。

すべてのライフサイクル操作の制御など、キー生成に関するコンプライアンス規制がorganizationにある場合は BYOK を使用します。 たとえば、キーをハードウェア セキュリティ モジュールで保護する必要がある場合などです。

詳細については、「 BYOK の構成」を参照してください。

二重キー暗号化 (DKE)

DKE は、Microsoft が Azure で作成して保持する 2 つのルート キーと、顧客がオンプレミスで作成して保持する 2 つのルート キーを使用して、コンテンツのセキュリティを強化します。

DKE では、暗号化されたコンテンツにアクセスするために両方のキーが必要です。これにより、Microsoft やその他のサード パーティが暗号化されたデータに自分でアクセスできないようにします。

DKE はクラウドまたはオンプレミスにデプロイできるため、ストレージの場所に完全な柔軟性を提供します。

詳細については、「 二重キー暗号化」を参照してください。

テナント キーの操作

Azure Rights Management サービス キーの種類に応じて、Azure Rights Management テナント キーに対するさまざまなレベルの制御と責任があります。

キー管理操作の用語:

  • Microsoft によって生成されるテナント キーを使用する場合、キーは Microsoft によって管理されます。
  • BYOK で生成した Azure Key Vaultでキーを使用する場合、キーはカスタマー マネージドです。

次の表を使用して、Azure Rights Management テナント キーが Microsoft で管理されているかカスタマー マネージドであるかに応じて、実行できる管理操作を特定します。

ライフサイクル操作 Microsoft マネージド (既定値) カスタマー マネージド (BYOK)
テナント キーを取り消す ✕ (自動) ✓
テナント キーのキーの再生成 ✓ ✓
テナント キーのバックアップと回復 ✕ ✓
テナント キーをエクスポートする ✓ ✕
侵害への対応 ✓ ✓

これらの各操作の詳細については、テナント キーの種類に関連するタブを使用します。

ただし、Active Directory Rights Management Services から信頼された発行ドメイン (TPD) をインポートして Azure Rights Management テナント キーを作成する場合、このインポート操作は AD RMS から Azure Information Protectionへの移行の一部です。 設計の一環として、AD RMS TPD は 1 つのテナントにのみインポートできます。

テナント キーを取り消す

Azure Rights Management サービスを含む唯一または最後のサブスクリプションを取り消すと、サービスは Azure Rights Management テナント キーの使用を停止し、ユーザーからのアクションは必要ありません。

テナント キーのキーの再生成

キーの再生成は、キーのローリングとも呼ばれます。 この操作を行うと、Azure Rights Management サービスは既存のテナント キーを使用して項目を暗号化し、別のキーの使用を開始します。 ポリシーと権限管理テンプレートはすぐに辞任されますが、この変更は、Azure Rights Management サービスを使用する既存のクライアントとサービスに対して段階的に行われます。 そのため、しばらくの間、いくつかの新しいコンテンツは、古い Azure Rights Management テナント キーを使用して暗号化され続けます。

キーを再生成するには、Azure Rights Management テナント キー オブジェクトを構成し、使用する代替キーを指定する必要があります。 その後、以前に使用したキーは、Azure Rights Management サービスのアーカイブ済みとして自動的にマークされます。 この構成により、このキーを使用して暗号化されたコンテンツにアクセスできます。

Azure Rights Management サービスのキーを再作成する必要がある場合の例:

  • 暗号化モード 1 キーを使用して Active Directory Rights Management Services (AD RMS) から移行しました。 移行が完了したら、暗号化モード 2 を使用するキーを使用するように変更する必要があります。

  • 会社が 2 つ以上の会社に分割されています。 Azure Rights Management テナント キーをキー変更すると、新しい会社は従業員が暗号化する新しいコンテンツにアクセスできなくなります。 古い Azure Rights Management テナント キーのコピーがある場合は、古いコンテンツにアクセスできます。

  • あるキー管理トポロジから別のキー管理トポロジに移動する必要があります。

  • Azure Rights Management テナント キーのマスター コピーが侵害されていると思われます。

キーを再生成するには、別の Microsoft マネージド キーを選択して Azure Rights Management テナント キーにすることができますが、新しい Microsoft マネージド キーを作成することはできません。 新しいキーを作成するには、キー トポロジをカスタマー マネージド (BYOK) に変更する必要があります。

Active Directory Rights Management Services (AD RMS) から移行し、Azure Rights Management サービスの Microsoft マネージド キー トポロジを選択した場合は、複数の Microsoft マネージド キーがあります。 このシナリオでは、テナントに対して少なくとも 2 つの Microsoft マネージド キーがあります。 1 つ以上のキーは、AD RMS からインポートしたキーです。 また、Azure Rights Management テナント用に自動的に作成された既定のキーもあります。

Azure Rights Management サービスのアクティブなテナント キーとなる別のキーを選択するには、 AIPService モジュールの Set-AipServiceKeyProperties コマンドレットを使用します。 使用するキーを特定するには、 Get-AipServiceKeys コマンドレットを 使用します。 Azure Rights Management テナント用に自動的に作成された既定のキーを特定するには、次のコマンドを実行します。

(Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1

キー トポロジをカスタマー マネージド (BYOK) に変更するには、「 Azure Rights Management サービスのルート キーに独自のキーを持ち込む」を参照してください。

テナント キーのバックアップと回復

Microsoft は Azure Rights Management テナント キーをバックアップする責任を負います。お客様からの操作は必要ありません。

テナント キーをエクスポートする

Azure Rights Management サービス構成と対応するテナント キーをエクスポートするには、次の 3 つの手順の手順に従います。

手順 1: エクスポートを開始する

  • Azure Rights Management キーのエクスポートの要求を含むMicrosoft Purview Information Protectionサポート ケースを開くには、Microsoft サポートにお問い合わせください。 テナントのグローバル管理者であることを証明し、このプロセスの確認には数日かかることを理解する必要があります。 Standardサポート料金が適用されます。テナント キーのエクスポートは無料のサポート サービスではありません。

手順 2: 検証を待つ

  • Microsoft は、Azure Rights Management テナント キーを解放する要求が正当であることを確認します。 このプロセスには最大 3 週間かかる場合があります。

手順 3: CSS からキーの指示を受け取る

  • Microsoft カスタマー サポート サービスは、パスワードで保護されたファイルで暗号化された Azure Rights Management サービス構成とテナント キーを送信します。 このファイルの 拡張子は .tpd です。 これを行うには、Microsoft サポート エンジニアが最初にツールを電子メールで送信します (エクスポートを開始したユーザーとして)。 コマンド プロンプトからツールを次のように実行する必要があります。

    AadrmTpd.exe -createkey

    これにより、RSA キー ペアが生成され、パブリックとプライベートの半分が現在のフォルダー内のファイルとして保存されます。 例: PublicKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt と PrivateKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt。

    サポート エンジニアからのメールに返信し、 PublicKey で始まる名前のファイルを添付します。 次Microsoft サポート、TPD ファイルが RSA キーで暗号化された .xml ファイルとして送信されます。 最初に AadrmTpd ツールを実行したのと同じフォルダーにこのファイルをコピーし、PrivateKey で始まるファイルとMicrosoft サポートからファイルを使用して、ツールをもう一度実行します。 例:

    AadrmTpd.exe -key PrivateKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt -target TPD-77172C7B-8E21-48B7-9854-7A4CEAC474D0.xml

    このコマンドの出力は 2 つのファイルである必要があります。1 つはパスワードで保護された TPD のプレーン テキスト パスワードを含み、もう 1 つはパスワードで保護された TPD 自体です。 ファイルには、次のように新しい GUID があります。

    • Password-5E4C2018-8C8C-4548-8705-E3218AA1544E.txt

    • ExportedTPD-5E4C2018-8C8C-4548-8705-E3218AA1544E.xml

      これらのファイルをバックアップして安全に保存して、このテナント キーで暗号化されたコンテンツの暗号化を解除し続けられるようにします。 さらに、AD RMS に移行する場合は、この TPD ファイル ( ExportTDP で始まるファイル) を AD RMS サーバーにインポートできます。

手順 4: 進行中: テナント キーを保護する

テナント キーを受け取った後は、誰かがアクセスを取得した場合、そのキーを使用して暗号化されたすべてのアイテムを暗号化解除できるため、十分に保護された状態を維持します。

テナント キーをエクスポートする理由が、Azure Rights Management サービスを使用しなくなった場合は、ベスト プラクティスとして、テナント内の Azure Rights Management サービスを非アクティブ化します。 この予防措置は、テナント キーにアクセスする必要のないユーザーがアクセスした場合の結果を最小限に抑えるのに役立ちますので、テナント キーを受け取った後にこれを実行しないでください。 手順については、「 Azure Rights Management サービスの使用停止と非アクティブ化」を参照してください。

侵害への対応

セキュリティ システムは、どの程度強くても、侵害対応プロセスなしでは完了しません。 Azure Rights Management テナント キーが侵害されたり、盗まれたりする可能性があります。 適切に保護されている場合でも、現在の世代のキー テクノロジまたは現在のキーの長さとアルゴリズムに脆弱性が見つかる可能性があります。

Microsoft には、製品とサービスのセキュリティ インシデントに対応するための専用チームがあります。 インシデントの信頼できるレポートが表示されるとすぐに、このチームはスコープ、根本原因、軽減策の調査に取り組みます。 このインシデントが資産に影響を与える場合、Microsoft はテナントのグローバル管理者に電子メールで通知します。

侵害がある場合、お客様または Microsoft が実行できる最善のアクションは、侵害の範囲によって異なります。Microsoft は、このプロセスを通じてお客様と連携します。 次の表に、一般的な状況と考えられる応答を示しますが、正確な応答は調査中に明らかにされたすべての情報によって異なります。

インシデントの説明 可能性の高い応答
Azure Rights Management テナント キーが漏洩しました。 テナント キーのキーを再生成します。 この記事の「 テナント キーのキーの再生成 」セクションを参照してください。
未承認の個人またはマルウェアは、Azure Rights Management テナント キーを使用する権限を持っていますが、キー自体は漏洩しませんでした。 ここでテナント キーをキー更新しても役に立ちません。根本原因の分析が必要です。 未承認の個人がアクセスを取得するプロセスまたはソフトウェアのバグに責任がある場合は、その状況を解決する必要があります。
RSA アルゴリズムで検出された脆弱性、キーの長さ、またはブルート フォース攻撃が計算上可能になります。 Microsoft は、回復性のある新しいアルゴリズムと長いキーの長さをサポートするように Azure Rights Management サービスを更新し、すべての顧客に Azure Rights Management テナント キーのキーを変更するように指示する必要があります。