クラウドファースト時代における特権アクセス管理解説

CSAジャパン　諸角　昌宏

特権的なアクセス権限は、ユーザーに異なる役割が割り当てられるあらゆる環境でセキュアに管理する必要がある。適切なコントロールが講じられていない場合に、組織は内部での不正利用や外部からの脅威に曝される。このような状況において、PAM（特権アクセス管理、Privileged access management）の重要性が高まっている。
本ブログでは、PAMの現在の位置づけを整理した上で、CSA本部が「クラウドファースト時代における特権アクセス管理、Managing Privileged Access In a Cloud-First World」として公開した資料に基づいて、クラウドファースト環境における特権アクセス管理のベストプラクティスについて解説する。

PAMとは？

まず、PAMの定義を明確にしたい。PAMというと、どうしても製品のイメージが強い。また、PAMの日本語訳である「特権アクセス管理」という言葉から考えられるのは、管理者が使用する特権アカウントをいかにセキュアにするか、つまり、特権を付与されているアイデンティティとアクセス管理を行う製品というイメージになる。しかしながら、WikipediaでPAMを検索すると、「Privileged access management（略称:PAM、別名:特権アクセス管理）は、組織内の特権アカウントの制御、監視、保護に焦点を当てたサイバーセキュリティ上重要なアイデンティティ管理である」としている。ここで「アイデンティティ管理」という部分については上記の特権アカウントの管理ということになるが、「組織内の特権アカウントの制御、監視、保護に焦点」を当てるという部分があり、単なる認証/認可だけではなく特権アクセスのセキュリティ統制を含んでいるといえる。そうすると、PAMを製品として捉えるのではなく、特権アクセスを付与・利用・監視・記録・不要になった場合の無効化を総合的に行うための統制モデルと考える必要がある。

また、Gartnerは、PAMが必要な機能としてJust-In-Time（JIT）や Zero Standing Privileges（ZSP）という用語を使っており、特権というのは常設されるべきでなく、必要な瞬間に付与し必要無くなったら直ちに削除するということを要件としている。

また、PAMと関連する用語としてIAM 、IGA、CIEMがあるが、これらとPAMとの違いは、IAM 、IGA、CIEMが「誰にどの権限を持たせるか」を管理するのに対して、PAMは「その権限をいつ、どのように使わせるか」を管理すると考える必要がある。以上のことから考えて、PAMは、特権アクセスに対して、最小特権、時間制限、制御および監視を適用するセキュリティ統制であると考えるのが妥当である。その上で、PAM製品はその概念を技術的に実装する手段という位置づけになる。

PAMの背景

「クラウドファースト時代における特権アクセス管理」において、特権アカウントは侵害において常に最も標的とされ最も深刻な被害をもたらす攻撃経路であると記述している。その理由として以下の点が挙げられている。

ガートナー社の調査によれば、インシデントの50％以上が、アイデンティティ、アクセス、特権の管理不備に起因している。
ベライゾン社のData Breach Investigations Report（DBIR）によると、データセキュリティインシデントの80％が、侵害または悪用されたクレデンシャル（特権・非特権を含む）に関連していることが統計で示されている。

このように、特権アカウントあるいは特権を持っていることがデータ侵害に大きく影響していることがわかる。では、特権というものが厳密に管理されていればデータ侵害は起こらないのだろうか？理論的には以下の4つの前提がすべて満たされれば外部攻撃によるデータ侵害は極めて成立しにくいと言える（ここでは、外部からのデータ侵害に絞って考える）。

アカウント侵害ができない
権限昇格が不可能である
過剰権限が存在しない
認可・設計・設定・運用が正しい

しかしながら、現実のシステムではこの前提がほぼ崩れることになる。その理由は、設計・運用が「常に」維持できるものではなく、システム・人間・環境が「時間とともに変化する」からだということができる。変化により「正しかった設計」が「不正確」になってしまう。緊急対応での一時設定、トラブル回避の例外措置、手作業の微調整などにより、設定が意図せずドリフトする。業務優先のショートカット、「今回はいいだろう」という対応、引き継ぎ漏れ・理解不足などにより人間は必ず逸脱を引き起こしてしまう。また、使われていないアカウント、放置されたAPIキー、シャドーアカウントなどにより、存在を認識していないものは管理できないという可視性の問題も起こる。このような設計・運用が「常に」維持できないという問題は、監査で確認することが求められているが、それをさらに確実にしていくには、自動化と継続的なモニタリングが必要であり、特権アカウントや特権アクセスが慎重に管理され、状況が認識されることが必要になる。これを支援するのがPAMの役割と考える。また、最小特権および時間制限という観点から、PAMは、ユーザーに業務に必要な最小限のアクセス権のみを、必要な期間のみ与えるための機能を提供することが必要になる。

効果的なPAMによるコントロール

PAMによるコントロールとして以下の点が必要となる。

最小特権（Least Privilege）
最小特権の原則をデフォルトで強制する。人/非人間の双方に、必要な権限のみを付与し、それ以上の権限は付与すべきではない。
必要な期間のみ（Just In Time、JIT）
特権は恒常的に付与せず、永続的な特権アカウントからジャストインタイム（JIT）や時間制限付きアクセスモードへ移行する。
ポリシー駆動（Policy-based Control）
特権アクセスは事前定義されたポリシーに基づいて制御する。裁量ではなく、ポリシーに基づいて制御する。
自動化（Automation）
特権の付与・剥奪・管理プロセスは自動化する。未使用または期限切れのアカウントには自動失効機能を適用する。
継続的モニタリング（Continuous Monitoring）
特権アクセスの利用状況は継続的に監視・記録する。継続的にモニタリングし、新たに作成された特権アカウント、役割の変更、または予期せぬ特権の昇格を検出する。

「特権は恒常的に付与しない」は可能か？

ここでは、「クラウドファースト時代における特権アクセス管理」には記述されていないが、PAMによるコントロールを整理する中で気になった点として「特権は恒常的に付与しない」ということが可能なのかという点について考察してみる。
特権を恒常的に付与しないことは、攻撃に可能な時間と影響範囲を最小化できるため重要である。恒常的な特権付与は、アカウント侵害時に即座に高権限を悪用されるリスクを内包するため、攻撃可能時間が無限になり、また特権取得を明確な監査イベントとして管理することができない。半面、特権を恒常的に付与せずJITとした場合、セキュリティが向上する代わりに、可用性、運用効率、ユーザーエクスペリエンスの問題が発生する。特に、緊急時の障害対応において時間がかかってしまう（JITの承認者がすぐに対応できないなど）ことになる。

PAM運用においては、特権付与の承認レベルに応じて以下のようなモデルが一般的に用いられる。

事前承認JIT
これは、特権の付与にあたって承認が必要となる。流れとしては、申請→承認→JIT付与→作業→自動失効となる。この場合、特権が必要な場合には常に事前承認が必要となるため、統制の観点では最強となる。したがって、高リスクの作業を必要とする場合に適している。ただし、緊急性が求められる場合には対応できないことが発生する可能性がある。
無承認JIT（自己承認/ポリシー自動）
これは、承認者が存在しない、別の言い方をすると自己承認JITというものである。流れとしては、本人要求→ポリシー判定→即JIT→作業→自動失効となる。この場合、承認者は存在しない。ガバナンスの観点では弱くなるが、ログが生成されるので監視・監査は可能である。したがって、これは低～中のリスクの作業に対して日常運用で用いることが考えられる。
事後承認（先に付与、後でレビュー）
これは、まず特権を付与し、使用した後でレビューする方式となる。流れとしては、JIT即時付与→作業→自動失効→後日レビュー（理由・操作内容）となる。承認なしで作業が行われるため、緊急対応や夜間対応の時に用いることが考えられる。

これらの機能をうまく運用することで、セキュリティの向上、緊急時の障害対応などを「特権を恒常的に付与しない」形で実現できる。ただし、運用方針をしっかり定めておくことが重要となる。

さて、上記の機能を使って「特権を恒常的に付与しない」運用をPAMを使って実現できるのであるが、常時特権を持ったアカウント（root等）は必要ないということにはならない。それは、非常事態として、PAMも認証基盤も壊れてしまった場合に最後に「必ず入れる道」を残す必要があるからである。いわゆる「Break-glass」である（注：Break-glassという考え方自体は「クラウドファースト時代における特権アクセス管理」に直接記載されているものではなく、実運用上一般的に用いられている設計パターンとして用いている）。認証基盤、PAM、管理プレーンなどが壊れた場合や緊急対応を必要とする重大インシデントへの対応などではどうしても「最後の管理者」が必要となる。そうすると、基本はPAMを使った「特権を恒常的に付与しない」運用を行い、緊急のためにBreak-glassで対応するという運用が必要となる。しかし、Break-glassを前提すべきではなく、あくまで基本はPAMを使った「特権を恒常的に付与しない」運用にすべきである。つまり、Break-glass は「存在させるが、通常は使わない」前提で設計する必要がある。

もう一つ、特権というか権限を常時付与することが求められることとして、部門/業務等で日常的に必要な権限の付与がある。これには、業務で必要となる権限、機械的に付与される権限などがあり、「必要な時だけ権限を付与」ということがそもそも成り立たない。しかしながら、この部門/業務等で常時付与される権限は、侵害の起点となることが多く、権限昇格やラテラルムーブメントを引き起こすことにもなりうる。これを考えると、PAMは「全体の権限を統合管理する基盤」ではなく、あくまで管理者権限、IAMの高権限ロールを対象にしていて、情報システムそのものを破壊できるような高権限を管理することを目的とし、部門/業務等で日常的に必要な権限はIAM/IGAの範囲と考えるのが妥当である。まとめると、PAMは「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる。

クラウドファースト環境における特権アクセス管理のベストプラクティス10選

「クラウドファースト時代における特権アクセス管理」では、クラウド環境における特権アクセス管理のベストプラクティスとして以下の10項目を挙げている。ここでは、その概要を説明する。

ジャストインタイムアクセス（JIT）およびジャストイナフアクセス（JEA）を活用し、常時付与された特権を排除する
- 永続的な管理者権限を廃止し、「必要な作業に必要な期間だけ最小権限」を動的に付与してアタックサーフェスを削減する。
- 攻撃者は「常時存在する管理者権限」を狙うことが多いため、これを排除することで侵害リスクが大きく減少する。
自動化による特権アクセスの検出とインベントリ
- シャドーアカウントを含むすべての特権アカウントを自動発見・棚卸しし、見えない特権（シャドー特権）を可視化し排除する。
- クラウドでは「誰も把握していない管理権限」が必ず増えるため、これを可視化し排除することが重要である。
きめ細かなアクセス制御と役割分担の導入
- RBAC/PBACにより職務の分離と最小特権を徹底し、単一アカウントへの過剰集中を防止する。
- 「管理者」という大雑把な権限をやめ、職務単位で分解し権限付与する。これにより、1アカウントを侵害することで全ての権限を持ってしまうという構造を壊すことができる。
権限付与、使用状況、および特権アクセス管理の行動パターンを分析する
- 特権の使われ方を継続的に分析し、異常行動・過剰権限・リスク傾向を早期検知する。
- 単にログを取るだけでなく、普段と違う操作、異常な時間帯、権限の使われ方の変化などを行動として分析する。クラウドでは、特に正規アカウントを使った侵害が起こるため、正規アカウントによる異常操作を見つける必要がある。
包括的な特権セッションのモニタリングおよび監査の有効化
- すべての特権操作を記録・可視化し、フォレンジック・説明責任・規制対応を可能にする。
- インシデント後に、誰が何をしたかを説明できるようにし、統制や復旧をスムーズに行えるようにする。
すべての重要な資産とアイデンティティにPAMを拡張する
- サーバーだけでなく、SaaS、業務アプリ、クラウド管理プレーンまでPAM対象に含める。
- PAMの対象をSaaS管理プレーン、業務アプリ、クラウド管理APIまで広げることで、SaaSや業務アプリ側の侵害を防ぐ。
非人間アイデンティティとワークロードアクセスをセキュアにする
- サービスアカウント、API、ボット、AIエージェントにもJIT・最小特権・監査を適用する。
- 人ではなく、サービスアカウントやAIエージェントにも適用することでセキュアにする。
セキュアなリモートおよびサードパーティアクセス
- ベンダーや外部委託先のアクセスも一時的・監査可能を前提として制御する。
- ベンダーや委託先に対しても、永続IDを渡さず時間限定や操作記録付きでアクセスさせるようにすることでセキュアにする。
PAMをDevOps、CI/CDのInfrastructure-as-Code（IaC）ワークフローに統合する
- PAMをDevOps、CI/CDのInfrastructure-as-Code（IaC）ワークフローに統合し、コード経由の特権漏洩や設定ミスを防止する。
- CI/CD、Terraform などの中の特権もPAM管理下に置くことで、コード内シークレットの問題を解決する。
強固なガバナンスとコンプライアンスの確立
- PAMログと統制をSOX／PCI DSS／NIST等の証跡として活用し、監査対応を自動化する。
- PAMログを、そのまま監査証跡、規制対応、経営報告に使えるようにする。これにより、PAMを経営統制のインフラとする。

まとめ

本ブログでは、PAMの定義、PAMの守備範囲について説明した。また、現代のデータ侵害の起点となる特権の扱いとして、「「特権は恒常的に付与しない」は可能か」という点について、PAMの機能を中心に考察した。さらに、クラウドファースト環境における特権アクセス管理のベストプラクティスについてその概要を説明した。

PAMは今後、必須の機能となるが、「全体の権限を統合管理する基盤」ではなく「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる点は理解しておく必要がある。

以上

SaaS 環境でよくあるセキュリティリスクと対策

コメントをどうぞ

第3回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第3回会議の内容をまとめて公開する。

2026年01月20日　18:30-20:00　開催

問題点の概要

BetterCloud社が公開した「Common SaaS security risks, horrifying recent breaches, and mitigation tips」において、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例、そしてそれらへの対策について解説している。第3回SaaSセキュリティリーグでは、ここで述べられている７つのセキュリティリスクについて、実際にSaaSのセキュリティ管理を行っている立場からディスカッションした。また、主なSaaSセキュリティリスクを軽減する方法（資料内の FAQ）の有効性についてディスカッションした。

SaaS 環境でよくあるセキュリティリスク

BetterCloud社が公開した資料で挙げられている7つのセキュリティリスクは以下である。

設定ミス（Misconfigurations）
- 誤った設定により脆弱点が露出。
- 例：認証不要のページに内部データが公開された Salesforce サイト。設定ミスが侵害につながった典型例。
オフボーディングの遅延（Delayed offboarding）
- 退職者アカウントが削除されずに残ると、データへの不正アクセスや情報窃取につながる危険性。
- 例： Cash Appでの退職者によるデータ抜き出し事件を紹介。
管理者権限の過剰付与（Excessive admin privileges）
- 権限の過剰なユーザーがいると、侵害時の被害拡大リスクが高まる
- 例：Verkada の内部カメラ映像が暴露された事件。
認証情報の漏洩（Compromised credentials）
- フィッシングや盗難によるアカウント侵害が依然として主要なリスク。
- 例：Okta 社のサポートチケット情報にアクセスされた事例。
過剰なアプリ権限（Overly permissive app data access）
- サードパーティアプリに対して不要なデータアクセスを許可してしまうと、意図せぬ情報漏洩につながる。
- 例： OneDriveで、アプリ連携（OAuth権限/スコープ）により過剰なデータアクセスが起こり得るリスクが指摘されているケース。
不十分な第三者統合（Insecure third-party integrations）
- 連携サービス側の脆弱性が本体システムへ影響を与える可能性。
- 例：Okta 侵害 → Cloudflare の Atlassian への不正アクセスに波及。
不適切なファイル共有（Improper file sharing practices）
- 誰でもアクセス可能な公開リンクなどにより、機密データが漏洩する危険性。
- 例：日本のゲーム会社 Ateam が Google Drive の公開リンクを誤設定し、長期間データ公開状態となった事件。

セキュリティリスクに対するディスカッション

上記SaaS 環境でよくあるセキュリティリスクについて、実際にどのように問題点として捉えているか、既に解決済みなのか、あるいは、どのような検討が行われているかについてディスカッションを行った。

設定ミス（Misconfigurations）
組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。
組織全体で利用するSaaSの場合は、情報システム部門が直接対応しているので対策が取れている。部門等で利用するSaaSの場合は、情報システム部門が助言はするが直接対応はしていない。部門と委託先（SaaSの調達・管理を委託）が協力して対応できているところはできているが、部門が独自にやっている場合は難しい。情報システム部門としてチェックをしているが、数が多いため難しい場合がある。したがって、基本的な運用としては、監査において定期的なチェックを行うこととしている。
オフボーディングの遅延（Delayed offboarding）
退職者アカウントについては管理できている。作業漏れの対策として、棚卸を定期的に実施している。部門で管理しているSaaSアカウントは、手動で管理するのは限界であり、人事システムとの連携が行えるようにIGA（Identity Governance and Administration）を利用することを検討している。人事システムとの連携ができるIGAは有効なツールになると考えている。その上で棚卸を実施し、定期的にチェックする。
管理者権限の過剰付与（Excessive admin privileges）
過剰権限、過剰設定を確認するチェックシートを作って管理している。チェックシートの中で最小権限等の指示を行っている。管理者権限の付与に対する対応は、どうしてもアナログにならざるを得ない。というのは、誰に対してどのような権限を付与するかについてはシステムオーナーしか分からないため、どうしても個別の対応になってしまう。したがって、情報システム部門としては、過剰権限になっていないかどうかのチェックを行うことで対応している。
SSPMが過剰な権限を指摘してくれるので、SSPMを利用して管理を行うのは有効であるが、以前から指摘されているSSPMのコストの問題がある。
管理者権限等の特権の管理としてPAM（Privileged Access Management）があり、これを利用することも考えられるが、現状はIaaSで一部利用している程度でSaaSでは利用していない。
認証情報の漏洩（Compromised credentials）
この問題も、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。組織全体で利用するSaaSでは、情報システム部門が管理しているため、条件付きアクセスの設定を付けることでアカウント侵害を防いでいる。しかしながら、部門等で利用するSaaSでは、どこまで徹底できているかは不明な部分がある。
認証情報については、アクセス元のチェック、端末認証等を導入して対応している。これにより、モニタリングができているので、もしアカウントの漏洩が発生すれば、情報システム部門から注意するという運用ができている。
過剰なアプリ権限（Overly permissive app data access）
API連携の申請が来るケースがあり、情報システム部門でチェックしている。サードパーティアプリから不要なデータアクセスをされるケースには、APIアクセスキーのローテーションで対応している。最近課題として出てきているのは、Microsoft graphAPIに対する連携の依頼が多くなっていることである。組織全体にアクセスできる権利を要求されることがあり、他の部門のデータも見られてしまう可能性があり注意が必要である。
以前（第１回SaaSセキュリティリーグ）指摘されたが、AIが社内の見えないところを見てしまう、つまり、AIが社内の機密データを見つけて公開してしまう問題がある。自律型AIの権限をどうするのかは今後課題となる。
不十分な第三者統合（Insecure third-party integrations）
上記5で検討した内容と同様。
不適切なファイル共有（Improper file sharing practices）
ファイル共有については、ルール化をどう定義するかが難しいポイントである。Microsoft 365では、外部DLP製品に頼らず、自社クラウドの標準機能として DLP を公式に提供している。このDLP機能を使ってクラウドストレージサービスの共有問題に対応している。Google Driveについては、ダウンロードはOKにしているが、アップロードはNGとする対応を取っている。これは、CASB/SGWでコントロールしている。また、クラウドストレージに外部公開する場合には申請が必要で、申請があれば特定領域を共有できるようにするという運用でカバーしている。

