iam-audit

IAM 監査 — ID・アクセス管理のレビューと設計

ID・アクセス層をエンドツーエンドで網羅します。既存の設定を監査し、ゼロから設計し、移行を計画して、多くのチームが誤りがちなパターンを体系化します。コンサルタント型のスキルです。「何が誤設定されているか」だけでなく、「どのような構成にすべきか」まで扱います。

3 つのモードから、取り組みに合ったものを選んでください。

• 監査 — すでに導入されているものをレビューし、権限の肥大化や不足を見つけます
• 設計 — 新しいプロジェクトや新しい ID プロバイダー向けに、グリーンフィールドの IAM を設計します
• 移行 — 複数の ID プロバイダーを統合し、アクセスをフェデレーションし、SSO に移行します

相互参照：クラウドプロバイダーの監査（IAM より広範）には cloud-audit、K8s RBAC と ServiceAccounts（オーケストレーション層の ID）には container-audit、個々の運用者自身のアカウント（ハードウェアキー MFA、復旧経路、SIM スワップ対策）には personal-opsec を参照してください。これらは組織の IAM では対応できない範囲です。

承認

ユーザーが所有する、またはレビューの許可を得ており、その目的で読み取りアクセスが付与されている ID プロバイダー、クラウドアカウント、アプリケーションのみを監査してください。事前承認済みのコマンドでは、ポリシーと検出結果を読み取ります。監査中にロールを変更したり、ユーザーを削除したり、認証情報をローテーションしたり、特権昇格の経路を実環境で試したりしないでください。経路と修正方法を報告し、対応は所有者に委ねてください。

モード 1 — 既存の IAM を監査する

クラウドプロバイダーの IAM

AWS：

• コンソールアクセス権を持つ IAM ユーザー — 成熟した構成ではゼロにすべきです（SSO／Identity Center を使用）
• 永続的なアクセスキーを持つ IAM ユーザー — すべて認証情報のローテーションが必要な状態です。SSO または IAM Roles Anywhere 経由のロール引き受けに置き換えてください
• ロールを作成できるすべてのロールに権限境界が設定されていること（iam:CreateRole と iam:AttachRolePolicy を使った特権昇格を防止）
• AdministratorAccess ポリシーのアタッチ — すべて指摘し、正当な理由を確認してください
• 緊急用ロール以外でのワイルドカード Action: "*" または Resource: "*"
• クロスアカウントの信頼ポリシー — Principal: { AWS: "*" } は全世界に公開されています。必要に応じて aws:PrincipalOrgID 条件を付けた、特定のアカウント ID にすべきです
• IMDSv2 が強制されていること — すべての EC2 起動テンプレートで MetadataOptions.HttpTokens: required を設定
• サービスリンクロールを監査 — 通常の制限を迂回します
• 実行：aws accessanalyzer list-findings、aws iam generate-credential-report、aws iam get-account-authorization-details

GCP：

