↓メインコンテンツへスキップ
  1. Blogs/

HCP Terraform Sentinel Policyを始める前に知っておきたいこと

· loading · loading · ·
HCP Terraform Sentinel GCP ガバナンス Policy as Code
Nimbus Craftsman
著者
Nimbus Craftsman
目次

はじめに 👋
#

こんにちは、ニンバスです！

現在、私は大規模なHCP Terraform環境の管理者として、組織全体で100以上のworkspaceを運用しています。

特徴的なのは、複数の開発チーム（インフラ開発者）が同じHCP Terraform環境を共同利用しているという点です。それぞれのチームが独立してインフラを構築しつつ、組織全体のセキュリティやコスト要件を守る必要があります。

こうした環境では、人によるレビューだけでガバナンス（統制）を効かせることには限界があります。そこで注目したのがPolicy as Codeという考え方、そしてHCP Terraformが提供するSentinel Policyです。

この記事では「Sentinelに興味を持ち始めた方」に向けて、導入前に知っておくべきことを実体験から共有します。それでは、Let’s Dive in! 🦄

この記事は実際の企業でのSentinel Policy導入プロジェクトを基にしていますが、社名や機密情報は伏せています。

なぜSentinelが必要だったのか 🎯
#

複数チーム環境特有の課題
#

私たちの組織では、HCP Terraformで100以上のworkspaceを管理しています。複数の開発チームが利用する環境では、いくつかの課題が顕在化しました。

各チームは独自にPull Requestのレビューを行い、インフラ変更を進めています。私たちの管理チームにレビュー依頼が来ることはありません。つまり、各チーム内でレビューが完結する仕組みです。

しかし、この仕組みには問題がありました。チームごとにレビュアーの知識や経験が異なるため、チェックの品質にばらつきが生じていたのです。あるチームでは厳格にセキュリティチェックが行われる一方で、別のチームでは見落としが発生してしまう。特に問題だったのは、ネットワークやアクセス制御に関する設定ミスです。意図せず広範囲へのアクセスを許可してしまうケースが何度かありました。

さらに、「後で修正する」と言いつつ放置される問題も頻発していました。各チームのセキュリティ意識や知識レベルにばらつきがあり、「こういう設定にすべき」というルールが暗黙知化している状況でした。

「このままではセキュリティインシデントが起きる」という危機感が、私たちをPolicy as Codeの導入へと駆り立てました。

Policy as Codeという解決策
#

Policy as Codeとは、セキュリティやインフラのポリシー（ルール）をコードで表現し、自動的にチェック・強制する仕組みです。

従来の方法では、ドキュメントでルールを定義し、人がレビューでチェックしていました。しかし、これでは見落としが発生し、ルール遵守が難しいという問題がありました。

Policy as Codeでは、ルールをコードで定義することで、機械が自動的にチェックします。つまり「ルールに違反しているコードは、そもそもApplyさせない」という強制力を持たせることができるのです。

HCP Terraformが提供するSentinel機能を使えば、複数チームに対して一律のルールを自動適用できます。各チームのレビュー品質のばらつきを気にする必要がなくなります。

Sentinelとは？ 📘
#

Policy as Codeの概念
#

Policy as Codeには、いくつかの大きなメリットがあります。まず、人によるレビューに頼らず機械的にチェックできるため、完全な自動化が可能です。また、誰が実行しても同じ基準でチェックされるため、一貫性が保たれます。さらに、ポリシーがコードで可視化されるため透明性が高く、Gitで変更履歴を追跡できるためバージョン管理も容易です。

SentinelとOPAの比較
#

HCP Terraformでは、ポリシー言語としてSentinelとOPA（Open Policy Agent）の2つがサポートされています。

項目SentinelOPA
開発元HashiCorpCNCF
適用レベル3段階2段階
学習のしやすさ比較的簡単やや難しい

なぜSentinelを選んだのか
#

私たちはSentinelを選択しました。決め手は3段階の適用レベルです。

Advisoryは「推奨」レベルで、違反してもWarning（警告）のみが表示され、Applyは可能です。Soft Mandatoryは「承認があれば可」というレベルで、違反するとApplyが止まりますが、管理者が承認すればApply可能です。Hard Mandatoryは「例外なく必須」というレベルで、違反すると完全にApplyが止まり、承認も不可能です。

この柔軟性により、複数チーム環境での段階的な導入が可能になります。いきなり厳しいルールを強制するのではなく、まずは警告から始めて徐々に強化していくことができるのです。