主なSaaSセキュリティリスクを軽減する方法

以下の12個が、BetterCloud社が公開した資料でSaaSセキュリティリスクを軽減する方法の概要をFAQとして記述したものである。

Q1. SaaS ベンダーのセキュリティリスク評価はどのように行うべきか？
SaaS ベンダー評価では、次の点を確認する必要がある：
- SaaS プラットフォームの運用するデータセンターやインフラのセキュリティ体制データ暗号化（保存時／移動時）の仕組みアクセス制御（認証・認可）の方式実施済みのセキュリティ監査や認証（たとえばSOC 2など）
- サードパーティ連携や API のセキュリティ設計・権限付与の仕組み
  これらの評価を自動化ツールで継続的にチェックすると、ベンダー変更や構成変化にも適応しやすくなる。
Q2. 多要素認証（MFA）をどのように強制するか？
- できる限りすべてのユーザーに MFA を必須化する
- MFA未設定のユーザーにはログインを拒否するルールを設ける
- 権限レビューを定期的に実施し、認証強度を維持する
Q3. 従業員向けにはどんなセキュリティ教育をすべきか？
- 最新のフィッシング手法の理解
  → フィッシング攻撃による認証情報漏洩防止
- ファイル共有の責任ある利用法
  → 過度に公開リンクを作らない／意図しない共有範囲を避ける
Q4. SaaS 全体のセキュリティを常に把握する方法？
「可視性の欠如」がSaaSリスクの根底にある。自動化された可視化／監視ツールの導入が有効。これによって次が可能になる：
- 新規・非承認アプリの検出（シャドーIT）
- ユーザーアクセスログとファイル共有状況の自動監視
- 外部共有や不正アクセスのリアルタイムアラート
Q5. 「Super Admin（管理者権限）」の数を制限する方法？
- セキュリティポリシーとしてアプリ毎に許容する最大Super Admin数を定め、しきい値を超えたらアラートを出す仕組みを設定
- 単純な管理者数の制御だけでなく、不適切な権限拡大を未然に検知する
Q6. ユーザーのオフボーディング（退職時処理）はどう自動化するか？
- SaaS 管理プラットフォームでは、退職者やロールチェンジの際にアカウントを自動無効化・権限削除するワークフローを設定可能。
- これにより「幽霊アカウント」問題や放置されたアクセス権限のリスクを抑制できる。
Q7. 定期的なコンテンツスキャンをどのように実行するか？
ファイルやデータをスキャンして以下を特定する：
- 機密データ（PII、顧客情報、知的財産など）の所在
- 過剰な共有設定ファイル
- 不適切なアクセス権限が付与されたファイル
  これも自動化ツールが必要で、人手ベースでは難しい。
Q8. どのようなファイル共有モニタリングが必要か？
- 外部共有の過剰検出
- 許可範囲の過度な広さ（過剰権限）
- 非アクティブ共有の把握と削除
  これらのモニタリングにより、ファイル共有に起因する漏洩リスクを削減可能。
Q9. ファイル共有方針を強制する方法？
- 教育に加え、自動化された定期的なファイル権限のクリーニングやポリシー例外を検出する仕組みを運用することで、方針遵守を強制する。
Q10. SaaS セキュリティポスチャを高める最良の方法？
- 強力なSSPM機能を持つ管理プラットフォームを使い、継続的な可視化、監査、ポリシー施行、自動リメディエーションを実施する。
Q11. インシデント発生時の即時対応（IR）計画はなぜ重要か？
- 侵害疑いを検知したら、影響範囲の隔離、パスワード変更、侵害アカウントの停止、ファイル共有のブロックなどを迅速に行うIR計画が必要である。
- これはインシデントの被害拡大を防ぐうえで極めて重要である。
Q12. ルート原因分析（Root-Cause Analysis）はいつ行うべきか？
侵害の封じ込め後に実施。分析の対象は以下：
- 初期侵入経路
- 誤設定や脆弱性
- データ抽出・ラテラルムーブメントのプロセス
- 影響した他 SaaS との関連
  これらにより恒久的な改善策が設計できる。

主なSaaSセキュリティリスクを軽減する方法に関するディスカッション

上記の12個の対策に対して、ディスカッションした内容を以下に記述する。

MFAの強制について
機密情報等を扱うSaaSについては、MFAは必須である。また、SSOへの対応も有効であり、SAMLで管理を行っている。これは、部門等で利用するSaaSで機密情報を扱う場合においても強制している。
また、MFAができない場合には、グローバルIP等で制限を掛けることでSaaSへのアクセスを制限している。グローバルIPによる制限は、完全ではないが、想定外の国やネットワークからの直接アクセスが防げるということで有効である。
また、業務に合わせて端末レベルでの制御も行っている。
従業員向けのセキュリティ教育
従業員教育は必ず実施しているが、きちんと理解されているかどうかは疑問なところもある。今後の対策として、教育を超えてシステム的な対策が必要であると考える。例として、一般的な内容ではなく、自分が直面するような問題・危機感を持たせるような（シナリオ的）教育を進めることが有効である。
また、日常的な観点に基づいてコンテンツ化することも有効である。
SaaS セキュリティポスチャを高める方法
これには、SSPMが有効であるが、実際にはコストの観点から広め切れていない。セキュリティの可視化ができないとリスクが分からないので、うまくSSPMを使う方法を考えていきたいし、ベンダー側の対応も期待したい。
インシデント対応
SaaSのインシデントレスポンスでは、インシデントの検知の報告が、SaaS側ではなく利用者側からの報告ベースになることが多い。あるいは、代理店が検知して対応してくれるケースがある。これは、SaaS側からのインシデントの報告が十分でないことを意味しており、特に部門で利用するSaaSの場合この傾向が顕著である。

まとめ

今回は、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例とそれらへの対策について、BetterCloud社が公開した資料をベースにディスカッションを行った。「あるある」的な内容ではあるが、実際にディスカッションしてみて以下の点が明確になった。

あらためて、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。情報システム部門が直接対応しきれない部門等で利用するSaaSへの対応をチェックリストや監査を通してうまく進めていくことが求められる。
特権アカウントおよび権限付与の扱いが、SaaS利用においても重要になっている。これは、人手による対応では厳しい状況となっており、IGAやPAM等を効果的に使っていくことが求められる。
API連携の問題がクローズアップされてきている。これは、自組織側の管理だけではなく、連携元の管理にも依存してくるため、どのように連携して対応していくかを検討する必要がある。
SaaSのインシデント対応が重要になる。インシデントの報告がSaaS側からきちんと行われないと、利用者側で対応することができない。しかしながら、現状は、SaaS側からの報告があまり行われていないようである。利用者とSaaS側とのより良い連携が求められている。
いつも話題となるが、SSPMのカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

以上

開発者向けクラウドネイティブセキュリティの基礎（ワークロードセキュリティ編）(2)

コメントをどうぞ

前回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「MLOps」に焦点を当てながら、AIワークロードセキュティの動向をみたが、今回は、AIの普及とともに急増する人間以外のアイデンティティ（NHI：Non-Human Identity）に焦点を当てる。

ノンヒューマン・アイデンティティ（NHI）とAIワークロードの関係

クラウドセキュリティアライアンス（CSA）のブログ記事「ノンヒューマン・アイデンティティ管理」（関連情報（https://cloudsecurityalliance.org/blog/2024/07/15/non-human-identity-management））によると、ノンヒューマン・アイデンティティ（NHI）とは、現代の企業システムにおいて、マシン同士や人とマシンとの間のアクセスおよび認証を安全に行うためのデジタル・ゲートキーパーとして機能するものである。イノベーションの推進により、マイクロサービス、サードパーティ製ソリューション、クラウドベースのプラットフォームの導入が進み、相互に接続されたシステムの複雑なネットワークが形成されているという背景がある。

そしてノンヒューマン・アイデンティティ管理（NHIM）とは、非人間の識別情報のライフサイクル全体を統制・自動化するプロセスであり、以下のような項目が含まれるとしている。

・発見と分類
・プロビジョニング（識別情報の作成と割り当て）
・所有者の割り当て
・状態の監視と異常検知
・保管庫への格納と安全な保存
・資格情報のローテーション（定期的な更新）
・コンプライアンス対応
・廃止（使用終了時の適切な処理）

他方、AIワークロードとは、機械学習モデルのトレーニング、推論、データ処理、API連携など、AIが関与する一連の処理やタスクのことを指す。AIワークロードはクラウドやオンプレミス環境で自動的に実行されることが多く、人間の介在なしに動くのが特徴となっている。

AIワークロードは、以下のような人間以外のエンティティによって構成されていることが多い：

・AIモデル自体（例：推論エンジン）
・スクリプトやバッチ処理
・APIクライアント
・コンテナやマイクロサービス
・CI/CDパイプラインの自動化ツール

これらはすべて人間ではないが、システムにアクセスし、機密データを扱い、他のサービスと通信する存在となっている。そこで、誰が何にアクセスしているのかを明確にするためには、NHIの管理が不可欠になる。

NHIに対するリスク認識と具体的セキュリティ対策のアンバランス

CSAでは、ボット、APIキー、サービスアカウント、OAuthトークン、シークレットなどノンヒューマン・アイデンティティ（NHI）セキュリティで見落とされがちな側面を理解するために、2024年6月にオンライン調査を実施し、ITおよびセキュリティ専門家から818件の回答を得た。この結果を取りまとめたのが、2024年9月11日に公開された「ノンヒューマン・アイデンティティ・セキュリティの現状」である（関連情報（https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report））。

この報告書では、以下の点について洞察を提供している。

・NHIとそのセキュリティリスクに関する認識
・現在のNHIのセキュリティ対策、ポリシー、管理
・サードパーティベンダーとの接続に関する課題
・APIキーの現在の管理とポリシー

主な調査結果は以下の通りである。

・NHI攻撃の防止に高い自信を持つ組織はわずか15%で、69%が懸念を表明している。これは、リスクを認識しているものの、現在のセキュリティ対策に自信がないことを示している。
・主な問題点としては、サービスアカウントの管理、監査と監視、アクセスと権限の管理、NHI の検出、ポリシーの適用などが挙げられる。
・APIキーのオフボーディングと失効に関する正式なプロセスを設けている組織はわずか20%であった。APIキーのローテーション手順を設けている組織はさらに少ない。
・多くの組織は、NHI向けに特別に設計されていないセキュリティツールを混在して使用している結果、一貫性と有効性が欠如している。
・有望な傾向として、NHI セキュリティ機能への投資が増加している。組織の 24% が今後 6 か月以内に、36% が今後 12 か月以内に投資する予定としている。

新たなノンヒューマン・アイデンティティ（NHI）のリスクとは？

前述のブログでは、MITRE ATT&CK Matrix for Enterprise（関連情報（https://attack.mitre.org/matrices/enterprise/））を参照しながら、管理されていないノンヒューマン・アイデンティティ（NHI）が、以下のような攻撃者の戦術・技術に関与することがあるとしている。

初期アクセス：攻撃者がネットワークへの侵入を試みる段階
・サプライチェーンの侵害（T1195）
・信頼された関係性の悪用（T1199）
・正規アカウントの悪用（T1078）
永続化：攻撃者がアクセスを維持しようとする段階
・アカウント操作（T1098）
・アカウントの新規作成（T1136）
・正規アカウントの悪用（T1078）
資格情報へのアクセス：攻撃者が権限昇格や横展開を目的に、認証情報を盗もうとする段階
・パスワードストアからの資格情報取得（T1555）
・保護されていない資格情報の取得（T1552）
・アプリケーションのアクセストークンの窃取（T1528）

そして攻撃者は、以下のような脅威ベクトルを通じてノンヒューマン・アイデンティティ（NHI）を悪用し、アクセスを獲得するとしている。

放置された特権NHI（資格情報のローテーションなし）：
・特権アクセスを持ちながらも、所有者不在や責任の所在不明、資格情報の未更新により放置されたアカウントは、攻撃者にとって格好の標的となる。
退職者に晒された未ローテーションのシークレット：
・退職した従業員が依然としてアクセス可能なシークレットがローテーションされずに残っている場合、特にそれがインターネット上でアクセス可能で特権を持っていると、重大なリスクとなる。
放置されたストレージアカウント
・長期間使用されていないストレージアカウントは、古い設定のまま放置されていることが多く、機密データが不正アクセスや漏洩の危険にさらされる可能性がある。
有効期限が50年以上のアクティブなシークレット：
・極端に長い有効期限を持つシークレットは、攻撃者にとって脆弱性を突くための長期間のチャンスを提供してしまい、セキュリティリスクが高まる。
未使用のアクセスポリシーを含むボールト（保管庫）
・使われていないアクセスポリシーが残されたボールトは、見落とされがちなセキュリティギャップとなり、意図しないアクセス権を通じて機密リソースやデータへの不正アクセスを許す可能性がある。

AIエージェントで複雑化するノンヒューマン・アイデンティティの保護

CSAの「AIエージェント時代におけるノンヒューマン・アイデンティティの保護」（2025年4月29日公開）では、人間1人に対して45のノンヒューマン・アイデンティティが存在しており、AIエージェントの普及によりこの数はさらに増加すると指摘している（関連情報（https://cloudsecurityalliance.org/artifacts/securing-non-human-identities-in-the-age-of-ai-agents-rsac-2025））。

AIエージェントは、サービスアカウント、APIキー、シークレット情報のようなNHIを使ってシステムにアクセスする。これらは組織の機密データや重要なシステムにアクセスするための鍵となるため、攻撃者にとって格好の標的になる。

しかしながら、従来のアイデンティティ・アクセス管理（IAM）は静的なアプリケーションや人間のユーザー向けに設計されており、AIエージェントのような存在には対応しきれない。AIエージェントは、自律的に意思決定を行い、タスクごとに一時的なIDを使い分けて、他のAIエージェントに権限を委譲するといった特徴を持つため、新しいIAMの枠組みが必要となる。

CSAでは、ノンヒューマン・アイデンティティ（NHI）について、以下のようなセキュリティ課題を挙げている。

・NHIに関する可視性の欠如：多くの組織が、どのNHIがどこで使われているかを把握できていない
・アクセス権の過剰付与：最小権限の原則が徹底されていない
・認証情報の管理不備：APIキーやシークレットが適切に保護・ローテーションされていない

これらに対して、以下のような対策を推奨している。

・NHIの発見・分類・監視の自動化
・エージェンティックIAMの導入
・ゼロトラスト原則に基づいたアクセス制御

適切なノンヒューマン・アイデンティティ管理プラットフォームの選び方

AIに代表される新技術の導入とともに、アイデンティティが新たなセキュリティ境界となる中で、人間のアイデンティティだけに注目していたのでは不十分な状況となっている。今や、ノンヒューマン・アイデンティティ管理（NHIM）は、アイデンティティ＆アクセス管理（IAM）における大きな転換点となっている。

非人間エンティティの特有の要件に対応するために、NHIMプラットフォームには以下の基本要件を満たすことが求められる。

包括的かつコンテキストに基づく可視性：
・非人間アイデンティティの全体像を把握することが不可欠である。
・NHIMプラットフォームは、使用状況、依存関係、エコシステム内の関係性を含む包括的な可視性を提供すべきである。
ハイブリッドクラウド全体での対応力：
・NHIMプラットフォームは、従来のインフラの枠を超え、ハイブリッドクラウド環境全体でシームレスに動作する必要がある。
・AWS、Azure、Google Cloudなどの主要なIaaSだけでなく、PaaSやSaaS、オンプレミス環境もカバーすべきである。
アクティブなポスチャー管理：
・脅威が進化する中で、リアルタイムでのセキュリティ状態の評価とリスク軽減のための能動的な対策が不可欠となる。
・NHIMプラットフォームは、これを可能にする機能を備えている必要がある。
ライフサイクル管理と自動化：
・プロビジョニングから資格情報のローテーション、廃止に至るまで、NHIのライフサイクル管理は自動化されるべきである。
・NHIMプラットフォームは、これらのタスクを自動化し、運用効率とセキュリティの両立を実現する機能を提供すべきである。
シークレット管理ツールやPAMとの連携：
・主要なシークレット管理ソリューションと統合できること。
・特権アクセス管理（PAM）ソリューションと連携し、発見されたシークレットを安全に保管・管理できることが求められる。
開発者に優しい設計：
NHIMプラットフォームは、堅牢なAPIを備え、アプリケーションやサービスとの統合が容易であるべきである。
・Infrastructure as Code（IaC）ツール、ITサービス管理（ITSM）システム、ログフレームワーク、開発ツールなど、運用スタックとのシームレスな統合も重要である。

