Zenn
電算システム 有志Publicationへの投稿
🛡️

Blog series Google Cloud セキュアな土台作り: 第２回

SKY(Tomoaki Sekiya)
に公開
Security
Google Cloud
basic
AWS Organizations
intermediate
tech

第2回：設計図を引こう！Google Cloud の「組織（Organization）」基本のキ

はじめに

お疲れ様です。SKY こと関谷です。

前回の第1回では、クラウドを安全に使うための「地図」として、責任共有モデル、多層防御（Defense in Depth）、ゼロトラスト（Zero Trust） を確認しました。これらはクラウド セキュリティを考えるうえでの普遍的な原則です。

今回からは、その「地図」をもとに 設計図（Landing Zone） を描いていきます。クラウドはすぐにプロジェクトを作って試せる反面、「とりあえず」で進めると将来の運用・監査・コスト最適化で大きなつまずきになりがちです。

この第2回では、まず なぜ土台作りが重要なのか をリスク面から整理し、次に リソース階層の理解、フォルダ構成の型、プロジェクト命名規則の作り方 を順に解説します。

2-1. はじめに：なぜ「土台作り（Landing Zone）」が重要なのか？

クラウドの良さは「すぐ試せること」。ただし、このスピード感は 設計が追いつかないまま運用に入る リスクと表裏一体です。最初の 1～2 個のプロジェクトなら勢いで回せても、10・100 と増える頃には、命名・権限・ネットワーク・ログの“ちょっとした判断”の積み重ねが、統制不能な複雑さとなって現れます。Landing Zone は、そうした将来の“ほつれ”を 構造で防ぐ基礎工事 です。

リスクについて

  • セキュリティリスク：公開不要なリソースを外に晒してしまう
    例）検証で開けたポートや外部 IP を閉じ忘れ、本番公開のまま残存。脆弱性対応やインシデント時に影響範囲が読めなくなります。
  • 管理コスト増：命名ルールがバラバラで棚卸しが困難
    例）誰の・何のためのプロジェクトかが分からず、権限見直しや課金精査が人海戦術に。監査・説明責任も重くなります。
  • 後戻り困難：既存サービスを止めずに再設計は難しい
    例）動いている CI/CD、監視、課金、権限の紐づけを“生かしたまま”移し替える作業は、現場にとって大きな負担です。

Landing Zone とは？

Google Cloud で言う「Landing Zone」とは、安全かつ拡張性を見据えた基本構造やルールを最初に整えること です。人の注意に頼らず、“作れない・通らない” という仕組み でミスを抑えます。

項目 考えるべき内容 効果
リソース階層 組織・フォルダ・プロジェクトをどう分けるか 権限・ポリシーを統一的に適用できる
命名規則 環境やシステム名をどう表現するか 一目で用途や環境が分かる
ガードレール 組織ポリシーや IAM ルールを最初に定義 セキュリティ事故を未然に防ぐ
共通基盤 ネットワークやログをどこで集中管理するか 全体の効率化・統制強化

補足の解説（表のねらい）

  • リソース階層：上位（Organization/Folder）で“原則”を定め、下位（Project）で“最小限の例外”だけを許すと、レビューと監査が楽になります。
  • 命名規則：env-system-team のような機械可読な形にすると、自動化（検索・集計・クォータ管理）が一気に進みます。
  • ガードレール：本番フォルダに「外部 IP 禁止」「サービス アカウント鍵作成禁止」「許可リージョン限定」などを先に敷くと、“うっかり” を構造的に防止。
  • 共通基盤：Shared VPC、ログ集約、監視、 CI/CD の“置き場”を最初に固定しておくと、各プロジェクトは“つなぐだけ”で標準準拠に。

構造的に落ちる落とし穴（なぜ起きる？）

  • 人の善意・注意に依存：担当交代・多忙・属人化で、例外運用が常態化します。
  • “一度きりの特例”が積み重なる：期限なしの例外は事実上の恒久ルールに。将来の統廃合で足かせになります。
  • 監視とコストの“後付け”：先に集約先を決めないと、各チームごとの局所最適になり全体像が見えません。

先に整えると何が変わる？

  • 安全性：本番に強い制約、開発は緩める——“環境で差をつける” が素直に実現。
  • 速さ：命名・ラベル・ネットワーク・ログの“決めごと”があると、新規プロジェクトが申請テンプレで数分〜数時間で立ち上がります。
  • 説明可能性：どの資産がどの原則で守られているかを 構造で 示せるため、監査・取引先説明が楽になります。

