IaCは「自動化の武器」か「破壊の導火線」か ― 静的解析で防ぐインフラ崩壊
「またS3バケットがパブリック公開されてるぞ」。深夜のSlackに飛び込むアラートほど、背筋が凍るものはない。
君たちが必死に書いたそのTerraformやCloudFormationのコード、本当に「安全」と言い切れるか？ クラウド時代、インフラはコード（IaC）として管理される。しかし、それは「脆弱性もまたコードとして全環境に高速伝播する」ことを意味する。手動で1つのバケットをミスするのと、IaCのミスで全環境のバケットを公開するのとでは、被害の桁が違う。
今日は、IaCの静的解析（Static Analysis）という「最後の防衛線」について、現場の泥臭い知見を共有しよう。
なぜ静的解析ツール（tfsec/Checkov）が必須なのか
「レビューで指摘すればいい」？ 甘い。人間はミスをする。疲れている時の深夜デプロイや、急ぎのHotfixで、設定ミスは必ず紛れ込む。
攻撃者は、GitHub上の公開リポジトリや、CI/CDパイプラインの構成ミスをスキャンしている。特にS3のパブリックアクセス設定や、IAMのAction: ""といった「設定の穴」は、彼らにとっての宝の山だ。
攻撃者の視点：PoC（概念実証）
攻撃者は君たちのコードを読み解くのではない。git cloneした後に、自動スキャンツールで「公開状態のデータベース」や「過剰な権限を持つIAMロール」を瞬時に特定する。
例えば、以下のようなTerraformの設定があったとしよう。
危険な実装例：パブリックアクセスを許可してしまっているバケット
resource “aws_s3_bucket” “data_store” {
bucket = “my-company-sensitive-data”
# aclがpublic-readやpublic-read-writeになっていると即死する
acl = “public-read”
}
このコードをCIに流した瞬間、攻撃者のBotは検知し、数秒後にはデータが暗号化され、身代金要求のメールが届く。これを防ぐのが、デプロイ前の「静的解析」だ。
実践：Checkovによる自動防衛ラインの構築
Checkovを使えば、CIパイプラインの中で「ポリシーに違反するコード」をデプロイ前に強制終了できる。
1. Checkovのインストールと実行
ローカル環境ですぐに試せる。
インストール
pip install checkov
特定のディレクトリをスキャン
checkov -d ./terraform/
もし脆弱性があれば、Checkovは即座にエラーを吐き、CIを失敗（Exit Code 1）させる。これこそが、ミスを本番に持ち込ませない最強の仕組みだ。
2. セキュアな実装への書き換え（ベストプラクティス）
先ほどのS3バケットを「鉄壁」にする設定がこちらだ。これをテンプレートとして共有する。
セキュアな実装例
resource “aws_s3_bucket” “data_store” {
bucket = “my-company-sensitive-data”
}
パブリックアクセスを完全にブロックする設定（必須）
resource “aws_s3_bucket_public_access_block” “data_store_block” {
bucket = aws_s3_bucket.data_store.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
バージョニングの有効化（誤削除対策）
resource “aws_s3_bucket_versioning” “data_store_versioning” {
bucket = aws_s3_bucket.data_store.id
versioning_configuration {
status = “Enabled”
}
}
現場で差がつく「CI/CDへの組み込み」Tips
単にツールを入れるだけでは意味がない。チームで運用を回すための「泥臭い工夫」を伝授する。
- パイプラインのFail戦略: CI（GitHub Actions等）では、
--soft-failオプションを使わないこと。チェックに引っかかったらビルドを止める。これが「痛みを伴う学習」になり、開発者が安全な書き方を覚える近道だ。 - 例外管理の透明化: どうしても設定上、例外が必要な場合は、コード内に
checkov:skipを記述させるルールにする。ただし、その際は必ず「なぜ必要なのか」のコメントを必須とし、セキュリティレビューの記録を残すこと。
例外を許可する場合の記述例
resource “aws_s3_bucket” “logs” {
# checkov:skip=CKV_AWS_18: ログバケットのためパブリックアクセスは不要だが要件により一時的に例外
bucket = “my-company-logs”
}
最後に：セキュリティは「文化」である
IaCの静的解析を導入することは、単なるツール導入ではない。「インフラの安全性を、人間の記憶力や注意力から切り離す」という設計思想への転換だ。
優秀なエンジニアは、コードを書くときに「どうやって楽をするか」だけでなく、「どうやって自分のミスをシステムで防ぐか」を考える。君たちには、ぜひ後者の思考を持ってほしい。
明日の朝、君たちのCIパイプラインにCheckovやtfsecが導入されていることを期待している。もし設定で詰まったら、いつでも聞きに来い。現場からは以上だ。
コメント