2026.09.29 セキュリティ

SaaSセキュリティ対策の実装手順｜設定診断・OAuth棚卸し・ログ監視を解説

SaaSの情報漏えいは、事業者側の侵害より利用側の設定と権限から起きる例が目立ちます。共有リンクが「全員に公開」のまま残る、社員が業務外のアプリにメール閲覧権限を渡す、退職者のアカウントが生きている。本記事では、SaaSセキュリティのうち利用企業が責任を負う範囲を整理したうえで、Microsoft 365とGoogle Workspaceの設定をCISAの無償ツールで診断する手順、OAuth連携アプリをAPIで棚卸しする方法、SSPM製品が必要になる条件までを、実行できるコマンド付きで解説します。

まとめ：SaaSセキュリティで利用企業が先に手を付ける作業と順番

SaaSの利用側で守るべき対象は、ID・データの共有設定・連携アプリの権限の3つに集約されます。サーバーやネットワークは事業者の責任範囲なので、利用企業が手を動かす場所は管理画面の設定値とアカウントの状態に限られる。

手を付ける順番は、SSOとSCIMでIDの入口を一本化し、次に設定値を機械的に診断し、最後にOAuth連携の同意を棚卸しする流れです。Microsoft 365とGoogle Workspaceだけを使う組織なら、CISAが公開するScubaGearとScubaGogglesを月次で回せば、有償のSSPM製品を入れずに設定診断を始められます。

SSPM製品を検討するのは、業務SaaSが10種類を超える、監査で継続的な証跡を求められる、設定変更を即時に検知したい、のいずれかに当てはまったときで足ります。

SaaSセキュリティの責任範囲と利用側で起きる事故の型を責任共有モデルで整理

対策の前に、どこまでが自社の仕事かを線引きします。ここが曖昧だと、事業者の認証取得を確認しただけで安心してしまう。

SaaS利用者が責任を負うID・データ・設定の3領域と事業者側の範囲

IaaSやPaaSと比べ、SaaSは利用者の責任範囲が最も狭いサービス形態です。OS、ミドルウェア、アプリケーション本体の脆弱性対応とパッチ適用は事業者が担います。利用者側に残るのは、誰にアカウントを発行するか（ID）、ファイルや予定表をどこまで共有するか（データ）、管理画面で何を許可するか（設定）の3領域でした。

狭いぶん、手を抜くと防御が残りません。事業者がISMAPやSOC 2を取得していても、それは事業者側の統制を示すもので、利用企業の共有設定までは保証しない。クラウド全体での責任分担はクラウドセキュリティのリスクと責任共有モデルで整理しています。

情報漏えいに直結する設定ミス・過剰なOAuth同意・退職者IDの3類型

利用側の事故は、ほぼ次の3つの型に収まります。

設定ミス：外部共有を「リンクを知っている全員」で許可したまま、機密ファイルが外部から閲覧できる状態になる
過剰なOAuth同意：社員が外部アプリに「メールの読み取り」や「全ファイルの読み書き」を許可し、アプリ側の侵害や悪意のあるアプリ経由でデータが抜ける
退職者・異動者のID残存：人事の手続きとSaaSのアカウント削除が連動せず、退職後もログインできる

このうち見落とされやすいのが2つ目です。パスワードを変えてもOAuthのトークンは失効しない場合があり、MFAを入れても同意済みのアプリはそのまま通る。管理者の把握していないSaaS利用そのものはシャドーITの該当例と公的資料に沿った対策で扱いました。

総務省の設定ミス対策ガイドブックとCISA SCuBAが示す確認項目

確認項目を自前で作る必要はありません。総務省は2022年10月に「クラウドサービス利用・提供における適切な設定のためのガイドライン」を公表し、2024年4月26日にその内容を平易に解説したクラウドの設定ミス対策ガイドブックを出しています。こちらは体制・手順・人材育成まで含む組織側の指針です。

