第3回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第3回会議の内容をまとめて公開する。

2026年01月20日　18:30-20:00　開催

問題点の概要

BetterCloud社が公開した「Common SaaS security risks, horrifying recent breaches, and mitigation tips」において、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例、そしてそれらへの対策について解説している。第3回SaaSセキュリティリーグでは、ここで述べられている７つのセキュリティリスクについて、実際にSaaSのセキュリティ管理を行っている立場からディスカッションした。また、主なSaaSセキュリティリスクを軽減する方法（資料内の FAQ）の有効性についてディスカッションした。

SaaS 環境でよくあるセキュリティリスク

BetterCloud社が公開した資料で挙げられている7つのセキュリティリスクは以下である。

1. 設定ミス（Misconfigurations）
   • 誤った設定により脆弱点が露出。
   • 例：認証不要のページに内部データが公開された Salesforce サイト。設定ミスが侵害につながった典型例。
2. オフボーディングの遅延（Delayed offboarding）
   • 退職者アカウントが削除されずに残ると、データへの不正アクセスや情報窃取につながる危険性。
   • 例： Cash Appでの退職者によるデータ抜き出し事件を紹介。
3. 管理者権限の過剰付与（Excessive admin privileges）
   • 権限の過剰なユーザーがいると、侵害時の被害拡大リスクが高まる
   • 例：Verkada の内部カメラ映像が暴露された事件。
4. 認証情報の漏洩（Compromised credentials）
   • フィッシングや盗難によるアカウント侵害が依然として主要なリスク。
   • 例：Okta 社のサポートチケット情報にアクセスされた事例。
5. 過剰なアプリ権限（Overly permissive app data access）
   • サードパーティアプリに対して不要なデータアクセスを許可してしまうと、意図せぬ情報漏洩につながる。
   • 例： OneDriveで、アプリ連携（OAuth権限/スコープ）により過剰なデータアクセスが起こり得るリスクが指摘されているケース。
6. 不十分な第三者統合（Insecure third-party integrations）
   • 連携サービス側の脆弱性が本体システムへ影響を与える可能性。
   • 例：Okta 侵害 → Cloudflare の Atlassian への不正アクセスに波及。
7. 不適切なファイル共有（Improper file sharing practices）
   • 誰でもアクセス可能な公開リンクなどにより、機密データが漏洩する危険性。
   • 例：日本のゲーム会社 Ateam が Google Drive の公開リンクを誤設定し、長期間データ公開状態となった事件。

セキュリティリスクに対するディスカッション

上記SaaS 環境でよくあるセキュリティリスクについて、実際にどのように問題点として捉えているか、既に解決済みなのか、あるいは、どのような検討が行われているかについてディスカッションを行った。

1. 設定ミス（Misconfigurations）
   組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。
   組織全体で利用するSaaSの場合は、情報システム部門が直接対応しているので対策が取れている。部門等で利用するSaaSの場合は、情報システム部門が助言はするが直接対応はしていない。部門と委託先（SaaSの調達・管理を委託）が協力して対応できているところはできているが、部門が独自にやっている場合は難しい。情報システム部門としてチェックをしているが、数が多いため難しい場合がある。したがって、基本的な運用としては、監査において定期的なチェックを行うこととしている。
2. オフボーディングの遅延（Delayed offboarding）
   退職者アカウントについては管理できている。作業漏れの対策として、棚卸を定期的に実施している。部門で管理しているSaaSアカウントは、手動で管理するのは限界であり、人事システムとの連携が行えるようにIGA（Identity Governance and Administration）を利用することを検討している。人事システムとの連携ができるIGAは有効なツールになると考えている。その上で棚卸を実施し、定期的にチェックする。
3. 管理者権限の過剰付与（Excessive admin privileges）
   過剰権限、過剰設定を確認するチェックシートを作って管理している。チェックシートの中で最小権限等の指示を行っている。管理者権限の付与に対する対応は、どうしてもアナログにならざるを得ない。というのは、誰に対してどのような権限を付与するかについてはシステムオーナーしか分からないため、どうしても個別の対応になってしまう。したがって、情報システム部門としては、過剰権限になっていないかどうかのチェックを行うことで対応している。
   SSPMが過剰な権限を指摘してくれるので、SSPMを利用して管理を行うのは有効であるが、以前から指摘されているSSPMのコストの問題がある。
   管理者権限等の特権の管理としてPAM（Privileged Access Management）があり、これを利用することも考えられるが、現状はIaaSで一部利用している程度でSaaSでは利用していない。
