こんにちは！インフラやクラウドのセキュリティを担当していると、「サーバーの鍵をちゃんと閉めなきゃ！」と意気込む場面がたくさんありますよね。でも、サーバーOSの中身をいくらピカピカに磨き上げても、その門番である「IAM（アクセス権限）の管理」がガバガバだったらどうでしょう？
たとえ玄関のドアに最新の頑丈な鍵を何重につけても、窓が開けっ放しだったり、家中のすべての部屋の合鍵を近所の人に配り歩いていたりしたら……泥棒に入ってくださいと言っているようなものですよね。
今回は、クラウド時代の「合配りすぎた合鍵」を綺麗に回収し、安全なおうちを作るための技術「IAMポリシーの静的解析と権限過剰の自動検知」について、一歩ずつ優しく紐解いていきましょう！
—
1. なぜ「権限過剰（オーバーパーミッション）」は怖いのか？
クラウド（AWSやGCP、Azureなど）を使い始めの頃は、「とりあえず動くようにしよう！」ということで、ついこんな魔法の言葉をポリシーに書いてしまいがちです。
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}この Action: "*" と Resource: "*" の組み合わせ、何でもできてしまう最強の権限（いわゆるフルアクセス）ですが、セキュリティの現場では「全財産の入った金庫の暗証番号を、街中に貼り出すようなもの」として恐れられています。
もし、あなたが作ったWebアプリケーションに小さなセキュリティの穴（脆弱性）が見つかり、そこに攻撃者が侵入してきたとします。もしそのアプリが動いているサーバーの権限が「必要最低限」であれば、被害はそのサーバーの中だけで食い止められます。
しかし、先ほどのような「何でもできる最強の権限」が渡されていたらどうなるでしょうか？ 攻撃者はその権限を乗っ取り、クラウド上の全データを人質に取ったり、勝手に大量の仮想サーバーを立ち上げてビットコインをマイニングし、月末に数百万〜数千万円の請求書をあなたにプレゼントして去っていく……なんていう悪夢が、現実に何度も起きています。
だからこそ、「使っていない無駄な権限」や「広すぎる権限」をあらかじめ見つけ出し、スリムに削っていく作業（ハーデニング）が必要になるのです。
—
2. 目視の限界と「静的解析」という自動お掃除ロボット
「じゃあ、毎日手作業で誰がどんな権限を持っているかチェックしよう！」と思ったそこのあなた。それは広大な砂漠で落とし物を探すようなもので、途中で気が狂いそうになってしまいますよね。
そこで登場するのが、IAMポリシーの静的解析（Static Analysis）です。
静的解析とは、実際にプログラムを動かさず、設計図（IAMポリシーのJSONファイルなど）をコードの文字面だけで読み解き、「おいおい、この設定だと誰でもデータベースを消せるようになっているぞ危険だ！」と事前にアラートを上げてくれる仕組みのことです。
身の回りの例えで言うなら、「自動でお家の鍵の閉め忘れをチェックして、勝手に二重ロックにしてくれるロボット掃除機」のようなものです。人間がうっかり見落としてしまう緩い設定を、機械の目でガッチリ見つけてくれます。
代表的なツールとしては、AWS公式の IAM Access Analyzer や、オープンソースの Pouncer、Checkov などがあります。これらを上手に使うことで、人間では気づけない権限のムダや危険を自動で炙り出すことができます。
—
3. 実践！CI/CDパイプラインへの組み込みで「うっかりミス」を防ぐ
セキュリティ対策で一番大切なのは、「人間の記憶力や注意力に頼らないこと」です。開発者がコードを書くたび、GitHubなどのリポジトリにプッシュするたびに、自動でチェックが走る仕組み（CI/CDパイプライン）を作りましょう。
ここでは、GitHub Actionsを使って、開発者がデプロイする前にIAMポリシーの静静的解析（今回はオープンソースの checkov を例にします）を自動実行する設定サンプルを見てみましょう。
プロジェクトのルートディレクトリに .github/workflows/security-check.yml というファイルを作成し、次のように記述します。
# 開発者の「うっかりミス」を自動で防ぐセキュリティチェックのワークフロー
name: IAM Policy Security Check
# GitHubにコードがプッシュされたり、プルリクエストが作られた時に自動で発動します
on:
push:
branches: [ "main", "develop" ]
pull_request:
branches: [ "main", "develop" ]
jobs:
iam-analysis:
runs-on: ubuntu-latest
steps:
# 1. リポジトリのコードを仮想環境にチェックアウトする
- name: Checkout repository
uses: actions/checkout@v4
# 2. Python環境をセットアップする
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.10'
# 3. 静替解析ツール（Checkovなど）をインストールする
- name: Install Security Tools
run: |
python -m pip install --upgrade pip
pip install checkov
# 4. IAMポリシーのJSONやTerraformコードに危険な設定がないかスキャンする
# （もし危険な設定が見つかったら、ここでビルドやマージを自動でストップさせます）
- name: Run Checkov Static Analysis
run: |
checkov -d . --framework terraform,json --check CKV_AWS_355,CKV_AWS_111このように、コードを書いた段階で自動的に「この権限、広すぎませんか？」と機械がツッコミを入れてくれる環境を作っておけば、本番環境に危険な合鍵が紛れ込むのを未然に防ぐことができます。
—
4. 未使用権限の特定とポリシーの最適化を進めるステップ
最後に、すでに動いているシステムに対して、どのように権限の断捨離（最適化）を進めていけばよいか、現場で使える現実的なステップをご紹介します。
ステップ1：AWSなら「IAM Access Analyzer」を有効にする
AWSをお使いなら、まずはボタン一つで有効化できる IAM Access Analyzer をオンにしましょう。これは、「外部の人がこのリソースにアクセスできる状態になっていないか」や「最近使われていない権限はどれか」を自動で分析してくれる強力な機能です。
ステップ2：ログ（CloudTrailなど）を活用する
「この権限、本当に使われているのかな？」と迷ったら、過去の利用ログ（CloudTrailのイベント履歴など）を覗いてみましょう。「あ、このAPI、過去90日間一度も呼ばれていないぞ」ということが分かれば、思い切ってその権限をポリシーから削除（または Deny に変更）します。
ステップ3：最小権限の原則（The Principle of Least Privilege）を徹底する
ポリシーを書くときは、
- 誰が（
Principal） - どの操作を（
Action：なるべく*は使わずs3:GetObjectのように具体的に） - どのリソースに対して（
Resource：特定のバケットやARNを指定する）
行うのかを、できる限り細かく限定するように心がけましょう。
—
まとめ
サーバーの要塞化というと、OSのパッチ当てやファイヤーウォールの設定といった「目に見えるインフラ部分」にばかり目がいきがちです。しかし、クラウド時代において一番の脆弱性は、往々にして「人間が適当に設定してしまった強すぎるアクセス権限」に潜んでいます。
最初は「細かく権限を分けるのって面倒だな……」と感じるかもしれませんが、一度仕組み（CI/CDや自動解析ツール）を作ってしまえば、あとはロボットが自動でお家を見守ってくれます。
「一歩ずつ、安全なおうちを作っていきましょう！」
あなたのインフラストラクチャが、今日も安全で快適に守られることを応援しています！
コメント