月別アーカイブ: 2026年11月

大阪公立大学 情報基盤システム障害　～　事例の概要とCSAクラウドセキュリティガイダンスに基づく分析

コメントをどうぞ

2026年11月15日
ガイダンスWGリーダー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

本資料の位置付け

本資料は、大阪公立大学が公表した第6報および添付資料を一次情報として事案の概要を整理し、CSAのセキュリティガイダンスv5とクラウドコントロールマトリックス（CCM）v4.1.0の観点から、関連する管理領域と確認事項を対応付けたものである。 公表された事実、CSAガイダンスに照らした分析・確認事項、現時点で不明な事項を区別する。公表資料で確認できない対策の有無や責任分担については、事実として断定しない。

エグゼクティブサマリー

  • 攻撃の起点として、NECの再委託先事業者の端末への不正アクセスが確認された。
  • 再委託先端末およびNEC管理のクラウドストレージから大学関連情報が漏えいした形跡があり、その後、NEC・再委託先が業務で使用する正規アカウント（管理者アカウントを含む）とパスワードを用いた大学システムへの不正アクセスが確認された。
  • NEC管理のクラウドストレージから、学生・教職員等の個人情報約17万名分が漏えいした。うち約1,400名分には銀行口座番号、健康関連情報、パスポート画像、旅券番号等が含まれていた。
  • 機密性の高い情報の多くは、2021年度のシステム移行作業で使用されたデータであり、作業完了後もストレージ上に保存されていた。
  • 大学自身の情報システムから個人情報が漏えいした明確な事実は第6報時点で確認されていない。ただし、不正アクセスとシステム暗号化があったため、漏えい可能性は否定されていない。
  • CSAの観点では、データセキュリティとプライバシーのライフサイクル管理（DSP）、アイデンティティとアクセス管理（IAM）、サプライチェーンの管理・透明性・説明責任（STA）、ガバナンス・リスク・コンプライアンス（GRC）が中心的な分析領域となる。

1. 事案の概要（公表内容）

1.1 攻撃・情報漏えいの経緯

関係を整理すると、「大阪公立大学 → NEC（受託事業者） → 再委託先事業者」という構造である。再委託先は、大学から直接委託を受けた事業者ではなく、NECが大学から受託した業務の一部をさらに委託した事業者を指す。

ただし、第6報から確認できるのは業務上の委託関係までであり、再委託先の企業名、NECとの資本関係（子会社・関連会社等であるか）、具体的な担当業務の範囲は公表資料から特定できない。したがって、資本関係や担当範囲を推測して記載しない。

大学の第6報によれば、大学は情報基盤システムの構築および運用保守業務をNECに委託していた。NECの再委託先事業者の端末が不正アクセスを受け、その端末およびNECが管理するクラウドストレージ上から、大学に関する大量のデータが漏えいした形跡が確認された。

さらに、その記録時刻の直後に、NECおよび再委託先が委託業務で使用する正規アカウントとパスワード（システム管理者アカウントを含む）を用いた大学システムへの不正アクセスが確認された。専門調査会社の調査では、再委託先への侵入と大学への侵入が同一攻撃者によるものと判断できる複数の証跡が確認された。

大学は、攻撃者が再委託先端末への侵入を通じてNEC管理のクラウドストレージから窃取したアカウント情報・パスワード等を悪用し、大学システムに侵入してサイバー攻撃を行ったものと判断している。

時系列で見ると、再委託先は2026年9月下旬にサイバー攻撃を受け（NECの2026年10月20日付公表による）、10月2日未明に大学の情報基盤システムで大規模な障害が発生した（大学の障害情報ページによる）。その後、11月12日にNECから大学へ漏えい内容に関する追加報告があり、第6報で漏えいした情報の内容と件数が公表された。

段階時期第6報・別紙2で示された内容
① 再委託先端末2026年9月下旬不正アクセスを受け、端末から情報が流出。クラウドストレージへのアクセス方法も漏えいしたと考えられる。
② NEC管理のクラウドストレージ公表資料では時期は示されていない（11月12日にNECが大学へ追加報告）大学のシステム関連重要情報、管理者アカウント・パスワード、個人情報等が漏えい。2021年度のデータ移行業務に使用した機密情報も含まれる。
③ 大学システムへの侵入②の記録時刻の直後窃取した情報を利用した可能性が非常に高いとされ、NEC・再委託先が使用する正規アカウントで不正アクセス。
④ システム暗号化2026年10月2日未明に障害発生大学の仮想化基盤、各種サーバー、バックアップデータ等が暗号化された。

