Entra ID SSO - Microsoft Entra ID SSO の推奨設定
Microsoft Entra ID（旧 Azure AD）で SaaS / AWS / 社内アプリへの SSO を構成する際の推奨設定。Conditional Access・MFA・Privileged Identity Management・Named Locations・監査ログの実装指針。
概念図
Entra ID SSO の全体像
Microsoft Entra ID は 2023 年に Azure AD からリネームされたクラウド ID プロバイダーで、Microsoft 365・Azure・AWS・SaaS・社内カスタムアプリに対する SSO のハブとして機能します。
Enterprise Applications ギャラリーに 1 万を超えるコネクタが登録されており、SAML・OIDC・パスワード代行（Password-based SSO）・Header-based SSO（Application Proxy 経由）などの方式で接続できます。
主な連携パターンは以下の通りです。
| 接続先 | 推奨フェデレーション方式 | 備考 |
|---|---|---|
| Microsoft 365 / Azure | ネイティブ | 同一テナントで自動連携 |
| AWS IAM Identity Center | SAML 2.0 | Entra ID を外部 IdP として登録、SCIM でユーザー / グループ同期 |
| Salesforce / ServiceNow / Workday | SAML 2.0 | ギャラリーアプリに設定済みテンプレートあり |
| Slack / Zoom / Box | SAML 2.0 または OIDC | SCIM プロビジョニング推奨 |
| GitHub Enterprise Cloud | SAML 2.0 | Enterprise Managed User で SCIM 対応 |
| 社内カスタムアプリ（モダン） | OIDC（Authorization Code + PKCE） | MSAL ライブラリを使用 |
| 社内カスタムアプリ（レガシー） | SAML 2.0 / WS-Fed | 既存の .NET / SharePoint 資産向け |
フェデレーションプロトコルは次のように使い分けます。
| プロトコル | 主な用途 | 特徴 |
|---|---|---|
| SAML 2.0 | 既存 SaaS・エンタープライズアプリ | XML ベース、幅広い互換性 |
| OpenID Connect (OIDC) | モバイル / SPA / 新規 API | OAuth 2.0 ベース、JWT、軽量 |
| WS-Federation | レガシーな .NET / SharePoint | 新規採用は非推奨 |
新規アプリでは OIDC、既存 SaaS では SAML 2.0 を使い、WS-Fed はレガシー互換用途に限定するのが現行の推奨です。
Conditional Access（条件付きアクセス）の推奨ポリシー
Conditional Access は Entra ID のゼロトラスト実装の中核で、「誰が」「どのデバイスで」「どこから」「どのアプリに」アクセスするかを評価し、許可・MFA 要求・ブロック・セッション制御の判断を行います。
まずはレポート専用モードで影響を確認し、本番適用する運用が鉄則です。
Microsoft が提供する Security Defaults やセキュリティベースラインテンプレート、および Zero Trust ガイドラインに準拠したベースラインポリシーを以下に整理します。
| # | ポリシー | 割り当て | 条件 | 制御 |
|---|---|---|---|---|
| 1 | 全ユーザー MFA 必須 | All users（Break-Glass 除外） | All cloud apps | Grant: Require MFA |
| 2 | レガシー認証ブロック | All users | Client apps: Exchange ActiveSync、Other clients（IMAP / POP / SMTP Basic / Legacy MAPI） | Block access |
| 3 | 管理者に Phishing-resistant MFA | Directory Roles: Global / Privileged Role Admin 等 | All cloud apps | Grant: Require authentication strength = Phishing-resistant MFA（FIDO2 / WHfB / 証明書） |
| 4 | 未登録デバイスの制限 | All users | 条件: Device state が Hybrid Entra Joined / Compliant でない | Block または Limited access（App Enforced Restrictions） |
| 5 | Named Locations で高リスク地域ブロック | All users | Locations: 業務外の国・匿名 IP（Tor 等） | Block access |
| 6 | サインインリスクで MFA / ブロック | All users | Sign-in risk = High | Block / Sign-in risk = Medium → Require MFA |
| 7 | ユーザーリスクで強制パスワード変更 | All users | User risk = High | Require password change + MFA |
| 8 | セッション制御 | All users | All cloud apps | Sign-in frequency 例: 管理者 4h、一般 24h、Persistent browser session = Never、unmanaged device → App Enforced Restrictions |
追加の注意点:
- Break-Glass アカウントは必ず全ポリシーから除外し、誤設定で全員ロックアウトされても復旧できるようにする
- レポート専用モードで 1〜2 週間運用してサインインログを確認し、想定外の影響が無いかを検証してから On にする
- 「認証強度（Authentication Strength）」機能を使うと、ポリシーごとに要求する MFA の種類（SMS 禁止、FIDO2 必須 など）をきめ細かく指定できる
- Identity Protection の Sign-in risk / User risk は Entra ID P2 ライセンスで利用可能
特権管理: PIM と Just-in-Time
Entra ID では特権管理の中核として Privileged Identity Management (PIM) を提供しており、管理者ロールを「恒久割当（Active）」ではなく「資格割当（Eligible）」にして、必要なときだけ昇格（JIT: Just-in-Time）するモデルが推奨されます。
グローバル管理者や特権ロール管理者は特にこのモデルを必須とし、常時特権を持つアカウントを最小化します。
推奨構成:
- Eligible 割当を基本にし、利用時は Activate 申請 → MFA → 承認フロー → 時間制限付きで昇格
- 承認者は該当ロールを持たない別の管理者（職務分掌）に設定する
- アクティベーション理由（チケット番号等）を必須にし、監査可能にする
- アクセスレビューを四半期ごとに実施し、長期間使っていない Eligible 割当は削除する
- Break-Glass アカウントを 2 つ用意する: クラウド専用（オンプレ同期しない）、.onmicrosoft.com ドメイン、FIDO2 / 長大パスワード、CA から除外、物理金庫保管、利用時にアラート発報
ロールごとの推奨最大アクティベーション時間の目安:
| ロール | 最大アクティベーション時間 | 承認 | MFA | 備考 |
|---|---|---|---|---|
| Global Administrator | 1 時間 | 必須 | Phishing-resistant MFA | 利用者は 2〜4 名以内、緊急時以外は使用しない |
| Privileged Role Administrator | 1 時間 | 必須 | Phishing-resistant MFA | PIM 設定を変更できる最上位 |
| Security Administrator | 2 時間 | 必須 | Phishing-resistant MFA | Defender / CA 管理 |
| Conditional Access Administrator | 2 時間 | 必須 | Phishing-resistant MFA | CA ポリシー変更 |
| Exchange / SharePoint Administrator | 4 時間 | 任意 | MFA | 日常運用 |
| User Administrator | 4 時間 | 任意 | MFA | ユーザー作成・パスワードリセット |
| Helpdesk / Password Administrator | 8 時間 | 任意 | MFA | 一次サポート業務 |
PIM は Entra ID P2 ライセンスが必要ですが、特権アカウント侵害の被害範囲を時間軸で限定できるため、管理者数が 10 名を超える組織では導入効果が大きい機能です。
監視・監査・ハイジーン
SSO ハブである Entra ID のログは、侵害の早期検知と事後調査の両面で最重要データです。
Entra ID の標準保持期間は短いため（監査ログは無料テナントで 7 日、P1 / P2 で 30 日）、Log Analytics / Microsoft Sentinel / ストレージアカウントに転送して長期保存し、アラートルールと連携させます。
主要ログと保存・監視指針:
| ログ種別 | 内容 | 推奨転送先 | 推奨保存期間 | 主なアラート例 |
|---|---|---|---|---|
| Audit logs | ディレクトリ変更（ユーザー作成、ロール割当、アプリ同意） | Log Analytics + Sentinel | 1〜2 年 | 特権ロール付与、アプリ同意付与 |
| Sign-in logs（対話 / 非対話） | ユーザー / サービスプリンシパルのサインイン | Log Analytics + Sentinel | 90 日〜1 年 | レガシー認証成功、異常地理、不可能な移動 |
| Risk events（Identity Protection） | サインインリスク / ユーザーリスク | Log Analytics + Sentinel | 1 年 | High risk sign-in、漏洩資格情報 |
| Provisioning logs | SCIM プロビジョニング結果 | Log Analytics | 90 日 | プロビジョニング失敗の急増 |
定期運用のハイジーンタスクも重要です。
- サービスプリンシパル / エンタープライズアプリの棚卸し: 未使用のアプリ、不要な権限（特に Microsoft Graph の委任 / アプリケーション権限）を削除。攻撃者は OAuth 同意フィッシングで悪意あるアプリをテナントに登録するため、User consent を「検証済み発行者 + 低リスク権限のみ許可」に制限し、Admin consent workflow で承認フローを通す
- ゲストユーザー（B2B 招待）の定期棚卸し: アクセスレビューを使って不要なゲストを自動削除
- Password Protection: グローバル禁止語句 + カスタム禁止語句（会社名・製品名等）を設定し、弱いパスワードを拒否。オンプレ AD にもエージェント展開で適用可能
- Smart Lockout: ブルートフォース対策としてデフォルト有効（既定値は 10 回失敗で 60 秒ロック）。しきい値は環境に合わせて調整
- Authentication Methods ポリシー: SMS / 音声通話を段階的に廃止し、FIDO2 / Microsoft Authenticator Number Matching / Windows Hello for Business に寄せる
関連トピック
AWS IAM ベストプラクティス- ルートユーザー保護・IAM Identity Center による SSO 集約・ロール中心設計・最小権限・MFA 強制など、AWS IAM の設計と運用における推奨設定を整理。 クラウドセキュリティの考え方- クラウド（AWS/Azure/GCP）のセキュリティを設計するうえで必須となる責任共有モデル・ゼロトラスト・ガードレール・最小権限・多層防御の基本原則。 クラウドへのセキュアなアクセス- AWS SSO / SSM Session Manager / IAM Identity Center など、ゼロトラストを意識したクラウドインフラへの接続方式。SSH 鍵の直接管理や踏み台サーバーに頼らない運用を実現する。 パスワードポリシー- パスワードの強度・管理・運用に関するルール。NIST SP 800-63B に基づく最新のガイドラインでは、定期変更よりも長く推測困難なパスワードが推奨される。 ゼロトラストアーキテクチャ- 「信頼しない、常に検証する」を原則とするセキュリティモデル。ネットワークの内外を問わず、すべてのアクセスを検証する。