導入ステップ（小さく速く始める）

  1. 原則を 1 枚に：環境区分（prod/stg/dev/sbx）、禁止事項（外部 IP・鍵作成など）、リージョン方針を箇条書き化。
  2. フォルダの“型”を選ぶ：環境優先 or 部門優先。どちらかで最小スコープを試す。
  3. 命名・ラベルを固定：[env]-[system]-[team]-[nn]、env/system/team/costcenter/owner を共通キーに。
  4. 共通基盤の置き場を作る：Shared Services にネットワーク・ログ・監視・ CI/CD を先置き。
  5. 例外運用を仕組み化：申請→承認→期限付き（自動リマインド）で“特例の常態化”を防止。

最初の 30 日チェックリスト

  • 組織ポリシーの 禁止リスト（外部 IP、鍵作成、許可リージョン）を作り、本番フォルダに適用
  • 命名テンプレと 必須ラベル を Wiki と申請フォームで周知
  • Shared VPC／ログ集約プロジェクト／監視の 集約先 を開設し、接続手順を標準化
  • 課金アラート と 監査ログ の保存先・保持期間を決定
  • サンドボックスに TTL／自動停止 の仕組みを導入（放置資産を作らない）

アンチパターンと回避策

  • プロジェクト乱立（組織直下） → フォルダで環境 or 部門を切り、原則はフォルダに集約
  • 表示名だけ運用 → Project ID を主語に。小文字・英数・ハイフン、変更不可を前提にルール化
  • “暫定の例外”が恒久化 → 例外は期限付き・再承認必須・可視化（ダッシュボード）
  • 監視・コスト“後で考える” → 初日から集約先とアラートを標準メニューに

Landing Zone 全体像
Landing Zone 全体像

2-2. Google Cloud の世界観：リソース階層を理解する

2-1 で「土台（Landing Zone）」の大切さを確認しました。続く 2-2 では、その土台を乗せる 器＝リソース階層 をもう一段わかりやすく噛み砕きます。ポイントは、

  1. それぞれの階層に「役割」と「責任境界」がある、
  2. 上で決めた原則が下に継承される、の 2 つです。
    ここが腑に落ちると、「どこに何のルールを置くか」「例外はどこで表現するか」が迷いにくくなります。

4 つの階層と“責任の持ち場”

  1. 組織（Organization）：全社の“屋根”

    • ドメイン（ Cloud Identity / Google Workspace）と結びつく最上位の入れ物。
    • 全社原則の置き場：外部 IP の作成禁止、鍵の作成禁止、許可リージョンの固定など、誤操作を防ぐ強いルールをここで定めると効果大。
    • 監査・コンプライアンスの観点では、一貫した原則が 1 箇所にある こと自体が強みになります。

  2. フォルダ（Folder）：運用の“型”を分ける仕切り

    • 部門・環境（Production / Staging / Development / Sandbox）・共通基盤（Shared Services）など、運用の違い を表します。
    • 継承の中継点：本番だけ制約を厳しく、開発は緩める、といった “環境の差” を フォルダで 表現。
    • 入れ子にできるため、部門 × 環境 の二軸構造にも馴染みます。ただし深くしすぎると迷子になりがちなので、目安は 2～3 段。

  3. プロジェクト（Project）：実務の“主語”

    • 課金・監査ログ・クォータ・権限の 最小単位。ここで VM、バケット、 DB などの実体（リソース）を作ります。
    • 詰め込み過ぎ注意：1 プロジェクトにすべてを抱え込むと、権限分離・変更リズム・障害影響の切り分けが難しくなります。
    • システムの性質に応じて、「アプリ系」と「データ系」を分けるなど、責任境界で分割 すると運用が楽です。

  4. リソース（Resource）：実体そのもの

    • Compute Engine の VM、Cloud Storage のバケット、Cloud SQL のインスタンス等。
    • リージョン / ゾーン の概念が絡むため、レイテンシ・可用性・災害対策を意識した配置が必要です。

「継承」を味方につける（原則は上位、例外は下位）

  • 上で決めたことは下へ流れる：Organization / Folder に置いた IAM や 組織ポリシーは、その配下の Project / Resource に継承されます。
  • 原則は上位に一度だけ：外部 IP 禁止、鍵作成禁止、許可リージョンなど、事故を生まない大枠のルールは上位 に。
  • 例外は下位に限定：どうしても必要な例外は、特定フォルダ（例：Staging）や特定プロジェクトに寄せると、見通しが保てます。
  • レビューのしやすさ：例外を下位に集約すると、「どこが標準外なのか」をレビューや監査で素早く把握できます。

リソース階層と継承
リソース階層と継承

よくある迷いどころと考え方

  • Q. フォルダの切り方は“環境別”と“部門別”どっち？
    A. 統制をシンプルに始めたいなら “環境別” が扱いやすい。責任・予算を部門で完結させたい大規模組織は “部門別”＋各部門の下に環境フォルダが相性良し。
  • Q. 1 つのシステムを 1 プロジェクトにまとめて良い？
    A. 小規模なら可。ただし運用が育つにつれ、責任境界ごとに分割（例：アプリ系とデータ系）しておくと、権限分離・変更管理・障害影響の抑制に効きます。
  • Q. フォルダはどれくらい深くして良い？
    A. 2～3 段が目安。深さより 命名・ラベルの一貫性 と “どこに何の原則を置くか” の分かりやすさ を優先します。

