Microsoft Entra に関する「Azure identity & access security best practices」で最初に押さえるべき結論は、IDをAzure環境の最重要な防御境界として扱い、MFA、条件付きアクセス、RBAC、特権管理、ワークロードIDへの移行をセットで見直す必要があるという点です。
特に影響が大きいのは、Azure CLI、Azure PowerShell、IaCツール、REST APIなどを使う管理・自動化作業です。ユーザーアカウントをサービスアカウント代わりに使っている環境では、MFA必須化の影響でスクリプトやCI/CDが止まる可能性があります。管理者は条件付きアクセスや特権ロールの棚卸しを、開発者は認証方式と自動化アカウントの移行を優先して確認しましょう。
Microsoftの公式ベストプラクティスでは、Microsoft Entra IDを中心に、ID管理の一元化、SSO、条件付きアクセス、MFA、Azure RBAC、特権アカウント保護、疑わしいアクティビティの監視、ストレージ認証などを総合的に整備する方針が示されています。該当ページは2026年5月時点で更新されており、単なる推奨設定集ではなく、Azure運用の前提を「ネットワーク境界」から「ID境界」へ移すための実務チェックリストとして読むべき内容です。(Microsoft Learn)
Microsoft Entraのセキュリティ更新で重要なポイント
今回確認すべきポイントは、「新しい機能が1つ追加された」というより、Azure環境のID・アクセス管理をより厳格に運用する方向へ公式推奨が整理されている点です。中心になるのは、次の5つです。
| 確認ポイント | 影響を受けやすい対象 | すぐ確認すべきこと |
|---|---|---|
| Azure利用時のMFA必須化 | 管理者、運用担当、開発者、外部委託先 | CLI、PowerShell、IaC、REST APIで人間のユーザー認証を使っていないか |
| 条件付きアクセスの設計 | Microsoft 365、Azure、SaaS、業務アプリ利用者 | Security Defaultsとの関係、対象ユーザー、対象アプリ、除外条件 |
| ユーザー型サービスアカウントの廃止 | バッチ処理、CI/CD、監視スクリプト | マネージドIDまたはサービスプリンシパルへ移行できるか |
| Azure RBACと特権管理 | Azure管理者、セキュリティ担当、監査担当 | 永続的な高権限付与、個人への直接付与、過剰権限の有無 |
| 監視と継続改善 | 情シス、SOC、セキュリティ管理者 | サインインログ、Identity Secure Score、リスク検出の運用状況 |
Microsoftは、2025年10月1日からAzureのMFA必須化フェーズ2として、Azure CLI、Azure PowerShell、Azure mobile app、IaCツール、REST APIエンドポイントでの作成・更新・削除操作に強力な認証を求める内容を示しています。読み取り操作は対象外とされていますが、運用現場では「更新系の自動化が止まるかどうか」を重点的に確認する必要があります。(Microsoft Learn)
影響範囲は「管理者だけ」ではない
Microsoft EntraのID・アクセスセキュリティは、管理者アカウントだけの問題ではありません。Azure上のリソースを操作する人、アプリケーションからAzureへ接続する仕組み、外部ユーザー、オンプレミスActive Directoryと連携するハイブリッド環境まで影響します。
管理者への影響
管理者は、AzureポータルやMicrosoft Entra管理センターだけでなく、PowerShell、CLI、IaCツールを使った操作でもMFA対応を前提にする必要があります。
特に注意すべきなのは、次のような運用です。
| よくある運用 | リスク | 見直し方 |
|---|---|---|
| 管理者が日常業務用アカウントでAzureを管理している | メールやWeb閲覧経由の侵害が管理権限に直結する | 管理専用アカウントを分離する |
| Global Administratorを常時付与している | 侵害時の被害範囲が大きい | PIMで必要時だけ有効化する |
| 退職者・異動者の管理者権限が残っている | 不正利用や監査指摘につながる | 月次でロール割り当てを棚卸しする |
| 緊急用アカウントがない | 条件付きアクセスの誤設定でロックアウトする | 緊急アクセスアカウントを用意し、利用手順を文書化する |
公式ベストプラクティスでは、特権アカウントの公開時間を短くするためにMicrosoft Entra Privileged Identity Managementを有効化し、管理作業用アカウントを通常利用のアカウントから分離すること、さらに緊急アクセス用アカウントを定義することが推奨されています。(Microsoft Learn)
開発者・DevOpsへの影響
開発者やDevOps担当者が特に確認すべきなのは、自動化処理がユーザー名とパスワードに依存していないかです。
たとえば、次のような構成は見直し対象です。
| 見直し対象 | なぜ危険か | 推奨される方向性 |
|---|---|---|
| Azure CLIにユーザーアカウントでログインしてバッチ実行 | MFA要求で非対話処理が止まる可能性がある | マネージドIDまたはサービスプリンシパルに移行 |
AZURE_USERNAME と AZURE_PASSWORD を環境変数に設定 | パスワード認証に依存し、MFAや認証強化と相性が悪い | ワークロードIDベースの認証へ変更 |
| ROPCフローを使ったアプリ認証 | MFAと互換性がなく、将来的な運用リスクが高い | 認可コードフロー、デバイスコード、マネージドIDなどへ移行 |
| 個人アカウントでCI/CDを実行 | 退職・異動・MFA変更の影響を受ける | CI/CD専用のワークロードIDを使う |
MicrosoftのMFA必須化ドキュメントでは、ROPCフローはMFAと互換性がなく、MSALやAzure Identityライブラリでユーザー名・パスワード方式を使っている場合は変更が必要と説明されています。また、Azure Identityライブラリで DefaultAzureCredential や EnvironmentCredential を使い、AZURE_USERNAME と AZURE_PASSWORD を設定している構成も確認対象です。(Microsoft Learn)
Microsoft EntraにおけるワークロードIDには、アプリケーション、サービスプリンシパル、マネージドIDが含まれます。特にマネージドIDは、開発者が資格情報を管理せずにAzureリソースへアクセスできる仕組みとして位置付けられています。(Microsoft Learn)
管理者が確認すべきMicrosoft Entra設定
ID管理をMicrosoft Entraに一元化する
Microsoft Entraのベストプラクティスでは、オンプレミスとクラウドのディレクトリを統合し、1つの権威あるID基盤として運用することが推奨されています。ハイブリッドID環境では、Microsoft Entra Connectを使ってオンプレミスのActive DirectoryとMicrosoft Entra IDを同期する構成が一般的です。(Microsoft Learn)
ただし、同期すればよいわけではありません。特に注意すべきなのは、オンプレミスActive Directory側の高権限アカウントです。Domain AdminsやEnterprise Adminsなどの高権限アカウントをそのままクラウドに同期すると、クラウド侵害からオンプレミスへ横展開されるリスクがあります。公式ドキュメントでも、OUベースまたは属性ベースのフィルターで高権限アカウントを同期対象から除外する考え方が示されています。(Microsoft Learn)
実務では、次の順で確認すると効率的です。
| 確認項目 | 判断基準 |
|---|---|
| Microsoft Entraテナントが複数乱立していないか | 組織アカウントの権威あるソースが明確か |
| オンプレミスADとの同期範囲 | 高権限アカウントや不要なOUを同期していないか |
| パスワードハッシュ同期 | フェデレーション障害時のバックアップや漏えい資格情報検出に使えるか |
| 管理者アカウントの所在 | クラウド専用か、オンプレ同期か、役割ごとに整理されているか |
Security Defaultsと条件付きアクセスを混在させない
小規模な環境では、Security Defaultsを有効にするだけでも基本的な防御を始められます。Security Defaultsは、MFA登録の要求、管理者へのMFA要求、レガシー認証のブロック、Azureポータルなどの特権操作保護を含む基本的な設定です。Microsoftは、MFAとレガシー認証ブロックにより多くの一般的なID攻撃を防げると説明しています。(Microsoft Learn)
一方で、Microsoft Entra ID P1またはP2を利用していて、部門別・アプリ別・デバイス別に細かく制御したい場合は、条件付きアクセスを使うべきです。Microsoftの条件付きアクセス展開ガイドでは、Security Defaultsと条件付きアクセスは組み合わせて使うものではなく、条件付きアクセスポリシーを作成するとSecurity Defaultsを有効化できないと説明されています。(Microsoft Learn)
判断基準は次のとおりです。
| 環境 | 向いている設定 |
|---|---|
| 小規模で個別ポリシー設計が難しい | Security Defaults |
| Microsoft Entra ID P1/P2を利用している | 条件付きアクセス |
| 部門、場所、デバイス、アプリごとに制御したい | 条件付きアクセス |
| リスクベースのアクセス制御を使いたい | Microsoft Entra ID P2 + 条件付きアクセス |
| 既存ポリシーが複雑で段階展開したい | 条件付きアクセスのレポート専用モード |
条件付きアクセスは「全アプリを守る」発想で設計する
条件付きアクセスは、Microsoft Entraのアクセス制御の中心です。「誰が」「どのアプリへ」「どの場所から」「どのデバイスで」「どのリスク状態で」アクセスするかを評価し、MFA要求、デバイス準拠、ブロック、セッション制御などを適用できます。
設計時に避けたいのは、重要アプリだけを個別に守る場当たり的な設定です。Microsoftは、すべてのアプリに少なくとも1つの条件付きアクセスポリシーが適用されるようにすることを推奨しています。新しいアプリを追加するたびに手作業でポリシーを更新する運用は漏れが発生しやすいためです。(Microsoft Learn)
実務で最初に作るべきポリシーは、次のようなものです。
| 優先度 | ポリシー例 | 目的 |
|---|---|---|
| 高 | 管理者ロールには常にMFAを要求 | 特権侵害の防止 |
| 高 | レガシー認証をブロック | パスワードスプレー攻撃対策 |
| 高 | Azure管理操作にMFAを要求 | Azureリソース操作の保護 |
| 中 | 社外アクセス時にMFAまたは準拠デバイスを要求 | リモートワーク対策 |
| 中 | 高リスクサインイン時に追加認証またはブロック | 不審ログイン対策 |
| 中 | 準拠していないデバイスから重要アプリを制限 | 端末リスク対策 |
ブロックポリシーは強力ですが、誤設定すると管理者を含めて組織全体がアクセス不能になることがあります。Microsoftは、ブロック制御を大規模に有効化する前に、レポート専用モードやWhat Ifツールで影響を検証することを推奨しています。(Microsoft Learn)
What Ifツールで展開前に影響を確認する
条件付きアクセスの失敗で多いのは、「テストせずに本番有効化する」ことです。特に、全ユーザー・全クラウドアプリ・ブロック制御を組み合わせると、意図しないロックアウトを招く可能性があります。
Microsoft EntraのWhat Ifツールは、特定のユーザー、ワークロードID、クラウドアプリ、サインイン条件を指定して、どの条件付きアクセスポリシーが適用されるかをシミュレーションできます。手動で何度もサインインテストを行う代わりに、ポリシーの適用結果を事前に確認できます。(Microsoft Learn)
展開前には、少なくとも次のシナリオを確認しましょう。
| テストシナリオ | 確認すること |
|---|---|
| 通常ユーザーが社内からMicrosoft 365へアクセス | MFA要求が過剰になっていないか |
| 通常ユーザーが社外から重要アプリへアクセス | 追加認証または準拠デバイス要求が働くか |
| 管理者がAzureポータルへアクセス | MFAまたは強力な認証が必須になっているか |
| 緊急アクセスアカウントでサインイン | ロックアウト時に復旧できるか |
| 開発者がCLIやPowerShellで更新操作 | MFA要求や認証エラーの影響が出るか |
| 外部ユーザーやB2Bゲストのアクセス | 想定外にブロックされていないか |
開発者が確認すべき認証方式と移行ポイント
ユーザー型サービスアカウントを棚卸しする
Azure運用では、昔から「専用のユーザーアカウントを作り、パスワードをスクリプトに設定して処理を回す」運用が残っていることがあります。これは、MFA必須化と相性が悪いだけでなく、退職・異動・パスワード変更・条件付きアクセスの変更にも弱い構成です。
Microsoftは、ユーザーアカウントをサービスアカウントとして使っている場合、マネージドIDやサービスプリンシパルなどのワークロードIDへ移行することを推奨しています。ワークロードIDは自動化シナリオ向けに設計されており、MFAを必要としないため、より管理しやすい構成にできます。(Microsoft Learn)
棚卸しでは、次の場所を確認してください。
| 確認場所 | 見つかりやすい問題 |
|---|---|
| CI/CDツールの接続設定 | 個人アカウントでAzureにログインしている |
| Azure Automation Runbook | ユーザー名・パスワードで認証している |
| GitHub Actions / Azure DevOps | 古いサービス接続やシークレットが残っている |
| サーバー上のバッチファイル | az login 後のセッションや保存済み資格情報に依存している |
| 監視・運用スクリプト | 更新操作をユーザー認証で実行している |
| アプリケーション設定 | 環境変数にユーザー名・パスワードを保存している |
移行先は用途別に選ぶ
すべてを同じ認証方式へ移す必要はありません。Azure上で稼働するアプリ、外部CI/CD、オンプレミスサーバーからの操作では、適した移行先が異なります。
| 用途 | 推奨される移行先 | 補足 |
|---|---|---|
| Azure VM、App Service、FunctionsからAzureリソースへアクセス | マネージドID | 資格情報をコードや環境変数に置かずに済む |
| GitHub ActionsやAzure DevOpsからAzureへデプロイ | サービスプリンシパルまたはフェデレーション資格情報 | 長期シークレットの管理を減らす設計が望ましい |
| オンプレミスサーバーの運用スクリプト | サービスプリンシパル、証明書ベース認証など | 個人ユーザーのMFA変更に依存しない |
| 人間が一時的に管理作業を行う | MFAまたはフィッシング耐性のある認証 | パスキー、FIDO2、Windows Hello for Businessなどを検討 |
| 特権ロールの一時利用 | PIM | 必要な時間だけ権限を有効化する |
Microsoftは、フィッシング耐性のあるパスワードレス認証として、パスキー、FIDO2セキュリティキー、Windows Hello for Business、証明書ベース認証などを挙げています。MFAは重要ですが、SMSや音声通話だけに依存するのではなく、管理者や高リスクユーザーから段階的にフィッシング耐性のある方式へ移すのが実務的です。(Microsoft Learn)
Azure RBACと特権アクセスの見直し
個人に直接権限を付与しない
Azure RBACは、Azureリソースに対して「誰が」「何を」「どの範囲で」できるかを管理する仕組みです。サブスクリプション、リソースグループ、個別リソースといったスコープに対して、ユーザー、グループ、アプリケーションにロールを割り当てられます。(Microsoft Learn)
実務上の基本は、個人ではなくMicrosoft Entraグループにロールを割り当てることです。個人に直接権限を付け続けると、異動や退職時に権限が残りやすく、監査も難しくなります。
| 悪い例 | 改善例 |
|---|---|
| 個人ユーザーにOwnerを直接付与 | 管理者グループに必要最小限のロールを付与 |
| リソースごとにバラバラな権限付与 | 管理グループ、サブスクリプション、リソースグループ単位で整理 |
| 全員にContributorを付与 | 運用、閲覧、セキュリティ、開発の役割ごとに分離 |
| 退職者の権限を手作業で探す | グループメンバーシップとアクセスレビューで管理 |
Microsoftの公式ベストプラクティスでも、リソース固有・ユーザー固有の権限付与は構成が複雑になりやすいため、企業全体では管理グループ、サブスクリプション内ではリソースグループ、権限付与ではMicrosoft Entraグループを使う考え方が示されています。(Microsoft Learn)
セキュリティチームには見える権限を付ける
セキュリティチームがAzureリソースを確認できないと、リスク評価やインシデント対応が遅れます。運用権限まで付ける必要がない場合でも、Security Readerなどの閲覧権限を適切なスコープで付与することが重要です。
一方、Microsoft Defender for Cloudの推奨事項やアラート対応を行うチームには、Security Adminなど追加の権限が必要になる場合があります。公式ベストプラクティスでも、セキュリティチームの責任範囲に応じて、ルート管理グループまたはセグメント管理グループで必要なロールを割り当てる考え方が示されています。(Microsoft Learn)
条件付きアクセス展開時の失敗しやすいポイント
条件付きアクセスは強力ですが、設計を誤ると業務影響が大きくなります。展開時は、次の失敗を避けてください。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| レポート専用モードを使わず本番有効化する | 業務アプリや管理者が突然アクセス不能になる | テストグループ、レポート専用、What Ifで段階確認する |
| 緊急アクセスアカウントを除外していない | 誤設定時に管理者全員がロックアウトする | ブレークグラス用アカウントを準備し、監視対象にする |
| Security Defaultsと条件付きアクセスの関係を理解していない | 設定が競合しているように見え、運用が混乱する | P1/P2環境では条件付きアクセス中心に設計する |
| 全リソース + ブロック制御を安易に使う | Microsoft Graphなど重要な依存関係で想定外の影響が出る | ブロックは範囲を絞り、必ず事前検証する |
| 国・地域ベースのブロックを過信する | VPN、出張、クラウドプロキシで誤判定が起きる | ネットワーク条件だけでなくMFAやデバイス条件と組み合わせる |
| レガシー認証を残す | パスワードスプレー攻撃の入口になる | レガシー認証の利用状況を確認して段階的にブロックする |
| ポリシーを作りすぎる | 管理不能になり、例外設定が増える | 役割・アプリ分類ごとに標準化する |
ネットワーク条件については、Microsoft Entraではユーザーの場所をパブリックIPアドレスやMicrosoft AuthenticatorアプリのGPS情報から判定します。特定の国・地域をブロックする用途には使えますが、VPNやクラウドプロキシ環境では想定と異なるIPで評価されることがあるため、単独の防御策として過信しないほうが安全です。(Microsoft Learn)
ストレージ認証もMicrosoft Entra IDへ寄せる
Azure Storageを使っている場合は、ストレージアカウントキーや接続文字列に依存した運用も見直し対象です。Microsoftのベストプラクティスでは、Blob StorageとQueue Storageについて、Microsoft Entra IDを使った認証・認可がサポートされており、Azure RBACでコンテナーやキューのスコープまで権限を付与できると説明されています。(Microsoft Learn)
実務では、次の順で移行を検討します。
| 現在の運用 | 移行の方向性 |
|---|---|
| ストレージアカウントキーをアプリ設定に保存 | Microsoft Entra ID認証 + RBACへ移行 |
| 複数アプリで同じキーを共有 | アプリごとにマネージドIDを分ける |
| キーのローテーション手順がない | キー依存を減らし、必要な場合はローテーションを定期化 |
| 開発者が広範なストレージ権限を持つ | コンテナー単位など必要最小限のロールにする |
ストレージキーは便利ですが、漏えいすると広範なアクセスにつながる場合があります。Microsoft Entra ID認証へ寄せることで、「誰が」「どのアプリが」「どの範囲へ」アクセスできるかをRBACで管理しやすくなります。
導入・移行の実務手順
Microsoft EntraのID・アクセスセキュリティを見直す場合、最初からすべてを厳格化しようとすると失敗しやすくなります。実務では、影響の大きい箇所から順に進めるのが安全です。
| フェーズ | 作業内容 | 完了基準 |
|---|---|---|
| 現状把握 | 管理者、一般ユーザー、外部ユーザー、サービスアカウント、ワークロードIDを棚卸し | 高権限アカウントと自動化アカウントが一覧化されている |
| MFA確認 | 管理者・Azure操作ユーザー・高リスクユーザーのMFA状況を確認 | Azure管理操作にMFAまたは強力な認証が適用されている |
| 条件付きアクセス設計 | 対象ユーザー、対象アプリ、除外、ブロック条件を定義 | レポート専用モードで影響を確認できている |
| 自動化移行 | ユーザー型サービスアカウントをマネージドIDやサービスプリンシパルへ移す | CLI、PowerShell、IaC、CI/CDが非対話で安定稼働する |
| RBAC整理 | 個人付与、過剰権限、永続的な高権限を見直す | グループベース・最小権限・PIM利用に近づいている |
| 監視整備 | サインインログ、リスク検出、Identity Secure Scoreを運用に組み込む | 月次レビューとインシデント時確認手順がある |
Microsoftの条件付きアクセス展開ガイドでも、テストユーザーやテストグループを用意し、ユーザーへの変更連絡を行うことが重要とされています。条件付きアクセスは柔軟性が高い反面、計画不足だと望ましくない結果を招くため、展開前の設計と検証が欠かせません。(Microsoft Learn)
運用開始後に見るべきログと指標
設定して終わりではなく、Microsoft Entraは継続的に改善する運用が前提です。公式ベストプラクティスでも、Identity Secure Scoreを使ってセキュリティ体制を測定し、改善計画に役立てることが推奨されています。また、疑わしいサインイン、ブルートフォース、複数場所からのサインイン、感染デバイス、疑わしいIPアドレスなどを監視する考え方も示されています。(Microsoft Learn)
月次レビューでは、次の項目を見ると効果的です。
| 項目 | 確認内容 |
|---|---|
| サインインログ | 失敗サインイン、MFA失敗、未知の場所からのアクセス |
| 条件付きアクセスのレポート | レポート専用ポリシーの影響、ブロック件数、例外の増加 |
| 管理者ロール | Global Administrator、Privileged Role Administrator、Ownerの棚卸し |
| サービスプリンシパル | 使われていないアプリ登録、期限切れ証明書、過剰なAPI権限 |
| ワークロードID | 退役済みシステムのIDが残っていないか |
| Identity Secure Score | 改善推奨事項の優先順位と進捗 |
| レガシー認証 | まだ利用しているクライアントやアプリがないか |
よくある疑問
Security Defaultsだけで十分ですか？
小規模でMicrosoft Entra ID Free中心の環境なら、Security Defaultsは有効な第一歩です。ただし、部門ごとにMFA条件を変えたい、準拠デバイスを条件にしたい、リスクベース制御を使いたい、特定アプリだけ厳格化したい場合は条件付きアクセスが必要です。Microsoftも、P1またはP2ライセンスを持つ組織や複雑なセキュリティ要件がある組織には、条件付きアクセスを検討するよう説明しています。(Microsoft Learn)
MFA必須化で自動化処理はすべて止まりますか？
すべてが止まるわけではありません。影響が大きいのは、ユーザーIDでAzureにサインインして自動化している処理です。マネージドIDやサービスプリンシパルなどのワークロードIDを使っている処理は、MFA必須化の対象外として扱われます。ユーザーアカウントをサービスアカウント代わりに使っている処理を優先して棚卸ししてください。(Microsoft Learn)
条件付きアクセスの最初のポリシーは何から始めるべきですか？
最初は、管理者MFA、レガシー認証ブロック、Azure管理操作へのMFA要求から始めるのが実務的です。その後、全ユーザーのMFA、社外アクセス、準拠デバイス、高リスクサインインへの対応へ広げます。いきなり全ユーザー・全アプリ・ブロック制御を本番有効化するのは避け、レポート専用モードとWhat Ifで検証してください。
P1とP2の違いは何を基準に判断すべきですか？
基本的な条件付きアクセスであればP1が中心です。ユーザーリスクやサインインリスクに基づく制御、Identity Protection、PIMなどを本格的に使う場合はP2が必要になる場面があります。特権管理やリスクベースアクセスを厳格に運用したい組織は、P2の必要性を早めに確認しましょう。Microsoftの条件付きアクセス展開ガイドでも、リスクを条件に含めるにはMicrosoft Entra ID P2が必要とされています。(Microsoft Learn)
まず着手すべき4つのアクション
Microsoft Entraの「Azure identity & access security best practices」を実務に落とし込むなら、次の4つから始めるのが効果的です。
| 優先順位 | アクション | 理由 |
|---|---|---|
| 1 | Azure操作ユーザーのMFA状況を確認する | 管理者・開発者・外部委託先の侵害リスクを下げるため |
| 2 | ユーザー型サービスアカウントを棚卸しする | MFA必須化で自動化が止まるリスクを避けるため |
| 3 | 条件付きアクセスをレポート専用で設計する | 業務影響を確認しながら段階展開するため |
| 4 | Azure RBACとPIMで特権を整理する | 過剰権限と永続的な管理者権限を減らすため |
Microsoft Entraのセキュリティ対策は、単発の設定変更ではなく、IDを中心にAzure全体のアクセスを見直す取り組みです。最初にMFAとサービスアカウントの影響を確認し、次に条件付きアクセス、RBAC、PIM、監視へ広げていくことで、業務停止を避けながらゼロトラストに近い運用へ移行できます。
コメント