【実務・中級編】 Infrastructure as Code (IaC) におけるIAM設定の静的解析とCI/CDパイプラインへの統合 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

IaCの「穴」を塞げ：TerraformをCI/CDで叩き斬る実戦的セキュリティ

現場で「とりあえず動く」Terraformコードを書いて満足していないか？
深夜のインシデント対応で、原因が「誰かが誤ってコミットしたIAMのフルアクセス権限」だったと判明した瞬間の絶望を、君には味わってほしくない。

現代のインフラ構築において、人間がコンソールをポチポチする時代は終わった。だが、IaC（Infrastructure as Code）の普及は、「脆弱な設定を爆速で全環境にばら撒く能力」を我々に与えてしまったのも事実だ。今日は、TerraformのコードをCI/CDパイプラインで自動スキャンし、開発者が「やらかす」前に止める仕組みを解説する。

—

1. なぜ「静的解析」が必須なのか

攻撃者は、GitHub上の公開リポジトリや、CI/CDの設定ミスを常に監視している。例えば、AWS S3バケットに s3:PutObject を Principal: "*" で設定したコードをpushした瞬間、数秒後には世界中のボットがそのバケットを叩きに来る。

攻撃者の視点：
彼らは複雑なハッキングなどしない。terraform plan の結果や、不適切なIAMポリシーが適用されたインスタンスのメタデータサービス（IMDS）を狙う。特に、IAMロールに iam:PassRole や s3:* のような「広すぎる権限」が付与されていると、Webサーバーの脆弱性を突かれた際、そのサーバーが「AWS環境全体の鍵」になってしまう。

これを防ぐ唯一の道は、「デプロイ前の自動門番（Static Analysis）」をCIパイプラインに組み込むことだ。

—

2. 現場で即効性のあるツール：tfsec / Checkov

手軽に導入できて効果が高いのが tfsec だ。これはTerraformコードを静的解析し、セキュリティベストプラクティスに反する設定を警告してくれる。

CI/CD（GitHub Actions）への統合設定

.github/workflows/security.yml を作成し、パイプラインの初期段階でチェックを強制しよう。

name: IaC Security Scan
on: [push]

jobs:
  tfsec:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      # tfsecをインストールして実行
      - name: Run tfsec
        uses: aquasecurity/tfsec-action@v1.0.0
        with:
          # 高リスクな脆弱性のみを検知し、失敗させる設定
          args: --minimum-severity CRITICAL

—

3. 「過剰権限」をブロックする：実戦的IAMポリシー設計

開発者がやりがちな「とりあえず AdministratorAccess をアタッチする」行為を物理的に防ぐには、Terraform側で権限を厳格に定義するポリシーをCIで強制することだ。

以下のTerraformコードは、S3バケットへのアクセスを最小権限の原則（Principle of Least Privilege）に基づき制限する例だ。

# セキュアなS3バケット定義のサンプル
resource "aws_s3_bucket" "secure_data" {
  bucket = "my-secure-app-data"
}

# パブリックアクセスを完全に遮断する設定
resource "aws_s3_bucket_public_access_block" "block_public" {
  bucket = aws_s3_bucket.secure_data.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# 最小権限のみを許可するIAMポリシーの例
resource "aws_iam_policy" "limited_access" {
  name        = "AppLimitedAccess"
  description = "特定のS3パスへの読み取りのみを許可"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "s3:GetObject"
        ]
        Effect   = "Allow"
        Resource = "${aws_s3_bucket.secure_data.arn}/uploads/*"
      }
    ]
  })
}

—

4. プロの教訓：なぜ「CIを通る」だけでは不十分なのか

静的解析ツールを導入すれば安心、ではない。ツールはあくまで「定義済みのルール」に照らしているだけだ。本当に怖いのは、「設計自体が間違っている場合」である。

メタデータサービスの保護: EC2インスタンスを作成する際、http_tokens = "required"（IMDSv2）を強制すること。これを忘れると、SSRF脆弱性が一つあっただけで、全権限を奪われる可能性がある。
暗号化の強制: EBSボリュームやRDS、S3には必ずKMSによる暗号化を強制せよ。「後でやる」は永遠に来ない。

セキュリティチーフからのアドバイス

CI/CDのパイプラインに tfsec を組み込んだら、次にやるべきは 「ポリシーのテスト」 だ。

Terratest などのフレームワークを使い、Terraformで作成したリソースが実際に「意図したセキュアな状態になっているか」をテストコード（Go言語等）で検証する習慣をつけてほしい。

// Terratestを用いた簡単なテスト例（概念）
func TestS3BucketEncryption(t *testing.T) {
    // 実際にデプロイして検証を行う
    // S3バケットが暗号化されているか確認するロジック
    assert.True(t, bucket.ServerSideEncryptionConfiguration != nil)
}

—

まとめ：セキュリティは「文化」である

IaCの静的解析は、単なるツール導入ではない。「インフラコードはアプリケーションコードと同じく、厳格なレビューとテストを経てデプロイされるべき」という文化をチームに定着させるためのトリガーだ。

今日から、GitHubのリポジトリに .tfsec 設定ファイルを置き、CI/CDで tfsec を回せ。そして、警告が出たら「警告を消す（＝設定を直す）」までマージボタンを押させない運用を徹底するんだ。

それが、君のシステムを守る最強の防御壁になる。セキュリティは、コードを書くその指先から始まっていることを忘れないでほしい。