リソース ガードを使用したマルチユーザー認可について
Azure Backup のマルチユーザー承認 (MUA) を使用すると、Recovery Services コンテナーと Backup コンテナーに対する重要な操作に保護レイヤーを追加できます。 MUA の場合、Azure Backup Resource Guard と呼ばれる別の Azure リソースを使用して、重要な操作が適用可能な承認でのみ実行される必要があります。
Note
Backup ボールトに対するリソース ガードを使用したマルチユーザー認可が、一般提供されるようになりました。
MUA for Backup の動作
Azure Backup では、Recovery Services コンテナーまたは Backup コンテナーの追加の承認メカニズムとして Resource Guard が使用されます。 そのため、重要な操作 (以下で説明します) を正常に実行するには、関連付けられている Resource Guard に対する十分なアクセス許可も必要です。
重要
意図した通り機能するには、Resource Guard が別のユーザーによって所有されている必要があります。また、コンテナー管理者に共同作成者のアクセス許可を付与することはできません。 コンテナーを含むサブスクリプションまたはテナントとは異なるサブスクリプションまたはテナントに Resource Guard を配置して、保護を強化できます。
重要な操作
次の表は、重要な操作として定義され、Resource Guard によって保護できる操作の一覧です。 コンテナーを関連付けするときに、Resource Guard を使用して特定の操作を保護から除外することができます。
注意
[必須] として示されている操作は、関連付けられているコンテナーの Resource Guard を使用して保護される対象から除外できません。 また、除外された重要な操作は、Resource Guard に関連付けられているすべてのコンテナーに適用されます。
コンテナーを選択してください
| 操作 | 必須/省略可能 |
|---|---|
| 論理的な削除の無効化 | Mandatory |
| MUA 保護を無効にする | Mandatory |
| バックアップ ポリシーの変更 (リテンション期間の短縮) | オプション |
| 保護の変更 (リテンション期間の短縮) | オプション |
| データを削除して保護を停止 | オプション |
| MARS セキュリティ PIN を変更する | オプション |
概念とプロセス
以下では、Azure Backup で MUA を使用する場合の概念とプロセスについて説明します。
プロセスと責任を明確に理解するために、次の 2 人のユーザーを検討しましょう。 この記事では、これら 2 つのロールについて参照します。
バックアップ管理者: Recovery Services コンテナーまたは Backup コンテナーの所有者であり、コンテナーに対して管理操作を実行します。 まず、バックアップ管理者は Resource Guard に対するアクセス許可を持つことはできません。
セキュリティ管理者: Resource Guard の所有者であり、コンテナーに対する重要な操作のゲートキーパーとして機能します。 そのため、セキュリティ管理者は、バックアップ管理者がコンテナーに対して重要な操作を実行するために必要なアクセス許可を制御します。
Resource Guard を使用して MUA が構成されているコンテナーで重要な操作を実行するための図形式の表現を次に示します。
一般的なシナリオでのイベントのフローを次に示します。
バックアップ管理者が Recovery Services コンテナーまたは Backup コンテナーを作成します。
セキュリティ管理者が Resource Guard を作成します。 Resource Guard は、コンテナーとは異なるサブスクリプションまたは異なるテナントに格納できます。 バックアップ管理者に Resource Guard に対する共同作成者アクセス許可が付与されていない必要があります。
セキュリティ管理者は、Resource Guard (または関連スコープ) のバックアップ管理者に閲覧者ロールを付与します。 バックアップ管理者は、コンテナーで MUA を有効にするには、閲覧者ロールが必要です。
次に、バックアップ管理者は、Resource Guard を介して MUA によって保護されるようにコンテナーを構成します。
バックアップ管理者がコンテナーに対して重要な操作を実行する場合は、Resource Guard へのアクセスを要求する必要があります。 バックアップ管理者は、セキュリティ管理者に連絡して、このような操作を実行するためのアクセス権の取得の詳細を確認できます。 これは、Azure Active Directory Privileged Identity Management (PIM) または組織が要求する他のプロセスを使用して行います。
セキュリティ管理者は、重要な操作を実行するために、Resource Guard の共同作成者ロールをバックアップ管理者に一時的に付与します。
これで、バックアップ管理者が重要な操作を開始します。
Azure Resource Manager は、バックアップ管理者に十分なアクセス許可があるかどうかを確認します。 これで、バックアップ管理者が Resource Guard の共同作成者ロールを持つたび、要求は完了します。
バックアップ管理者に必要なアクセス許可/ロールがない場合、要求は失敗することになります。
セキュリティ管理者は、承認されたアクションが実行された後、または定義された期間後に、重要な操作を実行するための特権が取り消されます。 JIT ツール Microsoft Entra Privileged Identity Management の使用が、これを確実に行うのに役立つ場合があります。
Note
MUA により、保管済みバックアップに対して実行される上記の操作のみが保護されます。 データ ソース (つまり、保護されている Azure リソース/ワークロード) に対して直接実行される操作は、Resource Guard の範囲を超えます。
使用シナリオ
次の表に、Resource Guard とコンテナー (Recovery Services コンテナーと Backup コンテナー) を作成するシナリオと、それぞれによって提供される関連する保護を示します。
重要
どのシナリオでも、バックアップ管理者に Resource Guard に対する共同作成者のアクセス許可を持つ必要はありません。
| 使用シナリオ | MUA による保護 | 実装の容易さ | メモ |
|---|---|---|---|
| ボールトとリソース ガードは同じサブスクリプション内にあります。バックアップ管理者にはリソース ガードへのアクセス権がありません。 | バックアップ管理者とセキュリティ管理者の間に最低限の分離が設けられます。 | 1 つのサブスクリプションだけが必要なので、比較的簡単に実装できます。 | リソース レベルのアクセス許可/ロールが正しく割り当てられている必要があります。 |
| コンテナーと Resource Guard は異なるサブスクリプションにありますが、同じテナント内にあります。バックアップ管理者には、Resource Guard または対応するサブスクリプションへのアクセス権がありません。 | バックアップ管理者とセキュリティ管理者の間の中程度の分離が設けられます。 | 2 つのサブスクリプション (1 つのテナントを含む) が必要なので、比較的中程度の実装が容易です。 | リソースまたはサブスクリプションに対してアクセス許可およびロールが正しく割り当てられていることを確認します。 |
| コンテナーと Resource Guard は異なるテナント内にあります。バックアップ管理者には、Resource Guard、対応するサブスクリプション、または対応するテナントへのアクセス権がありません。 | バックアップ管理者とセキュリティ管理者の間の最大分離が設けられます。そのため、セキュリティは最大です。 | テストには 2 つのテナントまたはディレクトリが必要です。 | リソース、サブスクリプション、またはディレクトリに対してアクセス許可またはロールが正しく割り当てられている必要があります。 |