クラウドサービスの普及に伴い、情報漏洩の公表事案は増加傾向にあります。「設定ミスで取引先情報が公開状態になった」「退職者のアカウントから営業データが持ち出された」「ベンダーの脆弱性で顧客データが流出した」。原因は限定的ですが、被害規模と社会的影響は事業継続を揺るがすレベルに達しています。

事故が発生する企業に共通する特徴は、対策が「ベンダー任せ」「個別判断頼み」になっている点です。責任共有モデル、設定の継続監視、アカウントライフサイクル管理、ベンダー評価といった基本的な仕組みを整えていないと、誰でも被害者になる可能性があります。

本記事では、近年公表されているクラウドサービス情報漏洩の代表的なパターンを整理し、原因別に再発防止策を解説します。情シスが自社の体制を点検する際のチェックポイントとしても活用できる構成にしました。

クラウドサービスにおける情報漏洩の現状

クラウドサービスにおける情報漏洩とは、SaaS・IaaS・PaaSに保管された機密情報・個人情報・営業情報が、想定外の第三者に取得・閲覧・流出される事案を指します。被害規模は1事案で数万〜数億件に及ぶケースもあり、組織への金銭的・社会的損害は深刻なレベルにあります。

個人情報保護委員会の公開資料では、漏洩事案件数は近年高止まりで推移しています。原因の内訳は誤送信・誤交付などの人的ミスが多くを占めますが、クラウドサービスの設定ミスや不正アクセスに起因する大規模な漏洩事案も複数報告されています。

クラウド特有の漏洩リスクが高まる背景は3つあります。第1に、クラウドサービスの利用拡大で、管理対象のデータと設定項目が爆発的に増えました。第2に、SaaS間連携・APIキー・OAuth等の認証情報が増え、漏洩経路が多様化しました。第3に、責任共有モデルにより、ベンダー責任と利用企業責任の境界が複雑化し、利用企業側の対応漏れが発生しやすくなっています。

参考：個人情報の漏えい等事案発生件数（個人情報保護委員会）

漏洩事例の代表パターン（原因別）

公表されている漏洩事案を原因別に整理すると、以下の6パターンに集約されます。それぞれの仕組みを理解することで、自社で同じパターンが発生する可能性を点検できます。

パターン1: クラウドストレージの設定ミス

代表的なパターンの一つです。Google Drive、AWS S3、Box、Dropbox等の共有設定が誤って「リンクを知る全員」「公開」になり、検索エンジンに一時的にインデックスされる事故が複数報告されています。

代表的な事例は、自治体・医療機関・大企業で発生した「クラウド上の文書が公開状態」という構成です。原因は申請プロセスなしの個人判断による設定変更、デフォルト設定の理解不足、定期点検の不在です。

パターン2: 認証情報の漏洩・使い回し

ID・パスワードがフィッシング被害、別サービスからの流出、内部関係者の持ち出しによって攻撃者の手に渡るケースです。MFA未設定の管理者アカウントが奪われ、組織全体のSaaSデータが流出した事例が複数報告されています。

パターン3: 退職者アカウントの放置

退職者のアカウントが削除されず、退職後数か月にわたって稼働し続け、個人情報を持ち出された事例です。発覚は転職先での営業活動を受けた取引先からの問い合わせが多く、被害発覚までに長期間を要する特徴があります。

パターン4: API・連携アプリの脆弱性

クラウドサービスとの外部連携で利用されるAPIキー・OAuthトークンが、コード内ハードコーディングやGitHub公開リポジトリへのコミットで流出するケースです。攻撃者がトークンを使ってデータを大量取得する事案が報告されています。

パターン5: サプライチェーン攻撃

利用しているSaaSベンダーまたはその取引先が攻撃を受け、自社データが二次的に流出するケースです。ベンダー側の脆弱性、委託先の不正アクセス、買収・統合に伴うセキュリティギャップなど、複数の経路が存在します。

パターン6: 内部不正・ヒューマンエラー

退職予定者・不満を持つ従業員による意図的な情報持ち出しと、誤送信・誤公開による意図しない漏洩の双方を含みます。アクセス権限内での操作のため検知が難しく、操作ログの定期分析でしか発見できないケースが多くなっています。

参考：2024 Data Breach Investigations Report（Verizon）

