HCP Terraformのチーム・権限管理で失敗しないために

はじめに 👋
#

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

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

HCP Terraformを使い始めたとき、多くの方が最初に直面するのが「チーム・権限管理をどうするか」という問題です。最初は数人、数個のワークスペースだったものが、気づけば数十人、数百のワークスペースに成長していきます。

そのとき、チーム・権限の設計を適当にやっていると、確実にカオスになります。

この記事では、カオスな状態から脱却した私たちの経験をもとに、これからHCP Terraformを本格導入する方が最初から正しく設計するためのベストプラクティスを共有します。それでは、Let’s Dive in! 🦄

この記事は実際の企業でのHCP Terraform運用経験を基にしていますが、社名や機密情報は伏せています。

なぜチーム・権限管理でカオスになるのか 🎯
#

私が見たカオスな現場
#

私が組織に参加する前の状態は、まさにカオスでした：

「誰が、どんな権限を持っているのか」が誰も把握していない
強い権限を持ったメンバーが好き勝手にワークスペースを作成・変更
退職者のアカウントが削除されず残ったまま
本番環境に開発者が直接アクセスできる状態
チーム名が統一されていない（developers, team-a, prod-usersなど）

すべて手動で管理されており、変更履歴もなく、Organization Ownerが10名以上という状態でした。

放置すると起きる4つの問題
#

1. セキュリティリスク

本番環境への不適切なアクセス、必要以上の権限を持つユーザーの存在、退職者アカウントの削除漏れなど、セキュリティ上の重大なリスクが生まれます。

2. 運用負荷の増大

「このワークスペースにアクセスしたい」という依頼が日常的に発生し、都度手動で権限を付与・調整する必要があります。誰がどこにアクセスできるか調べるだけで時間がかかります。

3. 監査対応の困難さ

「誰が、いつ、何にアクセスしたか」が追跡できず、コンプライアンス監査で苦労します。

4. チーム間の混乱

「なぜこのワークスペースにアクセスできないのか」「間違って本番環境を変更してしまった」といったトラブルが頻発します。

「最初から正しく設計する」ことの価値
#

後から修正するのは大変です。100以上のワークスペース、数十人のユーザーがいる状態での権限整理は、想像以上に労力がかかります。

最初からきちんと設計しておけば：

セキュリティリスクを最小化できる
運用負荷が劇的に下がる
チームが安心して開発できる
スケールしても破綻しない

成功するチーム設計の4つの原則 🏗️
#

私たちが試行錯誤の末に辿り着いた設計原則を紹介します。

原則1：ロールベースでチームを分ける
#

環境（本番/ステージング/開発）と役割（管理者/開発者/閲覧者）の組み合わせでチームを構成します。

なぜこの原則が重要か：

環境ごとに求められるセキュリティレベルが異なる
役割ごとに必要な権限が異なる
この2軸で分けることで、権限の過不足が発生しにくい

原則2：最小権限の原則を守る
#

必要最小限の権限のみを付与し、過剰な権限は与えません。

具体例：

開発者は開発環境でPlan/Apply可能だが、本番環境は閲覧のみ
本番環境の管理者でも、Organization全体の設定は変更不可
閲覧者はPlan結果を見られるが、Apply実行は不可

原則3：チームベースで管理する
#

個人に直接権限を付与せず、すべてチーム経由で管理します。

メリット：

新メンバー追加時、該当チームに追加するだけ
権限の棚卸しがチーム単位で可能
「このチームに所属している人は〇〇ができる」が明確

原則4：命名規則を統一する
#

チーム名から「何ができるか」が一目で分かるようにします。

推奨命名規則：

{システム名}-{レイヤー}-{環境名}-{役割}

具体例：

systemA-network-prod-admin - System Aのネットワーク本番環境管理者
systemA-security-stg-developer - System Aのセキュリティステージング環境開発者
systemA-app-dev-developer - System Aのアプリケーション開発環境開発者
systemA-db-prod-viewer - System Aのデータベース本番環境閲覧者
platform-infra-admin - プラットフォーム基盤管理者