1.2 漏えいした情報

NEC管理のクラウドストレージから漏えいした情報として、大学は次の内容を公表している。数値はいずれも大学公表の概数である。機密性の高い情報（銀行口座番号、健康関連情報、パスポート画像、旅券番号）の内訳を単純に合計すると約1,420名分となり、大学が公表する約1,400名分と概数として整合する。

情報の区分公表された規模補足
学生・教職員等の個人情報約17万名分ID、氏名、メールアドレス、生年月日等を含む
銀行口座番号約20名分機密性の高い個人情報
健康関連情報約200名分2018～2021年度に在籍した教職員・学生
パスポート画像約200名分2018～2021年度に留学した外国籍の方
旅券番号約1,000名分2018年度〜2021年度に在籍した学生の中で、JCSOS（海外渡航者）の対象者

機密性の高い情報の多くは、2021年度に実施したシステム移行作業で使用したデータであり、作業完了後もNEC管理のクラウドストレージに保存されたままだったと大学は説明している。大学は、長期間削除されず、多くのNEC・再委託先関係者が利用するストレージに保管されていたことを重大な問題と認識している。

1.3 大学システムからの情報漏えいと暗号化

第6報時点で、大学の情報システムから個人情報が漏えいした明確な事実は確認されていない。一方、不正アクセスがあり、多くのシステムが暗号化されていることから、漏えいの可能性を完全には否定できないとしている。

別紙2では、仮想化基盤、各種サーバー、バックアップデータ等が暗号化されたと説明されている。したがって、バックアップを含む復旧環境への影響が確認されているが、具体的な復旧可能性や復旧手順の詳細は、第6報だけからは評価できない。

2. CSAガイダンスの枠組み

本分析では、CSAセキュリティガイダンスv5をクラウドセキュリティ上の論点を整理する上位ガイダンスとして用い、CCM v4.1.0 日本語版を具体的な管理策・評価項目を検討するための管理策フレームワークとして用いる。

CSAセキュリティガイダンス v5は12ドメインで構成される。CCM v4.1.0は17ドメイン・207の管理策で構成され、クラウドサービスプロバイダ（CSP）とクラウドサービス利用者（CSC）を含むクラウドサプライチェーン上で、どの主体がどの管理策を実施するかを評価・整理するために利用できる。

2.1 クラウドセキュリティの観点から見た本件の問題

本件は、クラウド基盤やクラウドサービスの脆弱性が原因と確認された事案ではない。クラウドセキュリティの観点で問題となるのは、クラウド事業者が提供する基盤そのものではなく、クラウドサービスを「どう使い、誰が管理していたか」という運用の部分である。

各主体の立ち位置は、ISO/IEC 22123-1:2023（用語）および22123-2:2023（概念）の役割区分（CSP、CSC、クラウドサービスパートナー〔CSN〕）を用いると、次のように整理できる。表の「役割」は、公表された事実にこの区分を当てはめた分析上の位置付けであり、公表資料に記載された事実ではない。CSNは、CSPやCSCを支援する事業者を指し、システムの構築・運用を請け負う事業者などが含まれる。役割は会社ごとではなく関係ごとに決まるため、同じ主体が相手によって異なる役割を持つことがある。

主体本件での役割（分析上の位置付け）公表資料で確認できること公表資料で確認できないこと
大学CSCに相当（データの持ち主）情報基盤システムの構築・運用保守をNECに委託。自らのデータがNEC管理のストレージに保管されていた。当該ストレージの契約に大学が当事者として関与していたか。
NEC大学に対してはCSNに相当情報基盤システムの構築・運用保守の受託者。第6報で「NEC管理」とされるクラウドストレージの管理者。ストレージに関する立場。他社のストレージサービスを契約していたなら基盤事業者に対するCSC、自社のクラウドサービスとして提供していたならCSPとなる。
再委託先NECの下でのCSNに相当NECから業務の一部を再委託されていた。端末が侵入の起点となった。企業名、NECとの資本関係、担当業務の範囲、ストレージへのアクセス権限の範囲。
ストレージの基盤事業者CSPに相当―事業者名、サービスモデル（IaaS／PaaS／SaaS）、NECとの契約関係。

