お客様が管理: テナント キーのライフサイクル操作Customer-managed: Tenant key life cycle operations

適用対象: Azure Information ProtectionOffice 365Applies to: Azure Information Protection, Office 365

Azure Information Protection のテナント キーを自分で管理する場合 (Bring Your Own Key (BYOK) のシナリオ) は、次のセクションでこのトポロジに関連するライフサイクル操作に関する詳細を参照してください。If you manage your tenant key for Azure Information Protection (the bring your own key, or BYOK, scenario), use the following sections for more information about the life cycle operations that are relevant to this topology.

テナント キーの取り消しRevoke your tenant key

Azure Key Vault では、Azure Information Protection テナント キーが格納されたキー コンテナーに対するアクセス許可を変更して、Azure Rights Management サービスがキーにアクセスできないようにすることができます。In Azure Key Vault, you can change the permissions on the key vault that contains your Azure Information Protection tenant key so that the Azure Rights Management service can no longer access the key. ただし、これを行うと、以前に Azure Rights Management サービスで保護したドキュメントや電子メールを誰も開けなくなります。However, when you do this, nobody will be able to open documents and emails that you previously protected with the Azure Rights Management service.

Azure Information Protection のサブスクリプションをキャンセルすると、Azure Information Protection ではお客様のテナント キーの使用を停止します。操作を行う必要はありません。When you cancel your subscription for Azure Information Protection, Azure Information Protection stops using your tenant key and no action is needed from you.

テナント キーの再入力Rekey your tenant key

再入力は「キーをロールする」とも呼ばれます。Rekeying is also known as rolling your key. この操作を実行すると、Azure Information Protection は、ドキュメントおよびメールの保護に既存のテナント キーを使用することを停止し、別のキーを使い始めます。When you do this operation, Azure Information Protection stops using the existing tenant key to protect documents and emails, and starts to use a different key. ポリシーとテンプレートはすぐに再署名されますが、Azure Information Protection を使用しているクライアントおよびサービスの場合、この移行は段階的に行われます。Policies and templates are immediately resigned but this changeover is gradual for existing clients and services using Azure Information Protection. そのため、しばらくの間、一部の新しいコンテンツは引き続き以前のテナント キーで保護されます。So for some time, some new content continues to be protected with the old tenant key.

キーの再入力を行うには、テナント キー オブジェクトを構成し、代わりに使用するキーを指定する必要があります。To rekey, you must configure the tenant key object and specify the alternative key to use. これで、前に使用していたキーは自動的に Azure Information Protection のアーカイブされたキーとしてマークされます。Then, the previously used key is automatically marked as archived for Azure Information Protection. この構成により、このキーを使用して保護されていたコンテンツはアクセス可能なままとなります。This configuration ensures that content that was protected by using this key remains accessible.

Azure Information Protection に対してキーの再入力が必要になる場合の例を次に示します。Examples of when you might need to rekey for Azure Information Protection:

  • あなたの会社が 2 つ以上の会社に分かれました。Your company has split into two or more companies. テナント キーを再入力すると、新しい会社はあなたの社員が公開する新しいコンテンツにアクセスできません。When you rekey your tenant key, the new company will not have access to new content that your employees publish. 以前のテナント キーのコピーがあれば、以前のコンテンツにアクセスできます。They can access the old content if they have a copy of the old tenant key.

  • 別のキー管理トポロジに移行したい。You want to move from one key management topology to another.

  • テナント キーのマスター コピー (あなたが所有するコピー) の盗難が疑われています。You believe the master copy of your tenant key (the copy in your possession) is compromised.

管理している別のキーにキーを再入力するには、Azure Key Vault で新しいキーを作成することも、Azure Key Vault に既にある別のキーを使用することもできます。To rekey to another key that you manage, you can either create a new key in Azure Key Vault or use a different key that is already in Azure Key Vault. Azure Information Protection に BYOK を実装したときと同じ手順を実行します。Then follow the same procedures that you did to implement BYOK for Azure Information Protection.

  1. 新しいキーが Azure Information Protection に既に使用しているキーコンテナーとは別のキーコンテナーにある場合にのみ: AzKeyVaultAccessPolicyコマンドレットを使用して、キーコンテナーを使用する Azure Information Protection を承認します。Only if the new key is in a different key vault to the one you are already using for Azure Information Protection: Authorize Azure Information Protection to use the key vault, by using the Set-AzKeyVaultAccessPolicy cmdlet.

  2. Azure Information Protection 使用するキーがまだわからない場合は、 AipServiceKeyVaultKeyコマンドレットを実行します。If Azure Information Protection doesn't already know about the key you want to use, run Use-AipServiceKeyVaultKey cmdlet.

  3. Run Set-AipServiceKeyPropertiesコマンドレットを使用して、テナントキーオブジェクトを構成します。Configure the tenant key object, by using the run Set-AipServiceKeyProperties cmdlet.

これらの段階の詳細については、次を参照してください。For more information about each of these steps:

  • 管理する別のキーにキーを再入力するには、「Azure Information Protection テナント キーの BYOK を実装する」を参照してください。To rekey to another key that you manage, see Implementing BYOK for your Azure Information Protection tenant key.

    オンプレミスで作成し Key Vault に転送する、HSM で保護されているキーを再入力する場合は、現在のキーで使用したものと同じセキュリティ ワールドとアクセス カードを使用できます。If you are rekeying an HSM-protected key that you create on-premises and transfer to Key Vault, you can use the same security world and access cards as you used for your current key.

  • キーを再入力し、マイクロソフトが代わりに管理するキーに変更するには、マイクロソフト管理操作の「テナント キーの再入力」セクションをご覧ください。To rekey, changing to a key that Microsoft manages for you, see the Rekey your tenant key section for Microsoft-managed operations.

