クラウド設定不備とは？
クラウド設定不備とは、AWS、Azure、Google Cloudなどのクラウドサービスを利用する際、セキュリティ設定やアクセス制御を適切に行わず、本来は保護されるべきデータやシステムが外部から不正にアクセスできる状態になっている脆弱性です。クラウド・ソフトの供給リスクの中でも最も頻繁に発生し、データ漏洩や不正アクセスの主要な原因となっているサイバー攻撃の入口です。
クラウドサービスは、従来の自社サーバーとは根本的に異なる仕組みで動作します。インターネット経由で誰でもアクセスできる環境であるため、セキュリティ設定が適切でないと、世界中の誰もがそのデータにアクセスできてしまいます。多くのクラウドサービスは、利便性を優先して「デフォルトで公開」または「設定が複雑」になっており、利用者が意図せず危険な状態のまま運用してしまうことが頻発しています。
クラウド設定不備の典型的な例として、S3バケット（AWSのストレージサービス）が「パブリック公開」に設定されたまま顧客情報を保存する、データベースが認証なしでインターネットからアクセスできる状態になっている、管理画面のパスワードがデフォルトのまま変更されていない、アクセスキーがソースコードに埋め込まれてGitHubで公開されている、などがあります。
2019年のCapital Oneの事例では、AWS上の設定不備により約1億人分の個人情報が流出し、約80億円の罰金と和解金が発生しました。2021年のMcKinseyの報告によると、クラウドセキュリティインシデントの95%以上が、クラウドプロバイダーの問題ではなく、利用者側のクラウド設定不備に起因しています。つまり、クラウドサービス自体は安全に設計されていても、それを使う人間の設定ミスが原因で情報漏洩が発生しているのです。
クラウド・ソフトの供給リスクとして、クラウド設定不備は「誰でも見つけられる」という特徴があります。専門的なハッキング技術は不要で、Shodanなどの検索エンジンを使えば、設定不備のあるクラウドリソースを簡単に発見できます。攻撃者は、自動化されたスキャンツールで24時間365日、新たに公開された脆弱なクラウドリソースを探し続けています。
クラウド設定不備が発生する主な原因は、クラウドの「責任共有モデル」の誤解です。クラウドプロバイダーは「クラウドのセキュリティ」（インフラやハードウェアの保護）を担当しますが、「クラウド内のセキュリティ」（データの保護、アクセス制御、設定管理）は利用者の責任です。この区別を理解していない組織が多く、「クラウドは自動的に安全」と誤解して、適切なセキュリティ対策を怠ります。
クラウド設定不備を簡単に言うと？
自宅の貴重品を銀行の貸金庫に預けることを想像してください。銀行（クラウドプロバイダー）は、頑丈な建物、警備員、監視カメラなど、施設全体のセキュリティを提供します。しかし、貸金庫の中に何を入れるか、鍵をかけるかどうか、誰に鍵を渡すかは、あなた（利用者）の責任です。
もしあなたが貸金庫の扉を開けっ放しにしたまま帰ったり、鍵を貸金庫の前に置いたままにしたり、「誰でも開けていいですよ」という張り紙をしたりすれば、銀行の警備がどれほど厳重でも、貴重品は盗まれてしまいます。銀行は建物を守りますが、貸金庫の中身を守るのはあなたの仕事です。
デジタルの世界では、AWSやAzure、Google Cloudなどのクラウドサービスが「銀行」に相当します。クラウドプロバイダーはインフラを守りますが、そこに保存するデータの保護設定は利用者が行う必要があります。ストレージを「誰でもアクセス可能」に設定したり、データベースにパスワードを設定しなかったり、管理画面を誰でも見られる状態にしたりすることが、クラウド設定不備です。クラウド・ソフトの供給リスクとして、利用者側の設定ミスが原因で、世界中から機密情報が丸見えになってしまう危険な状態です。
クラウド設定不備で発生する被害は？
クラウド設定不備による被害は、一度発生すると数百万件から数億件のデータが一気に流出し、企業の存続を脅かすほどの深刻な事態に発展することがあります。クラウド・ソフトの供給リスクとして、被害の規模と速度が従来の情報漏洩とは比較にならないほど大きい特徴があります。
クラウド設定不備で発生する直接的被害
- 大規模な個人情報の流出と法的制裁
クラウド設定不備により、顧客の氏名、住所、電話番号、メールアドレス、クレジットカード情報、マイナンバーなど、数百万件から数億件の個人情報が一度に流出します。2019年のCapital One事件では、AWS上のファイアウォール設定不備により、約1億600万人分の個人情報（氏名、住所、収入、信用スコア、社会保障番号など）が流出しました。GDPRや個人情報保護法に基づく巨額の罰金が科され、Capital Oneは約80億円を罰金と和解金として支払いました。さらに、顧客からの集団訴訟、ブランドイメージの失墜、顧客離れなど、長期的な損失は計り知れません。日本企業でも、2020年に複数の企業でS3バケットの設定不備により顧客情報が流出し、数千万円から数億円の対応コストが発生しました。
- 企業機密の大量流出と競争力の喪失
クラウド上に保存された企業の機密情報──新製品の設計図、営業戦略、財務データ、M&A情報、ソースコード、顧客との契約書、研究開発データなど──がクラウド設定不備により外部に漏洩すると、企業の競争優位性が完全に失われます。2017年、米軍の機密データがAWS S3バケットの設定不備により公開され、テラバイト単位の機密情報が誰でもダウンロードできる状態でした。競合他社が自社の戦略や価格設定を知れば、市場での優位性は消滅します。研究開発に数年かけた成果が一瞬で競合にコピーされ、数十億円から数百億円の投資が無駄になります。さらに、顧客や取引先から「機密保持能力がない」と判断され、契約を打ち切られるリスクもあります。
- クラウドリソースの不正利用と莫大な課金
クラウド設定不備により、攻撃者が企業のクラウドアカウントに侵入し、無制限にリソースを使用することがあります。最も一般的なのは、クリプトジャッキング（仮想通貨マイニング）です。攻撃者は、数百台から数千台の仮想マシンを起動し、フルスペックで仮想通貨をマイニングします。企業が気づくのは、月末に通常の10倍、100倍、場合によっては1,000倍のクラウド利用料の請求が来た時です。2018年、ある企業のAWSアカウントがクラウド設定不備により侵害され、数週間で約10万ドル（約1,100万円）の不正利用料が発生しました。他にも、大量のデータ転送（データの外部送信）、DDoS攻撃の踏み台、スパムメール送信のためのサーバー利用など、様々な形で悪用されます。クラウドプロバイダーは正当な利用料として請求するため、基本的に返金されません。
クラウド設定不備で発生する間接的被害
- 信用の完全失墜と事業継続の危機
クラウド設定不備による情報漏洩が報道されると、企業は「ITセキュリティの基本すらできていない」と社会から厳しく批判されます。特に、クラウド設定不備は「専門的な攻撃」ではなく「基本的な設定ミス」であるため、「怠慢」「管理能力の欠如」と見なされ、技術的な攻撃による被害よりも評判の悪化が深刻です。顧客は「自分の情報も杜撰に扱われている」と感じて離れ、新規顧客の獲得は困難になり、取引先は契約を見直し、投資家は撤退を検討します。上場企業の株価は急落し、最悪の場合、事業の継続が不可能になります。2017年のEquifax（米国の信用情報機関）のデータ漏洩では、約1億4,700万人分の情報が流出し、CEOが辞任、株価は30%以上下落しました。
- 復旧と対策のための莫大なコストと時間
クラウド設定不備が発覚すると、影響範囲の特定、すべてのクラウドリソースの総点検、設定の見直し、脆弱性診断、ペネトレーションテスト、システムの再構築など、膨大な作業が必要です。外部のクラウドセキュリティ専門家への依頼、フォレンジック調査、法的対応、顧客への通知と補償、コールセンターの設置、広報対応など、数千万円から数億円のコストが発生します。IT部門は通常業務を中断して対応に追われ、新規プロジェクトは停止し、ビジネスの成長が数ヶ月から数年遅れます。さらに、再発防止のため、クラウドセキュリティポリシーの策定、全従業員への教育、監視システムの導入、継続的な監査体制の構築など、長期的な投資も必要です。
- サプライチェーン全体への波及被害
一つの企業のクラウド設定不備が、その企業だけでなく、顧客企業や取引先企業にも被害を及ぼします。例えば、SaaS企業のクラウド設定不備により、そのサービスを利用している数百社、数千社の顧客データが一斉に流出することがあります。2019年、複数のSaaS企業でElasticsearchの設定不備が発見され、それらのサービスを利用していた企業の顧客データが露出しました。被害を受けた企業は、自社では何も悪いことをしていないのに、サービスプロバイダーの設定ミスにより顧客に謝罪し、補償し、信用を失います。このようなサプライチェーンを通じた被害は、クラウド・ソフトの供給リスクの典型であり、一つの設定不備が業界全体に連鎖的な影響を与えます。
クラウド設定不備の種類とパターン
クラウド設定不備は、発生する場所やサービスの種類によって、いくつかのパターンに分類されます。
ストレージの公開設定不備
最も一般的で、被害が大きいのが、S3バケット（AWS）、Blob Storage（Azure）、Cloud Storage（Google Cloud）などのクラウドストレージの設定不備です。これらのサービスは、デフォルトでは非公開ですが、設定画面で「パブリックアクセスを許可」を選択すると、世界中の誰でもアクセスできるようになります。
開発者が「テスト用に一時的に公開」するつもりで設定を変更し、そのまま本番環境に移行してしまう、複数の担当者が関わる中で誰が設定を変更したか分からなくなる、設定画面が複雑で意図せず公開設定になってしまう、といったケースが頻発しています。
Shodanなどの検索エンジンや、専用のスキャンツールを使えば、公開されたS3バケットを簡単に発見できます。攻撃者は、バケット名の命名規則（company-backup、customer-dataなど）を推測して、自動的にスキャンしています。
データベースの認証不備
MongoDBやElasticsearch、Redisなど、NoSQLデータベースやキャッシュシステムの多くは、デフォルトで認証が無効になっています。これらをクラウド上に展開する際、認証を有効にせず、さらにファイアウォール設定で「すべてのIPアドレスからアクセス可能」にしてしまうと、誰でもデータベースにアクセスできます。
2017年から2019年にかけて、数千のMongoDBインスタンスとElasticsearchインスタンスが認証なしでインターネットに公開されているのが発見され、数億件のレコードが露出しました。医療記録、求人サイトの履歴書、ホテルの予約情報、IoTデバイスのデータなど、あらゆる種類の機密情報が含まれていました。
アクセス制御の設定ミス
IAM（Identity and Access Management）の設定不備により、不要な権限が付与されたり、過度に広範なアクセスが許可されたりします。「全員に管理者権限を付与」「特定のサービスに必要以上の権限を付与」「退職した従業員のアカウントが削除されずに残っている」などが典型的な問題です。
Capital Oneの事件では、WAF（Webアプリケーションファイアウォール）の設定不備により、本来は制限されるべき内部リソースへのアクセスが可能でした。攻撃者はこれを悪用して、サーバーロールの認証情報を取得し、S3バケットにアクセスしました。
セキュリティグループとファイアウォールの設定不備
クラウドのファイアウォール（Security GroupやNetwork Security Group）で、「0.0.0.0/0」（すべてのIPアドレス）からのアクセスを許可してしまうミスが頻発します。管理画面へのSSHやRDP、データベースポート、内部APIなど、本来は限定されたIPアドレスからのみアクセスを許可すべきリソースが、全世界に公開されます。
開発者が「自宅から一時的にアクセスするため」に設定を変更し、そのまま忘れてしまう、複数の環境（開発、テスト、本番）で設定が異なり、本番環境で誤った設定をしてしまう、といったケースがあります。
認証情報の露出
クラウドサービスへのアクセスキー、APIトークン、パスワードなどが、不適切な場所に保存されることで漏洩します。最も一般的なのは、ソースコードに直接埋め込んでGitHubやGitLabに公開してしまうケースです。
自動化されたボットが、GitHubに公開された新しいリポジトリを24時間監視しており、AWSのアクセスキーやAPIキーを発見すると、数分以内に悪用されます。2018年、ある開発者が誤ってAWSのアクセスキーをGitHubに公開し、数時間で約6,000ドルの不正利用が発生しました。
デフォルト設定のまま使用
クラウドサービスやソフトウェアをデフォルト設定のまま使用することも、クラウド設定不備の一種です。デフォルトのパスワード（admin/admin、root/passwordなど）を変更しない、サンプルアカウントを削除しない、不要なサービスを無効にしない、などが問題となります。
Kubernetesのダッシュボードが認証なしで公開されていたTeslaの事件では、攻撃者はデフォルト設定を悪用してアクセスしました。
クラウド設定不備の対策方法
クラウド設定不備の対策は、適切な初期設定、継続的な監視、従業員教育を組み合わせることが重要です。クラウド・ソフトの供給リスクとして、「設定して終わり」ではなく、常に見直し続ける必要があります。
組織として実施すべき基本対策として、最小権限の原則の徹底が最優先です。すべてのユーザー、サービス、アプリケーションには、業務に必要な最小限の権限のみを付与します。「とりあえず管理者権限を付与」は絶対に避けます。定期的に権限を見直し、不要になった権限は即座に削除します。
デフォルト拒否の原則により、ストレージ、データベース、APIなど、すべてのリソースはデフォルトで「非公開」「アクセス拒否」に設定し、必要な場合のみ、特定のIPアドレスやユーザーに対して明示的にアクセスを許可します。「必要になったら制限する」ではなく、「最初から制限し、必要なら開ける」という考え方が重要です。
インフラストラクチャー・アズ・コード（IaC）の活用として、Terraform、AWS CloudFormation、Azure Resource Managerなどを使い、クラウドリソースの設定をコードで管理します。これにより、設定の一貫性が保たれ、手作業による設定ミスを防げます。また、設定変更の履歴が残り、誰がいつ何を変更したか追跡できます。
自動化されたセキュリティスキャンの実装により、AWS Config、Azure Security Center、Google Cloud Security Command Centerなどのクラウドネイティブツールや、Prisma Cloud、Dome9、Cloudsplendeなどのサードパーティツールを使って、クラウド環境を24時間365日監視します。公開されたS3バケット、認証なしのデータベース、過度に広範なファイアウォールルールなどを自動的に検出し、アラートを発します。
秘密情報管理の徹底として、アクセスキー、APIトークン、パスワードなどをソースコードに直接書かない、環境変数やシークレット管理サービス（AWS Secrets Manager、Azure Key Vault、Google Cloud Secret Managerなど）を使用します。GitHubに誤ってプッシュしないよう、git-secretsなどのツールでコミット前にチェックします。
多要素認証とIPアドレス制限により、クラウドの管理画面へのアクセスには、必ず多要素認証を有効にします。さらに、管理画面へのアクセスは、オフィスのIPアドレスやVPN経由のみに制限します。
定期的な棚卸しとレビューとして、最低でも四半期に一度、すべてのクラウドリソース、IAM権限、ファイアウォールルール、公開設定などを総点検します。不要なリソースは削除し、過剰な権限は制限し、退職した従業員のアカウントは無効化します。
クラウドセキュリティ教育の徹底により、開発者、インフラ担当者、経営者を含む全従業員に、クラウドの責任共有モデル、基本的なセキュリティ設定、過去の事例などを教育します。特に、新しいクラウドサービスを導入する際は、セキュリティレビューを必須とします。
クラウド設定不備の対策を簡単に言うと？
家を建てる時の安全対策に似ています。まず、すべてのドアと窓に鍵をかけます（デフォルト拒否）。家族でも、必要な部屋にしか入れないようにします（最小権限）。「後で鍵をつける」ではなく、「最初から鍵付きのドアを設置」します。
設計図（IaC）に従って建てることで、建築ミスを防ぎます。セキュリティカメラ（自動スキャン）を設置し、24時間監視します。合鍵（認証情報）は玄関マットの下ではなく、金庫に保管します（シークレット管理）。
定期的に鍵を変え（ローテーション）、不要になった合鍵は回収します（権限の棚卸し）。家族全員に「戸締まりの重要性」を教育し（セキュリティ教育）、一人が忘れても他の人が気づける体制を作ります。
銀行（クラウドプロバイダー）は建物の警備をしてくれますが、貸金庫の鍵をかけるのはあなたの仕事です。クラウド・ソフトの供給リスクとして、利用者側の責任を理解し、基本的な設定を確実に実施することが最も重要です。
クラウド設定不備に関連した攻撃手法
クラウド設定不備は、クラウド・ソフトの供給リスクの中でも、他の攻撃手法の入口や関連要因として機能することが多い脆弱性です。
サプライチェーン攻撃は、クラウド設定不備によって大規模化・深刻化します。サプライチェーン攻撃では、ソフトウェアやサービスの供給過程に侵入し、多数の利用者を一度に攻撃します。クラウド設定不備がある場合、攻撃者はSaaS企業やソフトウェアベンダーのクラウド環境に侵入し、ソースコードにマルウェアを混入させたり、顧客データを一括で盗んだりできます。2020年のSolarWinds事件では、ビルドサーバーへの侵入により、正規のソフトウェア更新にバックドアが混入され、1万8千以上の組織が影響を受けました。この侵入の初期段階では、クラウド環境の設定不備が悪用された可能性が指摘されています。クラウド設定不備はサプライチェーン攻撃の「入口」であり、サプライチェーン攻撃はその結果として発生する「広範囲の被害」です。両者ともクラウド・ソフトの供給リスクとして、一つの組織の脆弱性が業界全体に影響を及ぼす危険性があり、サプライチェーン全体でのセキュリティ対策と継続的な監視が重要です。
公開バケット・共有の露出は、クラウド設定不備の最も典型的で具体的な表れです。公開バケット・共有の露出では、S3バケット、Azure Blob Storage、Google Cloud Storageなどが「パブリック公開」に設定され、誰でもデータにアクセスできる状態になります。これは、アクセス制御リストの設定ミス、バケットポリシーの誤設定、デフォルト設定の放置など、クラウド設定不備の具体的なパターンです。2019年の調査では、約7%のS3バケットが何らかの形で公開されていると報告されました。公開バケット・共有の露出は、顧客データ、財務記録、医療情報、企業秘密など、あらゆる種類の機密情報を世界中に晒します。クラウド設定不備は「概念」であり、公開バケット・共有の露出はその「具体的な発現形態」です。両者ともクラウド・ソフトの供給リスクとして、ストレージサービスの適切なアクセス制御設定、定期的な監査、自動スキャンツールによる検出が対策の鍵となります。
シークレット漏洩は、クラウド設定不備の一環として、または設定不備から派生して発生します。シークレット漏洩では、APIキー、アクセストークン、データベースパスワード、暗号化キーなどの機密認証情報が不適切に保存・公開されます。クラウド設定不備により、これらのシークレットがソースコード、設定ファイル、ログファイル、公開リポジトリ、環境変数の不適切な使用などから漏洩します。GitHubに誤ってAWSのアクセスキーをコミットする、環境変数を誤って公開バケットに保存する、ログに認証情報が記録される設定になっているなど、クラウド環境の管理不備がシークレット漏洩を引き起こします。一度漏洩したシークレットは、数分以内に自動スキャンボットに発見され、不正利用されます。クラウド設定不備は「管理体制の問題」であり、シークレット漏洩はその「結果として発生する具体的な情報漏洩」です。両者ともクラウド・ソフトの供給リスクとして、シークレット管理サービスの使用、定期的なローテーション、漏洩検知ツールの導入、開発者教育が重要な対策となります。
クラウド設定不備のよくある質問
クラウドサービスのインフラやプラットフォームは非常に高いセキュリティレベルで管理されていますが、利用者側の設定や使い方が不適切だと、データが危険にさらされます。これが「責任共有モデル」で、クラウドプロバイダーは「クラウドのセキュリティ」を、利用者は「クラウド内のセキュリティ」を担当します。
多くのクラウドサービスは、利便性を優先してデフォルト設定が緩く設定されていたり、セキュリティ設定が無効になっていたりします。また、一部のソフトウェアは初期パスワードが公開されており、それを変更しないと誰でもアクセスできます。必ずセキュリティ設定を確認し、強化する必要があります。
本当に公開が必要か再考し、可能であれば署名付きURLや CloudFront などを使って限定的なアクセスを提供します。どうしても公開する必要がある場合は、機密情報を含まない、定期的に監査する、アクセスログを確認するなどの対策を講じます。
AWS Config、Azure Security Center、Google Cloud Security Command Center などのクラウドネイティブツールや、Prowler、ScoutSuite などのオープンソースツールを使って、現在の設定をスキャンします。発見された問題を優先度順に修正していきます。
はい、自動化されたボットが24時間365日スキャンしており、脆弱な設定を発見すると数分から数時間以内に悪用を開始します。GitHubに誤ってAWSキーをアップロードした場合、数分で不正利用が始まることもあります。
いいえ、継続的な監視と見直しが必要です。新しいリソースが追加される、設定が変更される、新しい脆弱性が発見されるなど、状況は常に変化します。最低でも四半期に一度は全体を見直すべきです。
いいえ、開発環境やテスト環境も本番環境と同等のセキュリティ対策が必要です。これらの環境にも本番データのコピーが含まれることがあり、また、開発環境から本番環境への設定移行時にミスが発生しやすいためです。
はい、規模に関わらず必要です。むしろ、小規模な組織ほど一度の情報漏洩が致命的になりやすく、復旧リソースも限られているため、予防が重要です。最低限、公開設定の確認、強力なパスワード、多要素認証は必須です。
クラウドプロバイダーの公式ドキュメントやセキュリティベストプラクティスガイドを参考にする、AWS Well-Architected Framework などのフレームワークに従う、自動スキャンツールを導入して設定ミスを検出する、外部のセキュリティコンサルタントに定期的な診断を依頼するなどの方法があります。
サイバー保険によっては、一部の損害がカバーされることがありますが、「重大な過失」と判断されると免責となる可能性があります。基本的なセキュリティ対策を怠っていた場合、保険金が支払われないこともあります。保険よりも予防が重要です。
Infrastructure as Code（IaC）を使って設定を自動化し、設定の一貫性を保ちます。また、自動スキャンツールを導入して、定期的に設定をチェックし、問題があればアラートを発するようにします。人間のチェックは最終確認として行います。
まず、該当するリソースへのアクセスを即座に制限し、被害の拡大を防ぎます。次に、アクセスログを確認して不正利用がなかったか調査します。そして、同様の設定不備が他にないか全体をスキャンし、再発防止策を実施します。重大な情報漏洩が発生した場合は、法的義務に基づき報告や通知を行います。
更新履歴
- 初稿公開