こんにちは！クラウドインフラの構築やアプリ開発、毎日お疲れ様です。
新人のIT担当者の方や、セキュリティの勉強を始めたばかりの developers の皆さん、「IAMポリシーってなんだか難しそう…」「とりあえず AdministratorAccess（管理者権限）を付けておけば動くからいっか！」なんて、魔が差して設定していませんか？
実はその「とりあえず全権限」こそが、サイバー攻撃者にとって一番ご馳走な状態なんです。
今回は、AWS IAMやAzure RBACを舞台に、「最小権限の原則（PoLP: Principle of Least Privilege）」をどうやって現場で実践し、守りを固めていくのかを、身近な防犯の例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. 家の鍵で例える「最小権限の原則」
突然ですが、皆さんのご自宅の玄関の鍵を想像してみてください。
家族全員が持っている普通の鍵は、玄関を開けてリビングに入り、自分の部屋に入ることはできますよね。では、家の外にある「ガレージのシャッターの暗証番号」や「金庫の鍵」はどうでしょうか？ 家族全員がいつでも開けられるように、リビングの壁にデカデカとメモを貼ったりしていませんか？
……そんなこと、絶対にしませんよね！
金庫を開けられるのは信頼できる特定の人だけですし、ガレージの番号も必要最小限の人しか知らないはずです。
これが、セキュリティの世界でいう「最小権限の原則（PoLP）」の考え方です。
「人は、仕事をするために最低限必要な権限だけを持ち、それ以外の余計な権限を持ってはならない」という、防犯の超基本ルールなんですね。
クラウドの世界で起きている「やばい現実」
これをクラウド（AWSやAzure）に置き換えてみましょう。
新しく作ったアプリケーション用のサーバー（IAMロール）に、うっかり「何でもできるスーパーマン権限（AdministratorAccess）」を渡してしまう開発現場が後を絶ちません。
もし、そのアプリにたまたま「外部から不正なファイルがアップロードされてしまう脆弱性（穴）」があったとします。攻撃者はその穴から侵入し、アプリの裏にあるサーバーの権限を乗っ取ります。
もしサーバーが「最低限の権限」しか持っていなければ、被害は「特定のS3バケットの読み書きだけ」で食い止められます。しかし、もし「スーパーマン権限」を持っていたらどうでしょう？
攻撃者はそのクラウド環境全体の鍵を手に入れたことになり、他のデータベースを勝手に削除したり、勝手に仮想通貨のマイニングサーバーを何百台も立ち上げたり、顧客の個人情報を全部ダークウェブに売り飛ばしたり……やりたい放題になってしまいます。
これが、過剰な権限付与が引き起こす最悪のシナリオです。怖いですけれど、現実によくあるインシデントなんですよ。
—
2. 攻撃者はどうやって「過剰な権限」を狙うのか？
私たちホワイトハッカーの視点から見ても、攻撃者にとって最もおいしいターゲットは「権限が強すぎるのに、誰も監視していないリソース」です。
攻撃者は次のようなステップで侵入し、権限を悪用します。
1. 足場の確保: アプリケーションの古いライブラリの脆弱性などを突き、Webサーバーの中に侵入する。
2. 権限の確認 (Discovery): 「今、自分たちが持っているサーバー（IAMロール）には、どんな権限が付いているんだろ？」とクラウドの内部APIを叩いて調べる。
3. 特権の乱用 (Privilege Escalation & Abuse): もしここで「何でもできる権限」が見つかったら、管理者アカウントを新しく作ったり、別の機密データを盗み出したりする。
つまり、防御側である私たちがやるべきことは、「2番目のステップ（権限の確認）」の時点で、攻撃者に「あれ？ このサーバー、見れるデータが全然ないぞ…詰んだ…」と思わせることなんです。
—
3. 実践！AWS IAMポリシーで最小権限をデザインする
では、具体的にどうやって最小限の権限を設定すればいいのでしょうか？
言葉で言うのは簡単ですが、実際にポリシーを書こうとすると迷ってしまいますよね。
ここでは、よくある「特定のS3バケット（画像保存用バケットなど）にだけファイルをアップロードできる」という、必要最小限のIAMポリシーのサンプルを見てみましょう。
悪い例：全部お任せのアンチパターン
まずは、絶対にやってはいけない「何でも許可しちゃう」ポリシーです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}- 危険な理由:
"Action": "*"は「すべての操作」、"Resource": "*"は「クラウド上のすべてのリソース」を意味します。これでは先ほどの「家の鍵をリビングに貼る」のと同じ状態です。
良い例：対象と操作をガチガチに絞った最小権限ポリシー
続いて、しっかりと目的を絞った安全なポリシーの書き方です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificS3UploadOnly",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::my-company-app-uploads-bucket/*"
}
]
}ポイントの解説
Actionの限定: ファイルのアップロードに必要なs3:PutObjectなどのアクションだけを明示しています。ファイルを勝手に削除するs3:DeleteObjectや、他の設定を変える権限は一切与えていません。Resourceの限定: 操作できる対象を、自社アプリ用の特定のバケット (arn:aws:s3:::my-company-app-uploads-bucket/*) の中に厳密に制限しています。他の大切な顧客データが入っているバケットには、このポリシーを持つアプリからは絶対にアクセスできません。
このように、「何をする（Action）」を「どこに対して（Resource）」行うのかを、必要最小限に切り詰めるのがIAMポリシー設計の基本です。
—
4. IAM Access Analyzerで「気づかないうちに広がりすぎた権限」を掃除する
「理屈はわかったけれど、すでに運用しているシステムの中で、誰にどんな権限が当たっているかなんて追いきれないよ……」
そう思ったそこのあなた！安心してください。AWSには「IAM Access Analyzer」という、私たちの代わりにセキュリティチェックをしてくれる強力な味方がいます。
IAM Access Analyzerってなに？
簡単に言うと、「クラウド環境の中に、外から入られそうな隙間（公開されているリソースや、外部アカウントからアクセスできる設定）がないかを自動で見つけて教えてくれるお巡りさん」です。
実務での活用プロセスは以下の通りです。
1. アナライザーの有効化: AWSマネジメントコンソールから「IAM Access Analyzer」を開き、ゾーン（信頼された外部の境界線）を作成して有効化します。これだけで自動監視がスタートします。
2. 結果（Findings）の確認: 分析が走ると、「おっと、このS3バケット、インターネットの誰からでも読み取れる設定になっていますよ！」といった警告（所見）が一覧で表示されます。
3. ポリシーの修正・削除: 警告が出たリソースのポリシーを確認し、不要な外部アクセス許可を削除または修正します。
現場のインフラ担当者としてアドバイスしたいのは、「月に1回は必ずAccess Analyzerの画面をチェックする習慣をつける」ということです。プロジェクトが進むにつれて、一時的にゆるくした設定がそのまま放置されることが本当によくあるからです。定期的な健康診断のつもりで覗いてみましょう。
—
まとめ：一歩ずつ、安全なクラウド環境へ
今回は、IAMにおける最小権限の原則（PoLP）と、具体的なポリシー設計、そしてAccess Analyzerを使った最適化のプロセスについてお話ししました。
セキュリティ対策というと、「難しそう」「面倒くさそう」と感じてしまいがちですが、基本の考え方は身の回りの防犯と全く同じです。
- 「とりあえず全部許可」は絶対にしない。
- 仕事に本当に必要な人・プログラムだけに、必要な場所の鍵を渡す。
- 定期的にツールを使って、変な隙間ができていないか見直す。
これらを少しずつ意識するだけで、あなたの守るシステムは劇的に安全になります。
焦らず、一歩ずつ確実に、セキュアな開発・インフラ運用をマスターしていきましょう！応援しています！
コメント