必要なエコシステムとの統合機能や各種機能を備えた堅牢なノンヒューマン・アイデンティティ管理（NHIM）プラットフォームを導入することにより、組織は非人間アイデンティティを効果的に管理し、セキュリティ体制を強化し、自動化やシステム間連携の利点を最大限に活用することができるとしている。

　なお特権アクセス管理（PAM）に関連して、CSAでは、2025年11月24日に「クラウドファースト時代における特権アクセス管理」を公開している（関連情報（https://cloudsecurityalliance.org/artifacts/managing-privileged-access-in-a-cloud-first-world）、日本語版（https://www.cloudsecurityalliance.jp/site/?p=41892））。

OWASP Non-Human Identities Top 10とは？

参考までに、CSAと連携するOWASPでは、「OWASP Non-Human Identities Top 10」を公開している（関連情報（https://cloudsecurityalliance.org/blog/2025/06/30/introducing-the-owasp-nhi-top-10-standardizing-non-human-identity-security））。具体的な10項目は、以下の通りである。

・NHI1:2025 – 不適切なオフボーディング
不適切なオフボーディングとは、サービスアカウントやアクセスキーなどのノンヒューマン・アイデンティティ（NHI）が不要になった際に、適切に無効化または削除されないことを指す。監視されていない、または廃止されたサービスが脆弱なまま残る可能性があり、それに関連するNHIが攻撃者に悪用され、機密性の高いシステムやデータへの不正アクセスにつながるおそれがある。
・NHI2:2025 – シークレット漏えい
シークレット漏えいとは、APIキー、トークン、暗号鍵、証明書などの機密性の高いノンヒューマン・アイデンティティ（NHI）が、ソフトウェア開発ライフサイクル全体を通じて、許可されていないデータストアに漏えいすることを指す。たとえば、ソースコードにハードコーディングされたり、平文の設定ファイルに保存されたり、公的なチャットアプリで送信されたりすると、これらのシークレットは露出しやすくなり、悪意ある第三者に悪用されるリスクが高まる。
・NHI3:2025 – 脆弱なサードパーティNHI
サードパーティのノンヒューマン・アイデンティティ（NHI）とは、統合開発環境（IDE）やその拡張機能、サードパーティのSaaSを通じて、開発ワークフローに広く統合されている。もしサードパーティの拡張機能が、セキュリティの脆弱性や悪意あるアップデートによって侵害された場合、それを悪用して認証情報を盗んだり、付与された権限を不正に使用されたりする可能性がある。
・NHI4:2025 – 安全でない認証
開発者は、内部および外部（サードパーティ）のサービスをアプリケーションに頻繁に統合する。これらのサービスは、システム内のリソースにアクセスするために、認証情報を必要とする。しかし、一部の認証方式はすでに非推奨であったり、既知の攻撃に対して脆弱であったり、古いセキュリティ慣行により安全性が低いと見なされたりしている。安全でない、または時代遅れの認証メカニズムを使用すると、組織は重大なリスクにさらされる可能性がある。
・NHI5:2025 – 過剰な特権を与えられたNHI
アプリケーションの開発や保守の過程で、開発者や管理者がノンヒューマン・アイデンティティ（NHI）に、その機能に必要以上の権限を付与してしまうことがある。こうした過剰な権限を持つNHIが、アプリケーションの脆弱性やマルウェア、その他のセキュリティ侵害によって侵害されると、攻撃者はその過剰な権限を悪用する可能性がある。
・NHI6:2025 – 安全でないクラウド展開構成
CI/CD（継続的インテグレーションおよび継続的デプロイ）アプリケーションは、コードのビルド、テスト、そして本番環境へのデプロイを自動化するために、開発者に広く利用されている。これらの統合には、クラウドサービスとの認証が必要であり、通常は静的な認証情報やOpenID Connect（OIDC）を使用して実現される。静的な認証情報は、コードリポジトリ、ログ、設定ファイルなどを通じて、意図せず漏えいする可能性がある。もしこれらが侵害されると、攻撃者に対して永続的かつ特権的なアクセス権を与えてしまう恐れがある。一方、OIDCはより安全な選択肢であるが、IDトークンが適切に検証されていなかったり、トークンクレームに厳格な条件が設定されていなかったりすると、不正なユーザーがその弱点を突いてアクセスを得る可能性がある。
・NHI7:2025 – 長きにわたるシークレット
長期間有効なシークレットとは、APIキー、トークン、暗号鍵、証明書などの機密性の高いノンヒューマン・アイデンティティ（NHI）が、非常に長い有効期限を持っていたり、まったく期限切れにならないように設定されていたりする状態を指す。こうしたシークレットが漏えいした場合、有効期限が長いために、攻撃者が時間の制限なく機密サービスへアクセスできてしまうリスクがある。
・NHI8:2025 – 環境の分離
環境の分離とは、クラウドアプリケーションのデプロイにおける基本的なセキュリティ対策であり、開発・テスト・ステージング・本番といった環境を分けて運用することを指す。アプリケーションのデプロイプロセスやライフサイクル全体において、ノンヒューマン・アイデンティティ（NHI）が頻繁に使用される。しかし、同じNHIを複数の環境、特にテスト環境と本番環境で使い回すと、重大なセキュリティ脆弱性を招く可能性がある。
・NHI9:2025 – NHIの再利用
同じノンヒューマン・アイデンティティ（NHI）を、異なるアプリケーション、サービス、またはコンポーネント間で使い回すことは、たとえそれらが一緒にデプロイされていたとしても、重大なセキュリティリスクを引き起こす。もしある領域でNHIが侵害された場合、攻撃者はその認証情報を悪用して、同じ資格情報を使用している他のシステム部分にも不正アクセスできてしまう可能性がある。
・NHI10:2025 – 人間におけるNHIの使用
アプリケーションの開発や保守の過程で、開発者や管理者が本来は適切な権限を持つ人間のIDで実行すべき手作業を、ノンヒューマン・アイデンティティ（NHI）を使って行ってしまうことがある。このような運用は、NHIに過剰な権限を与える原因となり、また人間と自動化の活動が区別できなくなることで、監査や責任追跡が困難になるなど、重大なセキュリティリスクを引き起こす。

　今後、「OWASP Non-Human Identities Top 10」に関しては、CI/CDやIaC（Infrastructure as Code）、サードパーティ統合など、クラウドネイティブな開発環境におけるNHIの利用実態に即したベストプラクティスの整備が期待されている。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

SaaSプロバイダに求められるセキュリティ能力を整理/可視化するフレームワーク（SSCF）

コメントをどうぞ

CSAジャパン　クラウドセキュリティ自動化WGメンバー　諸角昌宏

本ブログでは、SaaSプロバイダに求められるセキュリティ能力を整理/可視化するフレームワークとしてCSAが提供しているSaaSセキュリティ能力フレームワーク（SSCF, SaaS Security Capability Framework）について解説する。

SSCFの背景
SSCFが作られた背景として、企業におけるSaaS利用についての以下のような課題が上げられる。
1. SaaS の利用数が急増、多様なSaaSを使う企業が増加
  1社あたりの利用数のデータは把握が難しい（SaaSの定義の違い、シャドーIT・部門契約の影響、頻繁に導入／廃止される）状況ではあるが、様々な調査レポートから判断するとこの傾向がみられる。
2. 誤設定によるインシデントの増大
  CSAが提供しているクラウドコンピューティングに対する重大な脅威2024において、クラウド利用者の「設定ミスと不十分な変更管理」が一番の脅威として上げられている。
3. SaaSプロバイダが提供するセキュリティ機能の差が大きい
  セキュリティに注力できるSaaSプロバイダと、あまり注力できないSaaSプロバイダがいるため、SaaSを利用する企業内でSaaSセキュリティの要求事項を統一することが難しくなっている。
4. SaaSログの標準化の欠如
  SaaSごとにログ形式、ログ項目、イベント名、取得方法がバラバラであり、企業が横断的に監査、検知、可視化を行うことができない。
  
  こうした背景のもと、SaaS利用者が負うセキュリティ責任を統一的かつ実務レベルで遂行できるようにすることを目的として、SSCFが整理・策定された。
SSCFの目的
SSCFの前提として、SaaS利用者が行わなければならないことをまとめてみると以下の2点である。
1. SaaS利用者が直接設定/管理を行わなければならないこと（行うべきこと）
2. SaaS利用者が直接管理できない領域を確認・判断すること（評価すべきこと）
  
  ここで、SSCFは、1のSaaS利用者が「行うべきこと」を対象としている。このSaaS利用者が直接設定/管理を行うにあたっては、SaaS利用者が自ら実施することができる部分と、SaaSプロバイダが提供する機能を使って実施する部分がある。後者のSaaSプロバイダが提供する機能を使用する場合、SaaSプロバイダが十分なセキュリティ機能を提供しないとSaaS利用者は設定を行うことができない。また、部門ごとに利用・管理されるSaaSセキュリティのベースラインを設定しようとすることも難しい。SSCFでは、このSaaSプロバイダがSaaS利用者に対して提供すべきセキュリティ機能を管理策として提供し、SaaS利用者が行うべきことを標準化することができるようにしている。IaaS/PaaSの場合、ほとんどのプロバイダが十分なセキュリティ機能を提供しているのであまり問題とはならないが、SaaSの場合、プロバイダが提供するセキュリティ機能がバラバラのため、SSCFのような管理策が必要とされている。
SSCFとは？
SSCFを一言で言うと、「SaaS利用者がセキュリティ責任を「実行可能」にするための機能要件を提供するもの」である。SaaS利用者が管理/設定しなければならないことを「実行できるようにする」ための機能を、SaaSプロバイダに要求し、標準化していこうという取り組みである。これを簡単な例で挙げると以下のようになる。

SSCFでは、これをcapabilityと表現しているが、これは単に「能力」を意味しているのではなく、「必須となるセキュリティ機能」あるいは「利用者が設定/活用できる状態で提供される機能」と理解すべきである。これにより、SaaSにおける「設定できないリスク」を減らすことができる。その上で、SSCFは、技術的な機能だけでなく以下の3つのポイントにフォーカスしている。
- 設定可能（Configurable）
  SaaS利用者がUI/APIを通じて、セキュリティ上の挙動そのものを変更・強制・制限できる。ただし、SaaSプロバイダの機能の内部実装は操作できない。
  例）MFA:　利用者が有効化・強制できる。また、利用するかどうかの選択が可能である。
- 技術仕様（Technical Dependency）
  SaaS利用者は操作できないが、SaaS利用者のセキュリティ管理（IAM/SOC/監査など）がSaaSプロバイダから提供される仕様などに依存する。
  例）ログの形式：　利用者は変更不可だが、SIEMに統合や監査を行うことができる。ログの取得は設定/構成可能だが、ログの形式は技術仕様となる。
- その他（上記2つのポイントを補足・説明するための文書化/可視化に関する管理策）
  SaaS利用者が設定も操作もできず、SaaS利用者の管理が技術的に依存もしないがSaaSプロバイダが説明/可視化/内部運用として担保すべき事項である。
  例）可視化/通知：情報提供が必要である。
  
  以上のように、SSCFは内部統制のフレームではない。つまり、新たなコンプライアンス要件を求めているわけではない。あくまで、SaaS利用者が設定する、SaaS利用者は操作できないがSaaSプロバイダの機能に依存する、あるいは、SaaS利用者がSaaSの利用の説明目的で使用するのに必要となる管理策集である。
SSCFの６つのカテゴリーの内容
SSCFでは、以下の6つのカテゴリーについて、SaaS利用者が管理/設定しなければならないことを「実行できるようにする」ための機能を記述している。
- CCC（変更管理と構成管理）
  - 定義されている内容
    SaaSのセキュリティ設定が「どのように構成」され、「どのように把握」され、「どのように変更」されるかを、SaaS利用者が管理できる能力を定義している。
  - 管理策のポイント
    SaaS利用者が設定/管理する以下の４つのポイントを記述している。
    - 現状のセキュリティ設定をプログラムで問い合わせることができること
    - 現在の設定状態を可視化できること
    - 設定変更が発生した事実を知ることができること
    - 設定内容を文書化することができること
      
      なお、ここで言う設定には、認証、RBACの割り当て、権限、アクセス許可、リソースACLなどがある。
  - DSP（データセキュリティとプライバシー）
    - 定義されている内容
      SaaS上で扱われるデータに対して、SaaS利用者が最低限のセキュリティ制御を適用できる能力を定義している。
    - 管理策のポイント
      SaaS利用者が不正データ、悪性データの取り扱いをコントロールできること
  - IAM（アイデンティティとアクセス管理）
    - 定義されている内容
      SaaSの利用者/権限/セッションをSaaS利用者が管理できる能力と、その管理が依存する機能/情報をSaaSプロバイダが提供することを定義している。
    - 管理策のポイント
      SaaS利用者が管理できることと、SaaSプロバイダがそのための機能と情報提供を行うこととして、以下の内容を定義している。
      - MFA、SSO、パスワード、セッション管理
      - ユーザー管理/権限管理
      - 認証/認可イベントの可視化
        
        なお、SSOなどは、機能提供を行うことがSaaSプロバイダにとって負担が大きいと考えられる。しかしながら、企業でのSaaS利用を考えた場合、SaaS利用者は数十から週百のSaaSを管理する必要があるので、SSOが必須機能と考える必要がある。
  - IPY（相互運用性と移植容易性）
    - 定義されている内容
      SaaSを他システムと連携あるいはほかのSaaSに移行する際に、SaaS利用者がセキュリティを保ったままコントロールできる能力を定義している。
    - 管理策のポイント
      - データエクスポートのコントロール
      - 外部アプリ/API連携の管理
  - LOG（ログとモニタリング）
    - 定義されている内容
      SaaSの挙動を、SaaS利用者が監査/監視/インシデント対応できる形で記録/取得/理解できる能力を定義している。
    - 管理策のポイント
      - どんなイベントがログに残るか
      - ログの形式と内容
      - 利用者がログを取得、活用する方法
  - SEF（セキュリティインシデント管理、Eディスカバリ、フォレンジック）
    - 定義されている内容
      SaaSでインシデントが起きた際に、SaaS利用者が通知を受け、事実確認や対応判断を行える能力を定義している。
    - 管理策のポイント
      - インシデント通知の方法・タイミング
      - 利用者が設定できる通知先
      - フォレンジック対応に関するSaaSプロバイダのポリシーの明示
SSCFの利用方法
SSCFは、以下のようにSaaSプロバイダ、SaaS利用者、TPRM（サードバーティ・リスク管理）で利用することができる。
- SaaSプロバイダ
  - SSCFに基づいて、SaaS利用者に提供するセキュリティ機能の実装方法の検討/開発を行う。
  - SSCFをセキュリティ機能のベースラインとする。SSCF準拠状況の情報を公開し、SaaS利用者が評価できるようにする。
  - SSCFフレームワークに基づいて評価回答を標準化し、SaaS利用者からの個別のチェックリストの評価に掛かる負担を軽減する。
- SaaS利用者
  - SSCFに基づいて、セキュリティ機能の実装方法の検討/開発を行う。
  - SSCFをSaaS利用者のセキュリティポリシーのベースラインとし、各部門で利用しているSaaSのセキュリティ基準とする。
- TPRM
  - SSCFをSaaSベンダー評価時のセキュリティ機能基準とし、リスク評価と調達プロセスを簡素化する。
SSCFのアーキテクチャ
ここでは、SSCFがカバーしている範囲について考察する。
まず、SSCFはCSAが提供しているCCM（Cloud Controls Matrix）をベースにしている。CCMは、クラウドセキュリティを包括的にカバーする管理策集であり、SSCFがCCMの管理策のどれをカバーしているか、また、どれはカバーされていないかを考えることにより、SSCFの有効性を理解することができる。CCMは以下の図で示すように17個の管理策のカテゴリーがあり、その中でSSCFがカバーしているカテゴリーは赤字で示した6個のカテゴリーである。

SSCFがなぜ6個のカテゴリーをカバーしているかを理解するには、CCMに記述されているセキュリティ責任共有モデル（Shared Security Responsibility Model：SSRM）を理解することが必要である。SSRMは、クラウドサービスプロバイダ（CSP）とクラウドサービス利用者（CSC）の双方が、当事者ごとに管理策の所有と実施責任を理解するのを支援するため、CCMの管理策ごとに記述している。これを、「CSP-Owned（CSPが所有し自ら実施する責任）」、「CSC-Owned（CSCが所有し自ら実施する責任）」、「Shared Independent（CSPとCSCが互いに依存しない形で共有し、それぞれ独立して実施する責任を負う）」、「Shared Dependent（CSPとCSCの両者で互いに依存する形で共有し、それぞれ実施する責任を負う）」の4種類に分類して記述している。なお、SSRMの詳細については、「CCM v4.0実施ガイドラインセキュリティ責任共有モデルによるクラウドの保護」を参照していただきたい。
SSCFは、SaaSプロバイダがSaaS利用者に対して提供すべきセキュリティ機能であるので、基本的に「Shared Dependent」が対象となる。また、機能だけではなく文書化・可視化が必要な部分があるため、一部「Shared Independent」が対象となってくる。ここではこのSSRMとSSCFとの関係について詳しく記述しないが、詳細については本書末尾の「付属A」を参照していただきたい。また、これを解説した資料である「SSCF（SaaSセキュリティ能力フレームワーク）解説　～　SaaSに実装されるべきセキュリティ機能と設定能力」を参照していただきたい。
以上のように、SSRMに基づいてSSCFでは6つのカテゴリーをカバーしている。
SaaS利用者にとってのSSCF利用方法
以上のSSCFの説明に基づいて、実際にSSCFを使ってSaaS利用者が行うことは、「自ら設定すべき管理を確実に実装し、依存せざるを得ない技術仕様を理解/前提化し、それ以外の事項を説明可能にすること」ということになる。したがって、以下の3つのポイントとなる。
- SaaS利用者自らセキュリティ管理を実装、運用する。また、設定を自社セキュリティポリシーに適合し、設定状態を継続的に確認し維持する。
  - MFA 有効化・強制
  - SSO 設定・強制
  - ログ取得の有効化、など