事例から学ぶ：設定ミスによる大量公開

設定ミスを原因とする漏洩は、代表的な発生パターンの一つです。実際に近年公表された事例の構造を整理します。

典型的な事象パターン

ある組織のクラウドストレージに保管された取引先情報・個人情報を含む文書が、共有設定の誤りにより、URLを知れば誰でも閲覧できる状態に置かれました。検索エンジンによってインデックスされ、外部からの指摘で初めて発覚するケースが多くなっています。

被害件数が大規模化するケースがあり、対象者への通知、コールセンター対応、調査委員会設置、再発防止策の策定で、大きな対応コストが生じることがあります。

発生原因の構造分析

3つの原因が重なって発生します。第1に、共有設定の選択肢の複雑さ。「組織内のみ」「特定ユーザーのみ」「リンクを知る全員」「公開」といった複数の段階があり、業務担当者の理解不足から誤選択が起きやすい構造です。第2に、設定状態の継続監視が不在。一度設定された共有設定が時間経過とともに見直されず、放置される運用です。第3に、申請・承認プロセスの欠如。個人判断で設定変更が可能な環境では、誤設定の発生確率が高まります。

再発防止策

3層で対応します。

• 技術的対策: SSPM・CSPM導入による設定状態の継続監視、誤設定の自動検知とアラート
• プロセス対策: 共有設定変更の申請・承認ワークフロー、定期的な設定棚卸し、外部公開設定の期限化
• 教育対策: 共有設定の意味と影響範囲を伝える社内研修、誤設定発生時の事例共有

参考：個人情報の漏えい等事案発生件数（個人情報保護委員会）

事例から学ぶ：認証情報侵害と退職者アカウント

認証情報侵害と退職者アカウント残存は、運用上の見落としが原因となる代表パターンです。

認証情報侵害の典型パターン

中堅企業の管理者アカウントが、フィッシングメールで奪取されたパスワードを使い不正ログインされる事例があります。MFAが未設定だったため、ID/パスワードのみで管理画面に侵入され、社員数百名分のメール本文・添付ファイルが外部送信される事故が報告されています。

復旧には数週間を要し、対応費用は数千万円規模に及びます。被害は技術面だけでなく、取引先への謝罪・契約見直し、株価への影響まで広範に及びます。

退職者アカウント放置の典型パターン

退職予定の社員が、最終出社日までの期間にクラウドストレージから営業データを大量にダウンロードし、競合他社への転職後に活用したと推定される事例があります。発覚は、転職先からの営業活動を受けた取引先からの問い合わせによるもので、被害発覚までに数か月を要しました。

退職後にアカウントが停止されないまま稼働し続け、その間にも情報持ち出しが続いていたケースもあり、被害規模は大きくなりがちです。

再発防止策

認証情報侵害に対しては、以下が有効です。

• 全社員へのMFA必須化、特に管理者・役員アカウントは強固な認証（FIDO2、ハードウェアキー）
• IDaaSによる認証経路の統一、条件付きアクセス（IPアドレス・デバイス・時間帯）の設定
• ログイン異常の自動検知（普段と異なる地域・時間帯）、即時アラート
• 定期的なフィッシング訓練、教育コンテンツの更新

退職者アカウント放置に対しては、以下が有効です。

• 人事マスタを起点とした自動プロビジョニング・デプロビジョニング
• 退職予兆検知（大量ダウンロード、外部送信の異常増加）
• 退職処理チェックリストの標準化、24〜72時間以内の即時停止
• アクセス権の四半期レビュー、休眠アカウントの自動検出

参考：サイバーセキュリティ経営ガイドライン Ver3.0（経済産業省）

事例から学ぶ：API・サプライチェーン攻撃

近年急増しているのが、API・OAuthトークンの漏洩と、サプライチェーン攻撃による二次被害です。

API・OAuthトークン漏洩の典型パターン

開発者がGitHubの公開リポジトリにAPIキーをコミットしてしまい、攻撃者が自動探索ツールでこれを発見し、不正利用するケースがあります。クラウドストレージ・データベースから機密情報が大量取得され、被害発覚までに時間を要する特徴があります。