“どこに何を置くか” の実務ヒント

  • Organization：全社原則（組織ポリシー）、全社ロールの最小付与、監査ログ・セキュリティ通知の基本方針。
  • Production フォルダ：外部公開の原則禁止、許可リージョン固定、サービス アカウント鍵禁止など 強い制約。
  • Development / Sandbox フォルダ：コスト上限、外部公開の原則不可、期限付きの例外運用（自動リマインド）。
  • Shared Services フォルダ：Shared VPC、ログ集約、監視、 CI/CD の 置き場。各 Project はここに“つなぐ”だけで標準準拠。
  • Project：命名・ラベルの統一（env/system/team/costcenter/owner など）。課金・監査の主語 であることを意識。

サンプル（イメージ）

  • EC サイト：
    • Production フォルダ配下に prod-ec-site-app（アプリ系）と prod-ec-site-data（データ系）を分離。
    • フォルダで外部 IP 禁止・許可リージョン固定。アプリ Project は Private 経由で入口を受け、Data Project は内部のみ通信。
    • ログと監視は Shared Services に集約し、横断観測を標準化。

2-3. 【具体的な方法】失敗しないフォルダ構成パターン

2-2 で「どの階層に何を置くか」を掴んだら、次は “運用の型” をフォルダで表現する 段階です。ここが腹落ちしていると、後ろの IAM 設計やログ集約、ネットワーク標準化までが一気にスムーズになります。結論から言うと、実務で扱いやすいのは 環境優先 と 部門優先 の 2 パターン。どちらも正解になり得ますが、選定の軸を先に共有しておくのがコツです。

まず押さえる設計方針（共通原則）

  • 原則はフォルダでまとめて適用：強いルール（外部公開禁止、許可リージョン固定、鍵作成禁止など）は、プロジェクト単位でバラバラにしないで フォルダ に載せます。
  • 例外は下位に寄せる：どうしても必要な例外は、特定のプロジェクト／特定のサブフォルダに “閉じ込める”。可視化と監査が楽になります。
  • Shared Services を最初に用意：ネットワーク（ Shared VPC など）、ログ・監視、 CI/CD は 置き場を固定。各プロジェクトは “つなぐだけ” にします。
  • 命名・ラベルは全フォルダで共通キー：env/system/team/costcenter/owner を決め、在庫・課金・監査の横断で迷わない土台に。

環境優先パターン（シンプル）

Organization
 ├─ Production
 ├─ Staging
 ├─ Development
 ├─ Sandbox
 └─ Shared Services

向いているケース

  • まず 統制をシンプル に始めたい（中規模以下の導入直後や、クラウド初心者チームが多い）。
  • 本番だけは 特に厳格 にしたい（外部 IP 禁止、鍵作成禁止、変更フロー厳格など）。

運用のポイント

  • Production フォルダ：厳格な組織ポリシー・ IAM 条件を集約。デプロイ経路も固定（例： CI/CD からのみ）。
  • Staging フォルダ：本番に近い制約で最終検証。公開は限定、監査ログは本番同等。
  • Development / Sandbox：利便性を確保しつつ、コスト上限・期限付き例外・外部公開禁止でリスクを制御。
  • Shared Services： Shared VPC、 Cloud NAT、 DNS、ログ集約、監視、 CI/CD 基盤の “置き場”。環境ごとに参照。

利点と注意

  • 利点：環境で縦串 に統制できる（本番だけ厳格、開発は緩める）。
  • 注意：部門別の可視化は ラベル・課金ビュー で補います（team=sales など）。

部門優先パターン（大規模・縦割り文化向け）

Organization
 ├─ Sales
 │   ├─ Production / Staging / Development
 ├─ IT
 │   ├─ Production / Staging / Development
 └─ Shared Services（全社共通）

向いているケース

  • 組織が大きく、責任と予算が部門単位 で完結している。
  • 各部門が自律的にプロジェクトを増やし、スピードと責任 を両立させたい。

運用のポイント

  • 各部門の Production に強い制約を適用。部門内の Shared Services（共通ライブラリ、内向け API、部門内ログ集約など）を併設してもよい。
  • 全社横断のネットワーク・監査・監視は 全社 Shared Services に集約し、部門内共通 と役割分担。
  • 標準の違いが部門ごとに増えすぎないよう、全社原則は Organization か全社 Shared Services で固定。