- SaaS利用者は、自ら操作することはできないが、管理の前提として評価を行う。
  - ログ形式/イベント種別、認証/認可イベントの生成、通知方法/タイミングの仕様の確認
  - 自社のSOC、SIEM、監査への組み込み、など
- SaaS利用者は、SaaSプロバイダの内部運用などの情報に基づき文書化する。
  - SaaSプロバイダのセキュリティ設定の内容・挙動・制約を理解し内部文書に反映
  - SaaSプロバイダのログ仕様、ログ品質等を理解し内部文書に反映
  - SaaSプロバイダのフォレンジック支援に関する方針・対応可否を理解し内部文書に反映、など
SaaSプロバイダにとってのSSCF利用方法
SSCFに基づいてSaaSプロバイダがすべきことは、SaaS利用者のセキュリティ管理を可能にするために必要な機能を、設定可能な機能と、依存される技術仕様として提供し、それ以外の責任範囲を明確に説明することである。
- SaaS利用者が、自ら実装できる機能を提供/維持する
  - MFA、SSO機能の提供
  - ログ取得機能の提供、など
- 技術仕様を明確に定義し、情報を提供する
  - ログ形式、イベント種別
  - 認証、認可イベントの生成
  - 通知方法、タイミング、など
- その他の情報提供
  - 設定項目の説明、制約事項の説明
  - 重要な変更の通知
  - インシデント対応方針、など
まとめ
SSCFにより、SaaS利用者が管理/設定しなければならないことを「実行できるようにする」ための機能を、SaaSプロバイダに要求し、標準化していくことが可能になる。特に、企業におけるSaaS利用においては、全社的に利用しているSaaSの設定管理はIT部門が行っているが、個別の部門が利用しているSaaSの設定管理は、SaaSのセキュリティ機能のバリエーションの問題があり、あまり管理できていない。SSCFにより、SaaSのセキュリティ機能の標準化が行われることが非常に重要であると考えられる。SSCFがSaaSプロバイダおよびSaaS利用者に周知され、可能であればSSCFを強制できるような枠組みができていくことが望まれる。本ブログにより、SSCFが広く認識されることを期待したい。
参考資料
SSCFそのもののダウンロードおよびその他の参考情報について、以下に記述する。

付属A　CCMのSSRMの考え方

CSAのCCMで用いられている責任共有モデル（SSRM：Shared Security Responsibility Model）の責任の分類について説明する。その上で、SSRMとSSCFの関係について記述する。

責任共有モデル（SSRM）概要
SSRMでは、CSAが提供するクラウドセキュリティの管理策集であるCCMのそれぞれの管理策に対して、クラウドプロバイダが実施するものとクラウド利用者が実施するものを明確化している。SSRMでは、これを4つの種類（CSP-Owned, CSC-Owned, Shared(Independent), Shared(Dependent)）に分類している。ここでは、この4つの種類の説明とこれらがCSCにとってどのような対応が必要になるかを記述する。なお、ここではSaaSに限定した話ではなく、すべてのクラウドにおいて適用される考え方のため、CSP、CSCという表現にする。
- CSP-Owned
  CSPが所有し、自ら実施する責任。CSPは、CCM管理策の実施に全責任と説明責任を負う。
  CSP-Ownedでは、CSCは、「設定・管理を行わない」が「評価が必要」となる。具体的には、以下のような内容を「評価すること」が含まれる。
  - CSPのインフラ管理（パッチ、ネットワーク、安全性）
  - アプリケーションの管理（脆弱性管理、分離制御）
  - CSP従業員のアクセス管理
  - サービス可用性（冗長化設計、RTO/RPO）
  - 変更管理（仕様変更・API変更・機能廃止）
  - 再委託先（Subprocessor）の情報
  - 法律・規制要件（データの所在値）
- CSC-Owned
  CSCが所有し、自ら実施する責任。CSCは、CCM管理策の実施に全責任と説明責任を負う。
  CSC-Owned は、CSCが、自身ですべて「行うべきこと」となる。具体的には、以下のような内容を「行うこと」が含まれる。
  - アクセス管理（IAM設定・MFA・ロール割当）
  - 利用者アカウントのライフサイクル管理
  - ログの取得・分析
  - データ分類
  - 教育・手順・ポリシー
  - 自社側のインシデント対応
  - クライアント管理
- Shared （Independent)
  Shared （Independent)では、CSPとCSCが互いに依存しない形で共有し、それぞれ独立して実施する責任を負う。つまり、同一目的の管理策を、双方が独立して実装する責任を負う。CSCは、自身の実装とCSPの仕様が整合しているかを「評価すること」が必要となる。具体的には、以下のような「行うこと」と「評価すること」が含まれる。
  - CSCが独立して行うこと（管理を行う）
    - 社内のインシデント対応体制
    - 情報セキュリティ／SaaS 利用ポリシー
    - リスク管理
    - 利用者教育・意識向上
    - 内部ガバナンス
  - CSCが評価すること
    - プロバイダの IR 体制
    - プロバイダのリスク管理プロセス
    - プロバイダのガバナンス枠組み
    - 第三者保証
- Shared （Dependent）
  CSPとCSCの両者で互いに依存する形で共有し、それぞれ実施する責任を負う。CSPの提供機能に依存し、CSCは提供される機能の“有無”で、「行うべきこと」と「評価すべきこと」が分かれる。これは CSP側の提供機能にCSCの実装が依存することになる。具体的には、以下のような「行うこと」と「評価すること」が含まれる。
  - CSCが行うべきこと
    - IAM / 認証
    - ログ運用
    - データ保護（共有範囲・公開設定の管理など）
    - インシデント対応
  - 評価すること
    - IAM / 認証基盤
    - ログ基盤
    - データ保護機構（暗号化等）
    - セキュリティイベント通知

SSCFとSSRMの関係
SSCFの考え方から、以下のように考えられる。
- CSP-Owned
  CSPが所有し、自ら実施する責任。CSPは、CCM管理策の実施に全責任と説明責任を負う。したがって、SSCFでは対象としていない。
- CSC-Owned
  CSCが所有し、自ら実施する責任。CSCは、CCM管理策の実施に全責任と説明責任を負う。したがって、SSCFでは、対象としていない。SSCFは、CSCの活動にCSPの支援・機能が必要となる場合が対象となるためである。
- Shared （Independent)
  CSPとCSCが互いに依存しない形で共有し、それぞれ独立して実施する責任がある。これは、依存はしてしないがCSPの仕様等の説明に基づいてCSCが管理を行う場合に対象となるため、一部対象となる。
- Shared （Dependent）
  CSPとCSCの両者で互いに依存する形で共有し、それぞれ実施する責任を持つ。したがって、基本的にSSCFの対象となる。これは、CSCが実施するにあたってCSPの支援・機能が必要となるためである。

以上

Valid-AI-ted：AIをセキュリティに活用するツール

コメントをどうぞ

CSAジャパン　AIワーキンググループメンバー　諸角昌宏

本ブログは、AIのクラウドセキュリティへの活用としてCSAが提供しているValid-AI-tedについて解説します。このValid-AI-tedツールは、最先端のLLM技術を用いて強化されたAIの革新的な利用方法となります。

Valid-AI-tedとは

Valid-AI-tedは、クラウドサービスプロバイダがクラウドサービスのセキュリティについて自己評価（Self-Assessment）した結果をAIが評価し、合格するとValid-AI-tedバッジが与えられるものです。

CSAでは、以前よりクラウドサービスプロバイダがCAIQ（Consensus Assessment Initiative Questionnaire）を使用して、その評価レポートを公開できるウエブサイトとしてSTAR Registryを提供していました。これにより、クラウドサービス利用者は、利用しようとしているクラウドサービスのセキュリティについて、STAR Registryから該当するクラウドサービスのCAIQ評価レポートをダウンロードし、自らの要求事項を満たしているかどうかを評価することができます。STAR Registryの詳細についてはこちらを参照してください。
Valid-AI-tedの登場により、クラウドサービスプロバイダは、今までは自己評価だけであったものが、AIを活用して評価することとなり、評価の質を高め、信頼性を大きく向上することができます。また、クラウドサービスプロバイダが行う監査の前の自己チェックや改善点の特定に用いることができます。クラウドサービス利用者は、より信頼性の高い評価レポートを入手することができます。

Valid-AI-ted概要

Valid-AI-tedでは、クラウドサービスプロバイダがSTAR Registryに公開しているCAIQ評価レポートをAIが評価し、合格するとValid-AI-tedバッジ（セルフアセスメントがセキュリティベースラインを達成していることを保証）がSTAR Registry上に表示されます。
CAIQでは、クラウドサービスプロバイダが自己評価した結果を記載します（下図の赤丸の部分）が、その中の「CSP Implementation Description」には、その管理策に対する実装・実施方法の説明（逆に、管理策が実装・実施されていない場合にはその理由）が記述されます。Valid-AI-tedは、この「CSP Implementation Description」の内容をAIが評価します。また、Valid-AI-tedは評価するだけではなく、詳細なフィードバックと修正ガイダンスをすぐに提供します。これにより、クラウドサービスプロバイダはどのような追加対策等を取る必要があるかを知ることができます。

また、評価のベースになるのが、CCM（Cloud Controls Matrix）のImplementation Guidelinesになります。CCMは、CSAが提供するクラウドセキュリティ管理策集です。CCMでは、管理策を記述するだけでなく、以下の図で示すような情報を含んでいます。

CCMのEXCELシートのタグにあるImplementation Guidelinesには、管理策の実装方法が書かれており、この内容がValid-AI-tedの評価のベースとなっています。
以上のように、Valid-AI-tedは、既存のCSAのガバナンス・フレームワーク（STAR認証、CCM、CAIQ）をそのまま維持し、その上にAIによる評価を構築したものとなっています。

Valid-AI-tedのメリット

以下の表に、Valid-AI-tedのメリットについてまとめてみました。クラウドサービスプロバイダ（CSP）、クラウドサービス利用者（CSC）、監査者（Auditor）のそれぞれについて、既存のSTAR Level1:セルフアセスメントとValid-AI-tedによる評価を比較しています。今までのセルフアセスメントもメリットがあるのですが、Valid-AI-tedにより、より多くのメリットを享受することができます。

Valid-AI-tedの今後の展開

2025年12月31日時点で、Valid-AI-tedバッジを取得しているクラウドサービスプロバイダは12社あります。その中には、GoogleやMicrosoftなどのメガプロバイダも含まれています。STAR Registryに登録されているクラウドサービスプロバイダは4,000社を超えており、これらが順次Valid-AI-ted対応を進めていくことになることを考えると、Valid-AI-tedが幅広く利用される状況になっていくものと思われます。

また、ここからは個人的な考えになりますが、Valid-AI-tedを現在のCAIQを使った評価だけでなく、様々な標準に対応できたら素晴らしいと考えています。たとえば、日本のISMAPやJC-STARの評価、国際的なISMSの評価、その他様々な監査などです。アーキテクチャ的には可能であると思われます。CSAは、ベンダーニュートラルの組織で、様々なリサーチ活動を行っています。もし、このような取り組みに関心がありましたら、info @ cloudsecurityalliance.jp(アットマークの前後の空白を削除)までメールでご連絡ください。一緒にやりましょう！

その他、関連情報

「Valid-AI-ted Overview」の内容の日本語ブログ
https://cloudsecurityalliance.jp/newblog/2025/06/16/validaited/
Valid-AI-tedの利用方法（英語）については、以下のウエブサイトを参照してください。
https://cloudsecurityalliance.org/artifacts/overview-of-csa-star-level-1-valid-ai-ted
Valid-AI-tedの日本語ウエブサイト
https://www.cloudsecurityalliance.jp/site/?page_id=41724

以上

開発者向けクラウドネイティブセキュリティの基礎（ワークロードセキュリティ編）(1)

コメントをどうぞ

CSAジャパン関西支部では、2024年7月15日にCSA本部が公開した「クラウドコンピューティングのためのセキュリティガイダンス V5」（https://cloudsecurityalliance.org/artifacts/security-guidance-v5）と前後して、クラウドワークロードセキュリティおよびアプリケーションセキュリティの観点から、以下のようなブログを展開してきた。

・コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (前編)（2024年6月25日）https://cloudsecurityalliance.jp/newblog/2024/06/25/devsecops_3/
・コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (後編)（2024年7月16日）https://cloudsecurityalliance.jp/newblog/2024/07/16/devsecops_4/
・コンテナ／マイクロサービス／サーバーレスセキュリティと自動化／AI(技術編)(前編)（2024年8月13日）https://cloudsecurityalliance.jp/newblog/2024/08/13/cloud_workload/
・コンテナ／マイクロサービス／サーバーレスセキュリティと自動化／AI(技術編)(前編)（2024年9月8日）https://cloudsecurityalliance.jp/newblog/2024/09/08/ssdlc/

今回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「MLOps」に焦点を当てながら、AIワークロードセキュティの動向をみていく。

膨大な量の学習用データを処理するAIワークロードとリスク低減策

前述の「クラウドコンピューティングのためのセキュリティガイダンス V5」のうち、「ドメイン8: クラウドワークロードセキュリティ」の「8.6 AIワークロード」では、AIワークロードについて、AI機能の構築、提供、または利用に関わるタスク、プロセス、あるいはオペレーションを指すとしている。AIワークロードは、ユーザー行動に基づく製品の推奨から、車両の自律的な操縦に至るまで、非常に幅広い複雑性と応用分野を包含しているのが特徴である。

AIワークロードは、モデルのトレーニングに大量のデータセットを必要とし、効率化のためにGPU（グラフィックス処理ユニット）やTPU（テンソル処理ユニット）などの専用ハードウェアを活用するなど、かなりの処理能力を要求する。さらに、これらのワークロードは、需要の変動に対応するために動的にスケールする必要があり、クラウド環境によって提供される柔軟なコンピューティングリソースが重要になる。AIワークロードへの取り組みは、単に計算能力を活用することだけではなく、様々な分野でイノベーションと価値を解き放つために、データ、アルゴリズム、リアルタイム処理の複雑な要素を乗りこなすことでもあるとしている。

　CSAガイダンスV5では、AIワークロードセキュリティにおけるリスク低減策として、以下のような点を挙げている。

・データセキュリティ：データを保護するために、暗号化、差分プライバシー、セキュアなマルチパーティ計算を利用する
・モデルセキュリティ：敵対的な攻撃に対してモデルをハードニングし、堅牢なトレーニング手法を利用し、盗難防止のために固有識別子を組み込む
・インフラストラクチャセキュリティ：割当・レート制限を実装し、クラウドサービスに関するベストプラクティスをフォローする
・サプライチェーンセキュリティ：サイバーセキュリティポリシーを定義し、定期的にサードパーティの依存性を監査し、信頼されたリソースを利用する

CSA DevSecOps WG が「MLOpsの概要」を公開

CSA DevSecOps WGは、2025年8月27日に「MLOpsの概要」（https://cloudsecurityalliance.org/artifacts/machine-learning-ops-overview）を公開している。

機械学習(ML)は、ますます企業の中核的な業務機能と結びつくようになっており、それに伴いMLパイプラインのセキュリティ確保が不可欠となっている。そこで本書では、MLSecOps（Machine Learning Security Operations）の概念を紹介し、ML資産を保護する上で特有の課題や、従来のセキュリティ対策がMLシステムに対する新たな脅威に対して十分に機能しない理由について説明することを目的としている。

・謝辞
・目次
・はじめに
・目標.
・対象読者
・エグゼクティブサマリー（概要）
・MLOpsとは？
・LLMOps vs. AgentOps vs. 従来型MLOpsの融合
・MLOpsのステークホルダー
－データサイエンティスト
－機械学習エンジニア
－運用チーム
－プラットフォームチーム
―セキュリティチーム／セキュリティエンジニア.
―プライバシーチーム
―データおよびコンプライアンスチーム
―Cレベル職／経営層.
―プロジェクト／プロダクトチーム
―顧客
・MLOpsの各ステージ
―設計ステージ
―モデル開発ステージ
―運用ステージ
―継続的フィードバックステージ
・MLOpsの課題
・結論

ここ数年で、従来のMLOpsの概念は、古典的な機械学習モデルを運用化するための一連のプラクティスやワークフローとして業界内で発展してきた。しかし、近年の大規模言語モデル（LLM）およびLLMを活用したAIエージェントの進化に伴い、これらの技術を運用化する際に特有の課題に対応するための新たなプラクティスやワークフローを表す用語として、「LLMOps」や「AgentOps」といった言葉が業界で使われるようになっている。LLMは、従来の機械学習モデルと比べてはるかに高い計算複雑性を持ち、専門的なインフラや最適化技術が必要とされる。LLMOpsは、こうしたLLMモデルを本番環境で学習・デプロイ・管理するために進化してきたものである。

本書では、MLOps(機械学習運用)、LLMOps(大規模言語モデル運用)、AgentOps(エージェント運用)の特徴を以下のように整理している。

【MLOps（機械学習運用）】
・対象範囲：一般的な機械学習モデル（分類、回帰、強化学習など）
・モデルサイズ：通常は数MB〜数GBの小〜中規模モデル
・データ要件：構造化データ／表形式データ、画像、時系列、小規模なテキストデータセット
・学習プロセス：モデルはゼロから学習されるか、小規模なデータセットでファインチューニングされる
・インフラ要件：従来型のMLモデルは、スケーラビリティとクラウドネイティブ環境に重点を置いた中程度のインフラを必要とする
・モデルのデプロイ：モデルは通常コンテナ化され、DockerやKubernetesなどのプラットフォーム、および自動化されたCI/CDパイプラインを用いて継続的にデリバリーされる
・推論：予測モデルはREST APIとしてデプロイされるか、アプリケーションに組み込まれる
・モニタリングと可観測性：モニタリングはモデルの性能、レイテンシ、ドリフト検出、精度に焦点を当てる。PrometheusやGrafanaなどの可観測性ツールが一般的
・バージョン管理：モデルのバージョン、特徴量、ハイパーパラメータを追跡
・ガバナンスとコンプライアンス：ガバナンスはデータプライバシー、規制遵守（例：GDPR、CCPA）、モデルおよびデータへの安全なアクセスに重点を置く
・最適化手法：従来型のML最適化（例：ハイパーパラメータチューニング、特徴量エンジニアリング）
・ライフスパンと更新：モデルは新しいデータセットや変化するトレンドに応じて頻繁な更新と再学習が必要