Policy enforcement levels - HCP Terraform公式ドキュメント

Policy Setsによる環境別ガバナンス設計 🏗️
#

Policy Setsとは
#

HCP Terraformでは、複数のSentinelポリシーをPolicy Setsとしてグループ化し、Workspace単位で適用できます。

しかし、「どう設計すべきか」のベストプラクティスはまだ確立されていません。 導入事例が少なく、試行錯誤しながら最適解を探る必要がありました。

複数チーム環境での設計課題
#

複数の開発チームが利用する環境では、環境ごとに求められるガバナンスレベルが異なります：

  • 本番環境: 厳格なセキュリティチェックが必須（ビジネスインパクト大）
  • ステージング環境: 本番に準じるチェック（検証環境として）
  • 開発環境: 開発速度を重視、チェックは緩めに
  • Policy開発環境: ポリシー自体をテストする環境

すべての環境に同じポリシーを適用すると…

  • 本番環境：セキュリティが不十分なリスク
  • 開発環境：厳しすぎて開発が止まる

→ 環境別にPolicy Setsを分ける必要がある

私たちが辿り着いたPolicy Sets設計
#

試行錯誤の結果、以下の3つのPolicy Setsに落ち着きました：

1. Production Policy Set（本番・ステージング環境用）
#

適用ポリシー：
- VPC Firewall Rule → Hard Mandatory（例外なく必須）
- Cloud Run冗長性チェック → Soft Mandatory（承認があれば可）

適用先Workspace：
- *-prod（本番環境）
- *-stg（ステージング環境）

設計のポイント：

  • クリティカルなセキュリティはHard Mandatory（例外なし）
  • ビジネス要件に応じて調整が必要なものはSoft Mandatory

2. Development Policy Set（開発環境用）
#

適用ポリシー：
- VPC Firewall Rule → Advisory（警告のみ）
- Cloud Run冗長性チェック → Advisory（警告のみ）

適用先Workspace：
- *-dev（開発環境）

設計のポイント：

  • すべてAdvisory（警告のみ、Applyは可能）
  • 開発チームの開発速度を損なわない
  • 違反を可視化し、意識向上を促す

3. Policy Development Set（ポリシー開発環境用）
#

適用ポリシー：
- テスト用の検証ポリシー

適用先Workspace：
- sentinel-mock-generator など

設計のポイント：

  • ポリシー自体をテストするための環境
  • 本番適用前の動作確認

Policy Sets設計のベストプラクティス（学んだこと）
#

試行錯誤を通じて学んだ、Policy Sets設計のポイントをシェアします：

1. タグベースでWorkspaceを識別する
#

Workspace命名規則だけに頼るのではなく、タグを活用することで、より柔軟で管理しやすい設計になります。

私たちの実装例：

Workspaceにタグを設定：
- env:prod（本番環境）
- env:stg（ステージング環境）
- env:dev（開発環境）

Policy Setsのスコープ設定：

  • Production Policy Set → env:prod、env:stgタグを持つWorkspaceに適用
  • Development Policy Set → env:devタグを持つWorkspaceに適用

タグベースのメリット：

タグを使うことで、Workspace名の命名規則に依存しない柔軟な設計が可能になります。例えば、myapp-network-prodでもlegacy-system-productionでも、env:prodタグさえ付いていれば同じPolicy Setが適用されます。

また、ProjectやWorkspaceが増えても、タグを設定するだけで自動的にPolicy Setのスコープに含まれます。手動でWorkspaceを一つ一つ追加する必要がありません。

さらに重要なのは、Policy SetsのスコープをTerraformで管理しているという点です。特定のタグを持つWorkspaceを一括で取得し、対象のWorkspaceを自動でスコープに追加することができます。つまり、Workspaceが100個から200個に増えても、コードを変更する必要がないのです。

Terraformでの実装イメージ：

# 特定のタグを持つWorkspaceを取得
data "tfe_workspace_ids" "prod_workspaces" {
  tag_names    = ["env:prod"]
  organization = var.organization_name
}

# Policy Setにスコープを設定
resource "tfe_policy_set" "production" {
  name         = "production-policy-set"
  organization = var.organization_name
  
  # タグで取得したWorkspaceを自動で適用
  workspace_ids = data.tfe_workspace_ids.prod_workspaces.ids
  
  # ポリシーファイルをVCSから取得
  vcs_repo {
    identifier = "your-org/hcp-terraform-policies"
    branch     = "main"
  }
}