利点と注意

  • 利点：権限委譲・予算管理が 部門の責任範囲に自然に一致。
  • 注意：部門ごとの例外が増えすぎないよう、原則（禁止・必須）を全社で単一化。

フォルダ単位でのガードレール例

フォルダ 制約例 目的
Production 外部 IP 禁止 / サービス アカウント鍵禁止 重大事故防止
Staging 本番に近いが一部緩和 移行前の検証
Development コスト上限 / 外部公開不可 開発者の利便性と安全性
Shared Services ネットワーク / ログ集約 全社統合管理

使い方の解像度を上げるヒント

  • Production：許可リージョン固定、強制暗号化（必要に応じて CMEK）、デプロイは特定の CI/CD サービス アカウントのみ、人手直操作は原則不可。
  • Staging：本番と同等のネットワーク・ IAM・監査ログを適用。外部公開が必要な場合は ** IP 制限・期限付き**。
  • Development：コストアラート、短命プロジェクトの ** TTL ルール**、外部公開不可。安全な速さ を担保。
  • Shared Services： Shared VPC ホスト、 Cloud DNS、 Cloud NAT、ログの集約先（ Cloud Logging / BigQuery）、 Cloud Monitoring ワークスペース、 Artifact Registry、 CI/CD。

フォルダ構成例
フォルダ構成例

2-4. 誰が見ても分かる！プロジェクト命名規則の決め方

フォルダ設計で “型” ができたら、現場の運用で一番効いてくるのが プロジェクトの命名 と メタデータ（ラベル等） です。Google Cloud では、課金・監査・権限・クォータ の多くがプロジェクトを単位に動きます。つまり、プロジェクトの名前づけが “在庫管理の索引” となり、トラブル対応や棚卸し、コスト最適化の速度に直結します。

命名は「今の担当が分かればよい」では不十分です。異動・引継ぎ・第三者の監査 を前提に、見ただけで意味が分かる・機械でも扱いやすい 形にしましょう。

含めるべき要素

要素 例 意味
環境 prod, stg, dev, sbx 本番 / 検証 / 開発 / 実験
システム名 ec-site, hr-system EC サイト / 人事システム
部門名 sales, it 営業部 / 情報システム部
番号 01, 02 拡張や複数環境対応

命名例

  • prod-ec-site-sales
  • it-hr-system-dev
  • data-analytics-stg-01

読み解き方の例

  • prod-ec-site-sales → 「本番（prod）／ EC サイト（ec-site）／ 営業部（sales）」
  • data-analytics-stg-01 → 「ステージング（stg）／ データ分析（data-analytics）／ 1 系列目（01）」

プロジェクトの識別子を正しく扱う

  • Project ID：URL や API、スクリプトで主に使う 一意の識別子。小文字英数字とハイフン を基本に、後から変更できない 前提で設計します（例：prod-ec-site-sales）。
  • Project name（表示名）：人が見るための名前。変更可能ですが、運用の主語にはしない 方が安全です。
  • Project number：数値の内部一意キー。覚えなくて OK。ただし監査ログや一部連携で目にします。

実務の鉄則：Project ID を“唯一の真実”として設計・自動化。表示名はサブ。ダッシュボードも Project ID で揃えるとブレません。

命名ルールを “運用” に落とすコツ

  • テンプレート固定：[env]-[system]-[team]-[nn] を標準に。system は小文字・ハイフン区切り、略語の表を Wiki に。
  • 申請フォーム化：Google Forms などで必須項目にし、入力ミスを構造的に防止。自動でラベル・フォルダ・請求先を紐づけて作成。
  • 衝突回避の仕組み：[nn] を 2 桁で確保（01 から）。将来の分割や DR 用の増設にも対応しやすくなります。
  • 命名とラベルの二層設計：名前で “人が読む”、ラベルで “機械が集計”。両輪で迷いをなくします。

ラベル設計（運用で効く最小セット）

  • 共通キーを全社で固定：env, system, team, costcenter, owner など。検索・請求・棚卸しの 横断軸 に。
  • 全リソースにも同じキー：VM やバケット、ジョブにも 同じキーセット を付与。資産の可視化 が一気に進みます。
  • 作成時に自動付与：プロジェクト作成フローでラベルを必須に。後付けは必ず漏れます。

命名とラベル
命名とラベル

2-5. 参照情報

次回予告

次回の第3回では、いよいよ IAM（Identity and Access Management）の鉄則 に進みます。
第2回で作った “型（階層・フォルダ・命名・ガードレール）” の上に、「誰に」「何を」「どこまで」 をどう重ねるのか。実務で使える最小権限の考え方や、 Google グループを用いた権限設計のコツを分かりやすく解説します。

電算システム 有志
電算システム 有志Publication

株式会社電算システムのエンジニアを中心に情報発信をしている Publication です。各記事の内容は個人の意見であり、企業を代表するものではございません。

Discussion