「パブリッククラウドは便利そうだけど、セキュリティは本当に大丈夫なのか」
クラウド導入を検討している企業の情報システム担当者や、すでにAWS、Azure、Google Cloudなどを利用している現場エンジニアの方から、こうした相談を受けることは少なくありません。
結論から言えば、パブリッククラウドそのものが危険というわけではありません。むしろ、大手クラウド事業者は大規模なセキュリティ投資を行っており、物理設備や基盤部分の保護は高い水準で管理されています。
一方で、実際のセキュリティ事故では、利用者側の設定ミス、権限管理の不備、認証情報の漏えい、ログ監視不足などが原因になるケースが多くあります。つまり、パブリッククラウドのセキュリティで重要なのは、「クラウドを使うかどうか」ではなく、「自社が守るべき範囲を理解し、正しく設定・運用できているか」です。
クラウドは、うまく使えば非常に強力な基盤です。しかし、設定ひとつで社内向けのデータが外部公開されたり、管理者アカウントの乗っ取りから高額課金につながったりすることもあります。
この記事では、CyberCrewのホワイトハッカーの視点から、パブリッククラウドの基本、セキュリティリスク、実際のインシデント事例、責任共有モデル、今すぐ実施すべき対策までを、できるだけ分かりやすく解説します。
なお、CyberCrewでは、AWS、Azure、GCPなどのクラウド環境に特化したクラウドペネトレーションテストを提供しています。企業が利用するクラウド基盤に対して、実際の攻撃者を模した手法で脆弱性を検出し、重要なデータ資産の保 護を支援します。ホワイトハッカーを擁するCyberCrewが、お客様のクラウドアカウント設定、アクセス権限、ストレージ構成、アプリケーション設定などを総合的に分析し、改善提案を行います。まずは無料でご相談ください。
TABLE OF CONTENTS
パブリッククラウドとは？
パブリッククラウドとは、クラウド事業者が提供するサーバー、ストレージ、ネットワーク、データベースなどのITリソースを、インターネット経由で利用できるサービス形態です。
自社でサーバーを購入して社内に設置するのではなく、必要なときに必要な分だけ、クラウド上のリソースを利用します。NISTも、クラウドコンピューティングを、ネットワーク経由で設定可能なコンピューティングリソースを必要に応じて利用できるモデルとして定義しています。詳しくはNISTのThe NIST Definition of Cloud Computingで確認できます。
セキュリティの観点では、「クラウド事業者がすべて守ってくれる」と考えるのは危険です。データセンターや物理サーバーなどの基盤部分は事業者が管理しますが、アカウント、データ、権限設定、公開範囲、アプリケーションの設定などは利用者側の責任として残ります。
言い換えると、パブリッククラウドは「安全な基盤を借りる」仕組みであって、「自社の運用責任がなくなる」仕組みではありません。
パブリッククラウドの代表例（AWS・Azure・Google Cloud）
パブリッククラウドの代表例として、AWS、Microsoft Azure、Google Cloudがあります。
AWSは、Amazonが提供するクラウドサービスで、コンピューティング、ストレージ、データベース、セキュリティ、AI、分析など幅広いサービスを提供しています。多くの企業で、Webサービス、基幹システム、データ分析基盤、バックアップ環境などに利用されています。
Microsoft Azureは、Microsoftが提供するクラウドサービスで、Windows Server、Active Directory、Microsoft 365など、既存のMicrosoft製品との親和性が高い点が特徴です。社内でMicrosoft 365やEntra IDを利用している企業では、ID管理や認証基盤と連携しやすいという利点があります。
Google Cloudは、Googleが提供するクラウドサービスで、データ分析、機械学習、コンテナ基盤、グローバルネットワークなどに強みがあります。BigQueryやGKEなどを活用し、データ分析やアプリケーション基盤として利用する企業も増えています。
いずれも高機能なサービスですが、利用者が設定を誤れば、情報漏えい、不正アクセス、高額課金などのリスクは発生します。クラウド事業者の信頼性と、自社の設定・運用の適切さは分けて考える必要があります。
プライベートクラウド・オンプレミスとの違い
パブリッククラウド、プライベートクラウド、オンプレミスの違いは、「誰が基盤を保有・管理するか」「共有基盤か専有基盤か」で考えると分かりやすくなります。
| 区分 | 概要 | 主な特徴 | セキュリティ上の注意点 |
|---|---|---|---|
| パブリッククラウド | クラウド事業者の基盤を複数企業で利用する形態 | 初期導入が早く、従量課金で拡張しやすい | 設定ミス、権限管理、公開範囲の管理が重要 |
| プライベートクラウド | 特定の企業・組織専用のクラウド環境 | 自社要件に合わせやすく、統制しやすい | 運用負荷やコストが高くなりやすい |
| オンプレミス | 自社施設内にサーバーやネットワーク機器を設置する形態 | 物理的に管理しやすく、独自設計しやすい | 機器保守、物理対策、冗長化、監視を自社で担う |
パブリッククラウドは「共有だから危険」という単純な話ではありません。クラウド事業者は、利用者ごとに論理的な分離を行い、物理基盤や仮想化基盤を管理しています。
問題になりやすいのは、その上で利用者が作成したリソース、ユーザー権限、ネットワーク設定、データ公開範囲です。クラウドの安全性は、事業者側の基盤の安全性だけでなく、利用者側の設計と運用によって大きく変わります。
パブリッククラウドのメリット・デメリット
パブリッククラウドは、正しく設定すれば安全に利用できます。実際の事故で問題になりやすいのは、クラウドそのものの欠陥ではなく、利用者側の設定ミスや運用不備です。
そのため、メリットだけを見て導入するのではなく、導入後に自社が管理すべき範囲まで理解しておくことが重要です。クラウドは便利な反面、設定変更が簡単にできるため、権限や公開範囲の管理が甘いとリスクが表面化します。
ここでは、導入前に押さえておきたい代表的なメリットとデメリットを整理します。
メリット①導入の手間が少なくすぐ使える
パブリッククラウドの大きなメリットは、導入までのスピードです。
オンプレミスの場合、サーバーの選定、見積もり、購入、納品、設置、ネットワーク接続、OSインストールなど、多くの工程が必要です。パブリッククラウドであれば、管理画面から数分〜数十分で仮想サーバーやストレージを作成できます。
新規サービスの立ち上げ、検証環境の構築、一時的なシステム利用など、スピードが求められる場面では非常に有効です。特に、事業部門から「まず試したい」「短期間で検証したい」といった要望が出る企業では、クラウドの柔軟性が大きな強みになります。
ただし、簡単に作れるということは、管理外のリソースも生まれやすいということです。誰が作ったのか、何のためのリソースなのか、いつまで使うのかを管理する仕組みも同時に必要です。
メリット②初期費用を抑えられる（従量課金）
パブリッククラウドは、基本的に使った分だけ支払う従量課金モデルです。
オンプレミスのように、将来の最大利用量を見込んで高価なサーバーを先に購入する必要がありません。中小企業にとっては、初期投資を抑えながら必要なIT基盤を利用できる点が大きなメリットです。
また、検証環境や一時的なプロジェクトであれば、必要な期間だけ利用し、不要になったら停止・削除できます。これにより、IT投資を段階的に進めやすくなります。
ただし、従量課金は便利な反面、設定ミスや不正利用によって想定外の費用が発生する可能性があります。コスト管理もセキュリティ管理の一部として考える必要があります。
メリット③必要に応じて拡張できる（スケーラビリティ）
アクセス数の増加、データ量の増加、新規サービスの追加に合わせて、必要なリソースを柔軟に増減できる点もパブリッククラウドの強みです。
たとえば、キャンペーン期間だけサーバー台数を増やし、終了後に減らすといった運用が可能です。オンプレミスでは調達に時間がかかるようなリソースも、クラウドであれば短時間で拡張できます。
事業変化に合わせてIT基盤を柔軟に変えられることは、クラウド導入の大きな価値です。特に、ECサイト、Webサービス、データ分析基盤、AI活用など、需要変動が大きい領域では効果を発揮します。
一方で、拡張しやすいという特徴は、不正利用時の被害拡大にもつながります。攻撃者に認証情報を悪用されると、短時間で大量のリソースを作成される可能性があるため、利用上限やアラート設定が重要になります。
デメリット①カスタマイズの自由度が低い
パブリッククラウドは、クラウド事業者が提供する共通基盤の上で利用するサービスです。そのため、自社専用にハードウェアや基盤部分を細かく変更することはできません。
オンプレミスでは自由に構成できたネットワーク機器、ストレージ装置、特殊なセキュリティ機器なども、クラウドでは事業者が提供するサービス仕様に合わせて設計する必要があります。
ただし、この制約は必ずしも悪いことではありません。標準化された構成を使うことで、保守性や可用性を高めやすくなる面もあります。
問題は、オンプレミス時代の設計思想をそのままクラウドに持ち込むことです。クラウドにはクラウドに適した設計があります。既存システムを移行する場合も、「そのまま移す」のではなく、ネットワーク、権限、監視、バックアップをクラウド前提で見直す必要があります。
デメリット②セキュリティ管理が利用者側の責任になる
パブリッククラウドでは、クラウド事業者がデータセンター、物理サーバー、仮想化基盤などを守ります。しかし、利用者が作成したユーザー、アクセス権限、データ、アプリケーション、ネットワーク設定までは、原則として利用者が管理しなければなりません。
たとえば、ストレージを誤って公開した、管理者権限を広く付与した、MFAを設定しなかった、SSHやRDPを全世界に開放した、といった問題は利用者側の運用不備です。
クラウドでは「誰でも簡単に作れる」ことが利点である一方、「誰が何を作ったのか分からなくなる」リスクもあります。利用者側の管理体制が整っていなければ、クラウドの便利さがそのままセキュリティリスクになります。
この分担を理解するために重要なのが、後述する「責任共有モデル」です。
パブリッククラウドの主なセキュリティリスク（被害）
この章では、「何が起きるか」というセキュリティリスク（被害）の種類を整理します。
クラウドセキュリティの話では、原因と被害が混ざりがちです。ここではまず、設定ミスや認証情報漏えいの結果として、企業にどのような影響が出るのかを見ていきます。
原因そのものは次の章で扱うため、この章では「情報が漏れる」「アカウントを使われる」「サービスや費用に影響が出る」といった結果に絞って説明します。
情報漏えい
パブリッククラウドで最も分かりやすい被害が情報漏えいです。
たとえば、顧客情報を保管しているクラウドストレージの公開範囲を誤り、外部から閲覧できる状態になっていた場合、氏名、メールアドレス、電話番号、契約情報、問い合わせ内容などが第三者に見られる可能性があります。
また、SaaSの権限設定を誤ることで、本来はログインユーザーしか見られない情報が、ゲストユーザーや外部ユーザーから参照できる状態になるケースもあります。
情報漏えいは、単に「データが見られた」という問題にとどまりません。顧客への通知、監督官庁への報告、問い合わせ対応、再発防止策の実施、ブランド毀損など、事業全体に影響します。
IBMのCost of a Data Breach Report 2025では、データ侵害の世界平均コストが440万米ドルとされています。もちろん個別企業の被害額は業種や規模によって異なりますが、情報漏えいが経営リスクであることは明らかです。
アカウント乗っ取り・不正利用
クラウド環境では、管理者アカウントやアクセスキーが盗まれると、大きな被害につながります。
攻撃者は、漏えいした認証情報を使ってクラウド環境にログインし、サーバーを作成したり、データを持ち出したり、権限を変更したりする可能性があります。特に、権限が強すぎるアカウントが乗っ取られると、影響範囲は一気に広がります。
クラウド環境では、侵害されたIAM認証情報を悪用して仮想マシンやコンテナ上で暗号資産マイニングが行われる事例も報告されています。これはクラウド事業者の基盤が破られたというより、利用者側の認証情報管理や権限管理の不備が悪用される典型例です。
クラウドでは、認証情報の管理がそのままセキュリティの土台になります。特に、長期的に利用できるアクセスキー、管理者権限を持つアカウント、MFA未設定のアカウントは重点的に管理する必要があります。
サービス停止・想定外の高額課金
クラウド環境が攻撃された場合、サービス停止や想定外の高額課金が発生することがあります。
たとえば、攻撃者が不正にサーバーを大量作成した場合、利用者が気づかないうちにクラウド利用料が膨らみます。暗号資産マイニングに悪用されると、CPUやGPUを大量消費する高額なリソースが作成されることもあります。
また、攻撃対応としてサービスを一時停止せざるを得ない場合もあります。これはクラウド事業者側の障害とは別の問題です。自社の設定不備や認証情報漏えいが原因で、クラウド上の自社システムが止まるケースを想定しておく必要があります。
特に、ECサイト、予約システム、業務システム、顧客向けポータルなどをクラウド上で運用している場合、停止時間はそのまま売上や信用に影響します。クラウドのセキュリティ対策は、情報漏えい対策であると同時に、事業継続対策でもあります。
クラウドのセキュリティ事故を招く設定・運用の不備
この章では、「なぜ事故が起きるか」という原因を整理します。
前章で説明した情報漏えい、アカウント乗っ取り、高額課金といった被害は、いきなり発生するわけではありません。多くの場合、その手前に設定ミス、認証不備、管理外リソース、ログ監視不足などの引き金があります。
クラウドは設定変更が容易な反面、変更履歴や責任者が曖昧になると、意図しない公開や過剰権限が残りやすくなります。
設定ミス（ストレージ公開・権限過剰）
クラウドセキュリティ事故の代表的な原因が設定ミスです。
よくあるのは、クラウドストレージを誤って公開状態にするケースです。社内向けのファイル、ログ、バックアップ、顧客情報などが、意図せず外部からアクセス可能になってしまうことがあります。
もう一つ多いのが、権限過剰です。本来は読み取り権限だけでよいユーザーに管理者権限を与える、開発用アカウントに本番環境の変更権限を与える、使われていないアカウントを残したままにする、といった運用はリスクを高めます。
クラウドセキュリティの文脈では、「クラウド事業者の基盤が弱いから事故が起きる」というより、利用者側の設定・運用の不備が原因になるケースが多くあります。だからこそ、導入時だけでなく、運用中の継続的な点検が重要です。
多要素認証（MFA）の未設定
多要素認証、いわゆるMFAの未設定も、アカウント乗っ取りの入口になります。
パスワードだけでログインできる状態では、フィッシング、パスワード使い回し、情報漏えいサイトからの認証情報悪用などによって、不正ログインされる可能性が高まります。
MFAを有効にすると、パスワードに加えて、認証アプリ、セキュリティキー、生体認証など別の要素が必要になります。AWSも、IAMのセキュリティベストプラクティスとして、必要に応じてMFAを要求し、可能な限り一時的な認証情報を使うことを推奨しています。詳しくはAWSのIAM security best practicesで確認できます。
MFAは、費用をかけずに始められる非常に効果の高い対策です。特に、管理者アカウントやクラウド環境全体に影響するアカウントでは、最優先で有効化すべきです。
放置されたクラウド資産（管理外リソース）
クラウドでは、検証用サーバー、古いストレージ、使われなくなったアクセスキー、一時的に作ったネットワーク設定などが、そのまま残りやすい傾向があります。
こうした放置資産は、管理台帳に載っていないため、パッチ適用、権限見直し、ログ監視の対象から外れます。結果として、攻撃者にとって見つけやすく、防御側にとって気づきにくい入口になります。
これはシャドーITとは少し違います。シャドーITは、部門や個人が情シスの管理外で勝手にサービスを使う問題です。一方、放置されたクラウド資産は、もともとは正規に作られたものの、運用の中で管理対象から外れてしまったリソースです。
どちらも危険ですが、対策としては「資産の棚卸し」と「所有者の明確化」が重要です。作成者、用途、期限、責任者が分からないリソースは、それだけでリスクになります。
実際のインシデント事例と被害規模
ここでは、実際に公表されたクラウド関連のインシデント事例を確認します。
なお、「被害規模」といっても、すべてが金銭被害として公表されているわけではありません。多くの場合、件数、閲覧可能性、アクセス確認の有無、影響範囲として公表されます。
金銭的な影響の参考としては、IBMのCost of a Data Breach Report 2025が、データ侵害の世界平均コストを440万米ドルとしています。個別の国内事例にそのまま当てはめるものではありませんが、情報漏えいが経営に与える影響の大きさを考えるうえで参考になります。
SaaSの設定不備で大規模な情報流出の可能性が相次いだ事例（2020〜2021年）
2020年から2021年にかけて、日本国内でもクラウド型システムやSaaSの設定不備に関連する事案が相次ぎました。
楽天グループでは、社外のクラウド型営業管理システムに保管された一部情報について、社外の第三者からアクセスがあったことを公表しています。公表内容では、楽天市場関連で最大1,381,735件、楽天カード関連で最大16,895件、楽天Edy関連で最大89,141件がアクセスの可能性があった情報として示され、原因は「社外のクラウド型営業管理システムの利用におけるセキュリティ設定の不備」とされています。詳細は楽天グループの公表資料で確認できます。
PayPayでは、2020年12月に管理サーバーへのアクセス履歴について公表しました。当初はアクセスされた可能性のある最大件数を20,076,016件としていましたが、その後の詳細な調査分析により2,101件であったことが判明したと訂正されています。また、原因は当該情報へのアクセス権限の設定不備とされています。詳細はPayPayの調査結果に関する公表で確認できます。
イオン銀行では、「来店予約・オンライン相談サービス」で利用していた外部のクラウド型システムに設定不備があり、顧客情報の一部が社外の第三者からアクセスできる状態だったことを公表しています。社外の第三者からアクセスがあった情報として、氏名2,062名分、電話番号608件、メールアドレス49件などが示されています。詳細はイオン銀行の公表資料で確認できます。
これらの事例から分かるのは、大企業であっても、クラウドやSaaSの設定不備は起こり得るということです。クラウドサービスを導入しただけで安全になるわけではなく、導入後の設定確認、権限確認、ログ確認が不可欠です。
設定ミスは長期間気づかれない｜約5年見過ごされたケース
クラウドの設定ミスで怖いのは、発生直後に気づけるとは限らないことです。
楽天グループの事例では、アクセスの可能性があった期間として、楽天市場関連では2016年1月15日から2020年11月24日まで、楽天カード関連では2016年1月15日から2020年11月26日まで、楽天Edy関連では2016年1月15日から2020年11月26日までと公表されています。つまり、約5年弱にわたり、外部からアクセス可能な状態が続いていた可能性があるということです。
この事例は、「一度設定したら終わり」ではないことを示しています。クラウドサービスはアップデートされ、機能が追加され、権限仕様が変わり、利用部門も変わります。導入時に問題がなかった設定でも、時間の経過とともにリスクになる場合があります。
自力での点検も重要ですが、担当者が日常運用の中で全設定を継続的に見続けるのは現実的に難しいことがあります。定期的な棚卸し、設定監査、第三者によるクラウドセキュリティ診断を組み合わせることが、長期間の見落としを防ぐうえで有効です。
誰がどこまで守る？責任共有モデルを理解する
パブリッククラウドのセキュリティを考えるうえで、必ず理解しておくべき考え方が「責任共有モデル」です。
責任共有モデルとは、クラウド事業者と利用者が、それぞれどの範囲のセキュリティ責任を持つのかを整理した考え方です。
AWSは、セキュリティとコンプライアンスはAWSと顧客の共有責任であり、AWSはホストOS、仮想化レイヤー、施設の物理セキュリティなどを管理し、顧客はゲストOS、アプリケーション、セキュリティグループの設定などを管理すると説明しています。詳しくはAWSのShared responsibilityで確認できます。
Microsoftも、クラウドプロバイダーが処理するセキュリティタスクと、利用者が処理するタスクを理解することが重要だと説明しています。詳しくはMicrosoftのクラウドでの共同責任で確認できます。
クラウド事業者側の責任範囲
クラウド事業者側の責任範囲は、主に「クラウド基盤そのもの」です。
具体的には、データセンターの物理セキュリティ、電源、空調、ラック、物理サーバー、ストレージ装置、ネットワーク機器、仮想化基盤、基盤サービスの可用性などが含まれます。
利用者がAWS、Azure、Google Cloudなどを使う場合、自社でデータセンターを建てたり、物理サーバーを保守したりする必要はありません。この部分をクラウド事業者に任せられることが、パブリッククラウドの大きなメリットです。
ただし、クラウド事業者が強固な基盤を提供していても、その上に作成したリソースをどのように設定するかは利用者側の問題です。金庫が頑丈でも、鍵を開けたままにしていれば安全とはいえないのと同じです。
利用者側の責任範囲（IaaS／PaaS／SaaS）
利用者側の責任範囲は、利用するサービス形態によって変わります。
| サービス形態 | 例 | 利用者側の主な責任 |
|---|---|---|
| IaaS | 仮想サーバー、仮想ネットワーク、クラウドストレージ | OS設定、パッチ適用、アプリケーション、ファイアウォール、アカウント、データ、公開範囲 |
| PaaS | アプリ実行基盤、マネージドDB、サーバーレス | アプリケーション、データ、認証、アクセス権限、設定、ログ確認 |
| SaaS | グループウェア、CRM、オンラインストレージ | ユーザー管理、権限設定、共有設定、データ分類、監査ログ確認 |
IaaSでは、利用者が管理する範囲が広くなります。仮想サーバーのOS更新、ミドルウェア設定、ネットワーク制御、ログ監視など、多くの作業が必要です。
PaaSでは、OSや基盤部分の管理負荷は下がりますが、アプリケーション、データ、認証、権限設定は利用者側に残ります。
SaaSでは、最も利用者負担が少ないように見えます。しかし、SaaSでもユーザー権限、外部共有、ゲストアクセス、管理者設定、ログ確認は利用者の責任です。SaaSの設定不備による情報閲覧事案が実際に起きていることを考えると、「SaaSだから安全」とは言えません。
パブリッククラウドの今すぐやるべきセキュリティ対策
ここからは、具体的に何をすべきかを整理します。
高度なセキュリティ製品をいきなり導入する前に、まずは基本対策を確実に実施することが重要です。ひとり情シスの企業でも、無料または低コストで始められる対策は多くあります。
ここで紹介する対策は、特定のクラウドサービスに限らず、AWS、Azure、Google Cloud、SaaS利用のいずれでも共通して重要になるものです。
多要素認証（MFA）を有効にする
最優先で実施すべき対策は、管理者アカウントへのMFA有効化です。
対象は、クラウドのルートアカウント、管理者アカウント、IAMユーザー、SaaSの管理者アカウント、IDプロバイダーの管理者アカウントなどです。特に、クラウド環境全体を操作できるアカウントにMFAが設定されていない状態は危険です。
MFAを有効にしても、すべての攻撃を防げるわけではありません。しかし、パスワード漏えいだけでログインされるリスクを大きく下げられます。
まず管理者から必ず設定し、その後、一般ユーザーにも段階的に広げるのが現実的です。クラウド利用を始めたばかりの企業でも、MFAは早い段階で取り組みやすい対策です。
パスワード・認証情報（アクセスキー）の管理
クラウドでは、パスワードだけでなく、アクセスキー、APIキー、シークレットキー、サービスアカウントキーなどの管理が非常に重要です。
AWSは、長期的なアクセスキーを作成する代わりに、IAMロールなどの一時的なセキュリティ認証情報を使うことをベストプラクティスとしています。詳しくはAWSのIAM security best practicesで確認できます。
実務上は、次のような管理が必要です。
| 対策 | 内容 |
|---|---|
| 使い回しを禁止する | クラウド管理者用のパスワードを他サービスと使い回さない |
| 長期キーを減らす | 可能な限り一時認証情報やロールを使う |
| キーをコードに書かない | GitHub、社内リポジトリ、設定ファイルに認証情報を残さない |
| 不要キーを削除する | 退職者、検証用、放置アカウントのキーを定期削除する |
| 権限を最小化する | 必要な操作だけ許可する最小権限にする |
認証情報は、漏えいすると攻撃者にとって「正規の入口」になります。ファイアウォールやIDSを整備していても、正しい認証情報でログインされると検知が難しくなる場合があります。
管理ポート（SSH／RDP）の通信制限
SSHの22番ポート、RDPの3389番ポートなど、管理用ポートをインターネット全体に公開するのは避けるべきです。
AWSのセキュリティグループは、EC2などのリソースに到達できる通信を制御する仮想ファイアウォールとして機能し、送信元、ポート範囲、プロトコルを指定できます。詳しくはAWSのSecurity groupsで確認できます。
管理ポートを開ける場合は、少なくとも次のような制限を行います。
| 項目 | 推奨される考え方 |
|---|---|
| 送信元IP | 自社固定IP、VPN、踏み台サーバーなどに限定する |
| ポート | 必要な管理ポートだけ許可する |
| 公開範囲 | 0.0.0.0/0での全開放を避ける |
| 認証 | パスワード認証ではなく鍵認証やMFA連携を検討する |
| 代替手段 | AWS Systems Manager、Azure Bastionなどの利用を検討する |
「一時的に開けたつもり」が、そのまま残るケースは非常に多くあります。設定した人だけでなく、第三者が見ても分かるように、変更理由と期限を記録しておくことが重要です。
ストレージの公開範囲を最小化する
クラウドストレージの公開設定は、定期的に確認する必要があります。
AWS S3、Azure Blob Storage、Google Cloud Storageなどは便利ですが、公開設定を誤るとファイルが外部から閲覧可能になる可能性があります。Web公開が必要なファイルと、社内利用・バックアップ・ログ・個人情報を含むファイルは明確に分けるべきです。
確認すべきポイントは次のとおりです。
| 確認項目 | 内容 |
|---|---|
| パブリック公開 | 意図せず全体公開されていないか |
| バケットポリシー | 不要に広いアクセス許可がないか |
| オブジェクト単位の権限 | 個別ファイルが公開されていないか |
| 共有リンク | 有効期限なしの共有リンクが残っていないか |
| 保管データ | 個人情報や機密情報を不要に置いていないか |
過去のインシデント事例でも、設定不備により情報が外部からアクセス可能になっていたケースが確認されています。ストレージは「作ること」よりも「誰が見られるか」を管理することが重要です。
ログ監視・変更検知を仕組み化する
クラウド環境では、設定変更や不審な操作に気づく仕組みが必要です。
たとえば、管理者権限の付与、MFAの無効化、セキュリティグループの変更、公開ストレージの作成、アクセスキーの作成、大量のリソース作成などは、早期に検知すべき操作です。
手動で管理画面を見に行くだけでは限界があります。AWS CloudTrail、Amazon GuardDuty、AWS Security Hub、Microsoft Defender for Cloud、Google Cloud Security Command Centerなど、クラウド事業者が提供する監視・検知機能を活用しましょう。
重要なのは、「ログを取得している」だけで満足しないことです。ログを見ていない、通知先がない、アラートが多すぎて無視されている状態では、実質的に機能していません。誰が、いつ、どのアラートを見るのかまで決めておく必要があります。
パブリッククラウド導入・選定時のポイント
これからパブリッククラウドを導入する場合、機能や価格だけでなく、セキュリティと運用面も含めて比較する必要があります。
特に、経営層や監査部門に説明する立場であれば、「どのサービスが有名か」ではなく、「自社の責任範囲を管理できるか」「規格や監査に耐えられるか」「運用を継続できるか」を確認することが重要です。
導入時点で確認を怠ると、後から権限設計やログ管理を作り直すことになり、結果的にコストもリスクも増えます。
事業者のセキュリティ規格取得状況を確認する（ISO/IEC 27017など）
クラウド事業者やクラウドサービスを選定する際は、セキュリティ関連の規格や認証の取得状況を確認しましょう。
代表的なものにISO/IEC 27017があります。ISO/IEC 27017は、ISO/IEC 27002をベースに、クラウドサービスの提供および利用に関する情報セキュリティ管理策のガイドラインを示す国際規格です。クラウドサービス事業者とクラウドサービス利用者の双方に向けた管理策が含まれています。詳しくはISOのISO/IEC 27017:2015で確認できます。
ただし、認証を取得している事業者を選べば、自社側の対策が不要になるわけではありません。規格取得状況は選定時の重要な判断材料ですが、利用者側の設定、権限管理、ログ監視は別途必要です。
つまり、規格は「信頼できる事業者か」を見る材料であり、「自社の設定が安全か」を保証するものではありません。
自社の既存システムと連携できるかを確認する
クラウド導入時には、既存システムとの連携可否も確認が必要です。
社内のID管理、Active Directory、Microsoft 365、VPN、基幹システム、監視ツール、ログ管理基盤などと無理なく連携できるかを事前に確認しましょう。
連携が不十分なまま導入すると、アカウントが二重管理になったり、退職者アカウントが残ったり、ログが分散して追跡できなくなったりします。セキュリティは単独のクラウド設定だけでなく、社内全体の運用とつながっています。
特に重要なのは、ID管理とログ管理です。誰がログインし、どの権限で、何を変更したのかを追跡できなければ、インシデント時の調査が難しくなります。
導入後のコスト（従量課金）を把握する
パブリッククラウドは従量課金で始めやすい一方、使い方によっては想定以上のコストが発生します。
サーバー台数、ストレージ容量、データ転送料、ログ保存量、バックアップ、監視、セキュリティ機能、サポート費用など、導入前に概算しておくことが重要です。
セキュリティ面では、不正利用による高額課金も考慮すべきです。予算アラート、利用上限の通知、異常なリソース作成の検知、不要リソースの定期削除などを運用に組み込みましょう。
コスト管理は経理だけの問題ではありません。クラウドでは、攻撃者による不正利用がそのまま利用料金として跳ね返ることがあります。そのため、コスト監視もセキュリティ監視の一部として考える必要があります。
自社だけで守りきれない範囲を見極める
MFAを有効にし、権限を最小化し、管理ポートを制限し、ストレージ公開範囲を見直し、ログ監視を始める。これらは非常に重要です。
しかし、それでも「実際に攻撃が通るかどうか」までは、自社だけでは判断しにくい場合があります。
たとえば、設定上は問題なさそうに見えても、複数の権限を組み合わせることで権限昇格できる、外部公開されたAPIから内部情報に到達できる、検証用アカウントが本番環境に影響を与える、といったケースがあります。
クラウドセキュリティは、チェックリストだけでは見落としが発生します。設定監査に加えて、攻撃者の視点で「どこまで到達できるか」を確認することが重要です。
パブリッククラウドのセキュリティ対策ならCyberCrew
CyberCrewは、サイバーセキュリティを専門とする企業として、攻撃者視点を重視したセキュリティ診断・リスク評価を行っています。
パブリッククラウドのセキュリティ対策では、単に設定項目を眺めるだけでは不十分です。クラウド環境では、IAM、ネットワーク、ストレージ、ログ、アプリケーション、SaaS連携などが複雑に絡み合っています。一つひとつの設定は小さな問題に見えても、攻撃者が組み合わせることで大きな侵入経路になることがあります。
CyberCrewでは、ホワイトハッカーの視点から、クラウド環境における設定不備、権限過剰、外部公開リソース、管理外資産、認証情報管理、ログ監視状況などを確認し、実際のリスクとして整理します。
特に、次のような課題を持つ企業には、第三者によるクラウドセキュリティ診断が有効です。
| 課題 | 診断で確認すべきポイント |
|---|---|
| クラウド設定に自信がない | IAM、ネットワーク、ストレージ、ログ設定の確認 |
| 管理者が少なく属人化している | 権限設計、運用手順、棚卸し状況の確認 |
| 監査・取引先から説明を求められる | 責任範囲、対策状況、改善計画の整理 |
| すでにクラウドを使っているが点検していない | 放置資産、公開設定、アクセスキー、ログの確認 |
| 攻撃された場合の影響を知りたい | 攻撃者視点での到達可能性、影響範囲の確認 |
CyberCrewのペネトレーションテストサービスおよび脆弱性診断サービスは、経済産業省の基準に基づく情報セキュリティサービス台帳にも登録されています。
クラウドは正しく使えば、企業の成長を支える強力な基盤になります。一方で、設定や運用を誤ると、情報漏えい、不正利用、サービス停止、高額課金などのリスクにつながります。
自社だけで判断が難しい場合は、第三者の視点を入れることで、見落としを減らし、経営層や監査部門にも説明しやすい状態を作れます。パブリッククラウドのセキュリティに不安がある場合は、CyberCrewへご相談ください。
パブリッククラウドのセキュリティについてよくある質問（FAQ）
ここでは、パブリッククラウドのセキュリティについて、よくある質問に回答します。
クラウド導入前の不安解消や、社内説明の材料として活用してください。特に、「クラウドは危険なのか」「どこまで自社責任なのか」「無料でできる対策はあるのか」といった疑問は、多くの企業で共通しています。
Q.パブリッククラウドはなぜ危険といわれるのですか？
パブリッククラウド自体が危険というより、利用者側の設定ミスや運用不備によって事故が起きるため、危険だといわれることがあります。
特に、ストレージの公開設定、過剰な権限付与、MFA未設定、アクセスキーの漏えい、管理ポートの公開などは代表的なリスクです。
正しく設定し、継続的に確認すれば、安全に利用できます。重要なのは、クラウド事業者が守る範囲と、自社が守る範囲を分けて理解することです。
Q.パブリッククラウドとプライベートクラウドはどちらが安全ですか？
一概にどちらが安全とは言えません。
パブリッククラウドは大手事業者の強固な基盤を利用できますが、利用者側の設定管理が必要です。プライベートクラウドは専有環境として統制しやすい一方、基盤の運用・保守・監視を自社または委託先で適切に行う必要があります。
重要なのは、クラウドの種類ではなく、自社の責任範囲を理解し、必要な対策を継続できるかどうかです。
Q.無料でできるパブリッククラウドのセキュリティ対策はありますか？
あります。
まずは、管理者アカウントのMFA有効化、不要アカウントの削除、アクセスキーの棚卸し、ストレージ公開設定の確認、SSHやRDPの通信制限、ログ取得の有効化から始めるべきです。
これらは大きな予算をかけなくても実施できる対策です。ただし、継続的に確認する仕組みがないと、時間の経過とともに設定が崩れる可能性があります。
Q.クラウドのセキュリティ事故が起きたら責任は誰にありますか？
原因によって変わります。
クラウド事業者の基盤障害や物理設備の問題であれば、事業者側の責任範囲になる可能性があります。一方で、利用者がストレージを公開した、権限を広く付与した、MFAを設定していなかった、認証情報を漏えいさせた、といった場合は、利用者側の責任になりやすいと考えられます。
この判断の前提になるのが責任共有モデルです。クラウドを利用する企業は、自社が守るべき範囲を事前に把握しておく必要があります。
Q.中小企業でも本格的なセキュリティ対策は必要ですか？
必要です。
中小企業であっても、クラウド上に顧客情報、取引先情報、請求情報、業務データを保管している場合、情報漏えいや不正利用の影響は大きくなります。
ただし、最初から高額なセキュリティ製品を導入する必要はありません。まずはMFA、権限見直し、公開設定確認、不要リソース削除、ログ監視といった基本対策から始めましょう。
そのうえで、自社だけで確認が難しい部分は、第三者診断を活用するのが現実的です。
まとめ｜パブリッククラウドは正しい設定と対策で安全に使える
パブリッククラウドは、正しく設定し、継続的に管理すれば安全に利用できる強力なIT基盤です。
一方で、「クラウド事業者が守ってくれるから大丈夫」と考えるのは危険です。責任共有モデルにより、データ、アカウント、権限、公開範囲、アプリケーション、ログ監視などは利用者側の責任として残ります。
まず実施すべき対策は、管理者アカウントのMFA有効化、不要アカウント・不要アクセスキーの削除、ストレージ公開設定の確認、SSHやRDPなど管理ポートの通信制限です。これらは大きな予算をかけなくても始められる基本対策です。
そのうえで、権限の最小化、ログ監視・変更検知の仕組み化、クラウド資産の定期棚卸し、第三者によるクラウドセキュリティ診断を組み合わせることで、見落としを減らせます。
クラウドセキュリティは、一度設定して終わりではありません。サービスの追加、担当者変更、権限変更、アップデート、組織変更によって、時間とともにリスクは変化します。
まずは無料でできる基本対策から着手しましょう。そのうえで、自社だけでは見落としが不安な場合や、実際に攻撃者がどこまで到達できるかを確認したい場合は、第三者のクラウドセキュリティ診断を活用することをおすすめします。
CyberCrewは、攻撃者視点と実務的なセキュリティ評価により、パブリッククラウドを安心して利用するための支援を行っています。クラウド環境の安全性に不安がある場合は、早めの点検が有効です。
投稿者プロフィール
-
CyberCrew（サイバークルー）は、企業の情報セキュリティをトータルで支援する専門チームです。高度なスキルを持つホワイトハッカーが在籍し、サイバー攻撃の監視・検知から初動対応、リスク診断や従業員向けのセキュリティ教育まで、幅広いサービスを提供。企業のニーズに応じた柔軟な対応で、安心・安全なIT環境の実現をサポートします。
■ 情報セキュリティサービス台帳登録事業者
■ セキュリティコンテスト受賞歴
CTF国際大会 世界No.1
CEH Master Leaderboard 世界No.1
Hack The Box Rank TOP10
■ 保有セキュリティ資格
GIAC GXPN、Cisco Cybersecurity Specialist、CEH Master、CEH Practical、
Cyber Security Professional Certificate、OSCP、OSCP+、CPENT、OSWP、
eCPPT、eMAPT、CRTS、SOC-100、PEN-100、
HTB Offshore Penetration Tester（Level 3）