【LLMOps(大規模言語モデル運用)】
・対象範囲：大規模言語モデル（LLM）に特化しており、ファインチューニング、推論、プロンプトエンジニアリングを含む
・モデルサイズ：数百億〜数千億パラメータ規模の大規模モデル
・データ要件：学習・ファインチューニング・継続学習のための膨大な非構造化テキストデータや埋め込みベクトル
・学習プロセス：事前学習済みモデル（例：OpenAIのChatGPT、MetaのLLaMA）をファインチューニングするか、プロンプトベースで適応させる手法が一般的
・インフラ要件：LLMは大規模なインフラ資源を必要とし、分散コンピューティング、高性能GPU/TPU、大規模データセットや並列学習に対応する高度なストレージソリューションが求められる
・モデルのデプロイ：推論効率を高めるために、量子化、モデル分割、知識蒸留などの最適化技術が用いられることがある。また、エッジAIやハイブリッドクラウドでの展開も行われる
・推論：プロンプトベースの推論、リアルタイムのテキスト生成、チャット型インターフェースなど
・モニタリングと可観測性：言語生成の品質、応答時間、モデルの倫理的側面（例：バイアス、不適切な応答、幻覚、攻撃的表現など）の監視が追加で求められる
・バージョン管理：プロンプト、モデルのチェックポイント、ファインチューニングされたバリアントのバージョン管理を含む
・ガバナンスとコンプライアンス：責任あるAIの実践、大規模モデルにおける知的財産の管理、生成AIシステムに対する倫理的ガイドラインの遵守に強く焦点を当てる

【AgentOps(エージェント運用)】
・対象範囲：ユーザー、ツール、環境と対話する自律型AIエージェントの管理、およびマルチステップ推論、記憶、ツール使用のオーケストレーション
・モデルタイプ：計画・推論・ツール使用が可能な動的かつ対話型のエージェント
・デプロイ： API、データベース、ユーザーとやり取りするサービスとしてエージェントをデプロイ
・推論：マルチステップ推論、反復的な意思決定、ツールの活用
・モニタリングと可観測性：エージェントの推論の正確性、ハルシネーションの検出、状態の追跡
・バージョン管理：エージェントのプロンプト、推論ログ、記憶状態、ツール統合の履歴を追跡
・最適化手法：エージェントの記憶のファインチューニング、推論ステップの改善、ツール使用の最適化

MLOpsを取り巻く多様なステークホルダーの存在

業界では現在、MLOps、LLMOps、AgentOpsといった用語を区別して使う傾向があるが、CSAとしては、これらの用語は最終的に統合されるべきであり、「MLOps」という用語が、機械学習に関連するすべての運用プラクティス、ワークフロー、技術アーキテクチャを包括するべきだと考えている。

定義上、機械学習の世界は、あらゆる学習手法とモデリングアーキテクチャを含む上位概念（スーパーセット）であり、現在LLMが使用しているトランスフォーマーのような手法、畳み込みニューラルネットワーク（CNN）、再帰型ニューラルネットワーク（RNN）、長短期記憶（LSTM）といった他の生成系AIの学習技術、さらにはサポートベクターマシン（SVM）、回帰モデル、人工ニューラルネットワーク（ANN）などのより古典的な機械学習手法もすべて含まれる。従って、本書においては、「MLOps」という用語を業界標準とは異なる意味で使用しており、LLMOpsやAgentOpsをも内包する広義の概念として扱っている。

MLOpsは、機械学習モデルの調査、データ収集、トレーニング、開発に多くの時間が費やされるため、従来のDevOpsと比べてややアジャイル性が低い傾向がある。MLOpsのプラクティスを導入することによって、機械学習モデルのライフサイクルに自動化を取り入れることが可能になる。MLOpsのパイプラインには複数の重要なステークホルダーが関与しており、それぞれが異なる役割を担いながら、機械学習と運用の橋渡しを行い、MLOpsを実現している。

　本書では、以下の通り、10の重要なステークホルダーを挙げている。

・データサイエンティスト：
データサイエンティストは、機械学習モデルを作成・学習させるためのアルゴリズムやデータを含む、モデルエンジニアリングのパイプラインを管理することが多い。彼らの役割には、モデルの作成、トレーニング、評価、テスト、パッケージ化などが含まれる。ただし、データサイエンティストは、実運用に耐えるソフトウェアサービスを構築する熟練のソフトウェアエンジニアであるとは限らない。

・機械学習エンジニア：
機械学習エンジニアは、データサイエンスチームから引き渡されたモデルを、呼び出し可能なアーティファクト（例：API統合）へと変換する役割を担うことが多い。大規模な機械学習モデルのトレーニング、モデルの保存、コードリポジトリやモデルレジストリへのアップロード、モデルのデプロイと利用可能な状態への展開、さらにスケーラブルな推論パイプラインやアプリケーションの構築などが、機械学習エンジニアの主な業務である。

・オペレーションチーム：
オペレーションチームは、継続的インテグレーション（CI）および継続的デリバリー（CD）のパイプラインを管理する。機械学習のデプロイメントにおいては、データ、モデル、トレーニング成果物といった複数のワークフローに対応する必要があるため、従来のソフトウェアのCI/CDフロー（例：開発 → QA → 本番）よりもパイプラインが複雑になる。モデルは頻繁に更新されるのではなく、全体として繰り返しリリースされる傾向があるため、データ用のパイプラインとモデル用のパイプラインが分かれて存在することが一般的である。

・プラットフォームチーム：
プラットフォームチームは、インフラの管理、自動化、スケーラビリティ、システムの監視を担当する。機械学習の文脈においては、MLモデルを迅速かつ信頼性高くスケーラブルにデプロイするためのフレームワークを設計・維持する上で、非常に重要な役割を果たす。

・セキュリティチーム／セキュリティエンジニア：
セキュリティチームは、MLOpsライフサイクル全体において、セキュリティ対策が設計段階から統合されていることを確保するという重要な役割を担う。このチームは、機械学習システムの脅威モデリングの実施、データおよびモデルにおける潜在的な脆弱性の特定、セキュリティガードレールの実装、セキュリティインシデントの監視、セキュリティポリシーや標準への準拠の確保などを担当する。

・プライバシーチーム：
MLOpsライフサイクルにおいて、プライバシーチームは、モデルの開発やトレーニングに使用されるデータが、適用されるプライバシー規制および組織の基準に準拠していることを確保する責任を担う。このチームは、データ最小化の原則の適用、個人識別可能情報（PII）の特定、そしてデータの匿名化、仮名化、差分プライバシーといった技術の導入を通じて、ユーザーデータの保護を行う。プライバシーチームは、MLOpsライフサイクル全体にわたってプライバシーの観点が組み込まれるようにし、倫理的なAIの実践と規制遵守の両方を支援する。

・データ／コンプライアンスチーム：
データ／コンプライアンスチームは、データライフサイクルの管理を担い、機械学習モデルが高品質で関連性があり、偏りのないデータでトレーニングされることを確保する責任がある。これには、さまざまなソースからの新たなデータの導入や収集、データ管理、分析、データセキュリティなどが含まれる。MLOpsパイプラインにおいては、データセキュリティが最重要事項の一つであり、コンプライアンスチームは機密情報を保護・管理するための対策を講じる必要がある。

・Cレベル職／経営層：
経営層やCレベルのチームは、社内プロセスの最適化や顧客向けビジネスの強化を目的として、機械学習の導入に関心を持っている。このチームは、MLOpsによって実現される開発期間の短縮、モデルの信頼性や最新性の確保、コストや稼働率の要件への適合、そしてビジネスの主要業績評価指標（KPI）や各種メトリクスに対する大きなインパクトに注目している。

・プロジェクト／プロダクトチーム：
プロダクトチームは、機械学習プロダクトのビジョンを導くうえで不可欠な存在であり、しばしばMLのユースケースの優先順位付けを担当する。一方、プロジェクトチームは、そのプロダクトビジョンを実現し、目標期日までに成果を届けるための推進役として重要な役割を果たす。

・顧客：
顧客は、自身のデータがMLOpsパイプラインにおいてどのように活用されているかに関心を持っている。具体的には、自分のデータがモデルのトレーニングに使用されているかどうか、機密データが適切に保護されており、マルチテナント環境で他の利用者に漏洩しないこと、退会後にデータが適切に削除され、機械学習モデルに機密情報が残らないことなどを気にしている。また、機械学習モデルの信頼性や説明可能性についても高い関心を持っている。

MLOpsパイプラインにおけるセキュリティ部門の役割とは？

次に本書では、以下の通り、MLOpsパイプラインの4つのステージを紹介し、各ステージにおける主要なステークホルダーとの関係を説明している。

1.設計ステージ：
・要求事項の収集、設計、計画策定
（ステークホルダー）経営層／リーダーシップ、製品／プロジェクトチーム、データサイエンティスト、機械学習エンジニア、セキュリティエンジニア

2.モデル開発ステージ：
・データ準備／モデルのためのデータ収集
（ステークホルダー）データ／コンプライアンスチーム、プライバシーチーム、データサイエンティスト、機械学習エンジニア
・モデル検証とテスト
（ステークホルダー）データサイエンティスト

運用ステージ：
・モデルトレーニング
（ステークホルダー）機械学習エンジニア、データサイエンティスト
・デプロイ
（ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム
・モニタリング
（ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム、サイト信頼性エンジニア

4.継続的なフィードバックステージ
・モデルの結果の利用
（ステークホルダー）下流アプリケーション、内部ステークホルダー、外部顧客
・新たなモデルのアップデート
（ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム

早期からDevSecOpsの導入に取り組んできたユーザー企業をみると、既存のオンプレミス環境をベースとするレガシーなエンタープライズシステム体制の改革からスタートし、クラウド環境への移行を図ってきたケースが多い。これに対してMLOpsの場合、DevOpsやDevSecOpsの原則やプラクティスを拡張し、機械学習（ML）のライフサイクルに適用することを目指すが、前述のステークホルダーの顔ぶれを見てもわかるように、組織の開発部門（Dev）や運用部門（Ops）、情報セキュリティ部門（Sec）だけでなく、社内のCレベル職／経営層やユーザー部門、組織外にある外部委託先／パートナー、顧客など、多様なステークホルダーとのコミュニケーションを行いながら、プロジェクトを進めることが必要になる。

その一方でMLOpsは、人間による操作を最小限に抑え、エンドツーエンドの自動化を実現するために、AIワークロードを実行する「非人間アイデンティティ（NHI: Non-Human Identity）」を活用しており、従来とは異なる認証／認可管理やアクセス制御ポリシーの策定が不可欠になってくる。参考までにCSAでは、2024年9月11日に「ノンヒューマンアイデンティティ・セキュリティの状況」（https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report）を公開している。

このようなMLOps固有のセキュリティ対策が設計段階から組み込まれるよう確保することが、今後、セキュリティチーム／セキュリティエンジニアの重要な役割となってくる。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

SaaSセキュリティの設定問題と、SaaSセキュリティ能力フレームワーク(SSCF)の有効性

コメントをどうぞ

第２回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第2回会議の内容をまとめて公開する。

2025年11月10日　18:30-20:00　開催

テーマ：SaaSセキュリティの設定問題と、SaaSセキュリティ能力フレームワーク(SSCF)の有効性

ディスカッション内容

SaaS利用者が実際に手を動かさなければならないこと（アイデンティティとアクセス管理、インシデント対応、ログ管理、データ保護等）の現状。どこまでできている/できていない点、課題。
- 全社的に設定管理するものに関してはIT部門が管理している。SaaSが提供しているセキュリティ機能についても確認できていて、それに基づいて管理している。一方、個別部門が設定管理を行っているものについては、SaaSのバリエーションの問題がありあまり管理できていない。また、小さいSaaSについては統一的な管理ができていない。
- 最初に、SaaS側のセキュリティ機能（ログを取っているか、ID/アクセス管理など）の確認を行っている。それに基づいて、設定管理を行っている。
- 利用の申請、また、どのように使っているか、SaaSサービスがどうなっているかを確認している。その上で、実装をどうするかを決めていく。利用者側の設定はバリエーションが出てしまう。難しいガイドラインを作っても部門が対応できない（知識がない）ケースもある。
- SaaSはロングテールになる傾向がある。O365のような主要なSaaSは情シスが面倒を見ている。それに対して、ロングテールとなる小さいところは、仕様変更に対して追従できているかも不明なところがある。また、SaaSそのものがそもそもセキュリティ機能を満たしていないところも多い。したがって、SaaSのセキュリティ管理を一律に制限することはできない。
- リスクの大きくないサービスに対してはあまり関わらないし、関わる時間もない。CASBの評価で一定の基準を満たしていれば設定はあまり気にしていない。
  
  まとめると、SaaS側が提供するセキュリティ機能のバリエーションの問題、部門のセキュリティ管理者へのSaaSセキュリティの徹底はなかなか難しい問題であることが分かる。
SaaSプロバイダはどこまで支援してくれているか。あるいは、機能提供しているか？
- SaaS利用前に、SaaSプロバイダにチェックリストに回答してもらう。セキュリティチェックシートを満たさないと契約できないようにしている。Webフィルタリング機能で、契約していないSaaSは使えないようにしている。
- チェックシートに回答がもらえないSaaSがある。また、チェックシートだけでは管理しきれないSaaSもある。
  
  SaaSプロバイダが提供しているセキュリティ機能がなかなか把握できず、SaaS利用者にはチェックリスト等による対応が求められているのが分かる。
利用しているSaaSはセキュリティ機能を持っているが、利用者側で正しく設定できていないケースはあるのか？
- SaaS利用担当者に、以下の項目を実施することを指示。これにより、設定問題をできるだけ回避するようにしている。
  - ユーザーアカウントの登録、変更、削除、パスワード初期化
  - 利用マニュアルの整備、利用方法の指導、利用者に対するヘルプデスク
  - クラウドサービスに設定するデータの定期的なバックアップ
  - インシデント発生時の連絡調整、迂回処理等の検討・実施
  - クラウドサービスでの処理量の増減に応じたサービス利用量の調整
- 利用者側の設定については、基本的には、監査とかで対応している。
- 当初は正しい設定をしていても、今までの設定では不十分になるケースがある。
- 他社で事故が発生した場合に、自社の設定問題が表面化するケースもある。
  
  上記1,2の状況を受けて、SaaS利用者側のセキュリティ設定を徹底する方法として、定期的な監査で設定問題を回避するというのが、現状取られている方法と考えられる。
SSCFの有効性について

ここで、CSAが最近公開した「SaaSセキュリティ能力フレームワーク（SSCF）」について、実際にSaaSセキュリティを担当している管理者の意見を出していただいた。
まず、SSCFであるが、SaaSプロバイダが利用者に提供するセキュリティ機能をまとめた管理策集である。すべてのSaaSプラットフォームで利用可能な標準化されたセキュリティ機能を確立することを目的としている。
- SSCFの資料
  SSCFの解説として提供されている情報（日本語）を以下に示す。本ブログでは、SSCFの詳細は記述しないので、これらの資料を参照していただきたい。
- SSCFで提供されている管理策の有効性についての意見
  - SaaSプロバイダが、SSCFに基づいて実装してくれると助かる。たとえば、SSOしてくれるだけでもうれしいし、ログがAPIで提供されるだけでも助かる。
  - SSCFにより、共通言語化されるだけでも良い。どの機能が揃っているというのが分かるし、同じ土俵で会話できるのはありがたい。
  - ベンダー向けのチェックリストの中で、聞かなくても良い項目が出てくるので楽になる可能性がある。
  - 自動化対応とかは日本のSaaSベンダーはあまりできていない。フレームワークとしてできるようになれば良い。SIEM連携とか、メリットがある。
  - SSCFを、どのように強制できるかが課題である。SSCFの名前がインパクトがない。もっとSaaSでは絶対必要だというような名前にすべきである。「能力フレームワーク」というのが分かりにくい。SSCFをもっと知らしめてほしい。
    
    総じてSSCFについて好意的な意見をいただいた。今まで、SSCFのようなまとまった形でSaaSセキュリティ機能を記述している資料がなかったため、これがSaaSセキュリティのバリエーションを生んでおり、設定および設定管理の難しさをもたらしていた。SaaSセキュリティ機能をプロバイダと利用者で標準化できれば、双方にとって有効であることが分かった。
その他
今回の議論の内容ではなかったが、他社が使っているSaaSを利用する場合、直接そのSaaSの管理ができない（たとえば、他社がBOXを使っていて、そのBOXを共有するケース）という問題が提起された。これは、SaaSに対してチェックリストを出すことができない。このような場合に、セキュリティ対応はどうしたらよいのかが課題となる。
まとめ
- SaaS利用者設定の課題について、全社的に設定管理するものに関してはIT部門が管理できている。一方、個別部門が設定管理を行っているものについては、SaaSのバリエーションの問題がありあまり管理できていない。
- 利用者側の設定の状況については、基本的に、監査で対応している。
- SaaSプロバイダが提供しているセキュリティ機能については、セキュリティチェックリストを送付し、SaaS利用前に回答してもらう方法が取られている。また、セキュリティチェックシートを満たさないと契約できないようにしている。ただし、チェックシートに回答がもらえないSaaSもあり、課題はある。
- SSCFにより、SaaSのセキュリティ機能の標準化ができるようになると非常に有効である。しかしながら、どのように強制できるかが今後の課題となる。

以上

SaaS上の機密データの不十分な可視性と脆弱なアクセス制御のリスクと対応

コメントをどうぞ

第一回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第一回会議の内容をまとめて公開する。

2025年10月14日　18:30-20:00　開催

テーマ：SaaS上の機密データの不十分な可視性と脆弱なアクセス制御のリスクと対応

