はじめに：なぜ今、SaaS監査が重要なのか

企業のクラウドサービス利用は、もはや例外ではなく標準となりました。総務省の調査によると、日本企業のクラウドサービス利用率は2023年時点で72.2%に達し、その中でもSaaS（Software as a Service）の利用は特に顕著な伸びを見せています。

しかし、SaaSの普及に伴い、新たなリスクも浮上しています。2023年には大手SaaSプロバイダーでの情報漏洩事故が複数発生し、利用企業にも甚大な影響を与えました。こうした背景から、外部サービスのリスク評価、すなわちSaaS監査の重要性が急速に高まっています。

本記事では、IT監査・セキュリティ担当者の皆様に向けて、SaaS監査の具体的な方法とリスク評価のポイントを実務視点で解説します。

SaaS監査とは：基本概念の整理

SaaSの定義と特徴

SaaS（Software as a Service）とは、インターネット経由で提供されるソフトウェアサービスのことです。ユーザーはソフトウェアをインストールすることなく、Webブラウザ等からアクセスして利用できます。

代表的なSaaSの例：

  • コミュニケーション系：Microsoft 365、Google Workspace、Slack、Zoom
  • 業務系：Salesforce、freee、マネーフォワード、SmartHR
  • 開発系：GitHub、Jira、Notion

SaaSの特徴として、以下の点が挙げられます：

特徴内容
マルチテナント複数の顧客が同一のインフラを共有
サブスクリプション月額・年額課金が一般的
自動アップデートプロバイダー側で機能更新・パッチ適用
データの外部保管顧客データがプロバイダーの環境に保存

SaaS監査の目的

SaaS監査の主な目的は以下の3点です：

  1. リスクの可視化：外部サービス利用に伴うセキュリティリスク、コンプライアンスリスクを特定する
  2. ガバナンスの確保：シャドーIT（未承認SaaS）の把握と管理体制の構築
  3. 継続的モニタリング：プロバイダーのセキュリティ状況の変化を追跡する

SaaS監査の7つのステップ

ここからは、実務で活用できるSaaS監査の具体的な手順を7つのステップで解説します。

ステップ1：SaaS利用状況の棚卸し

最初に行うべきは、自社で利用しているSaaSの全体像を把握することです。

多くの企業では、想定以上に多くのSaaSが利用されています。ある調査では、従業員1,000人以上の企業で平均200以上のSaaSが利用されているという結果も出ています。

棚卸しの方法

  1. IT部門管理のサービス一覧の確認

    • 契約管理台帳、経費精算システムからの抽出
    • SSO（シングルサインオン）連携済みサービスの確認

  2. シャドーITの発見

    • CASB（Cloud Access Security Broker）ツールの活用
    • ネットワークログ（プロキシログ、ファイアウォールログ）の分析
    • 従業員へのアンケート調査

  3. SaaS管理プラットフォーム（SMP）の導入検討

    • Zylo、Productiv、Torii等のツールで自動検出

実務ポイント

棚卸し結果は以下の項目を含むリストとして整備しましょう：

- サービス名
- プロバイダー名
- 契約部門・管理者
- 利用開始日
- 月額/年額費用
- 利用ユーザー数
- 取り扱うデータの種類（個人情報、機密情報等）
- 契約形態（直接契約/代理店経由）

ステップ2：リスク分類とティアリング

全てのSaaSを同じ深度で監査することは現実的ではありません。リスクベースアプローチに基づき、優先順位付けを行います。

リスク分類の基準

以下の観点からSaaSをティア（層）に分類します：

ティア基準例監査頻度
Tier 1（高リスク）機密情報・個人情報を大量に扱う、業務停止時の影響大基幹システム連携SaaS、人事系SaaS年1回以上
Tier 2（中リスク）業務に必要だが代替可能、限定的な情報を扱うプロジェクト管理ツール、ドキュメント共有2年に1回
Tier 3（低リスク）機密情報を扱わない、個人利用レベル名刺管理、アンケートツール3年に1回または変更時

スコアリングの例

定量的な評価を行う場合、以下のようなスコアリングシートを活用します：

評価項目（各5点満点）：
1. データの機密性レベル：__点
2. データ量：__点
3. 業務依存度：__点
4. ユーザー数：__点
5. 外部連携（API等）の有無：__点

合計：__点/25点

→ 20点以上：Tier 1
→ 10〜19点：Tier 2
→ 9点以下：Tier 3

ステップ3：プロバイダーのセキュリティ評価

SaaS監査の核心となるのが、プロバイダーのセキュリティ体制の評価です。

