レッスン7：クラウドのセキュリティ——責任共有モデルと設計の発想

このレッスンで学ぶこと

責任共有モデル（Shared Responsibility Model）を理解する
IaaS／PaaS／SaaS で利用者と事業者の責任範囲がどう変わるかを把握する
IAM（Identity and Access Management）と最小権限の原則を整理する
鍵管理（KMS）の役割を理解する
VPC とネットワーク分離の発想を整理する
ログと監査の必要性を把握する
クラウド時代のセキュリティ運用の発想を持つ

前のレッスンでは、クラウドのコストとガバナンス、FinOps の発想を整理しました。今回のレッスンでは、セキュリティを扱います。クラウドは「乗せれば全部事業者が守ってくれる」わけでも「危ないからオンプレが安全」でもありません。クラウドのセキュリティを語る出発点は、「責任共有モデル」という発想です。本レッスンでは、IAM・KMS・VPC・ログといった構成要素を概念中心に整理し、特定の攻撃手法やインシデント対応の詳細には踏み込みません。

責任共有モデル

責任共有モデル（Shared Responsibility Model）は、クラウドのセキュリティを「事業者が守る範囲」と「利用者が守る範囲」に明確に分ける発想です。AWS が早くから明文化したのを契機に、Azure や Google Cloud も同様の枠組みを公開し、現在では業界標準の整理になっています。

「クラウドの〜」と「クラウドの中の〜」

責任共有モデルの本質的な表現が、AWS の用いる「Security OF the cloud」と「Security IN the cloud」という対比です。

Security OF the cloud（クラウドの〜のセキュリティ）：クラウド基盤そのもののセキュリティ → 事業者の責任
Security IN the cloud（クラウドの中のセキュリティ）：クラウド上で利用者が動かすシステムのセキュリティ → 利用者の責任

「クラウドそのもの」と「クラウドの上に乗せたもの」で責任の所在を分けて捉える、という整理です。

各階層での責任分界

責任分界の線は、IaaS／PaaS／SaaS で動きます。

flowchart TD
  subgraph IaaS["IaaS の責任分界"]
    I1[アプリ・データ・設定 利用者]
    I2[OS・ミドルウェア 利用者]
    I3[仮想化基盤・物理 事業者]
  end
  subgraph PaaS["PaaS の責任分界"]
    P1[アプリ・データ・設定 利用者]
    P2[OS・ミドルウェア 事業者]
    P3[仮想化基盤・物理 事業者]
  end
  subgraph SaaS["SaaS の責任分界"]
    A1[データ・利用者管理 利用者]
    A2[アプリ・OS・ミドルウェア 事業者]
    A3[仮想化基盤・物理 事業者]
  end

利用者の責任は、SaaS でも「データ・利用者管理」として必ず残ります。「SaaS だから事業者がすべて守ってくれる」は誤解で、誰がどのデータにアクセスできるか、退職者のアカウントを削除したか、設定を間違えて公開していないか、これらは利用者が担います。

よくある誤解

「クラウドに乗せたら事業者が責任を持つ」→ 半分しか正しくない
「クラウドは危ない」→ 事業者の責任範囲だけを見れば、自社の物理設備より高度に守られていることが多い
「自社のセキュリティ責任は減る」→ むしろ「利用者が見える範囲」と「責任の所在」を明確にする必要が増える

💡 ポイント 責任共有モデルの図は、契約の前段で必ず確認すべきものです。「うちはどこまでが責任か」を社内で言語化できないまま導入すると、インシデント時の責任の押し付け合いになります。

IAM——「誰が何にアクセスできるか」

IAM（Identity and Access Management：アイデンティティとアクセス管理）は、クラウドで「誰が」「何に」「どのような操作を」できるかを管理する仕組みです。

各社の IAM サービス

AWS：AWS IAM、AWS IAM Identity Center（旧 AWS SSO）
Azure：Microsoft Entra ID（旧 Azure Active Directory）
Google Cloud：Cloud IAM、Identity Platform