問題点の概要（引用：「SaaSセキュリティの現状レポート2025年～2026年の動向と洞察」）
- 企業の63%は機微データや機密データの外部への過剰な共有を最大のリスクとして挙げており、56%は従業員が機微データを未認可なSaaSアプリケーションにアップロードしていると報告している。
- このようなリスクの主な要因は、効果的でない特権とアクセス管理の実践であり、組織の41%が最小特権アクセスポリシーが効果的に実施されていないと報告している。つまり、ユーザーやシステムが過剰な権限を保持することが多く、データ漏えいや権限の乱用、内部脅威のリスクが高まっている。
- 人間のアイデンティティに限ったことではなく、生成AIの統合は、新たな複雑性のレイヤーを導入しており、多くの場合、タスクを実行するために、複数のアプリケーションにわたる機密データへの広範なアクセスを必要とする。組織の56%は、サードパーティベンダーやAIを搭載したSaaSツールが、データへの過剰なAPIアクセスを獲得することを懸念している。
- SaaS のデータフローが一元的に可視化されておらず、SaaS 間の統合が監視されていない。企業の 42% が SaaS アプリケーション全体の機微データの追跡と監視に苦慮している。
ディスカッションのポイント
- SaaSアプリケーション上のアクセス設定が徹底できていない
- 最小特権アクセスポリシーが効果的に実施されていない
- サードパーティベンダーやAIを搭載したSaaSツールに対する過剰なAPIアクセスとなっている
- SaaS アプリケーション全体の機微データの追跡と監視が不足している

以下、ディスカッション内容をまとめる。

SaaS上の機密データの取り扱い
- セキュリティ対策を考える前に、対象となるSaaSを明確化
  以下にリストしたように組織ごとに様々なSaaSの位置づけがあるが、一概にこれというものではないことが分かった。しかしながら、組織として対象となるSaaSを明確にすることは、具体的なセキュリティの問題の洗い出し・対策を取っていく上で重要である。
  - 社内の情報を預けるもの、IDのあるものをSaaS/クラウドと定義
  - データの持ち出しを念頭に置いて判断
  - 業務で使うものという括りで判断
  - 有償契約のあるクラウドを管理対象（ただし、無料であっても企業で使うケースもある）
- 機密データをSaaSに上げることに対する管理の現状
  機密レベルに応じてSaaS/クラウド（ここでは、SaaSだけでなくクラウドとして捉えることが必要）に上げることができるデータとして、どのような基準を設けているかという問題に対して、以下のような意見が出された。
  - 機密データをクラウドに上げることは（極秘であっても）特に妨げてはいないが、機密レベルに応じて承認するかどうかを決めている。機密データの管理については、CASBのスコアベースで評価し、PaloAltoで止めるという方法を取っている。結果、リスクスコアが高いものはクラウドにアップロードできない。
    CASBのリスクスコアによる管理を行っている理由は、単純な仕組みで無いと従業員がついてこれないためである。
  - チェックリストに基づいて許可するかどうかを判断している。まずAssuredで評価し、それから独自のチェックリストに基づいて評価し許可を出している。技術的には、Zscalerのサービスでアクセス制御し、Web Filteringで制御している。
  - データ区分を設定して、データの重要度に応じてアクセスを制限している。IPアドレス等により、アクセスできる拠点、人等を管理する方法をとっている。
  - 使用できるSaaSを限定し、申請に基づいて評価している。技術的な管理は、SASEおよびCASBで実施している。
    
    各組織とも、SaaS/クラウドにアップできるデータに対する基準やチェックリストを設けて管理している。技術的には、CASBで管理し、その他の製品を使って制御していることが多い。チェックの仕方が煩雑だとうまく運用できない、特に部門主導のSaaSにおいては管理が難しいということもあり、できるだけシンプルな管理方法を取っている。
- クラウド上の機密データの管理（過剰な外部との共有になっていないか？）
  機密データの外部への過剰な共有による情報漏洩が大きなリスクであることが言われているが、実際どのような状況なのか、また、どのように管理しているかについて、以下のような意見であった。
  - 部署の使い方（外部のゲストユーザの状況、退職者管理等）を、あらかじめ作成したチェック項目に基づいて管理している。また、棚卸、監査のタイミングで再チェックし、是正処置を実施している。
  - O365は外部と共有できないようにしている。BOXは共有に使っているが、ログを監査し対処している。
  - 外部だけでなく社内にオープンにされているケースが多いのも問題である。グループ内に閉じておかなければならない情報が共有できてしまっている（人事情報、パスワードなど）。たとえば、Sharepointが誰でも見れる状況になっていたりする。これは、AIの利用によりさらに問題となってきており、本来共有できない情報をAIが取り込んでしまう問題がある。
    
    以上のように、この問題に対しては基本的に管理的な対策に頼らざるを得ない状況のようである。しっかりした管理と定期的な監査・是正が求められる。
- 最小権限アクセスポリシーが効果的に実施されていない
  これは、SaaS/クラウドに限らずオンプレでも同様であるが、ここでは、SaaSに限定して意見を出していただいた。
  - SaaSに対しては効果的な実施方法は無いのが実情である。オンプレであれば専門家が権限付与する時に申請ベースで動くことができ、過剰権限があれば運用において管理できる。
  - クラウドの場合、ツールの利用が必要である。SSPMであれば、過剰権限、SaaSに対する設定の確認、外部に公開されているリンクの検知などを行うことができる。SSPMによる可視化（公開設定管理など）もまた有効である。ただし、利用はまだ一部にとどまっている状況である。
  - アクセス権の付け間違いはどうしても発生する。データの管理者（SaaSの場合、特に部門）がそもそも理解できていないのが問題となるケースが多い。データをアップロードする人が一般事務の人だったりして、オンプレの慣習通りにアップロードしてしまい、クラウドにおいて問題となる。ITの専門家がいない部署が運営していて、設定がちゃんとしてない可能性があり、セキュリティ部門ではきちんとできているかを管理しきれない。
  - ツールの利用が考えられる。脅威インテリジェンス、アタックサーフェス用のツールで、公開されている情報を検知することが可能である。Avepointのようなツールが出てきており、うまく使うと有効であるという話もある。
  - ポリシーの教育は必須である。各拠点の担当者、エンドの利用者向けの教育を行っている。
    
    以上のように、効果的な管理は難しい状況ではあるが、SSPMやその他のツールを利用した技術的対策が有効であるので、検討していただくことが良いかと思われる。
- 他社との共有リスク
  調査レポートの課題としては上げられてはいないが、クラウドストレージ等を使って他社と情報共有していることも問題になる場合がある。他社との共有は、会社間での情報のやり取りを行う場合、セキュリティ的にも有効な手段であるが、反面、利用者が誤って機密データを上げてしまい、それが他社と共有されてしまうという問題がある。この問題に対して現在取られている対策は以下である。
  - 外部の委託業者との共有、他社のBOX等の共有を使うケースは、基本禁止している。対策としては、管理を厳しく行っている。
  - この課題は、CASBで管理できる（他社と共有してはいけない機密情報をクラウドに上げるのを制限する）が、自社が管理している共有サイトは管理できるが、他社が管理しているサイトだと難しい。
    
    この問題は、クラウドストレージの利用が禁止される典型的な例であり、なかなか管理が難しい。引き続き、検討が必要なものと考えられる。
その他
以上の議論とともに、以下の3点についても検討が必要であるとの意見があった。
- データセキュリティの観点
  - データの機密性を従業員が適切に判断するのが難しいケースが多い。そのため、社内ポータルに上げてはいけない極秘データを簡単においてしまったりするケースがある。機密区分を人に頼るのではなくAIによって自動的に判定するようなことができるとこのような問題は少なくなるかと思われる。
  - DLPで制御させるためのタグ付けに対して限界を感じている人が多く、もっと踏み込んだ対策が求められている。DSPMには「AIによるファイルの機密区分の判定」などの機能があり、これが有効なツールとなる可能性がある。
- Need-to-knowが分かる、あるいは、理解できる仕組み
  - 読みたい人がアクセス権を要求できる仕組みの方が良いのかもしれない。現状は、データオーナーの責任においてアクセスできる人を決めているが、これを読むべき人が自動的にNeed-To-Knowになるような仕組みができると良いかと思われる。
  - Need-to-knowを徹底できる仕組みとしてワークフロー化する方法では、共有グループのアクセス権の設定に対して承認を行うプロセスを作ることができる。
- ブラウザのロギングの強化
  - ブラウザのロギングがしっかりしていれば管理しやすくなると思われる。独自のアプリ以外はブラウザ経由なので、しっかりしたログを出してほしい。これができると、ログ分析する時に非常に有効になると思われる。現状は、アクセスログぐらいしか出されていない。
まとめ
今回のSaaSセキュリティリーグでの議論を以下の2点にまとめる。
- SaaS上の機密データの取り扱いの問題は、管理的対策と技術的対策をうまくミックスさせて行うことが必要と思われる。チェックリスト等の整備、定期的な見直しとしての監査/是正を愚直に進めることが必要になる。CASB等のツールによる技術的対策は、管理的対策を補完する形で有効に利用できると思われる。
- 最小権限アクセスポリシーが効果的に実施されていない問題は、ツールの利用が有効である。また、ポリシーの徹底のための教育は継続してきちんと行っていくことが求められる。

以上

海外に学ぶSMBのクラウドセキュリティ基礎（OTセキュリティ編）(2)

コメントをどうぞ

海外に学ぶSMBのクラウドセキュリティ基礎（OTセキュリティ編）(1)に引き続き、今回は、シンガポールサイバーセキュリティ庁の大企業・クラウドサービスプロバイダーを対象とするサイバートラストに基づいて開発されたOTセキュリティ固有のガイドを紹介していく。

シンガポール政府が大企業／CSP向けOTセキュリティガイドラインを提供

シンガポールサイバーセキュリティ庁のサイバートラストマークとCSA STAR認証との間には、相互承認制度（MRA：Mutual Recognition Agreement）が確立されている。サイバートラストマークの各管理策項目に対応するCCM v4の管理策項目については、「CSA サイバートラストとクラウドセキュリティアライアンス・クラウドコントロールマトリクスv4のクロスマッピング」で公開されている（https://isomer-user-content.by.gov.sg/36/2afb6128-5b9b-4e32-b151-5c6033b993f1/Cloud-Security-Companion-Guide-Cyber-Trust.pdf）。

以下では、サイバートラストマーク認証関連文書（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cybersecurity-certification-for-organisations/cyber-trust/certification-for-the-cyber-trust-mark/）の1つとして公開されている「サイバートラスト(2025) マーク – 自己評価テンプレート」より、サイバートラストマークの各管理策項目におけるOTセキュリティ固有の管理策およびフォーカス領域を紹介する。

B.1 ドメイン: ガバナンス
B.2 ドメイン: ポリシーと手順
B.3 ドメイン: リスクマネジメント
B.4ドメイン: サイバー戦略
B.5 ドメイン: コンプライアンス
B.6 ドメイン: 監査
B.7 ドメイン: トレーニングと認識
B.8 ドメイン: 資産管理
B.9 ドメイン: データ保護とプライバシー
B.10 ドメイン: バックアップ
B.11 ドメイン: Bring Your Own Device (BYOD)
B.12 ドメイン: システムセキュリティ
B.13 ドメイン: ウイルス対策／マルウェア対策
B.14 ドメイン: 安全なソフトウェア開発ライフサイクル（SDLC）
B.15ドメイン: アクセス制御
B.16 ドメイン: サイバー脅威管理
B.17 ドメイン: サードパーティリスクと監督
B.18 ドメイン: 脆弱性評価
B.19 ドメイン: 物理／環境セキュリティ
B.20 ドメイン: ネットワークセキュリティ
B.21 ドメイン: インシデント対応
B.22 ドメイン: 事業継続／災害復旧

サイバートラストのOTセキュリティ管理策は、ガバナンス、リスクマネジメント、戦略、技術的制御、インシデント対応、事業継続を網羅している。特に、OTの安全性と可用性の優先、レガシーシステムのリスク、OT特有のプロトコルへの対応を強調している。そして、CISOの明確化と経営層の関与を促し、ITとOTのポリシー統合、部門間の連携強化、脅威に応じた技術的制御（セグメンテーション、OT向けIDS/IPS等）、OT固有のシナリオを含む演習によるサイバーレジリエンスの確保を求めている。

【サイバートラスト】B.1 ドメイン: ガバナンス

B.1.4 組織は、サイバーセキュリティプログラムの実装を監督し、組織内のサイバーセキュリティリスクを管理する責任者（例：最高情報セキュリティ責任者〈CISO〉）が誰であるかを明確にするために、役割と責任を定義し、割り当てている。
【OTセキュリティ固有の管理策】
・OTセキュリティが経営陣の関心を得られるよう、組織はITおよびOTセキュリティの両方を監督し、全体的な責任を担う上級管理職のメンバーを特定している。
【フォーカス領域】

・役割と責任の定義

B.1.5 取締役会および／または上級管理職は、サイバーセキュリティに関する十分な専門知識を有しており、サイバーセキュリティ戦略、方針、手順、ならびにリスク管理の実装を承認し、監督する役割を担っている。
【OTセキュリティ固有の管理策】
・取締役会および／または上級管理職は、OTに特有のリスク（例：サイバーセキュリティを十分にサポートできない可能性のあるレガシーOTシステムの継続運用）に関連する影響を考慮した適切な経営判断を下すために、OTセキュリティに関する十分な専門知識を有しているべきである。。
【フォーカス領域】

・取締役会および／または上級管理職の関与

B.1.7 取締役会および／または上級管理職は、サイバーセキュリティに関する取り組みや活動について定期的に議論し、サイバーセキュリティリスクを監督・監視するための専任のサイバーセキュリティ委員会／フォーラムを設置しており、組織のサイバーセキュリティ方針、手順、法規制の要求事項への準拠を確保している。
【OTセキュリティ固有の管理策】
・サイバーセキュリティ委員会／フォーラムは、OTセキュリティの最新のプラクティスに関する情報を常に把握するための施策を実装しており、例えばOTの特別研究会への参加などが含まれる。
【フォーカス領域】
・サイバーセキュリティ委員会／フォーラムの設置

【サイバートラスト】B.2 ドメイン: ポリシーと手順

B.2.3 組織は、サイバーセキュリティリスクの管理に採用しているプロセス、業界のベストプラクティスや標準、そして情報資産を保護するための対策について、従業員に定期的に伝達・更新するためのプラクティスを実装している。
【OTセキュリティ固有の管理策】
・組織内のOTおよびITセキュリティ運用が交差する領域において、OTとITのチームがそれぞれ独立して運用されている可能性があるため、そのギャップを埋めるために、組織は部門横断的またはチーム横断的なコミュニケーションの取り組みを実装している。
【フォーカス領域】

・サイバーセキュリティに関する指針や要求事項を従業員に定期的に伝達すること

B.2.4 組織は、サイバーセキュリティリスクを管理し、自身の環境における情報資産を保護するために、関連する要求事項、指針、方針を取り入れたポリシーおよび手順を策定・実装しており、従業員が明確な指針と方向性を持てるようにしている。
【OTセキュリティ固有の管理策】
・組織は、OT環境の安全な利用のためのポリシーおよび手順を策定・実装しており、OTとIT環境の違いを考慮しつつ、それらをITのポリシーおよび手順と統合している。
【フォーカス領域】
・ポリシーおよび手順の策定

【サイバートラスト】B.3 ドメイン: リスクマネジメント

B.3.1　組織は、環境内のサイバーセキュリティリスクを特定しており、オンプレミスのリスクに加え、該当する場合にはリモート環境におけるリスクも含めて、特定されたすべてのサイバーセキュリティリスクに対処できるようにしている。
【OTセキュリティ固有の管理策】
・組織は、OT特有のリスクを考慮に入れており、業界に影響を与えたインシデントに基づく業種固有のリスクも含めている。
【フォーカス領域】

・リスクの特定と是正対応

B.3.6 組織は、特定されたリスクとその優先度、対応計画、タイムライン、追跡および監視の担当従業員を含むサイバーセキュリティリスク登録簿を策定・実装・維持している。
【OTセキュリティ固有の管理策】
・リスク登録簿には、OT環境の特性により軽減が困難なOTセキュリティリスクを記録する必要がある。たとえば、安全でないまたは旧式のプロトコル、サポートが終了したシステム、保守スケジュールによる更新の遅延などが該当する。
【フォーカス領域】

・サイバーセキュリティリスク登録簿の策定

B.3.9 組織は、取締役会および／または経営陣によって承認されたサイバーセキュリティリスクの許容度およびリスク許容声明を策定しており、受容可能なサイバーセキュリティリスクの種類と水準について、組織内で合意が得られていることを確保している。
【OTセキュリティ固有の管理策】
・重大または重要なOTセキュリティリスク（例：サイバーセキュリティを十分にサポートできないレガシーOTシステムの継続的な導入）が軽減できない場合には、そのトレードオフおよび適切な補完的管理策の活用について、取締役会および／または経営陣に報告し、承認を得る必要がある。
【フォーカス領域】
・サイバーセキュリティリスクの許容度および許容範囲の策定

【サイバートラスト】B.4ドメイン: サイバー戦略

B.4.5 組織は、サイバーレジリエンスを確保し、人材・プロセス・技術の観点からサイバーセキュリティ脅威に対抗するためのサイバーセキュリティ戦略を策定している。この戦略は、計画された目標を一定期間内に達成するためのロードマップへと具体化されている。
【OTセキュリティ固有の管理策】
・サイバーセキュリティ戦略およびロードマップでは、以下の要素が考慮されている:
–OTシステムにおけるサイバーセキュリティ目標（安全性、信頼性、物理的なシステムおよびプロセスへの重点など）
–OT資産の長期ライフサイクル
–組織のOTに関する運用モデル（例：内製、外部委託、マネージドセキュリティサービスの利用など）
【フォーカス領域】

・サイバーセキュリティ戦略とロードマップ

B.4.9 組織は、事業目標との整合性を確保し、変化するサイバー脅威の状況を考慮するために、サイバーセキュリティ戦略、ロードマップおよび作業計画を少なくとも年に一度見直し、更新している。
【OTセキュリティ固有の管理策】
・組織はまた、OT（制御技術）への敵対的関心が高まっているというOTの脅威状況も考慮に入れている。
【フォーカス領域】
・サイバーセキュリティ戦略、ロードマップおよび作業計画の更新

