SaaS（Software as a Service）は、事業者のクラウド上で動くアプリケーションを、ネットワーク経由で利用するサービス形態です。利用者はブラウザー、専用アプリ、プログラムから機能を使います。メール、ファイル共有、顧客管理、人事管理などが該当します。[1]

アプリケーションや基盤の運用は、主にSaaS提供者が担います。利用組織は、業務に使うデータと、そのデータを扱う利用者・権限・設定を管理します。具体的な分担は、サービスの仕様と契約で確かめます。[2]

例えば、顧客の契約書をファイル共有SaaSへ保存する場合、契約書を置く場所、閲覧できる人、社外への共有方法は利用組織が決めます。これらの判断を設定に反映することが、SaaSのセキュリティ管理の出発点となります。

本書は組織向けの管理標準案です。公開フレームワーク・指針の参照箇所は本文に示します。点検周期、判定規則、役割分担は、本書の提案として扱います。

管理方法を決めるには、まず各SaaSの用途を把握します。同じサービスでも、部門の予定調整に使う場合と、全社の機密情報を保管する場合では、事故の影響が変わります。

評価は「SaaS × テナント × 用途」を単位として行います。テナントとは、そのサービス上で組織ごとに設けられる管理領域を指します。部門やプロジェクトごとに設定が分かれる場合は、その領域も記録します。

利用者数に加え、保存するデータ、権限の強さ、接続先を確認します。例えば、利用者が数人でも、全顧客のデータを取得できる連携アプリを使う場合は、広い範囲に影響が及びます。

この情報をそろえると、SaaSごとの管理負荷と、事故時に影響を受ける範囲を説明できます。

利用部門は、そのSaaSで扱うデータの取扱条件を定めます。保存する情報に加え、入力、処理、出力、外部転送の対象も含めます。条件は、情報の重要性と業務上の用途に基づいて決めます。

データの取扱条件は、SaaS上の設定で具体化します。「取引先Aだけに共有する」という条件は、共有先の指定、本人確認、利用期限、再共有の範囲などに対応します。

実際に閲覧できる人は、組織全体の設定、フォルダーの設定、個別リンク、所属グループの権限を組み合わせて決まります。点検では、その組合せによって成立するアクセス範囲を確認します。

データの分類、共有先の判断、保存期間の決定は、利用部門が担当します。設定の実装は、IT部門や運用担当へ委ねることができます。

本書では、データへのアクセスや処理を決める設定、ID、権限、外部連携、保護・監視機能と、それらの関係を「構成」と呼びます。構成を把握すると、誰がどの経路でデータを扱えるかを確認できます。プログラムからSaaSの機能やデータを利用する窓口をAPIと呼びます。

SaaSを使う部門は、日々の利用とリスク管理を担う「1線」とします。セキュリティ統制部門は、共通ルールの策定と実行状況の確認を担う「2線」とします。以下の分担を本書の運用案とします。

データの取扱条件と実際の構成に差が生じると、想定した範囲を超えるアクセスや操作が可能になります。リスクは、その状態を通じて発生し得る損害として記述します。

一つのリスクには、対象データ、原因となる状態、アクセスする主体、操作、損害を記します。この組合せを「リスクシナリオ」と呼びます。

例えば「取引先向けに共有した顧客契約書が、広すぎる共有設定によって第三者に取得される」と記録します。これにより、共有設定の修正がどの損害を抑えるのかを追跡できます。

本章の事例は、管理対象とリスクの関係を説明するための想定例です。実際の評価では、利用しているデータと取得可能な操作記録を確認します。

適切な権限を持つ利用者による持ち出しも、SaaSのリスクに含まれます。ログイン後の利用状態（セッション）を維持する認証情報が盗まれ、悪用される場合もあります。さらに、提供者の障害や侵害は、利用組織の業務継続に影響します。これらは、構成の管理に加えて、操作の監視や復旧への備えを検討する対象となります。

CSAのSaaS Security Capability Framework（SSCF）は、提供者が利用者へ提供するセキュリティ機能を整理した枠組みです。管理領域の分類をSSCFの6領域に合わせ、各リスクに関連する領域を付けます。[3][4]

表の確認内容とリスク例は、本書で利用組織向けに整理したものです。提供者の管理や事業継続まで評価する際は、CSA Cloud Controls Matrix（CCM）の関連領域を併用します。[7]

各シナリオについて、損害の大きさを示す「影響」と、損害が生じる「発生可能性」を評価します。次の尺度を本書の運用案とします。評価対象期間は、評価日から12か月間とします。リスク評価の考え方はNIST SP 800-30を参照します。[6]

影響は、漏えい、改ざん、利用停止のそれぞれを検討し、最も高い段階を採ります。発生可能性には、実際の設定、変更頻度、アクセス条件、確認できた対策を反映します。

