変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。SC-500 第1章を新規作成（ドメイン1「ID・アクセス・ガバナンスの管理」: Entra ID=PIM/条件付きアクセス/MFA・パスワードレス/アプリ ID・OAuth 同意/マネージド ID、Key Vault=RBAC vs アクセスポリシー/ネットワーク制限/ソフト削除・消去保護/Defender CSPM シークレットスキャン・Defender for Key Vault、ガバナンス=Azure Policy/Defender for Cloud 規制コンプライアンス/RBAC 過剰特権是正/リソースロック/Azure Backup/IaC）
1.1Microsoft Entra ID によるアクセスの保護
SC-500 の土台となる ID 保護を学びます。特権 ID 管理（PIM）、条件付きアクセス、多要素認証（MFA）とパスワードレス、アプリケーション ID（エンタープライズ アプリ／アプリ登録）と OAuth の同意管理、そして Azure リソース用のマネージド ID を、「最小特権」と「ゼロトラスト」の観点で実装します。
SC-500 のすべてのドメインは ID（アイデンティティ） を出発点にします。クラウドでは境界がネットワークから ID へ移り、「誰が・どの条件で・何にアクセスできるか」を ID で制御することが防御の中心になります。これは ゼロトラスト（明示的に検証する／最小特権で付与する／侵害を前提とする）の考え方そのものです。中核となるディレクトリが Microsoft Entra ID（旧 Azure AD）で、ユーザー・グループ・アプリ・デバイスの ID とアクセスを一元管理します。
1.1.1特権 ID 管理（PIM）—ジャストインタイムの昇格
PIM（Privileged Identity Management）は、Global Administrator のような強力なロールを常時割り当て（永続）にせず、必要なときだけ時間制限つきで昇格（ジャストインタイム, JIT）させる仕組みです。昇格には承認・MFA・理由の記録を要求でき、すべてが監査ログに残ります。これにより「強力な権限を持つアカウントが常に攻撃対象になる」リスクを下げます。PIM は Entra ロールだけでなく Azure リソースロール（RBAC）にも適用でき、定期的な アクセスレビュー で「もう不要な割り当て」を棚卸しします。
1.1.2条件付きアクセス—シグナルに基づく制御
条件付きアクセス（Conditional Access）は、サインインのシグナル（ユーザー／グループ・アプリ・場所・デバイスの状態・サインインリスク）を評価し、アクセス制御（許可・ブロック・MFA を要求・準拠デバイスを要求 など）を適用するポリシーエンジンです。「if（条件）→ then（制御）」の形で表現します。例：「管理ポータルへのアクセスは MFA と準拠デバイスを必須にする」「未知の場所からの高リスクなサインインはブロックする」。Entra ID Protection のユーザーリスク／サインインリスクをシグナルに組み込むと、リスクベースの自動対応ができます。
1.1.3MFA とパスワードレス認証
多要素認証（MFA） は「知っているもの（パスワード）」に加えて「持っているもの（電話・トークン）」「本人であること（生体）」のうち2つ以上を要求し、パスワード漏洩だけでは突破されないようにします。さらに パスワードレス はパスワード自体を排除し、Windows Hello for Business、FIDO2 セキュリティキー、Microsoft Authenticator のパスワードレス サインインなどフィッシング耐性の高い方式を使います。SC-500 では「フィッシング耐性が求められる→FIDO2／Windows Hello」「電話の SMS は最も弱い MFA」という強度の序列を押さえます。
1.1.4アプリケーション ID と OAuth の同意管理
アプリも ID を持ちます。アプリ登録（App registration） はアプリの定義（テナント内の「設計図」）で、テナントにインスタンス化されたものが エンタープライズ アプリケーション（サービスプリンシパル） です。アプリは OAuth 2.0 の委任されたアクセス許可（ユーザーの代理）とアプリケーションのアクセス許可（アプリ自身）を要求し、ユーザーまたは管理者が 同意（consent） します。攻撃者が悪意あるアプリへ過剰な同意を誘導する「同意フィッシング／不正な OAuth アプリ」が脅威となるため、管理者の同意ワークフロー とユーザー同意の制限、付与済み同意の棚卸しが重要です。
1.1.5マネージド ID—シークレットレスなリソース認証
マネージド ID（Managed Identity）は、Azure リソース（VM・App Service・Functions 等）が他の Azure サービス（Key Vault・Storage・SQL 等）へ接続文字列やシークレットを持たずに認証するための Entra ID 上の ID です。資格情報は Azure が自動でローテーションするため漏洩リスクが下がります。システム割り当て（リソースと同じライフサイクル・1対1）と ユーザー割り当て（独立して作成し複数リソースで共有可）の2種類があります。「コードにシークレットを書きたくない／接続文字列をなくしたい」場合の第一選択です。
| やりたいこと（例） | 使う機能 | 要点 |
|---|---|---|
| 管理者ロールを常時持たせない | PIM（適格＋JIT 昇格） | 承認・MFA・監査・アクセスレビュー |
| 場所/デバイス/リスクで制御 | 条件付きアクセス | if 条件 → then 制御（MFA/ブロック） |
| フィッシング耐性のある認証 | FIDO2／Windows Hello（パスワードレス） | SMS は最弱・FIDO2 は最強級 |
| アプリへの過剰な権限付与を防ぐ | 管理者同意ワークフロー／同意制限 | 同意フィッシング対策・付与済み棚卸し |
| シークレットを使わず接続 | マネージド ID | システム割り当て or ユーザー割り当て |
シナリオ：運用担当者の特権アクセス。 平常時は権限を持たせず（PIM の適格割り当て）、作業時のみ承認＋MFAで数時間だけ昇格。昇格時のアクセスは条件付きアクセスで「準拠デバイス＋フィッシング耐性 MFA（FIDO2）」を必須化。担当者が使う自動化スクリプトはマネージド ID で Key Vault からシークレットを取得し、接続文字列をコードから排除。四半期ごとのアクセスレビューで不要になった適格割り当てを削除。
混同に注意：
①認証（誰か＝MFA/パスワードレス）と認可（何ができるか＝RBAC/PIM）は別物。
②アプリ登録（設計図）とエンタープライズ アプリ＝サービスプリンシパル（テナント内の実体）を取り違えない。
③委任されたアクセス許可（ユーザーの代理）とアプリケーションのアクセス許可（アプリ単体・要管理者同意）。
④マネージド ID のシステム割り当て（1対1）とユーザー割り当て（共有可）。
「要件 → 適切な ID 制御」を選ぶ問題が頻出。例：「管理者権限を常時持たせたくない」＝PIM、「特定条件のときだけ MFA を要求」＝条件付きアクセス、「フィッシング耐性が必須」＝FIDO2／Windows Hello、「アプリへの過剰な同意を防ぐ」＝管理者同意ワークフロー、「コードからシークレットをなくす」＝マネージド ID。
1.1.6この節のまとめ
- ID はクラウド防御の境界＝ゼロトラスト（明示的検証・最小特権・侵害前提）。中核は Microsoft Entra ID
- PIM＝特権の JIT 昇格（承認/MFA/監査/アクセスレビュー）。Entra ロールと Azure RBAC の両方に適用
- 条件付きアクセス＝if 条件 → then 制御。MFA/パスワードレスは強度差（SMS<…<FIDO2/Windows Hello）
- アプリ登録 vs エンタープライズ アプリ、OAuth 同意の管理（同意フィッシング対策）。マネージド ID でシークレットレス
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Global Administrator のような強力なロールを常時割り当てず、必要なときだけ承認と MFA を伴って時間制限つきで昇格させる仕組みはどれですか？
Q2. サインインの場所・デバイスの状態・リスクなどのシグナルを評価し、MFA を要求したりアクセスをブロックしたりするポリシーエンジンはどれですか？
Q3. フィッシング耐性が最も求められる場面で推奨される認証方式はどれですか？
Q4. 悪意あるアプリへユーザーが過剰なアクセス許可を与えてしまう「同意フィッシング」を抑止するために有効なものはどれですか？
Q5. Azure リソースが接続文字列やシークレットを持たずに Key Vault や Storage へ認証できるようにする ID はどれですか？
Q6. アプリ登録（App registration）とエンタープライズ アプリケーションの関係として正しいものはどれですか？