4. 認証情報の漏洩（Compromised credentials）
   この問題も、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。組織全体で利用するSaaSでは、情報システム部門が管理しているため、条件付きアクセスの設定を付けることでアカウント侵害を防いでいる。しかしながら、部門等で利用するSaaSでは、どこまで徹底できているかは不明な部分がある。
   認証情報については、アクセス元のチェック、端末認証等を導入して対応している。これにより、モニタリングができているので、もしアカウントの漏洩が発生すれば、情報システム部門から注意するという運用ができている。
5. 過剰なアプリ権限（Overly permissive app data access）
   API連携の申請が来るケースがあり、情報システム部門でチェックしている。サードパーティアプリから不要なデータアクセスをされるケースには、APIアクセスキーのローテーションで対応している。最近課題として出てきているのは、Microsoft graphAPIに対する連携の依頼が多くなっていることである。組織全体にアクセスできる権利を要求されることがあり、他の部門のデータも見られてしまう可能性があり注意が必要である。
   以前（第１回SaaSセキュリティリーグ）指摘されたが、AIが社内の見えないところを見てしまう、つまり、AIが社内の機密データを見つけて公開してしまう問題がある。自律型AIの権限をどうするのかは今後課題となる。
6. 不十分な第三者統合（Insecure third-party integrations）
   上記5で検討した内容と同様。
7. 不適切なファイル共有（Improper file sharing practices）
   ファイル共有については、ルール化をどう定義するかが難しいポイントである。Microsoft 365では、外部DLP製品に頼らず、自社クラウドの標準機能として DLP を公式に提供している。このDLP機能を使ってクラウドストレージサービスの共有問題に対応している。Google Driveについては、ダウンロードはOKにしているが、アップロードはNGとする対応を取っている。これは、CASB/SGWでコントロールしている。また、クラウドストレージに外部公開する場合には申請が必要で、申請があれば特定領域を共有できるようにするという運用でカバーしている。

主なSaaSセキュリティリスクを軽減する方法

以下の12個が、BetterCloud社が公開した資料でSaaSセキュリティリスクを軽減する方法の概要をFAQとして記述したものである。

1. Q1. SaaS ベンダーのセキュリティリスク評価はどのように行うべきか？
   SaaS ベンダー評価では、次の点を確認する必要がある：
   • SaaS プラットフォームの運用するデータセンターやインフラのセキュリティ体制データ暗号化（保存時／移動時）の仕組みアクセス制御（認証・認可）の方式実施済みのセキュリティ監査や認証（たとえばSOC 2など）
   • サードパーティ連携や API のセキュリティ設計・権限付与の仕組み
     これらの評価を自動化ツールで継続的にチェックすると、ベンダー変更や構成変化にも適応しやすくなる。
2. Q2. 多要素認証（MFA）をどのように強制するか？
   • できる限りすべてのユーザーに MFA を必須化する
   • MFA未設定のユーザーにはログインを拒否するルールを設ける
   • 権限レビューを定期的に実施し、認証強度を維持する
3. Q3. 従業員向けにはどんなセキュリティ教育をすべきか？
   • 最新のフィッシング手法の理解
     → フィッシング攻撃による認証情報漏洩防止
   • ファイル共有の責任ある利用法
     → 過度に公開リンクを作らない／意図しない共有範囲を避ける
4. Q4. SaaS 全体のセキュリティを常に把握する方法？
   「可視性の欠如」がSaaSリスクの根底にある。自動化された可視化／監視ツールの導入が有効。これによって次が可能になる：
   • 新規・非承認アプリの検出（シャドーIT）
   • ユーザーアクセスログとファイル共有状況の自動監視
   • 外部共有や不正アクセスのリアルタイムアラート
5. Q5. 「Super Admin（管理者権限）」の数を制限する方法？
   • セキュリティポリシーとしてアプリ毎に許容する最大Super Admin数を定め、しきい値を超えたらアラートを出す仕組みを設定
   • 単純な管理者数の制御だけでなく、不適切な権限拡大を未然に検知する
6. Q6. ユーザーのオフボーディング（退職時処理）はどう自動化するか？
   • SaaS 管理プラットフォームでは、退職者やロールチェンジの際にアカウントを自動無効化・権限削除するワークフローを設定可能。
   • これにより「幽霊アカウント」問題や放置されたアクセス権限のリスクを抑制できる。
