現場の「魔窟」を封じる：GCP組織ポリシーによる鉄壁のガードレール構築術
現場でインシデント対応をしていると、決まって遭遇するのが「開発者が良かれと思ってやった設定」が引き金となるセキュリティ事故だ。
「検証用だから公開IPを付けた」「コストを抑えるために他リージョンを使った」。その善意が、結果として攻撃者に踏み台を提供し、数千万円単位のクラウド利用料不正請求や、機密情報の漏洩を招く。個人の意識に依存するセキュリティは、もはや時代遅れだ。「人間がミスを犯す前提」で、システム側で物理的に拒絶する。 これが、我々エンジニアが到達すべき「要塞化」の境地である。
今回は、GCP（Google Cloud Platform）における「組織ポリシー（Organization Policy）」を活用し、インフラの穴を物理的に塞ぐ戦略を伝授する。
—
なぜ「設定」ではなく「強制」が必要なのか
攻撃者は、クラウド環境へ侵入した瞬間、真っ先に以下を確認する。
1. 外部からのアクセスが可能か（外部IPの存在）
2. 管理権限を奪取してリソースを増殖できるか（IAMの隙）
3. 監視の届かないリージョンに隠れ家を作れるか
特に、「公開IPアドレスの自動付与」や「許可されていないリージョンでのインスタンス作成」を放置していると、攻撃者に自由に動かれる。これらを「個人の規約」ではなく、クラウドプラットフォームのレイヤーで「エラー」として返却させるのが組織ポリシーの真骨頂だ。
—
実践：組織ポリシーによる「3つの鉄壁」
以下のポリシーは、どんな環境であっても最低限強制すべき「防衛線」である。
1. 外部IPアドレスの付与を制限する
インスタンスに外部IPを付与させないことで、踏み台化を根絶する。
2. リソース作成を許可されたリージョンのみに制限する
データ主権やコンプライアンス管理のため、特定のリージョン以外でのリソース作成を拒絶する。
3. 未承認のサービスアカウント作成の禁止
権限昇格の起点となるサービスアカウントの乱造を止める。
—
設定用YAMLサンプル：Terraformで強制する
これらをGUIでポチポチ設定してはいけない。構成管理（IaC）としてコード化し、リポジトリにコミットすることで「変更履歴」を残すのがプロの作法だ。
以下は、asia-northeast1（東京）以外でのリソース作成を禁止し、外部IP付与を物理的にブロックするTerraformの設定例である。
# 東京リージョン以外でのリソース作成を禁止するポリシー
resource "google_organization_policy" "allowed_locations" {
org_id = "1234567890" # 実際の組織ID
constraint = "gcp.resourceLocations"
list_policy {
allow {
values = ["in:asia-northeast1-locations"] # 東京のみ許可
}
}
}
# 外部IPアドレスの付与を禁止するポリシー
resource "google_organization_policy" "restrict_public_ip" {
org_id = "1234567890"
constraint = "compute.vmExternalIpAccess"
list_policy {
deny {
all = true # すべてのVMで外部IPの付与を拒否
}
}
}—
現場の盲点：開発者が「困らない」ためのブリッジ
「ポリシーでガチガチに固めると、開発チームから苦情が来る」という懸念はもっともだ。しかし、セキュリティは「不自由」を強いるものではなく「安全な経路」を提示するものであるべきだ。
外部IPを禁止したなら、開発者には以下の代替案をセットで提供せよ。
- Identity-Aware Proxy (IAP) の導入: 外部IPなしで、セキュアにSSHやHTTPSアクセスを可能にする。
- Cloud NAT の活用: アウトバウンド通信が必要な場合、NATゲートウェイ経由で通信させ、インバウンドは完全に遮断する。
実装ヒント：IAP経由でのセキュアなアクセス許可
インフラ側で以下のようにタグ制御を行い、IAPからのアクセスのみを許可するファイアウォールルールを適用する。
# IAPからのSSH通信（TCP 22）のみを許可するGCP CLIコマンド
gcloud compute firewall-rules create allow-ssh-from-iap \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20 \
--target-tags=secure-server—
最後に：セキュリティは「諦めない」こと
エンジニアにとって、最高のセキュリティツールは高額な商用製品ではなく、「面倒くさい作業をコードで自動化し、ミスを発生させない仕組み」だ。
今日紹介した組織ポリシーは、一度設定すれば、新しく入ったメンバーがどれほど無知であろうと、あるいはベテランがどれほど疲弊していようと、確実にインフラを守り続けてくれる。
インシデント対応の現場で、真っ先に被害を受けるのは「管理者が把握していない放置されたリソース」だ。まずは組織ポリシーで「把握できないリソース」を作らせない環境から作り始めよう。それが、君の明日を守るための第一歩だ。
技術は、使う人間の意志の強さで、初めて真の力を発揮する。現場の「魔窟」を一つずつ片付けていこう。健闘を祈る。
コメント