IAM権限を削っても戻る？｜最小権限の修正をCI/CDに乗せる設計

公開日 2026.09.17 更新日 2026.09.17 AWS IAM IAM Access Analyzer 最小権限 CI/CD

広すぎるIAM権限を管理画面で修正したのに、次のデプロイで元に戻った。原因は、実環境だけを直し、インフラ定義のコードを更新していないことかもしれません。

AWSは2026年9月15日、Access Analyzerの検出結果をCI/CDの修正工程につなぐ実装例を公開しました。これは新しい脆弱性の速報ではなく、検出で止まりがちな最小権限の運用を、レビュー可能な変更へ進める技術解説です。AWS公式記事

① 権限修正は実環境だけでなく、定義元のコードに反映する。

② ロールの管理方法を分類し、PR・Issue・廃止検討に分ける。

③ 未使用の検出は削除許可ではない。所有者確認と業務テストを挟む。

背景：最小権限は一度設定すれば終わりではない

IAMロールは、アプリや担当者にAWS操作の権限を渡す仕組みです。最小権限とは、必要な対象と操作に権限を絞ること。初期構築や障害対応で広げた権限が、そのまま残りやすい点が問題になります。

Access Analyzerは外部・内部・未使用アクセスの分析やポリシー検証を支援します。未使用権限には、アクセス履歴に合わせた修正案を提示します。ただし、検出された項目が本当に業務上不要かは別途判断しなければなりません。Access Analyzer公式概要

IaC（Infrastructure as Code）は、ロールなどのインフラ設定をコードとして管理する方法です。実環境だけを変更すると、コードとの差が「ドリフト」として残ります。本稿の主眼は、自動削除ではなく、修正の定義元を見つけて変更管理に乗せることです。

最新の実装例：三つの修正経路を作る

公式例は、Access Analyzerで検出し、CloudTrailで作成経緯を調べ、BedrockでCDKコードや説明文を生成する構成です。推奨ポリシーはAccess Analyzerが提供し、AIは主に実装への変換と説明を担当します。公式設計

検出結果をそのまま本番変更にしない

検出・除外判定
所有者と管理元を確認
変更案を生成
検証・レビュー
段階適用と監視

IaC管理 → PR定義元を修正し、差分をレビューして既存パイプラインで適用する。

手動・不明 → Issue推奨案と根拠を渡す。定義元が分からないものを勝手に書き換えない。

未使用ロール → 廃止検討担当者が依存関係を確認し、停止・監視・削除を計画する。

公式例には30日間監視するsoft-disable案もありますが、これは全業務に十分な安全期間という意味ではありません。また、サンプルの生成コード検証に ValidatePolicy は含まれていないと明記されています。実装の範囲と限界

技術ポイント：三種類の検証を混同しない

権限変更のチェックは複数段階で行う
段階	主に確認すること	これだけでは分からないこと
コード・構文	PythonやCDKが処理できるか	許可する対象・操作が適切か
ポリシー検証	IAM文法、エラー、セキュリティ警告	月末・災害復旧などの業務が動くか
業務テスト	代表処理、例外処理、復旧経路	テストしなかった将来の処理の安全性

Access Analyzerのポリシー検証は、エラー、セキュリティ警告、一般警告、提案を返します。公式文書も、本番適用前に変更後のポリシーを十分テストするよう求めています。コードがコンパイルできたことと、権限が安全なことは違います。ポリシー検証の仕様

例えば、生成されたidentity policyのJSONを検証する読み取り系のコマンドは次の形です。例示であり、本稿ではAWSアカウントに対して実行していません。

aws accessanalyzer validate-policy \
  --policy-document file://candidate-policy.json \
  --policy-type IDENTITY_POLICY \
  --locale JA \
  --output json

AWS CLIと必要な認証・権限が前提です。ロールの信頼ポリシーなど、resource policyを確認する場合は種別が異なります。CIではコマンドの終了コードだけでなく、返された findings を読み、エラー・警告の扱いを明示してください。CLI仕様

90日制約：作成経緯を常に探せるとは限らない

CloudTrailの通常のEvent historyは、過去90日間の管理イベントを参照する仕組みです。長期の記録はtrailやevent data storeを別途設計します。通常の履歴検索にはアカウント・リージョンの範囲制約もあります。CloudTrail公式仕様

したがって、数年前に作ったロールの作成イベントが見つからなくても、それだけで「手動作成」と断定できません。本稿の設計提案は、スタック情報、管理タグ、リポジトリ台帳、所有者の確認を補助証拠として使い、確証がなければ不明扱いでレビューに回すことです。

ここでの90日はCloudTrailの通常履歴の期間であり、権限を削除してよい未使用期間ではありません。30日監視案と90日履歴制約は別の意味の数字です。

導入手順：まずはPRを作らず、分類だけ試す

以下は本稿の編集上の導入提案で、AWSの顧客実績や必須設定ではありません。

範囲を一つに絞る。 検証アカウントと少数のアプリロールから始める。実行権限とリポジトリ書き込み権限を分離する。
所有者台帳を作る。 アカウントID、ロールARN、リポジトリ、管理スタック、担当チームを記録する。
除外には期限を付ける。 障害対応用や特別な業務のロールは、理由・責任者・再確認日を持つ例外として管理する。
分類をdry-runで確認する。 意図した経路に振り分けられるか、既存Issueの重複を防げるかを見る。
推奨案と生成物を比較する。 Actionだけでなく、Resource、Condition、Effectも差分確認する。共有ポリシーなら利用する全ロールへの影響を調べる。
段階適用する。 所有者レビュー、検証環境、限定本番の順で進め、権限エラーと業務指標を監視する。旧定義を戻す手順も準備する。

AIは説明やコード化の補助に使い、採用判断をモデルの自信度に委ねない方が、変更の根拠を追いやすくなります。生成時に渡すログやポリシーにも、機密情報の扱いを定めましょう。

リスクと限界：「未使用」は「不要」と同義ではない

未使用ロールにdeny-allを付ける案も、業務を停止させる可能性があります。気軽な自動処理にせず、変更窓、依存関係、復旧担当者を確認します。「止めて問題が出なかった」と判断する期間は、業務周期に合わせて決める必要があります。

また、ロールを一つだけ見て共有ポリシーを縮小すると、別のアプリが必要とする操作まで消す恐れがあります。生成された説明文が正しくても、適用対象が違えば事故になります。

開発・保守・運用・コンサルへの影響

開発： 権限変更もコードレビューとテストに乗せ、再デプロイで修正が戻らない形にできる。
保守： 定義元、所有者、例外期限を持つことで、過去の修正理由を追跡しやすくなる。
運用： PR数だけでなく、適用済み件数、差し戻し、権限エラー、長期未処理を監視する必要がある。
コンサル： 一括削除の提案より、業務周期と責任分界に合わせた変更経路の整備が重要になる。

これは設計上の期待効果です。公式記事の例示環境の数値を実在企業の成果と扱ったり、本稿から工数削減率を推定したりはしていません。

今後注目すべき点

推奨ポリシーの検証をパイプラインにどこまで組み込めるか、所有者不明のロールをどう減らすか、季節業務の回帰テストをどう残すかが実務上の焦点です。導入前には、Access Analyzerの分析範囲、料金、モデルの提供状況、クロスアカウント権限、API制限を確認します。

最小権限の自動化は、権限を速く消す競争ではありません。必要な権限を残しながら、修正を次のデプロイにも残す仕組みを作ることです。

最終確認日：2026年9月17日（日本時間）。公式実装解説の公開日：2026年9月15日。導入順序・判断条件は本稿の編集上の提案です。

参照元

Previous Post Next Post