構成要素

用語	意味
ユーザー（user）	個人を識別する単位
グループ（group）	ユーザーをまとめる単位
ロール（role）	一時的に与える権限のセット
ポリシー（policy）	「何ができるか」「何ができないか」を定義する規則
サービスアカウント（service account）	アプリやスクリプトに与える非人間用のアカウント

「ユーザーにポリシーを直接付ける」「ユーザーをグループに入れてグループにポリシーを付ける」「一時的にロールを引き受ける」など、複数の組み合わせ方ができます。

最小権限の原則

セキュリティ設計の古典的な原則として、「最小権限の原則（principle of least privilege）」があります。「業務に必要な最小限の権限だけを与える」という発想です。クラウドの IAM 設計は、この原則を実践するためのものです。

「とりあえず全権限を与えてあとで絞る」が、最も避けるべき設計です。実際には絞られないまま放置され、退職者のアカウントが乗っ取られて全システムが侵害される、というインシデントが繰り返し起きてきました。

多要素認証（MFA）の必須化

クラウドコンソール（管理画面）への管理者ログインには、多要素認証（MFA：Multi-Factor Authentication）を必須化するのが標準的なベストプラクティスです。パスワード単体では、フィッシングや漏洩リストでの侵害リスクが高すぎます。

⚠️ 注意 「ルートアカウント（最高権限のアカウント）」を日常的に使うのは大きなリスクです。設定後すぐに MFA を有効化し、日常作業は別の限定権限ユーザーで行うのが定石です。

鍵管理——KMS の役割

データを暗号化するには「鍵」が必要です。鍵を安全に保管・管理する仕組みが、鍵管理サービス（KMS：Key Management Service）です。

各社の鍵管理サービス

AWS：AWS KMS、AWS CloudHSM
Azure：Azure Key Vault、Azure Dedicated HSM
Google Cloud：Cloud KMS、Cloud HSM

鍵を扱う発想

鍵をアプリのコードや設定ファイルに直書きしない（GitHub に流出する事故が多発している）
鍵を KMS に保管し、必要なときに API 経由で取得する
鍵の利用ログを記録する（誰が・いつ・どのような操作で鍵を使ったか）
鍵をローテーション（定期的に更新）する
鍵自体を、より上位の「マスター鍵」で守る階層構造を採る

KMS は「データを暗号化する装置」ではなく「鍵を守る装置」です。データの暗号化処理そのものは、各クラウドサービス（ストレージ・データベース）が KMS の鍵を使って自動で行う構成が一般的です。

保管時・通信時の暗号化

保管時（at rest）：ディスクに保存されたデータの暗号化。ストレージサービスでデフォルトで有効化されていることが多い
通信時（in transit）：ネットワーク上を流れるデータの暗号化。TLS（Transport Layer Security）が標準

「保管時と通信時の両方を暗号化する」が現代のベストプラクティスです。

VPC とネットワーク分離

レッスン 4 で触れた VPC（Virtual Private Cloud）は、セキュリティの観点でも中心的な役割を果たします。

サブネットの設計

VPC の中にサブネット（subnet）を作って、用途別にネットワーク境界を分けます。

公開サブネット（public subnet）：インターネットからの受け口（Web サーバー・ロードバランサーなど）
内部サブネット（private subnet）：業務ロジック層（アプリケーションサーバー）
データベースサブネット：データベース層（外部から直接アクセスできない）

「層」を分けることで、Web 層が侵害されても、データベース層へ直接到達できない設計になります。

セキュリティグループとファイアウォール

仮想マシンやほかのリソースには、「どこからの・どんな通信を許可するか」を設定する仕組みがあります。

AWS：セキュリティグループ、ネットワーク ACL
Azure：ネットワークセキュリティグループ（NSG）
Google Cloud：ファイアウォールルール