この整理のうち、公表資料で確認できる事実は、NECが大学から情報基盤システムの構築・運用保守を受託していたこと、および問題のストレージが「NEC管理」とされていることである。NECを大学に対するCSNと位置付けるのは、この事実に基づく分析上の当てはめであり、大学のシステムがクラウドを利用していたかどうかも公表資料からは特定できない。一方、NECがストレージについてCSPであったか、他社サービスの利用者（CSC）であったかは、第6報からは判断できない。このため、本資料ではNECを当該ストレージのCSPと断定しない（責任分担の評価上の留意点は第5章で述べる）。

クラウドでは、運用を委託してもデータに対する責任は利用者側に残る。本件では、大学はデータの持ち主として説明責任を負う立場にあり、当該ストレージの日常的な管理（アクセス権の付与・見直し、データの削除）は、ストレージを管理していたNECが担っていたと考えられる。ただし、契約上の責任分担は公表されていない。

用語について：CCM v4.1.0は、CSPとCSCの二者を基本に責任分担を整理しており、CSNという用語は用いていない。委託先・再委託先との関係は、CCM上は主にSTAドメイン（サプライチェーンの管理、透明性、説明責任）で扱っている。

以上を踏まえ、公表資料に基づくと、本件の問題は次の5点に整理できる。

  1. クラウドストレージのデータライフサイクル管理が機能していなかった可能性：クラウドストレージは、関係者間でデータを簡単に共有でき、容量の制約もほとんどない。そのため、作業用データが業務終了後も削除されずに残りやすい。本件では、2021年度の移行作業で使われた機密性の高いデータが、作業完了後も長期間、多くのNEC・再委託先関係者が利用できるストレージに残っていた。大学自身もこの点を重大な問題と認識しており、保管期間、削除、アクセス範囲の管理が十分に機能していなかったことが、漏えいの重大性につながった可能性がある。（関連：DSP）
  2. アイデンティティが事実上の境界となる構造：クラウドサービス一般では、インターネット経由で利用するストレージや管理機能へのアクセスは、ネットワークの内側か外側かよりも、正しい認証情報を持っているかどうかで決まる。本件の当該ストレージや大学システムへのアクセス経路は公表されていないが、再委託先端末からストレージへのアクセス方法が漏えいし、さらにストレージに保管されていた管理者アカウント・パスワードが大学システムへの侵入に使われた。認証情報そのものの保護、保管場所、多要素認証の有無が、防御の要となる構造である。（関連：IAM）
  3. 責任共有の範囲が委託・再委託先に広がり、管理主体が見えにくかった：クラウドの責任共有モデル（SSRM）は、CSPと利用者の二者関係として説明されることが多い。本件のストレージは「NEC管理」とされ、大学、NEC、再委託先が関与していた。誰がアクセス権を付与・見直し、誰がデータの削除を確認し、誰が設定を監査するのかが、委託元である大学から見えにくい構造だった可能性がある。第6報では、ストレージの基盤提供者や契約関係は明らかにされていない。（関連：STA、GRC）
  4. 委託先が管理するクラウド環境は、委託元からの可視性が限られる：大学のデータを保管していても、委託先が契約・管理するクラウドストレージのアクセスログや設定は、大学が直接確認できないことが多い。大量ダウンロードや通常と異なる端末からのアクセスがあっても、委託元が自ら検知することは難しい。ログの取得・保存・共有と、異常時の報告義務を契約や手順で定めておくことが重要になる。（関連：LOG、SEF）
  5. 管理者権限の奪取がバックアップにまで及ぶリスク（一般論）：仮想化基盤やクラウドの管理機能は、1つの管理者アカウントで多数のシステムを操作できる。一般に、バックアップが本番環境と同じ認証情報・管理経路に依存していると、管理者権限を奪われた際にバックアップまで失われるおそれがあり、これはクラウドかオンプレミスかを問わず仮想化・クラウド環境に共通するリスクである。本件では管理者アカウントによる侵入の後、仮想化基盤、サーバー、バックアップデータ等が暗号化されたが、バックアップがどの認証経路で管理されていたかは公表されていない。このため、本資料ではこの点を確認事項として扱う（4.4参照）。（関連：I&S、BCR）

留意点：大学の情報基盤システム自体がクラウド上にあったか、オンプレミスの仮想化基盤であったかは、第6報からは特定できない。上記は、委託先が管理するクラウドストレージを中心に、クラウドセキュリティの考え方を当てはめた分析上の整理であり、各主体の対策の不備を断定するものではない。

3. 事案とCSAの主要領域との対応

以下は、事案との関連性が高いCCM v4.1.0 日本語版のドメインを中心に整理したものである。対応付けは分析上の整理であり、当該管理策に違反したことを意味するものではない。