7. Q7. 定期的なコンテンツスキャンをどのように実行するか？
   ファイルやデータをスキャンして以下を特定する：
   • 機密データ（PII、顧客情報、知的財産など）の所在
   • 過剰な共有設定ファイル
   • 不適切なアクセス権限が付与されたファイル
     これも自動化ツールが必要で、人手ベースでは難しい。
8. Q8. どのようなファイル共有モニタリングが必要か？
   • 外部共有の過剰検出
   • 許可範囲の過度な広さ（過剰権限）
   • 非アクティブ共有の把握と削除
     これらのモニタリングにより、ファイル共有に起因する漏洩リスクを削減可能。
9. Q9. ファイル共有方針を強制する方法？
   • 教育に加え、自動化された定期的なファイル権限のクリーニングやポリシー例外を検出する仕組みを運用することで、方針遵守を強制する。
10. Q10. SaaS セキュリティポスチャを高める最良の方法？
    • 強力なSSPM機能を持つ管理プラットフォームを使い、継続的な可視化、監査、ポリシー施行、自動リメディエーションを実施する。
11. Q11. インシデント発生時の即時対応（IR）計画はなぜ重要か？
    • 侵害疑いを検知したら、影響範囲の隔離、パスワード変更、侵害アカウントの停止、ファイル共有のブロックなどを迅速に行うIR計画が必要である。
    • これはインシデントの被害拡大を防ぐうえで極めて重要である。
12. Q12. ルート原因分析（Root-Cause Analysis）はいつ行うべきか？
    侵害の封じ込め後に実施。分析の対象は以下：
    • 初期侵入経路
    • 誤設定や脆弱性
    • データ抽出・ラテラルムーブメントのプロセス
    • 影響した他 SaaS との関連
      これらにより恒久的な改善策が設計できる。

主なSaaSセキュリティリスクを軽減する方法に関するディスカッション

上記の12個の対策に対して、ディスカッションした内容を以下に記述する。

1. MFAの強制について
   機密情報等を扱うSaaSについては、MFAは必須である。また、SSOへの対応も有効であり、SAMLで管理を行っている。これは、部門等で利用するSaaSで機密情報を扱う場合においても強制している。
   また、MFAができない場合には、グローバルIP等で制限を掛けることでSaaSへのアクセスを制限している。グローバルIPによる制限は、完全ではないが、想定外の国やネットワークからの直接アクセスが防げるということで有効である。
   また、業務に合わせて端末レベルでの制御も行っている。
2. 従業員向けのセキュリティ教育
   従業員教育は必ず実施しているが、きちんと理解されているかどうかは疑問なところもある。今後の対策として、教育を超えてシステム的な対策が必要であると考える。例として、一般的な内容ではなく、自分が直面するような問題・危機感を持たせるような（シナリオ的）教育を進めることが有効である。
   また、日常的な観点に基づいてコンテンツ化することも有効である。
3. SaaS セキュリティポスチャを高める方法
   これには、SSPMが有効であるが、実際にはコストの観点から広め切れていない。セキュリティの可視化ができないとリスクが分からないので、うまくSSPMを使う方法を考えていきたいし、ベンダー側の対応も期待したい。
4. インシデント対応
   SaaSのインシデントレスポンスでは、インシデントの検知の報告が、SaaS側ではなく利用者側からの報告ベースになることが多い。あるいは、代理店が検知して対応してくれるケースがある。これは、SaaS側からのインシデントの報告が十分でないことを意味しており、特に部門で利用するSaaSの場合この傾向が顕著である。

まとめ

今回は、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例とそれらへの対策について、BetterCloud社が公開した資料をベースにディスカッションを行った。「あるある」的な内容ではあるが、実際にディスカッションしてみて以下の点が明確になった。

1. あらためて、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。情報システム部門が直接対応しきれない部門等で利用するSaaSへの対応をチェックリストや監査を通してうまく進めていくことが求められる。
2. 特権アカウントおよび権限付与の扱いが、SaaS利用においても重要になっている。これは、人手による対応では厳しい状況となっており、IGAやPAM等を効果的に使っていくことが求められる。
3. API連携の問題がクローズアップされてきている。これは、自組織側の管理だけではなく、連携元の管理にも依存してくるため、どのように連携して対応していくかを検討する必要がある。
4. SaaSのインシデント対応が重要になる。インシデントの報告がSaaS側からきちんと行われないと、利用者側で対応することができない。しかしながら、現状は、SaaS側からの報告があまり行われていないようである。利用者とSaaS側とのより良い連携が求められている。
5. いつも話題となるが、SSPMのカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

以上