「特定の IP アドレス範囲からの SSH（管理用通信）だけを許可」「インターネット全体からの HTTPS 通信を許可」のように、細かく制御できます。

ゼロトラストの発想

伝統的なネットワーク防御は「社内ネットワーク内は信頼、外は不信」という境界防御の発想でした。クラウド時代には、社内・社外の境界が曖昧になります。テレワーク、SaaS の利用、複数クラウドの併用が日常になり、「どこにあっても信頼しない」という発想が必要になりました。これがゼロトラスト（zero trust）です。

NIST が SP 800-207（2020 年）で公式定義を出しています。具体的には次の発想を採ります。

「社内ネットワーク内だから安全」を前提にしない
通信ごとに認証・認可を確認する
最小権限を徹底する
通信は常時暗号化する
異常な振る舞いを検知する

ゼロトラストはクラウド固有の発想ではありませんが、クラウド時代に強く後押しされた発想です。本コースでは「概要」までを扱います。

📝 補足 ゼロトラストの詳細な設計（アクセスプロキシ・マイクロセグメンテーション・継続的認可など）は、別の専門書を参照してください。本コースは「クラウド時代のネットワーク設計の発想転換」として概要のみ触れます。

ログと監査

クラウドでは、「誰がいつ何を操作したか」のログ取得と監査が、運用と説明責任の両面で重要です。

各社のログサービス

種類	AWS	Azure	Google Cloud
API 操作ログ	AWS CloudTrail	Azure Activity Log	Cloud Audit Logs
アプリ・OS ログ集約	Amazon CloudWatch Logs	Azure Monitor Logs	Cloud Logging
メトリクス	Amazon CloudWatch	Azure Monitor	Cloud Monitoring

ログをどう活用するか

操作監査：誰がいつ何を変更したか、説明責任を果たすため
障害分析：障害発生時の原因究明
セキュリティ分析：攻撃の兆候を検知する
コンプライアンス対応：規制対応・監査対応の証跡

ログは「取りっぱなし」では役に立ちません。必要なログを必要な期間保管し、検索可能にしておくのが運用の中核です。

SIEM と SOAR

大規模な組織では、ログを集約して横断的に分析する SIEM（Security Information and Event Management）、対応を自動化する SOAR（Security Orchestration, Automation, and Response）を導入します。詳細は専門領域に踏み込むため、本コースでは名称の紹介にとどめます。

クラウド時代のセキュリティ運用の発想

クラウドのセキュリティ運用には、オンプレ時代とは異なる発想がいくつかあります。

1. 設定ミス（misconfiguration）が主な脅威源

クラウドのインシデントの多くは、外部からの高度な攻撃ではなく、利用者側の設定ミスから始まります。「公開設定のオブジェクトストレージに機密データを置く」「過剰な権限を与えたまま放置」など、ガードレールと自動チェックで防ぐ仕組みが必要です。

各社にはセキュリティ評価ツールがあります（AWS Security Hub、Azure Defender for Cloud、Google Security Command Center）。これらは「設定ミスを自動で検出する」発想に基づきます。

2. 攻撃手法は本コースの守備範囲外

フィッシング、マルウェア、ランサムウェア、ソーシャルエンジニアリング、ビジネスメール詐欺（BEC）、DDoS など、攻撃手法の詳細は本コースでは扱いません。「クラウド側で何を設計するか」「責任分界はどこにあるか」を中心に整理しています。攻撃手法と全社員の防御リテラシーは、別の専門書・コースを参照してください。

3. 「セキュリティはコスト」から「セキュリティは設計」へ

オンプレ時代、セキュリティは「事後で足す」発想が主流でした。クラウド時代は、最初から設計に組み込まないと、後から修正するコストが高くなります。「Shift Left（左にシフト）」「Security by Design（設計段階でのセキュリティ）」と呼ばれる発想です。

4. 認証情報の漏洩を最大の脅威に挙げる