【サイバートラスト】B.5 ドメイン: コンプライアンス

B.5.1 組織は、自社の事業領域に適用されるサイバーセキュリティ関連の法律、規制、および（業界特有の）ガイドラインを特定し、それらに準拠するための対応を行っている。
【OTセキュリティ固有の管理策】
・関連する法律、規制およびガイドラインを特定するにあたり、組織は適用される安全に関する法律、規制およびガイドラインも考慮している。
【フォーカス領域】
・サイバーセキュリティ関連の法律および規制の領域の特定

【サイバートラスト】B.6 ドメイン: 監査

B.6.6 組織は、OT環境における制約により十分なサイバーセキュリティ対策の実装が困難な場合（例：時間的制約により暗号化の使用が難しい、OT運用への影響により脆弱性修正のためのソフトウェア更新が困難など）、監査結果への対応およびリスク軽減のために、適切な代替管理策を策定・実装している。
【OTセキュリティ固有の管理策】
・組織は、OT環境における制約により十分なサイバーセキュリティ対策の実装が困難な場合（例：時間的制約により暗号化の使用が難しい、OT運用への影響により脆弱性修正のためのソフトウェア更新が困難など）、監査結果への対応およびリスク軽減のために、適切な代替管理策を策定・実装している。
【フォーカス領域】
・監査結果への対応

【サイバートラスト】B.7 ドメイン: トレーニングと認識

B.7.6 その組織は、研修の種類、頻度、参加者の要求事項、および研修の実装・参加手順に関する方針と手続きを策定・実装しており、それらが確実に遵守されるようにしている。
【OTセキュリティ固有の管理策】
・組織は、ITチームとOTチームのクロスドメイン研修を導入しており、統合されたIT／OT環境に備えるためのスキルを習得させている。
【フォーカス領域】
・サイバーセキュリティ意識向上および研修に関するポリシーと手順の策定

【サイバートラスト】B.8 ドメイン: 資産管理

B.8.4 組織は、ハードウェアおよびソフトウェアを機密性および/または機微度レベルに従って分類および処理するプロセスを確立し、実装している。これにより、それらが適切なセキュリティと保護を受けることを保証する。
【OTセキュリティ固有の管理策】
・OTにおいては、安全性と可用性が優先されるため、組織はそれらを考慮した分類および取り扱いのプロセス（例：セキュリティレベル）を策定・実装している。
【フォーカス領域】

・高度に機密性の高い資産の取り扱いに関する対策

B.8.9 組織は、ハードウェアおよびソフトウェア資産を追跡して管理するために、適切な、業界で認識されている資産インベントリ管理システムの使用を確立し、実装している。これにより、正確性を確保し、見落としを避けることができる。
【OTセキュリティ固有の管理策】
・組織の資産インベントリ管理システムには、OT資産を追跡・管理する機能が備わっている。
【フォーカス領域】
・資産インベントリ管理システム

【サイバートラスト】B.9 ドメイン: データ保護とプライバシー

B.9.3 暗号化を使用している組織は、推奨されるプロトコルやアルゴリズム、最小鍵長の使用に関するプロセスを定義し、適用しており、安全性が確保され、業界のベストプラクティスと整合していることを保証している。
【OTセキュリティ固有の管理策】
・暗号化を実装した結果、OTの運用や安全性に悪影響を及ぼすような遅延が発生する場合には、組織は合理的な代替管理策を策定・実装している。
【フォーカス領域】

・暗号アルゴリズムおよび鍵長を業界のベストプラクティスに整合させること

B.9.5 組織は、リスク分類を行い、機密性および機微度レベルに従ってビジネスに重要なデータ（個人データ、企業秘密、知的財産など）を取り扱うためのポリシーおよび手順を確立し、実装している。これにより、データが適切なセキュリティおよび保護を受けることを保証する。
【OTセキュリティ固有の管理策】
・OTにおいては、安全性と可用性が優先されるため、組織はそれらを考慮した分類および取り扱いに関するポリシーと手順を策定・実装している。
OTデータの例としては、コントローラーの設定ファイル、プログラマブルロジックコントローラー（PLC）のプログラムコード、CAD/CAM（コンピュータ支援設計／製造）ファイルなどが挙げられる。
【フォーカス領域】

・高度に機密性の高い資産の取り扱いに関する対策

B.9.6 組織は、業務上重要なデータ（個人データ、企業秘密、知的財産を含む）が、組織内の情報システムやプログラムを通じてどのように流れるかを文書化するためのデータフロー図に関するポリシーと手順を策定・実装しており、これらのデータが組織の環境内に留まるよう、適切な管理措置も実装している。
【OTセキュリティ固有の管理策】
・組織のOT向けデータフロー図には、OT環境における想定される運用上のデータの流れが含まれており、以下の内容が示されている:
–ネットワーク境界を越えるデータフロー（論理セグメントまたは物理セグメント間の通信経路を含む）
–安全でないプロトコルを通じたデータフローの事例
【フォーカス領域】

・データフロー図の作成

B.9.11 組織は、業務上重要なデータ（個人データ、企業秘密、知的財産など）を組織内で通信・保存・転送する際に、認可されたデバイスのみが安全なプロトコルを用いて行えるようにするためのポリシーと手順を策定・実装している。
【OTセキュリティ固有の管理策】
・OT環境において、認可されたデバイスが安全でないプロトコルを使用している場合には、組織は合理的な代替管理策を策定・実装している。
【フォーカス領域】
・暗号鍵のライフサイクル管理

【サイバートラスト】B.10 ドメイン: バックアップ

B.10.3 組織は、バックアップ作業が確実に実行され、人の介入なしに行えるよう、自動化されたバックアッププロセスを策定・実装している。
【OTセキュリティ固有の管理策】
・自動バックアップが適切でない、または推奨されない状況（例：OTの運用や安全性に悪影響を及ぼす場合）において、組織は定期的なスケジュールに基づく手動バックアップの実装を策定・実装している。
【フォーカス領域】

・自動化されたバックアップの利用

B.10.4 組織は、業務上重要なデータをバックアップするために取るべき手順を明確にするため、バックアップの種類、頻度、保存方法に関する計画を策定・実装している。
【OTセキュリティ固有の管理策】
・OTにおいては、安全性と可用性が優先されるため、組織は重要なOTデータ（プログラムやデバイスの設定などを含む可能性がある）に対してイミュータブルストレージ（不可変ストレージ）の活用を検討している。このようなストレージは以下の利点を提供する:
–読み取り専用形式で保存することによるデータ完全性の強化
–保守用ワークステーションで読み取り専用ドライブとして使用することで、新たなソフトウェアのインストールに対する追加的な保護
【フォーカス領域】
・バックアップ計画の策定

【サイバートラスト】B.12 ドメイン: システムセキュリティ

B.12.5 組織は、各種ログを安全に保存・分類するためのログ管理プロセスを定義・運用しており、効果的なトラブルシューティングに活用できるようにしている。
【OTセキュリティ固有の管理策】
・OT機器にはディスク容量やメモリに制限がある可能性があるため、組織は以下の対策を実施している:
–機器の容量超過やログ記録機能の喪失を防ぐための、十分なローカルまたはリモートストレージの確保
–OT機器から代替ストレージへログを安全に転送・保存するための仕組みの導入
【フォーカス領域】

・ログ管理プロセスの実装

B.12.6 組織は、アップデートやパッチを安全にテスト・適用するためのパッチ管理プロセスを定義・運用しており、悪影響が生じないようにしている。
【OTセキュリティ固有の管理策】
・パッチ管理プロセスでは、OTサブシステムやネットワークセグメントごとに異なる可用性要求事項や、パッチ適用に対する対応能力の違いを考慮しており、組織は対応すべき主要な脆弱性を追跡している。
【フォーカス領域】

・パッチ管理プロセスの実装

B.12.11 組織は、システムの構成を望ましくかつ一貫した状態に維持するために、業界で認知され、適切とされる構成管理ツール／ソリューションを導入・運用している。
【OTセキュリティ固有の管理策】
・組織は、可能な範囲でOTの構成情報を管理できる構成管理ツール／ソリューションを導入・運用している。
【フォーカス領域】

・構成管理ツール／ソリューションの実装

B.12.12 組織は、システムの構成要求事項が業界のベンチマークや標準に整合するよう、ポリシーおよび手順を策定・実装している。
※補足：システム構成のベンチマークを提供している組織の一例として、Center for Internet Security（CIS）が挙げられる。
【OTセキュリティ固有の管理策】
・特殊なOTシステムに関して、組織はOTベンダーやサービスプロバイダーから構成要求事項を取得している。
【フォーカス領域】
・システム構成ベンチマークの策定

【サイバートラスト】B.13 ドメイン: ウイルス対策／マルウェア対策

B.13.6 組織は、出所不明のコードやアプリケーションを業務環境で使用する前に、ウイルスおよび／またはマルウェアの有無を検査するため、隔離されたテスト環境内で実行するプロセスを定義し、適用している。
【OTセキュリティ固有の管理策】
・組織は、出所不明のコードやアプリケーションがOT環境に導入されないようなプロセスを実装している。
認可されたベンダーから新しいアップデートが提供され、かつ組織に冗長機器や予備システムがなくテストが困難な場合には、ベンダーのテスト環境での検証を行うか、定期保守期間やダウンタイム中に自社環境でテストを実施する体制を整えている。
【フォーカス領域】

・コードやアプリケーションの隔離

B.13.8 組織は、外部機関からの脅威インテリジェンスに加入し、ウイルスやマルウェア攻撃を含むサイバー攻撃に関する情報の共有および検証を行うためのポリシーとプロセスを策定・実装している。
【OTセキュリティ固有の管理策】
・組織は、OT特有の脅威に対する可視性を維持するための方針およびプロセスを策定・実装しており、自組織または関連業界向けに特化されたOT向け脅威インテリジェンスへの加入や、OT関連の専門グループ等への参加を通じて、新たな脅威や脆弱性に関する早期警戒や助言を受けられる体制を整えている。
【フォーカス領域】
・脅威インテリジェンスの利用

【サイバートラスト】B.14 ドメイン: 安全なソフトウェア開発ライフサイクル（SDLC）

B.14.4 組織は、ソフトウェア開発ライフサイクル（SDLC）を管理するために、サイバーセキュリティ対策および要求事項を組み込んだSDLCフレームワークを策定・実装しており、これによりデータの完全性、認証、認可、責任追跡、例外処理などの領域に対応できる体制を整えている。
【OTセキュリティ固有の管理策】
・組織は、OT環境に適したSDLCフレームワークを導入・運用しており、以下の要素が含まれている:
–セキュリティ管理
–セキュリティ要求事項の明確化
–セキュリティ・バイ・デザインの実践
–安全な実装
–セキュリティ要求事項に基づくテスト
–セキュリティアップデートの管理
–セキュリティガイドライン
【フォーカス領域】
・セキュアなSDLCフレームワークの策定

【サイバートラスト】B.15ドメイン: アクセス制御

B.15.6 組織は、機密情報および／または業務上重要なデータへのアクセス、ならびに特権アクセスを適切に管理・制限するために、要求事項・ガイドライン・具体的な手順を明記したセキュアなログオンポリシーおよび手順を策定・実装している。
【OTセキュリティ固有の管理策】
・組織は、従業員の認証情報が漏えいした場合に、コーポレートITネットワークからOT環境へのラテラルムーブメント（水平移動）を防止するため、OTおよびIT（またはコーポレート）ネットワークの両方にアクセスする従業員に対して、認証メカニズムおよび／または認証情報を分離して実装している。
・OTにおいては、安全性と可用性が最優先されるため、組織はセキュアなログオンポリシーおよび手順に伴う潜在的な遅延が、緊急時におけるOT担当者のアクセスを妨げないよう配慮している。
【フォーカス領域】

・安全なログオンポリシーおよび手順

B.15.7 組織は、強固なパスフレーズの定義に関する指針を提供するために、パスフレーズの設定およびアップデートに関する要求事項・ガイドライン・具体的な手順を明記したパスフレーズポリシーおよび手順を策定・実装している。
【OTセキュリティ固有の管理策】
・このポリシーおよび手順では、以下のようなOT資産に関する制約と、それに対応する代替的な管理策（補完的統制）が明記されている:
–初期設定のパスワードが変更できない場合
–セキュアなパスワードやパスフレーズがサポートされていない場合
–レガシープロトコルの影響で、パスワードやパスフレーズが平文で送信される場合
–パスワードの使用が推奨されない場合
–その他の制約や制限が存在する場合
【フォーカス領域】

・パスフレーズポリシーおよび手順

B.15.11 組織は、ユーザーの認証および役割に基づくアクセスの承認を行うために、業界で適切かつ認知された特権アクセス管理ソリューションを策定・実装しており、より効率的かつ効果的なアクセス管理を実現している。
【OTセキュリティ固有の管理策】
・組織は、特権アクセス認証情報が漏えいした場合に、コーポレートITネットワークからOT環境へのラテラルムーブメント（水平移動）を防止するため、OT環境とIT環境それぞれに対して特権アクセス管理ソリューションを分離して導入・運用している。

【サイバートラスト】B.16 ドメイン: サイバー脅威管理

B.16.5 組織は、システムのログ監視およびレビュー、インシデントの調査、関係者への報告を実施するための役割と責任を定義し、割り当てている。
【OTセキュリティ固有の管理策】
・組織は、OTおよびITのセキュリティ運用が統合されつつある状況を踏まえ、両者がそれぞれ独立して運用される可能性があることを考慮し、OTおよびITのログ監視・レビュー、インシデントの調査および報告を行うための役割と責任を割り当てている。
【フォーカス領域】

・ログ監視に関する役割と責任

B.16.6 組織は、ログを中央で保管・相関分析し、より効果的なログ監視を実現するために、セキュリティ情報イベント管理（SIEM）を実装している。
【OTセキュリティ固有の管理策】
・SIEMソリューションによるアクティブスキャンがOT環境において適切でない、または推奨されない状況では、組織は以下の対応を行っている:
–パッシブスキャンの実施
–計画されたメンテナンス期間やダウンタイム中にアクティブスキャンを実施
【フォーカス領域】

・セキュリティ情報イベント管理（SIEM）の実装

B.16.7 組織は、システム上で異常を特定できるように分析および監視を行うためのセキュリティベースラインプロファイルを策定・実装している。
【OTセキュリティ固有の管理策】
・OT環境には決定論的な特性があり、OTの活動やトラフィックは予測可能かつ反復的である傾向があることを踏まえ、組織は通常の人間の行動およびOTプロセスの挙動を考慮したネットワークトラフィックおよびデータフローのベースラインを確立している。これにより、通常または一時的な状態と異常を区別し、誤検知（フォールスポジティブ）アラートの最小化を図っている。
【フォーカス領域】

・セキュリティベースラインプロファイルの確立

B.16.8 組織は、異常または不審なログを検出した際に、それらを迅速に調査・報告・是正するための要求事項、ガイドライン、および具体的な手順を明記したポリシーおよび手順を策定・実装している。
【OTセキュリティ固有の管理策】
・OTにおいては、安全性と可用性が最優先であるため、組織のポリシーおよび手順では、対応の優先順位（例：フォレンジックデータの保全や調査よりも、OTの運用を正常状態に復旧すること）を明示している。
【フォーカス領域】

・異常または不審なログを検出した際のポリシーおよび手順

B.16.11 組織は、IT環境内に潜む脅威を積極的に探索するための対策およびプロセスを策定・実装している。
【OTセキュリティ固有の管理策】
・これには、OT環境や、組織自身の業界および隣接する業界を標的とする潜在的な脅威に対する脅威ハンティングも含まれる。
【フォーカス領域】
・積極的な脅威ハンティング

【サイバートラスト】B.17 ドメイン: サードパーティリスクと監督

B.17.4 組織は、サードパーティに対して最低限のサイバーセキュリティ要求事項が定義されていることを確保し、サードパーティが自らのセキュリティ上の責務を認識するよう周知するとともに、システムおよびデータのセキュリティが確保されるよう対策を策定・実装している。
【OTセキュリティ固有の管理策】
・これには、OTサプライチェーンへの依存度が高い状況、たとえばOTベンダーに関して、組織がサードパーティの運用を見直すことも含まれている:
–サードパーティが提供する製品、サービス、またはシステムのサイバーセキュリティ体制
–組織のOTシステムに対して、ソフトウェアのアップグレードやパッチの提供、統合サービスの実施、運用・保守の支援を行う際のサードパーティのサイバーセキュリティ運用
【フォーカス領域】

・サードパーティのセキュリティ責務

B.17.5 組織は、サードパーティと契約を締結する前やオンボーディングの段階で、提供されるサービスの種類に応じたリスクに基づき、必要なセキュリティ義務をすべて満たしていることを確認するための評価措置を策定・実装している。
【OTセキュリティ固有の管理策】
・これには、プロジェクトのリスクレベルに基づき、サードパーティが満たすべき最低限のサイバーセキュリティ要求事項の評価が含まれている。
【フォーカス領域】
・サードパーティの関与時に実施するセキュリティ評価

【サイバートラスト】B.18 ドメイン: 脆弱性評価

B.18.3 組織は、自身のシステムに対して脆弱性評価をレビュー・実施するために、目的、範囲、要求事項を定めた脆弱性評価計画を策定している。
【OTセキュリティ固有の管理策】
・脆弱性評価計画には、各OTサブシステム、ネットワークセグメント、および／またはゾーン内の脅威と脆弱性の特定および評価が含まれている。
【フォーカス領域】

・脆弱性評価計画の策定

B.18.4 組織は、少なくとも年に一度、システムに対して非侵入型のスキャンを実施し、脆弱性を発見するための定期的な脆弱性評価を行っている。
【OTセキュリティ固有の管理策】
・脆弱性評価を実施する際、リアルタイムのOT運用に影響を与える可能性があるアクティブスキャンについて、組織はOTシステムに干渉しないパッシブスキャンや監視ツールの活用を検討している。
・アクティブスキャンを実施する場合には、脆弱性評価計画の中に、事前のテストを行うプロセスや、スキャンを計画されたメンテナンス期間またはダウンタイム中に実施する手順を含めている。
【フォーカス領域】

