命名規則やタグ、暗号化、公開防止といった組織ルールは、レビューコメントで守らせるには限界があります。Policy as Codeでルールをコード化し、CIで機械的に止める設計を、代表的な3系統のツールに沿って整理します。
01なぜ「レビューで守らせる」が限界なのか
大手SIerやエンタープライズの現場では、命名規則、タグの必須付与、S3バケットの暗号化、セキュリティグループの全開放禁止といった「組織のお作法」が設計標準として定められています。問題は、その遵守をどう担保するかです。多くの現場ではプルリクエストのレビューコメントに頼っていますが、レビュアーの負荷が高く、見落としが起き、担当者が変わると運用が形骸化します。人間の注意力に依存した統制は、規模が大きくなるほど破綻します。
Policy as Code(PaC)は、この「お作法」を実行可能なコードとして記述し、CIパイプラインで機械的に検査する考え方です。ルールがコードになることで、レビューは「ポリシーそのものの妥当性」に集中でき、個別のプルリクは自動で判定されます。人が判断する領域と機械が判定する領域を分ける——これがPaCの本質です。本記事では、IaC(Infrastructure as Code)にガードレールを敷く代表的な3系統、OPA/Conftest・HashiCorp Sentinel・Checkov/tfsecを、実務での使い分けとともに整理します。
022つの検査ポイント — planを見るか、コードを見るか
IaCのポリシー検査には、大きく2つのアプローチがあります。1つはTerraformのplan結果(実行計画)を検査する方式。もう1つはソースコード(.tfやYAML)そのものを静的解析する方式です。この違いを理解しておくと、ツール選定で迷いません。
- plan検査型(OPA/Conftest、Sentinel):
terraform planの結果をJSON化し、「実際に何が作られ・変わり・消えるか」を評価します。変数展開やモジュール解決、既存stateとの差分まで反映された「未来の姿」を検査できるのが強みです。 - ソース静的解析型(Checkov、tfsec):
.tfファイルを直接パースし、既知のミス設定パターンを検出します。planを生成せず高速に回り、CIS/PCI DSSなどのベンチマークに沿った数百のルールが最初から入っている「即効性」が持ち味です。
両者は排他ではなく、組み合わせるのが実務の定石です。静的解析でセキュリティのベースラインを広く浅く押さえ、plan検査で組織固有のルール(このアカウントではこのタグ必須、この命名でなければ拒否)を精密に効かせる。以降、それぞれを見ていきます。
03OPA / Conftest — Regoで組織ルールを書く
Open Policy Agent(OPA)はCNCF卒業プロジェクトの汎用ポリシーエンジンで、Regoという専用言語でルールを記述します。特定ベンダーに縛られず、Kubernetesのマニフェスト、Terraformのplan、Dockerfileなど構造化データなら何でも評価できるのが最大の強みです。マルチクラウド・マルチツールの統制を1つのエンジンで貫きたいエンタープライズに向いています。
Terraformとの連携は、公式ドキュメントで示された手順が定石です。terraform plan -out=tfplan.binaryで計画を出し、terraform show -json tfplan.binary > tfplan.jsonでJSON化します。このJSONの.resource_changes配列に、各リソースのaddress・type・change.actions(create/update/delete)・change.after(適用後の姿)が入っており、ここをRegoで評価します。評価はopa exec --decision terraform/analysis/authz --bundle policy/ tfplan.jsonのように実行します。
実務では、OPAを直接叩くよりConftestを使うのが手軽です。ConftestはOPAをラップしたCLIで、conftest test tfplan.jsonの一行で、policy/ディレクトリ配下のRegoポリシー(deny・violation・warnルール)に対してファイルを検査します。JSON・YAML・HCL・Dockerfileなど幅広いフォーマットを直接パースできるため、「タグが付いていないリソースをdenyする」「暗号化されていないS3をdenyする」といった組織ルールを、宣言的に積み上げられます。
opa test)を書いておくと、ルール改修時のデグレを防げます。04HashiCorp Sentinel — 3段階の強制レベルという発明
HashiCorp Sentinelは、HCP Terraform(旧Terraform Cloud)およびTerraform Enterpriseに統合されたポリシーエンジンです。OSSのOPAと違い商用製品側の機能ですが、Terraformワークフローとの密結合、そして強制レベル(enforcement levels)という設計思想が実務で効きます。Sentinelはplanとapplyの間でポリシーを評価し、公式ドキュメントで定義された3段階の強制レベルを持ちます。
- advisory(勧告):違反しても警告を出すだけでapplyは止まりません。新ポリシーを導入する際、既存資産に猶予を与えながら周知する段階で使います。
- soft-mandatory(ソフト必須):違反するとapplyを止めますが、権限を持つ担当者がオーバーライド(例外承認)できます。オーバーライドは監査証跡として残るため、「原則禁止だが正当な理由があれば承認フロー付きで通す」という現実的な運用に噛み合います。
- hard-mandatory(ハード必須):違反すれば絶対にapplyを止め、例外は一切効きません。ポリシーを外す以外に回避手段がない、譲れないルールに使います。
この3段階が優れているのは、同じポリシーコードを、配置時の設定だけで強制強度を変えられる点です。強制レベルはポリシー本体ではなくsentinel.hclで指定するため、「まずadvisoryで様子を見て、棚卸しが済んだらsoft-mandatoryへ、定着したらhard-mandatoryへ」という段階的な締め上げを、コードを書き換えずに運用で回せます。前述の「一気に強制すると炎上する」問題への、製品としての回答がここにあります。
05Checkov / tfsec — 数百ルールで即座にベースラインを敷く
CheckovはBridgecrew(現Palo Alto Networks)開発のOSS静的解析ツールです。Terraform・Terraform plan・CloudFormation・Kubernetes・Helm・ARMテンプレート・OpenTofuなどを対象に、CIS・PCI DSS・HIPAA・SOC2といったコンプライアンス基準に沿った数百のビルトインポリシーが最初から入っています。checkov -d .とディレクトリを指定するだけで、その場でミス設定が一覧化される即効性が魅力です。
Checkovの技術的な強みはグラフベース解析です。リソースを単体で見るのではなく、リソース間の関係をグラフとして構築するため、「S3バケット自体はprivate設定だが、アカウントレベルのパブリックアクセスブロックが欠けている」といった、単純なパターンマッチでは見逃す複合的な問題を検出できます。カスタムポリシーはPythonまたはYAMLで記述でき(Regoには非対応)、YAMLはリソース間の接続状態やAND/OR条件、Pythonは属性の状態チェックに向くという分担で、組織固有ルールの追加にも対応します。
tfsecはAqua Security製のTerraform特化スキャナで、HCLをネイティブに理解し変数参照やモジュール構造を追える点が評価されてきました。ただし重要な注意点として、Aqua Securityは2023年(公式アナウンスは2023年2月18日)にtfsecのチェックライブラリをTrivyファミリーに統合し、以降tfsec単体は新規チェックが追加されない保守モードに移行しています。新規採用ならTrivyのIaCスキャン機能を選ぶのが妥当です。ツールの現行サポート状況やライセンスは移り変わるため、採用前に公式で要確認としてください。
--soft-failで最初はCIを落とさず件数だけ計測し、重大度の高いものから潰す。そして.checkov.yamlで正当な例外はスキップIDを明記して抑制し、抑制理由をコメントで残す運用にすると、ノイズと本当の違反を切り分けられます。06CIへの組み込み — 「止める」を仕組みにする
PaCは、CIパイプラインに組み込んで初めて価値を出します。ローカルで気が向いたときに走らせるだけでは、結局レビュー依存と変わりません。GitHub Actions・GitLab CI・Jenkins・Azure DevOpsいずれでも、プルリク時にポリシー検査ジョブを走らせ、違反があれば非ゼロの終了コードでCIを失敗させるのが基本形です。Checkov・Conftest・tfsecはいずれも違反時に非ゼロを返すため、ブランチ保護ルールと組み合わせればマージそのものを物理的にブロックできます。
組み込みの順序にはコツがあります。いきなりCIを赤くすると開発が止まるため、まずはPR上にコメントとして違反を可視化する非ブロッキング運用から始め、チームがルールに慣れた段階でマージブロックへ昇格させます。これはSentinelのadvisory→mandatoryと同じ発想で、ツールを問わず通用する導入プロトコルです。IaC向けCI/CDパイプラインの設計の中に、このポリシー検査ステージを組み込む形が実務では自然です。
DORA(State of DevOps)の継続的な調査でも、変更を小さく頻繁に、かつ自動化されたチェックを通して進めるチームほど、デプロイの安定性とスピードを両立できることが繰り返し示されています。ポリシー検査を人手のゲートではなくパイプラインの自動チェックに埋め込むことは、この知見に沿った投資です。
07SCPとの役割分担 — 予防ガードレールの二層構造
AWSを使う現場では、「Policy as Codeとマルチアカウント統制のSCP(Service Control Policy)は何が違うのか」という問いが必ず出ます。結論から言えば、両者は競合せず異なる層で働く予防ガードレールです。役割を混同すると、片方に穴が空きます。
- PaC(OPA/Sentinel/Checkov)は「デプロイ前(shift-left)」で効きます。IaCコードがapplyされる前にCIで止めるため、そもそも危険な変更がクラウドに到達しません。命名・タグ・暗号化といった「設計標準の遵守」を、開発者に最速でフィードバックするのが得意です。
- SCPは「実行時(runtime)」の最終防壁です。AWS公式が明記するとおりSCPは権限を付与せず、メンバーアカウントのIAMユーザー/ロールが取れる行動の上限(許可の最大範囲)を定めます。CIをすり抜けた操作やコンソールからの手動操作、CI外のツールによる変更も含めて、組織の境界で問答無用に拒否できます。ただし管理アカウントには効かない、といった制約はマルチアカウント統制の設計で押さえる必要があります。
実務では両方を敷きます。PaCで開発者体験を損なわず早期に矯正し、SCPで「万一すり抜けても組織としては絶対に許さない一線」を守る。例えば「特定リージョン以外でのリソース作成禁止」はSCPで最終防壁を張りつつ、PaCで開発段階から警告して手戻りを減らす、といった二層構造が堅牢です。SCPの具体的な組み方はOrganizations SCPによるガードレール設計で扱っています。
08ツールの使い分け — 現場への落とし込み
3系統を並べると迷いますが、選定軸はシンプルです。まずCheckov(またはTrivy)で無償・即時にセキュリティのベースラインを敷く——これはどの現場でも損がありません。次に、組織固有の複雑なルール(このアカウント/この命名/このタグ組み合わせでなければ拒否、といった文脈依存の判定)が必要になったら、plan検査型を足します。ここでHCP Terraform/Enterpriseを既に使っているならSentinelの強制レベルが噛み合い、マルチクラウドやKubernetesまで含めて1つのエンジンで統制したいならOPA/Conftestが適します。
- とにかく早く安全側に倒したい → Checkov / Trivy(静的解析、数百ルール既製)
- 組織固有ルールをコードで精密に書きたい・マルチツール統制 → OPA / Conftest(Rego、ベンダー非依存)
- HCP Terraform/Enterprise中心・段階的強制を運用で回したい → Sentinel(3段階の強制レベル)
- AWSの最終防壁 → SCP(実行時、PaCと二層で併用)
どのツールを選ぶにせよ、成否を分けるのは技術選定より導入プロトコルです。警告から始め、違反を可視化し、棚卸しし、段階的に強制へ昇格する——この順序を守れば、開発チームを敵に回さずにガードレールを定着させられます。私たちは導入事例でも、この「手が動かせる」粒度での設計・実装支援を重ねてきました。設計標準そのものの考え方はクラウド設計ガイドラインとあわせてご覧ください。
—まとめ
Policy as Codeは、レビュー依存で形骸化しがちな組織の「お作法」を、CIで機械的に止める仕組みに変えます。Checkov/tfsec(Trivy)で静的解析のベースラインを広く敷き、OPA/ConftestやSentinelでplanを検査して組織固有ルールを精密に効かせ、AWSではSCPを実行時の最終防壁として二層で併用する。技術以上に効くのは、advisoryから始めて段階的に強制へ昇格する導入プロトコルです。海外で確立したこの考え方を、日本のエンタープライズの承認フローと運用文化に馴染む形で落とし込むことが、定着の鍵になります。