クラウドセキュリティとは？責任共有モデルから始める設計の全体像

「クラウドはセキュリティが強いから安全でしょ」——この一言を聞いたとき、どう答えますか？

クラウドプロバイダーは高度なセキュリティ基盤を提供しています。しかしそれは「クラウドを使えば自動的に安全になる」ことを意味しません。クラウド上で何をどう設定するか・誰がアクセスできるか・何を監視するか——これらはすべて利用者側の設計と運用にかかっています。

クラウドセキュリティで事故が起きる現場の多くは、「クラウドだから大丈夫」という思い込みが原因です。ストレージが誤って公開設定になっていた・管理者権限が広く付与されたまま放置されていた・ログが取得されておらず侵害に気づけなかった——これらはすべて設計と運用の問題です。

この記事では、クラウドセキュリティの全体像——責任共有モデル・4つの領域・ゼロトラスト・多層防御——を若手エンジニア向けに解説します。個別のAzureサービスや設定の詳細は各スポーク記事で深掘りします。

※この記事ではAzureを例に解説しますが、責任共有モデル・ゼロトラスト・多層防御の考え方はクラウドプロバイダーを問わず共通する概念です。

クラウドにしたら「自動的に安全」は大きな誤解

オンプレミス環境では、物理サーバからOSまですべてを自社で管理します。クラウドに移行すると、その一部をクラウドプロバイダーが管理します。しかし「一部をプロバイダーが管理する」ことは「すべてが安全になる」ことではありません。

実際に起きているクラウドのセキュリティ事故の多くは、クラウドプロバイダー側の問題ではなく利用者側の設定ミス・設計の甘さが原因です。

• S3バケットやAzure Blob Storageの公開設定ミスによる情報漏洩
• 過剰な権限を持つIAMロールの放置
• MFAが設定されていない管理者アカウントの侵害
• 監査ログが無効のままインシデントに気づけない

「クラウドプロバイダーが守ってくれる範囲」と「自分たちが守らなければいけない範囲」を正しく理解することが、クラウドセキュリティの出発点です。

参考：クラウドセキュリティのベストプラクティス | Microsoft Learn

責任共有モデル——どこからが自分の責任か

IaaS・PaaS・SaaSで変わる責任の範囲

責任共有モデル（Shared Responsibility Model） クラウドサービスのセキュリティ責任をクラウドプロバイダーと利用者で分担する考え方。サービス形態（IaaS・PaaS・SaaS）によって責任の境界が変わる。

クラウドセキュリティを理解する上で最初に押さえるべき概念が責任共有モデルです。

（例）Azureにおける責任共有モデル

参考：Azure の責任共有 | Microsoft Learn

クラウドセキュリティを構成する4つの領域

クラウドセキュリティは大きく4つの領域で構成されます。この4つを体系的に設計することで「守れるクラウド環境」が実現します。

IDとアクセス管理——誰が使えるかを制御する

クラウドセキュリティで最も重要な領域です。「誰が・何に・どこまでアクセスできるか」を正しく設計することが、他のすべての設計の前提になります。

IAM（Identity and Access Management：IDおよびアクセス管理） ユーザー・グループ・サービスプリンシパルに対して、クラウドリソースへのアクセス権を管理する仕組み。最小権限の原則に基づいて設計することが基本。

最小権限の原則・RBAC・MFA・PIM——これらはすべてIDとアクセス管理の設計要素です。詳しくは以下の記事で解説しています。

• 「IAMとは？認証と認可の違いから学ぶアクセス管理の基本」
• 「最小権限の原則とは？実務での考え方と設計例」
• 「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」
• 「MFAとは？多要素認証の仕組みと実務での導入・運用ガイド」
• 「PIMとは？Azure特権アクセス管理の実務ガイド」

ネットワークセキュリティ——境界を設計する

クラウド環境でも「どの通信を許可し・どの通信を遮断するか」の設計は不可欠です。オンプレと異なるのは、物理的な境界ではなく論理的な境界（VNet・NSG・ファイアウォール）で設計する点です。

VNet（Virtual Network：仮想ネットワーク） Azure上に構築する論理的なネットワーク。VNet内のリソースは同一ネットワーク内として通信でき、外部との通信はNSGやファイアウォールで制御する。

NSG（Network Security Group：ネットワークセキュリティグループ） AzureのVNet内のトラフィックを制御するファイアウォールルール。インバウンド・アウトバウンドの通信をIPアドレス・ポート・プロトコルで許可・拒否する。

Azureのネットワークセキュリティ設計の詳細については「Azureネットワークセキュリティ設計入門｜VNet・NSG・ファイアウォールの考え方」（公開予定）で解説します。

データ保護——何を守るかを定義する

クラウド上のデータは「保存時」と「転送時」の両方で保護が必要です。

保存時の暗号化（Encryption at Rest） ストレージやデータベースに保存されているデータを暗号化する仕組み。Azureでは多くのサービスでデフォルト有効。暗号化キーの管理（Azure Key Vault等）も設計に含める。

転送時の暗号化（Encryption in Transit） ネットワーク上を流れるデータを暗号化する仕組み。TLS/HTTPSによる通信暗号化が基本。HTTPなど非暗号化通信を禁止する設定も重要。