・定期的な脆弱性評価の実装

B.18.7 組織は、評価によって明らかになった脆弱性について、その重大度に応じて適切に是正されるよう、追跡、レビュー、評価、および対応のための対策とプロセスを策定・実装している。
【OTセキュリティ固有の管理策】
・脆弱性を速やかに緩和できない状況（例：レガシーなOT機器や、ソフトウェアパッチが提供されていないシステム）において、組織はこれらの脆弱性に対応するための代替的な管理策（補完的対策）を実施している。
【フォーカス領域】

・特定された脆弱性の追跡と是正

B.18.8　組織は、ペネトレーションテスト（侵入テスト）を安全に実施できるように、目的、範囲、および実施ルールを定めたテスト計画を策定・実装している。
【OTセキュリティ固有の管理策】
・組織のOT環境におけるペネトレーションテスト計画には、以下の内容が含まれている:
–OTシステムはタイミング制約に敏感だったり、リソースが限られていたりする場合があるため、テストによってOT機能に悪影響を及ぼさないようにするための対策を実施していること
–必要に応じて、複製された環境、仮想化された環境、またはシミュレーション環境を用いてペネトレーションテストを実施するなど、代替的な管理策を考慮していること
–テストの実施にあたって、必要に応じて本番OT環境を計画されたメンテナンス期間やダウンタイム中にオフラインにする必要性を考慮していること
【フォーカス領域】
・ペネトレーションテスト計画の策定

【サイバートラスト】B.19 物理／環境セキュリティ

B.19.2 組織は、自らの環境における物理的・環境的リスクを特定し、脅威に迅速に対応できるようにするための検知手段を実装している。
【OTセキュリティ固有の管理策】
・例としては、以下が含まれる:
–OT環境への許可されていない人物による物理的アクセス
–自然災害や停電によって組織のサイバーセキュリティ対策が妨げられ、OT環境がサイバーセキュリティインシデントに対して脆弱になること
【フォーカス領域】

・検知的統制の確立

B.19.3 組織は、内部および外部の脅威から物理的資産を保護するための対策を講じており、例えば盗難や改ざんを防ぐためにケーブルロックを使用している。
【OTセキュリティ固有の管理策】
・論理的および／または物理的なセグメンテーションが、リスクや重要度、セキュリティ要求事項に基づいてOT資産を分類・隔離するために用いられていることから、組織はOTのサブシステムやネットワークセグメントを隔離するための物理的統制を実施している。例えば、OT資産を収納するために施錠されたキャビネットや部屋を使用することなどが挙げられる。
【フォーカス領域】
・内部および外部の脅威に対する保護

【サイバートラスト】B.20 ドメイン: ネットワークセキュリティ

B.20.3 組織は、基本的なパケットフィルタリング型ファイアウォールよりも高度なコンテキストに基づいてパケットをフィルタリングできるよう、ステートフルファイアウォールの使用を確立し、実装している。これにより、より高い効果でセキュリティを確保している。
【OTセキュリティ固有の管理策】
・組織は、OT環境向けに特化して設計された、またはOT環境に合わせて調整されたファイアウォールを実装しており、一般的なOTプロトコルに対応している。これにより、論理的または物理的なセグメント間のOTネットワーク、ならびにIT環境やインターネットに接続されるOTネットワークの保護が可能となっている。
【フォーカス領域】

・ステートフルファイアウォールの実装

B.20.5 組織は、有線および無線ネットワークの両方を安全に構成するためのプロセスを定義し、実装している。これには、少なくとも安全なネットワーク認証と暗号化プロトコルの使用、およびWPS(Wi-Fi Protected Setup)の無効化が含まれており、ネットワークの安全性を確保し、データの損失や漏えいを防止している。
【OTセキュリティ固有の管理策】
・OTの通信やネットワークの保護が適切でない、または推奨されない状況（例：OTの運用や安全性に悪影響を及ぼす場合）において、組織は代替的な管理策を実施している。
例としては:
–安全なネットワーク認証や暗号化プロトコルが実装できない場合、MAC（メディアアクセス制御）アドレスフィルタリングなどの対策を講じる
–レガシーなOT機器が安全でない無線接続しか対応していない場合、物理的な制御（例：無線ネットワークのカバレッジ範囲を安全な物理エリア内に限定する）を用いる
【フォーカス領域】

・ネットワークセキュリティの実装

B.20.6 組織は、ネットワークをプライベートネットワークとパブリックネットワークに分離するためのネットワークセグメンテーションのプロセスを定義し、実装している。プライベートネットワークには業務上重要なデータが保持されており、インターネットとは接続されていないことで、外部の脅威から隔離された状態が確保されている。
【OTセキュリティ固有の管理策】
・組織は、以下の目的のために（物理的セグメンテーションを含む）セグメンテーションを実装している:
–セキュリティ要求事項、リスク、重要度に基づいて、セグメント間の通信および情報の流れを制限・管理すること
–セキュリティ上の脆弱性を抱えるOTのレガシーシステムを保護し、他のセグメントやインターネットから拡散する脅威から隔離すること
【フォーカス領域】

・ネットワークセグメンテーションの実装

B.20.9 組織は、悪意のあるネットワークトラフィックを監視・検出するためにネットワーク侵入検知を確立し、実装している。これにより、脅威を迅速に特定し、対処できる体制が整えられている。
【OTセキュリティ固有の管理策】
・OTネットワークにおけるネットワーク侵入検知について、組織はOT向けに特化または調整されたネットワーク侵入検知ソリューションを確立し、実装している。これには、Modbus TCP、Distributed Network Protocol 3（DNP3）、Inter-Control Center Communications Protocol（ICCP）など、一般的なOTプロトコルに対応した攻撃シグネチャが組み込まれている。
・OT環境において非IPベースのプロトコルやコントローラベースのオペレーティングシステムに対応したネットワーク侵入検知ソリューションが利用できない場合には、組織は補完的な管理策（例：異常検知システム）を検討している。
【フォーカス領域】

・ネットワーク侵入検知の実装

B.20.11 組織は、悪意のあるネットワークトラフィックを遮断し、脅威から保護するためにネットワーク侵入防止を確立し、実装している。
【OTセキュリティ固有の管理策】
・OTネットワークにおけるネットワーク侵入防止について、組織はOT向けに特化または調整されたネットワーク侵入防止ソリューションを確立し、実装している:
・ネットワーク侵入防止システムに伴う自動応答がOT環境に影響を及ぼす可能性がある場合（例：誤検知による影響）、組織は適切な緩和策を講じている。たとえば、ネットワーク侵入防止システムをOTネットワーク内のDMZ（非武装地帯）インターフェースなど、より上位のレベルに配置することで対応している。
【フォーカス領域】
・ネットワーク侵入防止の実装

【サイバートラスト】B.21 ドメイン: インシデント対応

B.21.3 組織は、サイバーセキュリティインシデント対応計画に関与する従業員と迅速に連絡が取れるように、連絡先情報の確認手段を定義し、適用している。
通常関与する機能別グループには以下が含まれる:
–経営陣
–インシデント対応チームまたはサイバーセキュリティチーム
–法務チーム
–広報・コミュニケーションチーム
【OTセキュリティ固有の管理策】
・OTのインシデント管理においては、以下のような他の機能部門が関与する場合がある:
–OT業務に関与するIT担当者
–OT担当者
–セキュリティ担当者および安全管理担当者
【フォーカス領域】

・インシデント対応に関与する担当者の連絡可能性の確認

B.21.4 組織は、関係者がインシデント発生時に何をすべきかを理解し、十分に備えられるようにするため、サイバー演習を実施するプロセスを定義し、適用している。
【OTセキュリティ固有の管理策】
・組織は、これらのサイバー演習にOT特有のシナリオを含めている。
・OTの顧客とOTのサプライチェーン（例：OTベンダー）との間に強い依存関係や接点がある場合には、これらの演習にOTサプライチェーン上の主要な外部関係者も参加させている。
【フォーカス領域】

・サイバー演習の実施

B.21.6 組織は、インシデントを調査して証拠を収集し、根本原因を特定できるようにするための要求事項、指針、具体的な手順を明記したポリシーおよび手順を定義し、確立している。
【OTセキュリティ固有の管理策】
・組織は、OT特有のインシデント対応を全社的なインシデント対応計画に統合している。
・策定されたポリシーおよび手順には、必要な対応措置とそれがOT業務に与える影響の評価が含まれている。例えば、侵害されたシステムの物理的な隔離はOT業務に悪影響を及ぼす可能性があり、運用パフォーマンスや安全性の低下を招くことがある。
【フォーカス領域】
・インシデント調査のためのポリシーおよび手順の策定

【サイバートラスト】B.22 ドメイン: 事業継続／災害復旧

B.22.2 組織は、高可用性が求められる重要資産を特定し、それらに対して冗長性を確保するための対策を実装している。
【OTセキュリティ固有の管理策】
・組織は、サイバーセキュリティインシデント発生時に制限された運用や縮小された運用を維持するために必要な重要な接続性および資産を特定している。
また、容易に入手できないOTコンポーネントに対しては、冗長性や代替品を確保するための措置を講じている。
【フォーカス領域】

・高可用性が求められる重要資産の特定

B.22.5 組織は、事業継続／災害復旧に関するポリシーを確立し、実装している。このポリシーには、システムの重要度に応じて事業再開を実施できるようにするための要求事項、役割と責任、指針（RTOおよびRPOを含む）が明記されている。
【OTセキュリティ固有の管理策】
・復旧活動の優先順位を決定する際、組織はリスク評価を考慮し、運用上の依存関係を持つOT機器の起動活動に対して適切な順序を策定している。
【フォーカス領域】

・事業継続／災害復旧ポリシーの確立

B.22.6 組織は、サイバーセキュリティインシデントを含む一般的な業務中断シナリオに対応・復旧するための事業継続／災害復旧計画を確立し、実装している。これにより、サイバーレジリエンスの確保を図っていまる。
【OTセキュリティ固有の管理策】
・組織は、復旧活動の優先順位を決定している。例えば、OTシステムよりも先に重要なインフラを支えるシステムを復旧するなどである。
・組織の事業継続／災害復旧計画は、電子形式と紙形式の両方で文書化され、すぐにアクセスできる状態で保管されなければならない。
【フォーカス領域】

・事業継続／災害復旧計画の策定

B.22.8 組織は、事業継続／災害復旧計画の目的達成に向けた有効性を確保するために、少なくとも年に一度は定期的に計画をテストするためのポリシーおよびプロセスを確立し、実施している。
【OTセキュリティ固有の管理策】
・運用上または安全上の理由により復旧計画のテストが困難な場合、組織はOT機器の復旧手順を確認するために、ラボでのテストやオフラインでのテストなどの代替手段を実施している。
【フォーカス領域】

・事業継続／災害復旧計画のテスト

B.22.10 組織は、プロセスおよび手順の有効性を評価するために、第三者と連携して一定期間にわたる事業継続／災害復旧演習を実施している。
【OTセキュリティ固有の管理策】
・OTの顧客とOTのサプライチェーン（例：OTベンダー）との間に強い依存関係や連携がある場合、これらの演習にはOTサプライチェーンにおける主要な外部関係者も参加している。
【フォーカス領域】
・事業継続／災害復旧演習の実施

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

SaaS Security Capability Framework（SSCF）v1.0のご紹介：SaaSセキュリティのレベルを向上させる

コメントをどうぞ

本ブログは、CSA本部が公開している「Introducing the SaaS Security Capability Framework (SSCF) v1.0: Raising the Bar for SaaS Security」の日本語訳です。なお、本ブログと原書の内容に差異があった場合には、原書の内容が優先されます。

SaaS Security Capability Framework（SSCF）v1.0のご紹介：
SaaSセキュリティのレベルを向上させるフォームの始まり

CSA EMEA, AVP of GRC Solutions、Eleftherios Skoutaris

SaaSセキュリティの再考が必要な理由

SaaSはすべてを変えた。コラボレーションツールから重要なビジネスアプリケーションまで、SaaSは今や組織がテクノロジーを利用するデフォルトの方法となっている。しかし、この大規模な変化には大きな問題が伴う：セキュリティが追いついていないのだ。

多くのサードパーティリスク管理（TPRM）プログラムは、サプライヤーの組織全体のセキュリティ（SOC 2レポートやISO認証など）に焦点を当てている。しかし、各SaaSアプリケーション内部の実際のセキュリティ機能は評価されておらず、企業がそれらの機能を活用するための指針も提供されていない。その結果、企業は書類上はコンプライアンスを満たしているように見える数百のアプリケーションを導入しながら、実際にはセキュリティ上のギャップを残したままになっている。

JPMorgan Chaseがサプライヤーに送った最近の公開書簡は、まさにこの問題を浮き彫りにした。同社は一貫性のないSaaSセキュリティコントロールを指摘し、業界の改善を強く求めた。明確な基準がなければ、企業、SaaSベンダー、セキュリティチームはそれぞれ独自にギャップを埋めようとし、重複した労力と不要なリスクを抱え続けることになる。

SSCF v1.0の登場

そこで登場したのが SaaS Security Capability Framework（SSCF）v1.0である。

このプロジェクトは、MongoDBとGuidePoint Securityのセキュリティリーダーが主導し、自ら開発作業を率いた。彼らと共に、Cloud Security Alliance（CSA）が共同して主導し、その強みである業界関係者の結集、Cloud Controls Matrix（CCM v4）といった標準構築の豊富な経験、構造化された研究ライフサイクルを通じた作業の指導を行った。CSAはSaaSプロバイダ、SaaS利用者、監査人、コンサルティング企業すべてが意見を反映できるようにし、フレームワークが現実のニーズを反映するものとした。

その結果？ SaaSベンダーがすぐに採用できる、利用者向けのセキュリティ機能フレームワークが実現した。これにより、SaaS利用者とベンダー双方におけるセキュリティレビューと実践の一貫性が確保され、潜在的なセキュリティリスクの低減に貢献する。

「SSCF v1.0は、SaaSセキュリティにおける長年の課題である一貫性のある実行可能な管理策の欠如に対処する。ベンダーと利用者の双方が実装可能な実用的な解決策に焦点を当てることで、このフレームワークは高レベルのコンプライアンスと現実のセキュリティニーズの間のギャップを埋める。GuidePoint Securityでは、Cloud Security Allianceや業界の仲間と協力し、関係者全員にとってSaaSセキュリティを簡素化するものを創り上げたことを誇りに思う」と、GuidePoint SecurityのSenior Cloud Practice Director、Jonathan Villaは述べている。

MongoDBのSenior Director, Security Engineering、Boris Sieklikは次のように付け加えている。「SSCFは、私たちのようなSaaS利用者がまさに求めていたものを提供する。明確で標準化された設定可能な管理策によって、SaaSアプリケーションの評価、採用、安全な運用が容易になる」。

SSCFが目指すのは以下の通りである：

TPRMチーム向け：ベンダーリスク評価をより迅速かつ簡素化する一貫した基準を提供。
SaaSベンダー向け：回答を単一かつ広く認知された標準に統一することで、繰り返される質問票や評価方法の差異による負担を軽減。
SaaSセキュリティエンジニア向け：SaaS導入と日常的なセキュリティ運用を強化するための実践的なチェックリストを提供。

v1.0の内容

SSCF v1.0は、CSAのCCM v4から採用した6つの主要セキュリティドメインにわたる管理策を定めている：

変更管理と構成管理（CCC）
データセキュリティとプライバシーライフサイクル管理（DSP）
アイデンティティとアクセス管理（IAM）
相互運用性と移植容易性（IPY）
ログ記録と監視（LOG）
セキュリティインシデント管理、E-ディスカバリ、クラウドフォレンジック（SEF）

これらのドメインは、SOC 2 や ISO 27001 などのフレームワークに取って代わるものではなく、それらの高レベルの要件を、利用者が実際に設定し、信頼できる具体的な SaaS セキュリティ機能に変換するものである。ログ配信、SSO実施、安全な設定ガイドライン、インシデント通知など、利用者が SaaS を日常的にセキュアに運用するために本当に必要なすべてのものを考えてみてください。

なぜこれが重要なのか

SSCFの核心は摩擦を減らすことにある。企業はSaaSポートフォリオ全体でより一貫したセキュリティ機能を得られ、多様性に富むSaaS環境全体で統一された実装基準を構築できる。ベンダーは求められるセキュリティ管理策を知り得る。そして、個別評価から共通基準への移行により、すべての関係者が時間を節約できる。

最も重要なのは、信頼の構築である。SaaSがミッションクリティカルな存在となった現代において、この信頼こそがセキュアな導入とリスクの高い盲点の分かれ目となる。

Valence SecurityのCo-Founder兼CTO、Shlomi Matichinは次のように述べている。「SSCFが広く採用される世界では、組織はセキュリティ運用コストを負担することなく、大規模かつセキュアにSaaSを利用できるようになる。SaaS導入とデータ移動を加速させる自律型AIの急速な普及に伴い、SSCFの重要性はさらに増大する」。

今後の展望

SSCF v1.0は始まりに過ぎない。プロジェクトの次フェーズは既に進行中で、フレームワークをさらに実践可能なものへと進化させることに焦点を当てている：

組織が管理策を実践に移すための実装ガイドライン、および監査人がこれらの管理策を効果的に評価する方法の監査ガイドラインの確立。
それらの管理策が実際にどれほど効果的かを測定する評価および認証スキーム。

これらを組み合わせることで、SaaSプロバイダと利用者はチェックリストを超え、真に測定可能なセキュリティ改善を実現できる。

CSAは、MongoDB、GuidePoint Security、Grip Security、Obsidian Security、Valence Security、GitLab、Siemens、Kaufman Rossin、AppOmni、Band of Codersなど、多数の主要貢献者からなる広範なコミュニティと連携し、SSCF v1.0を実現できたことを誇りに思う。この最初のバージョンは、より一貫性があり、よりセキュアで、より信頼できるSaaSエコシステムの基盤を築く。そして、この取り組みはここで終わりではない。最高の成果はまだこれからである。

以上