城咲子｜情報システム部セキュリティ担当のつぶやき（ぼやき）

情シスの日常あるある備忘録 ※ほぼ愚痴です

城咲子｜情報システム部セキュリティ担当のつぶやき
トップ > AWS IAMで最小権限を実装する手順｜Access AnalyzerとJITで過剰権限を削る方法を情シスが解説

AWS IAMで最小権限を実装する手順｜Access AnalyzerとJITで過剰権限を削る方法を情シスが解説

「とりあえず PowerUserAccess、いや面倒だから AdministratorAccess でいいか」——AWS の IAM ロールを作るとき、一度はやったことがあるんじゃないでしょうか。分かります。開発を止めたくないし、権限不足で何度もエラーが出るのは本当にストレスですから。

でも、インシデント対応の現場をくぐってきた身として正直に言うと、その「とりあえず全権限」が一番怖いんです。漏れた認証情報が無制限の権限を持っていたら、その日の夜は眠れません。胃薬のお世話になりそうな話です。

この記事では、AWS の IAM で最小権限を「気合や注意力」ではなく「仕組み」で実装する手順を、IAM Access Analyzer・CloudTrail・ジャストインタイムアクセスを軸に、情シス・インフラ担当の目線で具体的に整理します。

そもそも AWS IAM の最小権限とは何か

最小権限の原則（Principle of Least Privilege, PoLP）とは、ユーザーやプログラムに対して「業務上どうしても必要な権限だけ」を与え、それ以外は与えない設計の考え方です。AWS の文脈に落とすと、IAM ユーザー・IAM ロール・サービスロールに付けるポリシーを、実際に使う API アクションだけに絞り込むことを指します。

なぜこれが重要かというと、理由はシンプルで「攻撃対象領域（やられたときの被害範囲）を小さくするため」です。権限を絞っておけば、万が一その認証情報が漏れても、攻撃者にできることが限られます。逆に AdministratorAccess が漏れれば、リソースの全削除も、暗号資産マイニング用インスタンスの大量起動も、データの全持ち出しも一発です。

ここで大事なのは、最小権限は「人間が頑張って手で書くもの」ではない、という点です。失敗する可能性のあるものは、いずれ失敗します。手作業でポリシーを精査し続けるのは現実的じゃないので、AWS が用意している仕組みに乗せてしまうのが正解だと私は考えています。

【関連記事】最小権限の原則そのものの定義・RBAC/IAMでの考え方を整理したい方に。

手順①：CloudTrail で「実際に使われている権限」を可視化する

最小権限を実装する第一歩は、「今この権限、本当に使われてるの？」を測定することです。測定できなければ管理できません。「たぶん使ってる」は管理ではなく、ただの願望です。

AWS では CloudTrail が、アカウント内で行われた API 呼び出しを記録してくれます。まずはこれを有効化し、できれば AWS Organizations の「組織証跡（organization trail）」として、すべてのアカウントのログを管理アカウントに集約しておきます。これで「誰が・いつ・どの API を呼んだか」が後から追える状態になります。

組織全体のログを designated account（指定アカウント）に集約しておくと、後述の Access Analyzer によるポリシー生成を、メンバーアカウントに対しても一元的に回せるようになります（AWS公式ブログ）。

ポイントは、リライトでも何でもなく「まずログを溜める」こと。次の手順で使う材料が、この CloudTrail ログだからです。

手順②：IAM Access Analyzer でポリシーを自動生成する

CloudTrail ログが溜まったら、いよいよ絞り込みです。ここで主役になるのが IAM Access Analyzer のポリシー生成（policy generation） 機能です。

これは何をしてくれるかというと、指定した期間（最大90日）の CloudTrail イベントを解析し、その期間にそのロール／ユーザーが実際に使ったアクションだけを含む IAM ポリシーのテンプレートを生成してくれます（AWS公式ドキュメント）。一部のサービスについては、アクションレベル・リソースレベルまで踏み込んだ細かいポリシーを作ってくれます。

つまり「人間が API リファレンスとにらめっこしてアクションを1つずつ書く」という、一番ミスが出やすくて一番続かない作業を、AWS が肩代わりしてくれるわけです。情シス担当の胃にやさしい仕様、と言ってもいいかもしれません。

自動生成ポリシーの使い方の注意

ただし、生成されたポリシーをそのまま鵜呑みにして貼り付けるのは少し待ってください。解析期間（最大90日）に「たまたま実行されなかったが業務上は必要なアクション」（四半期に1度のバッチ等）が抜け落ちる可能性があります。生成ポリシーは「叩き台」として扱い、業務サイクルを踏まえて人間がレビューする——この一手間だけは残すのが安全です。

手順③：使われていない権限（unused access）を継続的に削る

一度絞っても、運用を続けるうちに権限はまた肥大化します。プロジェクトが終わったのに残り続けるロール、退職者のアクセスキー、誰も使っていない権限——いわゆる「権限の幽霊」です。

