SaaS連携とOAuthのセキュリティ｜2025年のDrift事例から権限管理を学ぶ

Google Threat Intelligence Groupは2025年8月26日、Salesloft Driftに関連したOAuthトークンの悪用によるデータ窃取を公表し、8月28日に追記しました。対象となった外部連携の認証情報を通じてデータにアクセスするという、連携先も含めた管理の重要性を示す事例です。

これは2025年の公表事例であり、2026年現在も同じ侵入が続いているという説明ではありません。またGoogleの公表は、Google Workspace自体が侵害された事例とは区別しています。製品名だけで全利用者が被害に遭ったと広げず、対象の連携、期間、権限、提供元の対応を一次資料で確認します。

OAuthを利用する連携では、アプリに対してデータの読み取りなどの権限を委ねることがあります。利用者が毎回パスワードを渡す必要がない一方、許可されたトークンの保護と権限の範囲が重要です。「パスワードを教えていないから連携は全て安全」とは言えません。

SSOは複数のサービスでのログインを扱う考え方であり、OAuthによる権限の委任とは目的が異なります。画面上で一緒に現れることもありますが、ログインできる人の管理と、連携アプリができる操作の管理を分けて確認してください。

架空の会社が、顧客一覧を営業支援アプリに連携するとします。必要なのは担当者が持つ案件の閲覧だけなのに、全顧客データの読み書きとユーザー管理まで要求されたら、業務目的に対して許可が広すぎないかを検討します。便利になる内容と、漏えい・誤変更時の影響を同じ担当者だけで決めないようにします。

許可画面を読めば必ずリスクが分かるとは限りません。管理者は提供元の説明、組織の設定、サービスアカウントやトークンの有効範囲を確認し、必要な範囲へ制限できるかを判断します。最低限必要な権限にできない場合は、別の実現方法や利用見送りも選択肢です。

SaaS本体に脆弱性がある場合、第三者の連携が侵害された場合、自社が過剰な権限を与えた場合では、確認先と対処が違います。まず製品名を挙げて全て危険と判断するより、どの経路でどのデータにアクセス可能だったかを整理します。

自社の点検では、連携の名称だけでなく、担当部署、所有者、対象データ、権限、有効期間、最終利用、解約・退職時の処理を台帳に残します。使わなくなったアプリでも許可が残っていれば、権限の管理対象です。導入時の承認だけで終えず、定期的に棚卸しします。

架空の営業部が別のツールに移行した後、以前のアプリを開かなくなったとします。利用していないことと、以前の連携が取り消されていることは別です。移行の完了条件に、残った許可、トークン、共有データ、契約終了時の扱いを含めます。担当者の退職だけで自動的に全て消えるとも限りません。

連携を解除すると履歴や業務が使えなくなる場合もあるため、必要な記録の保存と解除の順序を管理者が決めます。再利用する可能性だけを理由に、過剰な許可を無期限に残すのではなく、必要になった時点で再承認する運用も検討します。

新しいAI機能が追加された場合も、契約しているサービスが同じだから点検不要とは判断しません。読むデータと操作の範囲が変わるかを、導入時と同じ観点で見直します。

連携のトークンや許可が影響しているなら、パスワード変更とは別に失効や連携解除が必要な場合があります。ただし業務停止への影響もあるため、担当者が提供元の手順と対象範囲を確認し、必要な記録を保存して対処します。闇雲に全連携を解除して調査や業務を困難にしないことも大切です。

どのデータへアクセスされたか、書き込みや新しい許可がなかったか、持ち出された情報に別の秘密が含まれていないかも調べます。対処後は必要な連携だけを最小の権限で再設定し、監視の条件と所有者を明確にします。AIエージェントとの連携でも、この管理の考え方は重要です。

本記事のケース・図解は当サイト独自の学習用です。公表事例と架空の練習例を区別し、実際の試験問題や過去問を再現していません。時事情報がそのまま出題されるという意味ではありません。

学習範囲を確認するなら情報・サイバーセキュリティ管理士の概要、理解を確かめるなら登録不要の無料お試し20問へ。収録内容と料金は管理士のコースページで確認できます。

外部の制度・事例は2026年10月14日時点で確認しました。事件の評価や製品の対応状況は更新されるため、実務判断では末尾の一次資料も再確認してください。