おそらく貴社は数百もの SaaS アプリを利用していますが、セキュリティチームはそれらに実際に誰がアクセスできるのかを把握できていない可能性が高いです。
私が支援している組織の多くは、クラウドセキュリティに多額の投資をしています。エンドポイント検知ツール、SIEMプラットフォーム、クラウドセキュリティ態勢管理(CSPM)、そして24時間365日体制で稼働する熟練のセキュリティチームを備えています。それでも、私がシンプルな質問をすると――「今、貴社のSalesforceテナントで管理者権限を持っているのは誰ですか?」――部屋は静まり返ります。誰も分からないのです。彼らが怠慢だからではありません。文字通り、それを見る術がないからです。
それがSaaSのブラインドスポットです。
Ashish Mishra
SaaS:数字が物語る実態
私はほぼすべての案件でこの質問をします。「貴社では何個のSaaSアプリケーションが稼働していますか?」と。返ってくる答えはだいたい30から多くて50程度です。しかし実際に数えてみると、その数は通常300を超えます。AppOmniの2024年の調査では、さらに衝撃的な結果が示されています。Microsoft 365を利用する組織の49%が、自社テナントに接続されているアプリは10個未満だと考えていましたが、実際の平均は1,000個を超えていたのです。
数だけでも驚きですが、私がそれ以上に懸念しているのはこの部分です。それら全アプリケーションのうち、セキュリティチームが明確に把握できているのはせいぜい10個に1個程度に過ぎません。残りのアプリ――顧客記録が保存され、ソースコードが置かれ、財務報告書が共有される場所――は誰にも監視されていません。チームが不注意だからではありません。彼らが持つツールが、そもそもそこを見るために作られていないからです。
以下では、こうした実態を示す具体的なインシデントを取り上げます。
2023年のSalesforce
2023年4月、KrebsOnSecurityが報じたところによると、SalesforceのCommunityサイトが政府機関、銀行、医療機関に属する機密データを静かに漏えいさせていたことが判明しました。高度な攻撃手法は使われていません。正しいAPIエンドポイントと、誤設定されたゲストユーザープロファイルがあっただけです。漏えいした記録には社会保障番号、口座情報、自宅住所などが含まれていました。Salesforceの回答は明快でした。これはプラットフォームの脆弱性ではなく、管理者がゲストアクセスポリシーを誤設定し、誰もそれを確認していなかったことが原因だというものです。
Salesforce Communitiesのゲストユーザープロファイルには、データレコードへのアクセス権を付与できます。管理者がそうした権限を――多くの場合は気づかないまま――広く設定しすぎると、認証されていない外部ユーザーがAPI経由で直接そのデータを照会できてしまいます。誰かが警鐘を鳴らすまでの間、実に15万社を超える企業がこのリスクにさらされていた可能性があります。
このパターンはいつも同じです。時間に追われて行われた設定、わずかに緩すぎるデフォルト値、そして誰も二度と見返さないこと。SaaSアプリケーションは、こうした静かな露出リスクを何ヶ月、何年もかけて蓄積していきます。
2022年のGitHub
2022年4月、GitHubが公表したところによると、攻撃者はHerokuとTravis CIに発行された盗まれたOAuthトークンを使い、npmを含む数十の組織のプライベートリポジトリの内容にアクセスし、ダウンロードしていました。GitHub自体のシステムは一切侵害されていません。トークンの出所は、ユーザーが自身のアカウントへの接続を許可していたサードパーティ製アプリケーションであり、それらのアプリケーションが静かに侵害されていたのです。
侵入口はGitHubではありませんでした。データを失った組織自体でもありませんでした。侵入口となったのは、それらの組織が何ヶ月も、あるいは何年も前にGitHubに接続していたCI/CDツールです。これらのツールには広範な読み取り・書き込み権限が付与されたまま、一度も見直されていませんでした。
これが、平たく言えばOAuthの問題です。サードパーティ製アプリケーションを許可した瞬間から、そのアプリのセキュリティ態勢も自社の問題になるのです。ほとんどの組織では、こうした接続が数十件、SaaSプラットフォーム全体に開かれたまま放置されており、誰もレビューしていません。
Ashish Mishra
2023年のMicrosoft
2023年のMicrosoftの事例は、「これは不注意な組織にだけ起こることだ」と考える人たちに私がいつも持ち出すものです。Wiz Researchの調査により、Microsoft自身のAIチームが、たった1つの誤設定されたAzureアクセストークンを通じて、秘密鍵やパスワード、3万件を超える社内Teamsメッセージを含む38TBもの内部データを露出させていたことが判明しました。本来、このトークンはGitHub上で1つのトレーニングデータセットを共有するためのものでした。ところが実際には、そのリンクを見つけた人なら誰でもストレージアカウント全体にアクセスできる状態になっていたのです。
この事例で私が気になったのはタイムラインです。このトークンは2021年10月からずっとそこに存在していました。誰かが気づくまで、Microsoft社内で実に2年近くもの間放置されていたのです。それだけのリソースと専門知識を持つチームでさえ、2年間も扉を開けたままにしてしまうのであれば、「気づくはずだ」という考え方はセキュリティ戦略としてほとんど意味を成しません。そして注目すべきは、これがデータベースの漏えいではなかったという点です。漏えいしたのはTeamsのメッセージでした。従業員が日々使っているのと同じコラボレーションツールも、構造化されたレコードを保持するプラットフォームと同様に無防備なのです。
従来のセキュリティツールがこれを見逃す理由
クラウドセキュリティ態勢管理(CSPM)ツールは、仮想マシン、ストレージバケット、ネットワークルール、インフラレベルのIAMポリシーといった、インフラ設定を監視するために設計されています。その層では十分な役割を果たしています。しかし、SaaSアプリケーションの内部までは見てくれません。CISAのSecure Cloud Business Applications(SCuBA)ガイダンスは、インフラセキュリティツールとSaaS層の可視性との間にあるこのギャップを、エンタープライズクラウドセキュリティにおいて最も対策が手薄な領域の一つとして特に指摘しています。
このギャップを埋めるために作られたのがSSPMです。インフラを監視する代わりに、SSPMはSaaSアプリケーション自体の設定――権限、共有設定、誰が何にアクセスできるか――を監視します。この違いは単なる理屈上のものではありません。インフラの誤設定はシステムを露出させる傾向がありますが、SaaSの誤設定はデータを直接的かつ静かに露出させ、しかも検知可能な攻撃活動が全く伴わないことも少なくありません。
Ashish Mishra
セキュリティチームが今すぐ取るべき対応
このギャップを埋め始めるために、明日から本格的なSSPMプラットフォームを導入する必要はありません。すぐに効果を発揮できる実践的なステップがあります。
- 主要なSaaSプラットフォーム全体で接続されているOAuthアプリケーションを監査。現行のビジネス上の必要性で正当化できない連携は解除する。
- 公開データ露出のよくある原因:SalesforceのCommunitiesおよびMicrosoft SharePointにおけるゲストおよび外部共有権限の確認。
- Microsoft 365でレガシー認証プロトコルが無効化されているかの確認。レガシー認証はMFAを迂回してしまい、エンタープライズ環境における潜在的な侵入口となる。
- SaaSアプリケーションの高権限アカウントについて、四半期ごとのアクセスレビュー体制の確立。多くの組織はせいぜい年次レビューにとどまっているが、設定が日々変化するプラットフォームにとってそれでは頻度が足りない。
- どのSaaSアプリケーションに機密データが保存されており、どれがセキュリティチームによる管理下に全く置かれていないかを示すマップの作成。そのリストはおそらく予想以上に長くなる。
核心的な問題は、組織が不注意だということではありません。境界とインフラを中心にセキュリティプログラムを構築してきた一方で、SaaSアプリケーションはその境界の内側で、一度もスコープに組み込まれることなく成長してきたということです。データはそこにあります。アクセス権もそこにあります。誤設定も往々にしてそこに存在します。欠けていたのは、それを見るための可視性だけなのです。
SSPMはそのギャップを埋めます。しかし、正式なツールを導入する前であっても、「自社がすでに利用しているアプリケーションは、何を見て、何を共有できる状態にあるのか」と問いかけるだけでも、意味のある第一歩になります。私の経験上、時間を取って調べてみた組織のほぼすべてが、その答えに驚くことになります。
本記事はFoundry Expert Contributor Networkの一環として公開されています。
参加をご希望ですか?
