SaaSセキュリティ対策の基本！設定ミスの脅威と責任共有モデルを解説

 

SaaSでは業務データと業務プロセスがベンダー管理の環境へ集約されます。オンプレミスのようにネットワーク境界やサーバーの設定を自社で握れない一方、アカウント、権限、共有、連携、監査ログなどの設定は利用企業が決めます。

 

ここに、SaaS特有のセキュリティ論点があります。 例えばMicrosoft 365はメール、ファイル共有、チャット、会議、ID連携のハブであり、Salesforceは顧客情報と営業プロセスの中枢です。これらの設定が不適切だと、不正アクセスなどがなくても情報が外へ漏れ出ます。

 

市場の変化として重要なのは、SaaSの導入数が増えたという量的変化だけでなく、SaaSが扱う情報の質が変わったことです。 以前は名刺管理や勤怠のような補助系が中心でしたが、現在は財務、人事、顧客、契約、開発、監査といった基幹領域がSaaSへ移っています。ここで発生する情報漏えいは、個別部門の障害ではなく、事業継続と説明責任の問題になります。

 

DX推進によるSaaS利用の急増と事故の背景

 

2025年のOkta社のレポートによると、1社当たりの平均導入アプリ数は100を超え、日本でも平均46と前年から31％増と大きく伸びていると公表されています。大企業の場合には平均247で、規模が大きいほどSaaSの数が増える傾向が見えます。 この数字が示すのは、情シスが把握できる範囲を超えてSaaSが広がりやすいという構造です。導入が速い一方、統制の設計と運用が追いつかない。これが事故の温床になります。

 

事故の背景として、攻撃手法の高度化だけを語るのは不十分です。SaaS事故では、設定変更が頻繁であること、運用担当が分散しやすいこと、外部委託や部門導入が増えることが重なります。 加えて、SaaSは連携が前提です。SSO、SCIM、自動同期、外部連携アプリ、Webhook、APIトークンなど、便利な機能がそのままアタックサーフェス（攻撃対象領域）となります。権限が適切に設計されていなければ、外部公開や権限逸脱につながります。

 

皆さんは自社のSaaS利用状況を把握しているでしょうか。SaaS台帳などがあったとしても、最新版でない、管理者が不明、データ分類がついていないなどが起こりがちです。 監査では、SaaSに何のデータがあり、誰が管理し、どの設定で運用しているかを説明できるかが問われます。説明できない状態は、潜在的なインシデント予備軍です。

 

設定不備が引き起こす情報漏えいの深刻さ

 

SaaSに関するインシデントは、ゼロデイなどの高度な攻撃だけでなく、設定不備と運用の問題でも起きます。 典型例は次の3つです。

 

共有範囲が広すぎる

権限が強すぎる

アカウントが残り続ける

 

Googleドライブなどのファイル共有システムで管理していた個人情報を含むファイルがインターネット上で閲覧可能な状態だったとして、閲覧範囲の設定が不適切だった旨が公表されたケースは後を絶ちません。公開設定が、そのまま情報漏えいに直結することもあります。 侵入する必要すらなく、設定が不適切なら正規の閲覧として成立してしまう点が重要です。脆弱性というより、設定と設計の理解不足が事故を拡大させた点に注目すべきです。

 

また、SaaSは仕様変更が頻繁です。デフォルト値が変わる、設定項目が増える、UIが変わる、権限体系が再整理される。これが知らない間に設定ミスを生みます。 最初は安全だった設定が、数か月後には危険な状態になっていることがあります。一回の作業ミスではなく、変化への追随ができない運用設計の問題として捉える必要があります。

 

これらの設定不備は次のリスクへ直結します。売上機会の喪失、顧客離反、レピュテーション低下、委託元からの契約解除、監査指摘、認証停止、行政対応、損害賠償、そして復旧コストです。 加えて、金融ではシステム障害や漏えいがサービス継続性に直結し、社会的影響も大きい。だからこそ、設定不備を技術課題で終わらせず、ガバナンスの問題として扱うべきです。

 

多くの企業は、アンチウイルス、EDR、CASB、プロキシ、SIEMなどを導入しています。これらは重要ですが、SaaSを守る視点とは観測対象が異なります。端末、通信、境界、ログを中心に守る設計であり、SaaS内部の設定や権限の妥当性を継続監査する目的では作られていません。ここに死角が生まれます。

 

