Infrastructure as Code (IaC) は、チームがクラウドインフラストラクチャを構築する方法を変えました。それは、反復可能で、バージョン管理され、自動化可能です。しかし、その力には新たなリスクが伴います。IaCセキュリティスキャン、またはIaCスキャンは、YAML、HCL、およびその他のインフラファイル内の誤設定が本番環境に到達する前に発見することを可能にします。この記事では、IaCスキャンの仕組み、それが検出する（および見逃す）一般的なクラウドの誤設定、ソフトウェアライフサイクルへの組み込み方、そして検討すべきツールについて説明します。
IaCの仕組み（簡単な入門）
IaCを使用すると、クラウドコンソールでクリックする代わりに、ファイルでインフラストラクチャを宣言できます。この変化により、環境は再現可能かつ監査可能になります。コミット、計画、適用。主に2つのIaCスタイルがあります。
- 宣言的 — 望ましい最終状態を記述します（例：「バージョン管理とプライベートアクセスを備えたS3バケットが欲しい」）。TerraformやPulumiなどのツールは、実行時に現在の状態と望ましい状態を調整します。
- 命令型 — その状態に到達するためのステップバイステップのプロセスをスクリプト化します（例：Ansibleプレイブック）。ツールが行うすべてのアクションを制御できます。
宣言型と命令型の両方のIaCは、IaCスキャンにおける正当な対象です。IaCがどのように適用されるか（手動適用か、Kubernetesのような継続的な調整か）を理解することは、リスクとドリフトについて考察するのに役立ちます。
例：Terraform vs Kubernetes
Terraformは呼び出されたときに変更を計画し適用します。Kubernetesコントローラーは、宣言された状態を実行中のワークロードと継続的に調整します。これは、Kubernetesマニフェストにコミットされた設定ミスが常に強制される可能性があるのに対し、Terraformの間違いは誰かが更新を実行するまで残ることを意味します。
IaCスキャンが実際に何をするのか
その核となるIaCスキャンは、インフラストラクチャファイルに対する静的解析です。スキャナーはHCL、YAML、その他の形式を解析し、安全でない設定を示すパターンを特定します：
- 公開アクセス可能なストレージ（例：オープンなS3バケット）
- 開いているネットワークポートと広すぎるCIDRルール
- 過剰な権限を持つIAMロールまたはポリシー
- 暗号化の欠如（転送中または保存時）
- rootとして実行されている特権コンテナ
- 未固定または未宣言のコンテナイメージ
- ロギングと監視の無効化
ロギングを無効にしても攻撃者が直接侵入できるわけではありませんが、可視性が失われます。それ自体が重大なセキュリティリスクとなります。
IaCでよくある間違い（そしてそれがなぜ重要なのか）
監査および侵害報告書で最も頻繁に現れる設定ミスは以下の通りです。
- 露出したデータストレージ: 設定ミスのあるバケットは、しばしばデータ漏洩につながります。
- 緩いネットワークルール: 広範なCIDRと開かれたポートは攻撃対象領域を拡大します。
- 過剰な特権: 過度に許可されたIAMロールは、ラテラルムーブメントとデータ流出を可能にします。
- 部分的な暗号化: 保存時のみでなく、転送時にも暗号化しない（またはその逆）場合、ギャップが生じます。
- 特権コンテナ： rootとして実行されるコンテナは、爆発半径（被害範囲）を劇的に拡大させます。
- 可観測性の欠如: ログや監視をオフにすると、攻撃が検出されなくなります。
IaCスキャンができることとできないこと
IaCスキャンは、セキュリティに追加できる最も初期の自動チェックポイントであるため、強力です。ファイルがコミットまたは適用される前に問題を検出することで、修正コストを削減し、安全でないデプロイを防ぎます。
しかし、IaCスキャンには限界があります。
- これは静的です。デプロイされると、ランタイムの状態やサービス間の関係を認識しません。
- クラウドコンソールで直接行われた手動変更（ドリフト）を見落とす可能性があります。
- 個々の開発者は、一元化されたリポジトリに戻されることのないローカルスキャンを実行できるため、盲点が生じます。
ランタイムの問題とドリフトに対応するには、Cloud Security Posture Management (CSPM) またはランタイムスキャンが必要です。IaCスキャンとCSPMは補完的であり、IaCスキャンはデプロイ前に問題を防止し、CSPMは本番環境で発生する問題を発見します。
人気のあるオープンソースのIaCスキャンツール
いくつかの成熟したオープンソーススキャナーがあります。どのスキャナーを選択するかは、スタックとワークフローによって異なります：
- Checkov — Terraform、Kubernetes、CloudFormationなどに対応した豊富なルールを提供します。
- Terrascan — TerraformとPolicy-as-Codeのチェックに特化しています。
- Trivy — IaC、コンテナイメージなどをカバーする高速で軽量なスキャナーです。
スキャナーをローカルで実行するのは簡単です。ツールをインストールし、リポジトリに対して実行し、検出結果を確認します。Trivyをローカルで使用する場合の一般的なワークフローは次のとおりです。
結果には通常、明確なルール名、ファイルの場所、および修正のヒントが含まれており、開発者が迅速に変更を行うのに十分な情報を提供します。
SDLCにIaCスキャンを統合する場所
カバレッジを最大化し、バイパスを最小限に抑えるには、複数のポイントでIaCスキャンを組み込む必要があります：
- 開発者のワークステーション: コーディング中（コミット前またはローカル実行）の迅速なフィードバック。
- プレマージ / Gitフック: 安全でないコミットがプッシュされるのを防ぎます。
- CI/CDパイプライン: GitHub Actions、CircleCI、GitLab CIなどを使用して、すべてのPRとコミットに対してチェックを強制します。
- Gitでの一元化されたスキャン: 単一の信頼できる情報源はリポジトリであるべきです。コミット/マージ時の自動スキャンは一貫性を保証します。
GitリポジトリをIaCポリシーのコントロールプレーンとします。スキャンがローカルのみの場合、異なる開発者間で乖離が生じ、セキュリティギャップにつながる可能性があります。
オープンソースを超えて：修正を加速する最新機能
商用IaCプラットフォームは、手作業と誤検知を削減するワークフローおよびAI駆動型機能を追加します。
- AI AutoFix: コード修正を自動的に生成し、設定ミスを修正するプルリクエストを作成します。
- コンテキスト認識型無視ルール: 既知のテスト環境やリスクが許容される場所での検出結果を抑制します。
- 一元化されたダッシュボードとフィルタリング: チームやリポジトリ全体で検出結果をトリアージし、優先順位を付けます。
AutoFixは生産性を向上させるものとなり得ます。開発者は提案されたコード変更を受け取り、単一のワークフローで安全な修正をマージできます。ただし、予期せぬ動作を避けるため、生成された修正は常にコードレビューとテストと組み合わせてください。
IaCスキャンを開始するための実用的なチェックリスト
- スタックをカバーする主要なスキャナー（例：Trivy、Checkov）を選択してください。
- 開発中にローカルでスキャンを実行し、プリコミットフックを追加します。
- すべてのPRとコミットでCI/CDにおけるスキャンを強制する。
- Gitリポジトリを唯一の信頼できる情報源とし、可能な限りコンソールからの直接変更をブロックします。
- IaCスキャンをCSPM/ランタイムチェックで補完し、ドリフトや手動変更を検出します。
- AutoFixやコンテキストに応じた無視などのプラットフォーム機能を活用し、修正をスケールアップすることを検討してください。
結論: IaCスキャンは不可欠ですが、それだけでは不十分です
IaCスキャンは、誤設定がインシデントになるのを防ぐための最も早期かつ費用対効果の高い方法です。これにより、公開バケット、開いているポート、過剰な権限を持つIAMなどの一般的な問題が本番環境に到達する前に検出されます。ただし、静的スキャンがランタイムのポスチャ管理に取って代わるわけではありません。IaCスキャンは、多層的なクラウドセキュリティ戦略における重要な最初のレイヤーとして活用してください。
まず、開発者ワークフローとCIにスキャナーを追加し、Gitでチェックを一元化し、IaCスキャンとCSPMを組み合わせてランタイムのギャップをカバーします。時間とともに、修正を自動化し、コンテキストルールでシグナル・トゥ・ノイズ比を改善することで、チームは迅速に動き、安全を維持できます。
