JavaScriptを有効にしてください

リソースガードを別テナントと使い隊

 ·   13 分で読めます  ·   [Kento GitHub Copilot]

ランサムウェア攻撃から重要なバックアップデータを守るために、Azure Backup のリソースガードを別テナントに配置してマルチユーザー承認を実装する方法について解説します。

本記事は GitHub Copilot を活用して作成しています。

想定される読者

  • Azure Backup を使ってバックアップ運用を行っている方
  • ランサムウェア対策としてバックアップのセキュリティ強化を検討している方
  • マルチユーザー承認の仕組みに興味がある方
  • Azure のマルチテナント構成に関心がある方

背景：なぜバックアップが狙われるのか

ランサムウェア攻撃では、データを暗号化するだけでなく、バックアップデータも削除または破壊することが一般的です。バックアップがあれば身代金を払わずにシステムを復旧できてしまうため、攻撃者はバックアップを最優先で狙います。

従来のバックアップ保護策には以下のような課題がありました：

  • 管理者権限の悪用: 攻撃者が管理者アカウントを乗っ取った場合、バックアップの削除や無効化が可能
  • 同一テナント内での無効化: リソースロックやセキュリティ設定を同じテナント内で簡単に解除できてしまう
  • 単一承認者のリスク: 1人の管理者だけで重要な操作が完結してしまう

これらの課題を解決するのが、別テナントに配置したリソースガードによるマルチユーザー承認です。

Azure Backup とリソースガードの基礎知識

Azure Backup とは

Azure Backup は、Azure 上の仮想マシンやデータベース、オンプレミスのサーバーなどを保護するためのバックアップサービスです。バックアップデータは Recovery Services コンテナーまたはバックアップ コンテナーに格納されます。（バックアップ対象に応じて使い分けます）

リソースガードとは

リソースガード（Resource Guard）は、Azure Backup の重要な操作に対して追加の承認レイヤーを提供する Azure リソースです。リソースガードを有効にすると、以下のような重要な操作を実行する際に、別の管理者からの承認が必要になります：

  • バックアップの削除
  • 論理的な削除の無効化
  • バックアップポリシーの変更
  • バックアップの停止

Resource Guard を使用したマルチユーザー承認 - Azure Backup | Microsoft Learn

マルチユーザー承認（MUA）とは

マルチユーザー承認（Multi-User Authorization, MUA）は、重要な操作を1人の管理者だけで完結させず、複数の承認者による承認を必要とする仕組みです。これにより、以下のメリットが得られます：

  • 権限の分離: バックアップ管理者とセキュリティ管理者で役割を分離
  • 不正操作の防止: 単独での悪意ある操作を防止
  • 監査証跡の強化: 誰がいつ承認したかの記録が残る

別テナント配置のメリット

リソースガードを別テナントに配置することで、さらに強力な保護が実現できます：

---
title: 別テナント配置によるセキュリティ強化
---
graph TB
    subgraph TenantA["テナント A（本番環境）"]
        BackupAdmin[バックアップ管理者]
        RSV[Recovery Services コンテナー]
        VM[仮想マシン]
        
        VM -->|バックアップ| RSV
    end
    
    subgraph TenantB["テナント B（セキュリティ管理）"]
        SecurityAdmin[セキュリティ管理者]
        RG[リソースガード]
    end
    
    RSV -.->|保護| RG
    BackupAdmin -->|削除要求| RSV
    RSV -->|承認要求| RG
    SecurityAdmin -->|承認/拒否| RG
    
    Attacker[攻撃者] -.->|テナント A を侵害| TenantA
    Attacker -.->|テナント B にはアクセス不可| TenantB
    
    classDef tenant fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef admin fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    classDef resource fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef attacker fill:#ffebee,stroke:#c62828,stroke-width:2px,stroke-dasharray: 5 5
    
    class TenantA,TenantB tenant
    class BackupAdmin,SecurityAdmin admin
    class RSV,VM,RG resource
    class Attacker attacker

重要なポイント：

  • 攻撃者がテナント A（本番環境）を完全に侵害しても、テナント B のリソースガードには到達できない
  • セキュリティ管理者はテナント B でのみ権限を持つため、テナント A の侵害の影響を受けない
  • 承認プロセスを突破するには、両方のテナントを同時に侵害する必要があり、攻撃の難易度が大幅に上がる

ざっくり手順

