Azure の管理グループを作成して Azure Policy を適用してみる

Microsoft Azure には、Azure サブスクリプションを束ねて管理できるサービスとして「管理グループ」機能があります。さらに、この管理グループ単位で特定のアクションを禁止したり、非準拠となるリソース設定を検出したりできる Azure ポリシーを割り当てることを割り当て可能です。本ブログでは、管理グループの作成と管理グループへ Azure ポリシーの割り当てを実際に試してみます。

管理グループの設計に関する考慮事項や推奨事項は次のドキュメントに記載があり、参考になります。

• 管理グループ - Cloud Adoption Framework | Microsoft Learn

Azure ポリシーには「効果（effect）」というポリシーが評価されたときの動作を決める項目があり、主な効果には下表があります。今回のブログでは、deny と audit の効果を持つポリシー定義を試してみます。

他の効果については次の Microsoft Learn ドキュメントに記載があります。

• Azure Policy 定義の効果の基本 - Azure Policy | Microsoft Learn

管理グループの作成

始めに、管理グループの設定を試してみます。
シンプルな構成として、Root の配下に中間管理グループを作成し、中間管理グループの配下に Workloads グループと Sandbox グループを作成してみます。

作業前の状態は 3 つのサブスクリプションが全て Root 直下にある状態です。

まずは、中間管理ルートとして IntermediateRoot 管理グループを作成してみます。
Azure ポータルの管理グループサービスにおいて。「構成」メニューの「作成」をクリックして進めます。

管理グループを識別する ID と表示名を入力して「Submit」を実行します。なお、ID は後から変更できず、表示名は後から変更できます。

IntermediateRoot 管理グループが作成されました。

次に、IntermediateRoot 管理グループ配下に Workloads 管理グループを作成します。
この場合は、IntermediateRoot 管理グループ横の「…」の設定から「ここで子グループを作成」を選択します。

管理グループの ID と表示名を入力して「Submit」を実行します。

IntermediateRoot 管理グループ配下に Workloads 管理グループが作成されたことを確認できました。

同じ要領で IntermediateRoot 管理グループ配下に Sandbox 管理グループを作成した後の状態です。

続いて、サブスクリプションが所属する管理グループを変更してみます。
workload-01 サブスクリプションを Workloads 管理グループに移動させます。workload-01 サブスクリプション横の「…」から「移動」を選択します。

「新しい親管理グループ」に移動先の管理グループとなる Workloads を選択して「保存」を実行します。

workload-01 サブスクリプションが Workloads 管理グループ配下に変更されました。

同様の手順で、sandbox-01, sandbox-02 サブスクリプションを Sandbox 管理グループに移動させた後の状態です。

以上で、管理グループの作成とサブスクリプションの移動は終わりです。
以降では、作成した管理グループに対して Azure ポリシーを割り当ててみます。

deny 効果の Azure ポリシーの割り当て

本番環境のサブスクリプションが格納される想定の Workloads 管理グループに対して、利用できるリージョン（ロケーション）を制限する deny 効果の Azure ポリシーを割り当ててみます。

利用できるリージョンを制限するポリシー定義は下記の名前で組み込みで用意されているため、今回はこのポリシー定義を利用します。

• ポリシー定義名：許可されている場所（Allowed locations）
• 定義 ID：/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c

Azure ポリシーの設定

Azure ポータル上で「ポリシー」などの文字列で検索して Azure ポリシーの設定画面を開きます。

「定義」メニューからポリシー定義を選択して割り当てる方法と「割り当て」メニューから割り当てる方法など複数の設定方法があります。今回は「割り当て」メニューから実行してみます。「割り当て」メニューから「ポリシーの割り当て」をクリックします。

「基本情報」タブでは、下表の設定を指定してみます。他はデフォルトの設定としています。

「パラメーター」タブでは、利用できるリージョン（制限されないリージョン）として日本国内の Japan East, Japan West の 2 つのリージョンを指定します。

「修復」タブでは、今回は deny 効果であり、修復が発生しないことからマネージド ID を作成しないようにしています。

「コンプライアンス非対応のメッセージ」タブでは、許可されていないリージョンで操作した際に利用者に表示するメッセージとして「管理者により利用を制限されています」との文章を指定してみます。

最後に「レビューと作成」タブで設定に問題ないか確認して、問題なければ「作成」を実行します。

以上で設定は完了です。

作成したポリシーが割り当てポリシー一覧に表示されていることを確認できました。スコープも Workloads 管理グループになっています。

動作確認

試しに workload-01 サブスクリプションに対して East US リージョンでストレージアカウントを作成しようとしてみると、指定したメッセージと共に警告が表示されました。

「ポリシーの詳細」リンクをクリックすると、ポリシー内容が確認できる下記の画面が表示されました。パラメーター値から許可されているリージョンを確認できます。