優先順位の意味：ここで示す「最優先」「高」「中～高」は、本事案を筆者の観点から分析する際の検討順序を示すものである。公式な重要度や、CCM管理策の適合性評価・リスク評価を示すものではない。

CCMドメイン事案との関係確認・評価すべき事項分析上の優先順位
DSP：データセキュリティとプライバシーのライフサイクル管理機密性の高い情報の多くを占める移行データが業務完了後もクラウドストレージに残存し、漏えい。データ分類、保管目的・期間、保存場所、アクセス範囲、削除・消去確認、委託終了時のデータ処理。最優先
IAM：アイデンティティとアクセス管理正規アカウント・パスワード（管理者アカウントを含む）が悪用され大学システムへ侵入。MFAの適用状況、特権ID管理、最小権限、認証情報の保護・共有、アクセス経路制限、アカウント棚卸し。最優先
STA：サプライチェーンの管理、透明性、説明責任再委託先端末への侵入が、委託先のストレージ情報窃取と大学への侵入につながった。再委託先の把握・評価、契約上のセキュリティ要求、アクセス権限、監査・報告、委託先の継続的モニタリング。最優先
GRC：ガバナンス、リスク、コンプライアンス大学・NEC・再委託先間の管理責任、業務完了後のデータ保持管理が論点。責任分担、リスク評価、委託・再委託の統制、業務終了時の確認、監査証跡、例外承認。高
LOG：ロギング＆モニタリング正規アカウントの悪用や大量データアクセスを検知・追跡できるかが論点。認証・管理操作・ストレージアクセスのログ、異常なダウンロード、アクセス元・端末の変化、ログ保全と相関分析。高
UEM：ユニバーサルエンドポイント管理再委託先の端末が侵入起点となった。端末の資産管理、パッチ・EDR等の保護、端末準拠性、ローカル保存・認証情報保存の制御、遠隔隔離。高
SEF：セキュリティインシデント管理、Eディスカバリ、およびクラウドフォレンジック侵入調査、情報漏えい範囲の特定、証拠保全が必要。インシデント対応計画、委託先との連絡・協力、証拠保全、フォレンジック、報告・通知、再発防止。高
BCR：事業継続管理と運用レジリエンス仮想化基盤、サーバー、バックアップデータ等が暗号化。バックアップの分離・保護、復旧優先順位、復旧テスト、代替運用、復旧目標と依存関係。高
I&S：インフラストラクチャセキュリティ仮想化基盤や各種サーバーが暗号化対象となった。管理プレーン保護、管理ネットワーク分離、ハイパーバイザー・管理者権限、ワークロード間分離。中～高

4. 重点分析テーマ

4.1 データセキュリティとプライバシーのライフサイクル管理（DSP）

最も明確な論点は、漏えいした機密性の高い情報の多くを占める2021年度の移行作業用データが、作業完了後も委託先管理のクラウドストレージに残存していたことである。クラウド上のデータは、保存中の暗号化だけでなく、利用目的、保管期間、アクセス主体、複製・転送、アーカイブ、削除までをライフサイクルとして管理する必要がある。

  • 移行作業完了時に、作業用データの削除・返却が契約・手順で定義されていたか。
  • 削除対象、削除期限、削除実施者、削除証跡の確認方法が明確だったか。
  • ストレージへのアクセス権が業務上必要な関係者に限定され、定期的に見直されていたか。
  • 個人情報・健康関連情報・旅券情報等の機密性に応じて、保存場所やアクセス条件を分けていたか。

4.2 アイデンティティとアクセス管理（IAM）

今回の侵入では、正規アカウントとパスワードが使用された。したがって、認証が成功したかどうかだけでなく、誰が、どの端末から、どの経路で、どの権限を用いて、何を実行したかを検証する必要がある。

  • 管理者アカウントの利用者・利用目的・利用時間を限定していたか。
  • MFA、特権アクセス管理、必要時のみの権限付与、セッション監視がどの範囲に適用されていたか。
  • 委託先・再委託先の端末やネットワークから大学環境へ接続する際の条件が定義されていたか。
  • 認証情報が端末や共有ストレージに平文・再利用可能な形で保存されないよう管理されていたか。

留意点：第6報はMFAの適用状況、特権アクセス管理の詳細、具体的なログ監視設定を明らかにしていない。したがって、これらは確認事項であり、未実施・不備とは断定できない。

4.3 サプライチェーンの管理・透明性・説明責任（STA）とガバナンス・リスク・コンプライアンス（GRC）