この命名規則により、チーム名を見ただけで「どのシステムの、どのレイヤーの、どの環境で、何ができるか」が理解できます。

レイヤーとは： 同じシステムでも、インフラチーム、セキュリティチーム、アプリケーションチーム、データベースチームなど、担当領域（レイヤー）が異なります。各チームは自分の担当するWorkspaceのみにアクセスできるよう、レイヤーごとにチームを分けます。

実際の設計例
#

環境別 × レイヤー別 × 役割別のチーム構成
#

【本番環境チーム】
├─ systemA-network-prod-admin（ネットワーク本番環境管理者）
│   ✓ systemA-network-prod Workspaceの管理権限
│   ✓ Plan & Apply実行権限
│
├─ systemA-security-prod-admin（セキュリティ本番環境管理者）
│   ✓ systemA-security-prod Workspaceの管理権限
│   ✓ Plan & Apply実行権限
│
├─ systemA-app-prod-admin（アプリケーション本番環境管理者）
│   ✓ systemA-app-prod Workspaceの管理権限
│   ✓ Plan & Apply実行権限
│
└─ systemA-db-prod-viewer（データベース本番環境閲覧者）
    ✓ systemA-db-prod Workspaceの閲覧のみ
    ✗ Apply実行不可

【ステージング環境チーム】
├─ systemA-network-stg-developer（ネットワークステージング開発者）
│   ✓ systemA-network-stg Workspaceで開発
│
└─ systemA-app-stg-developer（アプリケーションステージング開発者）
    ✓ systemA-app-stg Workspaceで開発

【開発環境チーム】
├─ systemA-network-dev-developer（ネットワーク開発環境開発者）
│   ✓ systemA-network-dev Workspaceで開発
│   ✓ Workspace作成権限（開発環境のみ）
│
└─ systemA-app-dev-developer（アプリケーション開発環境開発者）
    ✓ systemA-app-dev Workspaceで開発
    ✓ Workspace作成権限（開発環境のみ）

【プラットフォーム管理チーム】
└─ platform-infra-admin（HCP Terraform管理者）
    ✓ Organization全体の管理
    ✓ Team・User管理
    ✓ Policy Sets管理

レイヤー別にチームを分けるメリット：

同じSystem Aを担当していても、インフラチーム（network）、セキュリティチーム（security）、アプリケーションチーム（app）、データベースチーム（db）では、担当するWorkspaceが異なります。

レイヤー別にチームを分けることで：

インフラチームはsystemA-network-* Workspaceのみアクセス
アプリチームはsystemA-app-* Workspaceのみアクセス
セキュリティチームはsystemA-security-* Workspaceのみアクセス

このように責任の境界線が明確になり、誤って他チームのWorkspaceを変更するリスクがなくなります。

権限マトリックス
#

実際の権限設計を表にまとめると以下のようになります：

チーム	Organization	Project	Workspace	備考
platform-infra-admin	Manage Settings	Admin	Admin	Platform管理者のみ（2-3名）
systemA-network-prod-admin	-	Write	Write	ネットワーク本番環境管理者
systemA-security-prod-admin	-	Write	Write	セキュリティ本番環境管理者
systemA-app-prod-viewer	-	Read	Read	アプリケーション本番環境閲覧者
systemA-network-stg-developer	-	Write	Write	ネットワークステージング開発者
systemA-app-dev-developer	-	Write	Write	アプリケーション開発環境開発者

このマトリックスをドキュメント化しておくことで、新メンバーのオンボーディングや監査対応がスムーズになります。

Project × Workspace × Team のマッピング
#

実際の構成例：