この設計により、インフラのスケールに対応できる仕組みが実現できました。

2. ポリシーは共通、適用レベルだけを変える
#

最初は「本番用ポリシー」「開発用ポリシー」を別々に作ろうとしましたが、メンテナンスが二重になる問題に気づきました。

ベストプラクティス：

  • ポリシーコード自体は同じものを使う
  • Policy Setsごとに適用レベル（Hard/Soft/Advisory）だけを変える

例：

VPC Firewall Ruleポリシー（コードは共通）
→ Production Policy Set：Hard Mandatory
→ Development Policy Set：Advisory

3. 段階的な移行パスを設計する
#

新しいポリシーを追加する際の推奨フロー：

STEP 1: Development Policy SetにAdvisoryで追加
        ↓（開発チームからフィードバック収集）
STEP 2: ポリシーを調整・改善
        ↓（問題なければ）
STEP 3: Production Policy SetにAdvisoryで追加
        ↓（本番環境で様子見）
STEP 4: Soft Mandatory → Hard Mandatoryへ段階的に強化

→ いきなり本番環境でHard Mandatoryにしない

4. Policy SetsをTerraformで管理する
#

Policy Sets自体もInfrastructure as Codeとして管理します。私たちはHCP TerraformのPolicy SetsをTerraformで定義・管理しています。

具体的には、ポリシーコードをGitHubで管理し、HCP TerraformとVCS連携します。Policy Setのリソース定義（どのWorkspaceに適用するか、どのポリシーファイルを使うかなど）もTerraformコードで記述します。

この方法のメリットは非常に大きいです。まず、Policy Setの変更をPull Requestでレビューできるため、チーム全体で変更内容を確認できます。変更履歴もGitで追跡可能なため、「誰が、いつ、なぜ変更したか」が明確です。

さらに、前述のタグベースのスコープ設定と組み合わせることで、ProjectやWorkspaceが増えてもPolicy Setのコードを変更する必要がありません。新しいWorkspaceに適切なタグ（例：env:prod）を設定するだけで、自動的に対象のPolicy Setが適用されます。

ロールバック（元に戻す）も容易です。Terraformの状態管理により、以前のバージョンに戻すことができます。

5. HCP Terraform利用者への周知を忘れない
#

Policy Setsを更新したら、必ず開発チーム（HCP Terraform利用者）に周知します：

  • 何が変わったか
  • なぜ変更したか
  • いつから適用されるか

特に重要：

  • AdvisoryからSoft/Hard Mandatoryに変更する際は事前告知
  • 開発チームが対応する時間を確保

Policy Sets導入で期待できる効果
#

環境別Policy Sets設計により、以下の効果が期待できます：

✅ 本番環境のセキュリティ向上

クリティカルなルール違反を自動でブロックできるため、各チームのレビュー品質のばらつきに関わらず、組織全体で統一されたセキュリティ基準を維持できます。

✅ 開発環境の柔軟性維持

Advisoryにより、開発チームの開発速度を損なうことなく、違反を可視化して意識向上を促すことができます。警告は出るが作業は止まらない、というバランスが重要です。

✅ 段階的なガバナンス強化

開発環境でAdvisoryとして試してから本番環境へ展開し、徐々にSoft Mandatory、Hard Mandatoryへと強化していく道筋が描けます。開発チームの混乱を最小限に抑えながら、組織全体のガバナンスを強化できます。

Managing Policy Sets - HCP Terraform公式ドキュメント

Sentinel導入の最初の壁 😰
#

「何をポリシー化すべきか」が定まらない
#

Sentinelポリシー開発を始めようと意気込んだものの、肝心の**「何をチェックすべきか」が定まらない**という問題に直面しました。

背景：

  • 組織内にCCoE（Cloud Center of Excellence）チームが存在
  • CCoEチームと「クラウド利用ルール」をすり合わせる必要があった
  • しかし、CCoEチームも発足したばかりで稼働が取れない状況

試行錯誤のプロセス：

  1. こちらから草案を提示 - 待っていても進まないため、私たちから草案を提示
  2. 「ああだ、こうだ」の繰り返し - CCoEチームとのMTGで議論するも決着せず
  3. 先行実装の決断 - 「ポリシー化できそうなもの」から先行着手

気づき：小さく始めることの重要性

  • すべてを決める必要はない
  • ビジネス要件が明確なものから着手
  • フィードバックを得ながら改善

最初のポリシー選定のポイント 🔑
#

どのポリシーから始めるべきか
#