• roles/owner と roles/editor は範囲が広すぎます — カスタムロールまたは粒度の細かい roles/*Admin に置き換えてください
• ダウンロードされたサービスアカウントキー（projects.serviceAccounts.keys.create） — ゼロにすべきです。Workload Identity Federation を使用してください
• 自身に対して iam.serviceAccountTokenCreator を持つサービスアカウント ＝ 自己偽装 ＝ 特権昇格
• 組織レベルとプロジェクトレベルのバインディング — 組織レベルで範囲が広すぎるバインディングは、すべてのプロジェクトに気付かれないまま権限を付与します
• 機密性の高いリソースに対する allUsers／allAuthenticatedUsers のバインディング
• 実行：gcloud asset analyze-iam-policy、gcloud policy-intelligence query-activity、Recommender API

Azure：

• サブスクリプション／管理グループのスコープで割り当てられた Owner と Contributor ロール
• * アクションを含むカスタムロール
• 条件付きアクセス ポリシーがすべてのサインイン経路を対象としていること（レガシー認証、サービスプリンシパル、緊急用アカウントは明示的な理由を記載して除外）
• すべてのグローバル管理者／特権ロール管理者／アプリケーション管理者ロールで特権 ID 管理（PIM）が使用されていること
• サービスプリンシパルの認証情報（クライアントシークレット） — 有効期限を設定し、ローテーションする必要があります。有効期限を確認してください
• 実行：az role assignment list --all、Microsoft Graph auditLogs/signIns、Microsoft Entra の推奨事項

ID プロバイダー

Okta / Entra ID / Auth0 / Google Workspace：

• ユーザーの100％に MFA を適用します。「MFA は任意」というユーザー群は設けません
• 管理者にはフィッシング耐性のある MFA（FIDO2 / WebAuthn / ハードウェアキー）を適用し、すべてのユーザーに最低限 TOTP を適用します
• 非アクティブなアカウントは30／60／90日後に無効化します（ポリシーを選択し、適用します）
• ライフサイクルの自動化 — 入社／異動／退職のフローは自動化し、チケット駆動にしません
• グループベースのアクセス — ユーザーにはグループメンバーシップを通じて権限を付与し、個別に直接割り当てません。グループメンバーシップを監査対象とします
• 管理者の分離 — 特権管理者の操作には、日常業務用アカウントではなく、別の昇格済みアカウントを必須とします
• アプリの割り当て — すべての SaaS アプリを四半期ごとに見直し、孤立したアプリ（使用されなくなったアプリ）を削除します
• 認証ポリシー — レガシープロトコル（IMAP、POP、SMTP の基本認証）をブロックし、信頼度の高いアプリではデバイスのコンプライアンスを必須とします
• 機密性に応じた適切なセッション有効期間を設定します（管理者：短め、エンドユーザー：リフレッシュを伴う長め）
• ログを SIEM に転送します — サインイン、管理者による変更、MFA の失敗

アプリケーション認可

• ロール定義をどこかに文書化します（コード内だけにしません）— docs/roles.md または同等のもの
• 「Admin」は1つのロールではありません — 通常は3～5種類です：サポート、請求、コンテンツモデレーター、プラットフォーム管理者、セキュリティ対応担当者
• テナントごとにロールを分離します — 組織Aの「テナント管理者」は、同じロールでも組織Bの情報を読み取れません
• 権限チェックを一元化します — can(user, action, resource) 関数を1つ使い、if (user.role === "admin") のチェックをあちこちに散在させません
• アクセス判断がリソース属性（レコードの所有者、テナント、ステータス）に依存する場合は ABAC を使います — ロールの爆発的な増加が懸念される場合は ReBAC ツール（Cerbos、OpenFGA、Oso、SpiceDB）を使います
• 監査証跡のため、権限チェックをログに記録します

監査でよく見つかる問題

• ロールの爆発的な増加 — 新しい要件が出るたびに新しいロールが作られ、誰もそれぞれの役割を把握できず、削除に踏み切れません
• 権限の累積 — インシデント対応のためエンジニアに一時的な権限を付与したものの、取り消されないままになっています
• 隠れた管理者 — 管理者以外のロールから、推移的に iam:AssumeRole を使って管理者になれます
• 古い緊急アクセス — 緊急アクセス用アカウントが12か月以上テストされておらず、動作するか誰も把握していません
• レガシー認証による MFA の回避 — 「MFA を設定済み」のアカウントでも、IMAP／POP／SMTP の基本認証が引き続き機能します
• サービスアカウントの乱立 — サービスアカウントが人間のユーザー数を上回り、その半数は未使用で、残りの半数は過剰な権限を持っています

モード2 — 新規環境の IAM を設計する

原則（OWASP に限らない、コンサルタントとしての原則）

1. ID プロバイダーを信頼できる唯一の情報源とします。 クラウド IAM であっても、SAML／OIDC でフェデレーションし、AWS／GCP／Azure で直接ユーザーを管理しません。
2. ユーザーにはグループを通じてアクセス権を付与し、直接付与しません。 個別の割り当ては監査上のノイズになります。
3. サービスアカウントはロールとして扱います。 キーを発行せず、ワークロード ID フェデレーション（AWS IRSA、GCP Workload Identity、Azure Workload Identity、Kubernetes ServiceAccounts → OIDC）を使います。
4. 特権アクセスは常時付与ではなく、JIT にします。 デフォルトは「アクセスなし」とし、監査証跡を残したうえで、期間を定めてアクセス権を付与します（AWS IAM Identity Center + セッション期間を設定した権限セット、Azure PIM、Okta Workflows、コンテキスト対応アクセスを介した Google JIT）。
5. 緊急アクセスは、テスト済みで警報を伴う経路にします。 緊急アクセス用アカウントを用意し、厳格に監査するとともに、四半期ごとにテストします。
6. 最小権限は、目指すだけでなく、実際に確認できる状態にします。 アクセスアドバイザー／未使用アクセスのレポートを毎月取得し、使われていない権限を削除します。
7. 認可判断をログに記録します。 インシデント対応で追跡できるよう、すべての allow または deny を記録します。

グリーンフィールドのチェックリスト（ウェブアプリ＋クラウド）

新規プロジェクトでは、次の順番で設計します。

1. IDプロバイダーを選びます。 エンタープライズ向けには Okta または Entra ID、B2B SaaS 向けには Auth0 / Clerk / Stytch / WorkOS、小規模チーム向けには Google Workspace を選びます。独自に構築しないでください。
2. 認可モデルを定義します。 RBAC は最低限必要です。レコードの属性に応じて権限が決まる場合は ABAC を追加します。権限が複雑になり、コード内の if 文では読みづらくなった場合は、権限サービス（Cerbos、OpenFGA、Oso）を使います。
3. コードを書く前にロールを定義します。 プロダクトにはどのようなロールが存在しますか？各ロールについて、実行できることを1文で説明したドキュメントを作成します。多くのプロダクトでは、エンドユーザー、エンドユーザー管理者（テナントスコープ）、サポート、請求、コンテンツモデレーター、プラットフォーム管理者が該当します。
4. クラウドアクセスをフェデレーションします。 AWS IAM Identity Center と IdP、GCP Workload Identity Federation と IdP を連携させます。Azure のロールでは Azure AD を信頼できる唯一の情報源とします。
5. キーではなくワークロードIDを使います。 EC2 → IAM Roles、EKS → IRSA / Pod Identity、ECS → タスクロール、Lambda → 実行ロール、GitHub Actions → OIDC フェデレーションを使います。長期間有効なキーは使いません。
6. 初日からログを記録します。 クラウドのトレイル／監査ログを SIEM に接続されたバケットに保存します。ロギングサービス以外からログバケットへの *:Delete* および *:Put* を拒否します。
7. 緊急用アカウントを文書化し、テストします。 2人ルールとハードウェア MFA を適用し、「IdP が停止している」場合にのみ使用します。ログインのたびにアラームを発報します。

認証フローの選択肢（ウェブ／モバイルクライアント）

• パブリッククライアント（ブラウザー、モバイル）— PKCE を使った OAuth 2.0 Authorization Code。implicit flow は使用しません（非推奨で、トークンが漏えいするため）。
• コンフィデンシャルクライアント（サーバー間）— 有効期間の短いアクセストークンを使った Client Credentials グラント
• ファーストパーティのネイティブアプリ — IdP のネイティブ SDK（Okta、Auth0、Clerk）で、ストレージやトークン更新に関する細かな処理を行います。
• 有効期間の長いリフレッシュトークンは HttpOnly Secure Cookie に保存し、localStorage には保存しません（XSS で窃取される可能性があります）。
• トークン失効リスト — IdP がサポートしている必要があります。サポートしていない場合は、JWT に問題があります（owasp-audit A07 を参照）。

モード 3 — 移行／統合

よくある移行

• AWS IAM ユーザーから AWS IAM Identity Center（SSO）へ： グループを介してユーザーを権限セットにマッピングします。期限を設けて IAM ユーザーのアクセスキーをローテーションまたは無効化します。対応に時間がかかるのはサービスアカウントと CI/CD です。これらは OIDC フェデレーションに移行します。
• Active Directory から Entra ID へ： Entra Connect で同期し、Conditional Access を追加します。難しいのはレガシー認証（SMB、NTLM、オンプレミス LDAP）です。それぞれに独自の廃止計画が必要です。
• 「Google Workspace を IdP として使用」から専用 IdP（Okta / Entra）へ： Google はメールには対応しますが、30個の SaaS アプリへのプロビジョニングは次第に負担になります。移行の大部分は SCIM プロビジョニングと SAML フェデレーションです。ユーザーはほとんど気づきません。
• GCP のあらゆる場所で使われている roles/owner からカスタムロールへ： Recommender API を使って最小権限の代替案を提案し、プロジェクトごとに順次切り替えます。

移行手順（上記すべてに適用）

1. 現在の状態を棚卸しします。 誰が、どこで、何にアクセスできるかを確認します。スプレッドシートでも構いません。サービスアカウントも含めます。
2. 目標の状態を決めます。 ロールとグループを定義し、IdP を選び、フェデレーション方式を決定します。
3. 移行先を並行してセットアップします。 新しい IdP / IAM Identity Center などを現在の設定と並行して稼働させます。まだ切り替えは行いません。
4. 少人数のグループで試験運用します。 5〜10人に新しい方法を使ってもらい、問題点を洗い出して解消します。
5. 段階的に移行します。 一括ではなく、チームまたはアプリごとに移行します。各段階にロールバック手順を用意します。
6. 期限を設けて古い方法を廃止します。 「X日までに古い IAM ユーザーを無効化する」と期限を設定し、確実に実行します。期限のない移行は完了しません。
7. 切り替えを監査証跡に記録します。 誰が、いつ移行し、何を持っていて、何を付与され、誰が承認したかを文書化します。

検証してから記録

調査結果は、監査モードと、移行における現状のインベントリ（モード 3、ステップ 1）から得られます。設計と移行に関する推奨事項は調査結果ではありません。これらは findings.json ではなく、レポートの「推奨事項」テーブルに記載します。監査候補には、references/findings-format.md の定義に従い、必ずいずれか 1 つの判定を下してください。

1. まず証拠を保存します。 ここで扱うもののほとんどはファイルではなく、デプロイ済みの設定です。各候補の根拠となる読み取り専用の出力を、機密情報を削除したうえで <audit dir>/evidence/<name>.json（または .txt）に、行番号が変わらないよう整形して（| jq .）、保存してください。例：evidence/aws-iam-get-account-authorization-details.json、evidence/aws-accessanalyzer-list-findings.json、evidence/gcloud-asset-analyze-iam-policy-acme-prod.json、evidence/okta-policies-okta-sign-on.json、evidence/entra-conditional-access-policies.json。location、trace[]、evidence[] では、そのファイルと決定的な記述または設定の行を指定してください。他のロケーションと同様、パスはリポジトリ相対にします（security-audit/evidence/...）。リポジトリがない監査では、監査ディレクトリ相対のパスを使い、その旨をレポートのヘッダーに記載してください。アプリケーション認可に関する調査結果では、代わりにソースファイルを指定します。

シークレット値は決して保存しないでください。ファイルに書き込む前に、クライアントシークレット値（secretText）、秘密鍵、SAML 署名証明書の秘密鍵部分、API トークン、セッショントークン、パスワードハッシュを削除してください。リソースの特定に必要なプリンシパル名と ID は残してください。

2. 確定する前に、すべての候補について references/verification.md に従い、反証確認を行います。 IAM の場合、経路は次のとおりです。信頼度の低いプリンシパル（パスワードを盗まれたインターネットユーザー、GitHub 組織内の任意のリポジトリ、別アカウント内の任意のプリンシパル、開発者ロール）→侵入を可能にする付与、信頼関係、またはポリシーの不備→最終的に得られる権限またはデータです。証拠ファイルを使って trace[] に記述してください。entrypoint には、アクセスを許可する信頼ポリシー、サインオンルール、またはバインディングを指定します。propagation には各段階（iam:PassRole、iam:CreatePolicyVersion、actAs、グループの入れ子など）を指定します。sink には、到達する管理者権限またはデータリソースを指定します。確認中のポリシーより上位にある制御、すなわち SCP と組織ポリシー、権限境界、リソースポリシーの条件（aws:PrincipalOrgID、aws:SourceAccount）、Conditional Access、IdP 認証ポリシー、拒否ポリシーを重点的に確認してください。

3. 判定を選びます。

判定	この場合の内容
confirmed	保存された出力に、経路全体が示されています。例：ロール ci-deploy は、token.actions.githubusercontent.com:sub = repo:acme/* を信頼する GitHub OIDC を使用しており、そのポリシーでは * に対する iam:PassRole と lambda:CreateFunction が許可され、AdminRole を渡せるため、あらゆる組織リポジトリのワークフローが管理者としてコードを実行できます。Okta のサインオンポリシールールで「Everyone」に MFA が必須とされておらず、対象アプリは本番用の権限セットを持つ AWS IAM Identity Center アプリです。
needs_validation	確認できるポリシーは主張を裏付けていますが、決定的な事実が、読み取り権限のない場所にあります。例：開発者ロールには自身のポリシーに対する iam:CreatePolicyVersion があり（* への権限昇格）、SCP はアクセスできない管理アカウントにあります（阻害要因：SCP が iam:CreatePolicyVersion を拒否しているかどうか。確認計画：管理アカウントから aws organizations list-policies-for-target --target-id <account-id> --filter SERVICE_CONTROL_POLICY を実行するか、aws iam simulate-principal-policy --policy-source-arn <role-arn> --action-names iam:CreatePolicyVersion を実行します）。Conditional Access ポリシーでは MFA が必須ですが、メンバーを一覧表示できないグループ CA-Exclusions が除外されています。説明していても実行していない確認はすべて、validation_plan に正確なコマンドを記載したうえで needs_validation とします。
rejected	特定の場所にある特定のコントロールが、あらゆる経路でそれを阻止しています。例：iam:CreateRole と iam:AttachRolePolicy を持つロールは権限昇格経路に見えますが、新しいロールに dev-boundary 権限境界が付いていない限り、SCP が両方を拒否します（ruled_out_by.location = SCP の証拠ファイルと行）。信頼ポリシーには "Principal": {"AWS": "*"} がありますが、その Condition では aws:PrincipalOrgID = 自組織が必須です。

すでに管理者であるプリンシパルから始まる権限昇格経路は、検出事項ではありません。渡された IaC モジュールやロールテンプレートに危険な既定値がある場合（trusted_accounts が設定されていないと信頼ポリシーが "AWS": "*" を許可するモジュール）は、system_configuration 条件（「trusted_accounts を設定しないデプロイ」）と確信度 medium を付けて confirmed とします。

影響が追跡されていない不足は、記録ではなくセキュリティ強化の注意事項です。記録されていないロール、追加の権限を付与しないユーザーへの直接割り当て、管理者以外のユーザーに FIDO2 ではなく TOTP を使用すること、ポリシーより長いセッション期間、SIEM に転送されていないサインインログ、今年テストされていない緊急用アカウントが該当します。これらはレポートのセキュリティ強化セクションに、重大度を付けずに記載します。

4. 重大度を調整します。 references/severity-calibration.md に従い、confirmed の記録のみを対象として、プリンシパルが最終的に実行できることに基づいて評価します。低権限ロールからアカウントまたはテナントの管理者に至る権限昇格経路は High です。本番データを読み取れるロールの信頼ポリシーが開放されている場合は High または Critical です。MFA の欠如は、対象アカウントがアクセスできる範囲に基づいて評価します（本番環境の管理者：High、社内 Wiki の低権限ユーザー：Medium または Low）。overall は、実証された影響以下にします。

確信度について：ライブ API から読み取ったポリシーは証拠であり、再現ではありません。権限昇格経路を決して実行しないでください。プロバイダー独自の読み取り専用評価ツール（aws iam simulate-principal-policy、gcloud policy-troubleshoot iam、Entra の Conditional Access What If）が、決定的なアクションに対して「allowed」を返した場合は "reproduced": true と見なし、コマンドと結果を evidence[] に記録します。これがない場合、確信度は medium が上限です。

5. フィンガープリントは行ではなく、プリンシパルまたはポリシーごとに付けます。 形式：iam-audit/<class>/<provider>/<tenant>/<principal or policy>、アプリケーションの認可および IaC の場合は iam-audit/<class>/<file>/<symbol> です。ARN はスラッシュを使って記述します。バリデーターは :<digits> セグメントを拒否します。

iam-audit/shadow-admin/aws/123456789012/role/ci-deploy        # arn:aws:iam::123456789012:role/ci-deploy
iam-audit/open-trust-policy/aws/123456789012/role/partner-read
iam-audit/sa-self-impersonation/gcp/acme-prod/[email protected]
iam-audit/mfa-not-enforced/okta/acme.okta.com/policy/default-sign-on
iam-audit/tenant-role-isolation/src/auth/can.ts/can

使用中のクラス：wildcard-policy、admin-attachment、open-trust-policy、missing-permissions-boundary、shadow-admin、sa-self-impersonation、sa-key、static-access-key、console-user、primitive-role、public-binding、org-level-binding、mfa-not-enforced、legacy-auth-allowed、ca-gap、sp-secret-no-expiry、inactive-account、orphaned-app、tenant-role-isolation。該当するものがない場合は、新しいクラスを追加してください。

6. ドメインフィールドは ext の下に配置します：

Key	Value
provider	aws、gcp、azure、entra、okta、auth0、google-workspace、cognito、app
tenant	アカウント ID、GCP プロジェクトまたは組織 ID、Entra テナントドメイン、Okta 組織ドメイン
principal	検出事項の対象となるユーザー、ロール、グループ、サービスアカウント、またはアプリ。プロバイダーが出力した表記を使用します

7. 作成して検証します。 skill: "iam-audit" を設定し、フィンガープリントで並べ替えて findings.json に書き込み、検証に合格するまで修正します：

node references/validate-findings.mjs findings.json
node references/to-sarif.mjs findings.json -o findings.sarif   # optional

再実行時は、以前の findings.json を読み込み、フィンガープリントで照合します。rejected レコードは、それが示すコントロールが変更されない限り、rejected のままです（まず、その証拠を読み直してください）。処理区分は通常、後で finding-triage によって設定されます：Fixed / Deferred / Accepted Risk / Mitigated (platform/config) / Requires major migration。誤検知は rejected レコードです。

出力形式

まず findings.json を書き込みます（監査モード）。レポートはそこから生成され、JSON に記載されていない判定、重大度、ブロッカー、影響を変更することはありません。「Potential」や「Possible」というラベルは使用しません。

# IAM [Audit | Design | Migration] Report
## Scope: [accounts / orgs / IdPs / apps covered]   ## Mode: [Audit | Design | Migrate]   ## Date: [date]
## Access: [read-only role / API scopes used]   ## Not covered: [what and why]
## findings.json: [path] — validated: [yes]   ## Evidence: [audit dir]/evidence/

### Executive Summary
[2-3 paragraphs — the IAM posture in plain English, top 3 risks, recommended next 90 days]

### Summary
- Confirmed: [N] (Critical [n] | High [n] | Medium [n] | Low [n])
- Needs validation: [N]   Rejected: [N]   Hardening notes: [N]

### Confirmed findings
#### [SEVERITY] [Title]  `fingerprint`
**Provider / tenant / principal:** [ext.provider / ext.tenant / ext.principal]
**Evidence:** `evidence/<file>:<line>` — [the decisive statement or setting, redacted]
**Confidence:** [medium | high (reproduced via simulator)]   **Conditions:** [from conditions[]]
**Path:** [lower-trust principal → grant or gap → privilege or data reached]
**Fix:** [the policy, binding or IdP change]
**Verify the fix:** [the read-only command or simulator check that shows it's closed]

### Needs validation
| Finding | Blocker | Check for the owner to run |
|---|---|---|

### Hardening notes (not findings)
- [gap] — [why it isn't a finding] — [effort]

### Rejected (do not re-raise)
| Fingerprint | Ruled out by | Location |
|---|---|---|

### Privileged access inventory
| Principal | Provider / tenant | Admin-level grant | Standing or JIT | MFA type | Last used |
|---|---|---|---|---|---|

### Recommendations (Design / Migrate mode — not findings)
| ID | Category | Recommendation | Effort |
|---|---|---|---|

### Roadmap
[Quarterly milestones — what to do this month, next 90 days, next year]

境界

• ユーザーが監査を許可されているアカウントと ID プロバイダーのみを監査します
• 監査中の操作は読み取り専用とします（iam:AttachPolicy、ロールの作成、ユーザーの無効化は行いません）
• 移行時は、ロールバック手段が確認されていない限り、ユーザーを無効化しません
• MFA の回避、ソーシャルエンジニアリングによる認証情報の復旧、バックドアアクセスの設計には協力しません
• 監査で見つかった権限昇格チェーンは、悪用せずに検出事項として記録します

参考資料

• AWS IAM のベストプラクティス
• GCP IAM のベストプラクティス
• Microsoft Entra ID — 特権アクセス戦略
• NIST SP 800-63（デジタル ID ガイドライン）
• NIST SP 800-207（ゼロトラストアーキテクチャ）
• OWASP 認証チートシート
• OWASP 認可チートシート
• Open Policy Agent / Cedar / Cerbos / OpenFGA のドキュメント
• AWS Permission Boundary のドキュメント
• 「必要最小限のアクセス」／JIT アクセスのパターン
• 共通の参考資料（ビルド時に references/ にコピー）：findings-format.md、findings.schema.json、validate-findings.mjs、to-sarif.mjs、severity-calibration.md、verification.md