2026年10月30日

【速報】HCL で記述できる「Terraform Policy」が GA：Sentinel との比較と事前定義ポリシーの活用

# AIOps # Google Cloud # クラウド # セキュリティ

投稿者：種田

Terraform Policy とは？主な特徴と Sentinel との違い
コード比較：GCS の一律アクセス制御の強制
適用方法・運用フローは従来通り
既存 Sentinel / OPA 資産はどうする？「Conversion Agent」による移行支援
事前定義ポリシー（Pre-written Policies）がもたらす最大のメリット
その他の発表トピック（ダイジェスト）
まとめ

皆さま、こんにちは！
このテックブログでは、IT運用に関する内容を連載、「にこぷす通信」をお届けしています。

「NIC x Ops（にこぷす）」とは？

『NIC x Ops（にこぷす）』とは、
私たちの会社であるNTTインテグレーション（NI+C）の運用ノウハウと、
IBMさんの強力なソリューションを
Collaboration（コラボレーション）させた、IT運用高度化シリーズ（Ops）のニックネームなんです。

現代のIT運用の現場は、システムの複雑化や人手不足など、課題が山積みです。そんな現場を少しでも楽に、そしてエンジニアの皆さんが笑顔で「攻めの運用」ができるように支えたい。そんな想いがこの「にこぷす」には込められています。

「にこぷす」には、Instana（可観測性）のほかにも、Turbonomic（リソース最適化）やTerraform（インフラ自動化）など、IT運用を劇的に変える製品がたくさんあります。

これからもこの通信を通して、「IT用語は難しいけれど、中身を知ればこんなに便利で面白いんだ！」というテクニカルな内容をご紹介していきますので、どうぞよろしくお願いします。

0. はじめに

HashiConf at TechXchange 2026 にて、HCP Terraform の新機能 「Terraform Policy（tfpolicy）」の GA（一般提供） が発表されました。

従来の HashiCorp 公式 Policy as Code フレームワークである Sentinel と比較して何が変わり、現場の運用はどう変わるのか、GCS バケットのアクセス制御設定を例としたコード比較を交えて速報でお届けします。

1. Terraform Policy とは？主な特徴と Sentinel との違い

Terraform Policy は、HCP Terraform 上でインフラのガバナンスルールを検査するための新しい宣言型フレームワークです。

HCL ネイティブ
Sentinel 言語や OPA（Rego）のような専用言語を学ぶ必要はなく、普段の Terraform 開発と同じ構文・関数・型システムでポリシーを記述できます。
ライフサイクルの 3 段階評価に対応
- Init 前（Setup 段階）: 未承認の Provider や Module のダウンロード自体を未然に遮断（サプライチェーン保護）。
- Plan 時: 構成変更内容（属性値や設定ミス）の静的検証。
- Apply 後: 自動採番されるリソース ID やエンドポイントなど、プロビジョニング後に確定する値も即時判定。

💡 Init 前の検査がなぜ嬉しいのか？

従来の Sentinel は Plan 後に動くため、terraform init の時点で未承認の外部 Provider（実行バイナリ）や Module がランナー環境にダウンロードされてしまうリスクがありました。

Terraform Policy では Init 前の Setup 段階でソース元を検査できるため、不正な外部プラグインをダウンロードすらさせずに水際で遮断（サプライチェーン保護） できます。

2. コード比較：GCS の一律アクセス制御の強制

セキュリティ要件として一般的な 「すべての GCS バケットで Uniform Bucket-Level Access（一律のバケットレベルのアクセス制御）を有効化する」 ルールを、従来の Sentinel と新しい Terraform Policy で比較します。

従来の Sentinel（2ファイル構成：設定 HCL + 独自言語ロジック）

Sentinel では、強制度（mandatory など）を定義する設定ファイル sentinel.hcl と、判定ロジックを書く *.sentinel ファイルを別々に管理する必要がありました。また、ロジック内では tfplan/v2 の JSON 階層を手続き的に走査・判定する必要がありました。

① 設定ファイル (sentinel.hcl)

📄 sentinel.hcl （クリックで表示）

policy "enforce_gcs_uniform_access" {
  source            = "./policies/enforce_gcs_uniform_access.sentinel"
  enforcement_level = "hard-mandatory" # ここで強制度を指定
}

② ロジック本体 (policies/enforce_gcs_uniform_access.sentinel)