別テナントでのリソースガード設定は、以下の手順で実施します：

  1. 前提条件の確認

    • 2つのテナントの準備
    • 適切な権限の付与
    • リソースプロバイダーの登録

  2. リソースガードの作成（テナント B）

    • セキュリティ管理者がテナント B でリソースガードを作成
    • 保護対象の操作を選択

  3. バックアップ管理者への Reader 権限付与

    • テナント B のリソースガードに対して、テナント A のバックアップ管理者をゲストユーザーとして招待
    • Reader ロールを付与

  4. Recovery Services コンテナーへのリソースガード関連付け（テナント A）

    • バックアップ管理者がコンテナーにリソースガードを関連付け

  5. マルチユーザー承認の動作確認

    • 保護された操作（削除など）を試行
    • 承認プロセスを実施

それでは、各手順の詳細を見ていきましょう。

1. 前提条件の確認

必要なテナントとサブスクリプション

  • テナント A（本番環境）: Recovery Services コンテナーとバックアップ対象のリソースが存在
  • テナント B（セキュリティ管理）: リソースガードを配置

必要な権限

ロール テナント 対象リソース 目的
バックアップ管理者 テナント A Recovery Services コンテナー バックアップの日常管理
バックアップ管理者（ゲスト） テナント B リソースガード（Reader） リソースガードの参照と関連付け
セキュリティ管理者 テナント B リソースガード リソースガードの管理と承認操作

重要な制約：

  • バックアップ管理者は、リソースガードに対して Contributor、Backup MUA Admin、Backup MUA Operator 権限を持ってはいけません
  • これらの権限があると、バックアップ管理者がリソースガードを無効化できてしまうため

リソースプロバイダーの登録

両方のテナントのサブスクリプションで、以下のリソースプロバイダーが登録されている必要があります：

  • Microsoft.RecoveryServices（Recovery Services コンテナー用）
  • Microsoft.DataProtection（バックアップ コンテナー用）

リージョンの制約

リソースガードと Recovery Services コンテナーは、同じ Azure リージョンに配置する必要があります。テナントが異なっていても、リージョンは一致させてください。

2. リソースガードの作成（テナント B）

セキュリティ管理者が、テナント B でリソースガードを作成します。

Azure Portal での作成手順

  1. Azure Portal にセキュリティ管理者としてサインイン（テナント B）
  2. 検索バーで「リソースガード」を検索
  3. + 作成をクリック
Azure Portal でのリソースガード作成画面。サブスクリプション、リソースグループ、リージョン、名前を入力するフォームが表示されている
リソースガードの作成画面:

  1. 以下の情報を入力：

    • サブスクリプション: テナント B のサブスクリプション
    • リソースグループ: 新規作成または既存のものを選択
    • リソースガード名: 例）rg-backup-security
    • リージョン: Recovery Services コンテナーと同じリージョン
    • 説明: 例）「本番環境バックアップの保護用リソースガード。承認が必要な場合は security-team@example.com に連絡してください。」

  2. 次: 保護された操作タブに移動

保護対象の操作を選択

保護された操作タブでは、どの操作にマルチユーザー承認を要求するかを選択します。

リソースガードで保護する操作のチェックボックスが並んでいる画面。バックアップの削除、論理的な削除の無効化、バックアップの停止などの項目が表示されている
保護された操作の選択画面:

以下の操作を選択することを推奨します：

  • ✅ バックアップ データの削除
  • ✅ 論理的な削除の無効化
  • ✅ バックアップの停止（データの削除を含む）
  • ✅ バックアップ ポリシーの変更（保持期間の短縮を含む）

これらの操作は、ランサムウェア攻撃やデータ損失のリスクが高い重要な操作です。

  1. 確認および作成をクリックして、リソースガードを作成

リソースガードのリソース ID を取得

後の手順で使用するため、リソースガードのリソース ID を控えておきます：

3. バックアップ管理者への Reader 権限付与

テナント B のリソースガードに対して、テナント A のバックアップ管理者をゲストユーザーとして招待し、Reader ロールを付与します。

ゲストユーザーの招待

  1. Azure Portal でテナント B にサインイン（セキュリティ管理者）
  2. 作成したリソースガードのページを開く
  3. アクセス制御 (IAM) を選択
  4. + 追加 → ロールの割り当ての追加をクリック
