IAM設計の現実解 — 最小権限をどこまでやるか

最小権限（Least Privilege）は正しい理想ですが、初日から完璧を目指すと運用が止まります。現実解は「安全側の初期値から始め、実際の利用実績を見て反復的に絞る」こと。人・サービス・組織の3つのレイヤーで、どこまでやるかの線引きを実務目線で整理します。

01最小権限は理想、しかし「厳しすぎ」は運用を止める

IAMのベストプラクティスとして「最小権限の原則」が語られない場面はありません。必要な操作にだけ、必要な範囲で、必要な期間だけ権限を与える。異論の余地がない正論です。

問題は、この理想を「初日から完璧に」適用しようとしたときに起こります。開発者が s3:GetObject を実行するたびに AccessDenied で止まり、権限追加のチケットが情シスに殺到し、結局「面倒だから」と AdministratorAccess を配って回る——現場では珍しくない光景です。厳しすぎるIAMは、皮肉なことに最も緩い運用を招きます。

現実解は明快です。最初から絞りきろうとしないこと。安全側の初期値から始め、実際の利用実績（誰が何のAPIをいつ叩いたか）を見ながら、反復的に権限を削っていく。IAMは「一度設計して終わり」ではなく「運用しながら育てる」ものだと割り切るのが出発点です。

現場のコツ：権限設計の議論は「与える/与えない」の二値で紛糾しがちですが、実務上の軸は「初期値をどこに置き、どのくらいの周期で見直すか」です。完璧な初期設計より、絞り込みを回せる運用のほうが安全に効きます。

02人はIAMユーザーを作らない — Identity Center と一時認証

まず大原則として、人間のアクセスに長期のIAMユーザー・アクセスキーを使わない。これがIAM設計の現実解における最初の分岐点です。長期のアクセスキーは漏洩したときに無効化されるまで有効であり続け、ローテーションも人手に依存します。事故の温床です。

人間には AWS IAM Identity Center（旧 AWS SSO）を使い、既存のIdP（Entra ID、Okta、Google Workspace 等）とフェデレーションして、発行される認証情報を「一時的なもの」に統一します。ユーザーはSSOでサインインし、Permission Set（許可セット）を通じて各アカウントのロールを一時的にAssumeする。アクセスキーは手元に残りません。

図：人は外部IdP＋IAM Identity Center経由で、サービスはIAMロール経由で、いずれもSTSの一時認証情報に集約する。長期キーはどちらにも配らないのが基本形。

この形にすると、退職者の権限剥奪はIdP側の無効化1つで完結し、アクセスキーの棚卸しという不毛な作業から解放されます。マルチアカウント環境での展開はマルチアカウント統制とセットで考えると設計が締まります。アカウントを新規に作る段階の設計はアカウント初期設定も参照してください。

03サービスはロール、ワイルドカードは最後の手段

EC2・Lambda・ECS などのワークロードがAWS APIを呼ぶときは、必ずIAMロール（インスタンスプロファイル／実行ロール）を割り当てます。ここでもアクセスキーをコードや環境変数に埋め込むのは避けます。ロールが渡す認証情報はSTSの一時トークンで、自動でローテーションされます。

ポリシーを書く際の実務的な注意点を挙げます。

Action: "*" と Resource: "*" の同時使用を避ける。片方だけでも意味は大きく変わります。まずResourceを具体的なARN（バケット名、テーブル名、プレフィックス）に絞るだけで、事故の被害範囲が桁違いに小さくなります。
Actionのワイルドカードは「サービス内の限定」まで。どうしても列挙しきれない場合でも s3:Get* のように接頭辞で絞り、* 単体は使わない。iam:* や *:* は原則NGです。
条件キー（Condition）を活用する。aws:SourceIp、aws:PrincipalTag、s3:prefix などで「いつ・どこから・何に対して」を絞ると、Actionを広めに残しても実効的な範囲を締められます。
まずAWS管理のジョブ機能ポリシーを起点にする。ReadOnlyAccess や PowerUserAccess などを叩き台にし、そこから足りない・多すぎる分を調整するほうが、ゼロから書くより早く安全です。

現場のコツ：「ワイルドカードを一切使わない」を目標にすると、ポリシーが数百行に膨れて逆に読めなくなります。狙うべきは Resource の厳格化を最優先し、Action は接頭辞ワイルドカードで可読性とのバランスを取る、という現実的な締め方です。

04Permissions Boundary — 「権限委譲の天井」を先に置く

最小権限を組織で回すうえで見落とされがちなのが Permissions Boundary（アクセス許可の境界） です。これは「そのプリンシパルが持ちうる権限の上限」を定める仕組みで、実効権限は「アイデンティティベースのポリシー ∩ Permissions Boundary」の積集合になります。

実務での使いどころは、権限の委譲です。開発チームに「自分たちで必要なロールを作ってよい」という自由を与えつつ、「ただし作れるロールの権限はこの境界を超えられない」という天井を先に置く。これにより、中央のセキュリティチームが個々のロール作成をレビューし続けなくても、逸脱が構造的に防がれます。

図：実効権限は「与えたいポリシー」と「Permissions Boundary（天井）」の重なった部分だけ。境界を先に置けば、権限作成を委譲しても逸脱は起きない。

混同しやすいのですが、Permissions Boundaryは個々のIAMユーザー／ロールに付ける上限であり、後述するSCPはアカウント全体に効くガードレールです。レイヤーが違います。

05Access Analyzer と last accessed で「反復的に」絞る