言い換えると、従来型対策は外からの侵入や不審通信を検知することに強く、SaaSが持つ設定の膨大さを前提にしていません。 SaaSでは、正規ユーザーが正規の経路で、危険な設定のもとにデータへアクセスすることが起こります。この場合、通信も端末も正当であり、従来の検知ロジックが働きにくくなります。問題は、SaaS内部の設定が危険なまま放置されていることです。

 

通信を監視するCASBやEDRでカバーできない領域

 

CASBはクラウド利用の可視化、制御、シャドーIT検知、データ保護などに強みがあります。一方、SaaSごとに存在する数百から数千の設定項目を、ベンチマークに照らして継続評価し、設定変更を追跡し、是正までつなげる用途は別物です。CASBが悪いのではなく、目的の違いです。 EDRも同様で、端末の不審挙動には強いのですが、SaaSの権限設計や共有設定そのものを直接監査するのは範囲外です。端末が正常でも、共有設定が公開なら情報は漏れます。端末側で検知できるものではありません。

 

現場で頻出する問題として、過剰権限と退職者アカウントが挙げられます。管理者権限が多い、特権アカウントが棚卸しされていない、委託先に恒久的な強権限が付与されている。退職者や異動者のアカウントが残り続ける。これらは侵害が起きた後に必ず問われます。なぜその権限設計だったのか、なぜ削除できていないのか。説明責任を果たせないことが、経営・法務リスクになります。

 

境界防御の限界とSaaSスプロールの脅威

 

境界防御は、社内ネットワークを安全圏とみなし、外部からの侵入を防ぐモデルです。しかしSaaSでは、アイデンティティと設定が新しい境界となります。

 

さらに、SaaSスプロールが起きます。「SaaSスプロール」というのは、組織内でSaaSツールが管理されないまま乱立・増殖し、把握・統制が困難になっている状態です。部門ごとにSaaSを導入し、委託先も使い、プロジェクトごとに一時的なSaaSが増える。結果、次の3つの問題から管理不備が発生します。

 

全体像が分からない

設定レベルがばらつく

責任者が不明になる

 

スプロールが厄介なのは、リスクが単体SaaSの設定ミスに留まらない点です。SaaS連携が増えるほど、単体では低リスクだった設定が、別SaaSの連携によって高リスクに変わります。

 

例として、SaaS Aの共有設定が緩いだけでは公開範囲が限定的でも、SaaS BがAのデータを同期し、B側の公開設定が緩ければ、結果的にAのデータも公開されます。連携は資産の境界を溶かします。ゆえに、SaaSの管理は個別最適ではなく横断統制が必要になるのです。

 

クラウド利用で重要なのが責任共有モデルです。クラウドベンダーが全て守るわけではなく、提供形態に応じて責任が分かれます。責任共有モデルの理解不足は、設定不備と統制不備の根本原因になります。

 

米NSAが発表した資料でも、顧客がCSP（Cloud Service Provider）の責任範囲を過大評価しがちで、誤設定や統制不足が大きなリスクになると指摘されています。

 

事業者と利用者の責任範囲の境界線

 

IaaSではOS以上が利用者責任、PaaSではアプリとデータが利用者責任、SaaSではデータと利用設定が利用者責任という整理が基本です。SaaSの場合、インフラ、OS、ミドルウェア、アプリ基盤の脆弱性対応や可用性確保はベンダーの責任領域になります。

 

総務省のクラウド設定ミス対策のガイドライン活用を解説する資料では、責任分担の原則と、予防と発見の両輪を前提として対策を整理することが紹介されています。 この考え方はSaaSにも当てはまります。設定ミスはゼロにできません。だから予防だけでなく、発見と是正を回す統制が必要になるのです。

 

「SaaS設定はユーザー責任」という認識の重要性

 

SaaSの設定ミスやID管理不備による漏えいは、基本的に利用企業側の統制不備として扱われます。これは技術論だけでなく、ガバナンスと監査の論点です。つまり、経営層が関与しないまま現場へ丸投げする運用は、規制対応の観点でもリスクが高いのです。

 