「何をポリシー化すべきか」が定まらない中で、私たちはビジネス要件が明確なものから着手することにしました。

最初のポリシーとして選んだのは、セキュリティ要件が高い環境でのネットワーク制御に関するルールでした。なぜこれを選んだのか、いくつか理由があります。

まず、セキュリティ要件が明確だったことです。「外部への通信を制御する」という要件は、ビジネス上の必要性がはっきりしており、CCoEチームとも合意が取りやすいテーマでした。

次に、チーム間で共通のニーズがあったことです。複数の開発チームがセキュリティ要件の高い環境を扱っており、全員に関係するルールでした。

そして、ビジネスインパクトが大きかったことです。設定ミスによるデータ流出や不正なアクセスは、組織にとって重大なインシデントにつながります。「後で直す」では済まされない領域でした。

Advisory適用レベルを選んだ理由
#

最初のポリシーには、Advisory（推奨）適用レベルを選択しました。これは戦略的な判断です。

まず、認知フェーズを重視しました。いきなり厳しいルールを強制するのではなく、「Policy as Codeを実践している」ことを開発チームに知ってもらうことが先決でした。開発チームの混乱を避け、スムーズに受け入れてもらうことを優先したのです。

次に、フィードバック収集を目的としました。実運用でポリシーの妥当性を検証する必要がありました。「このチェックは厳しすぎる」「この条件だと開発が進まない」といった意見を吸い上げ、ポリシーを改善したかったのです。

そして、段階的な強化計画を見据えていました。Advisory → Soft Mandatory → Hard Mandatoryと段階的に強化する道筋を描いていました。いきなりHard Mandatoryで強制すると、開発が止まるリスクがあります。

現在の状況

現在、すべてのポリシーをAdvisory適用レベルで運用しています。これは組織への「認知フェーズ」と位置づけているためです。開発チームの理解が深まった段階で、クリティカルなセキュリティ要件からSoft Mandatory、Hard Mandatoryへと段階的に強化していく計画です。

導入で期待できる効果 📊
#

現在、私たちは導入フェーズにありますが、Sentinel Policyの導入により以下のような効果が期待できます。

効果1：自動チェックの威力
#

Pull Requestに自動でチェック結果がコメントされることで、開発チーム自身が違反に気づけるようになります。これにより、各チームのレビュアーの負担が軽減され、レビュー品質のばらつきも解消されることが期待できます。

効果2：開発チームの意識変化
#

ポリシー違反が可視化されることで、「後で直す」という先送りが減り、セキュリティへの意識が向上すると考えています。チーム間で統一された基準が明示されるため、暗黙知だったルールが明文化されます。

効果3：継続的な改善サイクル
#

ビジネス要件は変化します。ポリシー自体もコードとして管理することで、開発チームからのフィードバックを反映しながら継続的に改善できます。TerraformでPolicy Setsを管理しているため、変更も容易です。

Sentinel導入を検討している方へ 🚀
#

始める前に準備すべきこと
#

  1. ステークホルダー（関係者）との合意形成

    • なぜPolicy as Codeが必要か
    • どんなルールをポリシー化すべきか

  2. 小さく始める計画

    • すべてを一度に実装しない
    • ビジネス要件が明確なものから

  3. 段階的導入戦略

    • 最初はAdvisory適用レベル
    • フィードバックを得ながら強化

特に複数チーム環境では
#

  • 認知フェーズを大切に

    • いきなり強制しない
    • 「なぜこのチェックが必要か」を丁寧に説明

  • フィードバックループを回す

    • 現場の声を聞く
    • ポリシーを柔軟に調整

  • チーム全員が理解者になる必要はない

    • まずは1-2名が理解すればOK
    • 徐々に広げる

まとめ 🎉
#

Sentinel導入で学んだこと
#

  1. 完璧を求めない - 小さく始めて段階的に
  2. Advisory戦略 - 強制ではなく啓蒙から
  3. 関係者との対話 - ルール策定は一人では決められない
  4. 継続的な改善 - ポリシーは一度作って終わりではない

複数チーム環境での価値
#

Policy as Codeは、複数チームが協働する環境でこそ真価を発揮します。

次のステップ
#

もしあなたがSentinelに興味を持ったなら

  1. HashiCorp公式ドキュメントを読む
  2. 小さなポリシーを1つ作ってみる
  3. Advisory適用レベルで試してみる

この記事が参考になったら、是非SNSでシェアしてください！Sentinel Policyにより、皆さんの組織のガバナンス強化が実現することを願っています ✨