SaaSのインシデントは設定不備が原因？最新事例でわかる身近なリスクとその対策

はじめに

昨今、日本全体でクラウドシフトが進んでおり、データの保存や管理、社内外のコミュニケーションツールとしてSaaS（Software as a Service）が業務で欠かせない存在になっております。
しかし、こうした技術の進展と業務環境の変化に伴い、SaaSを通じた情報漏洩や不正アクセスといったセキュリティインシデントの件数も年々増加傾向にあります。これらの多くのインシデントは、SaaS提供者側ではなく、利用者側の設定ミスが原因で発生しています。
そこで、SaaSの設定監査を行う、SSPM（SaaS Security Posture Management）が脚光を浴びています。
本記事では、SaaSの設定ミスが引き起こしたインシデントの具体例や、必要な対策方法、そしてSSPMとは何かについて紹介します。また、代表的なSSPM製品であるAdaptive Shieldを例に、設定監査機能がインシデントの防止にどのように貢献するか、解説します。

目次

• クラウドやSaaS利用において企業が対策すべき範囲
• SaaSの設定不備によるリスクとインシデント事例
• SaaSの設定リスク対策の具体的な4つのステップ

クラウドやSaaS利用において企業が対策すべき範囲

「クラウド」と一口に言っても、「IaaS」「PaaS」「SaaS」と3種類に分けられ、それらが提供する機能が異なるのと同様に、それぞれに対して企業が負うべき責任範囲も異なっています。

それぞれが提供するサービス内容は以下の通りです。

• 「IaaS」・・・データセンターの管理、ネットワークの構築、ストレージの割り当てなどを行うInfrastructure as a Service
• 「PaaS」・・・企業でアプリケーション開発を行う際の環境を提供するPlatform as a Service
• 「SaaS」・・・情報管理、コミュニケーションツールなど、業務で必要なサービスを提供するSoftware as a Service

それぞれの責任範囲は以下の通りで、赤が利用者側の責任、青がベンダー側の責任となります。

SaaSの責任範囲をご覧いただくと、「ユーザ」と「データ」の部分は利用者側の責任となっています。
「SaaSのセキュリティはベンダー側が保証してくれるもの」と考えがちですが、

• SaaSで管理していたデータが漏洩する
• ユーザのアカウントが侵害される

といった情報漏洩インシデントはベンダー側の責任ではなく、あくまでSaaSを使っていた利用者側の責任になり、対策を講じる必要があります。 

SaaSを利用する中で最も避けなければいけないインシデントが、「情報漏洩」と「侵害」ですが、これらは主に【外的要因】【内的要因】【環境的要因】の3つの要因から発生することが多くあります。

これらの要因に対して有効な対策が以下のイメージです。

【外的要因】

• サイバー攻撃：メール・Webブラウザ・パスワードのセキュリティ強化、アクセス権限の整理
• 不正アクセス：ソフトウェアの更新、アクセス権限の整理、多要素認証の導入、システムの導入

【内的要因】

• 人的ミス：マニュアルの整備、システムの活用、教育の実施、作業者スキルの向上、フールプルーフの設計
• 不正行為：権限の適切な管理、操作ログの記録、ポリシーの策定周知、定期的な監査

【環境的要因】

• 自然災害：災害時における基本方針の策定、バックアップ
• システムエラー：情報資産の把握、適切な体制の整備、事前のリスク評価、監視システムの強化、バックアップ

これらの対策の多くは、SaaSの設定を見直すことで対応できますが、国内企業においては設定について定期的に監査する習慣がなく、インシデントの可能性が高まっています。

今回は、設定不備によるリスクと実際に発生したインシデント事例を3つご紹介します。

SaaSの設定不備によるリスクとインシデント事例

ServiceNowからの情報漏洩リスク

概要

2023年、SaaSベンダーのServiceNowが、利用者の設定ミスにより外部ユーザから機密情報へアクセスされる可能性があると発表しました。漏洩する可能性のある情報としては以下3つです。

1. ITチケット
2. 企業の機密情報
3. 従業員情報

原因

以下のことが原因と考えられています。

• 「Simple List」ウィジェットのデフォルト設定ミス
• 認証されていないユーザによるリモートアクセス 

現状、今までにこの設定不備によるインシデントは発生していませんが、リスクとしては今も存在しています。
企業のデータ保護のための継続的は設定の監視と、見直しを行う必要性が高まっています。

Teamsへのフィッシング攻撃

概要

2024年1月、企業のセキュリティチームがMicrosoft Teamsを利用したフィッシング攻撃を発見しました。

攻撃者が1,000以上のチャットに招待を送り、ターゲットが招待を受け入れると、悪意のあるファイルをダウンロードしてしまう仕組みになっており、実際にDarkGateマルウェアをインストールしてしまう被害が発生しました。

原因

Teamsのデフォルト設定では、外部ユーザがほかのユーザにメッセージを送信できるようになっており、その脆弱性により今回のインシデントが発生しました。