ここが最小権限の現実解の核心です。最初に絞りきるのではなく、実績データを見て後から削る。AWSはこのための道具を用意しています。

IAM Access Analyzer（未使用アクセスの分析）：組織・アカウント内のロールやアクセスキーを継続的に分析し、「一定期間使われていない権限・ロール・キー」を検出します。使っていないservice-level／action-levelの権限が可視化されるので、削る候補が機械的に見つかります。
Last accessed 情報（サービス／アクション単位）：IAMコンソールやCLIで、そのプリンシパルが各サービス・アクションを最後にいつ使ったかを確認できます。「180日間一度も使っていないサービス権限」は削除の第一候補です。
Access Analyzer のポリシー生成：CloudTrailの実アクセスログから、実際に使われたAPIだけを含むファイングレインなポリシーを生成できます。広い初期ポリシーで運用を始め、数週間の実績が溜まったら生成ポリシーで置き換える、という反復が成立します。
ポリシー検証（policy validation）：ポリシーを書いた／生成した段階で、過度に緩い記述やベストプラクティス違反を静的にチェックできます。

図：初期は安全側で広めに開け、実績→未使用検出→絞り込みを四半期ごとに回す。最小権限は「一度の設計」ではなく「反復する運用」で近づける。

現場のコツ：絞り込みを「気が向いたときにやる」と絶対に続きません。四半期ごとの棚卸しをカレンダー化し、Access Analyzerの未使用検出結果をチケット化する運用に落とすと定着します。監視・アラートの型づくりと同じ発想で、監視設計の型と並べて仕組み化するのが有効です。

06SCP との役割分担 — 「絞る」と「禁じる」は別レイヤー

AWS Organizations の SCP（Service Control Policy） は、IAMの最小権限とよく混同されますが、目的が異なります。IAMポリシーが「権限を与える」道具なのに対し、SCPは「その権限が許可されうる最大範囲を制限する」ガードレールです。SCP自体は誰にも権限を付与しません。

役割分担を整理します。

SCP（組織／OU単位）：「本番アカウントで特定リージョン以外を使わせない」「ルートユーザーの操作を禁じる」「CloudTrailの無効化を禁じる」など、誰であっても越えられない一線を引く。個別の業務権限は書かない。
Permissions Boundary（プリンシパル単位）：委譲したロール作成の天井を定める。
アイデンティティベースのポリシー（ロール／許可セット単位）：実際の業務に必要な権限を与える。ここで最小権限を反復的に絞る。

この3層が噛み合って初めて「緩すぎず・厳しすぎない」設計になります。実効権限は、SCP・Permissions Boundary・アイデンティティポリシーのすべてで許可された操作の積集合である、と理解しておくと事故調査も速くなります。SCPを軸にした組織全体のガードレール設計はOrganizations と SCPで、マルチアカウントの前提整理はマルチアカウント統制で掘り下げています。設計思想の全体像は設計ガイドラインもあわせてご覧ください。

07監査可能性を最初から作り込む

最小権限は「絞った状態を保つ」だけでなく「絞れていることを証明できる」ことまで含めて完成します。監査で問われるのは設計思想ではなく、いつ・誰が・何を・どのロールで実行したかの証跡です。

CloudTrail は全アカウント・全リージョンで有効化し、組織証跡（Organization Trail）で一元集約する。これはAccess Analyzerのポリシー生成の入力にもなるため、最小権限の運用そのものを支えます。
ロールに意味のある命名とタグを付ける。role-xxxx のような無名ロールが増えると、誰の・何のためのロールか追えなくなり、絞り込みも監査も止まります。
Identity Center のアクセス記録で、人がどのアカウントのどの許可セットをいつAssumeしたかを追えるようにする。IAMユーザーを使わない設計は、この追跡性の面でも有利です。
変更をコード管理する。ポリシーやロールをTerraform／CloudFormationで管理し、PRレビューを通す。手作業のコンソール変更を減らすことが、最小権限を「維持できる」最大の要因です。

現場のコツ：監査対応の直前に証跡を整えようとすると必ず穴が出ます。CloudTrailの組織証跡・ロール命名規約・IaC管理は、アカウントを作る初日に決めておくのが最も安く済みます。アカウント初期設定の段階で織り込んでおきましょう。

—まとめ

最小権限は目的地であって、初日に到達する場所ではありません。現実解を改めて整理します。

人はIAMユーザーを作らず、IAM Identity Center ＋外部IdP ＋一時認証に統一する。
サービスはロールで動かし、アクセスキーを配らない。Resource の厳格化を最優先し、ワイルドカードは接頭辞までに留める。
Permissions Boundary で委譲の天井を先に置き、中央レビューに頼らず逸脱を防ぐ。
Access Analyzer と last accessed で反復的に絞る。四半期ごとの棚卸しを運用に組み込む。
SCP は「禁じる」ガードレール、IAMは「与える」道具。レイヤーを分けて考える。
監査可能性を初日から作り込む。CloudTrail・命名・タグ・IaCが維持の要。

「厳しすぎて止まる」のでも「緩すぎて指摘される」のでもなく、実績を見ながら締め続けられる運用に落とすこと。それが実務で持続するIAM設計の現実解です。

IAM設計は正解が一つではなく、組織の体制と運用力に合わせた線引きが必要な領域です。「厳しすぎて運用が止まる」「緩すぎて監査で指摘される」の間で悩んでいる方は、手が動かせる第三者として設計をご一緒できるEMWの実務経験が活きる領域です。お問い合わせからお気軽にご相談ください。

相談する

← ブログ一覧へ戻る