侵害事例に学ぶグローバルSaaSの選定基準

セキュリティ対策・運用
イメージ写真

業務に欠かせないグローバルなSaaS（クラウドサービス）。便利な一方で、利用者は中身を自社で監査できないという根本的な制約があります。しかも近年は、ベンダー本体が堅牢でも、利用者側の設定・サービス間の連携・サポート経路の隙が突かれる事例が相次いでいます。

本記事は、実際のSaaS侵害事例（Snowflake・Okta・Salesloft）を題材に、SaaSを「導入する前」に見るべき選定・委託先管理の基準を、情シス担当者向けに事実ベースで整理します。

この記事でわかること

  • なぜSaaSは「選定」と「委託先管理」で差がつくのか
  • タイプの異なる3つの侵害事例とそれぞれの教訓
  • SaaS選定・契約・運用で具体的に確認すべき基準

なぜSaaSは「選定」で差がつくのか

SaaSはセキュリティが「共有責任」だからです。サービス基盤の安全はベンダーの責任ですが、アカウント設定・アクセス管理・他サービスとの連携は利用者側の責任です。さらに、1つのSaaSの障害が数百〜数千の利用組織に同時に波及し、SaaS同士の連携を通じて被害が連鎖することもあります。だからこそ、導入時の選定と日々の委託先管理が現実的な防衛線になります。

事例1：認証情報の悪用 × MFA未設定（Snowflake型・2024年）

データ基盤SaaSのSnowflakeで、2024年に大規模なデータ窃取が起きました。重要なのは、Snowflakeの基盤自体が破られたのではないという点です。

  • 攻撃者は、情報窃取マルウェアで過去に盗まれた認証情報を使い、多要素認証(MFA)が設定されていない顧客テナントに直接ログインした。
  • 影響は約165の顧客組織とされ、Ticketmaster等の大量データが流出したと報じられた。
  • 原因は「プラットフォームの脆弱性」ではなく「利用者側のセキュリティ設定の不備」だった。

教訓：共有責任モデルを正しく理解し、MFAの強制など「利用者側の設定責任」を果たすこと。ベンダーが安全でも、自社の設定が甘ければ守れない。

事例2：認証基盤・サポート経路への侵入（Okta型・2023年）

ID管理(認証基盤)を提供するOktaでは、2023年にサポート用システムへの不正アクセスが発生しました。認証基盤は多くのサービスの入口を束ねるため、影響範囲が広がりやすいのが特徴です。

  • 攻撃者は盗んだ認証情報でOktaのサポートケース管理システムにアクセス。
  • 顧客がサポートに提出したファイル（セッション情報を含むHARファイル等）が悪用され、Cloudflare・1Password・BeyondTrustなどが標的になったと公表された。
  • 各社は迅速に検知・封じ込め、顧客データへの影響はなかったと説明している。

教訓：認証基盤のような「集中リスク」の高いSaaSほど、ベンダーの検知・通知の速さと透明性が重要。利用者側も、サポートに機微情報（セッション・トークン）を渡さない運用が要る。

事例3：SaaS間連携(OAuth)のサプライチェーン（Salesloft/Drift型・2025年）

2025年には、AIチャットツール「Drift」（Salesloft社）の連携を起点に、連携先のSalesforceから広範なデータが盗まれました。SaaS同士をOAuthで連携する現代特有のリスクです。

  • 攻撃者はDrift連携のOAuth/リフレッシュトークンを窃取し、700組織超のSalesforce環境にアクセスしたとされる。
  • 流出データには、サポートケース本文や連絡先に加え、ケース内に書かれていたAPIキーやクラウド認証情報などの「二次被害の種」も含まれた。
  • SalesforceはSalesloft連携を一時停止する対応をとった。

教訓：「どのSaaSにどのSaaSを連携させているか」を可視化し、連携アプリの権限を最小化・定期見直しすること。サポートケースやチャットに秘密情報を書かないことも効く。

では、選定・委託先管理で何を見るか

3つの事例から導ける、SaaS選定時に契約・運用へ落とし込むべき観点をまとめます。

  • 共有責任の範囲：どこまでがベンダー責任で、どこからが自社設定の責任か。MFAやアクセス制御を自社で強制できるか。
  • 連携(SSO/OAuth)の管理：連携アプリを一覧化でき、権限を最小化・トークンを失効できるか。
  • インシデント通知の義務とタイムライン：何時間以内に、どの粒度で報告されるかを契約で明記する。
  • 責任分界・賠償・免責：漏洩時の責任の所在、補償、責任制限の妥当性。
  • ベンダーの過去の侵害歴と透明性：第三者認証、監査権、開示姿勢。
  • データの所在・暗号化・サイバー保険・出口（移行）条件：問題発生時に移行・データ取り出しができるか。

これらを自前でゼロから基準化する前に、公的な指針を土台にするのが近道です。

現場目線：便利さで増える「野良SaaS」

正直に言えば、SaaSは現場が「便利だから」と次々に導入し、情シスが把握しきれないのが実情ではないでしょうか。誰がどのサービスを契約し、どのデータを預け、何と連携しているか——この棚卸しができていないと、上記の基準も絵に描いた餅になります。派手さはありませんが、利用中SaaSと連携アプリの定期的な棚卸し、そして最小権限の徹底が、選定基準を実効あるものにする土台です。新しいサービスを止めるのではなく、「見えている状態」を保つことが現実的なゴールです。

まとめ

  • SaaSはセキュリティが共有責任。ベンダーが堅牢でも、設定・連携・サポート経路の隙が突かれる（Snowflake/Okta/Salesloftの各事例）。
  • 選定では共有責任の範囲・連携(OAuth)管理・通知義務・責任分界・侵害歴・移行条件を契約と運用に落とし込む。
  • 土台は利用中SaaSと連携アプリの棚卸し＋最小権限。公的指針(IPA等)を出発点にする。

出典

※本記事は公表情報・報道に基づきます。被害組織数などは報告ベースであり、調査の進展で更新される可能性があります（執筆時点：2026年6月）。

コメント

タイトルとURLをコピーしました