IAM Access Analyzer には、こうした unused access（未使用アクセス） を継続的に検出する機能があります。使われていない IAM ロール、IAM ユーザーの未使用アクセスキー・パスワードを洗い出し、さらにアクティブなロール・ユーザーについても「使われていないサービス・アクション」を可視化して、是正のための具体的なガイダンスを出してくれます（IAM Access Analyzer の機能）。

ここが「耐故障設計」の肝です。人間が定期棚卸しを忘れても、仕組みの側が「これ使ってませんよ」と教えてくれる状態を作っておく。棚卸しを四半期の手作業イベントにしてしまうと、忙しい時期には必ず飛びます（経験者は語る）。

【関連記事】クラウドの設定ミスがどう事業停止リスクにつながるか、構造から整理したい方は必見です。

手順④：常時付与をやめてジャストインタイム（JIT）に切り替える

最小権限を突き詰めると、最後に行き着くのが「強い権限を常に持たせない」という発想です。管理者権限を常時付与しておくのではなく、必要なときに・必要な時間だけ・申請と承認を経て渡す。これがジャストインタイム（Just-In-Time, JIT）アクセス、AWS の言葉では temporary elevated access（一時的な権限昇格）です。

AWS では IAM Identity Center（旧 AWS SSO）の permission set（許可セット）でこれを実現します。permission set ごとにセッション時間を設定でき、新規作成時の既定は1時間、最短1時間・最長12時間の範囲で構成できます（AWS公式ドキュメント）。承認を経て一時的に権限を付与し、時間が来たら自動で失効する——「消し忘れ」という人的ミスが構造的に発生しない設計です。

常時付与とJITの違い

観点 常時付与（従来型） JIT（一時的権限昇格）
権限の保持 強い権限を常に保持 必要なときだけ一時取得
漏洩時の被害 常に最大権限が漏れるリスク 付与されていない時間帯はリスク最小
失効 手動で剥奪（忘れがち） 時間経過で自動失効
監査 誰が何の権限を持つか追いにくい 申請・承認・期限が記録される

開発スピードを落としたくない気持ちは痛いほど分かります。だからこそ、「人間が剥奪を忘れない」ことに賭けるのではなく、「時間が来たら勝手に消える」仕組みに賭けるべきなんです。

【関連記事】AWSでのJIT・IaC連携をさらに深掘りしたい方に。

情シス担当のための実装チェックリスト

現場ですぐ着手できるよう、順番に並べておきます。

  • CloudTrail を有効化し、できれば組織証跡で全アカウントのログを集約する
  • IAM Access Analyzer を有効化する（外部アクセス・未使用アクセスの両方）
  • 棚卸し対象のロール／ユーザーについて、Access Analyzer でポリシーを自動生成する
  • 生成ポリシーを「叩き台」としてレビューし、業務サイクル上必要なアクションの欠落を確認する
  • unused access の検出結果を定期レビューに組み込む（手作業ではなく検出ベースで）
  • 管理者権限など強い権限は IAM Identity Center の permission set ＋ JIT に寄せる
  • permission set のセッション時間を業務に必要な最小限（既定1時間〜）に設定する

よくある質問（FAQ）

Q. AdministratorAccess を付けたままだと、具体的に何が問題ですか？

その認証情報が漏れた瞬間に、アカウント内のほぼ全操作が攻撃者に開放されます。リソース削除・データ持ち出し・不正なインスタンス大量起動などが一気に可能になり、被害の天井が無くなります。最小権限は、この「被害の天井」を下げるための設計です。

Q. IAM Access Analyzer のポリシー生成はどのくらいの期間を見てくれますか？

最大90日間の CloudTrail イベントを解析対象に指定できます。四半期に1度しか実行しない業務がある場合は、その周期を踏まえて生成結果をレビューしてください。

Q. JIT を入れると開発者の作業が遅くなりませんか？

申請・承認の手間は確かに増えます。ただ、強い権限を必要なときだけ・短時間だけ渡す設計にすれば、「漏れたら終わり」の常時付与より、組織全体のリスクは大きく下がります。承認フローを軽量化（チャット連携など）すれば、体感の遅延は最小化できます。

まとめ：最小権限は「気合」ではなく「仕組み」で守る

AWS IAM の最小権限実装は、突き詰めると「人間の注意力に頼るのをやめる」ことに尽きます。CloudTrail で測定し、Access Analyzer で絞り込み、unused access で継続的に削り、JIT で常時付与をやめる。この4つを仕組みとして回せば、誰か一人が頑張らなくても安全なレールに勝手に乗る状態を作れます。

私が目指しているのは、開発者が何も意識しなくても安全な側に倒れる「ガードレール」です。人を責めても権限は減りません。仕組みを攻めましょう。

【関連記事】最小権限の先にあるゼロトラスト設計の全体像を掴みたい方は必見です。

参考情報

@jo_sekiko