リソースガードのアクセス制御 (IAM) 画面。ロールの割り当ての追加ボタンが表示されている
ロールの割り当ての追加画面:
  1. ロールタブで「Reader」を選択して次へ
  2. メンバータブで、+ メンバーの選択をクリック
  3. テナント A のバックアップ管理者を選択
  4. 選択をクリック
  5. 確認と割り当てをクリック

4. Recovery Services コンテナーへのリソースガード関連付け（テナント A）

バックアップ管理者が、テナント A の Recovery Services コンテナーにリソースガードを関連付けます。

Azure Portal での関連付け手順

  1. Azure Portal にバックアップ管理者としてサインイン（テナント A）
  2. 保護したい Recovery Services コンテナーを開く
  3. 設定 → プロパティを選択
  4. マルチユーザー承認セクションで、更新をクリック
Recovery Services コンテナーのプロパティ画面。マルチユーザー承認セクションに更新ボタンが表示されている
マルチユーザー承認の設定画面:
  1. リソースガードで保護するを選択
  2. リソースガードセクションで、以下のいずれかの方法でリソースガードを指定：
    • 方法 1: ディレクトリを選択
      1. ディレクトリドロップダウンから、テナント B を選択
      2. リソースガードの選択をクリック
      3. 作成したリソースガード（rg-backup-security）を選択
    • 方法 2: リソース ID を入力
      1. 別のディレクトリのリソースガードのリソース ID を入力を選択
      2. 手順 2 で取得したリソース ID を貼り付け
リソースガードを選択する画面。ディレクトリのドロップダウンと、リソース ID を入力するテキストボックスが表示されている
リソースガードの選択画面:
  1. 保存をクリック

関連付けが成功すると、マルチユーザー承認が有効になります。

5. マルチユーザー承認の動作確認

リソースガードが正しく設定されているか、実際に保護された操作を試してみます。

承認なしでの削除試行（失敗を確認）

  1. Azure Portal でテナント A にサインイン（バックアップ管理者）
  2. Recovery Services コンテナーを開く
  3. バックアップ ポリシーから、保持期間を短くしたいバックアップポリシーを選択
  4. インスタント回復スナップショットの保有期間を 7日間（デフォルト）から 3日に変更を試行
バックアップの削除を試行すると表示される画面。リソースガードによって保護されており、承認が必要であることを示すメッセージが表示されている
承認要求画面:

以下のようなエラーメッセージが表示されます：

The client 'xxxxx' with object id '688b025c-763c-4aa2-b4fe-17c0610863cc' has permission to perform action ....

これで、マルチユーザー承認が正しく機能していることが確認できます。

承認フロー全体の図

---
title: マルチユーザー承認のフロー
---
sequenceDiagram
    participant BA as バックアップ管理者<br/>(テナント A)
    participant RSV as Recovery Services<br/>コンテナー<br/>(テナント A)
    participant RG as リソースガード<br/>(テナント B)
    participant SA as セキュリティ管理者<br/>(テナント B)
    
    Note over BA,SA: 通常のバックアップ削除操作
    BA->>RSV: バックアップ削除を試行
    RSV->>RG: 承認を確認
    RG-->>RSV: 承認なし（拒否）
    RSV-->>BA: エラー: リソースガードによって保護されています
    
    Note over BA,SA: 承認プロセス
    BA->>SA: 承認を依頼（メール・チャット等）
    SA->>RG: テナント B にサインイン
    SA->>RG: 一時的な権限付与<br/>(PIM 等)
    
    Note over BA,SA: 承認後の削除操作
    BA->>RSV: リソースガードトークンを使って削除を再試行
    RSV->>RG: トークンを検証
    RG-->>RSV: 承認済み（許可）
    RSV-->>BA: 削除成功

承認プロセスの実施

保護された操作を実行するには、以下の手順で承認を取得します：

ステップ 1: バックアップ管理者が承認を依頼

バックアップ管理者は、セキュリティ管理者に対して、保護された操作の承認を依頼します。依頼方法は、メールやチャット、チケットシステムなど、組織の運用に合わせて行います。

ステップ 2: セキュリティ管理者が一時的な権限を付与

セキュリティ管理者は、依頼内容を確認し、正当な理由であれば、バックアップ管理者に対して一時的な権限を付与します。

オプション 1: Azure Privileged Identity Management (PIM) を使用

  1. テナント B で PIM を設定
  2. バックアップ管理者に対して、リソースガードの Backup MUA Operator ロールを一時的に付与（例：8時間）
  3. バックアップ管理者が PIM でロールをアクティブ化

