セキュリティの考え方 - クラウドセキュリティの考え方

クラウドセキュリティの出発点は、クラウド事業者とユーザーのどこまでが誰の責任かを正しく理解することです。

AWS / Azure / GCP いずれも「Security of the Cloud（クラウド基盤の安全性）」はクラウド事業者、「Security in the Cloud（その上に載せるワークロードの安全性）」はユーザーの責任、という大枠は共通しています。

サービス形態（IaaS / PaaS / SaaS）によって境界が変わる点に注意が必要です。

責任範囲	IaaS（EC2 / Compute Engine / VM）	PaaS（Lambda / Cloud Run / App Service）	SaaS（M365 / Google Workspace）
データ	ユーザー	ユーザー	ユーザー
アクセス制御・ID 管理	ユーザー	ユーザー	ユーザー
アプリケーションコード	ユーザー	ユーザー	事業者
OS / ミドルウェアのパッチ	ユーザー	事業者	事業者
ネットワーク設定（SG / NSG / FW）	ユーザー	共有	事業者
物理インフラ・ハイパーバイザー	事業者	事業者	事業者

3 大クラウド事業者はいずれも同じ考え方のモデルを公開しています。

クラウド	モデル名	公式ドキュメント名
AWS	Shared Responsibility Model	「責任共有モデル」
Azure	Shared Responsibility in the Cloud	「クラウドにおける責任共有」
Google Cloud	Shared Responsibility / Shared Fate	「共有責任」「Shared Fate（運命共有）」

よくある誤解: 「マネージドサービスだから事業者が全部守ってくれる」は誤り。

データ・ID・設定ミスはどのサービス形態でも常にユーザー責任であり、実際のインシデントの大半はこの領域で起きています。

クラウドセキュリティを設計するときに押さえるべき 5 つの原則を整理します。

原則	意味	クラウドでの実装例
1. 最小権限（Least Privilege）	必要最小限の権限のみを付与する	IAM ロール/ポリシーを細分化。ワイルドカード * やフル管理ポリシーを避ける。IAM Access Analyzer で未使用権限を検出
2. 多層防御（Defense in Depth）	単一の防御に頼らず複数の層で守る	ID（MFA） + ネットワーク（SG/NSG） + アプリ（WAF） + データ（暗号化）を重ねる
3. ゼロトラスト（Zero Trust）	ネットワーク位置に関係なく常に認証・認可する	VPN に頼らず、全リクエストを ID ベースで検証（IAM Identity Center / Entra ID Conditional Access / BeyondCorp / IAP）
4. ガードレール（Guardrails）	事前に禁止事項を強制し「逸脱できない設計」にする	AWS SCP / Azure Policy / GCP Organization Policy でリージョン制限・公開 S3 禁止などを組織全体に適用
5. 監査可能性（Auditability）	誰が何をしたかを常に追跡できる状態にする	CloudTrail / Azure Activity Log / Cloud Audit Logs を全アカウントで有効化し、改ざん不可ストレージに長期保管

これらは互いに補強し合う点が重要です。

最小権限だけでは人的ミスをゼロにできないためガードレールで強制し、それでもすり抜けた事象を監査ログで発見する、という具合に多層で組み合わせます。

クラウドでは「悪いことが起きてから対応する」のではなく、「そもそも悪いことができない設計」＝ガードレール を組織全体に敷くのが基本です。

3 大クラウドはそれぞれ組織レベルのポリシーエンジンを提供しています。

クラウド	ポリシーエンジン	代表的な制御例
AWS	Service Control Policies（SCP） / AWS Config / AWS Control Tower	リージョン制限、ルートユーザーのアクセスキー作成禁止、CloudTrail 無効化禁止
Azure	Azure Policy / Microsoft Defender for Cloud	パブリック IP の割当禁止、暗号化必須、許可された SKU のみ作成可
Google Cloud	Organization Policy / Security Command Center	外部 IP 禁止、ドメイン制限共有、VPC Service Controls による境界化

コントロールは 3 分類で考えます。

予防的 → 発見的 → 修復的の順に対応コストが上がるので、できる限り上流（Preventive）で止めるのが望ましいです。

分類	目的	AWS 例	Azure 例	GCP 例
Preventive（予防的）	危険な操作を最初から禁止	SCP、IAM Permission Boundary、S3 Block Public Access	Azure Policy「Deny」、RBAC	Organization Policy、VPC Service Controls
Detective（発見的）	設定ミスや異常を検出する	AWS Config Rules、GuardDuty、Security Hub	Defender for Cloud、Azure Monitor、Sentinel	Security Command Center、Cloud Logging、Cloud Audit Logs
Responsive（自動修復的）	検知後に自動で是正する	EventBridge + Lambda、Security Hub 自動修復	Azure Policy「DeployIfNotExists」、Logic Apps	Cloud Functions + Pub/Sub、Security Health Analytics 連携

実務ポイント: 新規ワークロードではまず Preventive（SCP / Policy）で逸脱不可にし、すでに動いている既存環境には Detective から導入して影響範囲を把握してから段階的に締めていくのが現実的です。

クラウド環境を立ち上げる前に決めておくべき項目をチェックリスト化します。

後から変えるのが特に面倒なもの（アカウント分割・ネットワーク CIDR・鍵管理）を先に決めるのがコツです。

領域	決めるべきこと	代表的な選択肢
アカウント戦略	本番/検証/サンドボックスをどう分けるか	AWS Organizations（OU 単位）、Azure Management Groups、GCP Folder。ランディングゾーン雛形の採用
ID / 認証	誰がどうログインするか	IdP 集約（Entra ID / Okta / Google Workspace）、IAM Identity Center 経由の SSO、MFA 必須化
ネットワーク分離	VPC / VNet の設計	CIDR 割当、Transit Gateway / Hub-Spoke、Private Link / PrivateEndpoint、インターネット出口の集約
ログ保管	何をどこにどれだけ保管するか	CloudTrail / Activity Log / Audit Logs の集約先アカウント、改ざん防止（Object Lock）、保持期間
鍵管理	誰が鍵を管理するか	KMS / Key Vault / Cloud KMS の CMK、BYOK の要否、ローテーション間隔
インシデント対応	誰がいつ何をするか	連絡体制、権限エスカレーション手順、フォレンジック用の読み取り専用ロールの事前準備
コスト異常検知	予算超過を誰が検知するか	Budgets / Cost Alerts（不正利用・暗号マイニングの早期検知にも有効）

アンチパターン: 「1 アカウント/1 サブスクリプションに全部入れる」「開発と本番の権限境界がない」「ログを各アカウントに分散したまま集約しない」は、後から矯正するとプロジェクト 1 本分の工数が飛ぶので最初に避けておきたい構成です。