関連するソリューション
セキュリティサービス
セキュリティ製品
サイバー・セキュリティ・ソリューション部
テクニカルスペシャリスト
ボル カーステン
Entra ID・Azure 管理者必読：アクセス設定の確認
Microsoft社が提供するAzureを利用されている皆様、特に管理者の方々に重要な確認事項があります。まず、Azureポータルにログインしてみてください。次に、[Microsoft Entra ID] > [管理] > [プロパティ] の順に進み、 [Azure リソースのアクセス管理] の項目が「はい」になっているか確認してください。
| Azureリソースのアクセス管理 |
| <ユーザー名> (<ユーザーメール>)テナント内のすべてのAzureサブスクリプションおよび管理グループへのアクセスを管理できます。 はい |
実は、この設定はEntra IDにおける最高レベルの管理権限に関わる重要な項目です。AzureサブスクリプションはMicrosoft Entraテナントと信頼関係を築いており、このEntraテナントは、サブスクリプションおよびその内部リソースに対するロールベースのアクセス制御に使用される、すべてのユーザーIDを管理するディレクトリサービスを提供しています。
参考: 全体管理者のアクセス権を昇格する
これから、この機能の詳細と、セキュリティ対策について説明いたします。また、Azureの権限管理の概念についても少しお話ししたいと思います。
Entra テナント及び、Azure の権限管理構造
ユーザー、グループ、サービスプリンシパル、またはマネージドID（簡潔にいうと特別なタイプのサービスプリンシパル）に対して、サブスクリプション、リソースグループ、リソース、または管理グループといった特定のスコープでロールを付与します。Entraテナントがあり、その階層の下にサブスクリプションが存在し、さまざまなリソースが含まれています。サブスクリプションを作成する際には、特定のEntraテナントを信頼します。
Entraテナントの配下には、組織内のすべてのサブスクリプションが信頼するルートオブジェクトがあります。このルートオブジェクトは、Entraテナントの直下に位置していると考えることができます。
このルートオブジェクトの下には、ルート管理グループがあり、その下にさまざまな管理グループの階層を形成することができます。
最終的に、サブスクリプションは、特定の管理グループに関連付けられます。デフォルトでは、新しいサブスクリプションを作成してテナントを信頼すると、このルート管理グループに関連付けられますが、必要に応じて移動することができます。
このルート管理グループは、ポータルにアクセスすることで確認できます。確認する際、EntraテナントのテナントIDに注目してください。例としてこのIDは「84865」で終わると考えてください。
次に、Azureで管理グループを確認すると、「テナントルートグループ」があります。テナントルートグループを確認するとIDが表示されますが、これはEntra IDと同じです。したがって、ルート管理グループはEntra IDと同じ識別子を持ちます。
管理のニーズに応じて、さまざまな管理グループを作成し、継承されるロールベースのアクセス制御や特定のポリシー、予算などを設定することが可能です。EntraのロールとAzureのロールについて話す際、通常、Entraで持っている権限はAzureのリソースには継承されませんが、一つ例外があります。
オーナー不在のサブスクリプション
組織内でよくあるシナリオとして、異なるサブスクリプションに、それぞれ異なるオーナーがいる場合があります。サブスクリプションのオーナーは、そのサブスクリプションレベルで権限を設定できる唯一の人物になります。
そのため、もしオーナーが退職してしまうと、そのサブスクリプションはオーナー不在の状態となり、誰も権限を設定できなくなります。ここで登場するのが、Entraのグローバル管理者、つまりAzureの最強アカウントです。ベストプラクティスに従い、グローバル管理者の数は極力少なくすることが推奨されます。なぜならば、グローバル管理者は、Entraテナント全体のIDを管理するからです。
IDは、セキュリティにおける最初の境界です。クラウド専用のブレークグラス緊急用グローバル管理者アカウントが2つあり、これらのアカウントは耐火金庫などの安全な場所に保管されたハードウェアFIDOパスキーで管理すべきです。
参考:Microsoft Entra ID で緊急アクセス用管アカウントを管理する
また、ブレークグラス緊急用のグローバル管理者アカウント以外に、グローバル管理者であるごく少数のユーザーは、常にPrivileged Identity Management（PIM）を使用すべきです。これにより、必要なときにのみ(ジャストインタイム)グローバル管理者権限に一時的に昇格できます。
権限昇格を行うと、冒頭で述べたスライダーを「いいえ」から「はい」に変更することが可能になります。このスライダーを「はい」に設定すると、ルートレベルで「ユーザーアクセス管理者」と呼ばれる権限が付与されます。これにより、Entra IDの権限を通じて、Azureの権限を管理できるようになります。これが、先ほど述べた例外に該当します。
参考:Microsoft Entra Privileged Identity Management とは
※例のスライダーを「いいえ」から「はい」にスライドすることで、ユーザーアクセス管理者権限を得ます(昇格アクセス)。
設定適用後、ポータル内で「ルート管理グループ」を確認し、その「アクセス制御（IAM）」からロールの割り当てを確認すると、「ユーザーアクセス管理者」の権限が付与されていることが確認できます。
| 名前 | 種類 | 役割 | スコープ | 条件 |
|---|---|---|---|---|
| ~省略~ ユーザーアクセス管理者 |
||||
| ユーザー名 |
ユーザー |
ユーザーアクセス管理者 |
ルート(継承済) | なし |
| ~省略~ | ||||
参考:手順 1の5.
ここで重要なのは、どのスコープで権限が付与されているかということ点です。現在確認しているルート管理グループはEntraテナントの直下に位置していますが、このルート管理グループは親であるルートから権限を継承しています。
ユーザーアクセス管理者の権限の詳細
「ユーザーアクセス管理者」のロールの詳細を確認すると、ほとんど読み取りの権限しかありませんが、特に注目すべきは「Microsoft.Authorization/roleAssignments/」に関する権限です。
このロール単独では、管理者と同様の権限を持つわけではありません。しかし、「ユーザーアクセス管理者」の興味深い点は、「Microsoft.Authorization/roleAssignments/」に対する「write」権限、つまり、ロールの割り当てをできる書き込み権限を持っていることです。
参考:ユーザーアクセス管理者の権限
管理グループとその階層における重要なポイントは、権限が下位に継承されることです。つまり、ルート管理グループの最上位で設定された権限は、すべての下位レベルに継承されます。
したがって、グローバル管理者が、Azureのアクセス管理権限のロールをルートで取得すると、その権限はすべてのサブスクリプション、すべての管理グループ、すべてのリソースグループ、そして存在するすべてのリソースに対しても適用されます。
※図の赤い点線で囲まれた部分は、アクセス管理者に昇格したことによって得られた権限を示しています。
これにより、オーナー不在のサブスクリプションに対し、自分自身にオーナーロールを付与するか、他の誰かにオーナーロールを付与することができます。
ここで非常に重要なポイントがあります。この権限は常に有効にしておくべきではありません。
なぜなら、あらゆるAzureリソースに対して自分自身に権限を付与できるためです。この権限は、オーナー不在のサブスクリプションに対し、誰かにオーナー権限を付与する必要がある場合など、絶対に必要なときにのみ有効にし、その作業が完了したら、すぐにスライダーを「いいえ」に戻すべきです。常に「はい」のままにしておくと非常に危険です。
前述したPIM（Privileged Identity Management）について思い出してください。PIMを利用してグローバル管理者の権限を取得し、スライダーを「はい」にすることで、ルートレベルでユーザーアクセス管理者のロールが付与されます。
しかし、PIMによって権限が自動的に削除された場合でも、このスライダーは自動的に「いいえ」には戻りません。また、ユーザーアクセス管理者の権限も削除されません。そのため、作業が完了した後は、手動でスライダーを「いいえ」にすることにより、ユーザーアクセス管理者の権限を削除する必要があります。
昇格アクセス監査ログ、また確認方法
誰がこの操作を行っているのか確認したい場合、ドキュメントにはさまざまな方法が記載されていますが、最も簡単な方法は、ルート管理グループを確認することです。
そこで、誰がユーザーアクセス管理者の権限を持っているのかを確認できます。ルートから継承されているユーザーアクセス管理者権限を持つユーザーがいる場合、そのユーザーがスライダーを「はい」にしている証拠となります。
| 名前 | 種類 | 役割 | スコープ | 条件 |
|---|---|---|---|---|
| ~省略~ ユーザーアクセス管理者 |
||||
| ユーザー名 | ユーザー | ユーザーアクセス管理者 |
ルート(継承済) |
なし |
| ~省略~ | ||||
また、最近新しく追加されたプレビュー機能についてもご紹介いたします。それは、Microsoft Entra ディレクトリ監査ログにおける「昇格アクセスログエントリ」です。
このスライダーを「はい」または「いいえ」に変更すると、監査ログに記録されるようになります。これにより、完全な可視性が得られます。具体的には、Entraの監査ログにエントリが追加されます。スライダーを「はい」にするとエントリが追加され、「いいえ」にすると別のエントリが追加されます。もちろん、他のさまざまな操作も記録されます。
Azureサブスクリプションでもこれを確認できます。Azureでは、Entraテナントは特定のサブスクリプションのディレクトリサービスとして機能します。したがって、Azureのアクティビティログを確認すると、ディレクトリサービスログのオプションがあり、誰かがこのスライダーを「はい」または「いいえ」に変更した場合、その操作が表示されます。これにより、実際に誰がこの機能を使用しているのかをしっかりと把握できるようになります。
ディレクトリサービスは、すべてのサブスクリプション間で共有されていることを忘れないでください。そのため、ディレクトリアクティビティを確認する際、どのサブスクリプションを見ても同じ情報が表示されます。これは、すべてのサブスクリプションが同じディレクトリを使用しているためです。
参考:Azure portal を使用してアクセス権の昇格ログのエントリを表示する
現在の課題の一つは、ディレクトリアクティビティを確認する際に、エクスポートオプションがないことです。しかし、Entraで、アイデンティティは以下のモニタリングを選択し、監査ログを確認すると、いくつかの操作が可能です。
まず、サービスのオプションを「すべて」から「Azure RBAC（Elevated Access）」に変更し、「適用」をクリックします。
これにより、ユーザーアクセス管理者ロールがユーザーから削除されたことや、ユーザーがユーザーアクセス管理者ロールに昇格したことなど、詳細な情報を確認できます。
参考:昇格アクセス ログ エントリを表示する
さらに、この監査ログにはエクスポートログデータ設定があり、診断設定を利用することができます。診断設定を使用することで、ストレージアカウント、イベントハブ、またはLog Analyticsワークスペースにログデータを送信することが可能です。監査ログを1年間など保存する必要がある場合は、この機能を有効化することをお勧めします。
Entra IDの診断設定を利用することで、コストを抑えてデータを保存したい場合は、ストレージアカウントにデータを送信することが可能です。これらのイベントを受信する他のシステムと統合する必要がある場合は、データをイベントハブに送信できます。より詳細な分析や他のシステムをトリガーするためには、データをLog Analyticsワークスペースに送信することもできます。
Microsoft Sentinelもあります。SentinelにはEntra IDコネクタがあり、Log Analyticsワークスペースを活用しています。このSentinelのEntra IDコネクタは、Azure RBACのアクセス昇格イベントを分析することができます。これにより、アクセス昇格イベントに対してアクションを実行したり、トリガーを設定したりすることが可能です。
参考:Microsoft Sentinel を使用して昇格アクセス イベントを検出する
最後に
重要な点は、Entra IDのグローバル管理者がどのような権限を持っているかを理解することです。現在では、その権限の使用状況を詳細に把握し、いつ操作が行われたかを確認することが可能になりました。
今回の内容で、グローバル管理者がEntra IDだけでなく、Azureリソースに対しても大きな権限を持っていることを学びました。これが、グローバル管理者のアクセスを制限し、適切に管理する必要がある理由の一つです。
しかし、この新しいMicrosoft Entra ディレクトリ監査ログ機能のおかげで、権限の昇格がいつ行われたかを完全に把握できるようになりました。
ぜひ、この新機能を活用して継続的に監視していきましょう。
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。
