【実務・中級編】 IAMにおける最小権限の原則(PoLP)の実装と権限境界の設計 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

IAMの「最小権限の原則」は、きれいごとではなく生存戦略だ

やあ、現場の最前線でコードと格闘している諸君。セキュリティの教科書には「最小権限の原則（PoLP: Principle of Least Privilege）を守れ」と必ず書いてある。だが、正直に言おう。この原則を「建前」として放置しているシステムほど、インシデント発生時に目も当てられない惨状になる。

攻撃者は君たちのコードの些細な隙（脆弱性）を突き、そこから権限を奪取して横展開（Lateral Movement）を試みる。もし、そのサービスアカウントに「全S3バケットへの読み書き権限」や「全EC2の停止権限」が付与されていたらどうなるか？攻撃者はその瞬間に、君たちのインフラの「神」になる。

今日は、そんな悪夢を未然に防ぐための、現場で使える「IAM権限境界の防衛線」について、泥臭い実装レベルで解説する。

—

1. 攻撃者が狙う「過剰権限」という盲点

典型的なPoC（概念実証）のシナリオを想像してほしい。
君たちが開発したWebアプリケーションに、OSコマンドインジェクションやSSRF（Server-Side Request Forgery）の脆弱性があったとする。攻撃者はその脆弱性を突き、メタデータサービス（169.254.169.254）から一時的な認証情報を引き抜く。

もしその認証情報が「PowerUser」のような広範な権限を持っていたら、攻撃者は即座に本番環境のデータベースをダンプし、バックアップを削除し、ログを消去するだろう。ここで重要なのは、「脆弱性は防げなくても、権限で被害を限定できるか」という点だ。

—

2. 実践：IAM Condition句による「物理的」な絞り込み

AWSのIAMポリシーを書く際、"Action": "s3:*" のようにワイルドカードを乱用していないか？これは「鍵をかけずに玄関を開けっ放しにする」のと同じだ。特定のバケット、特定の条件でしか操作できないように縛り上げるのがプロの仕事だ。

実装例：特定のVPCエンドポイントからのみアクセスを許可するポリシー

これは、外部からの不正アクセスや、認証情報が流出した際のリスクを劇的に下げる強力な手法だ。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificVPC",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::my-secure-data-bucket",
                "arn:aws:s3:::my-secure-data-bucket/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "aws:SourceVpce": "vpce-0123456789abcdef0" 
                }
            }
        }
    ]
}

解説: Denyを優先することで、たとえ正しい認証情報を持っていても、指定したVPCエンドポイント（vpce-0123456789abcdef0）以外からのアクセスは全て拒否する。これが「権限境界」の考え方だ。

—

3. アプリケーション層でのPoLP：サービスアカウントの分離

Webサーバーがデータベースを操作する際、アプリの全機能が同じDBユーザーを使っているケースをよく見る。これは論外だ。

Python (SQLAlchemy) を例にした権限分離の考え方

Webアプリの「読み込み専用機能」には権限を絞ったユーザーを、バッチ処理等の「書き込み機能」には書き込み専用のユーザーを割り当てる。

# 読み込み専用の接続設定（脆弱性が突かれても書き込みは不可）
read_only_engine = create_engine('postgresql://app_reader:password@localhost/mydb')

# 書き込みが必要な処理用（最小限の権限を持つユーザー）
write_engine = create_engine('postgresql://app_writer:password@localhost/mydb')

def get_data(id):
    with read_only_engine.connect() as conn:
        # この処理中にインジェクションが発生しても、データ改ざんやDROP TABLEはできない
        return conn.execute("SELECT * FROM sensitive_table WHERE id = %s", (id,))

—

4. エンジニアが今日からやるべき「ハーデニング」チェックリスト

現場で私が後輩に伝えている、最低限守るべきルールだ。

1. IAMの棚卸し: 90日以上使われていないIAMユーザーやアクセスキーは、容赦なく無効化する。
2. ワイルドカードの撤廃: ポリシー内で * を見つけたら、それは「設計不足」のサインだ。
3. インスタンスプロファイルの活用: EC2に恒久的な認証情報をハードコードしてはならない。必ずIAMロールをアタッチし、必要最小限の権限を付与する。
4. ガードレールの導入: AWS Organizationsを使っているなら、SCP（Service Control Policies）で「リージョン制限」や「ルートユーザーの操作禁止」を組織全体に強制する。

—

最後に：セキュリティは「完璧」ではなく「持続可能」なもの

「完璧なセキュリティ」なんてものは存在しない。あるのは「攻撃コストをいかに引き上げ、被害をいかに局所化するか」という戦いだけだ。

今回紹介したIAMのCondition句や、アプリケーションレベルでの権限分離は、一見すると面倒に思えるかもしれない。だが、一度インシデントが起きた時、その「面倒」が君たちと会社の資産を救う唯一の防波堤になる。

コードを書くとき、常に自問自答してほしい。「この権限は、本当にこれ以上削れないのか？」と。その問いこそが、君を一流のエンジニアにする。

さあ、今すぐコンソールを開いて、ワイルドカードの海を掃除してこよう。健闘を祈る。