デフォルト設定の見直しをしていなかったことが最も大きな原因ではありますが、これは外部アクセス制限やセキュリティ設定の強化を行うことでこういった攻撃を防ぐことができます。

Snowflakeからの大規模データ漏洩 

概要

2024年5月27日、ハッカーグループにより不正アクセスが行われ、情報漏洩インシデントが発生しました。

脅威者は、SaaS利用者の名前とパスワードを取得し、取得した認証情報を使ってアカウントにアクセスすることで、合計5億6千万件のデータを盗み取りました。

漏洩した情報は以下の4つです。

1. 氏名
2. メールアドレス
3. 住所
4. クレジットカード番号

原因

ユーザがシングルファクター認証（SFA）を使用しており、アカウント侵害の対策がなされていなかったことで、認証情報が盗まれ、今回のインシデントにつながりました。

今回のインシデントにより、個人情報番号（PII）がフィッシングに利用され、新たに情報漏洩のリスクも生じています。

このように、インシデントは2次被害、3次被害まで及ぶ危険性があり、インシデントが起きる前の予防・対策が企業の命運を握っています。

SaaSの設定リスク対策の具体的な４ステップ

上記でご紹介したリスクやインシデントに見舞われないために、企業として行うべきことは大きく分けて以下の4つがあります。

①自社のセキュリティ基準の明確化

セキュリティ対策を行うにあたって、明確な基準を設ける必要があります。そのため自社で使用しているSaaS全体に該当する、または各SaaS毎に用意されたコンプライアンスを調べ、リスト化するところから対策の準備を整えます。

②自社のSaaSに潜む設定リスクの可視化

続いて、自社のSaaSのセキュリティに関する設定項目を洗い出し、それぞれがコンプラインス基準に準拠しているのかを判断します。

どの設定にリスクがあり、どの設定は安全に保たれているのかを可視化することで、自社が抱える本当の脆弱性を知ることができます。

③SaaSの設定リスクつぶし

SaaSの設定リスクの可視化が完了したら、設定を是正して対策を行います。
どの設定をどのように是正すれば安全になるのかを調べ、設定を一つ一つ是正していく必要があります。

これを行うことで、情報漏洩や侵害に対して直接的に予防/対策が可能になります。

④SaaSの安全性の維持

①～③を一通り完了してもまだ完全には安心できません。

SaaSの設定は日々追加/変更がなされており、SaaSベンダー側によりデフォルトの設定が急に変わることも珍しくありません。また、一人の従業員が外部と情報共有を行うために一時的に公開設定にしていたものを戻し忘れていたことによって情報漏洩につながってしまう可能性も十分考えられます。

そのため、設定を継続的に監視することによって急に発生したリスクにすぐ気づくことができ、インシデントの発生をより防ぐことができます。

 

これら4つのステップは、SaaSの情報漏洩や侵害の対策として必要不可欠な工程ですが、膨大な時間と工数が必要になります。
国内のセキュリティチームは人数が限られている一方で高度なセキュリティを求められる場合が多く、こういった対策を行うためにはツールを活用する必要があります。

SaaSのセキュリティ設定の安全性を担保し、セキュリティチームの工数を大幅に削減するツールとして、SSPM(SaaS Security Posture Management)が注目されています。

SSPMでは、外部のコンプライアンス準拠の管理、SaaS内の設定の監視、不適切な設定に対する是正方法の提示などを行い、設定に関するリスクを自動的に可視化、管理することが可能です。

マクニカで取り扱っているSSPM製品のAdaptive Shieldを例に、SSPMでどのようなセキュリティ対策が出来るか、インシデント事例として今回ご紹介したTeamsを例に説明します。

Teamsのインシデントの発生原因は、「Teamsのデフォルト設定で外部ユーザが他のテナントのユーザにメッセージを送信できるようになっていたから」でした。

Teams上には「External Domain Access」という、外部ドメインとのコラボレーションに関する設定項目がありますが、今回この設定項目が「Check Failed」になっているので、外部テナントへのアクセスができる状態ということが、ここから確認できます。
また、スクリーン画面左下に「Remediation」があり、ここで設定の是正方法も確認できます。

以上より、SSPMを利用することによって、設定リスク管理をシステム化し、かつ是正方法を確認できることから、インシデントの発生を防ぐことができます。 

まとめ

• クラウドの責任共有モデルから、SaaSの「ユーザ」と「データ」は利用者が守る責任がある
• 設定不備によるインシデントが増加している
• 具体的な対策ステップとしては以下の4つ
  1. 自社のセキュリティ基準の明確化
  2. 自社のSaaSに潜む設定リスクの可視化
  3. SaaSの設定リスクつぶし
  4. SaaSの安全性の維持
• SSPMによる設定リスクの把握と是正を行うことで、安全性の維持と工数削減が可能

▼関連資料：『SaaSアプリケーションセキュリティの最新脅威　～身近なSaaSアプリケーションを狙った攻撃を解説～』

▼関連資料：『浮き彫りになるSaaS設定不備のリスク 　～SSPMのリーディングカンパニーにインシデント回避のヒントを聞く～』