IaCスキャンは「お守り」ではない：設定ミスが招くインフラ崩壊の深淵
多くのエンジニアが「IaC（Infrastructure as Code）をCI/CDに組み込めば、セキュリティは担保される」と錯覚している。だが、現場の泥臭いインシデントを見てきた我々からすれば、それは単なる「静的チェックの通過儀礼」に過ぎない。
真に恐れるべきは、スキャンツールが検知できない「論理的な設定の歪み」だ。今回は、ただツールを回すだけの次元を脱し、アーキテクトが意識すべきIaCセキュリティの核心について語る。
—
1. 静的解析の「限界点」を理解せよ
Terraformのプランニング時に tfsec や checkov を走らせる。これは最低限の規律だが、これだけで安全だと思ったら大間違いだ。
例えば、S3バケットの公開設定（public_read）を禁止するルールをCIに書いたとしよう。しかし、攻撃者はその「先」を突く。
- IAMロールの過剰な権限委譲:
Action: "*"を指定しつつ、Resourceを"*"にしているコードは、スキャンツールでは「重大な警告」止まりだが、実質的には権限昇格のトリガーだ。 - リソース間の依存関係の欠落: セキュリティグループのルール単体は正しくても、それが接続されるエンドポイントが「VPCエンドポイント」を経由しているか、あるいはインターネットゲートウェイが意図せず接続されていないかという「トポロジーの脆弱性」は、コード片だけでは判断できない。
対策：ポリシー・アズ・コード（OPA）による文脈依存チェック
単なるルールベースの検知ではなく、Open Policy Agent (OPA) を用いて、リソース間の相関関係を評価するポリシーを書くべきだ。
# OPAによるポリシー例：RDSは必ず暗号化され、かつ指定のVPC内にあることを強制する
package terraform.security
# 暗号化されていないRDSを拒否
deny[msg] {
resource := input.resource_changes[_]
resource.type == "aws_db_instance"
resource.change.after.storage_encrypted == false
msg := sprintf("RDS %s は暗号化が必須です", [resource.address])
}—
2. 生成AIによる「プロンプトインジェクション」とIaCの融合
今、最も警戒すべきは、開発者が生成AI（GitHub Copilot等）からコピペしたコードの「毒性」だ。AIは「動くコード」を作るのは得意だが、「セキュアなコード」の文脈理解には欠陥がある。
特に危険なのは、AIが提案するIAMポリシーやSecurity Groupの設定だ。AIは高確率で「動作させるために 0.0.0.0/0 を許可する」といった安直な解決策を提示する。これをそのままパイプラインに流せば、自動的に脆弱性がインフラに刻まれる。
防衛層（ガードレイル）の構築:
パイプライン内に、AIが生成したコードの「特異性」を検知するロジックを組み込むべきだ。例えば、特定のポートが意図せず開放された際、過去の正常なコミット履歴と比較し、閾値を超えた変更に対しては自動で「人間による承認（Manual Approval）」を要求するゲートを設ける必要がある。
—
3. 通信プロトコルの欠陥と耐量子暗号への布石
IaCスキャンは、デプロイされるインフラの「暗号化設定」も監査できる。ここで重要なのは、現在の TLS 1.2 や 1.3 の設定だけでなく、将来的な 耐量子暗号（PQC: Post-Quantum Cryptography） への移行を見越した設計だ。
IaCにおいて、暗号化アルゴリズムをハードコードするのではなく、変数として管理し、中央のポリシーエンジンで一括制御せよ。
# セキュアな暗号化設定の標準化（モジュール化）
resource "aws_lb_listener" "front_end" {
load_balancer_arn = aws_lb.main.arn
port = "443"
protocol = "HTTPS"
# TLSポリシーを最新に強制
ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.main.arn
}
}—
4. 現場のアーキテクトに捧げる「監査」の哲学
結局のところ、IaCスキャンは「事故を減らすためのフィルタ」に過ぎない。本当に信頼すべきは、以下の3つの観点だ。
1. ドリフト検知の徹底: コードと実環境の乖離（ドリフト）は、セキュリティの死角そのものだ。terraform plan を定期的に実行し、自動修正ではなく「通知とアラート」を飛ばす運用を構築せよ。
2. パイプラインの不可侵性: CI/CDツール自体が攻撃者の標的だ。パイプラインの定義ファイル（.github/workflows/*.yml）を保護し、誰がその設定を変更できるのか、厳格な権限管理を適用せよ。
3. 「なぜこの設定なのか」をコードに残す: セキュリティの例外処理を行う場合、必ずコードコメントとして「なぜこのリスクを受容したのか」という技術的判断の根拠（Rationale）を記述せよ。これが後の監査における最大の武器となる。
セキュリティは、設定ミスを防ぐツールを導入して安心するためのものではない。「壊れることを前提に、その壊れ方を制御し、いち早く検知する」。この泥臭い戦いこそが、最高峰のホワイトハッカーとしての生存戦略である。
コードを書くとき、自問してほしい。「このインフラ設定は、明日の未知の攻撃に対して耐えうるか？」と。答えが曖昧なら、それはまだ修正の余地があるということだ。
コメント