クラウドセキュリティの基本｜責任共有モデルをやさしく解説

「クラウドに移行したから、あとはベンダーがセキュリティを守ってくれるはず」——そう思っていませんか。実はこれ、クラウドの情報漏えい事故で最も多い誤解のひとつです。AWSやAzure、GCPは強固なデータセンターを守ってくれますが、あなたが設定したストレージやアクセス権限までは守ってくれません。

この記事で分かること

クラウドのセキュリティは「責任共有モデル」に基づき、プロバイダと利用者で守る範囲が分かれている
IaaS・PaaS・SaaSでも利用者の責任範囲は変わるが、データと権限管理は常に利用者側の責任
IAM（アクセス管理）で「最小権限の原則」を守ることが、設定ミス事故を防ぐ最大の近道

対象読者：AWSやAzureなどのクラウドを使い始めたエンジニア

執筆：ゆるふわセキュリティ編集部　最終更新日：2026年8月13日

クラウドは「借りた分譲マンション」に近い

オンプレミス（自社サーバー）の時代は、建物の警備からサーバーラックの鍵、ネットワークの配線まで、すべて自社で管理していました。守る範囲は広いですが、その分「どこまで自分の責任か」で迷うことは少なかったのです。

クラウドはこれとは根本的に違います。たとえるなら、一戸建てから分譲マンションに引っ越すようなイメージです。エントランスの防犯カメラや建物の耐震性はマンションの管理会社（クラウドプロバイダ）が守ってくれますが、自分の部屋の鍵をかけ忘れたり、合鍵を誰彼構わず配ったりすれば、管理会社は責任を負えません。この「どこからが自分の部屋の中か」を明確にする考え方が、次に説明する責任共有モデルです。

責任共有モデルとは：守る境界線を知る

AWSは自社の公式ドキュメントで、責任共有モデルを「Security of the Cloud（クラウド自体の安全性）」と「Security in the Cloud（クラウドの中身の安全性）」という2つに分けて説明しています¹。前者はAWSの責任、後者は利用者の責任です。この考え方はAzureやGoogle Cloudなど他の主要クラウドでも基本的に共通しています。

🏢

プロバイダの責任範囲（Security of the Cloud）

データセンターの物理的な警備・耐災害性
サーバーやネットワーク機器などのハードウェア
仮想化基盤・ホストOSのセキュリティパッチ
リージョンやアベイラビリティゾーンの管理

🧑‍💻

利用者の責任範囲（Security in the Cloud）

自分が置いたデータの暗号化・分類
IAM（誰が何にアクセスできるか）の設定
ゲストOS・ミドルウェア・アプリの更新
ファイアウォールやセキュリティグループの設定

💡

IaaS・PaaS・SaaSで責任範囲は動く

サービスの抽象度が上がるほど、プロバイダが受け持つ範囲は広がります。仮想サーバーを借りるIaaS（EC2など）ではOSやミドルウェアの管理も利用者の仕事ですが、マネージドなPaaS（RDSなど）ではミドルウェアの管理はプロバイダに移ります。SaaS（Gmailなど）ではアプリ自体の管理は不要になりますが、「データの取り扱い」と「誰にアクセス権を与えるか」は、どのサービス形態でも最後まで利用者の責任として残り続けます。

よくある設定ミス：「公開」のつもりがなくても公開される

クラウドの事故で特に多いのが、ストレージサービス（AWSのS3バケットなど）の公開設定ミスです。デフォルトでは非公開のはずが、設定を1つ変更しただけで誰でもインターネット経由でアクセスできる状態になってしまうことがあります。

⚠️

15%

クラウド設定ミスが情報漏えいの原因になった割合（IBM調べ・2022年版）

🚗

約215万人分

設定ミスで車両情報が閲覧可能になった規模（トヨタ・2023年公表）

⏳

約10年間

公開状態が発覚するまでに経過していた期間

IBM社の調査では、クラウドの設定ミスは情報漏えいの初期侵入経路として全体の15%を占め、1件あたりの平均被害コストは414万ドルにのぼると報告されています²。

⚠️

実際にあった話：トヨタのクラウド設定ミス

2023年、トヨタ自動車は、クラウド環境の誤設定により、コネクテッドサービスを利用する約215万人分の車両位置情報などが、2013年11月から2023年4月まで約10年間にわたりインターネットから閲覧可能な状態になっていたと公表しました³。原因は「クラウド環境の誤設定」と、データの取り扱いルールの周知が不十分だったことでした。大企業であっても、設定の見落とし一つで長期間の情報公開につながることを示す事例です。