OAuth連携アプリへの過剰な権限付与も類似のリスクです。利用者が「便利そう」という理由で個人判断で連携を承認した結果、メール本文・連絡先・ファイルへの読み取り権限を第三者アプリに与えてしまうケースが報告されています。

サプライチェーン攻撃の典型パターン

利用しているSaaSベンダー、またはそのソフトウェアサプライヤーが攻撃を受け、自社データが二次的に漏洩する事例です。ベンダーの脆弱性、ベンダーが利用するライブラリの脆弱性、ベンダーの委託先の不正など、攻撃経路は多岐にわたります。

ベンダー側で被害が発覚しない期間が長引くと、利用企業側でも認識が遅れ、対応の初動が遅延する問題があります。

再発防止策

API・OAuthトークン漏洩に対しては、以下が有効です。

• ソースコード管理の自動スキャン（GitGuardian、TruffleHog等）
• APIキー・トークンの定期ローテーション、短期間有効化
• OAuthアプリ承認の管理プロセス（管理者承認、利用範囲の制限）
• 利用中の連携アプリの定期棚卸し、不要連携の削除

サプライチェーン攻撃に対しては、以下が有効です。

• ベンダーの第三者認証（ISO27001、SOC 2、ISMAP）の取得状況確認
• 契約条項でのインシデント通知義務（24〜72時間）の明記
• 主要ベンダーの公表情報、脆弱性情報の継続監視
• 二次的なベンダー（サブプロセッサ）の開示要求

参考：サプライチェーン攻撃対策（IPA）

クラウド情報漏洩を防ぐ再発防止フレームワーク

漏洩を防ぐ取り組みは、単発の施策では効果が限定的です。「人」「ID」「データ」「設定」「監査」の5領域を順序立てて整備するフレームワークが、抜けのない防御線を構築します。

ステップ1: クラウド利用の可視化

社内で使われているSaaS・IaaS・PaaSを棚卸しします。経費精算データ、SSOログ、ネットワーク機器ログ、CASBログを突合し、契約済み・未契約（シャドーIT）を区別します。

ステップ2: ID・アクセス管理の統一

IDaaSを基盤に、SSOで認証経路を統一、MFAを必須化します。条件付きアクセスでリスクの高い経路を遮断します。管理者アカウント・サービスアカウントは別管理とし、PAMの対象に含めます。

ステップ3: アカウントライフサイクルの自動化

人事マスタを起点に、入社時の発行と権限付与、異動時の権限変更、退職時の即時停止・削除を自動化します。SCIM対応SaaSであれば、IDaaSやSMP経由でプロビジョニングをコード化できます。

ステップ4: 設定状態の継続監視

CSPM・SSPMで、各SaaS・IaaSの公開設定・権限設定・パスワードポリシー・MFA設定を継続的に監査します。逸脱を検知したら情シスへアラート、自動修復ポリシーを設定するのが理想形です。

ステップ5: アクセス権定期レビューと監査ログ統合

四半期〜半期に1度、アクセス権の棚卸しを実施します。各SaaSの監査ログをSIEMに集約し、異常アクセスの検知・通知を自動化します。インシデントレスポンス計画も策定し、年1〜2回のテーブルトップ演習で実効性を確認します。

参考：NIST SP 800-207 Zero Trust Architecture（NIST）

クラウド情報漏洩対策に関連する用語集

記事内で頻出する専門用語を整理します。

• 責任共有モデル: クラウドの責任分界点。基盤側はベンダー、設定・データ側は利用企業
• CSPM: Cloud Security Posture Management。IaaS/PaaSの設定状態を継続監視
• SSPM: SaaS Security Posture Management。SaaSの設定状態を継続監視
• IDaaS: クラウド型ID統合管理。SSO・MFA・プロビジョニングを統合提供
• IGA: Identity Governance and Administration。アクセス権ガバナンス基盤
• DLP: Data Loss Prevention。機密データの社外持ち出しを技術的に検知・遮断
• PAM: Privileged Access Management。特権アクセス管理
• フィッシング: 偽サイト・偽メールで認証情報を窃取する攻撃
• サプライチェーン攻撃: ベンダー・委託先を経由した二次的な攻撃
• リーガルホールド: 訴訟・調査対応のためのデータ保全措置
• インシデントレスポンス: セキュリティ事案発生時の対応計画

ジョーシスを活用した漏洩リスク低減