データ保護の設計で見落とされやすいのは「どのデータがどこにあるか」の把握です。クラウド上のデータの所在を把握せずに保護設計はできません。

監視と検知——異常を見逃さない仕組みを作る

設計・設定が正しくても「何が起きているかを見える状態にする」監視がなければ、インシデントに気づけません。

Azure Monitor Azureのリソースからメトリクス・ログを収集・分析する統合監視サービス。アラートの設定・ダッシュボードの作成・Log Analyticsとの連携が可能。

Microsoft Defender for Cloud Azureリソースのセキュリティ状態を評価・監視するサービス。セキュリティスコアの算出・推奨事項の提示・脅威の検知を行う。

監視設計については「Azure Defender for Cloudとは？」（公開予定）で詳しく解説します。クラウド環境でのインシデント発生時の対応については「セキュリティインシデント対応入門」も合わせてご覧ください。

ゼロトラストという考え方——「信頼しない」設計の基本

ゼロトラスト（Zero Trust） 「すべてのアクセスは信頼しない」を前提とし、ユーザー・デバイス・ネットワークの場所によらず毎回認証・認可を行うセキュリティモデル。「社内ネットワークは安全」という従来の境界防御の考え方を覆す。

従来のセキュリティモデルは「社内ネットワークの内側は安全」という前提でした。しかしクラウドとリモートワークが普及した現代では、「どこから接続しているか」ではなく「誰が・何の端末で・何にアクセスしようとしているか」を都度検証することが必要です。

ゼロトラストの3つの原則は以下の通りです。

① 明示的に検証する ユーザー・デバイス・場所・サービスのすべての情報を使って認証・認可を行います。条件付きアクセスポリシーはこの原則の実装です。

② 最小権限アクセスを使用する 必要最低限の権限のみを付与します。JIT（Just-In-Time）アクセスで常時特権を持たせない設計がこれに相当します。JITの実装については「PIMとは？」を参照してください。

③ 侵害を想定する 侵害されることを前提に設計します。被害を最小化するためのネットワーク分離・ログ監視・インシデント対応計画が必要です。

ゼロトラストのAzureでの実装パターンについては「ゼロトラストとは？Azureでの実装パターン」（公開予定）で詳しく解説します。

参考：Microsoft ゼロトラストのガイダンス | Microsoft Learn

多層防御——1つの対策に頼らない設計思想

多層防御（Defense in Depth） 単一の対策に頼らず、複数のセキュリティ層を重ねることで、1つの対策が突破されても次の層で食い止める設計思想。物理・ネットワーク・ID・アプリ・データの各層で対策を講じる。

「MFAを設定したから大丈夫」「ファイアウォールがあるから大丈夫」——1つの対策に頼る設計は危険です。攻撃者は複数の手口を組み合わせて侵入を試みます。

Azureでの多層防御の例を整理すると以下の通りです。

AD環境での多層防御の実例については「AD攻撃手法と要塞化」で解説しています。

参考：多層防御について説明する | Microsoft Learn

このブログのクラウドセキュリティクラスターで学べること

このカテゴリーでは、クラウドセキュリティの全体像を踏まえた上で、Azureの具体的なサービスと設計パターンを順次解説していきます。

IDとアクセス管理については「ID管理・認証設計カテゴリー」の記事群で詳しく解説しています。

クラウドセキュリティ設計チェックリスト（基本編）

責任範囲の把握

• 使用しているサービス形態（IaaS・PaaS・SaaS）ごとの責任範囲を把握している
• 利用者側が管理すべき設定項目を洗い出している

IDとアクセス管理

• 全管理者アカウントにMFAを設定している
• 最小権限の原則に基づいてロールを設計している
• 不要なアカウント・権限を定期的に棚卸ししている
• PIMでJITアクセスを実装している（または計画している）

ネットワーク

• VNetでリソースを論理分離している
• NSGで不要なポート・通信を遮断している
• 管理用ポート（RDP・SSH）をインターネットに直接公開していない

データ保護

• ストレージの公開設定を確認している（意図しない公開がないか）
• 重要データの暗号化設定を確認している
• バックアップが取得・復元できる状態になっているか確認している

監視

• 監査ログを有効化している
• Defender for Cloudのセキュリティスコアを確認している
• 重要なアラートの通知設定をしている

まとめ——クラウドセキュリティは「設定するもの」ではなく「設計するもの」

クラウドセキュリティの本質は「プロバイダーが守ってくれる範囲と自分たちが守る範囲を正しく理解し、自分たちの責任範囲を設計すること」です。

責任共有モデルを理解し・4つの領域を体系的に設計し・ゼロトラストの考え方で「信頼しない」前提に立ち・多層防御で1つの対策に頼らない——この4つの軸がクラウドセキュリティ設計の土台です。

今日確認すべきことは1つです。現在使用しているAzureリソースで「意図せず公開されているストレージやリソース」がないかをDefender for Cloudのセキュリティスコアで確認してください。スコアと推奨事項を見るだけで、自分たちの設計の穴が可視化されます。

あわせてご覧ください

• IAMとは？認証と認可の違いから学ぶアクセス管理の基本
• 最小権限の原則とは？実務での考え方と設計例
• RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド
• PIMとは？Azure特権アクセス管理の実務ガイド
• セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方
• AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る