最終更新：2026年10月1日（メーカー公式資料などの一次情報に基づき事実関係を修正）
～ あなたは「鍵の開いた貸金庫」を使っているかもしれない ～
「サーバーをオンプレミスからAWSやMicrosoft 365に移行しました。これでセキュリティはベンダー任せにできるので安心です」
もしあなたがそう思っているなら、その認識は致命的です。
クラウドへの移行は、セキュリティリスクを「なくす」ことではありません。「変化させる」ことです。
例えるなら、クラウドベンダーは「世界一堅牢な銀行の貸金庫（インフラ）」を提供してくれます。彼らは建物の警備や耐震設備には命をかけています。
しかし、「貸金庫の鍵をかけること」と「誰に合鍵を渡すか」は、借り主であるあなたの責任です。
もしあなたが貸金庫の扉を開けっ放しにして帰ったら？ 中身が盗まれても、銀行は補償してくれません。
本稿では、クラウドセキュリティ事故の原因になりやすい「設定ミス」の正体と、それを防ぐための「責任共有モデル」および自動診断ツール（CSPM/SSPM）について解説します。
ほかの予防策もまとめて確認したい方は、中小企業のランサムウェア対策チェックリストをご覧ください。
1. クラウドの事故は「設定ミス」からも起きる
ハッカーは「ハッキング」すらしていないこともある
「クラウドからの情報漏洩」には、高度なサイバー攻撃ではなく、設定の不備から起きるものもあります。例えば、次のような設定ミスです。
- AWS:
S3バケット（ストレージ）の公開設定が「Public（全世界公開）」のまま放置されている。 - Microsoft 365:
SharePointやOneDriveの共有リンク設定が「リンクを知っている全員（匿名アクセス可）」になっており、リンクが外部に転送・掲載されると、誰でもサインインなしで閲覧できてしまう。
こうした例は、システムのバグではなく、単純な設定ミス（ヒューマンエラー）から起こりえます。この場合、攻撃者は鍵のかかっていないドアを探してノブを回すだけで済んでしまいます。
2. 「責任共有モデル」の境界線を知る
ベンダーが守る範囲、あなたが守る範囲
この悲劇を防ぐには、AWSやMicrosoftが提唱する「責任共有モデル（Shared Responsibility Model）」を正しく理解する必要があります（Microsoftの説明はクラウドにおける共有責任）。
- ベンダーの責任（AWSの表現では Security OF the Cloud）:
- データセンターの物理セキュリティ、ハードウェア、ホストOS、ネットワーク基盤。
- 「クラウドサービスそのもの」を守る責任。
- ユーザーの責任（AWSの表現では Security IN the Cloud）:
- 保存するデータ、ID管理、アクセス権限設定。IaaSの場合は、OSのパッチやファイアウォール設定も含みます。
- 「クラウドの使い方」を守る責任。
どんなにベンダーが堅牢な城壁を築いても、あなたが「城門を開放する設定」にしていれば、誰も侵入を防げません。ID管理（Vol.4）も重要ですが、それ以前に「誰でもアクセス可能」になっていたら、ID認証すら求められないのです。
3. 手動確認は無理ゲー：「CSPM」と「SSPM」の自動化
設定項目は膨大、機能追加も続く
「じゃあ設定を確認しよう」と思っても、AWSやM365の設定項目は膨大で、しかも機能追加で増え続けます。これを人間がExcelのチェックシートで漏れなく管理し続けるのは、現実的ではありません。
そこで必要になるのが、設定診断を自動化するツールです。
- CSPM (Cloud Security Posture Management):
- 主にIaaS (AWS/Azure/GCP) の設定を監視します。「S3が公開されている」「セキュリティグループでSSH(22)が全開放されている」などを自動検知します。
- SSPM (SaaS Security Posture Management):
- 主にSaaS (M365/Slack/Salesforce) の設定を監視します。「外部共有設定が緩すぎる」「多要素認証が無効な管理者がいる」といった設定の不備を検知します（検知できる項目は製品によって異なります）。
ゼロトラスト環境において、これらのツールは「クラウドの健康診断」を継続的に行い、人間が見落としがちなミスを見つけやすくしてくれます。
部門が独自に契約したクラウドのように、情シスが把握していない資産の洗い出し方はVol.03 ASM（攻撃面管理）で「野良資産」をあぶり出せで解説しています。
4. ゼロトラスト環境におけるクラウド保護
明日からできること：Microsoft Secure Score
専用ツールを検討する前に、Microsoft 365を使っているなら、まず確かめたい診断ツールがあります（推奨アクションによっては追加のライセンスが必要です）。
「Microsoft Secure Score（セキュリティスコア）」です。
Microsoft Defender ポータル（security.microsoft.com/securescore）にアクセスすれば、テナントのセキュリティ状態がパーセント（例：45%）と「獲得ポイント／満点ポイント」で表示されます（100点満点の点数ではありません）。
「管理者のMFAを有効にする」「レガシー認証をブロックする」といった推奨アクションが表示され、それを実行すると点数が上がります（スコアへの反映には24〜48時間かかることがあります）。
まずは、このスコアを確認してください。なお、Microsoftは、このスコアはシステムやデータが侵害される可能性を絶対的に測るものではないと説明しています（Microsoft Learn）。点数の高低だけで判断せず、表示された推奨アクションを一つずつ確認して設定を見直しましょう。
クラウドへのログインを守るMFAの導入手順は、Vol.04 MFA導入ガイドをご覧ください。
結論：クラウドは「使われるもの」ではなく「統制するもの」
クラウド移行は、インフラ管理の負担を減らしますが、セキュリティ管理の責任までは減らしてくれません。むしろ、インターネット経由でどこからでもアクセスできる分、オンプレミスよりも厳格な「設定管理」が求められます。
中堅・成長企業の情シス責任者へ。
「クラウドだから安心」という思考停止を捨ててください。
まずは明日、Microsoft Defender ポータルを開き、セキュリティスコアを確認すること。そして、AWSやAzureを使っているなら、公開設定になっているリソースがないか、CSPM（あるいはAWS Security Hub CSPM等のネイティブ機能）でスキャンをかけてください。
あなたの会社のデータを守る鍵を持っているのは、マイクロソフトではなく、あなた自身です。
このほかの予防策は、中小企業のランサムウェア対策チェックリストにまとめています。できるところから一つずつ進めてください。
