SaaSリスクの管理と統制
文書番号：2609.00011
要旨
SaaSを安全に利用するには、提供企業の運用と、利用企業が決める権限・共有・連携・業務手続を対応付ける必要があるのだ。本稿は、公開された定義、製品資料、公表事例を用いて、利用構造、攻撃面、リスク、対策、統制、製品別の確認、管理手段、残余リスクの判断を一つの流れとして整理するのだ。
設定基準と実設定の一致は管理の一部であり、正規権限の悪用、業務上の不正、提供側の事故には別の対策と証跡が必要なのだ。製品や自己評価の点数を到達点とせず、必要な対策の実施と残るリスクを責任者が判断できる状態を目指すのだ。製品情報と脅威動向は2026年9月27日時点の公開資料に基づく記録であり、架空の業務例・確認票・時間モデルと、実際の公表事例を区別するのだ。
想定読者は、SaaSの所管部門、IT運用、セキュリティ、内部監査の担当者なのだ。基本概念は第1〜4章、対策と責任分担は第6〜7章、製品別の実施確認は第8章と付録から参照できるのだ。設定点検に絞った運用は事前確認の記事、SSPMの導入費用と運用負荷は導入効果と運用TCOの記事で詳しく扱うのだ。
1 目的と範囲 ｜ 2 利用構造 ｜ 3 攻撃面 ｜ 4 リスク ｜ 5 脅威動向と公表事例 ｜ 6 対策 ｜ 7 統制 ｜ 8 製品別適用 ｜ 9 管理手段 ｜ 10 残余リスクの判断 ｜ 付録A 業務別確認 ｜ 付録B 実務資料 ｜ 参考文献
第1章 SaaSリスクを管理する目的と範囲
SaaSの安全性は、提供企業のサービス基盤だけでは決まらないのだ。利用企業が誰に何を許可し、どの情報を預け、変更や事故にどう対応するかによっても変わるのだ。本稿では、この利用企業側の判断を、通常業務の理解から管理・統制の実施へつなげるのだ。
1.1 SaaSを利用する業務
SaaSを検討する出発点は、製品名ではなく、そのサービスに任せる業務なのだ。まず、サービスを利用するとは何を外部へ委ねることなのかを確認するのだ。
1.1.1 業務アプリケーションのサービス利用
SaaS（Software as a Service）は、提供企業が運用するアプリケーションを、ネットワーク経由で利用する形態なのだ。利用企業は通常、基盤となるサーバーやOSを直接管理しないのだ。一方、アプリケーションに用意された範囲で、利用者や利用方法を設定するのだ。NISTも、基盤を管理する立場と、限定されたアプリケーション設定を扱う利用者の立場を区別しているのだ。[1]
自社運用からSaaSへ移ると、サーバーの更新などの作業は提供企業へ移るのだ。しかし、「顧客名簿を誰に見せるか」という判断まで自動的に移るわけではないのだ。設備の管理が減ることと、業務上の判断が減ることは別なのだ。
1.1.2 営業・共同作業・経費精算の利用場面
以後の説明では、三つの架空業務を共通の例として使うのだ。営業部門は顧客連絡先と商談記録を管理するのだ。プロジェクト部門は設計資料を取引先と共有するのだ。経理部門は従業員の経費申請を承認し、会計システムへ渡すのだ。
営業業務では顧客情報の持ち出しが問題になるのだ。共同作業では共有相手の取り違えが問題になるのだ。経費精算では、情報が漏れなくても、不正な承認や重複した支払いが損失を生むのだ。このように、同じ「SaaSの安全性」という言葉でも、保護すべき業務結果は異なるのだ。
1.2 利用企業の管理課題と保護対象
業務の目的が分かると、利用企業が避けたい損失も具体化するのだ。その損失を抑えるために、提供企業の仕事と自社の判断を区別するのだ。
1.2.1 サービスの運用委託と自社の利用判断
利用企業は、提供企業の運用能力と、自社の使い方を別々に評価するのだ。前者では、障害対応、基盤の保護、情報の保管条件などを確認するのだ。後者では、投入するデータ、利用者、共有先、許可する操作を決めるのだ。Microsoftの責任共有の説明でも、SaaS利用時に顧客が扱うデータやアクセス管理の責任が残るのだ。[2]
提供企業の認証取得や監査報告は、前者を評価する材料になるのだ。それだけで、自社が公開したファイルの共有先や、経費承認の正当性を確認したことにはならないのだ。利用企業は、提供側の保証と自社側の運用証跡を結び付けて利用を判断するのだ。
1.2.2 情報の保護と業務の維持
保護対象は、情報そのものと、その情報を使う業務なのだ。機密性は、認めた相手以外へ情報を渡さない性質を指すのだ。完全性は、情報や処理結果を意図した状態に保つ性質を指すのだ。可用性は、必要なときに業務で利用できる性質を指すのだ。
架空の経費精算では、領収書に含まれる従業員情報の漏えいは機密性の問題になるのだ。振込先の改変は完全性の問題になるのだ。締め日にサービスへ接続できないことは可用性の問題になるのだ。目的外利用や保存条件の違反は、これらに加えて、契約や個人情報の取扱要件から評価するのだ。[3][4]
1.2.3 個別サービスの安全確認と全社の管理
個別の設定確認は、「その時点の、その項目が、基準に合っていたか」を確認する作業なのだ。組織の管理は、確認する対象、基準の決定者、変更の承認者、不備の是正責任までを扱うのだ。
例えば、管理者が外部共有を無効にしても、後任者が理由を知らずに有効へ戻せば、対策は継続しないのだ。基準値、適用対象、変更理由、実設定、確認結果を保持すれば、変更の妥当性を後から検証できるのだ。個人の注意を組織の再現可能な作業へ変えることが、統制の役割なのだ。
1.3 本稿の目的と対象範囲
本稿の目的は、SaaSのリスクを理解したうえで、必要な管理を設計し、実施状態を確かめ、残るリスクを判断できるようにすることなのだ。
1.3.1 SaaSリスクの理解と管理・統制
SaaSリスクの管理とは、業務に生じ得る損失を特定し、発生条件と影響を評価し、必要な対策を選んで維持することなのだ。統制は、その管理を担当者の裁量だけに依存させず、責任、承認、証跡、是正によって継続させる仕組みなのだ。
実務上の到達点は、自社の利用環境について、設定基準と実設定を対応付け、権限と処理の正当性を検証できる状態なのだ。さらに、確認できない事項を残余リスクの判断へ渡し、必要に応じて対策や利用範囲を見直せなければならないのだ。
1.3.2 対象範囲：利用企業の判断と提供企業への依存
対象は、利用企業が変更できる設定、権限、データ取扱い、業務手続と、提供企業への依存なのだ。顧客管理や共同作業だけでなく、GitHubの開発ワークフロー、クラウド型WAF、クラウド型EDRの管理機能も含めるのだ。これらも、企業が外部サービスへ権限や情報を委ねる利用だからなのだ。
提供基盤の実装脆弱性や障害は、自社の設定変更だけでは除去できないのだ。それでも、預ける情報の限定、連携権限の縮小、復旧手段、契約上の連絡条件は評価できるのだ。端末内部の防御技術の比較と、製品導入プロジェクトの日程は本稿の範囲に含めないのだ。
1.3.3 論点の区分：利用構造・攻撃面・リスク・対策・統制
利用構造は、誰がどのサービスで何を扱うかを示すのだ。攻撃面は、その情報や処理へ到達できる接点を示すのだ。リスクは、接点の悪用や誤操作などによって生じる損失の可能性を扱うのだ。対策は、その成立条件や影響を変えるのだ。統制は、対策を実施・確認する責任を定めるのだ。
この区別を保ったまま、公表事例、製品別の設定、管理手段へ進むのだ。最後に、対策の実施証跡から残余リスクを評価するのだ。「どの製品を購入するか」は、その評価で不足が明らかになった場合の選択肢の一つなのだ。
第2章 SaaSの利用構造と責任分担
通常の利用構造が分からなければ、攻撃者が何を悪用したのかも判定できないのだ。本章では、責任を担う主体と、処理を行う構成要素を分けるのだ。その後、情報の流れに沿って管理の境界を確認するのだ。
2.1 SaaS利用に関わる主体
SaaS利用には、サービスを運営する企業、業務を担う利用企業、取引や委託で関与する相手がいるのだ。ここでは、意思決定や作業の責任を担う企業・部門・人を「主体」とするのだ。
2.1.1 SaaS・連携サービスの提供企業
SaaS提供企業は、アプリケーションと提供基盤を運営するのだ。別のサービスを接続する場合は、その連携サービスにも運営企業が存在するのだ。契約の窓口が販売代理店であっても、実際の運営者や事故調査者が同じとは限らないのだ。
利用企業は、契約先、運営企業、保守を行う企業、再委託先を区別して記録するのだ。障害の連絡先だけでなく、設定の説明、アクセス記録の提出、データ削除の確認を誰に求めるかを明らかにするのだ。サービス名は構成要素の識別に使い、責任主体の代わりには使わないのだ。
2.1.2 利用企業の所管部門・管理者・利用者
所管部門は、SaaSを使う業務とデータに責任を持つのだ。管理者は、その業務判断を設定へ反映するのだ。利用者は、許可された範囲で日々の処理を行うのだ。同じ従業員が複数の役割を担う場合でも、役割としては分けて扱うのだ。
例えば、経理責任者は承認経路を決めるのだ。SaaS管理者は経路を設定するのだ。承認者は個々の申請を判断するのだ。管理画面を操作できることだけを理由に、管理者へ業務上の承認権限まで与える必要はないのだ。
2.1.3 取引先・業務委託先
取引先は、共同作業や取引に必要な情報を受け取るのだ。業務委託先は、契約した業務や運用を代行するのだ。両者は外部の相手でも、必要なデータと操作の範囲が異なるのだ。
共同作業の例では、設計協力会社には担当案件の資料閲覧を認めるのだ。一方、SaaS運用委託先には利用者管理を任せる場合があるのだ。前者の参加期限と、後者の管理権限の期限は、別々の責任者が判断するのだ。外部企業を一つの「ゲスト」一覧にまとめるだけでは、この違いを表せないのだ。
2.2 利用環境の構成と業務データの流れ
各主体は、端末、SaaS、連携サービスを通じて業務を行うのだ。管理対象を特定するには、サービスの名称に加え、利用環境の区切りとデータの流れが必要になるのだ。
2.2.1 契約・テナント・利用環境の区切り
テナントは、提供サービス内で組織の利用や管理を区切る単位なのだ。ただし、契約、テナント、業務上の管理範囲が常に一対一になるわけではないのだ。製品によって、組織、サイト、ワークスペース、アプリなどの下位単位も管理対象になるのだ。[2][5]
台帳では、製品名だけでなく、環境を一意に識別するID、契約、所管部門、下位の対象を保持するのだ。「M365を確認済み」という記録だけでは、どのテナントのどのサイトを確認したか分からないのだ。後の証跡も、この環境IDへ対応付けるのだ。
2.2.2 利用端末・SaaS・連携サービスの構成
架空の営業業務は、従業員端末、認証を担うサービス、顧客管理SaaS、データを受け取る連携先から成るのだ。共同作業では共有サイトが加わるのだ。経費精算では、会計システムや振込データの受け渡し先が加わるのだ。
開発サービスには、コードを保管する場所と、コードを実行する場所があるのだ。クラウド型セキュリティ製品には、管理画面と、管理されるWebサイトや端末があるのだ。構成図では、保存先、実行先、管理対象を分けるのだ。特に、管理サービスの操作が別のシステムへ及ぶ場合は、その向きも記録するのだ。[6][7]
2.2.3 入力・保存・閲覧・承認・出力の業務処理
三つの業務を、データの処理段階へ分解すると次のようになるのだ。表は架空の利用構成であり、各製品の必須機能を示すものではないのだ。
| 業務 | 入力・保存 | 閲覧・判断 | 出力・後続処理 |
|---|---|---|---|
| 営業 | 顧客連絡先と商談を登録 | 担当者と上司が案件を確認 | 承認された対象を分析用に連携 |
| 共同作業 | 設計資料を登録 | 社内担当と指定の取引先が確認 | 承認済み版を配布 |
| 経費精算 | 申請と領収書を登録 | 上司が業務妥当性を承認 | 経理が会計へ出力 |
管理者は、この段階ごとに処理する人と許可する操作を対応付けるのだ。閲覧者の一覧だけでは、承認や出力を行う権限の評価が抜けるのだ。
2.2.4 端末・共有先・連携サービスへのデータ移動
データは、元のSaaSに保存されている間だけ管理すればよいわけではないのだ。出力したCSV、共有先に保存された文書、連携先の複製、サポートへ送ったログにも同じ情報が含まれ得るのだ。元データを削除しても、別の場所へ渡したコピーの削除までは確認できないのだ。
クラウド型WAFでは、利用者のWeb通信と、管理者の設定変更の通信を分けるのだ。EDRでは、端末からログが集まり、管理側から端末へ指示が返るのだ。利用企業は、この双方向の流れを管理対象に含めるのだ。情報の流れと権限の流れは、一致するとは限らないのだ。
2.3 提供企業と利用企業の責任分担
構成と処理が分かると、各部分を誰が変更できるかを整理できるのだ。責任分担は、提供企業か利用企業かを一括で決めるのではなく、作業と設定の単位で確認するのだ。
2.3.1 提供企業が運用するサービス基盤
SaaS提供企業は、サービス基盤の運用を担うのだ。しかし、利用企業がその内部へ直接入って設定を検証できるとは限らないのだ。利用企業は、公開仕様、契約、監査報告、障害報告から、提供側の管理範囲と確認可能な証拠を把握するのだ。[1][2]
「バックアップを取得している」という回答だけでは、利用企業が誤削除した一件のデータを復元できるかは分からないのだ。復元対象、時点、依頼条件、所要時間を質問する必要があるのだ。提供側の作業の存在と、自社の業務要件を満たすことは別の判定なのだ。
2.3.2 利用企業が決める利用条件と設定
利用企業は、アカウント、業務権限、共有、連携、投入データ、承認処理について、許可範囲を決めるのだ。その判断を設定へ反映する際は、製品で実現できる範囲を確かめるのだ。
機能が不足する場合の選択肢は、追加製品だけではないのだ。業務手続で確認する、扱う情報を減らす、操作を限定する、別の利用方法へ変えることもできるのだ。設定できない事項を放置するのではなく、どの方法で管理目的を満たすかを記録するのだ。
2.3.3 提供企業への照会事項と契約上の責任境界
提供企業への照会は、自社の要件と回答を対応付ける形で行うのだ。例えば「安全ですか」ではなく、「管理者の一括出力を、操作主体と対象が分かる記録として取得できますか」と聞くのだ。回答には対象製品、契約プラン、確認日を付すのだ。
監査報告で提供側の管理を確認しても、自社テナントの設定を確認したことにはならないのだ。反対に、管理画面が基準どおりでも、提供側の保管や再委託が要件を満たすとは限らないのだ。両方の証拠が必要な要求は、確認先を分けて管理するのだ。
第3章 SaaSのアクセス経路と攻撃面
前章で整理した業務データと処理には、人やプログラムがアクセスする接点があるのだ。この接点を悪用された場合、攻撃者は正規の機能を通じて影響を及ぼすことがあるのだ。本章では、まず正常なアクセスを説明し、その到達範囲を攻撃面として把握するのだ。
3.1 アクセスの全体像と攻撃面の考え方
個々の認証技術を覚える前に、誰が何へ接続しているかを確認するのだ。アクセス経路は、入口だけでなく、認証、権限、操作対象までを含めて整理するのだ。
3.1.1 データと業務処理へのアクセス経路
アクセス経路は、「操作する人またはプログラム」「接点」「利用する権限」「対象」「操作」の組で表せるのだ。営業担当者が画面から顧客情報を見る経路と、分析アプリがAPIから顧客情報を取得する経路は、同じデータを扱っていても別なのだ。
管理者は、データの所有部署とアクセス経路を対応付けるのだ。経路の一覧に画面操作しか載っていなければ、連携アプリは管理対象から漏れるのだ。入口の棚卸しは、後で権限や停止範囲を判定するための基礎になるのだ。
3.1.2 正規の接点と攻撃面の関係
攻撃面は、攻撃者が接触し、悪用を試み得る接点や機能の範囲なのだ。接点があることだけで、事故が成立するわけではないのだ。公開フォームには業務上の必要性があり、API連携にも正当な目的があるのだ。
利用企業は、接点をなくすべきか、許可する条件を限定すべきかを判断するのだ。ここで整理するのは「どこから、何ができるか」という点なのだ。「どの条件で損失になるか」は、第4章で別に評価するのだ。この区別により、接点の数だけで危険性を決めることを避けられるのだ。
3.1.3 通常利用・社外共有・アプリ連携・管理操作の区分
アクセス形態を、通常利用、社外との情報交換、連携・自動処理、管理操作に分けるのだ。通常利用では業務データを扱うのだ。社外との情報交換では相手や公開範囲が変わるのだ。連携・自動処理では人の操作なしに処理が進むのだ。管理操作では、これらの許可条件そのものが変わるのだ。
この分類は、主体を永久に一つへ割り当てるものではないのだ。同じ管理者でも、通常の資料閲覧と権限変更は別の操作として記録するのだ。分類の目的は、必要な権限と確認方法の違いを明らかにすることなのだ。
3.2 従業員による業務アクセス
従業員の利用には、利用者の識別、本人確認、認証済み状態の継続、操作の許可という異なる仕組みがあるのだ。この順序で区別すると、アカウント停止やMFAがどこへ作用するかを理解できるのだ。
3.2.1 アカウント：利用者の識別
アカウントは、サービス上で利用者を識別するための単位なのだ。通常はユーザーID、表示名、所属、状態などが関連付くのだ。アカウントが存在することと、現在その利用者を業務上認めていることは同じではないのだ。
例えば、異動前の部門で使ったアカウントが残っている場合、技術的には識別できても、利用目的が失われている可能性があるのだ。利用企業は、アカウントと、実在する利用者、所管部門、利用目的を対応付けるのだ。共有アカウントは、操作した個人を別の証跡で識別できるかが課題になるのだ。
3.2.2 認証：本人確認とログインの集約
認証は、アクセスしてきた相手が、そのアカウントの正当な利用者であることを確認する処理なのだ。多要素認証（MFA）は、知識、所持、生体などの異なる種類の要素を組み合わせるのだ。パスワードを二回入力させるだけでは、異なる要素にはならないのだ。
SSOは、ある認証結果を複数サービスの利用へつなげる仕組みなのだ。認証を担うIdPと、業務を行うSaaSを区別するのだ。SSOで認証を集約しても、各SaaSの共有範囲や業務権限を一括して決めたことにはならないのだ。認証後の許可は3.2.4項で扱うのだ。[2][8]
3.2.3 セッション：認証後の利用状態
セッションは、認証後の利用状態を継続させる仕組みなのだ。ブラウザーでは、認証済みの状態に対応する情報がCookieなどに保存されるのだ。APIでは、アクセスを許すトークンが使われる場合があるのだ。いずれも、毎回パスワードを入力せずに処理を続けるための情報なのだ。[9]
そのため、パスワードを変えれば、すべてのアクセスが直ちに終了するとは限らないのだ。利用企業は、アカウント、セッション、アクセストークン、更新用トークンを別の停止対象として扱うのだ。実際の失効条件は、認証基盤とSaaSの組合せで確認するのだ。
3.2.4 認可：閲覧・変更・承認の許可
認可は、認証された利用者やアプリに、どの対象へのどの操作を許すかを決める処理なのだ。例えば、営業担当者へ担当顧客の閲覧を認めても、全顧客の一括出力や権限変更まで認める必要はないのだ。
認可の評価では、画面の役割名だけでなく、実際にできる操作を確認するのだ。Salesforceでは、組織、オブジェクト、項目、レコードなどの層でデータアクセスを制御するのだ。上位の権限や別の付与経路も含めて、最終的にアクセスできる範囲を確かめるのだ。[10]
3.3 社外との情報共有・公開・外部入力
社外への情報提供は、従業員の通常利用と同じ条件では管理できないのだ。相手を識別して招待する場合、リンクを渡す場合、一般公開する場合を分けるのだ。外部から受け取る入力は、情報を出す経路とは逆向きの接点なのだ。
3.3.1 ゲスト招待による共同作業
ゲスト招待では、利用企業が社外の相手をサービスの利用者として登録し、対象の業務へ参加させるのだ。確認対象は、招待された相手、所属企業、利用目的、許可範囲、参加期限なのだ。
架空の共同作業では、設計協力会社の担当者を一つの案件へ招待するのだ。別案件の資料まで閲覧できるなら、業務上の参加範囲と設定が合っていないのだ。招待先メールアドレスの確認と、招待後に実際に見える範囲の確認を分けるのだ。[11]
3.3.2 共有リンクによるデータ提供
共有リンクは、対象データへアクセスするためのURLなのだ。リンクが特定の相手だけに有効な場合もあれば、リンクを知る相手へアクセスを認める場合もあるのだ。Microsoftの共有機能でも、認証を伴う共有と匿名リンクは異なる方式として扱われるのだ。[11]
リンクを送ったメールの宛先だけを見ても、データへアクセスできる相手は確定しないのだ。利用企業は、リンクの方式、対象、期限、許可する操作を確認するのだ。リンクが再転送された場合のアクセス可否も、共有の設計条件になるのだ。
3.3.3 公開ページによる情報の提供
公開ページは、不特定または広い範囲の相手へ情報を示す接点なのだ。公開対象となるデータと、元の業務データを区別するのだ。画面で隠した項目が、別の取得経路でも見えないとは限らないのだ。
架空の営業業務で、公開用の商品案内と社内用の顧客情報が同じ業務環境にある場合、公開機能が参照できる対象を確認するのだ。管理者だけの画面確認ではなく、匿名の利用者と想定した外部利用者の立場から取得範囲を試験するのだ。[12]
3.3.4 公開フォームによる外部入力の受領
公開フォームは、外部の相手が値や添付物を送信する接点なのだ。送信内容は、保存、通知、担当者への割当て、申請処理などへ渡るのだ。受付に成功したことは、内容が業務上正しいことの証明にはならないのだ。
架空の受付業務では、フォームが受け付けた銀行口座の変更を、確認なしに支払先へ反映してはならないのだ。入力した主体、入力条件、後続処理での確認者を分けるのだ。ここで評価するのは業務処理へ情報が入る構造であり、すべてのフォームに実装脆弱性があるという意味ではないのだ。
3.3.5 共有先によるダウンロードと再配布
共有先がダウンロードしたファイルは、元のサービスとは別の場所へ保存されるのだ。元の共有リンクを削除しても、受領済みのコピーまで回収したことにはならないのだ。再配布を防ぐ機能が利用できる場合も、その適用条件と対象形式を確認する必要があるのだ。
利用企業は、閲覧のみを認めるのか、ダウンロードを認めるのか、再配布も認めるのかを業務上区別するのだ。技術で維持できない条件は、共有する情報の限定や、取引先との取扱いの合意によって補うのだ。
3.4 連携アプリと自動処理によるアクセス
プログラムによるアクセスは、人が画面を操作しなくても継続するのだ。接続先、資格情報、付与権限、実行する処理を確認することで、連携と自動化の範囲を特定できるのだ。
3.4.1 API：プログラムが機能を利用する窓口
APIは、プログラムがサービスの機能を呼び出すための窓口なのだ。顧客情報の取得、申請データの登録、設定の変更など、APIごとにできる操作は異なるのだ。
画面で一件ずつ見る情報を、APIではまとめて取得できる場合があるのだ。この違いは利便性であると同時に、権限を悪用された場合の影響範囲にも関わるのだ。管理者は、APIが存在するという事実だけでなく、対象データ、操作、呼出し元を記録するのだ。
3.4.2 連携用アカウント・APIキー・トークン
連携用アカウントは、プログラムの処理を識別するためのアカウントなのだ。APIキーやトークンは、呼出しを許す資格情報として使われるのだ。秘密値を持っていれば操作できる方式では、その値の保管先自体が重要な管理対象になるのだ。[9][13]
従業員が作成した連携でも、その人が退職したときに必ず停止するとは限らないのだ。利用企業は、人のアカウント台帳とは別に、資格情報の用途、責任者、対象、権限、有効期間、失効方法を把握するのだ。台帳へ秘密値そのものを複写する必要はないのだ。
3.4.3 OAuth：連携アプリへのアクセス認可
OAuthは、あるサービスのデータや機能へのアクセスを、別のアプリへ認可するための枠組みなのだ。利用者が正規の画面で同意しても、その委任先が業務上承認されているとは限らないのだ。認証する相手と、権限を与えるアプリは別の確認対象なのだ。[9]
架空の営業連携では、分析アプリへ顧客情報の読取りを許すのだ。必要なのが集計だけなら、更新や削除まで許す理由はないのだ。アプリ名、提供企業、要求する権限、データの保存先、同意者を対応付ければ、何を委ねたかを説明できるのだ。
3.4.4 AI機能によるデータの参照
AIによるデータ参照は、回答の根拠として文書や記録を取得する処理なのだ。どの情報へアクセスできるかは、その機能が使用する認証と権限に依存するのだ。AIという名称だけで、通常のアクセス制御から独立した安全性が生まれるわけではないのだ。
例えばMicrosoftは、業務向けCopilotが個々の利用者に閲覧権限のある組織情報を提示すると説明しているのだ。これは過大に付与された権限を、自動的に業務上必要な範囲へ縮めるという意味ではないのだ。検索や要約が容易になることで、既存の過大共有が発見されやすくなる点も確認するのだ。[14]
3.4.5 AIエージェントによる業務操作の実行
AIエージェントは、回答を作るだけでなく、別の機能を呼び出して処理を実行する場合があるのだ。参照と、更新・送信・削除を区別するのだ。AIが操作を選んでも、実行先では何らかのアカウントやアプリ権限が使われるのだ。
利用企業は、依頼者、実行するAI、呼び出すツール、実行権限、操作対象を対応付けるのだ。複数のエージェントが協調する構成では、最初の依頼者の権限だけを調べても全体は分からないのだ。他のエージェントへ引き継ぐ際の権限と承認も確認するのだ。[15]
3.4.6 開発ワークフローの実行と資格情報の受け渡し
開発ワークフローは、コード変更の検査、ビルド、配布などを自動実行するのだ。GitHub Actionsのような環境では、外部のActionを部品として参照できるのだ。実行環境には、リポジトリへの権限や配布先の資格情報を渡す場合があるのだ。[6]
この構成では、保存されたコードだけでなく、実行時に取得する部品、部品の参照先、資格情報、実行ログが管理対象になるのだ。設定ファイルの文字列が変わっていなくても、参照したタグの指す内容が変わることがあるのだ。設定値と実際の実行内容を結び付ける必要があるのだ。[16]
3.5 管理者・サポートによる管理アクセス
管理操作は、業務データへのアクセスを許す条件そのものを変えるのだ。通常の管理画面に加えて、認証情報の復旧、外部支援、保護対象への遠隔指示も管理接点として整理するのだ。
3.5.1 管理画面と管理APIによる設定変更
管理画面や管理APIでは、利用者の追加、役割の変更、外部共有の許可、連携の承認などを行うのだ。これらは、管理者自身がデータを取得しなくても、他の人やプログラムの到達範囲を広げる操作なのだ。
管理者は、業務の利用権限と、利用条件を変更する権限を分けて把握するのだ。操作を画面だけに制限したつもりでも、同じ変更をAPIから実行できるなら、そのAPIも確認対象になるのだ。変更経路を一つだけ点検しても、構成全体の管理にはならないのだ。
3.5.2 認証情報の再発行と権限の復旧
認証情報の再発行や権限復旧は、通常の認証が使えない利用者を業務へ戻す手続なのだ。正規の利用回復に必要な一方、通常ログインの外側でアクセスを再設定する接点でもあるのだ。
確認する要素は、申請者の本人性、対象アカウント、復旧する認証方法、戻す権限、承認者なのだ。「社内の名前や部署を知っている」ことだけを本人確認に使うと、情報を得た第三者が申請者になりすます余地が残るのだ。Mandiantは、ヘルプデスクへの誘導がSaaS侵害につながる事例を報告しているのだ。[7]
3.5.3 提供企業・委託先による支援操作
提供企業や委託先は、問い合わせの調査や保守のため、利用企業の環境へアクセスする場合があるのだ。アクセスが常時有効か、申請時に一時付与されるかは、製品と契約によって異なるのだ。
利用企業は、支援の目的、接続方法、閲覧できるデータ、変更可能な設定、利用期間、操作記録の所在を確認するのだ。支援担当者の会社名だけでは、実際に許可した作業を特定できないのだ。自社で見えない操作は、提供側の証跡を要求する対象になるのだ。[17]
3.5.4 防御ポリシーの配布と保護対象への遠隔操作
クラウド型WAFの管理環境は、Web通信の許可や拒否に影響するのだ。クラウド型EDRの管理環境は、防御ポリシーの変更や、許可された遠隔操作に影響するのだ。管理サービスへのアクセス権限は、保護対象へ間接的に作用する権限でもあるのだ。[7]
参照専用の監視、設定変更、APIキー作成、遠隔実行を一つの「管理者権限」として扱わないのだ。例えば、検知結果を読む担当者が、全端末へコマンドを実行する必要はないのだ。各製品で実現できる分離を確認し、保護対象の範囲まで記録するのだ。
第4章 情報・業務・サービス依存のリスク
接点が存在することと、損失が発生することの間には、いくつかの条件があるのだ。例えば、共有リンクがあっても、必要な相手だけが閲覧できれば、直ちに漏えいとはならないのだ。本章では、接点、成立条件、出来事、業務影響をつないでリスクを分析するのだ。
4.1 事故の分析方法とリスクの評価対象
事故は、原因、弱点、発生した出来事、損失を混ぜずに記述するのだ。これにより、どの条件を変えると何を防げるかを、後の対策へ対応付けられるのだ。
4.1.1 脅威・弱点・事故・業務影響の区別
脅威は、損失を生じさせ得る行為や事象なのだ。弱点は、その事象による悪影響を許す条件なのだ。事故は、実際に起きた不正取得、誤処理、停止などを指すのだ。業務影響は、その事故が顧客対応、支払い、契約、事業継続へ与える結果なのだ。[3]
例えば、「アカウント」は脅威でも損失でもなく管理対象なのだ。「認証情報を盗まれること」は原因側の出来事なのだ。「営業データを取得されること」は侵害結果なのだ。「顧客への通知や交渉情報の流出」は業務影響なのだ。分類を混ぜると、アカウントを減らすだけで損失がなくなるような誤った結論になるのだ。
4.1.2 起点・成立条件・出来事・損失のつながり
架空の営業業務で、担当者を装う第三者が顧客名簿を取得する場合を考えるのだ。説明の単位は次のとおりなのだ。
| 要素 | この例で確認する内容 |
|---|---|
| 起点 | 攻撃者が担当者の認証情報を入手する |
| 接点 | 顧客管理SaaSのログインとデータ出力 |
| 成立条件 | 攻撃者の接続を拒否できず、取得した権限で広範囲を出力できる |
| 出来事 | 顧客名簿が外部へ取得される |
| 業務影響 | 顧客対応費用、機密情報の流出、取引上の信用への影響 |
認証の強化は入口の条件を変えるのだ。出力権限の限定は取得範囲を変えるのだ。ログ監視は発見までの時間を変えるのだ。対策の効果は、作用する箇所に応じて評価するのだ。
4.1.3 外部攻撃・内部不正・誤操作・提供側障害の区別
外部攻撃では、第三者の到達経路と取得権限を追うのだ。内部不正では、正規の権限を持つ人の目的外利用を調べるのだ。誤操作では、入力や変更を誤った条件と、誤りが業務へ反映される過程を調べるのだ。提供側の障害では、停止した依存先と自社業務の関係を調べるのだ。
すべてを「侵入経路」で説明する必要はないのだ。提供企業のサービス終了には、攻撃者が存在しない場合があるのだ。原因に応じて分析の始点を選び、同じ損失へ至る異なる過程を区別するのだ。
4.2 機密情報の漏えいリスク
機密情報の漏えいは、情報の取得者、取得経路、取得範囲が承認した利用から外れたときに問題になるのだ。外部攻撃だけでなく、正規利用者や支援担当者による持ち出しも含めて整理するのだ。
4.2.1 なりすましによる業務データの取得
なりすましでは、攻撃者が利用者の認証情報や認証済み状態を使ってアクセスするのだ。取得した権限が担当案件だけに限定されている場合と、全社データを出力できる場合では、漏えい範囲が異なるのだ。
評価担当者は、認証の成功だけで正当な操作と判断しないのだ。接続元、認証方法の追加、セッションの生成、出力対象を関連付けるのだ。MFAが有効でも、攻撃者の要求を利用者が承認する誘導や、認証後の情報の悪用は別に評価するのだ。[18]
4.2.2 復旧手続の誤承認による情報窃取
復旧手続の誤承認では、攻撃者が本人を装って認証方法や権限を再設定させるのだ。通常ログインへ強い認証を要求していても、その外側の復旧手続が弱ければ、別の経路でアクセスを取り戻されるのだ。
成立条件は、本人確認の不足、申請したアカウントの取り違え、復旧権限の過大付与などなのだ。対策の対象はログイン画面だけではないのだ。復旧の申請、承認、設定変更、本人への通知までを一つの業務として評価するのだ。[7]
4.2.3 共有・公開範囲の誤りによる情報の露出
共有・公開範囲の誤りは、業務上認めた相手より広い範囲へ情報を見せる条件なのだ。匿名リンク、過大なゲスト権限、公開ページからの不要な項目取得などが該当するのだ。
情報が取得可能な状態にあったことと、攻撃者が取得したことは分けるのだ。前者を確認した場合でも是正は必要だが、漏えい件数や取得者を断定するには別の証跡が要るのだ。管理者が表示できる画面ではなく、想定した外部の立場で実効権限を検証するのだ。[12][19]
4.2.4 連携先の侵害による委任権限の悪用
連携先が侵害されると、その連携へ渡していた資格情報や委任権限が悪用されることがあるのだ。利用企業の通常ログインを突破しなくても、既存の連携がデータ取得経路になるのだ。
評価では、連携先の侵害原因と、自社が許した権限を分けるのだ。自社が連携先の内部侵害を防げなくても、連携の取得範囲、資格情報の有効期間、停止手段は変えられるのだ。連携に必要なデータだけを渡すことは、提供側依存を残したままでも被害範囲を限定する方法になるのだ。[20]
4.2.5 内部者による情報の持ち出し
内部者の持ち出しでは、本人認証が正常に完了し、許可された出力機能が使われる場合があるのだ。設定変更や不正ログインの検知だけでは、目的外の出力を判定できないのだ。
架空の営業担当者が、担当顧客一覧を転職先で使うため個人クラウドへ保存した場合、問題は出力の業務目的と保存先にあるのだ。出力できる量の限定、業務上の承認、持ち出し先の制御、操作記録の確認を組み合わせるのだ。従業員の監視範囲は、社内規程と適用法令に基づいて定めるのだ。
4.2.6 外部支援権限の濫用による情報取得
外部支援権限の濫用では、支援担当者本人、またはその資格情報を奪った攻撃者が、依頼した作業を超えて情報へアクセスするのだ。常時の広い権限や、作業記録を取得できない状態は、影響範囲の確認を難しくするのだ。
提供企業が保守のためにアクセスするという説明だけで、自社の全データへのアクセスを承認したことにはしないのだ。支援の対象、期限、承認記録、閲覧・出力記録を確認するのだ。自社で直接制限できない範囲は、契約と提供側の証跡で評価するのだ。[17]
4.2.7 開発ワークフロー経由の資格情報流出
開発ワークフローでは、外部の部品に渡した資格情報が悪用される可能性があるのだ。部品の参照先がタグなどの変更可能な値なら、利用企業の設定を変えずに、実行する内容が変化し得るのだ。
そのため、構成管理では設定ファイルだけでなく、承認したコードの実体まで特定するのだ。実行ログ、成果物、キャッシュも秘密情報の出力先として確認するのだ。ログから秘密値を削除しても、取得済みの資格情報は失効するまで使われる可能性があるのだ。[16][6]
4.2.8 提供環境に保管された資格情報の流出
提供企業に保管されたAPIキーや秘密鍵が流出する場合、利用企業の設定が基準どおりでも影響を受けるのだ。秘密情報がどこへ預けられ、その値で何を操作できるかが、影響範囲を決めるのだ。
利用企業が変えられるのは、不要な保管を減らすこと、権限を限定すること、露出時に失効・更新できる状態を保つことなのだ。サポート資料へ秘密値を複写することは、正式な鍵保管機能へ預けることとは別の判断として扱うのだ。[21][22]
4.3 業務処理・管理操作の不正や誤りのリスク
業務では、閲覧できる範囲だけでなく、変更や承認が正しいことも必要になるのだ。ここでは、正規機能が不正な結果や誤った結果へつながる条件を分析するのだ。
4.3.1 業務データの改ざんと不正な支払い
支払先の改ざんは、データ変更と支払い実行という二つの出来事から成るのだ。変更権限を奪われても、別の担当者が信頼できる経路で変更を確認すれば、不正送金を止められる場合があるのだ。
架空の経費精算では、銀行口座の変更、申請の承認、振込データの出力を別の操作として扱うのだ。評価担当者は、どの操作を誰が実行できるかと、変更が後続処理へ反映される条件を確認するのだ。通信の暗号化だけでは、正規画面へ入力された不正な口座を見分けられないのだ。[23]
4.3.2 正規権限の濫用と承認業務の不正
職務分離が崩れると、一人の担当者が自分の申請を通過させたり、承認経路を変更して確認者を外したりできるのだ。本人認証が正常でも、業務上の牽制は成立しないのだ。
確認対象は、画面に表示された「申請者」「承認者」の名称だけではないのだ。代理権限、管理者権限、承認経路の変更権限を合成したときに、一人で処理を完了できるかを調べるのだ。製品がその組合せを技術的に制限しない場合は、利用企業が付与と事後照合を管理するのだ。
4.3.3 利用者・連携処理・支援担当者の操作ミス
操作ミスは、入力値、対象環境、実行対象、処理順序の取り違えから生じるのだ。正規の変更申請があっても、実際に選んだ対象が違えば、承認した結果にはならないのだ。
架空の連携で、テスト用と本番用の環境を取り違えて一括更新した場合、権限の存在だけでなく、実行前の対象確認と更新後の照合が問題になるのだ。外部支援を受ける場合も、依頼文と作業結果を突き合わせる必要があるのだ。作業者の善意と、処理の正確さは別に検証するのだ。
4.3.4 不正な外部入力による業務データの汚染
外部入力の不正は、入力を受け取った後に、業務上の確認を経ずに処理を進めることで影響を生むのだ。形式に合う値でも、虚偽の申請、他人の連絡先、存在しない取引を示すことがあるのだ。
評価担当者は、形式検査と内容の妥当性確認を区別するのだ。公開フォームで受けた情報を、そのまま承認済みの取引先や支払先へ変換する構成では、どの段階で本人性や業務根拠を確認するかが必要になるのだ。提供側の実装脆弱性と、利用企業が設計した業務の確認不足は混同しないのだ。
4.3.5 AIの誤実行による更新・送信・削除の損失
AIが誤った内容を回答する場合と、誤った操作を実行する場合では、必要な対策が異なるのだ。後者では、AIに渡した権限、操作対象、処理量、実行前の承認が損失の範囲を決めるのだ。
例えば、問い合わせ文を誤解したAIが顧客の記録を削除できる構成では、文章の誤りがデータ消失へ直結するのだ。外部入力に含まれた指示を、本来の業務指示と誤認する場合もあるのだ。実行前に独立した条件で対象と操作を確認することは、入力内容の検査とは別の制御になるのだ。[15]
4.3.6 セキュリティ管理権限の悪用による防御変更と遠隔操作
セキュリティ管理権限を悪用されると、防御の無効化、除外の追加、保護対象への遠隔操作などが可能になる場合があるのだ。防御製品であることを理由に、その管理権限を例外扱いにしてはならないのだ。
設定値を変えて防御を弱める行為は、構成の差分として検出できるのだ。一方、許可済みの遠隔実行機能で不正な操作を行う場合、設定値は変わらないのだ。前者には構成照合、後者には実行承認と操作記録の確認が必要になるのだ。[7]
4.4 業務停止・データ消失のリスク
業務停止は、攻撃者がデータを盗む場合だけに起きるものではないのだ。誤削除、依存先の停止、サービスの終了によっても、必要な情報と処理を利用できなくなるのだ。
4.4.1 データの削除と回復不能
データ削除の影響は、削除件数だけでは決まらないのだ。回復元があるか、必要な時点へ戻せるか、添付や履歴も再現できるかによって変わるのだ。回復用データが保存されていても、復元手順を実行できなければ業務は再開しないのだ。
営業データの例では、顧客レコードだけを戻しても、商談との関連や閲覧権限が欠ければ復旧は不完全なのだ。評価担当者は、データの回復可能性と、業務再開の可能性を分けて確認するのだ。提供側のバックアップと、顧客が依頼できる復元機能も区別するのだ。[24]
4.4.2 提供基盤・認証基盤・連携先の停止
顧客管理SaaSが正常でも、認証基盤が停止するとログインできない場合があるのだ。経費精算が正常でも、会計連携先が停止すると締め処理が完了しないのだ。依存先の可用性が、自社の業務へ波及する構造なのだ。
複数サービスを利用していることだけで、停止への備えができるとは限らないのだ。同じ認証基盤、同じ通信経路、同じ管理担当へ依存しているなら、障害が共通化するのだ。代替手段は、元の依存先が使えない状態で成立するかを確かめるのだ。
4.4.3 サービス終了・利用条件変更と移行困難
サービス終了や契約条件の変更では、利用企業が代替へ移れるかが問題になるのだ。データを取得できても、履歴、添付、関連付け、承認状態を移行先で利用できなければ、業務上の移行は完了しないのだ。
退出条件は、契約の解約日だけではないのだ。出力できる期間、出力形式、再利用に必要な権利、提供側の削除条件を確認するのだ。利用企業は、契約終了の直前に初めて移行可能性を調べるのではなく、利用判断の段階から制約を把握するのだ。
4.5 データの利用条件から逸脱するリスク
不正アクセスがなくても、データを認められていない目的や条件で使えば問題になるのだ。投入時の条件と、共有・二次利用・終了後の条件を通して確認するのだ。
4.5.1 投入情報と利用目的の不整合
業務責任者が一般資料だけの利用を承認していたSaaSへ、従業員が顧客の個人情報を投入した場合、設定が変わらなくてもリスクは変化するのだ。利用目的とデータの種類が、当初の審査から外れるためなのだ。
管理対象には、保存されている情報の分類と利用用途も含めるのだ。契約した製品名だけを台帳に載せても、この逸脱は分からないのだ。データの追加、用途の拡張、AI参照の追加を再評価の起点にするのだ。
4.5.2 保存・処理・再委託の条件との不整合
保存場所、処理場所、再委託先、利用目的は、それぞれ異なる確認事項なのだ。国内に保存されるという説明だけで、すべての処理が国内に限定されるとは判断できないのだ。AIやサポートなどの付加機能には別の条件が適用される場合があるのだ。[25][14]
個人情報を扱う場合、法務・個人情報保護の担当者は、自社に適用される法令と実際の処理を照合するのだ。国外に関係するという理由だけで一律に禁止したり、契約相手が国内企業という理由だけで確認を省いたりしないのだ。外国第三者提供の該当性などは、取扱いの実態に即して判断するのだ。[4][26]
4.5.3 二次利用・AI利用・利用終了後の取扱い
共有先の再配布、AIによる参照、モデルの学習、利用履歴の保存は同じ処理ではないのだ。「学習には利用しない」という条件だけでは、参照先、処理場所、応答履歴の保持まで確定しないのだ。
利用企業は、目的、入力情報、参照データ、出力、保持期間を別々に確認するのだ。利用終了後も保存義務や契約上の保持がある場合は、削除予定と保持対象を分けるのだ。必要な証跡を消すことと、不要な情報を残すことの双方を避けるのだ。[14][4]
4.6 自社の利用実態に基づくリスク評価
リスクの種類を知るだけでは、対策の必要性を決められないのだ。自社のデータと業務影響、既存対策の実効性を加えて評価するのだ。
4.6.1 影響の大きさと業務の重要度
業務責任者は、漏えいした場合の対象者と情報の機密性、誤処理した場合の金額や訂正可能性、停止した場合の業務期限を評価するのだ。データ件数が少なくても、契約交渉や特権資格情報に関わる情報は高い影響を持ち得るのだ。
評価には、単に「高・中・低」と書くのではなく、その根拠を添えるのだ。例えば、「締め処理までに再開できなければ支払いが遅延する」「一人の権限で全顧客情報を取得できる」と記録するのだ。これにより、対策後に何が変わったかを比較できるのだ。
4.6.2 発生条件と既存対策による抑制
発生可能性は、攻撃や誤操作の成立条件と、その条件を抑える対策から判断するのだ。MFAの設定、権限の限定、共有の制御、ログ取得などを、該当するシナリオに対応付けるのだ。実施したという報告だけでなく、設定値と動作の証跡を用いるのだ。
公開事例の件数を、そのまま自社の年間発生確率へ換算してはならないのだ。観測対象や公表方針が異なるためなのだ。確率を数値化する情報がない場合は、成立する条件、抑制できる条件、判断の不確実性を記録するのだ。[3]
4.6.3 未確認事項・残るリスク・対応優先度
対策不足と証拠不足は、別の状態なのだ。「匿名公開を禁止していない」は対策不足なのだ。「設定を取得できず公開可否が分からない」は証拠不足なのだ。後者を安全と見なすことも、必ず侵害されると断定することもできないのだ。
評価担当者は、未確認の内容、想定する影響、追加確認の方法、確認までの暫定措置を記録するのだ。残余リスクの許容判断は、第10章で実施証跡と組織の基準を照合して行うのだ。確認率や製品スコアを、残る侵害確率の代わりには使わないのだ。
第5章 脅威動向と公表事例
公表事例は、前章の成立条件が実際にどのような形で現れるかを確認する材料なのだ。2026年9月27日までに確認した一次資料を用い、最近の活動と、異なる論点を示す過去の事例を区別するのだ。各事例にはC番号を付け、同じ活動を複数の説明で参照しても重複計上しないのだ。
5.1 国際的なSaaS環境の脅威動向
最近のSaaS侵害では、認証手続や連携権限を悪用し、正規の機能から情報を取得する活動が報告されているのだ。AIの利用拡大は、参照データと実行権限の両方へ新しい確認対象を加えるのだ。[27][18][15]
5.1.1 攻撃目的と標的となる企業情報・業務
Googleが2026年1月30日に公表した分析では、電話などで認証操作を誘導した後、SalesforceやM365のデータを取得する活動が報告されたのだ。報告は、ShinyHuntersの名称を用いる複数の活動群を扱っているのだ。情報を盗み、金銭要求へつなげる目的が中心にあるのだ。一方、MicrosoftのStorm-2372の報告は、組織の情報収集を目的とする活動を扱うのだ。[27][28]
業務上の違いは、何を盗むと攻撃者の目的を達成できるかに現れるのだ。顧客情報、交渉文書、内部メール、資格情報では、価値と影響先が異なるのだ。国際情勢を考慮する場合も、国名や集団名から危険性を決めるのではなく、自社の情報とアクセス経路へ対応付けるのだ。
5.1.2 認証・連携機能・AI利用を狙う攻撃の動向
2026年のMicrosoftによるEvilTokens分析は、正規のデバイスコード認証を悪用する活動を報告したのだ。Check Pointは、TeamsやPlannerを装い、アプリへの権限同意へ誘導する活動を報告したのだ。両者の共通点は、正規の画面を利用していても、認証や認可の要求自体が攻撃者によるものになり得る点なのだ。[18][29]
連携では、Salesloft Driftの侵害が、預けたトークンを通じて別サービスへ波及したのだ。AIでは、外部入力がエージェント間の処理を誘導する研究が示されたのだ。[20][15] したがって、利用企業の管理は、入口の本人確認に加え、権限を渡す相手と、渡した後の利用までを扱う必要があるのだ。
5.2 情報漏えい・情報窃取の公表事例
情報取得の事例を、認証、共有、連携、内部者、支援アクセス、開発ワークフロー、提供側保管へ分けるのだ。取得可能な状態の確認と、実際の窃取を確認した事件は、同じ事実として扱わないのだ。
5.2.1 認証・セッション・復旧手続の悪用事例
C01：2026年のSaaSを狙う電話誘導： Googleの2026年1月30日付報告は、社内IT担当などを装う誘導から、認証情報や認証操作を取得する活動を説明したのだ。SalesforceやM365へのアクセスを確認しているのだ。Slackに関する攻撃者の主張は、同じ強さの確認事実として扱わないのだ。初期の認証基盤だけで調査を終えず、その認証結果で利用できるSaaSを追う必要があるのだ。[27]
C02：EvilTokens： Microsoftの2026年9月22日付分析では、攻撃者が開始したデバイスコード認証を、利用者が正規のMicrosoft画面で承認する流れが説明されているのだ。利用者は偽サイトへパスワードを入れなくても、攻撃者側のアクセスを成立させ得るのだ。対策はURL確認だけでは足りず、認証要求の用途と発行元、許可する認証フロー、取得されたトークンの失効までを含むのだ。[18]
C03：Storm-2372： Microsoftは2025年2月、2024年8月以降に観測したデバイスコードを使う情報収集活動を公表したのだ。2026年にも分析を更新しているのだ。C02とは別に公表された活動だが、正規認証を攻撃者のセッションへ結び付ける成立条件は共通するのだ。認証フローを業務上必要な用途へ限定する論点を示すのだ。[28]
C04：Snowflake顧客環境への侵害： Mandiantの2024年6月の調査は、盗まれた顧客資格情報によるデータ取得を報告したのだ。調査した事案では、MFA未適用や資格情報の長期残存などが影響していたのだ。Snowflake基盤への侵入がすべての原因だったという説明ではないのだ。認証、資格情報の更新、接続条件を、対象アカウント単位で評価する必要があるのだ。[30]
C05：ヘルプデスクの復旧手続の悪用： Mandiantが2024年6月13日に公表したUNC3944の調査では、本人になりすまして認証手段の再設定を求める活動が報告されたのだ。同じ報告に含まれるセキュリティ管理機能の悪用は5.3.2項で扱うのだ。復旧業務を通常ログインと別の統制として設計すべきことが、ここでの論点になるのだ。[7]
C06：SlackのGitHubリポジトリへのアクセス： Slackは2022年12月、従業員のトークンが盗まれ、外部でホストされたGitHubリポジトリが取得されたと公表したのだ。Slackは、顧客データや本番環境への影響はないと説明したのだ。これはSlack顧客のチャット流出ではなく、Slackという企業が利用するGitHubへの侵害なのだ。被害企業名と被害サービスを分けて記録するのだ。[31]
5.2.2 共有・公開設定に関係する事例
C07：Salesforce Experience Cloudのゲストアクセス： Salesforceは2026年3月7日付の注意喚起で、過大なゲスト権限を悪用する活動と対処を示したのだ。同社は、プラットフォーム固有の脆弱性ではなく、顧客側の設定に関する問題として説明しているのだ。利用企業は、公開サイトが参照できるオブジェクト、項目、レコードを確認する必要があるのだ。[12]
C08：Power Apps portalsの情報露出調査： UpGuardは2021年8月、公開設定に関連して個人情報などが外部から取得可能になっていた調査結果を公表したのだ。研究者が露出を確認した事例であり、全データを攻撃者が窃取したと認定するものではないのだ。過去の設定仕様を、現在のPower Pagesなどへそのまま当てはめることも避けるのだ。[19]
両事例に共通する確認点は、設定画面での見え方と、外部からの取得範囲の一致なのだ。匿名利用者のアクセスを試すことで、業務上の公開範囲を実際の権限へ結び付けられるのだ。
5.2.3 連携サービス・委任権限を経由した事例
C09：Teams・Plannerを装ったアプリ同意への誘導： Check Pointは2026年7月29日、同年6月末から7月に観測した活動を報告したのだ。正規のMicrosoft認証・同意機能を使い、攻撃者のアプリへ権限を与えさせる流れなのだ。誘導メールを受け取った組織数は、侵害に成功した組織数とは異なるのだ。業務上承認されたアプリかという判断が、本人認証とは別に必要になるのだ。[29]
C10：Salesloft DriftとSalesforceへの波及： Googleの2025年8月の報告では、Driftに関係するOAuthトークンを使ったSalesforceデータの取得が説明されたのだ。Cloudflareは同じ活動によるサポート情報の流出を公表し、流出データに含まれた104件の自社APIトークンを更新したのだ。同社は、関連する不審利用やCloudflare基盤の侵害は確認していないと説明したのだ。[20][22]
C10は、Drift連携の停止だけでは対応対象が終わらないことを示すのだ。取得されたサポート本文に別サービスの秘密値が含まれていれば、その失効も必要になるのだ。Cloudflareへの影響は同じ活動の分岐として扱い、WAFが回避された別事件として数えないのだ。
5.2.4 内部者による情報持ち出しの事例
C11：社内情報の個人クラウドへの持ち出し： 米国司法省は2026年1月30日、元Google技術者による機密技術情報の窃取について、有罪評決を公表したのだ。公表資料は、在職中の2022年から2023年に、社内資料を個人のGoogle Cloudアカウントへアップロードした行為を説明しているのだ。[32]
これは、Google Workspaceの顧客テナントで設定不備が起きた事件として扱うものではないのだ。内部者が閲覧できる情報を個人クラウドへ持ち出す構造を示す補助事例なのだ。利用企業の対策へ一般化できるのは、出力目的、保存先、操作記録を管理する必要性なのだ。具体的な製品の認可仕様や自社の発生確率は、この事例だけでは導けないのだ。
5.2.5 外部支援アクセスを経由した情報取得の事例
C12：HubSpotの支援機能の悪用： HubSpotの2022年7月更新の説明によると、同年3月、攻撃者は従業員へのソーシャルエンジニアリングで資格情報とMFAを悪用し、内部の顧客支援機能へアクセスしたのだ。攻撃者は、その権限を使って一部顧客の情報を出力したのだ。[17]
従業員本人が悪意を持って持ち出した事案と、従業員の権限を奪った事案は区別するのだ。利用企業にとっての論点は、提供企業の支援権限が自社データへ到達する範囲なのだ。提供側の本人認証を自社が直接運用できなくても、アクセス条件、出力範囲、記録、事故通知の要求は評価できるのだ。
5.2.6 開発ワークフローから資格情報が流出した事例
C13：tj-actions/changed-files： 2025年3月14〜15日、GitHub Actionsで使われる第三者製Actionの参照先が改変され、実行環境の秘密情報をログへ出力するコードが動作したのだ。GitHub Advisory Databaseは、複数のバージョンタグが悪意あるコミットを指す状態になったことを記録しているのだ。公開リポジトリのログは、第三者から閲覧され得る状態になったのだ。[16]
これは、GitHubの提供基盤全体が侵害されたという事例ではないのだ。利用する外部部品の供給経路が問題になったのだ。承認した完全なコミットSHAへの固定は、可変タグの差替えを防ぐ手段になるのだ。ただし、固定したコード自体の安全性、呼び出す別部品、渡す権限まで保証するものではないのだ。[6]
5.2.7 提供環境からAPIキー・秘密鍵が流出した事例
C14：Imperva Cloud WAFの提供環境からの流出： Impervaは2019年、2018年10月に提供環境の資格情報が悪用され、顧客情報を含むスナップショットが取得されたと報告したのだ。対象のデータにはAPIキーやTLS鍵が含まれていたのだ。過去の提供環境の侵害であり、現在のCloud WAFの顧客設定不備が原因だとする資料ではないのだ。[21]
C15：Dropbox Signの提供環境への侵害： Dropbox Signは2024年4月に検知した侵害について、顧客情報に加えてAPIキーなどが影響対象になったと説明したのだ。利用企業側では、サービスのパスワードだけでなく、連携に用いる資格情報への対応が必要になるのだ。[33]
両事例は、正しい設定を維持していても、提供側へ保管を委ねる秘密情報に依存が残ることを示すのだ。ここでの対策は提供側侵害の完全予防ではなく、権限の限定、保管先の把握、失効・更新による影響の制限なのだ。
5.3 不正処理・業務停止・データ取扱いの公表事例
情報漏えい以外では、不正な処理、誤操作、停止、契約条件の不整合が問題になるのだ。利用企業の設定で防げる原因と、提供側の修正や業務継続の備えが必要な原因を分けるのだ。
5.3.1 データ変更・承認不正・誤処理の事例
C16：クラウドメールを悪用した送金詐欺： FBIは2020年4月6日の注意喚起で、クラウドメールへの侵害から請求や送金を誘導する活動を説明したのだ。攻撃者は正規のメール履歴や受信ルールを悪用し、取引の流れに紛れ込むのだ。個々の経費精算製品の脆弱性を示す報告ではないのだ。[23]
この事例は、認証侵害が業務上の支払いへ接続する過程を示すのだ。支払先の変更をメールだけで完了させず、既知の別経路で確認することは、SaaSの設定とは異なる業務統制になるのだ。SAP Concurや楽楽精算の承認不正として事実を置き換えず、両製品へ適用する確認例は第8章で架空シナリオとして示すのだ。
5.3.2 クラウド型セキュリティ製品の管理機能が悪用された事例
C05の別の観測：CrowdStrike Falconの管理機能： Mandiantの2024年6月13日付UNC3944報告では、侵害された顧客環境でFalconのAPIキーが作られ、Real Time Responseを通じてコマンドが実行された観測が示されたのだ。同報告には、RTRがユーザー・管理者に既定で無効との提供企業の説明もあるのだ。すべての顧客や管理者が同じ操作をできるという意味ではないのだ。[7]
確認する論点は、防御製品のクラウド管理権限が、保護対象へ到達する権限でもあることなのだ。設定を変える操作と、許可済み機能を使う操作を分ける必要があるのだ。この観測はC05の一部として扱い、同じ調査報告を独立した侵害件数へ分解しないのだ。
5.3.3 外部入力が後続処理に影響した事例
C17：SalesforceのEmail-to-Caseを含むPhishForce： Guardioは2023年8月、Salesforceのメール機能を悪用したフィッシングを報告したのだ。外部メールが問い合わせ記録へ取り込まれる経路と、送信元アドレスの確認処理が組み合わさり、攻撃者が正規ドメインの信頼性を利用していたのだ。研究者は、2023年7月28日に提供側の修正が展開されたと記載しているのだ。[34]
これは、FormBridgeから虚偽の経費申請が承認された事件ではないのだ。また、利用企業の設定変更だけで提供側の検証問題を解消できたともしないのだ。外部から届いた内容が、後続処理の根拠として使われる点を示す関連事例として扱うのだ。第4章の入力シナリオへは、信頼境界をまたぐ処理を確認するという範囲で適用するのだ。
5.3.4 AIによる業務操作の誤実行事例
C18：ServiceNowのエージェント連携に関する再現実験： AppOmniは2025年11月、Now Assistのエージェント間連携で、チケット内容に含まれた入力が別のエージェントやツールの操作へ波及する実験を公表したのだ。研究で設定した条件では、データ操作や外部送信につながる動作が示されたのだ。これは実被害企業の侵害報告ではなく、特定の構成を用いた研究なのだ。[15]
この実験から確認できるのは、最初の利用者に与えた権限だけで、連携先の実行範囲を説明できない構成があることなのだ。すべてのServiceNow環境で再現するとは一般化しないのだ。利用企業は、自社が使うエージェントのツール、権限、実行承認を確認するのだ。
5.3.5 障害・データ消失・提供停止の事例
C19：Atlassian Cloudの2022年4月障害： Atlassianは、運用スクリプトへ渡した識別子の取り違えにより、顧客サイトが削除され、復旧に時間を要したと説明したのだ。影響が長い顧客では、停止は最大14日間に及んなのだ。攻撃による情報窃取ではないのだ。回復元があることと、必要な時間内に業務を戻せることの違いを示すのだ。[24]
C20：Ciscoの提供基盤での不正削除： 米国司法省は、2018年に元従業員がCiscoのクラウド基盤へアクセスし、仮想環境を削除してWebEx Teamsの利用に影響を与えた事案について、2020年の判決を公表したのだ。これは利用企業のテナント設定の誤りではなく、提供側基盤の事案なのだ。[35]
利用企業の備えは、原因の種類にかかわらず、自社業務が停止に耐えられるかで評価するのだ。代替の連絡、暫定処理、再開後の照合が、元サービスの認証や保存先に依存せず成立する必要があるのだ。
5.3.6 データの利用・保存条件に関係する事例
C21：Zoomの保存時暗号化に関する説明とFTCの和解： FTCは2020年11月、Zoomの通信保護や録画の保管に関する説明が実際の取扱いと異なるとする申立てと和解案を公表したのだ。録画を会議終了後直ちに暗号化するとの説明に対し、一部の録画が暗号化前の状態で保管されていたと主張したのだ。FTCは2021年に和解の最終承認を公表しているのだ。[36][37]
これは当時の説明と取扱いをめぐる行政上の事案であり、現在のZoomのすべての録画が暗号化されていないという意味ではないのだ。利用企業が確認する論点は、「暗号化する」という表現の対象、実施時点、鍵を扱う主体なのだ。提供側の説明と自社の必須要件を、具体的な処理の単位で照合する必要があるのだ。
5.4 公表事例の横断比較と利用企業への示唆
事例の比較では、製品名が同じかよりも、成立条件と利用企業が変更できる範囲が同じかを確認するのだ。似た条件には共通対策を置き、異なる条件には別の対策を割り当てるのだ。
5.4.1 侵害の成立条件と被害範囲の比較
認証の事例では、本人確認そのものの突破、認証済み情報の悪用、復旧手続の誤承認が異なるのだ。連携の事例では、アプリを誤って承認する場合と、承認済みの連携先が侵害される場合が異なるのだ。C13では、外部部品の参照名が同じまま実体が変更されたのだ。
比較の単位を「使われた権限と、その権限が通った経路」にすると、同じMFAや構成確認で防げる範囲が分かるのだ。反対に「有名なSaaSで起きた」という分類だけでは、対策の根拠にならないのだ。付録B.1では、各事例の性質と関連項を対応付けるのだ。
5.4.2 利用企業の予防範囲と被害限定の範囲
利用企業が原因を直接抑えられるものには、過大権限、公開範囲、未承認連携、弱い復旧手続があるのだ。提供企業の内部侵害や障害は、自社の設定だけでは原因を除去できないのだ。後者でも、情報の保管範囲、資格情報の権限、失効、代替業務によって影響を変えられるのだ。
したがって、事例の評価欄には「原因の予防」と「被害の限定」を分けて持つのだ。提供側事故を自社設定の点検だけで完全に防げると説明してはならないのだ。同時に、直接予防できないことを理由に、備えまで不要とすることもできないのだ。
5.4.3 国内製品の公開情報不足と事実認定の限界
国内の業務特化型SaaSでは、公表資料から利用企業の具体的な設定や事故経路まで確認できない場合があるのだ。本稿では、楽楽精算、NotePM、Hubbleなどについて、未確認の事件を製品名付きで作っていないのだ。第8章の想定例は、公表事故とは区別するのだ。
事例が見つからないことは、安全性の証明ではないのだ。製品の機能が公表されていないことも、その機能が存在しない証明ではないのだ。評価担当者は、公開仕様、契約、提供企業への照会、実環境の試験を組み合わせ、確認できた範囲を記録するのだ。
第6章 設定・業務手続・復旧の対策
対策は、リスクの成立条件か、発生後の影響を変えるために実施するのだ。設定に関わる対策では、望ましい状態を定めるだけでなく、実際の状態と変更を構成管理で維持するのだ。ここでは対策の作用と確認方法を扱い、組織としての承認責任は第7章へ分けるのだ。
6.1 リスクと対策の対応付け
同じ事故にも、入口を止める、取得範囲を狭める、早く見つける、業務を戻すという異なる作用点があるのだ。必要な対策は、事故シナリオのどこに不足があるかから選ぶのだ。
6.1.1 成立条件を減らす対策と影響を限定する対策
成立条件を減らす対策は、不正なログインや公開、過大な権限などを制限するのだ。影響を限定する対策は、取得できるデータの範囲、実行できる処理量、回復までの時間を小さくするのだ。
架空の顧客管理では、本人確認の強化と、全顧客の出力権限の削減は異なる対策なのだ。前者が突破されても、後者が有効なら取得範囲を狭められるのだ。対策の評価欄には、「防止する条件」と「残る条件」を対にして記録するのだ。
6.1.2 予防・検知・対応・復旧の組合せ
予防は、事故の発生条件を減らすのだ。検知は、状態の逸脱や不審な操作を発見するのだ。対応は、進行中の被害を抑えるのだ。復旧は、業務に必要な状態を取り戻すのだ。
例えば、匿名共有の禁止は予防であり、共有設定の差分通知は検知なのだ。問題のあるリンクの停止は対応であり、失われた資料と権限の再構成は復旧なのだ。一つの機能で複数の段階を支える場合も、各段階で実行できることと証跡を別に確認するのだ。
6.1.3 設定・業務手続・提供者との取り決め
技術設定は、認証や共有範囲など、サービスで強制できる条件に使うのだ。業務手続は、支払先変更の妥当性や申請内容など、人の判断が必要な条件に使うのだ。提供企業との取り決めは、自社で直接操作できない保管や支援アクセスへ使うのだ。
機能がない場合に、チェックリストへ「確認済み」と記入するだけでは補完にならないのだ。何を誰が確認し、どの条件なら処理を止めるかを定める必要があるのだ。補完によって満たせない要求は、残余リスクとして判断するのだ。
6.2 設定値の設計と構成管理
設定不備を減らす基礎は、承認した状態と実際の状態を区別して保持することなのだ。構成管理には、基準の選定、設定の記録、変更の制御、結果の確認が含まれるのだ。記録を作ったことだけで、正しい設定が維持されたとは判断しないのだ。[38]
6.2.1 リスクと業務要件に基づく設定基準
設定基準は、許可する業務と抑えるべきリスクから定めるのだ。提供企業の推奨値や公開基準は出発点になるが、自社の業務判断の代わりではないのだ。適用範囲と採用理由を付けることで、基準の妥当性を見直せるのだ。
次表は架空の共同作業に対する基準例なのだ。製品の設定名や全企業に共通の必須値ではないのだ。
| 管理目的 | 基準例 | 確認する結果 |
|---|---|---|
| 案件資料の匿名公開を防ぐ | 当該サイトで匿名リンクを許可しない | 未認証の試験利用者が資料を取得できない |
| 招待範囲を担当者に限定する | 外部参加者を承認した案件へ割り当てる | 別案件の資料を閲覧できない |
| 連携の影響を限定する | 対象資料の読取りのみを認める | 更新・削除・別案件取得が拒否される |
| 作業終了後のアクセスを止める | 参加終了の申告で権限と共有を見直す | 招待経路と既存リンクを再確認する |
設定値の一致と、表の右欄の動作は別に検証するのだ。継承や別経路の付与があると、単一の設定値だけでは実効権限を表せないのだ。
6.2.2 基準値・実設定値・例外の記録
構成情報には、対象環境、設定項目、基準値、取得時点付きの実設定値、評価結果、例外、証跡を保持するのだ。実設定を取得できなかった場合は、無効や未設定と置き換えず、未確認として記録するのだ。
次は、特定製品のAPIではなく、社内記録用のJSON例なのだ。日時と値は架空の記入例なのだ。
{
"asset_id": "COLLAB-01",
"scope": "project-site-07",
"control_id": "CFG-SHARE-01",
"setting": "anonymous_link_allowed",
"baseline": {
"value": false,
"version": "3",
"approval_ref": "APPROVAL-024"
},
"observed": {
"value": true,
"at": "2026-09-27T09:00:00+09:00",
"method": "read_only_export",
"evidence_ref": "EVIDENCE-117"
},
"exception": null,
"assessment": "unapproved_deviation",
"change_ref": null,
"remediation_owner_role": "SaaS管理者"
}
APIキーなどの秘密値は、この記録に入れないのだ。資格情報の識別子、用途、保管場所、有効期間、失効手段を参照として持つのだ。構成情報自体も内部構造や権限を示すため、閲覧・変更の権限を管理するのだ。
6.2.3 設定変更の照合と構成情報の更新
設定変更では、承認された差分、反映した結果、反映後に取得した実設定を照合するのだ。承認した設定ファイルを保存しただけでは、実環境への適用を確認したことにならないのだ。反映に失敗した項目や、別の管理者が上書きした項目も記録するのだ。
変更には、利用企業の操作だけでなく、提供側の機能追加、既定値の変更、外部参照先の更新が含まれるのだ。GitHub Actionの可変タグのように、見えている参照名が変わらなくても実体が変わる対象は、参照する内容を別に識別するのだ。[16] 基準を変更すべき場合と、未承認差分を元へ戻す場合を区別するのだ。
6.3 予防：利用者と管理者のアクセス制御
通常利用の本人確認と権限を定めた後、その外側にある復旧と支援の接点を制御するのだ。防御製品の管理権限も、同じ原則で評価するのだ。
6.3.1 本人確認と認証後のアクセス制御
認証基盤の担当者は、許可するログイン経路、認証方法、利用条件を定めるのだ。通常の利用者、管理者、緊急用アカウントを区別し、共通認証を経由しない経路も確認するのだ。認証後の利用については、セッションの期限、再認証、失効の条件を把握するのだ。
認証要求の正当性を利用者が判断しにくい経路は、用途を限定するのだ。デバイスコード認証などを使う正当な業務がある場合は、その機器・用途と例外を明らかにするのだ。誘導への注意喚起だけに依存せず、不要な認証経路を設定で制限できるかを検討するのだ。[18]
6.3.2 業務権限と申請・承認の分離
業務責任者は、閲覧、変更、出力、承認、設定変更を別の役割として定義するのだ。SaaS管理者は、その組合せを実際の権限へ反映するのだ。確認担当者は、上位役割、代理権限、グループ経由の付与を含めて実効権限を試すのだ。
経費精算の例では、申請者が承認経路を変更し、自分の申請を完了できないことを確認するのだ。代理操作がある場合は、本人と代理人の双方を記録するのだ。業務上許された例外は、その理由と確認方法を付した期限付きの例外として扱うのだ。
6.3.3 再発行・権限復旧時の本人確認と承認
ヘルプデスクは、復旧申請に書かれた連絡先だけを使って本人確認を完了させないのだ。組織が事前に登録した連絡経路や、承認済みの別の確認手段と照合するのだ。確認に必要な情報を相手が知っているだけで、本人と断定しないのだ。
担当者は、復旧対象のアカウント、追加する認証方法、戻す権限を明示するのだ。高い権限の復旧には、役割に応じた独立した承認を置くのだ。作業後は、変更記録と結果を保管し、本人へ通知するのだ。緊急対応も、確認を省略する理由ではなく、承認経路を切り替える条件として設計するのだ。
6.3.4 外部支援の作業範囲・期限・操作記録
外部支援では、作業の目的、対象、許可操作、接続期間を依頼ごとに限定するのだ。利用企業側で一時的に権限を与えられる場合は、作業終了時に削除または失効させるのだ。常時アクセスが必要な場合は、その必要性と監視方法を別に承認するのだ。
提供企業しか記録を取得できない操作は、証跡の提出条件を契約や支援手順へ含めるのだ。問い合わせの本文へ秘密値を貼り付ける方法は、正式な保管・伝達方法の代わりにしないのだ。支援によって増えた権限と情報のコピーを、作業終了時に確認するのだ。
6.3.5 防御設定の変更と遠隔操作の権限制限
セキュリティ運用責任者は、検知結果の閲覧、ルール変更、除外追加、APIキー作成、遠隔実行を分けるのだ。管理者は、それぞれの権限が及ぶサイトや端末群を限定するのだ。
遠隔操作では、依頼者、実行者、承認された目的、対象、実行結果を対応付けるのだ。参照専用の監視担当に、全端末への実行権限を自動的に付ける設計は避けるのだ。製品で承認を強制できない場合は、実行権限の付与条件と独立した記録確認で補えるかを評価するのだ。[7]
6.4 予防：共有・外部入力・データ取扱いの制御
情報を出す経路と受け取る経路では、確認する条件が異なるのだ。共有先での利用や秘密値の複写まで含めて、データの取扱いを管理するのだ。
6.4.1 社外共有・公開範囲の制限
業務責任者は、共有目的、相手、対象情報、必要な操作、終了条件を承認するのだ。SaaS管理者は、その範囲をゲスト、リンク、公開機能へ反映するのだ。匿名公開が必要な業務と、相手を特定する共同作業は分けるのだ。
動作確認では、承認した相手が取得できることと、承認していない相手が取得できないことの両方を試すのだ。検索結果、添付、過去版、関連レコードも、公開対象に含まれるかを確認するのだ。公開を停止した場合は、元のリンクや別の取得経路でも停止の効果を確かめるのだ。
6.4.2 外部入力の受付条件と後続処理への反映
フォームの受付では、必須項目、型、許容値、添付物、受付期間を定めるのだ。業務責任者は、受け付けた情報をどの時点で信頼するかも決めるのだ。形式検査に合格しただけで、取引や支払いを承認した状態へ進めないのだ。
架空の口座変更受付では、フォームの保存先を未確認の申請領域とするのだ。担当者が既知の連絡先で変更を確認し、承認者が反映を許可した後にマスタへ渡すのだ。製品でこの段階を分けられない場合は、反映処理を外す、対象情報を限定するなどの利用方法を選ぶのだ。
6.4.3 データ出力と共有先での再配布の条件
データ出力では、出力できる人、対象、出力先、目的を限定するのだ。大量出力が必要な業務は、通常の閲覧と別に権限を与える方法を検討するのだ。共有先での再配布を認める場合は、再配布先と保持条件も合意するのだ。
ダウンロード制限を設けても、画面の内容を記録する方法まで常に排除できるわけではないのだ。技術で防げる範囲を試験し、残る経路は情報の最小化や契約・教育・操作確認と組み合わせるのだ。ファイルがサービス外へ出た後も同じ制御が続くと仮定しないのだ。
6.4.4 投入データと提供サービスの利用条件
業務責任者と契約担当者は、投入可能な情報、利用目的、処理場所、再委託、保存期間、終了後の取扱いを定めるのだ。オプション機能やAI連携を追加するときは、元の契約条件がそのまま適用されるかを確認するのだ。
個人情報や保存義務のある記録は、法務・個人情報保護の担当者と照合するのだ。業務上不要な情報を投入しないことは、保護対象そのものを減らす方法になるのだ。自社の承認権限では免除できない義務と、組織として許容判断できる事項を区別するのだ。[4][26]
6.4.5 秘密情報の保管・提供・失効管理
資格情報の責任者は、秘密値を使う処理、保管先、複写先、権限、有効期間を把握するのだ。サポートへ送るログや画面には、APIキー、Cookie、認証ヘッダー、秘密鍵が含まれていないかを確認するのだ。必要な記録を残しつつ、秘密値はマスクまたは安全な別経路で扱うのだ。
露出が判明した場合、資料を削除するだけでは対応を終えないのだ。該当値を失効・更新し、利用履歴を確認し、関連する処理の再接続を検証するのだ。C10のサポート情報の例が示すように、最初に侵害された連携以外の秘密値も対象になるのだ。[22]
6.5 予防：連携・AI・開発ワークフローの制御
機械アクセスでは、連携先の名称だけでなく、実行する処理と渡す権限を管理するのだ。参照を許すこと、AIに操作を選ばせること、外部コードを実行することは、それぞれ別の判断なのだ。
6.5.1 連携アプリの参照範囲・資格情報・終了条件
連携責任者は、取得・更新するデータと、その業務目的を特定するのだ。SaaS管理者は、必要な権限だけを認可し、資格情報の保管と終了条件を設定するのだ。利用者の同意だけで強い権限を追加できる構成は、承認された連携の範囲と整合するかを確認するのだ。
読取りだけの連携に更新権限を与えないのだ。対象を限定できない連携では、連携先へ渡すデータ自体を分ける方法も検討するのだ。資格情報の更新は安全性を高める一方、停止を引き起こす可能性があるため、失効対象と依存処理を対応付けて実施するのだ。[9]
6.5.2 AIによる業務操作の実行範囲と承認
AIへ実行を許す場合、業務責任者は操作の種類、対象、件数、金額などの影響範囲を定めるのだ。更新・送信・削除のような高影響操作は、実行前に人または独立した制御が確認する条件を設けるのだ。
確認画面には、単なる「実行しますか」ではなく、対象と変更内容を示すのだ。参照文書に含まれた指示が、承認条件を書き換えられない構成が必要なのだ。確認や停止を実現できない操作は、自動実行の許可範囲から外すのだ。入力への注意文だけを、実行権限の制限と同等には扱わないのだ。[15]
6.5.3 外部Actionの参照先と実行権限の制御
開発責任者は、外部Actionの出所と内容を確認し、承認した完全なコミットSHAを参照するのだ。タグの固定と、内容を特定するSHAの固定は同じではないのだ。更新時には、変更内容と追加の依存先を確認するのだ。[6]
実行権限は必要な操作へ限定するのだ。秘密情報は、不要なジョブや信頼できない入力を扱う処理へ渡さないのだ。利用可能な範囲では、配布先が発行する短期間の資格情報を検討するのだ。実行ログや成果物についても、公開範囲と秘密値の露出を確認するのだ。特定コミットへの固定だけで、ワークフロー全体が安全になるわけではないのだ。
6.6 検知：設定の逸脱と不審な操作の発見
予防策が実装されても、設定や利用状態は変わるのだ。設定の逸脱、不審な操作、業務上の不正は、異なる証拠から検知するのだ。
6.6.1 構成情報と実設定の照合による逸脱の検出
確認担当者は、承認された構成情報と、取得した実設定を照合するのだ。評価結果は、基準適合、承認済み例外、未承認差分、取得不能に分けるのだ。設定取得が失敗した結果を、差分なしとして処理してはならないのだ。
差分には、対象の追加・削除、権限の継承、機能の有効化も含めるのだ。通知後は、業務上必要な変更だったのか、承認されていない変更だったのかを確認するのだ。誤って緩んだ設定を元へ戻す処理と、基準自体を変更する処理は、別に記録するのだ。
6.6.2 操作ログと不審な行動の調査
監視担当者は、事故シナリオから必要な記録を選ぶのだ。ログインだけでなく、認証方法の追加、復旧、権限変更、共有、出力、API、AI実行、防御設定変更、遠隔操作を対象にするのだ。
ログの取得、保存、検知、調査は別の工程なのだ。記録が保存されていても、誰も確認しなければ発見につながらないのだ。逆に、検知条件があっても、対象操作のログを契約上取得できなければ成立しないのだ。取得できない操作と保存できない期間は、未確認範囲として残すのだ。
6.6.3 業務記録との照合による不正・誤処理の発見
技術ログは、誰が何を操作したかを示す材料になるのだ。しかし、その操作が業務上必要だったかは、依頼、申請、承認、取引の記録と照合しなければ判断できないのだ。
経費精算では、承認履歴と支払対象を照合するのだ。外部支援では、作業依頼と変更結果を照合するのだ。AIでは、承認した対象と実際に更新した対象を照合するのだ。異常な量や時刻の検知と、業務上の正当性確認を、同じ判定にまとめないのだ。
6.7 対応：被害範囲の確認と封じ込め
異常を見つけた後は、被害を限定しながら影響を確認するのだ。証跡保全と封じ込めは状況に応じて並行し、証跡の収集が終わるまで被害の拡大を放置しないのだ。
6.7.1 影響する利用者・データ・連携の特定
事故対応担当者は、最初に確認したアカウントから、セッション、連携、共有、操作対象へ範囲を広げるのだ。調査対象の時刻、環境ID、利用者ID、アプリID、出力先を関連付けるのだ。初期の入口と、侵害後に追加された経路を分けるのだ。
記録を保全するときは、取得時点、取得者、取得方法、原本の保管先を残すのだ。攻撃者が管理者権限を持つ可能性がある場合は、同じ管理環境だけに証跡を置かないのだ。分からない範囲は、取得できなかったログとともに報告するのだ。
6.7.2 侵害されたアクセスと処理の停止
停止対象は、アカウントだけではないのだ。既存セッション、共有リンク、API資格情報、連携アプリ、実行中の処理、外部支援の接続を確認するのだ。停止した後は、以前の経路でアクセスできないことを試験するのだ。
クラウド型WAFやEDRでは、侵害された管理権限を止めることと、防御処理を止めることを区別するのだ。管理キーの失効で足りる状況で、業務の保護機能まで無効化する必要はないのだ。反対に、悪意ある処理が継続するなら、影響を判断して対象を限定して停止するのだ。
6.7.3 提供企業・社内部門との連絡
事故対応責任者は、対象環境、確認した事実、時刻、実施した停止、必要な支援を提供企業へ伝えるのだ。未確認事項と推測を分けるのだ。複数のサービスへ波及した場合は、各提供企業への依頼を一つの社内窓口で取りまとめるのだ。
連絡には、SaaSが停止していても使える経路を用意するのだ。侵害されたメールだけを連絡手段にすると、攻撃者へ対応状況が伝わる可能性もあるのだ。通知義務や対外説明は、法務・個人情報保護の担当者と適用条件を確認するのだ。[4]
6.8 事業継続：回復準備・復旧・代替・移行
復旧を可能にする準備は、事故前に必要になるのだ。回復元を確保した後、そのデータと手順で業務を戻せるかを試すのだ。サービスが戻らない場合に備えた代替と、他サービスへの退出も別に評価するのだ。
6.8.1 回復用データと復元機能の事前確保
IT運用担当者は、何を、どの時点へ、どの単位で戻す必要があるかを業務責任者と定めるのだ。対象には原本、添付、履歴、関連付け、権限、承認状態を含めるのだ。製品の復元機能と、自社で保存する出力やバックアップを区別するのだ。
回復元は、元データと同じ削除権限だけに依存しない構成を検討するのだ。取得の成否、保存期間、再投入方法も確認するのだ。CSVを出力できることは、すべての設定や履歴を再現できることの証明ではないのだ。
6.8.2 データの回復と復旧結果の確認
復元では、事前に確認した回復元を使い、対象データと必要な設定を戻すのだ。IT運用担当者は技術的な完了を確認し、業務責任者は業務上の正確さを確認するのだ。
経費精算の復元では、申請額、領収書、承認状態、会計出力済みの状態を照合するのだ。データが戻っただけで再出力すると、二重支払いにつながる可能性があるのだ。再開の合格条件には、件数の一致だけでなく、処理状態の整合も含めるのだ。
6.8.3 代替業務とサービス停止への備え
業務責任者は、停止を許容できる時間と、代替へ切り替える条件を定めるのだ。代替処理には、担当者、扱う情報、承認方法、記録先、元のサービスへ戻す方法が必要なのだ。
共同作業では、代替の連絡経路と資料の最新版を確保するのだ。経費精算では、暫定申請と支払いの記録を残すのだ。再開後は、未処理、重複、版の不一致を照合するのだ。代替手段も同じ認証障害で使えなくなる構成では、期待する継続性を得られないのだ。
6.8.4 サービス退出と移行の準備
退出の準備では、移行するデータ、出力形式、移行先での再現、利用終了後の保持・削除を確認するのだ。連携先や共有先に残る情報も対象に含めるのだ。
契約を解約しても、旧APIキー、共有リンク、委託先のアクセスが残っていないかは別に確認するのだ。移行時に必要な証跡を失わないよう、保存義務のある記録を先に確保するのだ。これは製品導入日程を作る作業ではなく、利用を継続できなくなった場合の制約を把握する管理なのだ。
第7章 責任・承認・証跡による統制
対策を継続するには、誰が判断し、誰が実施し、誰が結果を確認するかが必要になるのだ。本章では、前章の対策を、責任、実施時点、証跡、是正の仕組みへ置き換えるのだ。統制の対象は、作業を行った事実だけでなく、管理目的を満たした結果なのだ。
7.1 対策を継続させる責任と確認の仕組み
実施者が善意で設定を確認していても、担当変更や業務変更で運用が止まる可能性があるのだ。組織として継続するため、判断、実施、確認の役割を先に定めるのだ。
7.1.1 業務判断・設定実施・実施確認の分担
業務責任者は、許可する利用目的と残る損失を判断するのだ。設定担当者は、承認された条件を製品へ反映するのだ。確認担当者は、実設定と動作の証跡を照合するのだ。部署の名称が異なっても、この責任の区別を保つのだ。
例えば、外部共有の例外を設定担当者だけで承認すると、業務上の必要性を誰が判断したか不明になるのだ。逆に、業務責任者が設定したつもりでも、実環境を確認しなければ反映を保証できないのだ。一人が兼務する場合は、重要な変更について別の責任者による確認を設けるのだ。
7.1.2 所管部門・共通IT・セキュリティ・内部監査
本稿では、所管部門とIT運用部門が管理を実施し、セキュリティ部門が共通要求の策定と監督を担う構成を例とするのだ。内部監査は、実施と監督が機能しているかを独立して評価するのだ。この区別は、IIAのスリーラインモデルを適用する際の考え方と整合するのだ。[39]
セキュリティ部門が実務を支援する場合でも、業務のリスク所有者を不明にしないのだ。内部監査が日常の設定承認まで担えば、後から独立して評価しにくくなるのだ。役割は組織図の名称ではなく、実際の判断と作業から割り当てるのだ。
7.1.3 要求・実施時点・証跡・是正の対応
統制の記録は、「要求」「対象」「実施条件」「実施者」「確認者」「証跡」「不備時の処理」を一組にするのだ。単に「MFAを有効にする」という要求だけでは、どの利用者を、いつ、何で確認するかが不足するのだ。
| 統制の要素 | 架空の管理者認証の例 |
|---|---|
| 要求・対象 | 管理者の許可された認証方法を維持する |
| 実施条件 | 管理者の追加、認証方式の変更、定期確認 |
| 実施者 | 認証基盤とSaaSの設定担当者 |
| 確認者 | 設定変更者とは別の確認担当者 |
| 証跡 | 対象ID、実設定、取得時点、試験結果 |
| 不備時の処理 | 権限付与の保留、是正、再確認、必要な例外判断 |
この記録を統制IDで管理すると、同じ要求を製品ごとの設定と証跡へ対応付けられるのだ。
7.2 全社の管理対象と重要度
統制を実施する相手が台帳に載っていなければ、その統制は適用されないのだ。対象の把握と、重要度に応じた管理水準を組み合わせるのだ。
7.2.1 製品・契約・テナント・所管部門の台帳
台帳は、製品名の一覧ではなく、実際に管理する利用環境の一覧にするのだ。環境ID、契約、所管部門、業務責任者、データ分類、管理者、認証方式、共有・連携先を対応付けるのだ。
製品の中にサイトやアプリがある場合は、親子関係も記録するのだ。下位対象の作成を利用部門へ委任しているなら、追加時に責任者が分かる仕組みが必要になるのだ。契約を一件把握したことと、その契約内のすべての利用範囲を確認したことは分けるのだ。
7.2.2 未登録サービスと共有・連携関係の把握
IT部門は、契約・支払い、SSOの接続、承認したアプリ、ネットワーク利用などの情報を突き合わせるのだ。それぞれは一部の利用を示す材料であり、単独で完全な台帳になるとは限らないのだ。無料利用や個人契約、SaaS間の連携は、調達情報だけでは見つからない場合があるのだ。
発見したサービスは、所管部門と実際の用途を確認して登録するのだ。社員がアクセスしたという理由だけで、会社の承認済み利用と確定しないのだ。確認できない対象は、証拠の不足として記録し、必要に応じて暫定的にデータ投入や連携を制限するのだ。
7.2.3 業務影響に応じた管理水準
管理水準は、業務影響と変化の性質から決めるのだ。機密情報の公開や全端末への遠隔実行のように、短時間で影響が広がる項目では、年一回の確認だけで足りるかを検討するのだ。変化が少ない項目でも、重要な変更時には確認が必要なのだ。
基準策定部門は、確認頻度だけでなく、変更を認める役割、発見後の応答条件、是正の完了条件を定めるのだ。全項目へ同じ頻度を適用する方法は単純だが、費用と必要性が対応しない可能性があるのだ。頻度の根拠を、該当する残余リスクへ結び付けるのだ。
7.3 設定基準・構成情報・例外の管理
構成管理には、基準を決める責任、情報を更新する責任、変更を承認する責任があるのだ。評価スコアだけでは、この責任の所在と変更の正当性は確認できないのだ。
7.3.1 統制要求と設定基準の承認
共通要求の策定者は、管理目的と最低限満たす条件を定めるのだ。製品別の基準は、その要求を実際の設定へ対応付けて承認するのだ。業務要件と衝突する場合は、業務責任者が利用方法を見直すか、代替の制御を検討するのだ。
基準には版と承認者を付けるのだ。提供企業の推奨値が更新された場合、担当者は自社基準との差を評価するのだ。新しい推奨へ自動的に置き換えることと、古い基準を無期限に使い続けることのどちらも、再審査の代わりにはならないのだ。
7.3.2 構成情報と確認手順の維持責任
所管部門は、構成情報の記録責任者と、設定取得手順の保守責任者を定めるのだ。設定の名称変更、APIの変更、契約プランの変更があれば、取得と判定が引き続き成立するかを確認するのだ。
記録には、どの範囲を、いつ、どの方法で取得したかを残すのだ。先月の証跡を使って今月の状態を確認済みにしてはならないのだ。長期に取得できていない項目は、最新状態が不明な項目として監督側へ伝えるのだ。
7.3.3 設定変更の承認・反映・照合責任
設定変更には、申請者、承認者、反映担当者、照合担当者を割り当てるのだ。申請には目的と影響対象を記載し、承認者は基準との差と業務上の必要性を判断するのだ。反映担当者は作業結果を記録し、照合担当者は実設定を取り直すのだ。
緊急変更も、記録のない変更にはしないのだ。即時の承認が必要な範囲、事後確認の条件、期限を定めるのだ。変更後に構成情報だけを実設定へ合わせる方法では、不正な変更を正規の基準へ取り込む危険があるのだ。
7.3.4 機能不足・未確認・例外の承認
例外承認は、管理目的を無効にする手続ではないのだ。承認権限者は、機能不足、業務上の制約、補完策、残る影響、期限、見直し条件を確認して判断するのだ。
「対応できない」と「確認できない」は別に扱うのだ。前者には代替策の評価が必要であり、後者には追加の証拠が必要なのだ。法令や契約の義務を免除する権限がない場合、社内のリスク承認だけで未充足を解消したことにはしないのだ。許容判断の基準は第10章で整理するのだ。[4]
7.4 通常業務での導入・変更・特権作業・廃止
利用状態の変化は、定期点検の間にも発生するのだ。導入、異動、機能追加、特権作業、廃止を、管理が必要になる起点として定義するのだ。
7.4.1 調達・契約・利用開始の審査
所管部門は、利用する業務、投入情報、共有・連携、提供条件を申告するのだ。業務責任者は、必要な機能と管理要求を確認するのだ。契約担当者は、保管、支援、再委託、事故連絡、終了時の条件を照合するのだ。
開始時の承認には、確認した範囲と未確認事項を記録するのだ。資料にない機能をあるものとして見積もらないのだ。高影響の用途で必要な証跡や停止手段を確保できなければ、利用範囲を狭めるか、開始条件を満たすまでデータ投入を保留するのだ。
7.4.2 入社・異動・退職と権限変更
人事異動の情報を受け取る担当者は、対象者が使うSaaSと、その人が所有する連携・共有を確認するのだ。アカウントの停止だけでなく、役割の変更、ゲストの管理、連携の所有者引継ぎも対象になるのだ。
管理者は、各環境での反映結果を記録するのだ。SSO側で停止したことだけをもって、すべてのローカルアカウントや既存資格情報が失効したと判断しないのだ。業務に必要な連携は新しい責任者へ移し、不要な連携は終了を確認するのだ。
7.4.3 共有・連携・自動処理・防御機能の変更管理
共有先、公開機能、フォーム、API、AI、開発ワークフロー、防御機能の追加は、業務変更として審査するのだ。既存の契約内の機能であっても、データの取得先や実行範囲が変わるなら、当初の承認で足りるかを確認するのだ。
申請者は、新しい接点、権限、データの流れを示すのだ。業務責任者は、第4章のリスクへ対応付けて影響を判断するのだ。設定値の反映と照合は7.3節の構成管理へ渡すのだ。機能追加の審査と、設定変更の記録を同じ資料へ混在させすぎないのだ。
7.4.4 再発行・権限復旧の申請と作業確認
ヘルプデスクの責任者は、本人確認方法、承認経路、復旧可能な権限、通知、記録の保存を定めるのだ。特に、通常利用者、管理者、緊急用アカウントでは、復旧の影響が異なるのだ。
確認担当者は、申請記録と実際の変更を定期的に照合するのだ。確認方法が例外的に省略された案件や、短期間に復旧を繰り返した案件は、理由を確認するのだ。親切に早く対応したことではなく、正当な相手へ必要な権限だけを戻したことを合格条件とするのだ。
7.4.5 外部支援の承認と接続終了の確認
作業責任者は、外部支援の依頼、承認、期間、許可権限、記録提出の条件を定めるのだ。接続を許可する前に、必要な作業と実際に可能な操作の差を確認するのだ。
確認担当者は、作業後に変更内容と結果を照合し、臨時権限と接続が終了したことを確認するのだ。担当者の契約終了や委託先変更も、支援権限の見直し条件に含めるのだ。提供側で終了する権限は、照会結果や記録を完了証跡として残すのだ。
7.4.6 利用終了・契約終了・データ削除
所管部門は、利用を終える前に、保存する記録と削除する情報を分けるのだ。アカウント、共有、連携、資格情報、契約の終了を確認するのだ。データ移行の完了と、旧環境の利用停止は別の完了条件なのだ。
契約終了後に管理画面へ入れなくなる場合は、必要な出力と削除確認を先に行うのだ。提供企業がバックアップを一定期間保持する場合は、その対象と終了条件を記録するのだ。「解約した」という一つの事実だけで、すべての情報が消えたとは扱わないのだ。
7.5 事故対応時の指揮・決裁・連絡
事故時には、平常時の申請手続を待つことで被害が広がる場合があるのだ。即時に判断できる人と、停止できる範囲を事前に決めるのだ。
7.5.1 事故の判定・通報と調査責任
事故対応責任者は、疑いの通報先、事故を判定する役割、調査責任者を定めるのだ。初期段階では、被害の全体像が不明でも、証跡保全と必要な制限を開始できる条件を置くのだ。
所管部門、監視担当者、提供企業の窓口の間で、記録提出の担当と期限を決めるのだ。疑いが否定された場合も、何を確認して終了したかを残すのだ。調査の開始を、被害件数の確定まで待つ仕組みにはしないのだ。
7.5.2 緊急停止の決裁と業務再開の承認
業務責任者と事故対応責任者は、緊急に停止できる対象、担当者、事後報告、再開の承認条件を定めるのだ。単一アカウントの停止と、全社の連携停止では業務影響が異なるため、決裁の範囲も分けるのだ。
再開には、原因への対処、資格情報の更新、構成の復旧、必要な動作確認を条件として付けるのだ。クラウド型WAFやEDRでは、管理経路を止めても保護を維持できるかを確認するのだ。停止できる権限だけでなく、業務を安全に再開させる責任も定めるのだ。
7.5.3 提供企業・社内部門への事故連絡の管理
事故対応責任者は、契約と製品ごとの緊急窓口、社内通知先、連絡条件、決裁者を維持するのだ。契約の販売窓口と、技術調査を行う窓口が異なる場合は、その関係も記録するのだ。
連絡訓練では、窓口へ到達できることと、必要な記録を依頼できることを確認するのだ。通知期限などの必須要件は、法務・個人情報保護の担当者が最新の適用条件を確認するのだ。連絡した時点、受付番号、回答、次の報告時点を残し、送信だけで完了としないのだ。
7.6 回復準備と事業継続訓練の管理
回復可能性を評価するには、回復元の取得と、復元・代替の試験が必要になるのだ。日常の設定確認とは異なる実施条件と合格基準を定めるのだ。
7.6.1 回復元の取得・保存と復元試験の管理
業務責任者は、必要な回復範囲、許容できるデータ損失の時間幅、業務を戻すまでの目標時間を定めるのだ。回復するデータの時点に関する目標をRPO（Recovery Point Objective）というのだ。回復に要する時間の目標をRTO（Recovery Time Objective）というのだ。IT運用責任者は、これらを満たす回復元の取得・保存と復元試験を担当者へ割り当てるのだ。
試験記録には、回復対象、回復元の時点、実施時間、欠落した情報、権限の再現、合否を記載するのだ。失敗した項目には是正責任と再試験の条件を付けるのだ。実際の試験を伴わない「復旧可能」という回答は、検証済みとは区別するのだ。
7.6.2 代替業務への切替判断と訓練
業務責任者は、代替へ切り替える判断者と、切替えの条件を定めるのだ。訓練では、元のSaaSや共通認証を使えない前提で、必要な処理を継続できるかを確かめるのだ。
合格条件には、処理の継続だけでなく、承認と記録の維持を含めるのだ。再開後に元サービスへ結果を取り込むときの重複や漏れも照合するのだ。代替手順が業務担当者の端末だけに保管されている場合は、その端末を使えない状況への備えも確認するのだ。
7.7 実施状況の検証と経営への報告
管理の報告は、実施件数よりも、どのリスクをどこまで確認し、何が残ったかを示す必要があるのだ。証跡、不備の是正、経営への判断依頼をつなげるのだ。
7.7.1 設定証跡・操作記録・動作確認
確認担当者は、設定値、操作記録、試験結果の性質を区別するのだ。設定値は許可条件を示すのだ。操作記録は実際の利用を示すのだ。試験結果は特定の条件で制御が働いたことを示すのだ。
例えば、外部共有を禁止する設定の証跡に加え、匿名利用者が資料を取得できない試験を残すのだ。承認経路については、設定と申請処理の実績を照合するのだ。すべての統制に同じ証拠を要求するのではなく、主張する効果を確認できる証拠を選ぶのだ。
7.7.2 不備の是正と再確認
是正担当者は、不備の内容、影響対象、期限、対応方法を記録するのだ。確認担当者は、是正後の設定や動作を再取得して完了を判定するのだ。担当者が「修正した」と回答しただけでは完了にしないのだ。
同じ不備が繰り返される場合は、設定値の修正だけでなく、基準、承認、取得手順、責任分担を見直すのだ。是正が困難な項目は、期限を延長し続けるのではなく、補完策と残余リスクの判断へ移すのだ。
7.7.3 管理範囲・未確認・重大な不足の報告
監督部門は、管理対象の総数、確認できた範囲、未確認、重大な不備、是正の停滞を分けて報告するのだ。実施率が高くても、高影響の管理権限が未確認なら、その事実を埋もれさせないのだ。
経営へ求める判断は、追加費用の承認だけではないのだ。利用範囲の縮小、業務手順の変更、残余リスクの許容、重大な未充足への対応も含まれるのだ。報告の単位は、ツールの警告件数ではなく、業務影響と選択肢にするのだ。
第8章 製品別の統制適用と確認方法
共通の管理目的は、製品ごとの設定と確認手段へ対応付けて初めて実施できるのだ。ここでは公開資料で確認した仕様と、利用企業が実環境で行う検証を分けるのだ。以下の想定例は、指定がない限り各製品で実際に発生した事故ではないのだ。機能の利用可否は、契約、役割、構成、適用時点によって確認するのだ。
8.1 製品共通の確認票と利用条件
製品ごとに異なる確認表を一から作ると、同じ要求の確認漏れが生じるのだ。まず共通の入力と判定方法をそろえ、製品固有の設定名や証跡を対応付けるのだ。
8.1.1 製品別確認票の入力と適用判定
確認票には、対象環境、業務、データ、リスク、統制要求を入力するのだ。そのうえで、実装機能、基準値、実設定、取得時点、動作確認、契約上の制約を記載するのだ。設定を取得した結果と、要求を満たした判定は別の欄にするのだ。
「対象外」は、実際にその機能を使っておらず、別経路もないことを根拠にするのだ。「製品に機能がない」は対象外ではなく、管理要求に対する不足なのだ。必要な証拠が取れない場合は未確認とし、例外判断へ渡すのだ。共通の記入例を付録B.2に示すのだ。
8.1.2 再発行・権限復旧の手続と証跡
製品担当者は、利用者と管理者の再発行経路を分けて確認するのだ。共通認証の復旧、SaaS固有のローカル認証、提供企業へ依頼する所有権回復など、利用できる経路を列挙するのだ。
確認票には、申請窓口、本人確認、承認者、復旧できる権限、変更履歴、本人通知を記録するのだ。試験用アカウントで申請から作業後の確認までを試し、社内手順と提供企業の手順の境界を確認するのだ。提供側の秘密の認証手順を開示させるのではなく、責任と検証可能な条件を確認するのだ。
8.1.3 外部支援の接続・権限・作業記録
外部支援については、提供企業、販売代理店、導入支援会社、運用委託先を分けるのだ。各主体が使う接点と権限を、実際の利用環境へ対応付けるのだ。
試験では、支援の承認前、作業中、終了後の状態を確認するのだ。操作履歴が自社で取れない場合は、提供側が示せる記録の範囲と提出条件を記載するのだ。自社が付与した臨時権限と、提供基盤の内部支援権限を同じ一覧で混同しないのだ。
8.1.4 投入・再利用・保存・終了時の取扱条件
契約担当者は、本体サービスとオプション・連携ごとに、投入情報、保存、処理、二次利用、終了後の取扱いを照合するのだ。データの所在と、処理する主体は別々に記録するのだ。
NotePMの公式説明は、基本の保管環境に関する説明と、AI機能のクロスリージョン処理を分けているのだ。MicrosoftのCopilot資料も、拡張エージェントの条件を別に確認するよう示しているのだ。[25][14] このような違いを、「同じ製品だから同じ条件」とまとめずに確認票へ反映するのだ。
8.2 顧客管理：Salesforce
顧客管理では、担当者が必要な情報へアクセスできることと、公開・連携が不要な情報へ及ばないことを確認するのだ。Salesforceの評価は、個々の権限層とその組合せから行うのだ。
8.2.1 顧客データと業務権限
Salesforceのデータセキュリティは、オブジェクト、項目、レコードなどの層でアクセスを制御するのだ。利用企業は、業務上の担当範囲を、実際の役割や権限セットなどへ対応付けるのだ。単一のプロファイル名だけで最終的な権限を判断しないのだ。[10]
架空の営業業務では、一般担当者、部門責任者、出力担当者を試験用に用意するのだ。担当外の顧客、機密項目、レポート出力、API取得が、それぞれ承認範囲に収まるかを確認するのだ。確認票には、試験した役割、対象レコード、操作、結果を記録するのだ。
8.2.2 外部向け機能と公開範囲
Experience Cloudなどの外部向け機能では、匿名利用者と認証済みの外部利用者を分けるのだ。公開ページに表示する項目だけでなく、ゲストが参照できるオブジェクト、項目、レコードを確認するのだ。Salesforceの2026年の注意喚起も、この範囲の見直しを求めているのだ。[12]
試験では、公開予定の情報を取得できることと、社内用の顧客連絡先や案件情報を取得できないことを確認するのだ。設定変更時には、元データを追加したことで公開側の参照範囲が変わっていないかを検証するのだ。公開URLを知られていないことは、アクセス制御の証拠にはしないのだ。
8.2.3 連携アプリとデータ操作権限
管理者は、利用中の連携アプリと、それに付与した操作権限を一覧化するのだ。アプリの名称、提供企業、認可した人、対象データ、資格情報、最終利用、終了条件を、承認済みの業務目的へ対応付けるのだ。
承認済みアプリでも、目的より広い取得・更新を認めていれば見直すのだ。Salesloft Driftの事例を踏まえ、連携を停止する際は、その連携経由で取得されたデータに別の資格情報が含まれていないかも確認するのだ。[20] 通常ログインの認証強化と、アプリ認可の審査を同じ対策として扱わないのだ。
8.3 情報共有・共同作業：M365・Teams・SharePoint・Slack
共同作業では、組織の参加者と、資料へアクセスできる相手が必ずしも一致しないのだ。共通認証、サービス別の権限、個々の共有と連携を分けて評価するのだ。
8.3.1 利用者の認証と管理権限
M365とSlackでは、共通認証で管理する範囲と、サービス側の役割・アプリ・共有を管理する範囲を分けるのだ。管理者、通常利用者、外部参加者、連携アプリを同じ認証条件で扱わないのだ。
確認票では、共通認証を経由しないログイン、緊急用アカウント、役割の付与先、認証復旧の経路を記録するのだ。Slackについては、アプリの承認設定も独立した管理対象にするのだ。Slackが提供するアプリ承認機能の利用と、既存の導入済みアプリの権限確認は別の作業なのだ。[40]
8.3.2 共同作業への参加とファイルアクセス
Microsoftの資料では、Teamsの標準チャネルのファイルは親のSharePointサイトと関連し、プライベートチャネルや共有チャネルには別のサイトが作られるのだ。チーム、チャネル、サイトを同じ管理単位とみなさないのだ。[5]
架空の共同作業では、次の組合せを実際の参加者・リンクで検証するのだ。
| 対象 | 確認する組合せ |
|---|---|
| TeamsとSharePoint | チーム参加者、チャネル参加者、サイトへの直接権限、ファイルの個別共有 |
| SharePointの外部共有 | 組織側の許可、サイト側の許可、リンクの方式、実際の受領者 |
| Slackの共同作業 | ワークスペース、対象チャネル、外部組織・ゲスト、共有されたファイルの到達範囲 |
「チャネルへ参加できない」ことだけで、そこから別途共有されたファイルも取得できないとは判断しないのだ。参加範囲とデータの実効権限を、それぞれ確認するのだ。[11]
8.3.3 アプリ連携とデータ出力
アプリ連携では、利用者に代わって参照する権限と、アプリとして与える権限を区別して確認するのだ。管理者は、M365とSlackの導入済みアプリについて、目的、許可した範囲、出力先を記録するのだ。
ファイルやメッセージの出力には、利用者のダウンロード、管理者のエクスポート、アプリの取得という異なる経路があるのだ。監査ログを取得できることは、すべての本文を同じ範囲で出力できることを意味しないのだ。SlackのAudit Logs APIも、操作の監査とメッセージ本文の取得を区別して評価するのだ。[41]
8.3.4 AI機能の参照権限と実行承認
Microsoftの現行資料は、業務向けCopilotについて、利用者の閲覧権限を尊重することと、プロンプト・応答・Graphから取得するデータを基盤モデルの学習に使わないことを説明しているのだ。同資料は、拡張エージェントの利用規約やデータ取扱いを別に確認するよう求めているのだ。[14]
利用企業は、これを自社の全共有が適切であるという保証には置き換えないのだ。過大共有された資料、接続された外部データ、許可した実行ツールを確認するのだ。Slackを含め、AIが参照だけを行う構成と、別アプリへ更新を実行する構成を分けるのだ。後者では、実行承認、記録、停止を追加の確認対象にするのだ。
8.4 経費精算：SAP Concur・楽楽精算
経費精算では、認証だけでなく、申請・代理・承認・出力の組合せを検証するのだ。以下の確認例は、自社の業務規程を製品へ適用するための試験であり、SAP Concurや楽楽精算に不正が発生しているという主張ではないのだ。
8.4.1 申請・代理・承認の権限
SAP Concurの提供企業担当者の説明では、代理で内容を事前確認する権限と、実際に承認する権限は区別されているのだ。楽楽精算も、申請、承認、差戻し、経理処理を支援する機能を提供しているのだ。[42][43] 利用企業は、製品の役割名と自社規程の責任を照合するのだ。
試験では、申請者、代理入力者、承認者、管理者の四つの立場を用意するのだ。一人が兼務した場合に、自己申請を承認できないか、本人の承認として記録されないか、代理の利用が履歴から分かるかを確認するのだ。契約中の機能で制限できない組合せは、権限付与と照合の手続で補えるかを判断するのだ。
8.4.2 承認経路の設定と変更記録
承認経路は、利用企業の業務規程を実装した構成情報なのだ。部署、金額、費目、代理、不在時の扱い、経路変更者を基準と実設定で対応付けるのだ。製品を導入しただけでは、自社の規程に合う経路が完成したことにはならないのだ。
架空の試験条件として、「通常の申請」「承認限度額の直前と直後」「異動した申請者」「不在の承認者」を用意するのだ。各条件で正しい承認者へ進むかを確認するのだ。履歴では、経路変更と個別申請の承認を分け、変更前後の設定と反映時点を残すのだ。
8.4.3 会計連携とデータ出力
SAP ConcurのAPI認証では、アプリや企業に関係するOAuthの資格情報を使う構成があるのだ。人がログインする認証と、会計連携の権限を同じものとして扱わないのだ。[13] 楽楽精算も会計連携や振込データ作成を提供しているため、利用する方式ごとの出力先と処理責任が必要になるのだ。[43]
実務上の照合は、申請ID、出力単位、対象金額、出力時点、会計側の受領結果で行うのだ。再送時には、同じデータを二重に支払わない条件を確認するのだ。承認済みデータでも、出力後にファイルを変更できる担当者がいれば、その経路が別の管理対象になるのだ。
8.5 業務アプリ・外部公開：kintone・FormBridge・kViewer
kintoneと外部連携で一つの業務を構成する場合、元アプリの権限だけでは全体を判断できないのだ。公開側、入力側、接続資格情報を分け、データの経路に沿って確認するのだ。
8.5.1 業務アプリのデータと権限
kintoneでは、人が利用するアプリやレコードのアクセス権と、APIトークンへ設定する権限を別に評価するのだ。公式資料は、APIトークンの権限がアプリ・レコード・フィールドのアクセス権より優先されると説明しているのだ。[44]
そのため、一般利用者の画面で顧客情報が見えないことだけでは、連携アプリからも取得できないと判断できないのだ。確認担当者は、利用者としての閲覧・更新試験と、承認したAPI資格情報での取得・更新試験を分けるのだ。APIトークンに必要以上の操作を許していないかも確認するのだ。
8.5.2 公開範囲と元データの境界
kViewerは、kintoneの情報を外部へ公開するためのサービスとして提供されているのだ。[45] 評価する対象は、元アプリ全体ではなく、実際のビュー、公開項目、対象レコード、認証方式、公開先なのだ。
架空の受付状況公開では、申請の受付番号と処理状況だけを表示し、連絡先や内部メモを公開しない基準を置くのだ。ビューへ項目を追加した場合は、別の利用者の情報が含まれないかを再確認するのだ。URLの推測困難性と、利用者や対象を制限する機能は別の制御として扱うのだ。
8.5.3 外部フォームの受付条件と反映前の確認
FormBridgeの公式ガイドは、フォームごとの受付期間と、設定後の保存・更新を説明しているのだ。[46] 受付期間は、入力を受け付ける条件の一つであり、送信者の正当性や入力内容の妥当性まで保証するものではないのだ。
フォームの確認票には、入力項目、必須条件、添付物、受付期間、kintone側の保存先、通知先、後続処理を記録するのだ。試験では、期限外、欠落値、想定外の値、重複送信、未承認データの反映を確かめるのだ。確認を必要とする入力は、承認前に正式なマスタや支払いへ反映されない構成にするのだ。
8.5.4 連携をまたぐ資格情報と管理責任
一つの業務でも、kintone、FormBridge、kViewerには別の管理環境と資格情報が関わるのだ。構築を委託した場合は、その委託先が保持するアカウントやトークンも確認するのだ。
管理者は、資格情報ごとに利用先、対象アプリ、許可操作、作成者、責任者を記録するのだ。更新時は、どの入力・公開が停止するかを確認して切り替えるのだ。連携を廃止した際は、連携サービスの設定削除だけでなく、元アプリ側の資格情報の失効も確認するのだ。
8.6 プロジェクト管理・文書共有：Backlog・Cacoo・NotePM
プロジェクト管理と文書共有では、業務上の所属と情報へのアクセスを照合するのだ。社外参加、資料の公開、作業終了後のアクセスを、製品ごとの実際の単位で確認するのだ。
8.6.1 プロジェクト・文書の閲覧範囲
BacklogやCacooに関係する共通認証の管理手段として、Nulab PassにはSAML SSO、管理対象アカウント、監査ログなどの機能があるのだ。これは、各プロジェクトや図の業務上の閲覧範囲を自動的に正しくするという意味ではないのだ。[8]
NotePMの公式資料にも、SSO、権限管理、ダウンロード制限などの説明があるのだ。[25] 確認担当者は、在籍、プロジェクト参加、文書・図の閲覧、出力、離任後の状態を製品別に試すのだ。認証基盤で無効化した利用者とは別に、ゲストや個別共有が残っていないかを確認するのだ。
8.6.2 社外参加・資料共有の範囲
社外参加では、誰をどのプロジェクトや資料へ招待したかを記録するのだ。公開ページや共有リンクを併用している場合は、メンバー一覧にいない相手の到達経路も確認するのだ。
架空の開発委託では、委託会社の作業終了時にプロジェクト参加を終了するのだ。併せて、納品用に作ったリンク、図の公開、文書の共有を確認するのだ。NotePMなどのダウンロード制限を採用する場合も、対象形式と利用経路で制限が働くかを検証するのだ。SSOの有無を、共有設定の評価の代わりにはしないのだ。
8.7 契約管理・承認業務：Hubble・コラボフロー
契約文書の閲覧と、契約や申請への意思決定は別の管理対象なのだ。Hubbleとコラボフローを同じ機能の製品とみなさず、それぞれの利用業務へ共通要求を適用するのだ。
8.7.1 契約・申請情報の機密区分
Hubbleは契約文書や版、やり取りの管理を支援するのだ。コラボフローでは、アプリケーションへのアクセス権をグループ単位で設定する機能が説明されているのだ。[47][48] 利用企業は、契約情報や申請情報の機密区分と、実際の閲覧範囲を照合するのだ。
試験では、原本だけでなく、過去版、添付、コメント、検索結果を確認するのだ。本文を隠しても、一覧や通知に相手先や金額が表示されるなら、その情報も評価対象になるのだ。閲覧対象を法務部門だけに限定するかは、業務上必要な役割から決めるのだ。
8.7.2 承認者・管理者の権限分離
契約を承認する責任と、閲覧者や申請経路を変更する権限は分けるのだ。文書管理製品に承認機能を使っていない場合は、存在しない承認経路を前提にしないのだ。意思決定を別システムで行うなら、その記録との対応を確認するのだ。
コラボフローを申請・承認に使う構成では、経路の設定変更者と案件の承認者を照合するのだ。担当者が経路を変更し、自分の申請を通過させることができないかを試すのだ。設定による強制が難しい場合は、変更承認と記録の独立確認を設けるのだ。
8.7.3 処理履歴と設定変更の記録
業務履歴と監査ログは、同じ内容を記録するとは限らないのだ。コラボフローのシステム管理資料は、「監査ログ」でログイン監査情報を確認できると説明しているのだ。その名称だけから、すべての経路変更や文書閲覧を取得できると推定してはならないのだ。[48]
Hubbleでは、版ややり取りの記録と、セキュリティ調査に必要なアクセス記録を分けて確認するのだ。[47] 確認票には、必要な操作、取得できる記録、保存期間、出力方法、不足を記載するのだ。記録がない操作には、別の承認記録や取得方法で補えるかを判断するのだ。
8.8 開発・配布管理：GitHub
GitHubでは、ソースコードの機密性に加え、変更の完全性とワークフローの実行権限を守るのだ。リポジトリの設定だけでなく、外部Action、実行環境、配布先までを利用構成として評価するのだ。
8.8.1 リポジトリ・変更承認・公開範囲
GitHubのrulesetは、ブランチやタグへの操作を制御するのだ。管理者は、対象のブランチ、適用状態、必要なレビュー、ルールを迂回できる人やアプリを確認するのだ。rulesetが存在しても無効なら、要求した保護は働かないのだ。[49]
架空の配布リポジトリでは、公開範囲、変更承認、ワークフロー定義の変更権限を構成情報へ含めるのだ。一般開発者、管理者、配布アプリの立場で、無承認の変更や公開範囲の拡大ができないかを試すのだ。保護ルールの迂回権限は、例外として承認理由を保持するのだ。
8.8.2 外部Action・実行権限・資格情報
ワークフローごとに、使用する外部Actionの完全なSHA、実行条件、渡す秘密情報、トークン権限、配布先を記録するのだ。GitHubの公式ガイドは、第三者Actionを完全なコミットSHAへ固定することと、必要最小限の権限を推奨しているのだ。[6]
確認担当者は、信頼できない変更や入力が、秘密情報を持つ処理へ接続していないかを確認するのだ。タグを固定したつもりでも、その実体を追っていなければC13の論点が残るのだ。短期の認証やOIDCを採用する場合も、対象リポジトリやブランチを限定する信頼条件まで検証するのだ。
8.8.3 監査記録・実行ログ・秘密情報の露出確認
監査では、権限変更とワークフローの実行を分けて記録するのだ。実行ログ、成果物、キャッシュ、リポジトリの内容は、秘密情報の露出を確認する対象になるのだ。ログの公開範囲と保存条件も構成情報へ含めるのだ。
秘密値の露出を検知した場合は、ログの削除だけで完了させないのだ。値を失効し、配布先や連携先の利用履歴を確認するのだ。自動検出の対象外や検出されない形式もあるため、「警告がない」ことを秘密情報が存在しない証拠にはしないのだ。C13の実行履歴と利用資格情報を対応付ける考え方を適用するのだ。[16][6]
8.9 Web防御：クラウド型WAF
クラウド型WAFの管理では、保護を受けるWeb通信と、ルールを変更する管理経路を分けるのだ。CloudflareやImpervaを利用する場合も、WAFの存在ではなく、適用範囲と例外の実態を確認するのだ。
8.9.1 保護対象・ルール・例外設定の構成管理
構成情報には、アカウント、対象サイト、ホスト名、ルール、優先順位、処理、例外条件、変更理由を保持するのだ。CloudflareのSkipは、条件に一致する通信について指定したセキュリティ機能を省略する仕組みなのだ。単に「許可ルール」と記録すると、何の検査を外したか分からなくなるのだ。[50]
次は、架空の帳票送信機能で誤検知を調整する場合の確認例なのだ。
| 確認点 | 記録・試験の内容 |
|---|---|
| 例外の範囲 | 対象ホスト、特定の送信先パス、POST、必要なルールだけを指定 |
| 正常性 | 承認した帳票の送信が成功する |
| 保護の維持 | 別パスや別メソッドまで検査が省略されない |
| 終了条件 | アプリ修正や期限到来時に例外を再評価 |
オリジンサーバーへ直接到達できる経路も確認するのだ。Cloudflare自身もオリジン保護を別の設定対象として案内しているのだ。[51] WAFの設定値が正しくても、業務通信がその経路を通らなければ、期待する効果は得られないのだ。
8.9.2 管理API・秘密鍵・サポート資料の管理
CloudflareのAPIトークンは、権限と対象リソースを指定して作成できるのだ。[52] 利用企業は、設定取得用と変更用の資格情報を分け、対象サイトを限定するのだ。Impervaについても、契約中の管理API、権限単位、鍵の保管条件を実環境と公式資料で確認するのだ。
TLS秘密鍵、管理キー、サポート資料は、それぞれの保存先を把握するのだ。提供側でTLSを処理する構成では、どの鍵がどこに置かれるかを確認するのだ。C14の歴史的な提供側侵害と、C10のサポート本文への複写は異なる原因であり、保管方式の確認と資料への秘密値混入防止を別に実施するのだ。
8.9.3 変更履歴・防御ログ・管理経路の停止
防御ログは、Web通信がどう判定されたかを示すのだ。監査ログは、誰が管理設定を変更したかを示すのだ。Cloudflareには管理操作を確認する監査ログが用意されているが、確認可能なイベントと出力条件は利用する方式で確認するのだ。[53]
試験では、承認したルール変更が記録され、その時点以降の防御動作が意図どおりかを照合するのだ。事故時には、侵害された管理キーやセッションを停止し、基準と異なる変更を確認するのだ。管理権限を止めるためにWAFの保護全体を外すことを、標準の手順にはしないのだ。
8.10 セキュリティ運用：クラウド型EDR・監視サービス
クラウド型EDRや監視サービスは、保護対象の情報を集め、設定や操作を配布する管理サービスでもあるのだ。監視のための権限と、対象を変更する権限を分離して評価するのだ。
8.10.1 管理コンソール・APIの権限分離
管理者は、検知結果の閲覧、端末情報の取得、ポリシー変更、API管理、遠隔実行を別の権限として記録するのだ。CrowdStrikeの公開API資料でも、RTRにおける読取り系の操作と、Active Responderの操作は区別されているのだ。[54]
ただし、「read」という名称だから単なるダッシュボード閲覧だとは限らないのだ。許可されるAPI操作を具体的に確認するのだ。試験用の対象群で、監視担当が設定変更や不要な端末操作を実行できないことを確認し、実行担当にも対象群の限定を適用するのだ。
8.10.2 防御ポリシー・除外・遠隔操作の範囲
防御ポリシー、除外、遠隔操作は、作用が異なるのだ。ポリシー変更は防御水準を変えるのだ。除外は検査対象を減らすのだ。遠隔操作は、その時点の権限で端末やデータへ作用するのだ。
構成情報には、除外する対象、条件、理由、期限を記録するのだ。遠隔操作には、対象端末、承認された処理、実行者、結果を記録するのだ。端末が一時的にオフラインでも、後で実行されるキューを使う構成では、保留中の処理も停止確認の対象になるのだ。[54]
8.10.3 管理操作の記録と独立した確認
管理操作の記録は、ポリシー変更、除外追加、APIキー作成、遠隔セッション、実行結果を対象とするのだ。製品内部のログだけでなく、必要な記録を別の権限で保全できるかを確認するのだ。
同じ管理者が防御設定と監査記録の両方を自由に変更できる場合、独立した証拠が不足するのだ。別の保管先や確認担当を設け、作業依頼と実行記録を照合するのだ。C05の権限悪用を検知するには、設定値の差分と、設定変更を伴わない実行の両方が必要になるのだ。
8.11 事故対応機能の製品横断評価
製品の平常時の制御に加え、事故が起きたときに何を調べ、止め、依頼できるかを比較するのだ。管理機能の存在と、事故対応に利用できる証跡の範囲を区別するのだ。
8.11.1 調査ログの取得範囲と証跡保全
ログは、記録対象、取得権限、保存期間、遅延、出力方法を組にして評価するのだ。Microsoft Purviewの監査にはStandardとPremiumがあり、保存期間や利用機能に違いがあるのだ。Standardの標準保持は180日と説明されているが、すべてのM365の記録が同じ条件で保持されると一般化しないのだ。[55]
SlackのAudit Logs APIなども、契約と対象イベントを確認するのだ。[41] 必要な記録について、対象環境で試験操作を行い、その操作を検索・取得できるかを検証するのだ。「監査機能あり」という製品比較欄だけでは、事故調査の実現性を判断できないのだ。
8.11.2 緊急停止の対象と失効の確認
停止試験では、アカウント、既存セッション、共有リンク、APIトークン、アプリの認可、実行中・保留中の処理を分けるのだ。管理画面で無効と表示されたことと、既存の経路からアクセスできないことを照合するのだ。
試験は、許可された環境と無害なデータで行うのだ。停止できる担当者が不在でも対応できるか、提供企業への依頼が必要かも確認するのだ。制御の反映に時間がかかる場合は、その間の露出を残余リスクへ記録するのだ。
8.11.3 事故連絡の窓口と提供企業への依頼事項
契約担当者と事故対応担当者は、緊急窓口、必要な契約番号、対象環境ID、依頼できる記録、受付条件を確認するのだ。複数製品がつながる業務では、各社に何を依頼するかを分けるのだ。
例えば、kintoneと入力・公開サービスを組み合わせた業務では、受付、保存、公開のどこに問題があるかを共有するのだ。クラウド型WAFでは、ルール変更、鍵の扱い、防御ログのどの調査を求めるかを明示するのだ。保管中の連絡先を、定期的な照会や訓練で確認するのだ。
8.12 回復・代替・退出条件の製品横断評価
回復と退出では、製品のバックアップ有無だけで比較しないのだ。業務を再開するために必要なデータ、状態、権限を、実際に取り戻せるかで評価するのだ。
8.12.1 回復元・回復範囲・取得方法の確認
製品担当者は、提供側の復元機能、利用企業の出力、外部バックアップを分けて記録するのだ。営業では顧客と案件の関連、共同作業ではファイルと共有権限、経費精算では申請と承認状態が必要になるのだ。
GitHubではコードだけでなく、ワークフローや権限などの管理情報も確認するのだ。WAF・EDRでは、基準となる防御設定と対象の関連が必要になるのだ。出力が可能でも、再投入や同じ状態の再現が契約・機能上できるかを別に試すのだ。
8.12.2 復元試験と業務データの照合
復元試験は、事故の種類に合わせた対象で行うのだ。単一の誤削除、広範囲の変更、環境全体の利用不能では、必要な回復元が異なるのだ。
確認票には、使用した回復元、基準時点、実行結果、欠落、所要時間、業務上の合否を記録するのだ。復元後の過大共有や権限欠落も確認するのだ。必要な設定を戻すために強い権限を一時付与した場合は、試験終了時の権限回収までを完了条件にするのだ。
8.12.3 代替業務への切替と処理結果の取り込み
代替業務は、製品名ではなく業務の期限から設計するのだ。営業では顧客対応記録、共同作業では最新版の配布、経費精算では申請・承認・支払いの整合が中心になるのだ。
代替中の記録を元サービスへ戻すときは、処理ID、時刻、担当者、状態を使って重複と欠落を照合するのだ。WAFやEDRの代替では、防御を失う時間と管理可能な範囲を明示するのだ。停止時に初めて別製品を探すことを、検証済みの代替策とは扱わないのだ。
8.12.4 移行用出力と利用終了時の削除確認
移行確認では、原本、添付、履歴、関連付け、権限、承認状態を、移行先でどう保持するかを決めるのだ。すべてを同じ形式へ移せない場合は、参照用保管と稼働用データを分ける方法を検討するのだ。
終了確認には、契約、旧アカウント、共有、連携、秘密情報、提供側の保持・削除を含めるのだ。データの取得期限や削除証跡を事前に確認するのだ。業務類型ごとの確認対象は付録Aにまとめるのだ。
第9章 自己評価・API・SSPMの管理手段
前章では、共通の要求を各サービスの設定と証跡へ具体化したのだ。本章では、その確認作業をどの手段に担わせるかを比較するのだ。比較の起点は、必要な管理項目と確認頻度なのだ。提供企業の自己評価機能、管理画面、API、共通基盤、外部製品を、同じ要求に照らして評価するのだ。
9.1 管理手段の比較基準
管理手段の価値は、機能の数だけでは決まらないのだ。必要な状態を正しく取得し、判断できる証拠を残し、許容できる期間内に不備を是正できることが重要になるのだ。まず、手段の名称から独立した比較条件を定めるのだ。
9.1.1 対象設定・評価基準・取得範囲
評価担当者は、比較対象を「製品名」ではなく「環境IDと確認項目の組合せ」で定めるのだ。同じ製品へ接続できても、サイト単位の共有、アプリの認可、承認経路、管理者の復旧手続をすべて取得できるとは限らないのだ。
比較表には、必要な項目、取得できる値、判定に使う基準、取得できない範囲を記録するのだ。組織全体を対象にした取得と、権限のある一部環境だけの取得を区別するのだ。評価対象の母数が不明な状態で、取得件数から網羅率を算出しないのだ。
9.1.2 確認頻度・証跡・運用負荷
確認頻度は、取得の間隔だけで評価しないのだ。設定を取得した後には、通知、担当者による判断、修正、再確認が続くのだ。頻繁に取得していても、通知を読む担当者がいなければ、危険な状態が長く残るのだ。
運用負荷には、接続設定、権限の維持、基準の改訂、誤検出の調整、提供側の仕様変更への追随を含めるのだ。手動確認と自動確認は、同じ対象範囲と必要な証跡で比較するのだ。作業時間が減った場合の効果は、担当者を他の業務へ振り向けられることでもあるのだ。減少した時間を、給与などの現金支出が同額減る効果として計上しないのだ。
9.1.3 接続権限・収集情報・手段自体のリスク
確認用の権限も保護対象になるのだ。参照専用であっても、利用者一覧、共有先、セキュリティ設定、契約情報を取得できることがあるのだ。連携の承認者は、取得する情報と保管先を把握するのだ。
設定を変更する権限は、取得・評価の権限から分けて審査するのだ。自動修正を認める場合は、修正対象、承認条件、誤修正時の戻し方を定めるのだ。評価用スクリプト、自己開発ツール、外部製品のいずれも、資格情報と依存先を増やす点では同じ評価を受けるのだ。
9.2 提供企業の自己評価機能
提供企業の自己評価機能は、その製品の設定を把握するための有力な材料になるのだ。ただし、評価機能が採用する基準と、自社の業務に必要な基準は同一とは限らないのだ。機能が示した推奨事項を、構成管理の記録へ対応付けて利用するのだ。
9.2.1 M365のMicrosoft Secure Score
Microsoft Secure Scoreは、Microsoft環境のセキュリティ状態を点数と推奨事項で示す機能なのだ。管理者は、対象となる改善アクションと現在の実施状態を確認できるのだ。Microsoftは、この点数が侵害される確率を直接表すものではないと説明しているのだ。[56]
利用企業は、推奨事項ごとに対象環境、採用する基準、実設定、確認証跡を記録するのだ。スコアの画面は全社のリスク台帳の代わりではなく、設定確認に使う入力の一つなのだ。共同作業の資料が本当に必要な相手にだけ届くか、経費の承認が業務規程に従っているかは、それぞれの証跡で判断するのだ。
評価項目や利用機能が変わると、比較の前提も変わるのだ。前月より点数が下がった場合は、実設定の悪化なのか、評価対象や判定条件の変更なのかを分けて調べるのだ。
9.2.2 SalesforceのSecurity Health Check
SalesforceのSecurity Health Checkは、セキュリティ設定をSalesforceの基準またはカスタム基準と比較する機能なのだ。管理者は選択した基準に対する設定の差を確認できるのだ。一括修正の対象になる設定と、個別に変更する設定があるのだ。[57]
利用企業は、採用した基準の版と自社要件への対応を記録するのだ。変更が必要な場合も、通常の構成変更と同じ承認を経るのだ。修正後は、評価結果と実設定の両方を確認するのだ。
顧客情報の閲覧範囲は、オブジェクト、項目、レコードなどの権限を組み合わせて決まるのだ。[10] Health Checkの高い点数だけを根拠に、公開サイトや連携アプリを含む全アクセスが適切だと結論しないのだ。評価対象外の要求には、個別の確認方法を割り当てるのだ。
9.2.3 推奨設定・自社基準・評価対象外の照合
推奨設定は、提供企業が評価に採用した基準なのだ。自社基準は、利用企業が業務要件とリスクから承認した条件なのだ。実設定は、ある時点で環境に反映されている状態なのだ。この三つを別の欄で管理するのだ。
例えば、社外共有を許すこと自体が業務上必要でも、すべての資料を匿名で公開してよいことにはならないのだ。評価担当者は、業務で必要な共有方式と公開範囲を決め、その範囲を確認できる証拠を探すのだ。
異なる製品のスコアは、対象項目と重みが異なるため、同じ尺度の危険度として並べないのだ。統合報告では、自社の統制要求を単位に、適合、承認済み例外、不適合、未確認を示すのだ。点数を合成するより、重大な未確認事項が何かを示す方が意思決定に使えるのだ。
9.3 構成情報の取得・照合方法
自己評価機能がない項目にも、構成管理は適用できるのだ。必要なのは特定の評価画面ではなく、実状態を確認できる情報なのだ。取得手段を選び、その手段が見落とす範囲を記録するのだ。
9.3.1 管理画面・設定出力・提供企業への照会
管理画面による確認では、環境名、対象オブジェクト、実施日時、表示に使った権限を証跡に含めるのだ。一画面のスクリーンショットだけでは、ページ分割や絞り込みによる欠落を説明できないのだ。対象一覧と照合して確認範囲を示すのだ。
設定出力が使える場合は、出力条件と元データを保存するのだ。公開仕様で分からない事項は、提供企業へ具体的に照会するのだ。「安全ですか」ではなく、「対象テナントで支援担当者が閲覧した操作を、利用企業はどの記録で確認できますか」と質問するのだ。
手動確認は、対応APIがないという理由だけで不適切になるわけではないのだ。必要な範囲を確認でき、変更と再確認を許容時間内に処理できれば、管理手段として成立するのだ。確認不能な部分は、合格に置き換えずに残すのだ。
9.3.2 API・スクリプトによる構成情報の管理
APIによる取得では、環境ID、対象ID、取得時刻、APIの版、取得件数、失敗した要求を残すのだ。返ってこなかった項目を「無効」や「設定なし」へ変換しないのだ。ページ分割、権限不足、呼出し制限による部分取得を検出できるようにするのだ。
取得した実設定は、承認済み基準と別に保管するのだ。比較しやすい形式へ変換しても、元の出力を追跡できる関係を保持するのだ。基準をGitなどで版管理する場合も、秘密値を格納せず、変更の承認と閲覧権限を管理するのだ。
Microsoft365DSCは、Microsoft 365の構成の定義・取得・比較などを扱うオープンソースのプロジェクトなのだ。Microsoftのエンジニアとコミュニティによって開発されており、管理画面に標準搭載された評価機能とは区別するのだ。[58] 利用企業は、必要なリソースへの対応、実行権限、版の維持を評価するのだ。抽出した現状を、そのまま望ましい基準として採用しないのだ。
9.3.3 公開基準を用いた自動アセスメント
CISA ScubaGearは、CISAの基準に照らしてMicrosoft 365の設定を評価するツールなのだ。提供企業の自己評価機能とは別の公開ツールとして利用できるのだ。[59]
評価担当者は、ツールの版、基準の版、対象サービス、取得権限を記録するのだ。報告書の不適合は、自社要件と照合して是正対象を決めるのだ。未実施や取得不能の項目は、自動評価の対象外として別の確認へ回すのだ。
構成の取得と差分管理、公開基準への適合確認、業務上の正当性判断は、別の作業なのだ。Microsoft365DSCとScubaGearも、その名称だけで代替関係を決めないのだ。自社の要求を満たすために、それぞれの実際の入出力を比較するのだ。
9.4 共通基盤と外部製品
設定の照合以外には、本人確認、権限の付与・回収、操作の監視、持ち出しの制御が必要になるのだ。共通基盤や外部製品は、これらの作業を補う手段なのだ。導入している製品の種類ではなく、各リスクのどの条件を変えるかで役割を決めるのだ。
9.4.1 共通認証・権限管理
共通認証を利用しても、各SaaSの権限や共有設定まで一括して正しくなるわけではないのだ。認証基盤は誰を認証するかを扱い、SaaS側は認証された利用者にどの操作を許すかを扱うのだ。製品間で連携する範囲を個別に確認するのだ。
人事情報とアカウントの付与・停止を連携する場合は、処理の完了を各サービス側で確認するのだ。ローカルアカウント、緊急管理者、外部利用者、連携アプリが処理から漏れていないかを点検するのだ。共通化の効果は、対象範囲と例外の把握を伴って初めて評価できるのだ。
9.4.2 操作ログ監視と情報持ち出しの制御
操作ログの監視は、設定を変えずに行われる大量出力、不審なAPI利用、承認外の遠隔操作を調べるために使うのだ。監視担当者は、検知したい行為と必要なイベントを対応付けるのだ。ログが集まることと、必要な異常を発見できることは別に試験するのだ。
情報持ち出しの制御では、画面、ダウンロード、API、外部共有などのどこに制御が働くかを確認するのだ。ある経路を制限していても、別経路が同じ制御を通るとは限らないのだ。利用者の行動を監視する場合は、取得情報と利用目的を社内規程や適用される法令に照らして定めるのだ。[4]
設定照合、操作監視、情報の出力制限は、互いを一括して代替するものではないのだ。必要な役割を既存機能で満たせる場合は、その証跡を評価に使うのだ。
9.4.3 SSPMによる設定・権限の横断確認
SSPMは、SaaS Security Posture Managementの略称なのだ。本稿では、SaaSの設定や権限の取得・評価・変更確認を横断的に補助する製品群を指すのだ。個々の製品の対応範囲は同一と仮定しないのだ。
評価担当者は、必要な設定項目、実効権限、確認頻度、証跡を、候補製品が扱える範囲と照合するのだ。比較対象は、自己評価機能や手動確認を含む現在の管理方法なのだ。既に満たしている要求の重複と、新たに確認できる要求の差分を分けるのだ。
設定評価のほかに、権限分析や操作検知を備える製品は、それぞれの機能を別に評価するのだ。導入によって実施責任や残余リスクの判断が製品へ移るわけではないのだ。利用企業が必要な要求を既存手段で満たしている場合、SSPMを追加すること自体を管理上の到達点にしないのだ。
9.4.4 未対応項目の確認方法と残る不確実性
未対応項目には、管理画面、出力、個別API、提供企業への照会などの手段を割り当てるのだ。取得した情報が要求の証拠として使えるかを確認し、取得不能と設定不適合を分けるのだ。
| 必要な確認 | 手段の候補 | 別に残る判断 |
|---|---|---|
| 実設定と基準の差 | 自己評価機能、画面、API、評価ツール、SSPM | 基準自体が業務上妥当か |
| 許可された操作の不審利用 | 操作ログ、監視基盤、業務記録 | 操作が承認された目的に沿うか |
| 申請・承認の職務分離 | 業務規程、権限表、実操作試験 | 兼務や代理の範囲を許容するか |
| 提供側の支援・保存条件 | 契約、提供企業の証跡、照会 | 確認できない依存を許容するか |
| 回復と業務継続 | 回復元、復元試験、代替業務訓練 | 再開時間と回復範囲が足りるか |
確認できない状態が残る場合は、その不確実性が影響評価をどこまで変えるかを整理するのだ。必要に応じて投入情報や操作範囲を制限するのだ。国内製品か海外製品かではなく、この判断に必要な証跡を得られるかで評価するのだ。
第10章 残余リスクの判断
ここまでで、利用構造、事故の成立条件、対策、実施責任、確認手段がそろったのだ。最後に判断するのは、これらを実施した状態で残るリスクを組織が許容できるかという点なのだ。追加対策の選定は、この判断から導くのだ。
10.1 構成管理後に残るリスク
設定値が承認済み基準と一致していることは、設定不備を抑えるための重要な証拠なのだ。ただし、その証拠が示すのは、対象にした項目の取得時点における一致なのだ。基準の妥当性、対象の網羅、変更後の時間差、設定以外の事故経路は別に評価するのだ。
10.1.1 設定基準の不足と管理対象の漏れ
基準が不足している場合は、実設定を基準へ一致させても必要な制限が成立しないのだ。例えば、認証だけを基準化し、匿名公開や連携権限を対象外にしていれば、認証項目の全件適合は情報保護の全件適合ではないのだ。
評価担当者は、リスク台帳の各成立条件から確認対象へ戻り、管理されていない接点を探すのだ。新しいサイト、別契約、追加アプリ、AIの操作権限、外部Actionの参照先も対象にするのだ。設定の継承や組合せでアクセスが成立する場合は、単一項目の値だけでなく、実際に許可される操作を確認するのだ。
不足が見つかったときの第一候補は、基準や管理対象の修正なのだ。現在の不完全な基準を別のツールで高速に照合しても、欠落した要求は評価されないのだ。
10.1.2 設定変更から検出・是正までの空白
未承認変更が発生してから解消するまでの期間は、取得待ち、通知待ち、判断、修正、効果確認に分けて評価するのだ。定期取得の間隔だけを短くしても、修正の承認に長い時間がかかれば、露出は十分に縮まらないのだ。
仮に、継続して残る設定変更を24時間ごとに全件取得し、検出後の修正に最大3時間かかるとするのだ。取得漏れや障害がないという条件では、露出期間は最長27時間になり得るのだ。これは説明用の時間モデルであり、侵害確率や実際の検出保証を表さないのだ。
一時的な権限拡大を取得前に元へ戻した場合は、設定差分だけでは発見できないのだ。変更履歴や操作ログによる確認が必要になるのだ。どの程度の時間差を許容するかは、その間に取得・変更・削除できるデータと業務影響から判断するのだ。
10.1.3 正規権限の悪用と提供サービスへの依存
承認済みの権限を使った不正は、設定値を変えずに成立するのだ。内部者の持ち出しや、侵害された遠隔操作権限の悪用が該当するのだ。外部コードの供給経路と提供基盤も、利用企業の設定管理とは別の依存を残すのだ。第5章のC05、C11、C13、C14は、その違いを説明する材料になるのだ。
利用企業は、これらを一括して「設定不備」と扱わないのだ。操作の承認、監視、資格情報の権限制限、回復準備などが、どの影響を抑えているかを確認するのだ。提供側事故の原因を直接防げない場合も、保管する情報の範囲や失効の準備を見直す余地はあるのだ。
一方、取得済みの情報を後から取り戻せるとは限らないのだ。影響限定策があることを、漏えいの影響が消えることと混同しないのだ。
10.2 リスク許容と追加対策の判断
残余リスクは、必須要件を満たすかという判断と、残る損失を許容するかという判断に分けるのだ。評価担当者は根拠を提示し、承認権限を持つ責任者が対応を決めるのだ。ツールの評価結果だけで、この判断を完了させないのだ。
10.2.1 証跡に基づく発生可能性と影響の評価
評価担当者は、事故シナリオごとに成立条件、現在の対策、その対策を確認した証跡、残る条件、想定影響を整理するのだ。NISTのリスク評価も、脅威や弱点、発生可能性、影響、不確実性を関連付けて扱うのだ。[3]
「MFAあり」「構成管理済み」といった状態名だけでは、対策の強さを比較できないのだ。対象に漏れがないか、いつ確認したか、例外が何か、実際の動作を試したかを根拠に含めるのだ。発生頻度を推定するだけの観測がない場合は、数値を作らず、成立条件と判断の確かさを記録するのだ。
次表は架空の評価例なのだ。残余リスクの許容水準を、特定企業の実績や業界標準として示すものではないのだ。
| 対象 | 確認できた証跡 | 残る条件 | 判断に必要な追加情報 |
|---|---|---|---|
| 社外との資料共有 | 対象サイト全件の設定取得、匿名閲覧の拒否試験、例外の期限 | 承認済み取引先による再配布 | 情報区分、再配布時の損失、取引上の管理 |
| 経費精算 | 申請者と承認者の分離、代理設定、会計出力の照合記録 | 共謀や誤った原始証憑の承認 | 金額範囲、独立確認、事後監査の有効性 |
| クラウド型WAF | ルールと例外の版管理、経路試験、管理APIの権限制限 | 変更から是正までの時間差、提供側の停止 | 公開サービスへの影響、許容停止時間、代替策 |
| 国内の文書SaaS | 閲覧権限の確認、外部共有の拒否試験 | 一部の閲覧記録が取得不能 | 調査可能性の要求、保存情報の機密性、提供側の記録 |
最後の例では、ログがないことを直ちに侵害発生と扱わないのだ。ただし、調査できないという不確実性は残るのだ。高機密情報を扱う判断に不可欠な証拠が得られない場合は、情報の投入範囲を変えるなどの対応を検討するのだ。
10.2.2 組織の許容基準と必須要件の充足
組織は、法令、契約、社内規程などの必須要件を先に特定するのだ。法令上の義務を、社内のリスク受容という手続だけで免れることはできないのだ。個人情報の取扱いでは、利用目的、安全管理、委託先管理などの適用条件を確認するのだ。[4]
その上で、責任者は残る影響と発生可能性を組織の許容基準へ照合するのだ。許容基準は、情報区分、業務の重要度、停止時間、取引上の影響などと対応させるのだ。「スコアが一定以上」だけを許容条件にしないのだ。
受容する場合も、対象範囲、理由、承認者、見直し時点、再評価を開始する条件を記録するのだ。証拠不足を既知の低リスクへ変換しないのだ。判断に必要な情報が欠けている場合は、追加確認と、その間の利用制限を決めるのだ。
10.2.3 継続・追加対策・利用範囲見直しの選択
責任者は、不足の原因に対応する選択肢を比較するのだ。基準が不足していれば基準を修正し、確認の時間差が長ければ取得・通知・是正のどこを短縮するかを検討するのだ。過大な権限が原因なら、権限や処理対象を縮小するのだ。
| 確認した状態 | 対応の方向 |
|---|---|
| 必須要件を満たし、残余リスクが許容内 | 現行管理を継続し、変化に応じて再評価する |
| 基準または管理対象に欠落がある | 設定基準と対象一覧を修正する |
| 必要な証跡を得られるが、確認・是正が遅い | 頻度、通知、決裁、担当体制、必要な自動化を比較する |
| 設定は適合するが、正規操作の悪用が許容外 | 権限制限、操作承認、監視、業務上の照合を追加する |
| 提供側への依存や確認不能が許容外 | 投入情報・利用範囲の縮小、契約上の補完、代替サービスを検討する |
新しい製品を選ぶ場合は、既存手段との差分がどの残余リスクを下げるかを示すのだ。追加製品なしで必要な要求を満たせる場合は、導入しない判断が成立するのだ。反対に、費用が安いという理由だけで、満たすべき要求の不足を放置しないのだ。
10.3 SaaSリスク管理と継続的な再評価
SaaSリスクの管理と統制は、設定を一度点検して終わる活動ではないのだ。業務に必要な利用を定義し、その範囲が実際の設定と操作に反映されていることを確かめ、残る損失を組織として判断する活動なのだ。
10.3.1 リスクに応じた管理と統制の継続
利用企業は、サービスの構成と依存関係から管理対象を定めるのだ。事故の成立条件から対策を選び、設定基準と実設定を構成情報として維持するのだ。担当者は、変更、確認、是正を証跡でつなぐのだ。
構成管理が抑えるのは、設定に起因する事故の条件なのだ。正規権限の悪用、業務上の不正、提供側の事故には、それぞれの対策を組み合わせるのだ。必要な対策の実施と残余リスクの受容を、責任者が根拠付きで判断できることが、管理と統制の成立条件となるのだ。
10.3.2 利用状態・脅威・機能の変化に応じた再評価
再評価の起点には、利用目的、投入情報、共有先、連携先、管理権限の変更を含めるのだ。提供企業の機能追加、既定値の変更、新しい攻撃手法、外部コードの更新も対象になるのだ。自社が設定を操作していないことは、利用条件が変わっていない証拠にはならないのだ。
変更を受けた責任者は、影響する管理対象と基準、既存対策の有効性、残余リスクの判断を見直すのだ。全項目を無条件に再実施するのではなく、変更の影響を追跡して必要な確認を選ぶのだ。これにより、管理手段の導入そのものではなく、業務と脅威の変化に対応した統制を維持するのだ。
付録A 業務類型別の確認事項
次の確認票は、第8章の説明を点検作業に使うための様式なのだ。各行に、対象環境、実施者、実施日時、証跡ID、結果を記録するのだ。試験には、承認された環境と無害なデータを用いるのだ。記載した確認方法を製品がすべて標準提供しているとは仮定せず、実現できない項目は不足として評価するのだ。
A.1 顧客管理：Salesforce
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| 顧客情報へのアクセス | 役割、オブジェクト・項目・レコードの権限、試験用利用者 | 担当外の顧客と非公開項目が、意図した範囲で拒否される |
| 外部公開 | 対象サイト、ゲストから取得できた項目、承認された公開範囲 | 社内向け情報が公開用の経路へ含まれていない |
| 連携と支援 | アプリID、利用目的、付与権限、支援期間、作業記録 | 連携・支援の権限と利用期間が承認内容に一致する |
| 調査・停止 | データ出力と権限変更の記録、失効試験 | 侵害された接点を特定し、他の業務から区別して停止できる |
| 回復・退出 | 顧客レコードと添付・関連データの回復結果 | 関連付けと閲覧権限を含む業務再開条件を満たす |
A.2 情報共有・共同作業：M365・Teams・SharePoint・Slack
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| 認証と参加者 | 認証経路、管理者、ゲスト、チーム・サイト・ワークスペースの参加者 | 共通認証の対象外と、参加終了後の権限が把握されている |
| 共有範囲 | 保存場所、共有リンク、アクセス試験 | 会話への参加範囲と、ファイルの実際の共有範囲を説明できる |
| アプリとAI | アプリID、参照先、実行操作、承認条件 | 参照権限と実行権限が、別々に承認されている |
| 調査・停止 | 共有・出力・権限変更の記録、停止対象一覧 | アカウント停止だけで残るリンクや連携が明らかになっている |
| 回復・退出 | ファイル、メッセージ、履歴、共有設定の出力・復元結果 | 必要な内容と共有範囲を再現し、終了対象を確認できる |
A.3 経費精算：SAP Concur・楽楽精算
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| 申請・代理・承認 | 役割表、代理範囲、異動後の状態、試験申請 | 申請の補助と承認権限を混同していない |
| 経路と設定変更 | 承認経路の基準、変更申請、実設定、変更記録 | 経路変更だけで職務分離を回避できない |
| 会計連携 | 申請ID、出力ID、金額、対象期間、会計側の処理結果 | 未出力、重複出力、二重支払いを区別できる |
| 調査・停止 | 操作記録、承認状態、連携停止の試験結果 | 支払いへの影響を判断したうえで問題の処理を止められる |
| 回復・退出 | 証憑、申請、承認状態、会計照合の結果 | 復元によって過去の支払いが再実行されない |
A.4 業務アプリ・外部公開：kintone・FormBridge・kViewer
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| 元データ | アプリID、画面利用者の権限、APIトークンの権限 | 画面とAPIの取得範囲を別々に確認している |
| 公開 | 公開用ビュー、選択項目、元データとの対応、外部アクセス試験 | 公開するために必要な情報だけが取得される |
| 外部入力 | フォームID、受付条件、添付、保存先、反映前の確認 | 不適切な入力が、そのまま確定した業務データにならない |
| 責任と停止 | 各サービスの責任者、連携資格情報、受付・公開・更新の停止試験 | 一つのサービスを止めた後に残る経路が分かる |
| 回復・退出 | アプリ・入力定義・公開条件・データの回復結果 | 入力から公開までの構成を、承認済みの状態へ戻せる |
A.5 プロジェクト管理・文書共有：Backlog・Cacoo・NotePM
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| 閲覧範囲 | 課題・図・文書の所属、参加者、権限表 | 別案件の情報へ不要にアクセスできない |
| 社外共有 | 社外参加者、資料共有の方法、公開リンク、期限 | 作業終了後の相手が情報を取得し続けない |
| 管理・監査 | 管理者、設定変更と出力の記録、取得不能な操作 | 必要な調査の範囲と、証跡の不足を識別できる |
| 回復 | 課題、コメント、図、文書、添付、版の照合結果 | 内容だけでなく、業務に必要な関連と版を戻せる |
| 終了 | 出力物、外部参加者・連携の停止、保持・削除条件 | 退出後も残す記録と、終了させるアクセスを分けている |
A.6 契約管理・承認業務：Hubble・コラボフロー
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| 機密情報 | 契約書・申請書の情報区分、閲覧者、出力先 | 承認を担当することと、全契約の閲覧を許すことを分けている |
| 意思決定と管理 | 承認者、代理者、経路変更者、管理者の権限 | 設定変更だけで必要な承認を外せない |
| 記録 | 原本、版、申請・承認結果、取得可能な操作履歴 | 業務上の決定とシステム操作を照合できる |
| 事故対応 | 対象文書・申請の特定、アクセス停止、提供側の窓口 | 問題の処理と、継続すべき意思決定を区別できる |
| 回復・退出 | 原本と版、添付、承認状態、移行後の参照方法 | 過去の決定の証拠を損なわずに保持できる |
A.7 開発・配布管理：GitHub
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| コード変更 | リポジトリ、公開範囲、ルール、適用状態、例外権限 | 重要な変更が、承認した経路を通る |
| ワークフロー | 実行条件、外部Actionの完全な参照先、実行環境 | 未審査の参照先や入力が特権処理へ直結しない |
| 秘密情報 | 用途、受渡し先、有効期間、出力ログ、失効責任者 | 実行処理に不要な資格情報が渡されない |
| 調査・停止 | 変更履歴、実行ログ、対象コミット、アプリ・トークンの失効 | 露出した秘密値の削除と失効を別々に完了できる |
| 回復・退出 | コード、課題、成果物、権限、ワークフローの回復結果 | リポジトリのコピーだけを全環境の回復と扱わない |
A.8 Web防御：Cloudflare・Imperva Cloud WAF
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| 防御構成 | サイト、動作モード、ルール、除外、検査経路 | 対象通信が意図した防御を通る |
| 例外 | 条件、対象ルール、承認理由、期限、許可・拒否の試験 | 特定業務の例外が、広範な検査省略にならない |
| 秘密情報 | 管理APIの権限、鍵の保管、支援資料の受渡し履歴 | サポート資料へ不要な秘密値を複製していない |
| 記録と停止 | 管理操作と防御ログ、資格情報の失効、復元したルール | 管理経路の停止と、Web防御の停止を区別する |
| 回復・代替 | 設定の回復元、通信試験、切替条件、鍵の再発行 | 防御なしの公開を、承認なしの代替にしていない |
A.9 セキュリティ運用：クラウド型EDR・クラウド型監視サービス
| 確認領域 | 記録する対象・証跡 | 合否判断で確認すること |
|---|---|---|
| 管理権限 | 閲覧、APIキー作成、設定変更、遠隔操作の付与状況 | 役割名ではなく実行可能な操作を確認している |
| 防御と実行 | ポリシー、除外、対象グループ、実行承認、保留中の処理 | 許可済みの機能を承認外の対象へ実行できない |
| 支援 | 提供企業・委託先の担当、作業期間、操作対象 | 作業終了後の臨時権限と接続を回収できる |
| 記録と停止 | API・設定変更・遠隔操作の記録、独立した保存先 | 侵害された管理権限だけに証跡保全を依存しない |
| 回復・代替 | ポリシー復元、保護対象への適用、監視再開の試験 | 管理環境の回復と、実際の保護の再開を照合できる |
付録B 管理・統制の実務資料
実務で利用する記録は、業務、リスク、設定、証跡、判断を識別子で結び付けるのだ。以下は記入様式と架空例なのだ。社内の実データや製品の既定値を示すものではないのだ。
B.1 公表事例の比較表
C番号は説明単位の識別子なのだ。キャンペーン、研究報告、単一事件を混在させて侵害件数や発生率を計算しないのだ。「公表」は参照した資料の日付であり、最新の法的・技術的状態を無期限に保証しないのだ。
| ID | 対象 | 種別 | 発生・観測時期 | 参照資料の公表・更新 | 主な論点／本文 | 出典 |
|---|---|---|---|---|---|---|
| C01 | 複数SaaSへの電話誘導 | 活動分析 | 2026年1月の活動を含む | 2026年1月30日 | 認証から複数サービスへの波及／5.2.1 | [27] |
| C02 | EvilTokens | 活動分析 | 2026年 | 2026年9月22日 | 正規デバイスコード認証の悪用／5.2.1 | [18] |
| C03 | Storm-2372 | 活動分析 | 2024年8月以降 | 2025年2月13日、2026年更新 | 認証フローの用途制限／5.2.1 | [28] |
| C04 | Snowflake顧客環境 | 調査報告 | 2024年 | 2024年6月10日 | 盗難資格情報と顧客側対策／5.2.1 | [30] |
| C05 | UNC3944、Falcon管理機能 | 複数事象の調査 | 公表前の観測期間 | 2024年6月13日 | 復旧手続と管理機能の悪用／5.2.1・5.3.2 | [7] |
| C06 | SlackのGitHub | 企業の事故報告 | 2022年12月 | 2022年12月31日、2023年1月9日更新 | 被害企業と被害サービスの区別／5.2.1 | [31] |
| C07 | Salesforceゲスト権限 | 提供企業の注意喚起 | 資料記載の活動 | 2026年3月7日、3月11日更新 | 公開機能の実効権限／5.2.2 | [12] |
| C08 | Power Apps portals | 情報露出の調査 | 2021年 | 2021年8月23日 | 露出確認と窃取確認の区別／5.2.2 | [19] |
| C09 | Teams・Plannerを装うアプリ | 活動分析 | 2026年6月末〜7月 | 2026年7月29日 | 本人認証とアプリ承認／5.2.3 | [29] |
| C10 | Salesloft Driftと顧客環境 | 活動・被害報告 | 2025年8月 | 2025年8月、Cloudflare報告は9月2日 | 委任権限とサポート情報の波及／5.2.3 | [20][22] |
| C11 | Google元技術者の情報窃取 | 司法省の評決公表 | 2022〜2023年の持ち出し | 2026年1月30日 | 個人クラウドへの持ち出し／5.2.4 | [32] |
| C12 | HubSpot支援機能 | 提供企業の事故報告 | 2022年3月 | 2022年7月11日更新 | 支援権限の侵害／5.2.5 | [17] |
| C13 | tj-actions/changed-files | セキュリティ勧告 | 2025年3月14〜15日 | 2025年3月15日 | 外部Actionの可変参照先／5.2.6 | [16] |
| C14 | Imperva提供環境 | 提供企業の事故報告 | 2018年10月 | 2019年公表、10月10日詳細更新 | 預けたAPIキー・TLS鍵／5.2.7 | [21] |
| C15 | Dropbox Sign | 提供企業の事故報告 | 2024年4月検知 | 2024年5月 | 提供側の侵害と連携資格情報／5.2.7 | [33] |
| C16 | クラウドメールによるBEC | FBIの注意喚起 | 複数の観測事象 | 2020年4月6日 | 通信の信頼と支払い承認／5.3.1 | [23] |
| C17 | PhishForce | 観測・研究報告 | 2023年、7月に修正 | 2023年8月2日 | 外部入力と後続の確認処理／5.3.3 | [34] |
| C18 | ServiceNowのAI連携 | 再現実験 | 公表資料の試験環境 | 2025年11月19日 | エージェント間の実行権限／5.3.4 | [15] |
| C19 | Atlassian Cloud | 障害報告 | 2022年4月 | 2022年4月29日 | 回復可能性と回復時間／5.3.5 | [24] |
| C20 | Ciscoのクラウド基盤 | 司法省の判決公表 | 2018年 | 2020年12月9日 | 提供側の不正削除と業務停止／5.3.5 | [35] |
| C21 | Zoomの保護に関する説明 | FTCの申立て・和解 | 当時の提供方法 | 2020年11月、最終承認公表は2021年2月 | 説明と実際の処理の照合／5.3.6 | [36][37] |
B.2 製品別の統制確認票
確認票では、共通要求と製品固有の設定を対応付けるのだ。判定の単位は一つの要求とし、複数の設定を組み合わせて確認する場合は、その組合せを証跡に残すのだ。
| 欄 | 記入内容 |
|---|---|
| 対象 | 製品、契約、環境ID、対象オブジェクト、業務責任者 |
| 要求 | リスクID、管理目的、必須要件、許可する条件 |
| 基準 | 設定項目、承認済み基準値、基準の版、承認者 |
| 実状態 | 取得した値、取得日時、取得方法、取得範囲、失敗した範囲 |
| 効果 | 試験した操作、期待結果、実際の結果、証跡ID |
| 判定 | 適合、不適合、承認済み例外、未確認、理由付きの対象外 |
| 是正 | 担当者、期限、変更ID、再確認結果 |
| 例外 | 例外ID、業務理由、補完策、承認者、期限、見直し条件 |
以下の値は架空の記入例なのだ。「承認済み例外」は通常基準と同じ状態を意味せず、条件付きの別判定として残すのだ。
| 対象と要求 | 基準 | 実状態・証跡 | 判定と処理 |
|---|---|---|---|
| 設計資料サイトの匿名公開 | 匿名閲覧を禁止 | 実設定は許可のだ。匿名の試験アカウントで資料取得のだ。EV-101 | 不適合のだ。公開停止後にEV-102で再確認 |
| 委託先の臨時支援権限 | 申請した対象、期間、操作だけを許可 | 対象と権限は確認のだ。操作記録の提出なし | 未確認のだ。提供側へ記録を要求し、残る権限を点検 |
| 特定資料の期間限定共有 | 社外共有を原則禁止 | 取引先一社へ期限付き共有のだ。EX-014と照合 | 承認済み例外のだ。期限と再配布条件を確認 |
| 利用していないAI実行機能 | 高影響操作は個別承認 | 契約・有効機能・連携一覧で実行経路がないことを確認 | 理由付きの対象外のだ。機能追加時に再評価 |
B.3 台帳・統制・事故対応の記録様式
記録を別々の表やファイルに置く場合も、識別子で関連付けるのだ。次の構造なら、表形式でもJSONでも同じ関係を保持できるのだ。
| 記録 | 識別子 | 主な属性 | 接続する記録 |
|---|---|---|---|
| 利用環境 | ASSET-001 | 製品、契約、環境ID、業務、データ区分、責任者、連携先 | リスク、構成情報、連絡先 |
| リスク | RISK-001 | 接点、成立条件、損失、現在の対策、残る条件、不確実性 | 利用環境、統制、受容判断 |
| 構成情報 | CFG-001 | 設定項目、基準値、実設定、取得時点、基準版 | 利用環境、変更、証跡、例外 |
| 統制 | CTRL-001 | 目的、実施条件、担当、確認者、合格条件 | リスク、構成情報、実施証跡 |
| 変更 | CHG-001 | 申請理由、変更前後、承認、実施結果、戻し方 | 構成情報、確認証跡 |
| 証跡 | EV-001 | 種別、対象、日時、実施者、保管先、完全性の確認情報 | 構成情報、統制、事故 |
| 例外・受容 | EX-001 | 不足、補完策、承認者、根拠、期限、再評価条件 | リスク、構成情報 |
| 事故 | INC-001 | 通報、対象、調査責任者、停止判断、連絡、再開条件 | 利用環境、証跡、変更 |
| 回復・訓練 | TEST-001 | 回復元、対象、目標、実績、合否、残課題 | 利用環境、統制、証跡 |
例えば、RISK-001 → CTRL-001 → CFG-001 → EV-001をたどれば、あるリスクに対する設定の実施証拠を確認できるのだ。CFG-001 → EX-001がある場合は、通常基準から外れる理由も追跡できるのだ。関係が存在することだけで内容の妥当性を認定せず、実際の値と根拠をレビューするのだ。
秘密情報の記録には、秘密値ではなく保管先と用途を使うのだ。台帳の更新権限と、証跡の閲覧権限も管理するのだ。訂正前の値を失わない履歴と、実際の取得時点を保持するのだ。
B.4 リスク評価・対策設計・統制運用の実践課題
各課題では、管理対象、事故の成立条件、対策、実施者、証跡、残余リスクの判断を回答するのだ。製品名を答えるだけでは完了としないのだ。
課題1：共通認証の停止後も連携が動く： 退職者の共通認証アカウントを停止したのだ。翌日も、その担当業務の連携アプリが顧客情報を取得していたのだ。アカウント停止が失敗したと判断してよいかを考えるのだ。
解答の要点： 人の認証とアプリの資格情報を区別するのだ。連携の認証方式、資格情報の所有者、付与権限、失効条件を調べるのだ。人事手続が正常でも、連携が独立した資格情報で動いている可能性があるのだ。業務責任者は継続の要否を判断し、管理者は不要な認可と秘密情報を失効させるのだ。停止試験と利用記録を証拠にするのだ。
課題2：自己評価の点数は高いが共有範囲が不明である： 提供企業の自己評価機能は高い点数を示しているのだ。プロジェクト資料への社外アクセスは調べていないのだ。管理上の合格判定を出せるかを考えるのだ。
解答の要点： 点数が示す対象と、自社の要求を照合するのだ。必要な共有範囲が評価されていなければ、その要求は未確認なのだ。共有設定と実際のアクセスを確認した後、承認済みの相手による再配布のリスクも評価するのだ。点数を侵害確率へ変換しないのだ。
課題3：公開フォームの値が申請へ直結する： 外部フォームの必須項目は設定したのだ。受け取った内容は、自動的に承認待ちの申請へ入るのだ。どこまでを確認すべきかを考えるのだ。
解答の要点： 入力項目の有無と、その内容の正しさを分けるのだ。受付条件、送信者の確認、添付、重複、反映先、承認者を追うのだ。業務責任者は確定前の確認条件を定め、設定担当者は実装できる制限を反映するのだ。無害な異常値で、確定処理へ進まないことを試験するのだ。実装できない要件は業務手続か利用制限で補うのだ。
課題4：外部Actionのタグ名は変わっていない： ワークフローの差分はないが、外部Actionのタグが指すコードは変更されていたのだ。構成管理に不足があるかを考えるのだ。
解答の要点： 記録した参照名と実行する実体を分けるのだ。審査したコミット、間接的な依存先、実行権限、渡す秘密情報を確認するのだ。承認済みの完全な参照先と実体の一致を管理するのだ。固定だけでコードの安全性を保証せず、更新審査を継続するのだ。資格情報が露出していれば、ログ削除だけでなく失効を行うのだ。
課題5：WAFの例外は承認済みだが範囲が広い： 一つの業務の誤検知対応として、広いURL範囲で検査を省略していたのだ。設定値は承認記録に一致しているのだ。何を修正すべきかを考えるのだ。
解答の要点： まず承認した基準の妥当性を見直すのだ。必要なホスト、パス、メソッド、対象ルールまで例外を限定し、想定通信で許可と拒否を確認するのだ。現状との差分がゼロでも、基準が過大ならリスクは残るのだ。SSPMなどの追加導入より先に、基準と例外承認の根拠を修正するのだ。
課題6：EDRの許可済み遠隔機能が承認外に使われた： 管理者ロールと防御ポリシーは基準どおりだったが、担当者の権限で承認外の操作が実行されたのだ。設定点検の頻度を上げれば十分かを考えるのだ。
解答の要点： 設定逸脱ではなく、許可された操作の濫用として分析するのだ。実行承認、対象制限、個々の操作記録、独立した確認を検討するのだ。侵害された管理権限を停止し、必要な保護機能は可能な範囲で維持するのだ。残る影響が許容内かを判断し、不足の作用点に合う対策を選ぶのだ。
B.5 用語索引と一次資料
用語は本文の導入箇所で説明しているのだ。次表は、確認のために戻る位置を示す索引なのだ。
| 用語 | 本文での意味・区別 | 初出・主な説明 |
|---|---|---|
| SaaS | 提供企業が運用する業務アプリケーションのサービス利用 | 1.1.1 |
| 管理・統制 | リスクへの対応と、その実施・確認・是正を組織として維持する仕組み | 1.3.1、7.1 |
| テナント | サービス内で利用・管理を区切る環境 | 2.2.1 |
| 攻撃面 | 悪用され得る接点と操作の範囲 | 3.1 |
| アカウント | 利用者を識別する情報 | 3.2.1 |
| 認証・MFA・SSO | 本人確認、複数要素の組合せ、認証の共通利用 | 3.2.2 |
| セッション | 認証後の利用状態とその継続 | 3.2.3 |
| 認可・実効権限 | 操作の許可と、設定の組合せで実際に許可される範囲 | 3.2.4、8.2 |
| API・資格情報 | プログラムが使う窓口と、そのアクセスに用いる情報 | 3.4.1〜3.4.2 |
| OAuth | アプリによるアクセスを認可する仕組み | 3.4.3 |
| AIエージェント | 参照だけでなく、接続した機能を通じて操作を実行する構成 | 3.4.4〜3.4.5 |
| ワークフロー・Action | 自動実行する一連の処理と、呼び出す処理部品 | 3.4.6 |
| WAF・EDR | Web通信の防御、端末の検知・対応を支える製品群 | 3.5.4、8.9〜8.10 |
| 脅威・弱点・業務影響 | 損失を生じさせる要因、成立を許す条件、業務の結果への影響 | 4.1.1 |
| 構成管理 | 基準、実設定、変更、例外を対応付けて維持する管理 | 6.2 |
| 証跡 | 対象・時点・実施内容を確認するための記録 | 7.1.3、7.7.1 |
| 回復元・RPO・RTO | 回復に使う情報、回復時点の目標、回復時間の目標 | 6.8、7.6 |
| 自己評価機能 | 提供企業の評価基準で設定状態などを確認する機能 | 9.2 |
| SSPM | SaaSの設定・権限を横断的に確認する手段の一つ | 9.4.3 |
| 残余リスク | 現在の対策を考慮した後にも残るリスク | 4.6、10.1 |
一次資料の確認基準日は2026年9月27日なのだ。製品仕様の記述は公開資料に基づくのだ。利用企業の契約や実環境での動作を検証した結果ではないのだ。法令・契約の適用、利用可能な機能、記録の取得範囲は、対象環境に照らして確認するのだ。
以下に本文の参照資料を掲載するのだ。資料の発生日、公表日、確認日を区別したのだ。本文の想定例、確認票、時間モデルは本稿の説明用であり、公表事件や対策効果の測定値ではないのだ。
参考文献
[1] NIST
The NIST Definition of Cloud Computing（SP 800-145）。2011年9月。
[2] Microsoft
Shared responsibility in the cloud。2026年9月27日確認。
[3] NIST
Guide for Conducting Risk Assessments（SP 800-30 Rev.1）。2012年9月。
[4] 個人情報保護委員会
個人情報の保護に関する法律についてのガイドライン（通則編）。2026年9月27日確認。
[5] Microsoft
Teams-connected sites。2026年9月27日確認。
[6] GitHub
Secure use reference。2026年9月27日確認。
[7] Mandiant / Google Cloud
UNC3944 Targets SaaS Applications。2024年6月13日。
[8] ヌーラボ
Nulab Pass。2026年9月27日確認。
[9] IETF
Best Current Practice for OAuth 2.0 Security（RFC 9700）。2025年1月。
[10] Salesforce Trailhead
Data Security: Overview of Data Security。2026年9月27日確認。
[11] Microsoft
External sharing overview。2026年9月27日確認。
[12] Salesforce
Protecting Your Data: Essential Actions to Secure Experience Cloud Guest User Access。2026年3月7日公表・3月11日更新。
[13] SAP Concur
Authentication: Getting Started。2026年9月27日確認。
[14] Microsoft
Data, Privacy, and Security for Microsoft Copilot。2026年8月18日更新。
[15] AppOmni Labs
ServiceNow AI Agent-to-Agent Discovery Prompt Injection。2025年11月19日。 研究者による再現実験。実被害事件として集計しない。
[16] GitHub Advisory Database
tj-actions/changed-files compromised（GHSA-mrrh-fwg8-r2c3 / CVE-2025-30066）。2025年3月15日公表。
[17] HubSpot
March 2022 Security Incident。2022年7月11日更新。
[18] Microsoft
Unmasking EvilTokens: Getting to the root of device code phishing。2026年9月22日。
[19] UpGuard
Power Apps Portals: Millions of Records Exposed。2021年8月23日。
[20] Google Threat Intelligence Group
Widespread Data Theft Targets Salesforce Instances via Salesloft Drift。2025年8月。
[21] Imperva
Imperva Security Update。2019年10月10日更新。
[22] Cloudflare
The impact of the Salesloft Drift breach on Cloudflare and our customers。2025年9月2日。
[23] FBI Internet Crime Complaint Center
Cyber Criminals Conduct Business Email Compromise Through Exploitation of Cloud-Based Email Services。2020年4月6日。
[24] Atlassian
Post-Incident Review: April 2022 outage。2022年4月29日。
[25] NotePM
セキュリティへの取り組み。2026年9月27日確認。
[26] 個人情報保護委員会
個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）。2026年9月27日確認。
[27] Google Threat Intelligence Group / Mandiant
The Expansion of ShinyHunters SaaS Data Theft。2026年1月30日。
[28] Microsoft
Storm-2372 conducts device code phishing campaign。2025年2月13日公表・2026年7月更新。
[29] Check Point Research
Attackers Are Turning Microsoft’s Trusted Login System into Their Latest Phishing Weapon。2026年7月29日。
[30] Mandiant / Google Cloud
UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion。2024年6月10日。
[31] Slack
Slack security update。2022年12月31日公表・2023年1月9日更新。
[32] 米国司法省
Former Google Engineer Found Guilty of Economic Espionage and Theft of Confidential AI Technology。2026年1月30日。 当該公表時点の評決と行為の記録。個人クラウドへの持出しを説明する補助事例。
[33] Dropbox Sign
A recent security incident involving Dropbox Sign。2024年5月。
[34] Guardio Labs
[35] 米国司法省
San Jose Man Sentenced To Two Years In Imprisonment For Damaging Cisco’s Network。2020年12月9日。 SaaS提供企業の基盤側の事案。
[36] Federal Trade Commission
FTC Requires Zoom to Enhance its Security Practices as Part of Settlement。2020年11月。
[37] Federal Trade Commission
[38] NIST
Guide for Security-Focused Configuration Management of Information Systems（SP 800-128）。2019年10月更新。
[39] The Institute of Internal Auditors
The IIA’s Three Lines Model。2020年7月。
[40] Slack
Manage app approval for your workspace。2026年9月27日確認。
[41] Slack
Audit Logs API。2026年9月27日確認。
[42] SAP Concur Community
Acting as a delegate（提供企業担当者による回答）。2024年11月。
[43] ラクス
楽楽精算 公式製品情報。2026年9月27日確認。
[44] サイボウズ
APIトークンを生成する。2026年9月27日確認。
[45] トヨクモ
kViewer。2026年9月27日確認。
[46] トヨクモ
フォームの受付期間（公開期間）を設定する。2026年7月17日更新。
[47] Hubble
Hubble 製品・セキュリティ情報。2026年9月27日確認。
[48] コラボスタイル
システム管理とは？。2026年9月27日確認。
[49] GitHub
About rulesets。2026年9月27日確認。
[50] Cloudflare
Configure a custom rule with the Skip action。2026年8月3日更新。
[51] Cloudflare
Protect your origin server。2026年9月27日確認。
[52] Cloudflare
Create an API token。2026年9月27日確認。
[53] Cloudflare
Review audit logs。2026年9月27日確認。
[54] CrowdStrike
Real Time Response API reference。2026年9月27日確認。
[55] Microsoft
Learn about auditing solutions in Microsoft Purview。2026年9月27日確認。
[56] Microsoft
Microsoft Secure Score。2026年9月27日確認。
[57] Salesforce
Security Health Check。2026年9月27日確認。
[58] Microsoft365DSC project
What is Microsoft365DSC?。2026年9月27日確認。
[59] CISA
ScubaGear。2026年9月27日確認。