変更要約: SC-300 第4章を新規作成（ドメイン3: ワークロード ID 選択/マネージド ID(システム/ユーザー割当)/サービスプリンシパル/gMSA、エンタープライズアプリ(SSO/Application Proxy/app role 割当/同意ポリシー/管理者同意ワークフロー)、アプリ登録(リダイレクト URI/シークレット・証明書・フェデレーション資格情報/委任・アプリケーション権限/app roles)、Defender for Cloud Apps(cloud discovery/Cloud app catalog/OAuth アプリポリシー/CA アプリ制御/アクセス・セッションポリシー)）。
4.3アプリ登録（app registrations）
自社開発アプリの app registration、アプリ認証（リダイレクト URI・シークレット/証明書・フェデレーション資格情報）、API アクセス許可（委任/アプリケーション）と app roles を理解します。
自社で開発するアプリは アプリ登録（app registration） で Entra に定義します。これがアプリの「設計図」となり、各テナントに サービスプリンシパル として実体化します。
4.3.1アプリ認証と資格情報
アプリ登録では リダイレクト URI（認証後の戻り先）やサポートするアカウント種別を設定します。アプリ自身を認証する資格情報は クライアントシークレット か 証明書、そして最も安全な フェデレーション資格情報（workload identity federation） です。フェデレーション資格情報は GitHub Actions など外部 IdP のトークンを信頼し、シークレットを保存せずにアプリを認証します。「CI/CD パイプラインから鍵を持たず認証」＝フェデレーション資格情報が最適です。
4.3.2API アクセス許可と app roles
アプリが API（例：Microsoft Graph）にアクセスするには API アクセス許可 を構成します。委任（delegated）権限 は「サインインしたユーザーの代理」として動き、ユーザーの権限を超えません。アプリケーション権限 は「ユーザー無しでアプリ単独」で動き、強力なため 管理者同意が必須 です。バックグラウンドのデーモン/サービスはアプリケーション権限を使います。アプリが公開する役割は app roles で定義し、呼び出し側ユーザー/アプリに割り当てます。「ユーザー不在のバックエンドが Graph を読む」＝アプリケーション権限＋管理者同意です。
決め手：「CI/CD など外部から鍵なしでアプリ認証」＝フェデレーション資格情報。「ユーザーの代理で動く」＝委任権限。「ユーザー無しでアプリ単独・要管理者同意」＝アプリケーション権限。「アプリが公開する役割」＝app roles。アプリの設計図＝アプリ登録、テナントの実体＝サービスプリンシパル。
混同に注意：
①委任権限（ユーザーの代理・ユーザー権限を超えない）とアプリケーション権限（アプリ単独・強力・要管理者同意）を取り違えない。
②クライアントシークレットは漏えい源＝可能ならフェデレーション資格情報/証明書へ。
③アプリ登録（設計図）とエンタープライズアプリ/サービスプリンシパル（テナントの実体）は別ビュー。
4.3.3この節のまとめ
- アプリ登録＝自社アプリの設計図。資格情報はシークレット/証明書/フェデレーション資格情報(鍵レス・最も安全)
- API 権限＝委任(ユーザー代理)とアプリケーション(アプリ単独・要管理者同意)。app roles で役割を公開
- CI/CD からの鍵レス認証＝フェデレーション資格情報
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. GitHub Actions のパイプラインから、クライアントシークレットを保存せずに Entra アプリを認証させたい。最適なのはどれですか？
Q2. ユーザーが不在のバックグラウンドサービスが Microsoft Graph でメールボックスを読む必要がある。最適な API アクセス許可はどれですか？
Q3. サインインしたユーザーの代理として、そのユーザーの権限の範囲でのみ Graph を呼びたい。最適な API アクセス許可はどれですか？
Q4. アプリ登録とサービスプリンシパルの関係として正しいのはどれですか？
Q5. クライアントシークレットの利用について最も適切な設計はどれですか？