社内のSaaS利用が増えるにつれて、IT部門の管理範囲は急速に拡大しています。Google Workspace、Microsoft 365、Salesforce、Slack、Zoom、Box、Dropbox、Notion、kintone、Asana。1社で50〜100以上のSaaSが日常的に使われるのは、もはや珍しくありません。

しかし、利用が広がる速度に対して、セキュリティ管理が追いついていないケースが目立ちます。退職者のアカウントが残り続ける、共有設定が「リンクを知っている全員」になっている、外部ベンダーに付与した権限が削除されない。こうした穴から情報が漏れ出す事故が、毎月のように報じられています。

本記事では、SaaSにおけるデータ漏洩リスクの全体像を、情シス担当者の視点で整理します。発生メカニズムを構造的に理解したうえで、具体的な対策フレームワークと、実装に役立つソリューションを紹介します。

対象読者は、複数のSaaSを管理する情シス担当者、CISO、セキュリティ部門のマネージャーです。

SaaSデータ漏洩リスクが高まる背景

SaaSデータ漏洩リスクとは、クラウド型業務アプリケーションに保管された機密情報・個人情報・営業情報が、想定外の第三者に取得・閲覧・改ざん・流出される危険性を指します。リスクが高まっている理由は、利用するSaaSの数と、扱うデータの機微性が同時に増しているためです。

総務省「令和6年通信利用動向調査」によれば、企業のクラウドサービス利用率（全社利用＋一部利用の合計）は80.4%に達しました。1社あたり平均で50を超えるSaaSを契約する企業も珍しくなく、IT部門の管理対象は飛躍的に増えています。一方で、人員はほぼ横ばいです。

加えて、SaaSは「契約すればすぐ使える」性質上、現場の判断で導入されるケースが増えています。情シスを通さない契約、いわゆるシャドーITは、可視化できない領域を拡大させ、ガバナンスの空白地帯をつくります。

リスクが顕在化する典型的な場面は3つあります。

• 設定ミスによる外部公開（共有リンク、バケットの公開設定）
• 退職者・外部委託先のアカウント削除漏れ
• ID/パスワードの使い回しによる不正ログイン

これらは技術的な高度な攻撃よりも、運用上の見落としで発生するものが大半です。「攻撃を受けた」というより「自ら鍵を開けていた」状態に近く、対策の出発点は技術投資ではなく運用整備にあります。

参考：クラウドサービスの利用動向（総務省）

SaaSデータ漏洩の主な原因

漏洩の入口は限定的です。攻撃の手口は多様に見えても、原因を整理すると以下の6パターンに集約されます。それぞれの仕組みを理解することで、対策の優先順位が明確になります。

設定ミス（コンフィギュレーションエラー）

クラウドストレージや業務SaaSの共有設定が、本来「特定ユーザーのみ」とすべきところで「リンクを知る全員」「組織全体」になっているケースです。Google Driveの共有設定、AWS S3バケットの公開設定、Box・OneDriveのリンク共有が代表例で、Verizon「2024 Data Breach Investigations Report」によれば、設定ミスを含む「Miscellaneous Errors」は依然としてデータ漏洩の主要パターンの1つに数えられています。

設定ミスは悪意のない単純ミスから生まれるため、教育や注意喚起だけでは防ぎきれません。CSPM（Cloud Security Posture Management）やSaaS Security Posture Management（SSPM）など、設定状態を継続的に監視する仕組みの導入が現実的な対策となります。

権限過多（Excessive Permissions）

業務上必要な範囲を超えた権限を、利用者やAPI連携アプリケーションに付与してしまうケースです。「念のため管理者権限」「とりあえず全フォルダ閲覧可」のような運用が積み重なり、内部不正や認証情報侵害時の被害を拡大させます。

最小権限の原則（Principle of Least Privilege）を徹底し、定期的なアクセス権レビュー（Access Certification）で過剰権限を棚卸しする仕組みが必要です。

退職者・異動者のアカウント残存

退職者のアカウントが削除されず、月単位で稼働し続けているケースは多くの企業で発生しています。人事システムとSaaSが連携していない環境では、退職連絡から削除までに数日〜数週間のタイムラグが生まれ、その間に内部情報が持ち出される事例が後を絶ちません。

人事マスタを起点としたアカウントライフサイクル自動化（プロビジョニング・デプロビジョニング）が、根本対策となります。

認証情報の漏洩・使い回し

社員個人の不注意によるパスワード漏洩、フィッシング被害、別サービスからの流出パスワードの使い回しなど、認証情報そのものが奪われるケースです。MFA（多要素認証）が設定されていないSaaSでは、IDとパスワードだけでログインを許してしまうため、攻撃者にとって最も狙いやすい入口になります。