漏洩対策はSaaS・デバイス・人を統合的に管理することで、運用負荷を増やさずに防御線を構築できます。個別ツールの組み合わせだけで運用すると、情シスの作業負荷は跳ね上がります。

ジョーシスは、SaaS・デバイス・人を一元管理するAI駆動のSMPです。漏洩対策の文脈では、以下の機能が直接的な貢献となります。

• 利用SaaSの自動可視化: シャドーIT検出を含むSaaS利用状況の可視化を支援
• アカウントライフサイクル: 入退社に伴うアカウント発行・停止・削除の自動化を支援、過剰権限の蓄積防止
• ライセンス管理: 休眠アカウント・未利用ライセンスの継続監視
• 監査ログ: アカウント・権限変更履歴を一元保管、監査対応資料に活用
• IDaaS・MDM連携: 既存のセキュリティ製品と統合運用

導入企業数は国内外700社を超え、事例によっては、IT工数の最大50%削減、IT管理コストの最大75%削減につながった報告もあります。350以上のSaaSアプリと連携可能で、漏洩対策と運用効率化を同時に実現できます。

Josysの製品概要を5分で理解する資料をダウンロードする

Josysの無料デモを予約して、自社の課題に合うかを確認する

クラウド情報漏洩対策に関するよくある質問

Q1. 中小企業でも漏洩対策は必要ですか

必要です。むしろ中小企業はセキュリティ投資が手薄になりがちなため、攻撃者にとって相対的に侵入しやすい標的と認識されています。サプライチェーン攻撃の踏み台として狙われる事例も増えており、規模に関係なく最低限の対策は必須です。

Q2. クラウドベンダー側のセキュリティ対策で十分ではないですか

不十分です。責任共有モデルでは、ベンダーは「クラウド基盤の安全性」、利用企業は「ユーザー側の設定・アカウント管理」に責任を負います。設定ミス・権限過多・退職者アカウント残存はすべて利用企業側の対策範囲です。

Q3. 漏洩発覚時の初動で最も重要なことは何ですか

被害拡大の遮断です。具体的には影響範囲の特定、該当アカウントの停止、ネットワーク経路の遮断、関連SaaSのログ保全を最優先で実施します。並行して経営層・法務・広報への第一報、個人情報保護委員会への速報（発覚後3〜5日以内）・確報（原則30日以内、不正目的のおそれがある場合は60日以内）の準備を進めます。

Q4. 法令上、漏洩発生時に報告義務はありますか

あります。個人情報保護法では、要配慮個人情報の漏洩、財産的被害が生じうる漏洩、不正目的のおそれがある漏洩、1,000人超の漏洩は、個人情報保護委員会への報告と本人への通知が義務化されています。違反すると、勧告・命令の公表対象になる場合があります。なお、課徴金制度の創設を含む改正法案が2026年に閣議決定・国会提出されており、今後の審議・施行動向に注意が必要です。

Q5. 漏洩対策の社内予算を確保するにはどう経営層に説明すべきですか

「漏洩は金銭被害」ではなく「事業継続リスク」として説明することが効果的です。直接的な対応コスト（数千万〜数億円）に加え、行政処分、取引先からの信頼喪失、株価下落、経営陣の時間消費といった間接的な損失を含めて、ROIで議論します。

まとめ

クラウドサービスの情報漏洩は、特殊な攻撃ではなく運用上の見落としから発生するケースが大半です。設定ミス、認証情報侵害、退職者アカウント放置、API・OAuthトークン漏洩、サプライチェーン攻撃、内部不正の6パターンを把握し、自社の体制に当てはめて点検することが対策の出発点になります。

重要なのは、単発施策ではなく「可視化→ID統合→ライフサイクル自動化→設定監視→定期監査」の5ステップを順序立てて実装することです。IDaaS・CASB・SSPM・IGA・DLP・SMPといった製品カテゴリを役割に応じて組み合わせ、自社の規模と運用に合った構成を設計します。

情シスの工数を増やさずに漏洩リスクを低減したい方は、SaaS統合管理基盤の活用を検討してください。詳細はジョーシスの資料を参照ください。

Josysの製品概要を5分で理解する資料をダウンロードする

Josysの無料デモを予約して、自社の課題に合うかを確認する