変更要約: in-scope サービス網羅(是正): Network Firewall 節に Web 保護の AWS WAF（L7・SQLi/XSS/レート制限の IaC 適用）を追加（参考書で未説明だった軸B欠落を解消）
6.1ID とシークレットの管理
パイプラインと実行環境の認可——IAM ロール、一時認証情報、Secrets Manager／Parameter Store、OIDC フェデレーション——を理解します。長期キーを排し、最小権限で安全に動かします。
DevOps の自動化は強い権限を扱います。長期キーを避け、ロールと一時認証情報、シークレット管理で安全に運用します。
6.1.1認可とシークレット
- IAM ロール＋一時認証情報：サービスはロールで動作し、長期アクセスキーを埋め込まない。
- Secrets Manager：DB パスワードや API キーを保管し、自動ローテーションに対応。
- Parameter Store（SecureString）：設定値や軽量な機密を一元管理（KMS で暗号化）。
- OIDC フェデレーション：外部 CI（GitHub Actions 等）がキーなしでロールを引き受ける。
「サービスは IAM ロール＋一時認証情報（長期キー禁止）」「ローテーション必須の機密＝Secrets Manager」「設定/軽量機密＝Parameter Store（SecureString）」「外部 CI からのキーレス認可＝OIDC フェデレーション」 は DOP-C02 で頻出です。GitHub Actions から AWS へは OIDC でロールを引き受けるのが定石です。
DOP-C02 では「自動化の強い権限を、いかに長期キー無しで安全に与えるか」が問われます。AWS のサービス（CodeBuild/CodePipeline/Lambda/EC2/ECS タスク）にはサービスロール/インスタンスプロファイル/タスクロールを割り当て、STS の一時認証情報で動かします。クロスアカウントのデプロイは、CI/CD アカウントから各環境アカウントのロールを AssumeRole し、信頼ポリシーで引き受け元を限定します。外部 CI（GitHub Actions など）からは OIDC フェデレーション——IAM の OIDC ID プロバイダーを登録し、sub（リポジトリ/ブランチ）を信頼ポリシーの条件にしてロールを引き受け、長期キーを GitHub に置きません。シークレットは、ローテーションが要る DB 認証情報＝Secrets Manager（Lambda ローテーション、RDS と統合）、設定値や階層パラメータ＝Parameter Store（SecureString は KMS 暗号化）と使い分けます。CodeBuild/CodePipeline は環境変数にシークレットの ARN を参照させ、値を平文で持ちません。権限設計は最小権限が基本で、Permissions Boundary で委譲時の上限を、SCP で組織的なガードレールを敷きます。コードに鍵を埋め込まない、ログにシークレットを出さない、定期ローテーションする、という運用規律が DevOps の安全性を支えます。
| 対象 | 認可/保管の方法 | 要点 |
|---|---|---|
| AWS サービス | IAM ロール＋一時認証情報 | 長期キー禁止・最小権限 |
| 外部 CI（GitHub 等） | OIDC フェデレーション | キーレスでロール引受・sub で限定 |
| ローテーション要の機密 | Secrets Manager | 自動ローテーション・RDS 統合 |
| 設定値・軽量機密 | Parameter Store（SecureString） | KMS 暗号化・階層・安価 |
6.1.2マルチアカウント/アプリの ID 管理（IAM Identity Center・Cognito・Directory Service）
組織やアプリのユーザー/デバイス ID を管理するサービス群です。対象（AWS アカウント横断 vs アプリユーザー vs 既存 AD 統合）によって使い分けます。 IAM Identity Center（旧 AWS SSO）は、組織内の複数 AWS アカウントとビジネスアプリへのシングルサインオン（SSO）を一元提供します。パーミッションセット（permission set）を定義して複数アカウントに展開し、既存 IdP（Active Directory、Okta 等）と SAML 2.0 / SCIM で連携できます。DevOps では「開発者が 1 回のログインで複数環境（dev/staging/prod）のコンソール/CLI を切り替える」用途が典型です。 Cognito（Amazon Cognito）は Web/モバイルアプリのユーザー認証・認可を担います。ユーザープールはサインアップ/サインイン/MFA/パスワードリセットを管理するディレクトリで、JWT トークンを発行します。ID プール（フェデレーテッド ID）は、ユーザープールや外部 IdP（Google、Facebook、SAML）で認証したユーザーへ一時的な AWS 認証情報を付与し、S3・DynamoDB 等へ直接アクセスさせます。 Directory Service（AWS Directory Service）は、マネージドなディレクトリサービスです。AWS Managed Microsoft AD はフル機能の Active Directory をマネージドで提供し、EC2 のドメイン参加や IAM Identity Center との統合に使います。AD Connector はオンプレミス AD へのプロキシで、クラウドにディレクトリを持たず既存 AD を活かします。Simple AD は Samba ベースの軽量ディレクトリです。
| サービス | 対象ユーザー/用途 | 典型的な選択基準 |
|---|---|---|
| IAM Identity Center | AWS アカウント横断の従業員 SSO | 組織内複数アカウントへのパーミッションセット一元配布 |
| Cognito ユーザープール | Web/モバイルアプリのエンドユーザー認証 | アプリ独自のサインアップ/サインイン・MFA |
| Cognito ID プール | 認証済みユーザーへの AWS 一時認証情報付与 | S3/DynamoDB への直接アクセスをクライアントに許可 |
| Managed Microsoft AD | フル AD（EC2 ドメイン参加/グループポリシー） | オンプレ AD をクラウドに拡張、または新規 AD |
| AD Connector | 既存オンプレ AD へのプロキシ | クラウドにディレクトリ複製を持たず既存 AD を活用 |
「組織の従業員が複数 AWS アカウントに SSO ＝ IAM Identity Center（パーミッションセット）」「Web/モバイルアプリのユーザー認証 ＝ Cognito（ユーザープール＝認証 / ID プール＝AWS 認証情報）」「EC2 ドメイン参加や既存 AD 統合 ＝ Directory Service（フル AD は Managed Microsoft AD、既存 AD の活用は AD Connector）」 を区別してください。IAM Identity Center は内部の従業員向け、Cognito は外部アプリユーザー向けという切り分けが試験頻出です。
シナリオ：GitHub Actions から本番 AWS アカウントへデプロイしたいが、長期アクセスキーを GitHub Secrets に置きたくない。→ AWS に GitHub の OIDC ID プロバイダーを登録し、デプロイ用ロールの信頼ポリシーで repo:org/app:ref:refs/heads/main のように sub を限定。ワークフローはロールを AssumeRoleWithWebIdentity で引き受け、短命の一時認証情報でデプロイします。これで GitHub 側に永続キーを保存せずに済みます。
FAQ：Secrets Manager と Parameter Store、どちらに置く？ 自動ローテーションや RDS との統合、クロスアカウント共有が要る本格的な機密は Secrets Manager。ローテーション不要の設定値や軽量な機密は Parameter Store（SecureString）が安価で手軽（標準は無料枠あり）。Parameter Store から Secrets Manager のシークレットを参照することもでき、併用が可能です。
ひっかけ：「CI/CD を簡単にするため IAM ユーザーのアクセスキーを発行して GitHub Secrets に保存」は誤りで、長期キーは漏洩リスクが高くアンチパターンです。正解は OIDC フェデレーションでキーレスにすること。また機密を buildspec や環境変数に平文で書くのも誤り——ARN 参照で実行時に取得します。
6.1.3この節のまとめ
- 認可＝IAM ロール＋一時認証情報／OIDC（外部 CI）
- 機密＝Secrets Manager（ローテーション）／Parameter Store（SecureString）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. CodeBuild がビルド中に S3 や ECR へアクセスする。資格情報をどう扱うのが正しいですか？
Q2. データベースのパスワードを定期的に自動ローテーションしながら安全に管理したい。何を使いますか？
Q3. GitHub Actions から AWS にデプロイする際、長期アクセスキーを GitHub に保存したくない。何を使いますか？