リクルーティングサイト
テックカリキュラム

Sentinelによるポリシー適用 ── Terraformの実行に“組織のルール”を埋め込むPolicy as Code戦略

Sentinelによるポリシー適用 ── Terraformの実行に“組織のルール”を埋め込むPolicy as Code戦略

はじめに

Infrastructure as Code（IaC）によってインフラ構成は自動化されましたが、「誰が」「何を」「どのように作るか」を制御するガバナンスは別途必要です。

Terraform Enterprise（TFE）または Terraform Cloud（TFC）では、Sentinelというポリシーエンジンを使って、**Terraformコードの実行に対して強力なポリシー制御**を行えます。これにより、セキュリティ・コスト・構成ルールを**コードベースで一貫管理**することが可能になります。

この記事では、以下の観点から Sentinel の活用法を最大ボリュームで解説します。

  • Sentinelの基本構造と適用レベル
  • 主要ユースケース：タグ強制、リージョン制限、リソース数制限、コスト制御
  • Sentinelコードの実装例と解説
  • Terraform Cloudでの実装フロー
  • 実務でのポリシー開発・レビュー体制

1. Sentinelとは何か？Terraformにおける役割

Policy as Code（PaC）の考え方

Policy as Codeとは、「人が頭で判断していたポリシー（ルール）をコードで定義する」考え方です。Sentinelはこの考え方をTerraformに導入するための専用DSL（ドメイン固有言語）です。

Terraform Cloud / Enterprise の実行フローにポリシーチェックを組み込むことで、計画（plan）や適用（apply）前にポリシー違反を検出し、ブロックできます。

ポリシーが実行されるステージ：

  • pre-plan：planの前にルール確認
  • post-plan：plan結果に対して評価
  • pre-apply：apply前に最終チェック

3段階の強制レベル

ポリシーモード動作
advisory警告表示のみ。実行は継続。
soft-mandatory違反時に承認者の判断で実行可。
hard-mandatory違反時は完全にブロック。

2. Sentinel活用のユースケースと実装例

① タグ強制：すべてのリソースに特定のタグを義務化

チーム・コスト配分・環境区分などを明示するタグが欠如すると、運用・可視化・FinOpsに支障が出ます。

// require_tags.sentinel import "tfplan/v2" as tfplan main = rule { all_resources = tfplan.resource_changes as r { all r as rc { rc.change.after contains "tags" and rc.change.after.tags contains "Project" and rc.change.after.tags contains "Owner" } } all_resources }

違反時の表示メッセージ：

リソースに Project および Owner タグが設定されていません。全リソースにこれらのタグを必須としてください。

② リージョン制限：特定リージョン以外での構築を禁止

// restrict_region.sentinel import "tfconfig" main = rule { tfconfig.provider["aws"].region is "ap-northeast-1" }

東京リージョン以外でリソース作成が試みられると、実行がブロックされます。

③ EC2インスタンスタイプ制限

// restrict_instance_type.sentinel import "tfplan/v2" as tfplan main = rule { all tfplan.resource_changes as rc { rc.type is "aws_instance" => rc.change.after.instance_type in ["t3.micro", "t3.small"] } }

開発・検証環境において、コストの高いインスタンスタイプ（c5.large など）を使えないよう制限可能です。

④ 作成リソース数の制限（例：EC2は最大5台）

// limit_ec2_count.sentinel import "tfplan/v2" as tfplan main = rule { count = length([r for r in tfplan.resource_changes if r.type is "aws_instance"]) count <= 5 }

このように、動的にリソース数をカウントし制限することも可能です。

⑤ Cost Explorer連携による「コスト上限ルール」（高度な実装）

Terraformでリソースを作成しようとしているときに、現時点のコストが月間上限を超えていたら実行を止める、という複雑なポリシーも、外部データ連携と組み合わせることで実現可能です（Enterprise機能）。

// check_cost_threshold.sentinel import "external" data = external.request("https://example.com/budget-check") main = rule { data.cost &lt;= 10000 }

このように、Sentinelポリシー内で外部システム（API）と連携することで、予算管理・セキュリティ監査システムとの統合も可能になります。

3. Terraform Cloud / Enterprise での実装ステップ

① ポリシーの配置

GitHub などの VCS にポリシーファイル（.sentinel）を配置します。Terraform Cloud はこれを自動的に読み込み、Policy Set として適用します。

② Policy Set の作成

  • TFC 管理画面 → Policy Sets → 新規作成
  • 適用対象の Workspace を選択（全体 or 特定）
  • Enforcement Level（advisory / soft / hard）を設定

③ 実行フローでの反映

Terraform Plan/Apply 実行時に Sentinel の評価結果が表示され、違反時はApplyがブロックされます（hard-mandatory）。

 Run #1234: Apply blocked by Sentinel Policy ✖ EC2インスタンスのタイプが "c5.large" に制限違反 ✖ "Owner" タグが不足しています

4. 実務におけるポリシー設計・運用のコツ

組織内での運用フロー例

  1. IaCチームが Sentinel ポリシーの初期設計
  2. セキュリティ/クラウドガバナンス部門によるレビュー
  3. advisory → soft → hard の3段階で段階適用
  4. CI/CDパイプラインでPolicy Lintを実施

ベストプラクティス

  • 全てのポリシーは Git でバージョン管理
  • あらかじめ「許容例」「違反例」のドキュメントを整備
  • リリース前に“影響分析モード”で組織内PoCを実施

まとめ

Sentinelを活用することで、Terraformによる自動化の恩恵を享受しつつ、企業・組織が求めるルールとガバナンスを強力に実装可能です。

  • 事前に構成ミスやセキュリティリスクを排除できる
  • 社内ポリシーをコード化し、チーム間の合意形成が容易に
  • FinOpsやセキュリティ部門との連携が強化

次章では、OPA（Open Policy Agent）やConftestといったOSSベースのポリシーエンジンとSentinelとの比較・併用について解説していきます。

関連カリキュラム