はじめに
現代の企業における開発環境では、セキュリティとアクセシビリティの両立が重要な課題となっています。Google Cloud Workstationsを活用したセキュアな開発環境の設計について、実際のアーキテクチャパターンと技術的考慮事項を解説します。
全体アーキテクチャ
基本構成
Cloud Workstationsを中心とした開発環境では、以下のような階層化されたアーキテクチャを採用します：
1
2
3
4
5
| インターネット → Global Load Balancer → Private Service Connect → Cloud Workstations
↓
Google Cloud APIs（直接）
↓
Secure Web Proxy → 外部サイト
|
主要コンポーネント
- Cloud Workstationsクラスター: 開発者用の仮想開発環境
- Global Load Balancer: 外部からの安全なアクセス制御
- Secure Web Proxy: 外部サイトへのアクセス制御
- VPCネットワーク: セキュリティ境界の確立
セキュリティ制御の多層化
1. 入口制御（外部→開発環境）
SSL証明書管理
1
2
3
4
5
6
7
8
| resource "google_certificate_manager_certificate" "main" {
managed {
domains = [
var.cluster_custom_domain,
"*.${var.cluster_custom_domain}"
]
}
}
|
Google Certificate Managerによる自動SSL証明書管理により、安全な接続を確保します。
Global Load Balancer設定
1
2
3
4
5
6
7
8
| resource "google_compute_backend_service" "main" {
protocol = "HTTPS"
timeout_sec = 86400 # 開発作業用の長時間セッション
log_config {
enable = true
sample_rate = 1.0 # 全アクセスのログ記録
}
}
|
2. 出口制御（開発環境→外部）
Google Cloud API直接アクセス
開発に必要なGoogle Cloud APIは高速化のため直接アクセスを許可：
1
2
3
4
5
6
7
8
| resource "google_network_connectivity_policy_based_route" "google_apis" {
for_each = {
"private_googleapis" = { cidr = "199.36.153.8/30" }
"cloud_dns" = { cidr = "35.199.192.0/19" }
}
priority = 101 # 高優先度
next_hop_other_routes = "DEFAULT_ROUTING"
}
|
外部サイトアクセス制御
外部サイトへのアクセスはSecure Web Proxyを経由し、厳格に制御：
1
2
3
4
5
6
7
8
| resource "google_network_security_url_lists" "allowed_urls" {
values = [
"github.com",
"npmjs.com",
"docker.io"
# 必要最小限のサイトのみ許可
]
}
|
TLS インスペクションの実装
仕組みの概要
Secure Web ProxyでTLSインスペクションを有効化することで、暗号化された通信の内容検査が可能になります：
1
2
3
| 開発環境 ←→ [偽証明書] ←→ Proxy ←→ [本物証明書] ←→ 外部サイト
↓
通信内容検査・制御
|
Private CA設定
1
2
3
4
5
6
7
8
9
| resource "google_privateca_certificate_authority" "main" {
type = "SELF_SIGNED"
config {
subject {
organization = "Company Development CA"
common_name = "dev-proxy-ca"
}
}
}
|
パフォーマンスへの影響と対策
TLSインスペクションは通常3-5倍の処理時間増加を伴いますが、小規模開発環境では以下の最適化が有効です：
- Keep-Alive設定最適化:
timeout=600s, max=unlimited - 接続プール活用: 同時接続数が少ない環境での長時間セッション維持
- Google Cloud API回避: 頻繁に使用するAPIは直接アクセス
VPCファイアウォールの設計
GCPとAWSの設計思想比較
GCP: ネットワーク中心設計
1
2
3
4
| resource "google_compute_firewall" "workstation_rule" {
network = google_compute_network.main.name
target_tags = ["cloud-workstations-instance"] # タグで選択的適用
}
|
AWS: リソース中心設計
1
| Security Group → インスタンス直接アタッチ → 横断的適用可能
|
階層化されたファイアウォール制御
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| # 1. Cloud Workstations基本動作用（高優先度）
resource "google_compute_firewall" "workstation_control_plane" {
priority = 1000
target_tags = ["cloud-workstations-instance"]
allow {
protocol = "tcp"
ports = ["443", "980"] # 管理用ポートのみ
}
}
# 2. 基本通信許可（中優先度）
resource "google_compute_firewall" "allow_icmp" {
priority = 60000
allow {
protocol = "icmp"
}
}
# 3. デフォルト拒否（最低優先度）
resource "google_compute_firewall" "default_deny" {
priority = 65535
deny {
protocol = "all"
}
}
|
Private Service Connect (PSC) の活用
内部接続の確保
1
2
3
4
5
| resource "google_compute_forwarding_rule" "psc" {
target = workstation_cluster.service_attachment_uri
ip_address = internal_ip_address
load_balancing_scheme = "" # PSC専用
}
|
PSCにより、VPC内からの内部アクセスと外部からのインターネットアクセスを分離できます。
DNS設定によるアクセス制御
1
2
3
4
| resource "google_dns_record_set" "private_wildcard" {
name = "*.${cluster_hostname}"
rrdatas = [psc_internal_ip]
}
|
運用上の考慮事項
ホワイトリスト管理
外部アクセス制御は変数化により運用効率を向上：
1
2
3
4
5
6
7
8
9
| variable "allowed_domains" {
default = [
"github.com",
"*.googleapis.com",
"pypi.org",
"registry.npmjs.org",
"docker.io"
]
}
|
監査ログの活用
1
2
3
4
5
6
7
| resource "google_logging_metric" "suspicious_access" {
filter = <<EOT
resource.type="cloud_workstations"
AND severity>=WARNING
AND jsonPayload.url=~".*suspicious-pattern.*"
EOT
}
|
まとめ
Google Cloud Workstationsを活用したセキュアな開発環境では、以下のポイントが重要です：
- 多層防御: 入口・出口両方での制御
- 最小権限の原則: 必要最小限のアクセス許可
- 監査証跡: 全アクセスのログ記録
- パフォーマンス最適化: セキュリティとのバランス
これらの考慮事項を適切に実装することで、セキュアでありながら開発効率を維持できる環境を構築できます。