IDaaSによるSSO・MFA・条件付きアクセスポリシーの統一が有効です。

シャドーIT・シャドーAI

情シスの承認を得ずに、現場が独自に契約・利用するSaaSやAIツールが、企業データを社外に流出させるルートになります。無料のオンラインPDF変換、ChatGPT等の生成AI、個人アカウントのファイル共有サービスが典型例で、契約形態や設定によっては、入力データが外部処理・学習利用の対象となる可能性があります。

CASB（Cloud Access Security Broker）でアクセスログを可視化し、許可リスト・拒否リストの管理を行う必要があります。

サプライチェーン攻撃

利用しているSaaSベンダー自身、あるいはその取引先・委託先がサイバー攻撃を受け、自社データが二次的に漏洩するケースです。SaaSベンダーの管理が及ばない領域のため、契約時のセキュリティ評価（SOC 2、ISO 27001、ISMAP等）と、漏洩時の通知義務・損害賠償条項の整備が重要になります。

参考：2024 Data Breach Investigations Report（Verizon）

SaaSデータ漏洩の代表事例

典型的なパターンをもとにした想定事例を3つ取り上げます。原因の多くは「特殊な攻撃」ではなく、設定や運用の見落としに起因します。事例を通じて、自社で同じパターンが発生していないかを点検することが、対策の出発点になります。

設定ミスによる大量公開（クラウドストレージ）

国内大手企業で、Google系のクラウドストレージの共有設定が誤って外部公開され、数十万件規模の取引先情報や顧客情報が、検索エンジンに一時的にインデックスされる事故が複数報告されています。原因は「アクセス権設定の誤認識」と「定期点検の不在」で、悪意ある攻撃ではなく内部運用の不備でした。

教訓は、共有設定を「申請型」かつ「期限付き」にすることと、設定状態を機械的に監査する仕組みを導入することです。

退職者アカウントからの情報持ち出し

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

教訓は、退職予兆検知（大量ダウンロード・アクセス先変更等の異常検知）と、退職プロセスのアカウント停止を「即時」かつ「自動」で実施することです。

MFA未設定アカウントへの不正ログイン

中堅企業のSaaS管理者アカウントが、フィッシングで奪取されたパスワードを使い不正ログインされ、社員数百名分のメール本文と添付ファイルが外部に送信された事例です。MFAが設定されていれば防げた典型的なケースで、被害発覚から復旧までに数週間を要しました。

教訓は、特に管理者・役員アカウントへのMFA必須化と、ログインアラート（普段と異なる地域・時間帯）の自動通知を整備することです。

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

SaaSデータ漏洩がもたらす影響

データ漏洩は、直接的な金銭被害だけでなく、組織運営の複数の領域に長期的な影響を残します。事業を止めるリスクとして経営層に説明する際、以下の4軸で整理すると理解されやすくなります。

直接的な金銭被害

漏洩発生時の第一の損害は、調査・通知・復旧にかかる費用です。フォレンジック調査、漏洩対象者への通知、コールセンター開設、再発防止策の導入で、数千万〜数億円規模になる事例があります。IBM「Cost of a Data Breach Report 2024」では、世界平均で1件あたり488万ドル（約7.3億円）に達しています。

法令違反による行政処分

個人情報保護法では、要配慮個人情報や財産的被害が生じうる漏洩は、個人情報保護委員会への報告と本人への通知が義務化されています（2022年改正施行）。また、2026年4月に閣議決定された改正法案では、違反に対する課徴金制度の新設が盛り込まれており、罰則強化の方向で規制整備が進んでいます。GDPR適用案件では、全世界年間売上高の最大4%が制裁金として課されます。

取引先からの信頼喪失

エンタープライズ企業や金融機関は、取引先のセキュリティ評価を厳格化しています。漏洩発生は契約解除・新規取引停止の直接的な要因となり、過去数年の漏洩履歴が今後数年の商談機会を奪うリスクがあります。

株価・ブランド毀損

上場企業の場合、漏洩発覚時の株価下落は数%〜十数%に達する事例があります。経営責任を問われる調査委員会の設置、訴訟対応、メディア対応は経営層の時間を奪い、本業の意思決定を停滞させます。

教訓を整理すると、「漏洩は金銭被害」ではなく「事業継続リスク」として扱うべきテーマです。

参考：Cost of a Data Breach Report 2024（IBM） 参考：個人情報保護法ガイドライン（個人情報保護委員会）

SaaSデータ漏洩を防ぐ5つの対策フレームワーク

漏洩対策は単一施策では機能しません。「人」「ID」「データ」「設定」「監査」の5領域を順序立てて整備することで、抜けのない防御線が構築できます。情シスが現場で運用しやすいフレームワークとして整理します。

