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