📄 policies/enforce_gcs_uniform_access.sentinel （クリックで表示）

import "tfplan/v2" as tfplan

# 1. 作成・更新される GCS バケットを tfplan のリソース変更リストから抽出
all_gcs_buckets = filter tfplan.resource_changes as _, rc {
  rc.type is "google_storage_bucket" and
  (rc.change.actions contains "create" or rc.change.actions contains "update")
}

# 2. 対象バケットの uniform_bucket_level_access をループ検証
gcs_uniform_access = rule {
  all all_gcs_buckets as _, bucket {
    bucket.change.after.uniform_bucket_level_access is true
  }
}

# 3. エントリーポイント
main = rule {
  gcs_uniform_access
}

新しい Terraform Policy（1ファイル完結：完全な HCL）

Terraform Policy では設定とロジックが統合され、単一の .policy.hcl ファイル内に enforcement_level とルール本体をまとめて宣言できます。Plan JSON の構造を意識する必要もありません。

単一ファイル (policies/enforce_gcs_uniform_access.policy.hcl)

📄 resource_policy.hcl （クリックで表示）

resource_policy "google_storage_bucket" "bucket_uniform_access" {
  enforcement_level = "mandatory" # 設定とロジックを同じファイルに記述可能

  enforce {
    condition     = core::try(attrs.uniform_bucket_level_access, false) == true
    error_message = "Cloud Storage buckets must have uniform_bucket_level_access enabled."
  }
}

主な変更点

設定とロジックが 1 ファイルに集約: sentinel.hcl と *.sentinel の二重管理がなくなり、.policy.hcl 単一でメタデータ・強制度・判定ブロックが完結します。
JSON 階層の知識が不要: rc.change.after.xxxx のような内部データ構造を意識せず、リソースの属性名（resources.uniform_bucket_level_access）を直感的に参照できます。
手続き型ループ構文の排除: filter ... as や all ... as などの専用構文を使わず、宣言的な条件式のみで記述できます。

3. 適用方法・運用フローは従来通り

記述言語やファイル構造は刷新されましたが、HCP Terraform における適用・管理フローは Sentinel と同様の仕組みを継続しています。

Policy Sets の仕組みをそのまま利用
GitHub などの VCS リポジトリに .policy.hcl をコミットし、HCP Terraform の「Policy Sets」として登録します。
適用範囲と強制レベルの管理
組織全体（All Workspaces）または特定 Workspace へのアタッチ、advisory / mandatory（オーバーライド可否）の設定など、従来のガバナンス設計をそのまま維持できます。
CI/CD パイプラインへの影響なし
Pull Request 上の自動チェックや Run 画面でのステータス表示など、開発者が触れる UI 体験は変わらないため、チームのワークフローを変更する必要はありません。

4. 既存 Sentinel / OPA 資産はどうする？「Conversion Agent」による移行支援

すでに Sentinel や OPA で多くのポリシーを運用しているチーム向けに、公式の移行支援ツールが提供されています。

Conversion Agent（変換エージェント） 既存の Sentinel や OPA（Rego）で書かれたポリシーライブラリ全体を、Terraform Policy（.policy.hcl）へ自動変換してくれます。
テストケース（.policytest.hcl）も自動生成 ロジックを機械的に書き換えるだけでなく、変換後のポリシーが正しく動作するかをローカルで検証できる単体テスト用ファイルもセットで作成されます。
AI コーディングエージェント対応（tfpolicy agent skill） Claude Code などのエージェントツール向けにスキルが提供されており、手元で対話しながら一括変換とテスト実行を行える環境が整っています。ゼロから手作業で書き直す必要はありません。

5. 事前定義ポリシー（Pre-written Policies）がもたらす最大のメリット

今回のアップデートで実務上最もインパクトが大きいのではと感じたのが、HashiCorp 公式が提供する事前定義ポリシーカタログ 「Pre-written Policies」 です。

業界標準ベンチマークの網羅
CIS GCP Foundations Benchmark などの主要なセキュリティ標準に準拠したポリシーセットがパッケージ化されています。（2026年10月29日時点で、対象はAWS/Azure/Google Cloud のみ）
運用の推奨パターン
- GCS のパブリック公開禁止やデフォルト暗号化、Compute Engine の外部 IP 制限といった汎用的なセキュリティガードレールは、カタログから Policy Set を選択して適用するだけで運用を開始できます。
- 自前で HCL ポリシーを記述するのは、「社内独自の命名規則」や「特定ラベル・タグの必須化」といった組織特有のルールに絞り込むことができます。