設定値の粒度まで落ちているのは、米CISAのSCuBA（Secure Cloud Business Applications）でした。Microsoft 365とGoogle Workspace向けに安全な設定基準（Secure Configuration Baselines）を公開し、その基準と実際のテナント設定を突き合わせる診断ツールまで無償で配布しています。2022年に始まった取り組みで、診断ツールは2023年から提供されています。

Microsoft 365の設定をScubaGearで自動診断する手順とレポートの読み方

ScubaGearはMicrosoft 365のテナント設定を読み取り、SCuBAの基準に照らして合否を出すPowerShellモジュールです。2026年9月時点の最新版は1.8系（v1.8.0・2026年5月公開）で、ライセンスはCC0になっています。

ScubaGear 1.8系のインストールと依存モジュール導入の手順

READMEの手順では、WindowsのPowerShell 5系ターミナルで実行します。PowerShell 7系ではなく5系が前提なので、Windows PowerShellを開いてください。

# PowerShell Galleryから導入
Install-Module -Name ScubaGear

# 診断に必要な依存モジュール（OPA等）をまとめて導入
Install-ScubaDependencies

# 導入された版を確認
Invoke-SCuBA -Version

ScubaGearは設定の合否判定にOpen Policy Agent（OPA）を使うため、依存関係の導入ではインターネットから実行ファイルやモジュールを取得します。社内プロキシで外部取得が制限されている端末では、ここで止まる場合があります。

Invoke-SCuBAの実行対象を製品単位で絞り込むコマンドの書き方

対象製品は -ProductNames で指定します。指定できる値は aad（Entra ID）、securitysuite、exo（Exchange Online）、powerplatform、sharepoint（SharePoint OnlineとOneDrive）、teams、powerbi の7つで、* なら全製品です。

# 全製品を対話ログインで診断
Invoke-SCuBA -ProductNames *

# 情報漏えいに直結する3製品に絞って診断
Invoke-SCuBA -ProductNames aad, sharepoint, exo