Organization
├─ Project: system-A-prod
│   ├─ Workspace: systemA-network-prod
│   │   ↑
│   │   └─ Team: systemA-network-prod-admin (Write)
│   │
│   ├─ Workspace: systemA-security-prod
│   │   ↑
│   │   └─ Team: systemA-security-prod-admin (Write)
│   │
│   ├─ Workspace: systemA-db-prod
│   │   ↑
│   │   └─ Team: systemA-db-prod-viewer (Read)
│   │
│   └─ Workspace: systemA-app-prod
│       ↑
│       └─ Team: systemA-app-prod-admin (Write)
│
├─ Project: system-A-stg
│   ├─ Workspace: systemA-network-stg
│   │   ↑
│   │   └─ Team: systemA-network-stg-developer (Write)
│   │
│   └─ Workspace: systemA-app-stg
│       ↑
│       └─ Team: systemA-app-stg-developer (Write)
│
└─ Project: system-A-dev
    ├─ Workspace: systemA-network-dev
    │   ↑
    │   └─ Team: systemA-network-dev-developer (Write)
    │
    └─ Workspace: systemA-app-dev
        ↑
        └─ Team: systemA-app-dev-developer (Write)

この構成のメリット：

環境ごとにProjectを分けることで、Project-level権限で環境全体を制御できます。

さらに、レイヤー（network, security, db, app）ごとにチームを分けることで、各チームは自分の担当Workspaceのみにアクセスできます。例えば：

インフラチーム（network）はsystemA-network-* Workspaceのみ
アプリチーム（app）はsystemA-app-* Workspaceのみ

これにより、誤って他チームのWorkspaceを変更するリスクがなくなり、責任の境界線が明確になります。

Terraformでチーム管理を「コード化」する 🔧
#

なぜTerraformで管理すべきか
#

手動でチーム・権限を管理していると、変更履歴が残らず、誰が何を変更したか分かりません。レビュープロセスもなく、設定ミスに気づきにくい状態です。

TerraformでTeam管理を行う4つのメリット：

✅ 変更履歴の完全な追跡 - すべての変更がGitで履歴管理される
✅ レビュープロセスの導入 - Pull Requestでレビューを経てから反映
✅ 宣言的な管理 - 「あるべき姿」をコードで定義
✅ テンプレート化・自動化 - 新しいシステム追加時に再利用可能

実装例
#

基本的なパターンは以下の通りです：

# チーム定義
resource "tfe_team" "network_prod_admin" {
  name         = "systemA-network-prod-admin"
  organization = var.organization_name
  
  organization_access {
    manage_policies      = false
    manage_workspaces    = false
    manage_vcs_settings  = false
  }
}

# プロジェクトレベルの権限付与
resource "tfe_team_project_access" "network_prod_admin_access" {
  team_id    = tfe_team.network_prod_admin.id
  project_id = tfe_project.system_a_prod.id  # system-A-prod Project
  access     = "write"
}

# ワークスペースレベルの権限付与
resource "tfe_team_access" "network_prod_admin_workspace" {
  team_id      = tfe_team.network_prod_admin.id
  workspace_id = tfe_workspace.systemA_network_prod.id
  
  permissions {
    runs              = "apply"
    variables         = "write"
    state_versions    = "write"
    workspace_locking = true
  }
}

このパターンを応用すれば、どんな規模のチーム・権限管理もコード化できます。

詳しい実装方法は、HashiCorp公式ドキュメントのTerraform Provider - tfe_teamを参照してください。

運用を成功させる3つの実践 🌟
#

設計と実装ができたら、次は運用です。長期的に安定した運用を続けるための3つの実践を紹介します。

1. SSO連携で入退社を自動化
#

私たちはEntra ID（旧Azure AD）とSSO連携しています。

メリット：

組織のIDプロバイダーと一元管理
入社時：自動的にHCP Terraformのチームに同期
退社時：HCP Terraformへのアクセスも自動で無効化
多要素認証（MFA）の強制が可能

IDプロバイダー側でのグループとHCP TerraformのTeamをマッピングすることで、権限管理の自動化が実現します。

環境分離が必要な場合：

セキュリティ要件が厳しい組織では、1人のユーザーが複数環境に簡単にアクセスできることを好まない場合があります。このような場合、環境ごとにアカウントを分離する選択肢もあります。

例：

user-prod@example.com → 本番環境のみ
user-stg@example.com → ステージング環境のみ
user-dev@example.com → 開発環境のみ

この方法では、本番環境にアクセスするには本番用アカウントでログインする必要があるため、「うっかり本番を触ってしまう」リスクを物理的に排除できます。アカウント管理は煩雑になりますが、金融・医療など本番環境への変更がクリティカルな組織では有効なアプローチです。

