ポリシーアズコードと継続的コンプライアンス

なぜ制約を「コード」にするのか

「本番の Pod は root で動かさない」「S3 バケットは暗号化必須」「タグのないリソースは作らせない」――こうした組織のルールは、長らく Wiki の文章とレビュアーの目視で守られてきました。問題は、自然言語のルールが実行可能でも検証可能でもないことです。レビュアーが見落とせば素通りし、ルールが更新されても古い構成は放置され、「いま全環境がルールに準拠しているか」を機械的に答えられません。

ポリシーアズコード（Policy as Code, PaC）は、この制約を宣言的なコードとして表現し、評価エンジンに機械判定させる考え方です。本質は、ポリシーを次の形の関数に還元することにあります。

decision = policy(input)
# input  : 評価対象を JSON 化したもの（マニフェスト、Terraform plan、API リクエスト…）
# policy : 制約を記述したルール集合（Rego, CEL, YAML…）
# decision: allow / deny（+ 違反理由）

この関数は理想的には**純粋（副作用なし・決定的）**です。同じ入力には常に同じ判定を返すため、テスト・バージョン管理・コードレビュー・再現が普通のコードと同じようにできます。これが目視レビューに対する決定的な優位です。

評価エンジンの内部：Rego を例に

代表格が CNCF の OPA（Open Policy Agent） と、その言語 Rego です。Rego は宣言的なクエリ言語で、命令的な手順ではなく「違反が成立する条件」を書きます。

package kubernetes.security

# Pod が root 実行なら deny に違反メッセージが入る
deny[msg] {
    input.kind == "Pod"
    some c
    container := input.spec.containers[c]
    not container.securityContext.runAsNonRoot
    msg := sprintf("container %v は runAsNonRoot=true が必須", [container.name])
}

ここで効いている原理が2つあります。第一に deny は集合（set） で、ルールを満たす全違反が要素として集まります。空集合なら準拠、要素があれば違反です。第二に、本体の各行は論理 AND で結ばれ、input.spec.containers[c] の c のような未束縛変数は全要素に対する反復として展開されます（内部的には全解の探索）。つまり「どれかのコンテナが runAsNonRoot 未設定なら…」を明示的なループなしに表現できます。

評価器は入力を**ドキュメント（木構造の JSON）**として読み、ルールを評価して仮想ドキュメントを生成します。Kubernetes の CEL も思想は近く、式が真偽を返す点は共通ですが、CEL は API サーバー内蔵で軽量・反復が限定的、Rego/Kyverno は外部エンジンで表現力が高い、というトレードオフがあります（/devops/admission-control-policy/ で強制点ごとに整理）。

強制点（PEP）をどこに置くか

ポリシーを書いても、それを**評価して実際に止める場所（Policy Enforcement Point, PEP）**がなければ絵に描いた餅です。PEP は実務上3つの層に置けます。

重要なのは、これらが代替ではなく多層防御だという点です。CI ゲートは「速いフィードバックで開発者体験を守る」層、admission は「どの経路から来た変更も取りこぼさない」最終層です。CI だけだと、kubectl apply を直接叩く、別ツールが書き込む、といった迂回路を塞げません。逆に admission だけだと、違反に気づくのがデプロイ直前になり手戻りが大きくなります。

ガードレールとポリシーの分類

PaC の制約は強制の仕方で大別できます。ハードガードレールは違反を deny で物理的に阻止します（防止的・preventive）。ソフトガードレールは警告のみで通し、後から是正を促します（発見的・detective）。組織を回す現実解は、リスクの高いルールだけハード、残りはソフトから始め、違反率を見て段階的に締める運用です。最初から全部ハードにすると、誤検知（false positive）で開発が止まり、ポリシー自体が無効化されます。

評価の観点でも、mutating（構成を改変して準拠させる。例：欠けたラベルを自動付与） と validating（改変せず合否だけ返す） を区別します。admission では mutating が先、validating が後に走り、validating 後はオブジェクトを変えられない――この順序は決定性のために重要で、検証した後で誰かが書き換える余地を残さないためです。

継続的コンプライアンス：検知・防止・証跡の三層

ここまでは「入る前に止める（防止）」話でした。継続的コンプライアンスはこれに検知と証跡を足し、3つの独立した役割に分解します。

1. 防止（強制）：PEP が違反を入口で止める。前述の三層。
2. 検知（ドリフト）：すでに存在する実体を定期的に再評価し、後から逸脱したものを見つける。
3. 証跡（監査）：いつ・何が・どのルールで・どう判定されたかを不変ログに残す。

検知が必要なのは、防止が完璧ではないからです。ポリシーが追加される前に作られたリソース、admission を持たない経路、緊急対応の手動変更などで、実体は静かにドリフトします。検知は実体（実クラウド・実クラスタの現状）を取得して JSON 化し、それを同じ policy(input) に通すことで、防止と同一のルールを再利用して逸脱を洗い出します。IaC では plan のリフレッシュがこの実体取得に相当します（/devops/iac-state-drift-locking/）。

GitOps とも自然に噛み合います。望ましい状態を Git に置き、収束ループが実体を Git に引き戻す仕組み（/devops/gitops-reconciliation/）に PaC を載せると、「Git にコミットされる構成」と「収束で適用される構成」の両方をポリシーで検査でき、ドリフトの是正と準拠の維持が一体化します。

ポリシー自体をどう正しく保つか

ポリシーはコードなので、コードと同じ品質問題を抱えます。誤って正当な構成を弾けば（false positive）開発が止まり、見逃せば（false negative）防御が穴になります。だからポリシーにはユニットテストが必須です。Rego なら test_ プレフィックスのルールで「この入力なら deny が空」「あの入力なら違反 1 件」を assert し、CI で回します。

もう一つの原理的注意は判定の決定性です。ポリシーが現在時刻や外部 API の応答に依存すると、同じ入力でも判定が揺れ、テストも監査も再現できなくなります。外部データ（許可リスト等）が要る場合は、評価時点のスナップショットを input に焼き込み、policy(input) を純粋関数に保つのが鉄則です。

まとめ

• 制約をコード化する本質は、目視レビューを decision = policy(input) というテスト・再現可能な純粋関数に置き換えること。
• 強制点は多層（CI ゲート・IaC plan・admission）。早い層は安く速く、実行時の層は迂回路を塞ぐ最終防壁。代替ではなく併用する。
• 継続的コンプライアンスは防止・検知・証跡を分離する。同じポリシーを実体に再適用してドリフトを検知し、判定の入出力を不変ログに残せば監査証跡が自動で揃う。
• ポリシー自体もテストし・決定的に保つ。これがなければ PaC は新たな見落としと不信の源になる。

「ルールは Wiki に書く」から「ルールはテストされ実行されるコード」へ。この転換が、準拠を人の注意力から機械の保証へ引き上げます。