確認に必要な記録（証跡）が不足する場合は、評価の状態を「未評価」として記録します。前回の評価がある場合は、その値と確認不足の範囲を併記します。重要データに関する未評価事項は、2線が追加確認を優先します。

高・中・低はリスクの段階を表します。「未評価」は確認状況として別欄で管理します。

構成管理は、管理する対象を識別し、承認された基準に従って設定と変更を管理する活動です。現状の記録、定期的な照合、差異の是正を継続します。セキュリティを構成管理に組み込む考え方は、NIST SP 800-128で示されています。[5]

全SaaSの利用部門に、この管理義務を適用します。管理する設定の項目と値は、サービスの機能と利用条件に合わせて定めます。

CM番号は本書の管理要求を識別する番号です。第3章の管理領域との対応を各記録に付け、2線が実行状況を確認できる形で保存します。

対象は、データへの到達、操作権限、外部への転送、保護、監視、復旧に影響する構成とします。業務上の承認経路や出力先も、この条件に該当する場合は対象に含めます。

基準は、組織の情報管理方針と適用される義務を確認して作成します。サービスの公式仕様や推奨値は、実装方法を決める際の根拠として参照します。利用責任者が業務上の妥当性を確認し、所定の権限で承認します。

例えば、顧客契約書の共有では「承認された相手だけが閲覧できること」を要求します。その実装として、本人確認を伴う招待制の共有と、有効期限を設定します。

基準どおりの機能を利用できるかは、契約プランと管理権限を含めて確認します。実装上の制約は、代替策と残余リスクの評価に引き継ぎます。

定期点検は、全SaaSについて前回完了日から12か月以内を基本とします。変更が多い対象や、前回の点検で管理漏れ・再発が見つかった対象は、6か月以内の点検を検討します。周期は利用部門が提案し、2線が妥当性を確認します。

12か月・6か月は本書の運用案です。損害が短時間で発生するシナリオには、第6章で示す事前制限や短周期の監視を組み合わせます。

日常の変更は、入退社、異動、権限申請、外部共有、連携追加などの業務手続に組み込みます。定型作業は、承認済みの条件と手順に従って実施します。重要な変更は、個別の影響確認と承認を行います。

自動取得や既存の申請システムで確認できる記録は、定期点検にも利用します。利用部門は、確認した範囲と時点が分かる形で記録を整理します。

担当者やAIによる解釈の差を抑えるため、各要求には適用条件、期待する状態、確認方法、判定結果を定めます。判断の根拠となる事実と、業務上の承認を、それぞれ記録します。

必須機能の不足が確認された場合は、不適合として理由を記録します。例外が承認された場合は、判定に加えて承認者と有効期限を記録します。残余リスクは、対策の実際の効果に基づいて評価します。

「顧客契約書の閲覧者は承認した相手に限定する」という基準を確認します。組織共通の共有制限に加え、既存の共有リンクと個別権限を取得します。取得できた範囲が必要範囲を満たし、承認先と一致した場合に適合とします。

AIは、設定項目の抽出、証跡の整理、規則に沿った照合、変更案の作成に利用します。固定値や一覧の比較には、定義済みの処理を使います。調査には読取専用の権限を用い、設定変更は所定の承認後に実行します。

管理画面や文書の内容は、評価対象のデータとして扱います。実行する指示は承認済み手順に限定します。判定が分かれた項目は、担当者が根拠を確認し、判断規則へ反映します。

構成管理により、利用部門は管理対象と基準を把握し、設定の差異を発見・是正できます。効果は、設定不備の発生を抑えることと、発生した不備を解消することに分けて確認します。

効果の評価では、管理対象の範囲、基準の内容、実際の適用、是正までの時間を確認します。例えば、不要な連携を失効した記録があれば、その連携経由でアクセスされる範囲を低減したと評価できます。

点検実施率は、共通対策が回っているかを示します。対象の把握率や是正までの時間は、管理の到達範囲と処理速度を示します。これらを、リスクシナリオごとの残るアクセス経路と合わせて評価します。

共通対策の低減効果は、対象と証跡に基づいて個別に説明します。事故発生確率を算定する場合は、発生実績や曝露条件を用いた別の分析が必要となります。

設定不備が点検の直後に発生した場合、次の定期点検まで存在し続けることがあります。年次を半期へ変えると、この期間を短縮できます。

表は、不備の発生時刻が点検間で一様に分布し、次回点検で必ず発見されると仮定した計算例です。点検間隔をTとすると、平均未検知期間はT／2となります。発見から是正までの時間rを加えると、平均してT／2＋rの間、不備が存在します。

現在の設定値からは、点検時点で継続している不備を確認できます。短時間で設定が変わり、その後に元へ戻った場合は、変更履歴や操作記録を確認します。