ステップ1: SaaS利用の可視化

社内で使われているSaaSを棚卸しすることが、すべての出発点です。経費精算データ、SSOログ、ネットワーク機器ログ、CASBログを突合し、契約済み・未契約（シャドーIT）を区別します。可視化なしには、後続の対策が抜け漏れだらけになります。

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

IDaaSを基盤に、SSOで認証経路を統一し、MFAを必須化します。条件付きアクセス（IPアドレス・デバイス・時間帯による制御）で、リスクの高い経路を遮断します。管理者アカウント・サービスアカウントは別管理とし、特権アクセス管理（PAM）の対象に含めます。

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

人事マスタを起点に、入社時のアカウント発行と権限付与、異動時の権限変更、退職時の即時停止・削除を自動化します。SCIM対応SaaSであれば、IDaaSやSMP経由でプロビジョニングをコード化できます。手作業を排除することが、削除漏れの根本対策になります。

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

CSPM・SSPMで、各SaaSの公開設定・権限設定・パスワードポリシー・MFA設定を継続的に監査します。逸脱を検知したら情シスへアラート、自動修復ポリシーを設定するのが理想形です。設定変更の履歴をログとして残し、監査証跡として活用します。

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

四半期〜半期に1度、アクセス権の棚卸しを行います。Identity Governance and Administration（IGA）製品の認証フローで、上長承認を経た棚卸しを記録に残します。各SaaSの監査ログをSIEMに集約し、異常アクセスの検知・通知を自動化します。

参考：NIST SP 800-207 Zero Trust Architecture（NIST） 参考：サイバーセキュリティ経営ガイドライン Ver3.0（経済産業省）

SaaSデータ漏洩対策に役立つ主要ソリューション

漏洩対策を実装する代表的な製品カテゴリを整理します。各カテゴリの役割と、選定時の観点をまとめます。

IDaaS（Identity as a Service）

SSO・MFA・条件付きアクセスを統合提供するクラウド認証基盤です。代表製品はMicrosoft Entra ID、Okta、Google Cloud Identity。社員のSaaSログイン経路を一元化し、認証情報の使い回しや紛失リスクを抑えます。

CASB（Cloud Access Security Broker）

社員のSaaS利用ログを可視化・制御するゲートウェイです。代表製品はMicrosoft Defender for Cloud Apps、Netskope、Zscaler CASB。シャドーIT検出、データ持ち出し制御、機密情報のアップロード遮断に有効です。

SSPM（SaaS Security Posture Management）

主要SaaSの設定状態を継続監視し、ベストプラクティスとの差分を検知します。代表製品はAppOmni、Adaptive Shield、Wing Security。設定ミスによる漏洩を、運用負荷を抑えて防ぐ用途に向いています。

IGA（Identity Governance and Administration）

アクセス権ガバナンスを支援する基盤です。代表製品はSailPoint、Saviynt、Microsoft Entra ID Governance。アクセス申請ワークフロー、定期的な権限棚卸し、職務分離（SoD）違反の検知などを提供します。

DLP（Data Loss Prevention）

機密データの定義と、その持ち出し・送信を検知・遮断します。Microsoft Purview DLP、Symantec DLP、Forcepoint DLPなどがあります。クレジットカード番号、マイナンバー、社外秘ドキュメントの流出リスクを技術的に低減します。

SaaS管理プラットフォーム（SMP）

SaaSの契約・利用・アカウントを統合管理するプラットフォームです。代表製品はジョーシス、Admina、Zluri。アカウントライフサイクル、コスト最適化、シャドーIT検出を1つのコンソールで実現します。

ジョーシスの特徴と漏洩対策への貢献

ジョーシスは、SaaS・デバイス・人を一元管理するAI駆動のSMPです。350以上のSaaSと連携し、アカウントの可視化・自動プロビジョニング・退職時の即時停止を実現します。導入企業数は国内外700社を超え、IT工数を最大50%、ITコストを最大75%削減した事例が報告されています。

漏洩対策の観点では、退職者アカウントの放置・権限過多・シャドーIT検出という3大リスクを単一プラットフォームで解消できる点が強みです。人事マスタとの連携、アクセス権棚卸しの自動化、利用状況の可視化により、運用負荷を増やさずにガバナンスを強化できます。

参考：ジョーシス公式サイト

SaaSデータ漏洩リスクの全体像を5分で把握し、ジョーシスがどう解消するかを知りたい方は、以下から資料をダウンロードください。

5分でわかるJosys（資料ダウンロード）

SaaSデータ漏洩対策の用語集

記事内で頻出する専門用語を整理します。経営層への説明資料を作成する際の用語リファレンスとしても活用できます。

