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