例えば、顧客資料が一時的に社外へ公開され、その間に取得された場合、後日の共有設定は適切な状態になっていることがあります。被害の確認には、公開された時点と、その期間のアクセス記録が必要となります。

上の計算が示すのは、仮定の下での未検知期間です。損害の発生可能性は、共有先、アクセスの機会、保護機能などを含めて評価します。

対策を適用した後も残る損害の可能性を「残余リスク」と呼びます。構成管理で確認した基準と実設定を踏まえ、残る経路について影響と発生可能性を再評価します。既存の認証、データ保護、監視機能の効果も、適用状況を確認して反映します。

表は、記載した条件に基づく架空の評価例です。実際の評価では、各対策の適用範囲と運用記録を確認します。

大規模なSaaSでは、データ量、利用部門、権限の種類、個別共有、外部連携が増えやすくなります。さらに変更が頻繁な場合、定期点検で確認した状態からの変化も多くなります。

このような利用では、点検間の変化や多数の権限関係を追跡する負荷が増します。残余リスクを評価する際は、管理対象の多さ、変更頻度、被害範囲、必要な対応速度を確認します。

構成管理で整理できた部分と、現在も成立する経路を記録すると、追加対策が必要な箇所が明確になります。例えば、全社共有では「設定の継続確認」と「データ取得の監視」を別々の必要機能として検討できます。

追加対策は、残余リスクが組織の許容範囲を超えるシナリオに適用します。まず、既存の機能と運用で対応できる範囲を確認します。そのうえで、取得する情報、制限する操作、検知・是正までの時間を定めます。

構成情報を取得するまでの時間、分析時間、担当者の判断待ち、アクセス停止までの時間を確認します。合計が被害の発生・拡大に間に合うように、監視頻度と対応手順を設計します。

顧客契約書が公開直後に取得され得る場合は、共有先の事前制限を優先します。短周期の設定確認と操作監視は、意図しない変更の発見や、被害範囲の把握に利用します。

対策の選択では、対象のSaaSで使える機能を確認します。必要な機能を既存の契約で利用できる場合は、その適用を検討します。追加機能が必要な場合は、対象範囲、取得できる情報、運用負荷を比較します。

表の方法は機能を実装する候補です。対応範囲は、各サービスと製品の仕様で確認します。例として、Microsoftの公開資料には、SaaSの構成評価と、OAuthアプリを経由する攻撃経路の可視化（プレビュー）が記載されています。[8]

SSPM（SaaS Security Posture Management）は、SaaSの構成や権限などを取得し、セキュリティ上の状態を評価する仕組みです。製品によっては、外部連携、データの公開範囲、不審な操作も扱います。AppOmniの公開資料では、これらを含むSaaS向けの機能が説明されています。[9]

全社ファイル共有では、所属グループ、フォルダーの継承、個別リンク、連携アプリが重なってアクセス範囲を作ります。リスクを評価するには、これらをまとめて把握する機能が必要になります。

必要な情報を既存製品から取得できるかを確認します。SSPMがその情報の取得と解析を提供する場合は、追加対策の候補となります。代替方法を比べる際は、同じ対象と取得周期で運用できることを条件とします。

残余リスクへの効果は、取得・評価できた範囲と、是正までの運用に基づいて判断します。

SIEM（Security Information and Event Management）は、複数のシステムから記録を集めて分析する基盤です。SSPM等から得た権限や共有範囲に、認証、端末、SaaSの操作記録を組み合わせると、調査対象を具体化できます。Google Security Operationsには、AppOmniの評価結果、操作イベント、アラートを取り込む方法が公開されています。[10]

上表は必要な記録が取得できる環境を想定した例です。検知後は、業務上の一括処理などを確認して対応を判断します。

テナント、利用者、アプリ、対象データを識別するIDを対応付けます。操作の発生時刻と、構成を取得した時刻も記録します。過去の操作を評価する際は、その時点の構成を確認します。

必要な記録の取得範囲、受信の遅れ、欠損を監視します。通知先と、共有停止・ID失効を行う権限を定め、検知から対応までの経過を保存します。

2線は、利用部門の構成管理が定めた範囲と周期で実施されているかを確認します。その結果をもとに、残余リスクの評価と追加対策の必要性を検証します。

全SaaSについて、責任者、適用基準、点検日、未処理事項、残余リスクを確認します。詳細な実設定の検証は、重要なデータ、多数の権限・連携、変更の多い領域、不備の再発箇所を優先します。

抽出して確認する場合は、対象全体、抽出件数、選定理由、確認済み範囲を記録します。未検証事項には、追加確認の担当者と期限を設定します。

利用部門は、この記録を使って管理内容を更新します。2線は、組織全体で残るリスクと必要な追加対策を取りまとめます。