現場の失敗例は、設定の良し悪しではなく、説明責任の欠如として現れます。 例えば、退職者アカウントが残っていた、外部共有が許可されたままだった、特権が棚卸しされていなかった。事故が起きた後に問われるのは、なぜそうなっていたのか、誰が承認したのか、どの頻度で点検していたのかです。だから、SaaS設定はユーザー責任という認識を前提に、統制設計を先に作る必要があります。

 

対策は、教育や注意喚起だけでは足りません。設定は複雑で、変化し、担当が入れ替わります。必要なのは、誰が見ても同じ判断ができ、監査で説明でき、継続運用できる仕組みです。

 

ここでは、監査と可視化、そしてSSPM（SaaS Security Posture Management : SaaSセキュリティ態勢管理）を軸に整理します。

 

セキュリティ設定の定期的な監査と可視化

 

第一に、設定を測る物差しが必要です。属人的なチェックリストでは、担当が変わるたびに品質がぶれます。外部ベンチマークと標準に基づき、評価項目を固定します。

 

代表例がCIS Benchmarksです。CIS Benchmarksというのは、米CISがOSやソフトウェア、そしてクラウドサービスのセキュアな設定基準をまとめたベストプラクティス集です。このCIS Benchmarksを起点に、社内ポリシーを重ね合わせ、逸脱するものはリスク受容として文書化していきます。 また国際的な基準となっているNIST CSF 2.0では、ガバナンスと継続改善を明確化しており、SaaS設定統制を経営のリスク管理へ接続するために使うことができます。

 

監査の実務では、SaaS別に全項目を見るのではなく、特権アカウント、MFA、外部共有、ゲスト、監査ログ、APIトークン、条件付きアクセス、データ保持など、事故につながりやすいポイントから優先度を付けます。 ここでのポイントは、設定の存在を確認するだけでなく、意図と承認を確認することです。外部共有を許可しているなら、どの業務目的で、誰が承認し、例外はどう管理し、どの頻度で棚卸ししているかまで揃えて初めて統制になります。

 

SSPM活用による設定管理の自動化と効率化

 

第二に、手動監査の限界を越える手段がSSPM（SaaS Security Posture Management）です。SSPMはSaaSの設定状態を収集し、ベンチマークやポリシーと突合し、危険設定を検知し、是正を支援するソリューションです。 Cloud Security Allianceは、SSPMをSaaSサイバーセキュリティの基盤層として位置付け、可視性、コンプライアンス、リスク管理、アクセス制御、設定管理といった目的を整理しています。

 

SSPMの導入価値は、自動化そのものではなく、継続監査を運用に組み込めることです。SaaSは変化するため、年一回の棚卸しでは追いつきません。 CISAのSCuBA（Secure Cloud Business Applications）は、クラウド業務アプリ環境の可視性と設定強化をねらった取り組みとして公開されており、Microsoft 365の設定評価ツールScubaGearも提供されています。

 

実務上は、次のような形でSSPMを使うと効果が出ます。

 

重要SaaSを優先し、段階的に対象を広げる

高リスク設定にアラート閾値を置き、即時是正を回す

例外設定は承認と期限を持たせ、期限切れで再評価する

月次で経営向けの指標を出し、統制が回っていることを示す

 

ここで経営向け指標として使えるのは、危険設定の件数、是正までの平均日数、例外の件数と期限超過率、特権アカウント棚卸しの実施率などです。監査の質問に答えるための証跡が、日々蓄積されます。

 

ただ、SSPMは万能ではありません。誤検知や設定の意図を理解できない場面もあります。だから、人が判断する運用設計が必要です。ただし、全項目を人が追うのではなく、ツールで差分と高リスクを抽出し、人は意図と承認、例外管理、是正判断に集中する。ここに、実務で回る設計があります。

最後に、現場で管理不能が起きる典型パターンを短くまとめます。 第一に、導入の意思決定が部門単位で行われ、契約主体と運用主体が分離することです。第二に、外部委託や連携が増え、アクセス権限の例外が積み上がること。第三に、仕様変更に追随する役割が曖昧で、設定が時間とともに劣化することです。これらが重なると、ルールがあっても守られず、統制が形骸化します。

 

次回は、シャドーITとSaaSスプロールがなぜ止められないのか、どこで統制が破綻するのかを、組織設計と運用設計の観点で掘り下げます。情シスだけに負担を寄せず、経営が関与して回せる統制モデルへ落とし込むことが主題になります。