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

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

問題点の概要

サイバー攻撃の巧妙化・多様化が急速に進む中、企業のセキュリティ対策において「人」の要素がかつてなく重要になっている。

• なぜ今、セキュリティ教育が問われるのか
  2024年の個人情報漏洩は年間約2,164万件。上場企業の情報事故は過去最多189件。インシデントの27.3%が人為的ミスに起因。
  東京商工リサーチ / サイバーセキュリティクラウド（2025年4月）
• セキュリティ教育投資
  中小企業はセキュリティ投資の優先順位として「教育・人材」よりも「ウイルス対策などの具体的な技術対策」を選ぶ傾向がある。
  IPA「2024年度中小企業実態調査」（2025年2月）
  70%が社内に体制 (専門部署等）がなく、64％が従業員へのセキュリティ教育を実施していない。41%が人材育成のための適切な演習がない・分からない。
  経済産業省（2025年5月）
• インシデント発生時の「心理的安全性」
  クリックした社員を非難する文化があると報告文化が育たない。フィッシング訓練は、クリック率5%以下・報告率70%以上を目標に、従業員の「気づく力」と「報告する文化」を育てましょう。
  フィッシング訓練の実務知見（BTNコンサルティング）

ディスカッション内容

各社が実際にやっていること

実施中の施策を共有したところ、以下のように各社の「リアルな現場感」が浮き彫りになった。

• グループ会社からEラーニングと迷惑メール訓練が降ってきて、それを実施している。
• 新入社員研修に2時間ほどのセキュリティ講義を盛り込んでいる。基本的な教育として、社用のPCの使い方とか、勝手にクラウド/AIのサービスを使わない、迷惑メール訓練等を行っている。
• 月1回でセキュリティ啓蒙資料を公開し、週次でコンテンツを提供している。
• セキュリティ・ワークショップを希望者向けに企画中である。タッチポイントを増やすことを意識している。
• 年1回のEラーニングとフィッシングメール訓練に加え、情報セキュリティポータルから時事ネタを発信している。社内インシデントの再発防止策を3か月に一度、事案ベースで共有している。
• グローバル企業であるので多言語対応が必須である。また、経営層向けのサイバーセキュリティ教育を外部機関と組んで実施し、部門長レベルにも個別に教育を展開している。
• セキュリティだけでなく、世の中で起こっている問題の研修を行っている。

「本当に身についている」か、正直なところ

• フィッシング訓練を繰り返しても、クリックしてしまう人は一定数存在する。抜けてしまうスパム等については問い合わせが増えているが、ウイルス検知については問い合わせが来ていなくて、うまく駆除できていない可能性がある。問題は、「報告する＝恥ずかしい」という空気が漂い、報告が滞ることである。
• メールテストの内容：差出人とURLのチェック、内容確認として緊急を煽るものを入れている。教育として見逃せないことは、Eラーニングでどのようなトピックを挟むかである。

従業員の「気づく力」と「報告する文化」が重要

• クリックした社員を非難する文化があると報告文化が育たない。目指すべきは「完璧な社員」ではなく、「気づいたら躊躇なく報告できる組織」である。
• 「空振りはかまわないよ！」を周知する。疑わしきは報告する文化の形成が重要である。
• Slackに報告用ワークフローを設けた企業では「わりと効果が出ている」という声がある。報告のハードルを下げる設計が、報告文化の醸成につながっている。

ルールを守らせるのか、リスクを理解させるのか

この問いに対して、参加者の意見はわかれた。 「ルールは出すが、背景を伝えることで理解につなげている。なぜそのサービスを使ってはいけないのか、セキュリティ的な理由を説明する」——という声がある一方で、「現場は余裕がないので教育時間を増やせない。基本を教えることがルールになるのかもしれない」という意見がある。

理解させたいのは山々だが、現場に余裕がない。基本を教えることがそのままルールになってしまうというのが現実のようである。したがって、重要なのは、ルールの背景にある「なぜ」を伝えることで、完全な理解は難しくても「疑わしきは報告」という行動原則を染み込ませることはできるのではないかと考える。

変えていくための4つのアプローチ

1. 継続的なタッチポイント
   年一回の研修だけでなく、週次・月次の小さな接触の積み重ねが必要である。ワークショップ、ニュースレター、Slack等を組み合わせるのが望ましい。
2. セキュリティチャンピオン
   万人向けの深い教育は難しい。まず各部門に「わかっている人」を育て、周囲を巻き込む構造を作る。
3. 経営層・部門長の巻き込み
   セキュリティを現場だけの問題にしない。経営課題として位置づけ、部門長が旗を振ることで優先度が上がる。
4. 効果測定と改善サイクル
   KnownBE4のような動画による教育も有効である。ツールを使うことで集計・測定が可能になるのが良い。「感覚」ではなくデータで効果を見える化し、改善につなげる。

どのアプローチも共通するのは「地道に続けること」である。セキュリティ教育に即効薬はない。以下のような日々の小さな改革の積み重ねが、組織のリテラシーを底上げする。

• 報告のハードルを下げる——Slackワークフロー、専用フォームなど「気軽に言える場」を作る
• 「空振りはかまわない」を明言する——報告した社員を絶対に責めない文化を経営層が宣言する
• インシデント事例を定期共有する——他社・自社の事例を定期的に共有し、「対岸の火事」にしない
• 効果を測定する——クリック率・報告率・アンケート結果を追い、改善サイクルを回す

おわりに

セキュリティ教育の難しさは、「やった」と「身についた」の間にある大きな溝である。年一回のEラーニングを全社員が受けても、翌日にフィッシングメールをクリックする人は出てくる。

大切なのは「完璧な社員を育てること」ではなく、「何か起きたとき、すぐ報告できる組織を作ること」である。そのための文化づくりは、ルール設計よりずっと時間がかかる。しかし、地道に続けることでしか変わらない。

以上

第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のカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

以上

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

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

2025年10月14日　18:30-20:00　開催

テーマ：SaaS上の機密データの不十分な可視性と脆弱なアクセス制御のリスクと対応

1. 問題点の概要（引用：「SaaSセキュリティの現状レポート2025年～2026年の動向と洞察」）
   • 企業の63%は機微データや機密データの外部への過剰な共有を最大のリスクとして挙げており、56%は従業員が機微データを未認可なSaaSアプリケーションにアップロードしていると報告している。
   • このようなリスクの主な要因は、効果的でない特権とアクセス管理の実践であり、組織の41%が最小特権アクセスポリシーが効果的に実施されていないと報告している。つまり、ユーザーやシステムが過剰な権限を保持することが多く、データ漏えいや権限の乱用、内部脅威のリスクが高まっている。
   • 人間のアイデンティティに限ったことではなく、生成AIの統合は、新たな複雑性のレイヤーを導入しており、多くの場合、タスクを実行するために、複数のアプリケーションにわたる機密データへの広範なアクセスを必要とする。組織の56%は、サードパーティベンダーやAIを搭載したSaaSツールが、データへの過剰なAPIアクセスを獲得することを懸念している。
   • SaaS のデータフローが一元的に可視化されておらず、SaaS 間の統合が監視されていない。企業の 42% が SaaS アプリケーション全体の機微データの追跡と監視に苦慮している。
     
2. ディスカッションのポイント
   • SaaSアプリケーション上のアクセス設定が徹底できていない
   • 最小特権アクセスポリシーが効果的に実施されていない
   • サードパーティベンダーやAIを搭載したSaaSツールに対する過剰なAPIアクセスとなっている
   • SaaS アプリケーション全体の機微データの追跡と監視が不足している

以下、ディスカッション内容をまとめる。

1. SaaS上の機密データの取り扱い
   • セキュリティ対策を考える前に、対象となるSaaSを明確化
     以下にリストしたように組織ごとに様々なSaaSの位置づけがあるが、一概にこれというものではないことが分かった。しかしながら、組織として対象となるSaaSを明確にすることは、具体的なセキュリティの問題の洗い出し・対策を取っていく上で重要である。
     • 社内の情報を預けるもの、IDのあるものをSaaS/クラウドと定義
     • データの持ち出しを念頭に置いて判断
     • 業務で使うものという括りで判断
     • 有償契約のあるクラウドを管理対象（ただし、無料であっても企業で使うケースもある）
       
       
   • 機密データをSaaSに上げることに対する管理の現状
     機密レベルに応じてSaaS/クラウド（ここでは、SaaSだけでなくクラウドとして捉えることが必要）に上げることができるデータとして、どのような基準を設けているかという問題に対して、以下のような意見が出された。
     
     • 機密データをクラウドに上げることは（極秘であっても）特に妨げてはいないが、機密レベルに応じて承認するかどうかを決めている。機密データの管理については、CASBのスコアベースで評価し、PaloAltoで止めるという方法を取っている。結果、リスクスコアが高いものはクラウドにアップロードできない。
       CASBのリスクスコアによる管理を行っている理由は、単純な仕組みで無いと従業員がついてこれないためである。
     • チェックリストに基づいて許可するかどうかを判断している。まずAssuredで評価し、それから独自のチェックリストに基づいて評価し許可を出している。技術的には、Zscalerのサービスでアクセス制御し、Web Filteringで制御している。
     • データ区分を設定して、データの重要度に応じてアクセスを制限している。IPアドレス等により、アクセスできる拠点、人等を管理する方法をとっている。
     • 使用できるSaaSを限定し、申請に基づいて評価している。技術的な管理は、SASEおよびCASBで実施している。
       
       各組織とも、SaaS/クラウドにアップできるデータに対する基準やチェックリストを設けて管理している。技術的には、CASBで管理し、その他の製品を使って制御していることが多い。チェックの仕方が煩雑だとうまく運用できない、特に部門主導のSaaSにおいては管理が難しいということもあり、できるだけシンプルな管理方法を取っている。
       
       
   • クラウド上の機密データの管理（過剰な外部との共有になっていないか？）
     機密データの外部への過剰な共有による情報漏洩が大きなリスクであることが言われているが、実際どのような状況なのか、また、どのように管理しているかについて、以下のような意見であった。
     
     • 部署の使い方（外部のゲストユーザの状況、退職者管理等）を、あらかじめ作成したチェック項目に基づいて管理している。また、棚卸、監査のタイミングで再チェックし、是正処置を実施している。
     • O365は外部と共有できないようにしている。BOXは共有に使っているが、ログを監査し対処している。
     • 外部だけでなく社内にオープンにされているケースが多いのも問題である。グループ内に閉じておかなければならない情報が共有できてしまっている（人事情報、パスワードなど）。たとえば、Sharepointが誰でも見れる状況になっていたりする。これは、AIの利用によりさらに問題となってきており、本来共有できない情報をAIが取り込んでしまう問題がある。
       
       以上のように、この問題に対しては基本的に管理的な対策に頼らざるを得ない状況のようである。しっかりした管理と定期的な監査・是正が求められる。
       
       
   • 最小権限アクセスポリシーが効果的に実施されていない
     これは、SaaS/クラウドに限らずオンプレでも同様であるが、ここでは、SaaSに限定して意見を出していただいた。
     • SaaSに対しては効果的な実施方法は無いのが実情である。オンプレであれば専門家が権限付与する時に申請ベースで動くことができ、過剰権限があれば運用において管理できる。
     • クラウドの場合、ツールの利用が必要である。SSPMであれば、過剰権限、SaaSに対する設定の確認、外部に公開されているリンクの検知などを行うことができる。SSPMによる可視化（公開設定管理など）もまた有効である。ただし、利用はまだ一部にとどまっている状況である。
     • アクセス権の付け間違いはどうしても発生する。データの管理者（SaaSの場合、特に部門）がそもそも理解できていないのが問題となるケースが多い。データをアップロードする人が一般事務の人だったりして、オンプレの慣習通りにアップロードしてしまい、クラウドにおいて問題となる。ITの専門家がいない部署が運営していて、設定がちゃんとしてない可能性があり、セキュリティ部門ではきちんとできているかを管理しきれない。
     • ツールの利用が考えられる。脅威インテリジェンス、アタックサーフェス用のツールで、公開されている情報を検知することが可能である。Avepointのようなツールが出てきており、うまく使うと有効であるという話もある。
     • ポリシーの教育は必須である。各拠点の担当者、エンドの利用者向けの教育を行っている。
       
       以上のように、効果的な管理は難しい状況ではあるが、SSPMやその他のツールを利用した技術的対策が有効であるので、検討していただくことが良いかと思われる。
       
       
   • 他社との共有リスク
     調査レポートの課題としては上げられてはいないが、クラウドストレージ等を使って他社と情報共有していることも問題になる場合がある。他社との共有は、会社間での情報のやり取りを行う場合、セキュリティ的にも有効な手段であるが、反面、利用者が誤って機密データを上げてしまい、それが他社と共有されてしまうという問題がある。この問題に対して現在取られている対策は以下である。
     
     
     • 外部の委託業者との共有、他社のBOX等の共有を使うケースは、基本禁止している。対策としては、管理を厳しく行っている。
     • この課題は、CASBで管理できる（他社と共有してはいけない機密情報をクラウドに上げるのを制限する）が、自社が管理している共有サイトは管理できるが、他社が管理しているサイトだと難しい。
       
       この問題は、クラウドストレージの利用が禁止される典型的な例であり、なかなか管理が難しい。引き続き、検討が必要なものと考えられる。
       
       
2. その他
   以上の議論とともに、以下の3点についても検討が必要であるとの意見があった。
   
   • データセキュリティの観点
     
     • データの機密性を従業員が適切に判断するのが難しいケースが多い。そのため、社内ポータルに上げてはいけない極秘データを簡単においてしまったりするケースがある。機密区分を人に頼るのではなくAIによって自動的に判定するようなことができるとこのような問題は少なくなるかと思われる。
     • DLPで制御させるためのタグ付けに対して限界を感じている人が多く、もっと踏み込んだ対策が求められている。DSPMには「AIによるファイルの機密区分の判定」などの機能があり、これが有効なツールとなる可能性がある。
       
   • Need-to-knowが分かる、あるいは、理解できる仕組み
     
     • 読みたい人がアクセス権を要求できる仕組みの方が良いのかもしれない。現状は、データオーナーの責任においてアクセスできる人を決めているが、これを読むべき人が自動的にNeed-To-Knowになるような仕組みができると良いかと思われる。
     • Need-to-knowを徹底できる仕組みとしてワークフロー化する方法では、共有グループのアクセス権の設定に対して承認を行うプロセスを作ることができる。
       
   • ブラウザのロギングの強化
     
     • ブラウザのロギングがしっかりしていれば管理しやすくなると思われる。独自のアプリ以外はブラウザ経由なので、しっかりしたログを出してほしい。これができると、ログ分析する時に非常に有効になると思われる。現状は、アクセスログぐらいしか出されていない。
       
       
3. まとめ
   今回のSaaSセキュリティリーグでの議論を以下の2点にまとめる。
   
   • SaaS上の機密データの取り扱いの問題は、管理的対策と技術的対策をうまくミックスさせて行うことが必要と思われる。チェックリスト等の整備、定期的な見直しとしての監査/是正を愚直に進めることが必要になる。CASB等のツールによる技術的対策は、管理的対策を補完する形で有効に利用できると思われる。
   • 最小権限アクセスポリシーが効果的に実施されていない問題は、ツールの利用が有効である。また、ポリシーの徹底のための教育は継続してきちんと行っていくことが求められる。

以上