IaCの「設定ミス」が会社を潰す——tfsec/CheckovをCI/CDに組み込むための実践戦術
現場で数々のインシデントを見てきた私から一つ、苦い真実を伝えよう。今日のサイバー攻撃者は、アプリケーションコードの脆弱性よりも、「設定ミスだらけのインフラ（IaC）」を狙う方が遥かに効率的だと知っているということだ。
AWSのS3バケットがパブリック公開されたまま放置されていたり、IAMロールが「とりあえず全権限（AdministratorAccess）」で作成されていたりする。これらは攻撃者にとって、鍵のかかっていない玄関を通り抜けるようなものだ。
今回は、TerraformやCloudFormationをただの「自動化ツール」で終わらせず、堅牢なセキュリティ要塞に変えるための実践的なアプローチを解説する。
なぜ「静的解析」がインシデント予防の切り札なのか
IaCの静的解析ツール（tfsec や Checkov）は、コードが実行される前に「この設定は危険だ」と警告を出す。これは、デプロイ後にクラウドの管理画面をポチポチ回って確認する作業とは次元が違う。
なぜなら、クラウドの権限設定は非常に複雑だからだ。例えば、S3のバケットポリシーひとつとっても、Principal: *（誰でもアクセス可能）になっていないか、暗号化は強制されているか、ログの保存先は適切かを人間がすべてチェックするのは不可能に近い。これを自動化しないのは、セキュリティを放棄しているのと同じだ。
CI/CDパイプラインへの組み込み：実践コード例
GitHub Actionsを使って、PRが投げられるたびに自動で脆弱性をスキャンする設定例を見てみよう。ここでは tfsec を例に挙げる。
.github/workflows/security-scan.yml
name: IaC Security Scan
on: [pull_request]
jobs:
tfsec:
runs-on: ubuntu-latest
steps:
- name: リポジトリをチェックアウト
uses: actions/checkout@v3
- name: tfsecを実行して脆弱性を検知
# --format sarif で結果を出力し、GitHubのSecurityタブに統合可能にする
run: |
wget -q -O tfsec https://github.com/aquasecurity/tfsec/releases/latest/download/tfsec-linux-amd64
chmod +x tfsec
./tfsec . --format sarif > results.sarif
- name: 結果をGitHubにアップロード
uses: github/codeql-action/upload-sarif@v2
with:
sarif_file: results.sarifこの設定を組み込むだけで、開発者が「誤ってパブリック公開の設定をコミットした」瞬間にビルドが失敗し、マージをブロックできる。「ミスに気づいた時にはすでに流出していた」という最悪のシナリオを物理的に防げるのだ。
実務で死ぬほど重要な「暗号化とIAM」の防御原則
ツールに任せきりにしてはいけない。重要なのは「何が危険か」を肌感覚で理解することだ。ここでは、最もミスが起きやすい AES-256 暗号化とIAM権限のセキュアな実装例を示す。
1. セキュアなS3バケット定義（Terraform例）
デフォルトの設定では、暗号化が有効になっていないケースが多い。必ず server_side_encryption_configuration を明示すること。
resource "aws_s3_bucket" "secure_bucket" {
bucket = "my-sensitive-data-bucket"
# 暗号化を強制する（AES-256）
server_side_encryption_configuration {
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256" # 強力な共通鍵暗号
}
}
}
}
# パブリックアクセスを完全遮断する
resource "aws_s3_bucket_public_access_block" "block" {
bucket = aws_s3_bucket.secure_bucket.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}2. IAMの最小権限原則（PoLP）の実装
「とりあえずAdministrator」は即刻禁止だ。特定のS3バケットに対する読み取り権限だけを与える例を挙げる。
# IAMポリシーの定義
resource "aws_iam_policy" "s3_read_policy" {
name = "S3ReadOnlyAccess"
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = ["s3:GetObject", "s3:ListBucket"]
Effect = "Allow"
Resource = ["arn:aws:s3:::my-sensitive-data-bucket/*"]
}]
})
}最後に：セキュリティは「文化」である
多くのエンジニアが「ツールを入れれば完璧」と勘違いしている。しかし、tfsec はあくまで「間違った設定」を指摘するだけであり、「ビジネスの要求に最適な権限設計」まではやってくれない。
本当に強いチームは、これらの静的解析ツールを「自分たちのコード品質を上げるための対話ツール」として使っている。スキャンで警告が出たとき、「なんでこれがダメなのか？」を議論し、納得して修正する。このプロセスこそが、チーム全体の防御力を底上げする。
今日から、プロジェクトのCI/CDパイプラインに一つ、セキュリティスキャンを加えてほしい。それが、明日、あなたのシステムがニュースのトップを飾るのを防ぐ、最初の一歩だ。
何か詰まったら、いつでも相談してくれ。泥臭い現場の知見を共有しよう。
コメント