• IDaaS（Identity as a Service）: クラウド型のID統合管理サービス。SSO・MFA・プロビジョニングを統合提供する
• CASB（Cloud Access Security Broker）: SaaS利用ログを可視化・制御するゲートウェイ。シャドーIT検出やデータ持ち出し制御を担う
• SSPM（SaaS Security Posture Management）: SaaSの設定状態を継続監視し、誤設定・逸脱を検知する仕組み
• IGA（Identity Governance and Administration）: アクセス権の付与・棚卸し・職務分離を統合管理するガバナンス基盤
• DLP（Data Loss Prevention）: 機密データの社外持ち出しを技術的に検知・遮断する仕組み
• 最小権限の原則: 業務に必要な最小限の権限のみを付与する原則。Principle of Least Privilege
• SoD（Segregation of Duties）: 職務分離。同一人物に承認・実行・監査の3権限を集中させない統制
• プロビジョニング: アカウント発行・権限付与の自動化。デプロビジョニングは削除側の自動化
• SCIM（System for Cross-domain Identity Management）: ID情報をシステム間で同期する標準プロトコル
• シャドーIT/シャドーAI: 情シスの承認を得ずに現場が独自に契約・利用するSaaSやAIサービス

ジョーシスを活用したSaaS統合管理

複数のSaaSにまたがる漏洩対策を、個別ツールの組み合わせだけで運用すると、情シスの作業負荷は跳ね上がります。SaaS管理プラットフォームでアカウント・利用・コストを一元化することで、漏洩リスクの低減と運用工数の削減を同時に実現できます。

ジョーシスは、AIを活用したSMPとして、SaaS・デバイス・人の3軸を統合管理します。350以上のSaaS連携、人事マスタとの自動同期、退職時の即時アカウント停止、アクセス権の定期棚卸しを単一コンソールで提供します。

導入効果として、事例によってはIT工数を最大50%・ITコストを最大75%削減したケースがあり（効果は個社の状況により異なります）、導入企業は国内外700社以上（2026年5月時点）に広がっています。

漏洩対策の文脈では、以下の機能が直接的な貢献となります。

• アカウントライフサイクルの自動化により、退職者アカウントの残存を構造的に解消
• 利用状況の可視化により、シャドーITやアイドルアカウントを継続的に検出
• アクセス権棚卸しの自動化により、過剰権限の蓄積を防止
• 契約・コスト・利用状況の統合管理により、情シスがガバナンスとコスト最適化を同時に実現

製品の詳細を知りたい方、導入事例を確認したい方は、以下から資料をダウンロードください。

5分でわかるJosys（資料ダウンロード）

‍無料デモを予約する

SaaSデータ漏洩リスクに関するよくある質問

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

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

Q2. SaaSベンダー側のセキュリティ対策だけでは不十分ですか

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

Q3. MFAを導入しても漏洩は防げますか

MFAは認証経路からの侵入を大幅に減らしますが、それだけでは不十分です。設定ミスによる外部公開、社員による意図的な情報持ち出し、サプライチェーン攻撃などはMFAではカバーできないため、CASB・SSPM・IGAなど複数レイヤーでの対策が必要になります。

Q4. 漏洩発生時に最初にすべき対応は何ですか

被害拡大の遮断です。具体的には影響範囲の特定、該当アカウントの停止、ネットワーク経路の遮断、関連SaaSのログ保全を優先します。並行して経営層・法務・広報への第一報、個人情報保護委員会への報告準備（個人情報保護法では速報3〜5日・確報30日が目安）を進めます。事前にインシデントレスポンス計画を整備しておくことが、初動の速度を決めます。

Q5. SaaS管理プラットフォーム（SMP）はどんな企業に向きますか

利用SaaSが20以上、または従業員数が100名以上の企業に効果が高いと言われています。SaaSの数と利用者数が増えるほど、手作業での管理は破綻しやすく、SMP導入のROIが高くなります。情シスのリソースが限られている企業ほど、自動化による効果が大きく出ます。

まとめ

SaaSデータ漏洩は、特殊な攻撃ではなく運用上の見落としから発生します。設定ミス、権限過多、退職者アカウント残存、認証情報漏洩、シャドーIT、サプライチェーン攻撃。原因は限定的であり、対策の方向性は確立されています。

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

情シスの工数を増やさずに漏洩リスクを下げるためには、SaaS管理プラットフォーム（SMP）でアカウント・利用・コストを統合管理する選択が現実的です。ジョーシスはそのカテゴリでAI駆動の管理基盤を提供し、SaaS・デバイス・人を1つのコンソールで運用できる製品として、漏洩対策と運用効率化の双方に貢献します。

5分でわかるJosys（資料ダウンロード）

無料デモを予約する