# 定期実行向け：証明書で認証するサービスプリンシパルを使う
Invoke-SCuBA -ProductNames * `
  -CertificateThumbprint <証明書の拇印> `
  -AppID <アプリケーションID> `
  -Organization example.onmicrosoft.com

初回は対話ログインで全製品を回し、結果を見てから定期実行へ移るのが手戻りの少ない進め方です。サービスプリンシパルで回す場合は、読み取りに必要な権限だけをアプリ登録に付与します。

HTMLレポートで不合格になった項目に優先度を付ける判断基準

実行すると、カレントディレクトリに日時付きのフォルダが作られ、要約の BaselineReports.html、機械処理向けの ScubaResults.csv、対応計画用の ActionPlan.csv などが出力されます。HTMLは実行後に自動で開きます。

不合格が数十件並ぶのは珍しくありません。全部を同時に直そうとせず、次の順で着手します。Entra IDのMFA・レガシー認証・特権ロールに関する項目が最優先。次にSharePointとOneDriveの外部共有、その次にExchange Onlineの自動転送とメール認証（SPF・DKIM・DMARC）です。TeamsやPower Platformは外部アクセスの項目を除き、後回しでも実害に直結しにくい。ActionPlan.csv に担当者と期限を書き込み、翌月の再実行で差分を確認する運用にすると、診断が1回きりで終わりません。

Google WorkspaceのScubaGoggles診断と監査ログ依存項目の限界

Google Workspace側はScubaGogglesを使います。Python製のコマンドラインツールで、2026年9月時点の最新版は1.0系（v1.0.1・2026年7月公開）、動作要件はPython 3.10以上です。

scubagoggles setupでOPAと認証情報ファイルを登録する初期設定

pipで導入し、setup で出力先・OPAの実行ファイル・認証情報ファイルの場所を登録します。認証はOAuthクライアントかサービスアカウントのどちらかを選べます。

python -m venv .venv
.venv\Scripts\activate
pip install scubagoggles

# 出力先・OPA・認証情報JSONの場所を対話で登録（OPAは既定で自動取得）
scubagoggles setup

# 全ベースラインを診断
scubagoggles gws

# 共有とメールに絞って診断し、結果を./outputへ出力
scubagoggles gws -b drive gmail commoncontrols -o ./output

-b に渡せるのは assuredcontrols、calendar、chat、classroom、commoncontrols、drive、gemini、gmail、groups、meet、sites の11種類です。結果は GWSBaselineConformance_ で始まる日時付きフォルダにHTMLとJSONで出ます。

変更履歴が6か月を超えた設定を判定できないログ依存チェックの注意点

ScubaGogglesの判定の多くはGoogleのPolicy APIから設定値を直接読みますが、APIで取れない一部の項目は管理者の監査ログから推定しています。公式ドキュメントのLimitationsには、この方式の弱点が書かれています。一度も既定値から変更していない設定はログが存在しないため判定できない。管理ログの保持期間は6か月なので、それより前に変えた設定も見えません。

レポート上でログ依存と表示された項目の「合格」は、そのまま信用しないことです。組織部門（OU）単位で設定を分けている場合も、子のOUは親の設定を継承しているとみなして判定されます。ログ依存の項目だけは、管理コンソールで目視確認する手順を月次の点検表に残しておきます。

OAuth連携アプリの同意をGraph APIとAdmin SDKで棚卸しする手順

設定診断ツールは「同意を許す設定になっているか」は見ますが、「すでに誰が何に同意したか」の一覧は出しません。ここはAPIで直接取りに行きます。OAuthの同意とスコープの仕組み自体はOAuth 2.0の認可フローと認証との違いで解説しています。

oauth2PermissionGrantsで全テナント同意と過剰スコープを抽出

Microsoft 365では、委任されたアクセス許可の付与状況をMicrosoft Graphのoauth2PermissionGrantsの一覧APIで取得できます。最小権限は Directory.Read.All で、グローバル閲覧者ロールでも実行できる。consentType が AllPrincipals なら管理者が全利用者分を一括で許可したもの、Principal なら個々の利用者が同意したものです。

Connect-MgGraph -Scopes "Directory.Read.All"

Get-MgOauth2PermissionGrant -All |
  Where-Object { $_.ConsentType -eq "AllPrincipals" -or
                 $_.Scope -match "ReadWrite\.All|Mail\.Read|Files\.Read\.All" } |
  ForEach-Object {
    $sp = Get-MgServicePrincipal -ServicePrincipalId $_.ClientId
    [pscustomobject]@{
      App     = $sp.DisplayName
      Consent = $_.ConsentType
      User    = $_.PrincipalId
      Scope   = $_.Scope.Trim()
    }
  } | Export-Csv grants.csv -NoTypeInformation -Encoding UTF8

clientId は連携アプリのサービスプリンシパルのオブジェクトIDなので、表示名に引き直してから一覧にします。抽出条件の正規表現で対象としているのは、メール・全ファイル・ディレクトリの書き込みといった影響の大きいスコープです。不要な付与は、エンタープライズアプリの画面またはGraphの削除APIで取り消します。

Directory APIのtokens.listで利用者ごとの外部アプリ連携を一覧化

Google Workspaceでは、Admin SDK Directory APIのtokens.listが、利用者が承認したサードパーティアプリのトークンを返します。必要なスコープは admin.directory.user.security です。サービスアカウントにドメイン全体の委任を設定し、管理者になりすまして全利用者を走査します。

from google.oauth2 import service_account
from googleapiclient.discovery import build

SCOPES = [
    "https://www.googleapis.com/auth/admin.directory.user.readonly",
    "https://www.googleapis.com/auth/admin.directory.user.security",
]
creds = service_account.Credentials.from_service_account_file(
    "sa.json", scopes=SCOPES).with_subject("[email protected]")
svc = build("admin", "directory_v1", credentials=creds)

req = svc.users().list(customer="my_customer", maxResults=200)
while req is not None:
    res = req.execute()
    for u in res.get("users", []):
        toks = svc.tokens().list(userKey=u["primaryEmail"]).execute()
        for t in toks.get("items", []):
            print(u["primaryEmail"], t.get("displayText"), t["clientId"],
                  len(t.get("scopes", [])), sep="\t")
    req = svc.users().list_next(req, res)

出力をアプリ名で集計すると、何人がどのアプリに同意しているかが見えます。利用者が1〜2人しかいない見慣れないアプリと、Gmailやドライブ全体へのスコープを持つアプリから確認していきます。

利用者の同意を検証済み発行元と低リスク権限へ限定する設定変更

棚卸しで消しても、同意の入口が開いたままならすぐに元へ戻ります。Microsoftのユーザー同意の構成手順によれば、既定ではすべての利用者が、管理者の同意を要しない権限についてアプリへ同意できます。推奨は、検証済みの発行元のアプリに限り、低リスクに分類した権限だけ同意を許す設定です。組み込みポリシーでは microsoft-user-default-low がこれに当たります。

Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# 変更前に、現在割り当てられているポリシーを必ず控える
(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions.PermissionGrantPoliciesAssigned

更新時は、控えた一覧のうち ManagePermissionGrantsForOwnedResource で始まるポリシーを残したまま、managePermissionGrantsForSelf.microsoft-user-default-low を割り当てます。この変更は以後の同意にだけ効き、付与済みの許可は残るので、前の手順の棚卸しと必ず組み合わせてください。同意を止めると業務アプリの申請が管理者に集まるため、管理者同意ワークフローを同時に有効にしておくと窓口が詰まりません。

SSPM製品を導入する条件と無償ツールの定期実行で足りる組織の境界

SSPM（SaaS Security Posture Management）は、複数SaaSの設定と連携アプリを継続監視する製品群です。相談を受けたときの判断をここで言い切ります。

M365とWorkspace以外のSaaSが少ない組織は無償ツールで足りる理由

中堅・中小企業で機密データが集まるのは、多くの場合メール・ファイル共有・予定表を持つMicrosoft 365かGoogle Workspaceです。この2つはScubaGearとScubaGogglesで基準付きの診断ができ、OAuth連携は前章のAPIで棚卸しできる。月1回の実行と差分確認を点検表に組み込めば、SSPM製品の主要機能の相当部分を賄えます。

この段階で年額のSSPM製品を先に買うのは過剰です。診断結果を直す担当者と手順が決まっていない組織では、製品が出す警告も同じように放置されます。

SSPM製品が必要になる連携SaaSの数・監査要件・常時監視の条件

一方、次のいずれかに当てはまるならSSPM製品を検討します。

Salesforce・Slack・Box・GitHubなど、M365とWorkspace以外に機密データを持つ業務SaaSが10種類を超える
監査や取引先の審査で、設定状態の継続的な記録と逸脱時の対応履歴を求められる
管理者の設定変更を月次ではなく数分〜数時間の単位で検知したい

SCuBAの基準はM365とWorkspaceにしかなく、他のSaaSは設定項目の名前も取得APIもばらばらです。製品ごとにスクリプトを書いて保守する工数が、ライセンス費を上回った時点が切り替えどきになります。IaaSやPaaS側の設定監視は別領域で、CSPMの設定ミス検出の仕組みとCNAPPとの違いで扱っています。

SSOとSCIMで入口を一本化してから設定診断に進む順番の根拠

設定診断より先に手を付けるべきなのがIDの一本化です。SaaSごとにパスワードとアカウントが分かれている状態では、MFAの強制も退職者の削除も製品の数だけ作業が発生し、診断で見つけた不備を直しきれません。

IdPでSSOを受け、SCIMで入退社をSaaS側へ自動反映すれば、3類型のうち「退職者IDの残存」は構造的に消えます。条件付きアクセスでMFAも入口で一括して強制できる。プロトコルの分担はIDaaSとSAML・OIDC・SCIM連携の実装にまとめました。自社開発の業務システムまで含めてID基盤を寄せる設計や、SaaS非対応の社内システムを繋ぐ改修は、認証基盤・ID管理システム開発で相談を受け付けています。

SaaSを提供する側が顧客から問われるCSA SSCFとSOC2の確認項目

自社でSaaSを開発・提供する立場なら、問われる内容が逆になります。Cloud Security Allianceは2025年9月にSaaS Security Capability Framework（SSCF）v1.0を公開しました。変更管理と設定管理、データセキュリティ、IDとアクセス管理、相互運用性、ログと監視、インシデント対応の6領域で、SaaSが顧客に提供すべき設定可能なセキュリティ機能を定めています。

要するに、利用企業が本記事の手順を回せるだけの機能（SSO、SCIM、監査ログのAPI提供、同意の制限）を製品側が備えているかが問われる。事業者の統制を示す認証はSOC2の5基準と証跡の揃え方、政府調達向けはISMAPの管理基準と費用で解説しています。

よくある質問

SaaSセキュリティの対策を進めるときによく受ける質問をまとめました。

SaaSは自社サーバーよりセキュリティが低いのですか？

基盤部分は多くの場合、自社運用より強固です。OSやミドルウェアの脆弱性対応、物理的な防御、DDoS対策は事業者が専任体制で担い、第三者認証を取得している事業者も多い。弱くなりやすいのは利用側の設定とアカウント管理で、共有範囲の設定ミスや退職者IDの残存は事業者の対策では防げません。安全性はサービスの種類より、利用企業が自社の責任範囲を管理できているかで決まります。

ScubaGearやScubaGogglesは日本企業でも無料で使えますか？

使えます。どちらもCISAがGitHubで公開しているオープンソースで、米連邦機関向けに作られたものですが、利用者を限定していません。ScubaGearはCC0ライセンスです。ただし基準は米国の政府機関向けの水準なので、そのまま全項目を満たそうとすると業務に支障が出る設定も含まれます。不合格項目のうち自社で受け入れるものは、理由を記録したうえで除外する運用にしてください。

SSPMとCASBは何が違いますか？

見ている対象が違います。CASBは利用者とSaaSの間の通信やアクセスを可視化・制御し、未許可SaaSの利用検知やデータの持ち出し制御を担う製品群です。SSPMはSaaSの管理画面の設定値と連携アプリの権限を継続的に点検します。CASBは「誰がどのSaaSにどうアクセスしているか」、SSPMは「SaaSの設定が安全な状態か」を見るものと整理すると選び分けやすくなります。

社員が勝手に連携した外部アプリはどう見つければよいですか？

Microsoft 365ではGraph APIのoauth2PermissionGrantsでconsentTypeがPrincipalの付与を、Google WorkspaceではDirectory APIのtokens.listを全利用者分走査すると一覧化できます。どちらも管理者権限で読み取れる公式APIです。見つけた後は、業務で必要なものは管理者同意に切り替え、不要なものは取り消し、再発防止としてユーザー同意を検証済み発行元に限定する設定まで行います。

SaaSのセキュリティチェックシートでは何を確認すればよいですか？

事業者の統制と、自社が使う機能の両面を確認します。統制面はISMAPやSOC 2などの第三者認証、データの保管場所、障害とインシデントの通知方法です。機能面は、SSO（SAMLまたはOIDC）とSCIMへの対応、MFAの強制可否、監査ログの保持期間とAPIでの取得可否、外部共有とアプリ連携を管理者が制限できるかを見ます。機能面が欠けていると、導入後に利用側の対策が打てません。