評価の情報源

  1. 第三者認証・監査報告書

    • SOC 2 Type II報告書：最も重要な評価資料。セキュリティ、可用性、処理のインテグリティ、機密性、プライバシーに関する統制を評価
    • ISO 27001認証：情報セキュリティマネジメントシステムの国際規格
    • ISO 27017/27018：クラウドサービス固有のセキュリティ・プライバシー規格
    • PCI DSS：決済データを扱う場合に確認

  2. プロバイダーのセキュリティドキュメント

    • セキュリティホワイトペーパー
    • トラストセンター（Salesforce Trust、Google Cloud Security等）
    • プライバシーポリシー・データ処理契約（DPA）

  3. セキュリティ質問票（SIG/CAIQ）

    • SIG（Standard Information Gathering）：Shared Assessmentsが提供
    • CAIQ（Consensus Assessment Initiative Questionnaire）：CSA（Cloud Security Alliance）が提供

SOC 2報告書の読み方

SOC 2 Type II報告書を入手したら、以下の点を重点的に確認します：

□ 報告書の対象期間（通常12ヶ月）
□ 対象となるサービス範囲（自社利用サービスが含まれているか）
□ 監査法人の意見（適正意見か、限定付適正意見か）
□ 例外事項（Exceptions）の有無と内容
□ 補完的ユーザー統制（CUEs）の確認

実務ポイント：SOC 2報告書はNDA（秘密保持契約）締結後に開示されることが一般的です。営業担当経由で早めにリクエストしましょう。

ステップ4：契約・法務面の確認

セキュリティ技術面だけでなく、契約条件のリスク評価も重要です。

確認すべき契約条項

確認項目ポイント
データの所有権顧客データの所有権が明確に顧客側にあるか
データの所在地データセンターの物理的な所在国
サブプロセッサー再委託先の開示と管理体制
データ削除契約終了時のデータ削除・返却手続き
インシデント通知セキュリティインシデント発生時の通知義務と期限
監査権顧客による監査の可否
責任制限損害賠償の上限設定
準拠法・管轄紛争時の適用法と裁判管轄

GDPR・個人情報保護法対応

EU域内の個人データを扱う場合や、日本の個人情報保護法への対応として、以下を確認します：

  • **データ処理契約（DPA）**の締結
  • **標準契約条項（SCC）**の採用（EU域外へのデータ移転時）
  • 越境移転への対応方針

ステップ5：技術的セキュリティ設定の確認

プロバイダー側のセキュリティに加え、自社側の設定もリスク要因となります。

確認すべき設定項目

  1. 認証・アクセス制御

    • 多要素認証（MFA）の有効化
    • SSO連携の実施状況
    • パスワードポリシーの設定
    • 最小権限の原則に基づくロール設定

  2. データ保護

    • 通信の暗号化（TLS 1.2以上）
    • 保存データの暗号化
    • データエクスポート制限
    • DLP（Data Loss Prevention）機能の活用

  3. 監査ログ

    • アクセスログの取得・保存期間
    • 管理者操作ログの確認
    • SIEM連携の可否

  4. 外部連携

    • API連携の把握と制限
    • OAuth認可済みアプリの棚卸し
    • サードパーティアドオンの管理

設定監査ツールの活用

主要なSaaSには設定監査ツールが存在します：

  • Microsoft 365：Microsoft Secure Score
  • Google Workspace：セキュリティ調査ツール
  • Salesforce：Salesforce Health Check
  • AWS/Azure/GCP：各種セキュリティスコアリング機能

これらを定期的に実行し、推奨設定との乖離を確認します。

ステップ6：継続的モニタリング体制の構築

SaaS監査は一度きりではなく、継続的なプロセスとして運用します。

モニタリングの仕組み

  1. 定期的な再評価

    • 年次のセキュリティ評価更新
    • 契約更新時のレビュー
    • 重大なセキュリティインシデント発生時の緊急評価

  2. 自動化ツールの活用

    • セキュリティレーティングサービス：SecurityScorecard、BitSight、RiskRecon等
    • SaaS Security Posture Management（SSPM）：Adaptive Shield、AppOmni、Obsidian等

  3. インシデント情報の収集

    • プロバイダーのステータスページの監視
    • セキュリティニュースのウォッチ
    • 脆弱性データベース（CVE等）の確認

KPIの設定例

SaaS監査の有効性を測定するKPIの例：

- 管理台帳に登録されたSaaSの割合：目標95%以上
- Tier 1 SaaSの年次監査完了率：目標100%
- 高リスク設定の是正完了率：目標90%以上
- セキュリティインシデント検知から初動対応までの時間：目標24時間以内

ステップ7：報告と改善サイクル

監査結果は適切に報告し、改善につなげます。

報告書の構成例

1. エグゼクティブサマリー
   - 全体的なリスク評価結果
   - 重要な検出事項のハイライト
   