テナント キーのバックアップ/復旧Backup and recover your tenant key

あなたはテナント キーを管理しているので、Azure Information Protection で使用されるキーをバックアップする責任があります。Because you are managing your tenant key, you are responsible for backing up the key that Azure Information Protection uses.

オンプレミスでテナントキーを生成した場合は、nCipher HSM: キーをバックアップするには、トークン化されたキーファイル、world ファイル、および管理者カードをバックアップします。If you generated your tenant key on premises, in a nCipher HSM: To back up the key, back up the tokenized key file, the world file, and the administrator cards. Azure Key Vault にキーを転送すると、サービス ノードの障害から守るために、トークン化されたキー ファイルがサービスによって保存されます。When you transfer your key to Azure Key Vault, the service saves the tokenized key file, to protect against failure of any service nodes. このファイルは、特定の Azure リージョンまたはインスタンスを対象としたセキュリティ ワールドにバインドされます。This file is bound to the security world for the specific Azure region or instance. ただし、このトークン化されたキー ファイルを完全なバックアップとは考えないでください。However, do not consider this tokenized key file to be a full backup. たとえば、nCipher HSM の外部で使用するためにキーのプレーンテキストコピーが必要な場合、Azure Key Vault は回復不可能なコピーしかないため、このキーを取得することはできません。For example, if you ever need a plain text copy of your key to use outside a nCipher HSM, Azure Key Vault cannot retrieve it for you, because it has only a non-recoverable copy.

Azure Key Vault には、バックアップ コマンドレットが用意されています。これを使用すれば、キーをダウンロードしてファイルに保存することで、キーのバックアップを作成できます。Azure Key Vault has a backup cmdlet that you can use to back up a key by downloading it and storing it in a file. ダウンロードされたコンテンツは暗号化されているため、Azure Key Vault の外部で使用することはできません。Because the downloaded content is encrypted, it cannot be used outside Azure Key Vault.

テナント キーのエクスポートExport your tenant key

BYOK を使用する場合、テナント キーを Azure Key Vault または Azure Information Protection からエクスポートできません。If you use BYOK, you cannot export your tenant key from Azure Key Vault or Azure Information Protection. Azure Key Vault 内のコピーは回復不可能です。The copy in Azure Key Vault is non-recoverable.

侵害への対応Respond to a breach

違反対応プロセスがなければ、どれほど強固でも、セキュリティ システムは完全になりません。No security system, no matter how strong, is complete without a breach response process. あなたのテナント キーが盗まれた可能性があります。Your tenant key might be compromised or stolen. たとえ十分に保護されていても、現在の生成キー技術、または現在のキーの長さおよびアルゴリズムに脆弱性が見つかる可能性があります。Even when it’s protected well, vulnerabilities might be found in current generation key technology or in current key lengths and algorithms.

製品とサービスのセキュリティ インシデントに対応するためにマイクロソフトは専用のチームを置いています。Microsoft has a dedicated team to respond to security incidents in its products and services. インシデントが認められる報告があった場合、至急、このチームは範囲、根本原因、軽減の調査にあたります。As soon as there is a credible report of an incident, this team engages to investigate the scope, root cause, and mitigations. このインシデントが資産に影響する場合、Microsoft はテナントのグローバル管理者に電子メールで通知します。If this incident affects your assets, Microsoft notifies your tenant Global administrators by email.

侵害がある場合、あなたまたはマイクロソフトがとれる最善策は侵害の範囲によって異なります。マイクロソフトはあなたと連携し、このプロセスを進めます。If you have a breach, the best action that you or Microsoft can take depends on the scope of the breach; Microsoft will work with you through this process. 次の表は一般的な状況と、考えられる対応をいくつかまとめたものです。ただし、実際の対応は調査中に明らかになった情報によって変わります。The following table shows some typical situations and the likely response, although the exact response depends on all the information that is revealed during the investigation.

インシデントの説明Incident description 考えられる対応Likely response
テナント キーが漏れています。Your tenant key is leaked. テナント キーを再入力します。Rekey your tenant key. テナント キーの再入力」をご覧ください。See Rekey your tenant key.
無許可の個人またはマルウェアがテナント キーを使用する権利を手に入れましたが、キー自体は漏えいしていません。An unauthorized individual or malware got rights to use your tenant key but the key itself did not leak. テナント キーを再入力してもここでは役に立ちません。根本原因の分析が必要です。Rekeying your tenant key does not help here and requires root-cause analysis. 無許可の個人がアクセスを得た原因がプロセスまたはソフトウェアのバグにある場合、その状況は解決する必要があります。If a process or software bug was responsible for the unauthorized individual to get access, that situation must be resolved.
現行世代の HSM テクノロジに脆弱性が発見されたVulnerability discovered in the current-generation HSM technology. Microsoft は HSM を更新する必要があります。Microsoft must update the HSMs. 脆弱性によってキーが公開されたと信じるに足る理由が存在する場合、Microsoft はすべてのユーザーにテナント キーを再入力するように指示します。If there is reason to believe that the vulnerability exposed keys, Microsoft will instruct all customers to rekey their tenant keys.
RSA アルゴリズム、キーの長さ、ブルート フォース攻撃に見られる脆弱性がコンピューターで実現可能になります。Vulnerability discovered in the RSA algorithm, or key length, or brute-force attacks become computationally feasible. Microsoft は回復力のある新しいアルゴリズムまたは長いキーをサポートするように Azure Key Vault または Azure Information Protection を更新し、すべてのお客様にテナント キーの再入力を指示する必要があります。Microsoft must update Azure Key Vault or Azure Information Protection to support new algorithms and longer key lengths that are resilient, and instruct all customers to rekey their tenant key.