なぜ自作せず事前定義ポリシーを使うべきなのか？

たとえば「Cloud Storage のパブリック公開を禁止する」というルールを1つ適用したい場合、自前で書こうとすると以下のような膨大なリソースの組み合わせを考慮する必要があります。

google_storage_bucket_iam_member（allUsers / allAuthenticatedUsers の付与）
google_storage_bucket_iam_binding（複数メンバー内の公開プリンシパル）
google_storage_bucket_iam_policy（生 JSON ポリシー内のロールバインド）
google_storage_bucket_acl / access_control（レガシー ACL 設定）
google_storage_default_object_acl（新規オブジェクトへの公開 ACL 継承）
google_storage_managed_folder_iam_*（マネージドフォルダ経由の公開設定）

自前ですべての実装漏れをなくすのは極めて困難ですが、公式の Pre-written Policies（CIS GCP Foundations Benchmark 対応）では、これら 11 種類以上の関連リソース・設定パターンを網羅したポリシーが最初からワンパッケージで提供されています。

📄 pre_written_policy.hcl （クリックで表示）

# 公式 Pre-written policy の実装イメージ（抜粋）
locals {
  storage_public_principals = ["allUsers", "allAuthenticatedUsers"]
}

# IAM Member の検査
resource_policy "google_storage_bucket_iam_member" "bucket_iam_member_not_public" {
  enforcement_level = input.storage-bucket-no-public-access-enforcement-level
  enforce {
    condition     = !core::contains(local.storage_public_principals, core::try(attrs.member, ""))
    error_message = "Cloud Storage bucket IAM members must not be allUsers or allAuthenticatedUsers."
  }
}

# IAM Binding の検査（リスト走査）
resource_policy "google_storage_bucket_iam_binding" "bucket_iam_binding_not_public" {
  locals {
    members        = core::try(attrs.members, [])
    public_members = [for m in local.members : m if core::contains(local.storage_public_principals, m)]
  }
  enforcement_level = input.storage-bucket-no-public-access-enforcement-level
  enforce {
    condition     = core::length(local.public_members) == 0
    error_message = "Cloud Storage bucket IAM bindings must not include allUsers or allAuthenticatedUsers."
  }
}
# ... その他 ACL や Managed Folder 用のポリシーが続く

推奨される運用スタイル

ベースライン: 業界標準のセキュリティガードレール（公開禁止、暗号化強制、パブリック IP 制限など）は Pre-written policies を数クリックでアタッチして済ませる。
自作ポリシー: 「社内独自の命名規則」や「必須タグ・ラベルのチェック」など、自社固有のルールだけを Terraform Policy で追加記述する。

この役割分担により、ポリシーのメンテナンス負荷を劇的に抑えられます。

6. その他の発表トピック（ダイジェスト）

Terraform Policy のほかにも以下の機能が Public Preview として発表されました。

Remote Terraform MCP Server（Public Preview）
Claude などの AI コーディングエージェントから HCP Terraform を安全に操作するための MCP（Model Context Protocol）サーバー。ローカル環境のツールセットアップ不要でエージェント連携が可能になります。
Terraform Developer Portal（Public Preview）
社内の承認済みモジュールをセルフサービスでカタログ化し、開発者や AI が安全にインフラをプロビジョニングできるようにするポータル基盤です。

まとめ

Terraform Policy により、Policy as Code の記述が HCL に統合され、設定ファイルとロジックの二重管理も解消されました。チーム内でのポリシー作成やコードレビューのハードルは大幅に下がっています。

運用フロー自体は従来の Policy Sets と変わらないため、まずはテスト用 Workspace に Pre-written policies（CIS GCP Benchmark 等）を割り当て、既存コードの適合度をチェックしてみるのが実務導入の第一歩として適しています。

「にこぷす通信」について

「NIC × Ops（にこぷす）通信」は、隔週で皆さまに情報をお届けします。
このシリーズでは、Instana（可観測性）をはじめ、Turbonomic（リソース最適化）やTerraform（インフラ自動化）など、IT運用を劇的に変える製品をピックアップしていきます。
これからも最新の技術検証をチームで継続し、皆さまの現場ですぐに役立つ「有益な知見」を全力で共有していきます。次回の連載もお楽しみに！