API キー、シークレットキー、パスワードのソースコードへの直書きや、設定ファイルでの誤コミットによる漏洩が、クラウド時代のインシデントの代表例です。GitHub などにキーが漏れると、攻撃者が数分以内にビットコイン採掘のために大量のサーバーを起動し、月額数百万円の請求が来る例があります。Secrets Manager（AWS）、Key Vault（Azure）、Secret Manager（Google Cloud）といった専用サービスでキーを管理し、コードに直書きしないのが鉄則です。

💡 ポイント 「セキュリティ製品を買えば守られる」は誤解です。クラウドのセキュリティは「設定・運用・教育・設計」の組み合わせで成り立ちます。製品はその一部の補助にすぎません。

講師の現場メモ：「金融機関のレギュレーション対応」

私（山下）が外資系クラウド事業者にいた頃、大手金融機関のクラウド移行プロジェクトを担当しました。金融業界は規制が厳しく、責任共有モデルの理解と実装が決定的に重要でした。

経営層は当初、「全部クラウドに乗せれば事業者が守ってくれる」と思っていました。私と金融機関の情報セキュリティ部の方とで、半年かけて次の作業を進めました。

責任共有モデルを業務システムごとに 1 枚の図にする
規制要件（PCI DSS、FISC 安全対策基準）に対する責任分界を明文化する
鍵管理ポリシーを策定（鍵は自社管理、データ暗号化は事業者サービスで自動化）
全リソースに IAM ポリシーで最小権限を設計
セキュリティ評価ツールで自動チェック、CSPM（Cloud Security Posture Management）を導入
ログを 7 年間保管できる体制を構築
定期的な内部監査と外部監査の対応フローを整備

半年後、金融庁の監査が入ったとき、責任分界の文書とログがそのまま提示できました。監査官から「これだけ整理されているなら問題ない」と評価されました。経営層は「クラウドに乗せたから安全」ではなく「設計と運用で守られている」を理解してくれました。

このときに痛感したのは、責任共有モデルは「契約上の押し付け合い」のためではなく、「全社員が責任の所在を理解して動くための地図」だ、ということです。本コースで責任共有モデルを軸に据えるのは、この地図を社内で共有する語彙を、皆さんにも持ち帰っていただきたいからです。

まとめ

このレッスンでは、以下のことを学びました。

責任共有モデル：クラウド基盤は事業者の責任、クラウド上のシステムは利用者の責任
「Security OF the cloud」と「Security IN the cloud」の対比
責任分界線は IaaS／PaaS／SaaS で動く。SaaS でも「データ・利用者管理」は利用者の責任
IAM（AWS IAM、Microsoft Entra ID、Cloud IAM）で「誰が何にアクセスできるか」を管理
最小権限の原則：業務に必要な最小限の権限だけを与える
管理者の MFA 必須化、ルートアカウントの日常使用回避が定石
KMS（鍵管理サービス）は「鍵を守る装置」、データ暗号化は各サービスが KMS の鍵で自動実施
保管時（at rest）・通信時（in transit）の両方で暗号化するのが現代のベストプラクティス
VPC とサブネットで「層」を分け、Web 層からデータベース層への直接到達を防ぐ
ゼロトラスト：境界防御から「どこにあっても信頼しない」への発想転換（NIST SP 800-207）
各社のログサービス（CloudTrail、Activity Log、Cloud Audit Logs など）で API 操作を記録
クラウドのインシデントの多くは外部攻撃ではなく設定ミス。自動チェックが鍵
認証情報の漏洩が代表的な脅威。Secrets Manager・Key Vault・Secret Manager でキー管理
攻撃手法の詳細は本コースの守備範囲外。別の専門書・コースを参照

次のレッスンでは、クラウド移行の選択肢（7R）、ハイブリッド・マルチクラウドの現実、AI エージェント実行環境、SBOM・PQC、修了後の学習方向を案内します。

確認クイズ

このレッスンの理解度をチェックしましょう。