ストレージアカウントの作成において Japan East リージョンを選択した場合は、警告メッセージは表示されなくなりました。想定どおりです。

また、Azure ポリシーを割り当てしていない Sandbox 管理グループ配下にある sandbox-1 サブスクリプションでは East US リージョンを選択している場合でも警告メッセージは表示されませんでした。こちらも想定どおりです。

許可されていないリージョンで利用を制限できていることを確認できました。

なお、「許可されている場所」のポリシー定義としては、リソースグループの作成やグローバルサービスの利用は制限されない動作となります。参考までに組み込みのポリシー定義の詳細は下記となります。

{
  "properties": {
    "displayName": "許可されている場所",
    "policyType": "BuiltIn",
    "mode": "Indexed",
    "description": "このポリシーでは、リソースをデプロイするときに組織が指定できる場所を制限できるようになります。geo コンプライアンス要件を適用するときに使用します。リソース グループ、Microsoft.AzureActiveDirectory/b2cDirectories、'グローバル' リージョンを使用するリソースは除外されます。",
    "metadata": {
      "version": "1.0.0",
      "category": "General"
    },
    "version": "1.0.0",
    "parameters": {
      "listOfAllowedLocations": {
        "type": "Array",
        "metadata": {
          "description": "リソースのデプロイ時に指定できる場所の一覧。",
          "strongType": "location",
          "displayName": "許可されている場所"
        }
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "location",
            "notIn": "[parameters('listOfAllowedLocations')]"
          },
          {
            "field": "location",
            "notEquals": "global"
          },
          {
            "field": "type",
            "notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }
  },
  "id": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c/versions/1.0.0",
  "type": "Microsoft.Authorization/policyDefinitions/versions",
  "name": "1.0.0"
}

audit 効果の Azure ポリシーの割り当て

すべてのサブスクリプションを対象に、パブリック公開のリソースを検出する audit 効果の Azure ポリシーを試してみます。すべてのサブスクリプションを対象にするため、中間管理ルートに対して割り当ててみます。

複数のポリシー定義をまとめたイニシアティブ定義として、複数サービスのパブリック公開リソースを検出する定義が組み込みで用意されているため利用してみます。

• イニシアティブ定義名：パブリック ネットワーク アクセスの監査（Audit Public Network Access）
• 定義 ID：/providers/Microsoft.Authorization/policySetDefinitions/f1535064-3294-48fa-94e2-6e83095a5c08

Azure ポリシーの設定

Azure ポータル上で「ポリシー」などの文字列で検索して Azure ポリシーの設定画面を開きます。
「割り当て」メニューから「イニシアティブの割り当て」をクリックします。

「基本情報」タブでは、下表の設定を指定してみます。他はデフォルトの設定としています。

「パラメーター」タブでは、イニシアティブ定義に含まれているポリシー定義毎に効果を選択します。今回はすべて Audit 効果としています。

「修復」タブでは、今回は Audit 効果であり、修復が発生しないことからマネージド ID を作成しないようにしています。

「コンプライアンス非対応のメッセージ」タブでは、メッセージなしとしています。

最後に「レビューと作成」タブで設定に問題ないか確認して、問題なければ「作成」を実行します。

以上で設定は完了です。
割り当てポリシー一覧に作成したイニシアティブが表示されていることが確認できました。スコープも IntermediateRoot 管理グループになっています。

動作確認

試しに workload-01 サブスクリプションと sandbox-01 サブスクリプションの両方において、ストレージアカウントのパブリックネットワークアクセス設定を有効にしておき、検出されることを確認してみます。ストレージアカウントの設定では「Public network access」を Enabele にして（下図）、さらに「BLOB 匿名アクセスを許可する」も有効にしている状態です。

非準拠リソースの確認は「コンプライアンス」メニューから確認できます。Azure ポリシーの一覧の中から作成した「パブリック ネットワーク アクセスの監査」を選択します。

イニシアティブ定義に含まれる複数のポリシーが表示されるため、ストレージアカウントのパブリックアクセスに関する「ストレージ アカウントでパブリック ネットワーク アクセスを無効にする必要がある」を選択します。

workload-01 サブスクリプションと sandbox-01 サブスクリプションのストレージアカウントがコンプライアンス非対応になっていることを確認できました。

イニシアティブ定義に含まれるサービスのパブリック公開を検出して確認できました。

さいごに

管理グループを作成して、その管理グループ配下のサブスクリプションに対して統制を行う一連の流れを試してみました。Azure ポリシーには今回試した効果以外にも、複数の効果があるため、要件に応じて使い分けていく必要がありそうです。他の効果についても、いつか試してみたいと思いました。
以上、このブログがどなたかのご参考になれば幸いです。