2. Organization Ownerは2-3名に限定
#

Organization Ownerは組織の削除、課金情報の変更、SSO設定の変更など、最も強い権限を持ちます。

推奨：

Organization Ownerは2-3名のみに限定
それ以外の管理者は、Teamベースで必要な権限のみ付与
定期的に見直し、本当に必要な人だけに絞る

3. 四半期ごとの権限棚卸し
#

権限は時間とともに「腐敗」します。定期的な見直しが重要です。

四半期ごとに確認すべきこと：

退職者・異動者のアカウント削除、各チームのメンバーが適切か確認、不要なチームの統廃合、過剰な権限を持つユーザーがいないか確認、Organization Ownerの数が適切かの確認を行います。

Terraform管理のメリット： Gitの履歴を見れば、誰がいつ追加されたかすぐに分かります。

# 特定のチームの変更履歴を確認
git log -p -- teams.tf | grep "prod-admin"

これから始めるあなたへ 🚀
#

最初の一歩
#

HCP Terraformを本格導入する際、以下のステップで進めることをお勧めします：

STEP 1: 設計原則を決める（1-2日）

環境の区分（prod/stg/dev）、レイヤーの区分（network/security/app/db）、役割の区分（admin/developer/viewer）を決め、命名規則を統一します。SSO連携の有無も検討してください。

STEP 2: 小さく始める（1週間）

まずは1つのシステム・プロジェクトから始めます。Terraformでチーム管理の基本パターンを実装し、ドキュメント（チーム構成図、権限マトリックス）を作成します。

STEP 3: 段階的に拡大（2-4週間）

他のシステムにも展開し、Terraformコードをテンプレート化します。SSO連携を有効化し、定期的な棚卸しルールを決めます。

特に大規模環境で気をつけること
#

100+ Workspaces、複数チームでの運用では、以下が特に重要です：

自動化は必須
手動では追いつかなくなります。Terraformでの管理を最初から導入してください。

命名規則の徹底
統一された命名規則がないと、カオスになります。最初に決めて、徹底的に守りましょう。

定期的な見直しの習慣化
四半期ごとの棚卸しを、カレンダーに入れて確実に実施してください。

段階的な権限昇格
開発者は開発環境から始め、必要に応じて段階的にステージング・本番環境へアクセスできるようにします。

まとめ 💡
#

HCP Terraformのチーム・権限管理で押さえるべき4つのポイント：

1. チームベースで管理 - 個人に直接権限を付与せず、すべてチーム経由で
2. 最小権限の原則 - 必要最小限の権限のみを付与
3. Terraformで管理 - 変更履歴、レビュープロセスのメリットを享受
4. 定期的な見直し - 四半期ごとの権限棚卸しを習慣化

チーム・権限設計は、HCP Terraform運用の基盤です。最初は面倒に感じるかもしれませんが、きちんと設計しておくことで、長期的な運用が格段に楽になります。

この記事が、これからHCP Terraformを本格導入する方の参考になれば幸いです！

参考リンク：

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

はじめに 👋#

なぜチーム・権限管理でカオスになるのか 🎯#

私が見たカオスな現場#

放置すると起きる4つの問題#

「最初から正しく設計する」ことの価値#

成功するチーム設計の4つの原則 🏗️#

原則1：ロールベースでチームを分ける#

原則2：最小権限の原則を守る#

原則3：チームベースで管理する#

原則4：命名規則を統一する#

実際の設計例#

環境別 × レイヤー別 × 役割別のチーム構成#

権限マトリックス#

Project × Workspace × Team のマッピング#

Terraformでチーム管理を「コード化」する 🔧#

なぜTerraformで管理すべきか#

実装例#

運用を成功させる3つの実践 🌟#

1. SSO連携で入退社を自動化#

2. Organization Ownerは2-3名に限定#

3. 四半期ごとの権限棚卸し#

これから始めるあなたへ 🚀#

最初の一歩#

特に大規模環境で気をつけること#

まとめ 💡#