大学、NEC、再委託先という複数主体が関与する構造では、委託元が直接管理できない端末・アカウント・保管環境が、委託元システムへの侵入経路となり得る。STAおよびGRCの観点では、委託先の評価だけでなく、再委託先の把握、アクセス経路、契約条件、監査権、事故報告、業務終了時のデータ処理までを一連の統制として扱う。

  • 再委託先を含むサプライチェーンの構成・役割・データアクセス範囲を可視化していたか。
  • 再委託先に対するセキュリティ要求事項が契約に反映され、履行状況を確認していたか。
  • 委託業務終了時のデータ返却・削除、アカウント停止、認証情報更新を確認するプロセスがあったか。
  • 大学・NEC・再委託先・ストレージ提供者の責任分担とインシデント時の協力義務が明確だったか。

4.4 ロギング＆モニタリング・セキュリティインシデント管理・事業継続管理と運用レジリエンス（LOG／SEF／BCR）

正規アカウントの悪用は、単純な認証失敗の監視だけでは検知できない場合がある。認証ログ、特権操作ログ、ストレージのダウンロード・共有ログ、接続元端末情報を組み合わせた監視が重要となる。また、大学の仮想化基盤、サーバー、バックアップデータ等が暗号化されたとされるため、バックアップの保護と復旧訓練を含むレジリエンス評価が必要である。

  • 異常な大量アクセス・ダウンロードや、通常と異なる端末・接続元からの管理者アクセスを検知できるか。
  • ログが攻撃者によって改ざん・削除されないよう保護され、調査に利用できる期間保存されているか。
  • 委託先・再委託先からの初報、証拠保全、影響範囲調査、顧客・本人への通知の役割分担が定義されているか。
  • バックアップが本番環境と同じ認証・管理経路に依存していないか。隔離・イミュータブル化（不変化）・復旧テストが実施されているか。

5. クラウド責任分担を評価する際の留意点

本件では「NEC管理のクラウドストレージ」と公表されているが、第6報だけでは、当該ストレージの基盤提供者、サービスモデル（IaaS／PaaS／SaaS）、契約関係、管理権限の所在を特定できない。

したがって、NECを当該ストレージのCSPと断定したり、大学をそのサービスのCSCと単純に位置付けたりすることは避ける。実際の責任分担は、契約、サービス構成、管理権限、データ管理の実態を確認した上で整理する必要がある。

CCM v4.1.0 日本語版のSTAドメイン（STA-02「SSRMポリシーと手順」～STA-07「SSRM管理策の実施」）およびIntroductory Guidanceで示されるセキュリティ責任共有モデル（SSRM）の考え方を用い、CSP・CSCだけでなく、委託先・再委託先を含む各主体について、管理策ごとに実施主体、確認主体、証跡を明確にすることが望ましい。なお、管理策番号はCCM v4.1.0 日本語版の「CCM_V41」シートによる。v4.1ではSTA-01に新たな管理策が追加されたためSSRM関連の番号が繰り下がっているが、Introductory Guidanceの本文には、SSRMの案内をSTA-01～STA-06とする旧番号表記が残る箇所がある。

6. 事実と未確認事項の区別

第6報で確認・公表された事項第6報だけでは確定できない事項
・再委託先端末への不正アクセス・大学システムから個人情報が実際に漏えいしたか（明確な事実は未確認）
・NEC管理ストレージからの大学関連情報の漏えい形跡・MFAの適用状況・特権ID管理の具体的内容
・正規アカウント・パスワード（管理者アカウントを含む）による大学システムへの不正アクセス・ストレージのサービスモデル、基盤提供者、契約関係
・NEC管理ストレージから個人情報約17万名分、機密性の高い情報約1,400名分が漏えい・各主体間の最終的な責任分担・契約上の責任
・機密性の高い情報の多くは2021年度の移行データで、作業完了後も保存されていた・バックアップの復旧可能性、復旧に要する時間・範囲
・大学の仮想化基盤、サーバー、バックアップデータ等の暗号化・各管理策が実施されていたか、または不備があったか

7. まとめ、分析の方向性

7.1 事案の全体像

本件は、クラウド基盤自体の脆弱性が原因であったと確認された事案ではない。公表資料から読み取れるのは、①再委託先端末への侵入、②委託先が管理するクラウドストレージからの情報窃取、③窃取した正規の認証情報（管理者アカウントを含む）による大学システムへの侵入、④仮想化基盤・サーバー・バックアップデータ等の暗号化、という4段階の連鎖である。

