Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
クラウドの構成ミスは、本番で発見した時点ですでに「コードに書かれた状態」になっていることが少なくありません。S3バケットの公開設定、過剰なIAMロール、全開放のセキュリティグループなどは、TerraformやCloudFormationのテンプレートに記述され、CI/CDを通ってそのままデプロイされます。つまり、多くの構成ミスは、本番のクラウドコンソールで発見する前に、コード段階で検出・修正できます。
本記事は、Terraform／Kubernetes Manifestを日常的に書くSRE・プラットフォームエンジニア、そして組織横断のガードレールを設計したいセキュリティ担当者・CISOを主な読者と想定し、IaC（Infrastructure as Code）セキュリティとPaC（Policy as Code）を、コード段階で構成ミスを防ぐための実装パターンとして整理します。
tfsec／Checkov／Terrascan／Trivyといったスキャナの使い分けから、OPA／Conftest／Kyverno／Gatekeeperによるポリシー強制、ドリフト検知、そして「PRをブロックすると開発者に嫌われる」という現実的な運用課題への向き合い方まで、デプロイ前の予防と本番運用をつなぐ視点で解説します。
1. IaCセキュリティとは何か — 「構成ミスをコードで止める」という発想
IaCセキュリティがデプロイ前に果たす役割とは何か。CSPMとの時間軸上の住み分けとあわせて整理します。
1-1. Infrastructure as Codeの普及と「設定ミスの自動量産」リスク
Infrastructure as Code（IaC）は、サーバ、ネットワーク、IAM、Kubernetesリソースといったインフラ構成を、Terraform／CloudFormation／Pulumi／Kubernetes Manifestなどのコードとして宣言し、Gitで版管理する手法です。再現性、レビュー可能性、自動化という大きな利点をもたらした一方で、セキュリティの観点では「設定ミスを自動で量産できてしまう」という副作用もあります。
手作業であれば1つのバケットを公開するのは1回の操作ですが、IaCでは誤った設定を1か所のモジュールに書けば、それを参照する複数のリソースが一斉に同じ穴を持ってデプロイされます。構成ミスの「爆発半径」がコードによって拡大する——これが、IaCセキュリティが必要とされる根本的な理由です。
1-2. IaCスキャンとCSPMの役割分担（デプロイ前 vs デプロイ後）
IaCセキュリティとCSPM（Cloud Security Posture Management）は、検査する「構成」という対象は重なりますが、見るタイミングが異なります。
両者は競合ではなく補完関係にあります。IaCスキャンで「コードに書かれた構成ミス」を予防し、CSPMで「コード外の手動変更やドリフト」を発見する。この二段構えが、クラウド構成管理の基本形です。
CSPM側の役割と運用設計の全体像は、「CSPMとは？クラウド構成ミスを未然に防ぐSecurity Posture Managementの全体像」を参照してください。本記事では、その手前にある「コード段階」に焦点を絞ります。
1-3. シフトレフトの中でのIaCセキュリティの位置づけ
IaCセキュリティは、シフトレフト（Shift Left）の中核施策の一つです。シフトレフトの実践ガイド「シフトレフト（Shift Left）とは？コンテナセキュリティをCI/CDに組み込む実践ガイド」では、CI/CDを「コミット → PR → ビルド → デプロイ」の4ステージに分け、IaCセキュリティとPaCをステージ3として位置づけています。
本記事は、その4ステージ俯瞰の中の「ステージ3＝IaC／PaC」部分を、実装ツールと運用設計まで踏み込んで深掘りするものです。後半で触れるPlan→Build→Run→Respondのライフサイクルの中では、本記事で扱うIaC／PaCはPlanフェーズに相当します。CI/CD全体への組み込み方や、シークレット管理・SBOMなど他ステージとの連携は、ハブ記事もあわせて参照してください。
2. IaCで起こりがちな構成ミスの典型
IaCスキャンが検出すべき構成ミスとはどのようなものか。具体的なコード例で見ていきます。
2-1. ストレージ公開・過剰IAM・暗号化漏れ・root実行
IaCで頻出する構成ミスは、CSPMが本番で検出するものと本質的に同じですが、それが「コードとして書かれている」点が異なります。代表的なものを挙げます。
- ストレージの公開設定：S3／GCS／Blobのバケットを、ブロックパブリックアクセスを無効にしたまま定義してしまうケース。
- IAMの過剰権限：Action: "*"／Resource: "*"を含むポリシー、AdministratorAccessの安易な付与。
- 暗号化の欠落：EBS／RDS／S3で暗号化指定を省略し、保存データが平文で保持される。
- ネットワーク全開放：セキュリティグループで0.0.0.0/0に対しSSH（22）／RDP（3389）／DBポートを開放。
- コンテナのroot実行・特権昇格：DockerfileやK8s ManifestでrunAsNonRootを指定せず、privileged: trueを許可。
たとえば次のTerraformは、ブロックパブリックアクセスを指定していないため、後続のACL設定次第で公開され得る危険な記述です。
resource "aws_s3_bucket" "logs" {
bucket = "example-app-logs"
}
resource "aws_security_group_rule" "ssh_open" {
type = "ingress"
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"] # 全開放：IaCスキャンで検出すべき典型例
security_group_id = aws_security_group.bastion.id
}IaCスキャナは、こうした記述をデプロイされる前に検出し、PRの段階で警告またはブロックします。
2-2. Kubernetes Manifest特有のリスク（RBAC・PSA・NetworkPolicy）
KubernetesのManifestでは、クラウドリソースとは別系統のリスクが発生します。
- 過剰なRBAC：ClusterRoleにverbs: ["*"]／resources: ["*"]を付与し、ServiceAccountが実質的にクラスタ管理者になっている。
- Pod Securityの欠如：securityContextを指定せず、privileged: true／hostNetwork: true／hostPID: trueを許可。Pod Security Admission（PSA）のrestrictedプロファイルに違反する記述。
- NetworkPolicyの不在：デフォルトではPod間通信が全許可のため、NetworkPolicyを定義しないと横展開（lateral movement）を制限できない。
- Secretsの平文管理：SecretをBase64のままGitにコミットし、暗号化なしで保管。
apiVersion: v1
kind: Pod
metadata:
name: risky-pod
spec:
containers:
- name: app
image: example/app:latest
securityContext:
privileged: true # 特権コンテナ：PSA restricted違反
runAsUser: 0 # root実行Kubernetes構成のポスチャ管理（KSPM）とこれらのManifest検査の関係は、CSPMハブ記事のKSPMの章でレイヤ構造として整理しています。本記事では、「Manifestをコードとして書く段階で何を弾くか」に集中します。
2-3. ドリフト（コードと実態の乖離）という構造問題
IaCを導入しても、本番環境が常にコードと一致しているとは限りません。インシデント対応のための緊急手動変更、コンソールからの一時的な設定変更、別チームによる上書き——こうした「コードに戻されない変更」が積み重なると、IaCのコードと実態が乖離するドリフトが発生します。
ドリフトの厄介な点は、「コードは正しいのに本番が危険」という状態を生むことです。IaCスキャンはコードしか見ないため、ドリフトそのものは検出できません。ここを埋めるのがCSPMの継続スキャンであり、「IaCスキャン（コードの正しさ）× CSPM（実態の正しさ）」の両輪でしかドリフトは管理できません。
そのため、コード段階の検査と本番環境の継続監視を、別ツール・別運用で分断しないことが重要です。
3. IaCセキュリティスキャンの主要ツール
IaCスキャンを担う代表的なOSSツールを、対象範囲と特徴の軸で押さえておきましょう。
3-1. tfsec／Checkov／Terrascan／KICSの比較
実務的には、マルチクラウド・多フレームワークならCheckov、Terraform中心ならtfsec／Trivyを起点に選ぶ構成が多く見られます。複数ツールは検出ルールが部分的に重複するため、まず1つをCIに組み込み、カバレッジの穴を別ツールで補う進め方が現実的です。
3-2. PRゲートとIDE統合 — 開発者の流れを止めない検査点
IaCスキャンの価値は、検出そのものより「どこで開発者にフィードバックするか」で決まります。配置すべき検査点は概ね3つです。
- IDE（コーディング中）：VS Code拡張などで記述中にリアルタイム警告。最も早く、修正コストも最小。
- PR（レビュー時）：GitHub Actions／GitLab CIでスキャンを走らせ、結果をPRコメントとして自動投稿。レビューの流れの中で指摘が届く。
- マージゲート（必須チェック）：重大度の高い検出のみマージをブロックし、それ以外は警告に留める。
GitHub ActionsでCheckovをPRに組み込む最小例を示します。
name: iac-scan
on: [pull_request]
jobs:
checkov:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: bridgecrewio/checkov-action@master
with:
directory: .
soft_fail: true # まず警告のみ（段階導入）
output_format: github_failed_onlysoft_fail: trueで警告から始め、運用が定着してから重大度別にブロックへ格上げするのが、現場に受け入れられやすい導入手順です。
3-3. 誤検知（False Positive）とのつき合い方
IaCスキャンは、初回導入時に大量の検出を出します。その中には「意図して許可している構成」も含まれるため、抑制（suppression）の仕組みをルール化しておくことが、形骸化を防ぐ鍵になります。
- インラインの抑制コメント：#checkov:skip=CKV_AWS_20:静的サイト配信用バケットのため公開は意図的のように、理由付きでコード内に記録する。
- ベースライン機能：既存の検出を一旦ベースライン化し、「新規に増えた検出」だけをPRでブロックする。
- 例外の有効期限：恒久的な抑制を避け、期限付き例外として定期的に棚卸しする。
重要なのは、「抑制＝なかったことにする」ではなく、「抑制＝誰が・なぜ許可したかをコードに残す」という運用にすることです。これにより、監査時にも判断根拠を追跡できます。
4. Policy as Code（PaC）— ガードレールをコードで強制する
IaCスキャンの一歩先にあるのがPolicy as Code（PaC）です。両者の違いを一言で言えば、IaCスキャンが「ツール側が提供する既定ルールによる検査」であるのに対し、Policy as Codeは「組織独自のルールそのものをコード化して強制する仕組み」です。
CheckovやConftestのように両者の境界に位置するツールもありますが、本記事では「既製ルールでの検査」をIaCスキャン、「自組織のルールのコード化」をPaCとして整理します。その考え方と実装を見ていきます。
4-1. ルールベース検査から「ポリシーをコードで宣言」へ
IaCスキャンは「既製のルールセットに照らして合否判定する」アプローチですが、PaCは「自組織のセキュリティ基準そのものをコードとして宣言し、自動適用する」アプローチです。
たとえば「本番環境ではprivilegedコンテナを禁止する」「すべてのS3バケットはパブリックアクセスをブロックする」「タグにownerがないリソースは作らせない」といった組織固有のルールを、人間のレビューに頼らずコードとして表現します。ポリシーがコード化されることで、ルールそのものが版管理・レビュー・テストの対象になり、全環境に一貫して適用できるようになります。
4-2. OPA／Rego・Conftest・Kyverno・Gatekeeper
PaCの代表的な実装系統を整理します。
CI段階（デプロイ前）ではConftest、クラスタ受け入れ段階（Admission）ではKyverno／Gatekeeper、という二段構えが定番です。ConftestでTerraform planを検査する例を示します。
# policy/deny_public_s3.rego
package main
deny[msg] {
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket_public_access_block"
resource.change.after.block_public_acls == false
msg := sprintf("S3 %v: block_public_aclsを無効化できません", [resource.address])
}terraform plan -out=tfplan.bin
terraform show -json tfplan.bin > tfplan.json
conftest test tfplan.json --policy policy/4-3. Admission Control連携でデプロイ前に弾く
PaCの効力が最大化するのは、CIのチェックをすり抜けた変更でも、KubernetesのAdmission（受け入れ）段階で最終的に弾けるようにしたときです。Kyvernoで「特権コンテナを拒否する」ポリシーの例を示します。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-privileged
spec:
validationFailureAction: Enforce
rules:
- name: privileged-containers
match:
any:
- resources:
kinds: [Pod]
validate:
message: "特権コンテナは許可されていません"
pattern:
spec:
containers:
- =(securityContext):
=(privileged): "false"CI（Conftest）とAdmission（Kyverno／Gatekeeper）の両方に検査点を置くことで、「コードレビューで弾く」「それでも漏れたものはクラスタが弾く」という多層防御が成立します。ただし、Admissionでの拒否は本番デプロイを止めるため、Auditモードで影響を観測してからEnforceへ移行する段階導入が安全です。
4-4. コンテナイメージの信頼性ゲートとの接続
PaCは構成だけでなく、「どのイメージを起動してよいか」のガードレールにも使えます。署名済み・スキャン済みのイメージのみAdmissionで許可する、といったポリシーは、ビルド段階のイメージスキャンと表裏一体です。
イメージ側のスキャン・署名・レジストリ運用の詳細は、「コンテナイメージスキャンと依存パッケージ管理｜Build段階で脆弱性を止める実践」で扱っています。構成ポリシー（本記事）とイメージポリシー（当該記事）を組み合わせて設計してください。
なお、PaCはあくまでデプロイ前のガードレールであり、デプロイ後に発生するドリフトそのものを検出するものではありません。CIやAdmissionをすり抜けずに弾けたとしても、デプロイ後の手動変更やコンソール経由の上書きは別問題として残ります。ドリフトの検出には、引き続きCSPMの継続スキャンが必要です。
5. IaCセキュリティの運用設計
IaC／PaCを「ツール導入」で終わらせず、「運用」として根付かせる手順を整理します。
前提として、ここまで扱ってきたIaC／PaCはクラウドネイティブ防御のPlanフェーズに位置づけられます。続くイメージスキャンがBuild、CWPP／CDRによるランタイム検知がRunを担い、それぞれがPlan→Build→Run→Respondという時間軸でつながります。本章以降は、Planフェーズの運用を起点に、隣接するBuild／Runとどう接続するかを見ていきます。
5-1. 段階導入（warn → block）と例外管理
IaC／PaCをいきなり「全件ブロック」で始めると、開発が止まり、ゲートを迂回する文化を生みます。現実的な導入は、次の段階を踏みます。
- 可視化フェーズ：全PRでスキャンを走らせるが、結果は警告のみ（soft_fail(Checkow)／Audit(Kyverno)）。検出の母数と傾向を把握する。
- 重大度ゲートフェーズ：Critical／Highのみマージブロックに格上げ。Medium以下は警告継続。
- ポリシー強制フェーズ：組織共通のPaCをAdmissionでEnforce。例外は理由・期限付きで明示登録。
各フェーズの間に「既存検出のベースライン化」を挟むと、過去分の負債に押し潰されず、新規流入だけを確実に止められます。
5-2. 開発・プラットフォーム・セキュリティの責任分担
IaCセキュリティの検出を「誰が直すか」は、リソースを定義したチーム、つまり開発チームやプラットフォームチームです。セキュリティチームの役割は、ルールセットとPaCの定義、例外承認、横断レポートに置きます。「スキャンはセキュリティ、修正は所有者」という線引きを最初に決めておかないと、検出が宙に浮いて積み上がります。
修正期限（SLA）やRACI（誰が責任を持ち、誰が承認するか）の具体的な設計は、ライフサイクル運用設計の正典である「DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方」に集約しています。本記事では「IaC／PaCという技術コンポーネント」に焦点を絞り、組織ガバナンスの詳細は当該記事を参照する構成にしています。
5-3. コード段階の検査をRunの知見で重み付けする
IaC／PaCは「構成ミスを減らす」仕組みですが、検出されたリスクの優先順位付けまでは得意ではありません。単体では「コード上のすべての構成リスク」をフラットに並べるだけで、どこから直すべきかの優先度はつきにくいのです。たとえば「過剰なIAM権限」がコードに書かれていても、その権限が本番で実際に使われていなければ、緊急度は下がります。
ここで効くのが、コード段階（Plan）の検出をRun（本番）の実行情報で重み付けする発想です。実際に攻撃経路として到達可能か、該当リソースが稼働中か、権限が実使用されているか——こうしたランタイム由来のコンテキストを掛け合わせることで、「直すべき構成ミス」を現実的な件数に絞り込めます。
このようなPlan ↔ Runを往復させる優先順位付けの考え方は、近年のCNAPP製品でも重要な設計要素になっています。Sysdigにおける具体的な実装は次章で扱い、その中核となるランタイム観測の仕組み・数値は、Runtime Insightsの正典である「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」で扱います。
6. Sysdig SecureのIaC／Policy as Code機能
最後に、Sysdig SecureがIaC／PaCをどのように支援するかを概観します。
6-1. IaCスキャンとCSPMの一元管理
Sysdig Secureでは、IaCスキャンによるコード段階の構成ミス検知と、CSPMによる稼働中クラウド構成の継続監視を、同一のCNAPPプラットフォーム上で管理できます。
これにより、Terraform／CloudFormation／Kubernetes Manifest／Helmなどに記述された構成と、実際に稼働しているクラウド・Kubernetes環境の状態を突き合わせ、コードと実態の乖離やドリフトを継続的に把握しやすくなります。コード段階の検査と本番環境の継続監視で判定基準を揃えやすくなる点も、運用上の利点です。
CNAPPプラットフォーム全体での位置づけは、「CNAPPとは何か？」も参照してください。
6-2. Runtime Insightsによる「直すべき構成ミス」の優先度付け
Sysdigでは、IaC／CSPMが検出した構成リスクに、Falcoをベースにしたランタイム観測の情報を組み合わせて優先度付けできます。
コード上は多数に見える構成リスクでも、「実際に稼働中か」「外部から到達可能か」「攻撃経路上にあるか」「権限が実使用されているか」といった実行時の文脈を加えることで、開発チームが優先して対応すべきリスクを絞り込みやすくなります。
この優先度付けの中核となるRuntime Insightsの仕組みと、ノイズ削減の具体的な数値・事例は、「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」に集約しています。
6-3. Sysdig Sage™による修正提案
検出されたIaCの構成ミスやポリシー違反に対し、Sysdig Sage™はAIを用いて優先順位の根拠や修正方針を提示します。
「どの構成ミスから直すべきか」「どう直せばよいか」を整理しやすくなることで、セキュリティ担当と開発担当のあいだの確認コストを減らせます。IaCスキャンが「指摘するだけで直らない」状態に陥らないよう、検出から修正までの流れを支援する位置づけです。
7. まとめ — 構成ミスは「コードの段階」で止める
IaCセキュリティとPolicy as Codeは、クラウド構成ミスを本番環境で発見するのではなく、TerraformやKubernetes Manifestなどのコードに書かれた段階で検出・制御するための実装アプローチです。tfsec／Checkov／Terrascan／TrivyなどのスキャナでPR段階に検査点を置き、OPA／Conftest／Kyverno／Gatekeeperで組織共通のガードレールをコードとして強制することで、デプロイ前の予防線を構築できます。
ただし、IaCスキャンが見られるのはあくまでコード上の構成です。デプロイ後の手動変更やドリフトはCSPMで継続的に検知し、構成ミスを突いた実際の攻撃はCWPP／CDRなどのランタイム検知で捉える必要があります。IaC／PaCは強力な予防策ですが、単体で完結するものではなく、CSPMやランタイム検知と接続して初めて、Plan→Build→Run→Respondを貫く防御線になります。
導入時に重要なのは、ツール選定だけではありません。段階導入（warn → block）、例外をコードに残す運用、所有者とSLAの明確化を先に決めることが、IaCスキャンの形骸化を防ぐ最大のポイントです。
コード段階で構成ミスを防ぎ、コード外の変化はCSPMで捉え、本当に直すべきものをランタイムの知見で絞り込む。この設計が、構成ミス起因のインシデントを構造的に減らします。