TL;DR
- 開発者アクセスのゼロトラスト化は2026年に「やるべきか」から「どう実装するか」に移った
- VPN 依存は接続オーバーヘッド・全社停止リスク・横展開困難の3点で限界
- 採用パターンは Tailscale（メッシュ VPN 系）・Cloudflare Access / AWS Verified Access（IAP 系）・SSH bastion（古典）の組合せ
- 識別はアイデンティティ（IdP）、認可はリソース単位、監査は中央集約が基本
- IaC で表現できる構成にしないと、変更履歴と権限漏れが両方詰む
この記事の目的と成功基準
- 目的: 開発者アクセスのゼロトラスト化を、ツール選定と IaC 化レベルで具体化する
- 想定読者: SRE / Platform / セキュリティ担当のエンジニア
- 成功基準: 「ゼロトラスト 開発者アクセス」関連クエリでの流入、Platform Engineering AI 時代 への回遊
なぜ VPN から離れるのか
2026 年技術トレンド でもゼロトラストは継続したトレンドとして挙げられている。VPN は以下が限界：
- 接続オーバーヘッド: 一度繋ぐと全社ネットワーク到達可能、最小権限が表現できない
- 全社停止リスク: VPN ゲートウェイの障害が全社停止に直結
- 横展開困難: マルチクラウド・マルチリージョンの統合が苦手
- 監査の薄さ: 「誰がいつ何にアクセスしたか」の粒度が荒い
ゼロトラストは「アイデンティティで識別 → リソース単位で認可 → 全アクセスをログ」が原則。
採用パターン
パターン1: メッシュ VPN 系（Tailscale / Cloudflare WARP / ZeroTier）
WireGuard ベースの分散 VPN。ノード間で直接接続される。
長所：
- セットアップが速い（1日で全社展開も可能）
- 個別ノードへの ACL で最小権限が表現可能
- 開発者体験が良い（既存ツールがそのまま動く）
短所：
- すべてのリソースに sidecar/agent を入れる前提
- 外部監査向けの構造化レポートが弱い場合あり
パターン2: Identity-Aware Proxy 系（Cloudflare Access / AWS Verified Access / Google IAP）
リソースの前に Proxy を置き、IdP 認証＋ポリシー判定でアクセスを許可する。
長所：
- リソース側に agent 不要（HTTP / SSH / RDP に対応）
- IdP（Okta、Google Workspace 等）との統合が自然
- 監査ログが構造化されている
短所：
- 設定の細粒度管理が複雑になりがち
- パブリックネットワーク経由のため latency が乗る
パターン3: SSH bastion（古典）
踏み台サーバ経由でアクセス。古典だが2026年でも残る理由がある。
長所：
- レガシーシステムとの相性が良い
- 監査が SSH ログとして残る
- 既存運用との整合性
短所：
- 単一障害点になりやすい
- 横展開が手作業中心
組合せ設計
実務では1つで完結せず、組合せが標準。
| 接続先 | 推奨パターン |
|---|---|
| Web 管理画面（社内ツール） | IAP |
| Kubernetes API | IAP + kubectl plugin |
| クラウド VM への SSH | Tailscale or IAP（SSH対応） |
| データベース（直接接続） | bastion 経由 + audit log |
| オンプレ機器 | Tailscale |
認可の設計
リソース単位 × アクション単位で認可を表現する。
# 例: Cloudflare Access policy
policy:
- name: prod-database-read
decision: allow
require:
- email_domain: "growth-lab.example"
- group: "data-platform"
- mfa: true
- name: prod-database-write
decision: allow
require:
- email_domain: "growth-lab.example"
- group: "data-platform-write"
- mfa: true
- approval: "[email protected]"
key は「read と write を別ポリシーに」「destructive操作には承認 hook」。
監査ログの中央集約
すべてのアクセスを構造化ログで残し、SIEM（Splunk / Datadog / Elastic）に集約する。
- アクセスのアイデンティティ（user + device）
- リソース・アクション
- 認可判定の根拠（どのポリシーで許可）
- セッション ID（操作トレース用）
異常検知の起点になる。新規地点からのアクセス、深夜時間帯、特権アクションの急増などをアラート化。
IaC 化が必須
ポリシーは手動 UI で増やすと、3か月で「誰がなぜ追加したか」が辿れなくなる。
- Terraform で Tailscale / Cloudflare Access / AWS Verified Access を表現
- PR レビューで変更を承認
- 変更履歴が git に残る
resource "cloudflare_access_policy" "prod_db_read" {
application_id = cloudflare_access_application.prod_db.id
zone_id = var.zone_id
name = "prod-database-read"
decision = "allow"
precedence = 10
include {
email_domain = ["growth-lab.example"]
group = ["data-platform"]
}
require {
mfa = true
}
}
移行ステップ
- 可視化: 現状のアクセス経路をすべて列挙
- IdP の整備: SSO（Okta、Google Workspace 等）を全アプリで統一
- 重要リソースから順に: 本番 DB・Kubernetes・管理画面の順
- VPN の段階廃止: ゼロトラスト経路が安定したら VPN を縮退
- IaC 化: 全ポリシーを Terraform に
- 監査ログ集約: SIEM 連携と異常検知
アンチパターン
- 「とりあえず VPN を残したまま」: 二重管理になり、どちらも形骸化
- MFA を一部リソースだけ: 弱い経路から侵入される
- IaC 化を後回し: 変更履歴が消え、棚卸し不可能に
FAQ
Q. Tailscale と Cloudflare Access、どちらを選ぶべきですか？ A. ノードに agent を入れられる環境なら Tailscale、agent 不可・HTTP/SSH 中心なら Cloudflare Access。組合せも普通です。
Q. 既存 VPN を完全廃止できますか？ A. 多くの組織で可能ですが、レガシーシステムが残るとパターン3（bastion）を限定的に併用するケースがあります。
Q. ゼロトラスト導入のコスト感は？ A. Tailscale なら月数 USD/ユーザー、Cloudflare Access も同等。VPN ゲートウェイ運用コストと比較すると低くなることが多いです。
まとめ
開発者アクセスのゼロトラスト化は、メッシュ VPN・IAP・bastion の組合せで設計する。アイデンティティで識別、リソース単位で認可、IaC で変更履歴を残す、監査ログを中央集約する——この4点が揃って初めて運用に乗る。Platform チームの責務として位置づけるのが現実解。