こうした事故を防ぐ第一歩は、「デフォルトで公開にしない」「公開設定を変更する前に必ずレビューする」というシンプルなルールを徹底することです。IPA（情報処理推進機構）も、クラウドサービスを利用する際は契約前に責任分界点を確認し、設定を定期的に点検することを推奨しています⁴。

IAMの基礎：「誰が」「何を」できるかを管理する

IAM（アイエーエム（Identity and Access Management））

「誰が」「どのリソースに」「どんな操作を」できるかを管理する仕組みです。ユーザーやアプリケーションごとにアカウント（アイデンティティ）を分け、それぞれに必要な権限だけを割り当てます。IAMの設計が甘いと、1つのアカウントが漏えいしただけで被害が全システムに広がってしまいます。

最小権限の原則（さいしょうけんげんのげんそく（Principle of Least Privilege））

「その人・そのプログラムが業務上どうしても必要な権限だけを与える」という考え方です。AWSのWell-Architected フレームワークでも、セキュリティの柱の実践項目として明記されています⁵。「とりあえず管理者権限を渡しておく」は一見便利ですが、アカウントが乗っ取られたときの被害を最大化してしまう、最も避けたい運用です。

最小権限の原則を守るコツはシンプルです。まず必要最低限の権限だけを与え、あとから「足りない」と言われたら追加する。逆に「念のため広めに」権限を与えるのは、事故のリスクを先に払っておくようなものだと考えてください。

今日からできる実践チェックリスト

クラウドセキュリティ、最初の一歩

🔍

公開範囲を棚卸しする

ストレージやデータベースが意図せず公開になっていないか、設定を一覧で確認する

→

🔑

IAMを最小権限で見直す

管理者権限を持つアカウントを洗い出し、本当に必要かをチェックする

→

🔐

多要素認証を必須にする

特に管理者アカウントはMFAなしでのログインを許可しない設定にする

→

📝

変更ログを記録・監視する

誰がいつ設定を変えたかを追跡できるようにし、異常があれば気づける状態にする

→

🔄

定期的に設定を点検する

一度守っても運用中に設定は崩れていく。定期チェックをルーチン化する

まとめ

クラウドのセキュリティは「責任共有モデル」に基づき、プロバイダと利用者で守る範囲が明確に分かれている
プロバイダは物理インフラや基盤を守るが、データの中身とアクセス権限の管理は利用者の責任
IaaS・PaaS・SaaSとサービスの抽象度が上がっても、データと権限管理の責任は利用者から離れない
ストレージの公開設定ミスは、大企業でも長期間発覚しないほど身近なリスクである
IAMで「最小権限の原則」を徹底することが、設定ミス事故を防ぐ最も基本的で効果的な対策

もう少し詳しく（背景）

責任共有モデルという考え方が広まった背景には、クラウド普及初期に「クラウドは安全なはずだから自分たちで対策しなくていい」という誤解が原因の事故が相次いだ経緯があります。AWSやMicrosoft Azureは、この誤解を解消するために、公式ドキュメントで責任範囲を図解して明示するようになりました¹。IPAも中小企業向けに、契約前に責任分界点を確認することの重要性を繰り返し呼びかけています⁴。

権限管理の考え方をさらに理解したい方は、常に検証を要求するゼロトラストの考え方や、ログイン時の防御を強化する多要素認証（MFA）の記事もあわせて読むと理解が深まります。クラウド上のデータそのものを守る技術については暗号化の基本、認証情報の安全な管理についてはPythonでのシークレット管理も参考になります。万が一設定ミスによる漏えいが起きてしまった場合の初動対応はインシデントレスポンスの記事で解説しています。

参考資料・出典

AWS Shared Responsibility Model（責任共有モデル）AWS公式：Security of the Cloud / Security in the Cloudの境界線を解説
IBM Cost of a Data Breach Report 2022 ハイライト（Cloud Security Alliance）クラウド設定ミスが情報漏えいの初期侵入経路の15%を占めるとする調査結果
クラウド環境の誤設定によるお客様情報の漏洩可能性に関するお詫びとお知らせについてトヨタ自動車公式発表：約215万人分の車両情報が約10年間公開状態だった事例
中小企業のためのクラウドサービス安全利用の手引き（2024年7月版）IPA公式：責任分界点の確認や設定点検の重要性を解説
SEC03-BP02 最小特権のアクセスを付与します（AWS Well-Architected フレームワーク）AWS公式：最小権限の原則の実践方法を解説

ゆるふわポータルでは、一次情報・公的資料にもとづき、専門用語をできるだけやさしく翻訳することを心がけています。内容に誤りや古い情報がある場合は、お問い合わせからご連絡ください。