この連鎖は、大学が直接管理していない再委託先の端末と、委託先が管理するストレージを起点としている。また、侵入には正規アカウントが使われたため、大学側の境界防御だけでは防ぎにくい。一方で、委託先アカウントの接続条件、MFA、特権アクセス管理は大学側でも設定し得る対策であり、4.2で確認事項に挙げたとおり、委託先アカウントのアクセス経路の統制は大学側の論点でもある。本件は、委託元・委託先・再委託先を通じたデータと認証情報の管理が問われた事案といえる。

被害の重大性に大きく影響したと考えられるのは、機密性の高い情報の多くを占める2021年度の移行データが、作業完了後も長期間、多くの関係者が利用できるストレージに残っていたことである。この移行データが削除されていれば、攻撃の起点が同じでも、銀行口座番号や健康関連情報、旅券情報といった機密性の高い情報の漏えいは大きく限られた可能性がある。なお、約17万名分の個人情報全体が移行データであったとは公表されていない。

7.2 CSAの観点から見た論点の整理

CCM v4.1.0 日本語版のドメインに照らすと、本件の論点は次のように整理できる。いずれも公表資料に基づく分析上の対応付けであり、特定の管理策の不備を断定するものではない。

  • DSP（データセキュリティとプライバシーのライフサイクル管理）：業務完了後のデータ削除・返却、保管期間とアクセス範囲の管理。機密性の高い情報の漏えいに最も直接関係する論点。
  • IAM（アイデンティティとアクセス管理）：正規アカウントと管理者権限の悪用。認証情報の保管方法、MFA、特権アクセス管理、接続経路の制限が論点。
  • STA／GRC（サプライチェーンの管理、透明性、説明責任／ガバナンス、リスク、コンプライアンス）：再委託先を含む関係者の把握、契約上のセキュリティ要求、SSRMに基づく責任分担、業務終了時の確認プロセス。
  • LOG／UEM／SEF／BCR／I&S：正規アカウント悪用の検知（LOG）、侵入の起点となった端末の管理（UEM）、インシデント対応と証拠保全（SEF）、バックアップを含む復旧（BCR）、仮想化基盤の保護（I&S）。被害の検知・拡大防止・復旧を評価する補完領域。

7.3 委託元組織にとっての示唆

本件は、外部事業者にシステムの構築・運用を委託する多くの組織に共通する課題を示している。委託元として、少なくとも次の点を確認することが望ましい。

  • 委託先・再委託先が、自組織のどのデータと認証情報を、どこに、いつまで保持しているかを把握しているか。
  • 業務やプロジェクトの終了時に、データの削除・返却、アカウントの停止、認証情報の変更を確認し、証跡を残しているか。
  • 委託先が使う管理者アカウントに、MFA、利用時間・接続元の制限、操作の記録・監視を適用しているか。
  • バックアップが本番環境と同じ認証情報・管理経路で破壊されないよう、分離やイミュータブルの措置をとり、復旧を検証しているか。
  • インシデント発生時に、委託先・再委託先からの報告、証拠保全、本人への通知までの役割分担が契約・手順で決まっているか。

7.4 今後の分析の方向性

今後、より詳細な分析を行う場合は、CCM v4.1.0 日本語版の個別管理策の記述（管理策、実装ガイドライン、監査ガイドライン、CAIQ）と照合し、各管理策について「適用主体」「実施主体」「確認主体」「必要な証跡」「公表資料で確認できる事実」を整理する。

第6報の時点では、MFAの適用状況、ストレージのサービスモデルや契約関係、各主体の責任分担など、評価に必要な情報の多くが公表されていない。このため、現時点で公表資料から個別の管理策を不適合として対応付けることは避け、大学や関係事業者の今後の公表内容を踏まえて分析を更新する。

参考資料

注記：CCM v4.1.0は17ドメイン・207管理策で構成される。本資料のドメイン名・用語（管理策、クラウドサービス利用者、セキュリティ責任共有モデル等）は、CCM v4.1.0 日本語版の訳語に基づく。v4.0のIVS（Infrastructure & Virtualization Security）は、v4.1.0ではI&S（インフラストラクチャセキュリティ）として整理されており、仮想化セキュリティもI&S-01等の管理策に含まれる。個別管理策の番号・文言は、同日本語版の「CCM_V41」シート等を参照すること（Introductory Guidanceには旧番号表記が残る箇所がある）。

以上