オプション 2: 手動でロールを一時的に付与

Azure Portal でリソースガードのアクセス制御 (IAM) に移動し、バックアップ管理者に対して Backup MUA Operator ロールを一時的に付与します。操作完了後に削除してください。

バックアップ管理者に対して、リソースガードの Backup MUA Operator ロールを付与する設定が表示されている
権限付与画面:

ステップ 3: バックアップ管理者が作業を実行

  1. テナント A に戻り、Recovery Services コンテナーで変更操作を再試行
  2. 変更が成功
操作が成功した画面:

ステップ 4: 一時的な権限の削除

操作が完了したら、セキュリティ管理者は、付与した一時的な権限を削除します（PIM を使用している場合は、自動的に期限切れになります）。

Azure Portal のアクセス制御 (IAM) 画面。バックアップ管理者から Backup MUA Operator ロールが正常に削除された状態が表示されている
削除成功画面:

まとめ

別テナントリソースガードの効果

別テナントにリソースガードを配置することで、以下のセキュリティ強化が実現できます：

✅ テナント分離による攻撃範囲の限定

  • 攻撃者がテナント A を侵害しても、テナント B のリソースガードには到達できない

✅ 権限の分離と職務分担

  • バックアップ管理とセキュリティ管理を完全に分離

✅ 承認プロセスの強制

  • 重要な操作には必ず複数の管理者の関与が必要

✅ 監査証跡の確保

  • 誰がいつ承認したかの記録が残り、コンプライアンス要件を満たしやすい

セキュリティ強化のベストプラクティス

リソースガードを最大限に活用するために、以下のベストプラクティスを推奨します：

  1. PIM の活用

    • Azure Privileged Identity Management を使って、一時的な権限付与を自動化
    • 承認ワークフローや多要素認証を組み合わせる

  2. 最小権限の原則

    • バックアップ管理者には Reader 権限のみを付与
    • Contributor や Backup MUA Admin は付与しない

  3. 承認ポリシーの文書化

    • どのような場合に承認するかのポリシーを明確化
    • 承認依頼のテンプレートを用意

  4. 定期的なレビュー

    • リソースガードの設定を定期的に見直し
    • 不要なゲストユーザーの削除

  5. 論理的な削除の有効化

    • リソースガードと併用して、論理的な削除機能を有効化
    • 誤削除や攻撃後のリカバリ期間を確保

注意点と運用上の考慮事項

運用負荷の増加

マルチユーザー承認を導入すると、以下のような運用負荷が増加します：

  • 承認依頼と承認のやり取りが発生
  • 緊急時の対応手順を事前に整備する必要
  • 複数の管理者の調整が必要

これらを軽減するために、PIM を活用した自動化や、承認プロセスの明確化が重要です。

緊急時の対応

災害復旧など緊急時の対応については、以下を事前に準備しておきましょう：

  • オンコール体制の整備
  • 緊急連絡先の共有
  • Break Glass アカウントの準備（最終手段）

コストへの影響

リソースガード自体のコストは無料ですが、以下のコストが発生する可能性があります：

  • PIM のライセンス（Microsoft Entra ID P2）
  • ゲストユーザーの外部アクセスに関連するコスト（通常は無料範囲内）

リージョンの制約

リソースガードと Recovery Services コンテナーは同じリージョンに配置する必要があるため、グローバル展開している場合は、リージョンごとにリソースガードを作成する必要があります。

今後の展開

リソースガードによる保護をさらに強化するために、以下のような施策も検討できます：

  • Azure Policy との組み合わせ
    • すべての Recovery Services コンテナーでリソースガードを強制
  • モニタリングと アラート
    • リソースガードの操作ログを Azure Monitor で監視
    • 承認要求が発生した際のアラート設定
  • 自動化とカスタムワークフロー
    • Logic Apps や Power Automate を使った承認ワークフローの構築

参考リンク

公式ドキュメント

関連トピック

以上、Azure Backup のリソースガードを別テナントに配置して、マルチユーザー承認を実装する方法について解説しました。ランサムウェア対策として、ぜひ導入を検討してみてください！

共有
Kento
著者
[Kento GitHub Copilot]
2020年に新卒で IT 企業に入社. インフラエンジニア（主にクラウド）として活動中

関連記事