第１回 基本の復習 - セキュリティの全体像と「責任共有モデル」
はじめに
お疲れ様です。SKYこと関谷です。
そういえば、Google Cloud のセキュリティに関する主な部分を纏めたブログってあまりないなと思っている今日この頃（私の確認不足かもしれませんが。。）、自分なりに纏めてみるのもありかなということで、Google Cloud のセキュリティについて、ブログシリーズを開始します！
対象は、初級～中級というところになるかと思います。少なくとも上級と中級の上の人は新しい発見はないかと思います。もし、間違えや勘違いを招くような部分がありましたら教えて下さい！
本回の最後にも記載しているように、一旦、全９回を予定しています。もしかしたら途中で増減するかもしれません。
それなりに長編になると思うので、今どきの生成ＡＩも活用しつつ、週に１度くらいは新しい回を投稿できるようにする予定です。
お付き合いいただけたら幸いです！
ブログシリーズその他の執筆
＊2025.09.05更新*
本編
番外編
1-1. なぜクラウドセキュリティの「地図」が必要なのか？
クラウドを使い始めるとき、多くの方が最初に感じるのは「どこから手をつければいいのだろう？」という戸惑いではないでしょうか。私も社会人経験の半分以上経験してきたオンプレミスの世界では、サーバーを自分たちのデータセンターに設置し、ネットワーク機器を用意して、自分たちの管理下で全てを制御していました。ところが Google Cloud のようなクラウドサービスでは、その境界が大きく変わります。
クラウドは便利でスピード感がありますが、「セキュリティを守る」という観点では、オンプレミス時代とは考え方を切り替える必要があります。特に重要なのが「自分たちが守るべき範囲」と「クラウド提供者である Google が守ってくれる範囲」を正しく理解することです。
この違いを理解しないままクラウドを利用し始めると、「設定は Google がやってくれているだろう」と思い込んでしまい、実際にはユーザー自身の責任で行うべきセキュリティ対策が抜け落ちることがあります。たとえば、強固なインフラは Google が用意してくれていても、誤った IAM 設定 や 広すぎるファイアウォールルール は利用者側のミスとしてセキュリティリスクを招きます。
ここで役に立つのが「セキュリティの地図」＝責任共有モデルです。
地図があれば、自分たちがこれからどの道を歩むべきかが見え、迷子になることを防げます。クラウドセキュリティにおける「地図」とは、クラウド全体の責任の分担を整理したフレームワークのこと。これを頭に入れておくことで、「まずは何を確認すべきか」「どこまで Google が担保してくれているか」が明確になります。
責任共有モデルの比較表
| 領域 | オンプレミス | Google Cloud（クラウド利用時） |
|---|---|---|
| 物理インフラ（データセンター・電源・冷却） | 利用者が準備・維持 | Google が責任を持つ |
| ハードウェア（サーバー・ネットワーク機器） | 利用者が調達・運用 | Google が責任を持つ |
| 仮想化基盤（ハイパーバイザー、基盤ソフトウェア） | 利用者が管理 | Google が責任を持つ |
| OS・ミドルウェアの設定 | 利用者が構築・運用 | IaaS: 利用者が責任 PaaS: Google が一部管理 |
| アプリケーションの実装・設定 | 利用者 | 利用者 |
| アイデンティティとアクセス管理（IAM） | 利用者 | 利用者 |
| ネットワーク構成（VPC、FWルール） | 利用者 | 利用者 |
| データ保護（暗号化、アクセス制御） | 利用者 | 利用者（ただし Google は暗号化の基盤を提供） |
| 監視・ログ管理 | 利用者 | 利用者（Google は仕組みを提供） |
ポイント整理
-
Google が責任を持つ範囲は、物理的なインフラや基盤の部分（“雲の下”）。
-
利用者が責任を持つ範囲は、IAM・ネットワーク・データ管理などの設定（“雲の上”）。
-
PaaS / SaaS の場合は、Google 側がカバーする範囲が広がるため、利用者の責任は「データと利用方法」に集中していく。
この章で伝えたいことのまとめ
-
クラウドのセキュリティはオンプレミスとは考え方が異なる。
-
「Google が守る範囲」と「利用者が守る範囲」を理解することが第一歩。
-
その理解を助ける「地図」として、責任共有モデルを活用する。
1-2. 最も重要な基本原則：「責任共有モデル」とは？
前の章で「クラウドセキュリティの地図」として責任共有モデルが欠かせないことをお話ししました。ここでは、その中身をもう少し具体的に見ていきましょう。
クラウド利用におけるセキュリティは、「Google が担う部分」と「利用者が担う部分」 にきれいに分かれています。この分担を正しく理解することが、安心して Google Cloud を利用するための第一歩です。
Google が責任を持つ範囲（“雲の下”）
Google が担うのは、いわゆる クラウドの土台となる部分 です。
-
データセンターの物理的なセキュリティ（入退室管理、監視カメラなど）
-
電源、冷却、ネットワーク回線などのインフラ維持
-
サーバーやストレージなどハードウェアの管理
-
仮想化基盤やハイパーバイザーのセキュリティパッチ適用
つまり、利用者が自分で確認・管理できない部分を Google がグローバルな標準で守ってくれています。
公式ドキュメントでも示されているとおり、Google Cloud のインフラは ISO 27001 や SOC 2 など、世界中のセキュリティ認証を取得しており、非常に高い基準で運用されています【参考: Google Cloud セキュリティ概要】。
利用者が責任を持つ範囲（“雲の上”）
一方で、クラウド上の設定やデータ保護の方法 は利用者の責任となります。
代表的な例を挙げると次の通りです。
-
IAM 設定：誰にどの権限を与えるのか
-
ネットワーク制御：VPC サブネットやファイアウォールルールの設計
-
データ保護：暗号化のキー管理やアクセス権の設定
-
アプリケーションの実装：安全なコーディングと脆弱性対策
-
ログ監視とアラート：インシデントが発生した時に気付ける仕組みづくり
つまり、Google が「安全な箱」を提供してくれても、その中に 鍵をかけ忘れた宝箱を置いたままにするかどうか は利用者次第、ということです。
簡単な例え話
少し身近な例に置き換えてみましょう。
Google Cloud を「最新鋭の高層マンション」に例えると、
-
マンション全体の建物構造、監視カメラ、オートロックなどは Google が管理 してくれます。
-
しかし、自分の部屋の鍵のかけ忘れや、窓を開けっぱなしにするかどうかは 入居者（利用者）の責任 です。
いくらマンション自体が安全でも、自分の部屋の管理を怠れば、泥棒に入られてしまいます。クラウドも同じで、基盤は Google が守ってくれますが、最終的な利用方法と設定は自分たちで守る必要があるのです。
IaaS / PaaS / SaaS での責任分界の違い
クラウドの利用形態によっても、責任の分担は変わります。
IaaS / PaaS / SaaS での責任分界
| サービス形態 | Google の責任範囲 | 利用者の責任範囲 |
|---|---|---|
| IaaS（例: Compute Engine） | 物理インフラ、仮想化基盤 | OS、ミドルウェア、アプリ、IAM、ネットワーク設定 |
| PaaS（例: App Engine、Cloud SQL） | 基盤インフラ、OS、ミドルウェアの多く | アプリ設定、データ保護、IAM |
| SaaS（例: Google Workspace） | ほぼすべてのインフラとアプリ本体 | データ、利用者管理、アクセス権限設定 |
このように、サービスのレイヤーが上がるほど、Google の責任は増え、利用者の責任は「データと利用方法」に絞られていきます。
この章で伝えたいことのまとめ
-
責任共有モデル は、クラウドを使ううえでの最も重要な基本ルール。
-
Google は “雲の下” を守り、利用者は “雲の上” を守る。
-
サービス形態によって責任の範囲は変わるため、自分が使っているサービスの特性を理解することが大切。
1-3. Google Cloud セキュリティの主要な思想
前章で「責任共有モデル」を確認しました。ここからは、その土台の上で実践に直結する二つの思想、多層防御（Defense in Depth） と ゼロトラスト（Zero Trust） を丁寧に解きほぐします。どちらも、Google が長年の運用で磨いてきたアーキテクチャや運用モデルに根ざしており、私たち利用者側の設計判断にも直結します。まずは「なぜ重ねるのか」「なぜ疑って検証するのか」を、腹落ちする言葉で押さえましょう。
多層防御（Defense in Depth）—「守りを重ねて、破られても止める」
一枚の盾に頼ると、その盾が欠けた瞬間に「全部抜け」になります。多層防御は、異なる性質の防御を段階的に重ねる 発想です。Google の技術基盤そのものが多層化されており、ネットワーク、アイデンティティ、データ、運用プロセスまでが「冗長に」「重なって」安全側に倒れる設計になっています。例えば Google のネットワークでは DDoS 対策、承認されたプロトコル制御、ファイアウォールや ACL の多段適用などで層を作り、攻撃面を小さく保っています。
利用者側の設計でも、同じ発想を写し取ります。IAM の最小権限、VPC ファイアウォールのデフォルト拒否、組織のポリシー（Org Policy）や IAM Deny による上書きの「最後の一手」、ログ監視と自動アラート、データ暗号化と鍵管理……。一つが漏れても他の層で止める配置にします。最近は Org Policy と IAM Deny を「必ず効くブレーキ」として使い、ヒューマンエラーや過剰権限の拡大を抑え込むプラクティスが推奨されています。
多層防御を「自分ごと」で表した対応マップ（例）
| 層 | 代表的な Google Cloud の機能・手段 | 現場での勘所 |
|---|---|---|
| 物理・基盤層 | Google の物理 DC、ハード/ハイパーバイザーの保護（Google 管理） | ここは Google が担保。上位層に集中。 |
| ネットワーク層 | VPC、ファイアウォール、Cloud Armor、Private Google Access、Cloud NAT | 受信は原則拒否から。外向きは NAT／ PIA で最小経路に。 |
| アイデンティティ層 | IAM（最小権限）、IAM Conditions、IAM Deny、Cloud Identity | ロール付与はグループ経由＋条件付きで。Deny を“非常ブレーキ”に。 |
| サービス境界層 | VPC Service Controls（略してVPC-SC） | 「誰が」だけでなく「どこから・どうやって」を境界で制御。 |
| データ層 | 自動暗号化、Cloud KMS（CMEK） | 機密は必ず鍵管理ポリシーとセットで運用。 |
| 可視化・運用層 | Cloud Logging / Monitoring、SCC（Security Command Center） | 変化を常時検知し、人が見る前にアラート を鳴らす設計に。 |
ポイント：
-
“突破される前提” で層を重ねる。
-
“人間がミスる前提” で上位ガードレール・最終防衛線（Org Policy / IAM Deny）を置く。
玉ねぎモデル
ゼロトラスト（Zero Trust）—「場所ではなく、文脈で信頼する」
従来の「社内にいれば信用」する考えは、クラウドとリモート前提の現代では限界があります。Zero Trust は、ユーザーの属性・デバイス状態・接続元・アクセス対象 といった 文脈（コンテキスト） を都度評価し、必要最小限のアクセスのみ許可 する思想です。Google 自身が社内で実践してきた BeyondCorp は、まさにこの実装モデルで、場所（オフィス内）に依存しない厳密な検証の積み重ねで安全を作ります。
Google Cloud では、Context-Aware Access によってユーザー／デバイス条件・ネットワーク・位置などに基づくアクセス制御を記述できます。IAP（Identity-Aware Proxy）と組み合わせると、アプリごと・パスごとに細やかな制御が可能です。
さらに VPC Service Controls を使えば、IAM の許可可否だけでは防ぎづらい データ持ち出し（Egress／Exfiltration） リスクに対して、サービス境界（Service Perimeter） という“仮想の塀”を築けます。IAM と VPC-SC を 役割の異なる二つの鍵 として合わせるのが、Zero Trust 的な設計の肝です。
Zero Trust の構成要素とプロダクト例
| 要素 | ねらい | Google Cloud の代表機能 |
|---|---|---|
| 強いアイデンティティ | 「誰か」を厳密に識別し、最小権限で付与 | Cloud Identity、IAM、IAM Conditions、短寿命クレデンシャル |
| デバイストラスト | 管理端末・暗号化・ OS 状態などで足切り | Context-Aware Access（デバイス属性を条件化） |
| ネットワークの相対化 | 内部＝安全という前提を捨てる | IAP、Private Google Access、Cloud Armor（エッジで遮断） |
| データ境界 | サービス横断の持ち出しを封じる | VPC Service Controls（サービス境界・ブリッジ・アクセスポリシー） |
| 継続的検証 | 一度通した後も見直す | セッション制御・再認証・SCC による検知と是正 |
「城と堀」から「Zero Trust」へ
ポイント：
-
「場所」ではなく「条件」 を積み上げる。
-
IAM（誰に何を） と VPC-SC（どこからどうやって） を両輪にする。
「多層防御 × ゼロトラスト」を設計に落とす手順概要
-
入口を絞る：VPC 受信は原則拒否、公開は Cloud Load Balancing／ Cloud Armor 経由のみ。
-
誰でも通さない：IAM はグループ経由＋条件付き。高権限には IAM Deny でブレーキ。
-
境界で囲う：VPC Service Controls で BigQuery／ Cloud Storage などの周囲にサービス境界を設定。
-
文脈で選ぶ：Context-Aware Access で社外からの利用や非準拠端末を制限。
-
見てアラームする：Cloud Logging / Monitoring と SCC をつなぎ、権限変更・データアクセス異常を即通知。
Zero Trust の実装マップ
小さく始めるコツ：まずは “公開点の一元化” と “VPC-SC の最小境界” をつくると、安全度が一段上がります。
よくある誤解と落とし穴
-
「社内 IP なら許可」 に頼る：場所だけではゼロトラストになりません。端末の状態 まで見て初めて質が上がります。
-
IAM だけで完結 させる：許可された人の“意図せぬ持ち出し”は IAM だけでは防ぎづらい。VPC-SC を必ず検討。
-
“人に注意喚起” で終える：最上位の Org Policy / IAM Deny を“構造的なミス防止”として入れるのが王道です。
この章で伝えたいことのまとめ
-
多層防御：性質の異なる盾を重ね、突破されても次で止める。
-
ゼロトラスト：場所ではなく 文脈で検証し続ける。BeyondCorp／ Context-Aware Access／ VPC-SC が実装の核。
-
設計では IAM × VPC-SC × Org Policy / IAM Deny を骨格に、ログとアラートで「検知→是正」を回す。
1-4. ロードマップと実践のコツ
前章までで、Google Cloud のセキュリティは 多層防御（Defense in Depth） と ゼロトラスト（Zero Trust） を土台に考えることを確認しました。ここからは、その思想を 設計 → 実装 → 運用 → 改良 に落としていきます。本シリーズは、「雲の下（Google が担保）」を前提に、雲の上（私たちが担う設定と運用） を少しずつ固める道のりです。焦らず、しかし戻りが少ない順番で進めましょう。
進め方の原則
-
戻りにくい土台から決める：Organization／フォルダ設計、命名規則、権限付与のルール（第 2–3 回）
-
入口と通り道を先に整える：VPC・ファイアウォール、外部公開の統制（第 4 回）、Shared VPC による一元管理（第 5 回）
-
ミスを“構造で”防ぐ：Organization Policy と IAM Deny による上位ガードレール（第 6 回）。
-
見える化して守る：ログ集約と監視アラートで“気づける運用”（第 7 回）
-
データを二段で守る：暗号化（Cloud KMS / CMEK）と VPC Service Controls による持ち出し防止（第 8 回）
-
継続的に検知・是正：Security Command Center での可視化と自動検知（第 9 回）
ひとことで言えば、“上位ルール → 共通基盤 → 各プロジェクト” の順に固め、“入口制御 → データ制御 → 監視と是正” を重ねていきます。
このブログシリーズの目標
| 区切り | 範囲 | 説明内容 | セルフチェック |
|---|---|---|---|
| 第 2–3 回 | 組織・IAM | リソース階層（Organization/Folder/Project）、命名規則、グループベース権限 | 個人直付けのロールを撤廃し、グループ経由＋最小権限にできたか |
| 第 4–5 回 | ネットワーク | 受信デフォルト拒否の VPC、Cloud NAT／Private Google Access、Shared VPC 設計 | 直接公開 VM をゼロにし、公開点を LB＋ Cloud Armor に一元化できたか |
| 第 6 回 | ガードレール | Organization Policy（外部 IP 制限、SA キー作成禁止など）、IAM Deny | 危険設定が「物理的に不可能」な状態にできたか |
| 第 7 回 | 可視化・運用 | ログ集約プロジェクト、監査ログの集約、主要アラート（権限変更/予算超過など） | 重大イベントが 5 分以内に通知されるか／ダッシュボードで横断確認できるか |
| 第 8–9 回 | データ & 検知 | CMEK 運用ポリシー、VPC Service Controls のサービス境界、SCC の主要検知有効化 | PII/機密のデータ持ち出し経路が境界で抑止され、異常が自動検出されるか |
表：本ブログシリーズのロードマップ
| 回 | テーマ | 主な決定事項 | x |
|---|---|---|---|
| 2 | Organization | フォルダ構成・命名規則 | 標準階層図、命名規則表 |
| 3 | IAM | 権限設計・付与プロセス | グループ設計、標準ロールセット |
| 4 | VPC/FW | 入口制御・非公開化 | VPC テンプレ、基本 FW ルール |
| 5 | Shared VPC | ネットワーク一元管理 | ホスト/サービス設計書 |
| 6 | Org Policy | 危険操作の抑止 | 必須ポリシー一覧と適用表 |
| 7 | Logging/Monitoring | 可視化・検知 | 集約シンク、ダッシュボード |
| 8 | データ保護 | 暗号化・境界 | CMEK 方針、VPC-SC 境界図 |
| 9 | 検知と是正 | 自動発見・対応 | SCC 主要検知、是正手順 |
実務での進め方
-
準備：Sandbox 用の Organization/Folder/Project を 1 セット用意（本番と同じ命名規則）。
-
IaC 推奨：Terraform で最小構成からコード化（後戻りしない土台の差分管理に効きます）。
-
検証の型：各回の最後に “破壊的テスト” を 1 つ（例：外部 IP 禁止の Org Policy を破れるか？）。
-
運用の型：権限変更・ネットワーク公開・鍵操作・境界逸脱は 必ず アラート化。
-
ドキュメント：各回の成果を「決めたこと／できたこと／できなかったこと」に分け、次回の TODO へ。
決定内容の優先度を表したピラミッド(優先度高)下→上(優先度低)
本回のまとめ
-
先に決めるべきこと：組織階層・命名・権限の原則（戻りをなくす）。
-
先に塞ぐべきこと：公開点の一元化と受信拒否のデフォルト。
-
常に効かせること：Org Policy / IAM Deny のガードレール。
-
見続けること：ログとアラート、SCC による継続的な検知と是正。
次回の 第 2 回 では、Organization（組織）とフォルダ設計、命名規則 を固めていきます。ここを丁寧に作ると、この先の作業がぐっと楽になります。
第９回までどうかよろしくお願いします！
Discussion