2. 監査対象と範囲
   - 対象SaaS一覧
   - 評価基準と手法

3. 検出事項
   - リスクレベル別の分類
   - 各事項の詳細説明と推奨対策

4. プロバイダー別評価
   - 個別SaaSの評価スコアカード

5. 改善計画
   - 優先度付けされた対応項目
   - 担当者と期限

6. 付録
   - 詳細な評価シート
   - 根拠資料

報告先と頻度

報告先頻度内容
経営層・取締役会年1〜2回エグゼクティブサマリー、重大リスク
情報セキュリティ委員会四半期全体状況、改善進捗
IT部門・利用部門月次具体的な設定変更指示、新規SaaS評価結果

よくある質問（FAQ）

Q1：SOC 2報告書を提供してもらえないSaaSはどう評価すればよいですか？

A1：SOC 2報告書がない場合、以下の代替手段を検討します。

  1. 他の認証の確認：ISO 27001、CSA STAR等の認証取得状況
  2. セキュリティ質問票の送付：CAIQやSIGを直接送付して回答を求める
  3. 公開情報の精査：セキュリティホワイトペーパー、プライバシーポリシーの詳細確認
  4. セキュリティレーティング：SecurityScorecard等の外部評価の参照

ただし、Tier 1に分類される重要なSaaSで十分な評価情報が得られない場合は、利用継続の可否を含めて検討が必要です。代替サービスへの移行も選択肢に含めましょう。

Q2：シャドーITが発見された場合、どのように対応すべきですか？

A2：発見したシャドーITへの対応は、以下のステップで進めます。

  1. 即座にブロックしない

    • まず利用状況と業務への影響を把握
    • 突然のブロックは業務停止や代替手段（さらに危険なサービス）への移行を招く

  2. リスク評価の実施

    • 取り扱われているデータの種類
    • 利用ユーザー数と範囲
    • プロバイダーのセキュリティ状況

  3. 対応方針の決定

    • 承認：正式にIT部門管理下に置く
    • 代替：承認済みの類似サービスへ移行
    • 禁止：高リスクと判断した場合はブロックと削除

  4. 再発防止策

    • SaaS利用申請プロセスの周知
    • 承認済みSaaSカタログの整備と公開
    • 検知・監視体制の強化

実務ポイント：シャドーITが発生する根本原因は「公式プロセスが面倒」「ニーズに合うツールがない」であることが多いです。利用部門のニーズを汲み取り、迅速な評価・承認プロセスを整備することが予防につながります。

Q3：SaaS監査の体制づくりに必要なリソースはどの程度ですか？

A3：企業規模と利用SaaS数によりますが、以下が目安です。

中堅企業（従業員500〜1,000人、SaaS 50〜100個）の場合：

項目内容
専任人員0.5〜1名相当（他業務との兼務可）
初期構築期間3〜6ヶ月（棚卸し、プロセス整備、ツール導入）
年間運用工数200〜400時間程度
ツール費用CASB/SSPM：年間100〜500万円程度（規模による）

コスト削減のポイント：

  • 全てを内製せず、セキュリティレーティングサービス等のツールを活用
  • Tier分類により監査深度にメリハリをつける
  • 契約更新タイミングに合わせた効率的な評価スケジュール
  • 業界内での情報共有（同業他社が評価済みのSaaSは情報交換）

まとめ：SaaS監査を成功させるために

SaaS監査は、現代のIT環境において避けては通れない重要な管理活動です。本記事で解説した7つのステップを振り返ります。

  1. SaaS利用状況の棚卸し：見えないリスクは管理できない
  2. リスク分類とティアリング：限られたリソースを効果的に配分
  3. プロバイダーのセキュリティ評価：SOC 2等の第三者評価を活用
  4. 契約・法務面の確認：技術だけでなく契約もリスク要因
  5. 技術的セキュリティ設定の確認：自社側の設定ミスも見逃さない
  6. 継続的モニタリング体制の構築：一度きりでなく継続的に
  7. 報告と改善サイクル：検出事項を確実に改善につなげる

最後に

SaaS監査は、「外部サービスだから管理できない」という諦めから脱却するための取り組みです。確かに、オンプレミス環境のように全てをコントロールすることはできません。しかし、本記事で紹介した方法を実践することで、リスクを可視化し、許容可能なレベルに管理することは十分に可能です。

まずは自社のSaaS棚卸しから始めてみてください。現状が見えてくれば、次に何をすべきかは自ずと明らかになるはずです。

参考資料・リンク：

  • Cloud Security Alliance (CSA) - CAIQ
  • Shared Assessments - SIG Questionnaire
  • AICPA - SOC 2報告書ガイダンス
  • IPA（情報処理推進機構）- クラウドサービス利用に関するガイドライン