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

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

要旨

2026年10月の2件の事案は、事業者起因の脅威が重大脅威の上位から外れたという傾向が、日本の国内IaaS/PaaS事業者にはそのまま当てはまらない可能性を示した。どちらも、利用者の設定ミスではなく、事業者側のシステムに起因する侵害である。

• CSAの重大脅威調査では、2019年以降、事業者の責任範囲の脅威は順位を下げ、設定ミスやIAMなど利用者側の脅威が上位を占めている。また、主戦場はSaaSに移っている。
• IDCFクラウドでは、顧客向けポータルの認証システム（OSS）の脆弱性から管理コンソールを経て仮想化基盤の管理者権限が奪われ、495の企業・自治体の仮想サーバーが暗号化された。事業者が管理する共通管理基盤が破られた事案である。
• お名前.com デスクトップクラウドでは、GMOが自社システムのセキュリティ上の問題を認め、顧客情報の外部持ち出しを確認したと公表した。不正プログラムが確認されたのは一部の顧客の環境で、全プランの停止は被害拡大防止のための措置である。侵入経路と破られた層は公表されていない。
• クラウド環境における責任範囲として「ゲストOSから上は利用者」とする分担は、事業者が共通管理基盤を守り切ることを前提とする。その前提が崩れると、利用者側の対策では防ぎきれない。

このブログが扱う事案はIaaSとVPSだが、PaaSも事業者の管理基盤の上で提供されるため、管理基盤に関する論点は同様に当てはまる。このブログは、管理プレーンの到達性と分離、特権の持ち方、外部部品の脆弱性管理、共通要素の個別化、復旧手段の分離と既定値、透明性と第三者保証の範囲、下流への説明責任の7点を、国内インフラ事業者への問いとして整理する。

1. 前提：CSA重大脅威の推移

CSAの重大脅威調査は、2019年版以降「事業者起因の脅威は重要度を下げ、利用者起因の脅威が中心になった」という傾向を一貫して示している。CSAジャパンの日本語資料集の14「重大脅威関連資料」に、各版の日本語訳が掲載されている。

版	上位の脅威	事業者起因の脅威の扱い
2019年版（11の悪質な脅威）	1位 データ侵害、2位 設定ミス	DoS、共有技術の脆弱性、事業者によるデータ消失などが順位を下げた
2022年版（パンデミックイレブン）	1位 IAM	同じ傾向が継続
2024年版	1位 設定ミスと不十分な変更管理、2位 IAM、3位 安全でないインターフェースとAPI	CSAは事業者に関わる従来型の課題が引き続き重要度を下げていると説明

あわせてCSAジャパンの資料集では、SaaSセキュリティの調査やガバナンス資料が続けて公開され、関心の重心はSaaSに移っている。

ただし、この調査は専門家へのアンケートに基づく世界的な傾向である。国内の中堅インフラ事業者にもそのまま当てはまるかどうかは、この傾向からは分からない。

2. 逆行する2つの事案

2件とも、利用者の設定ではなく事業者側のシステムの問題が原因であり、多数の利用者がサービスを使えなくなった。

項目	IDCFクラウド（IDCフロンティア）	お名前.com デスクトップクラウド（GMOインターネット）
サービスの性格	汎用IaaS（仮想サーバー、RDB等）	Windows ServerのVMを1利用者1台割り当てるWindows VPS相当
侵入経路	顧客向け「IDCFクラウドポータル」の認証システムで使うOSSの脆弱性 → 管理コンソール経由で仮想化基盤の管理者権限を取得（第7報）	未公表。GMOは「システムにセキュリティ上の問題が存在」したとする（第4報）。攻撃者は「全VM共通の管理者アカウント」などを突いたと主張（未確認）
破られた層	顧客向けの入口から管理コンソールを経て、ハイパーバイザー管理へ	未公表
確認された被害	東日本リージョン1の4ゾーン、495の企業・自治体の仮想サーバーが停止・暗号化。最大71社の登録情報への不正照会	一部の顧客のサーバー環境で不正プログラムの設置を確認（第1報）。顧客情報の外部持ち出しを確認（第4報。情報の種類と件数は未公表）
予防的な措置	全リージョンのポータルを停止し、外部とのネットワークを遮断	被害拡大防止のため全プランを停止（第1報）。影響の可能性があるサーバーは26,739件（第2報）
下流への波及	メール配信事業者等を経由し、JR各社、自治体、物流など利用者のその先の顧客まで停止や漏えい可能性の公表が相次いだ	VM内に保存されたFX口座のログイン情報が不正利用された可能性
復旧	従来環境での復旧は困難。スナップショット機能の利用者194顧客のバックアップ取り出しが可能と判明し（第5報）、その後206顧客に増えた（第7報）	現行基盤をそのまま再開せず、独立したクラウド基盤上の代替サービスへの移行を案内（第4報）
事業者の認識	自社開発部分には脆弱性診断ツールを使っていたが、外部のソフトウェアには適用していなかった（NHK報道）	社内のホワイトハッカーが事前に課題を指摘していたが、対応の深さと速さが十分でなかったとGMOグループ代表が説明（代表ブログ、報道経由）

IDCFの第7報は、再開に向けてポータルへの接続を顧客IPアドレスに制限し、多要素認証を必須化し、認証システムを外部IdPに刷新するとしている。裏返せば、事案前のポータルはインターネットの任意の送信元から到達でき、多要素認証も必須ではなかったと読める。

出典：IDCFは第5報、第7報、piyologのまとめ。GMOは第1報、第2報、第4報、週刊アスキーの報道。

3. 共通管理基盤が破られるとき

IDCFでは、顧客向けの入口から全利用者に届く特権まで攻撃経路がつながっており、経路の上で分離が実効力を失っていた。分離の欠落がネットワーク、認証、権限のどこにあったかは公表されていない。

利用者向けの入口を破った攻撃者が、事業者の管理系を経て、全VMに外側から届く権限に達した。点線は、本来そこで経路が断たれるべき境界である。

このブログでは共通管理基盤を、次の3つのプレーンと共通要素で捉える。

層	誰の操作を受け付けるか	範囲	侵害されたとき
コントロールプレーン（顧客ポータル、API）	利用者	画面は利用者ごと、裏の仕組みは全体共通	認可不備で他人のリソースを操作される
マネジメントプレーン（運用者の管理系）	事業者の運用者	全体共通	特権で全VMに届く
ハイパーバイザー・共通テンプレート	—	全体共通	VMの外側からディスクや実行に届く
データプレーン（各VM）	利用者	利用者ごとに分離	その利用者だけ

IDCFでは、利用者向けの入口（コントロールプレーン側）を突破した攻撃者が、管理コンソールを経てハイパーバイザーの管理者権限に到達した。つまり、利用者向けの入口から運用者級の特権まで、一続きの経路が存在していた。第7報はこの「管理コンソール」が運用者用かどうか、どのネットワークに置かれていたかを明示していない。

GMOでは、破られたのがどの層かは公表されていない。全プランの停止は被害拡大を防ぐための措置で、不正プログラムが確認されたのは一部の顧客の環境である。共通管理基盤や共通要素が使われたかどうかは、現時点では分からない。

IDCFでは「各利用者の環境は分離されているが、それを束ねる管理層は一つ」という構造が、そのまま影響範囲（blast radius）になった。管理層への到達経路を絞り、権限をゾーンやセル単位に分けることが、事業者にしかできない対策である。

4. 責任共有モデルの前提が崩れるとき

なお、ここでは責任共有モデルを、事業者と利用者がどこまでを担うかという責任境界の観点から扱う。責任共有モデルには、事業者が機能や情報を公開し、利用者がそれを使って検証するという面もある。この面については、第5章の論点6（透明性と第三者保証の範囲）と第6章の調達時の確認で取り上げる。

「VM内は利用者の責任」という分担は、事業者が共通管理基盤を適切に管理することを前提とする。共通管理基盤が侵害されると、利用者がVM内で行える対策だけでは防ぎきれない場合がある。

• IDCF： 攻撃者はハイパーバイザー側から仮想サーバーを停止し、仮想サーバー自体を暗号化した。ゲストOSのパッチ、EDR、パスワード管理をどれだけ徹底しても、VMの外側からの暗号化は防げない。
• GMO： 自動売買を無人で動かすには、口座のログイン情報をVM内に保存せざるを得ない。事業者側のシステムが破られれば、この情報を利用者が守る手段はほぼない。

利用者にできるのは、侵入を防ぐことではなく、被害を小さくすることである。管理基盤から独立したバックアップ、別の基盤での再構築手順、口座側の多要素認証や出金制限がこれに当たる。IDCFの事案では、シックス・アパートが別基盤（Google Cloud）に置いていたバックアップで翌日中に暫定移行を終え（同社第3報）、サイバー大学も独自に取得していたバックアップで別基盤に再構築した（同大学第3報）。

ここから導かれるのは、責任共有モデルを「利用者はここから上」という線引きだけで説明することの限界である。線の下を事業者がどう守っているかが示されなければ、利用者は自分の分担を果たしても安全を評価できない。

5. 日本のIaaS/PaaS事業者への問題提起

世界の調査では事業者起因の脅威が重大脅威の上位から外れ、利用者起因の脅威が重大になっている一方で、国内では事業者側のシステムに起因する侵害が1か月に2件起きた。この差を個別の事業者の問題として扱うのではなく、業界全体の課題として次の問いを検証すべきである。

#	論点	事案で見えたこと	事業者への問い
1	管理プレーンの到達性と分離	IDCF：インターネットに面した顧客ポータルの認証から、ハイパーバイザー管理者権限まで到達できた	顧客向けの入口と運用者の管理系は、ネットワークと認証の両方で分離されているか。運用者の管理系はインターネットから到達できないか
2	特権の持ち方	IDCF：仮想化基盤の管理者権限を奪われた結果、1リージョンの4ゾーンが同時に停止・暗号化された	特権はゾーンやセル単位に分け、必要なときだけ付与し、フィッシング耐性のある多要素認証と操作監査をかけているか
3	外部部品の脆弱性管理	IDCF：診断の対象は自社開発部分で、OSSは対象外だった。再発防止策でSBOM化を挙げた	管理基盤を構成するOSSや商用製品を含め、部品を把握して脆弱性情報と突合できているか。公開から悪用までが短くなるAI時代の速度に間に合うか
4	共通要素の個別化	GMO：攻撃者は全VM共通の管理者アカウントを突いたと主張（未確認）	VMイメージの初期アカウント、管理エージェント、接続設定をVMごとに個別化しているか
5	復旧手段の分離と既定値	IDCF：バックアップの取り出しが可能と判明したのは206顧客。有償バックアップのイミュータブル機能は申請制で、初期状態では無効	管理基盤が破られても残る復旧手段を、既定で提供しているか。その分離の程度を利用者に説明しているか
6	透明性と第三者保証の範囲	両社とも、管理基盤の統制は事案後まで利用者から見えなかった	管理プレーンの統制をCAIQやSTAR、ISMAPなどで開示し、監査の範囲に含めているか
7	下流への説明責任	IDCF：利用者の公表が事業者の第1報より先行した。利用者のその先の顧客まで漏えい可能性の公表を強いられた	利用者が自らの顧客へ説明できる速さと粒度で、情報を出せる体制があるか

ここで問うべきは、個別の対策の有無よりも、事業者起因の脅威を「重大ではない」水準に抑えていると、国内事業者が利用者に示せるかどうかである。IDCFは自社サイトでIDCFクラウドを「ソブリンクラウド」として打ち出している。国内事業者の価値が「国内にあること」にあるなら、その信頼は管理基盤の統制で裏付けられている必要がある。

6. 利用者・調達側への示唆

第5章で見たように、事業者起因の脅威が「重大ではない」水準に抑えられているかどうかは、現状では利用者から確かめにくい。事業者がそれを示せるようになるまでは、利用者は、事業者の管理基盤が破られる事態を「想定外」ではなく、設計上の前提として扱う必要がある。あわせて、事業者が示す情報を調達時に確かめることが、利用者の側からできる働きかけになる。

1. 管理基盤から独立した復旧手段を持つ。 事業者のバックアップサービスでも、別拠点への保管、イミュータブル機能の有効化、論理的な分離といった条件を満たし、本番環境の管理系が破られても消されないものであればよい。条件を満たせない場合は、別の事業者に保管する。いずれの場合も、別基盤での再構築を訓練しておく。
2. 調達時に管理プレーンを尋ねる。 CAIQでは、IVS-06（区分と分離）、IAM-09・IAM-10（特権の分離と期限付き付与）、IAM-14（強固な認証）が事業者の担当とされているか、実装の説明が記入されているかを確認する。CAIQは自己評価なので、第三者監査の報告書で、監査の範囲に顧客ポータルや運用者の管理系などの管理基盤が含まれているかも確認する。第5章の問いは、CAIQで足りない部分を補う追加質問として使える。
3. 委託先のその先を把握する。 IDCFの事案では、メール配信などの委託先がIDCFを使っていたことを、多くの利用企業が事案後に知ったとみられる。
4. 認証情報はできるだけVMに保存しない。 パスワード、APIキー、外部サービスや取引口座のログイン情報などは、VM内に保存しないことが望ましい。管理基盤が破られると、VM内の情報は外側から読み取られうるためである。自動売買のように保存せざるを得ない場合は、その情報が盗まれてもできることを、接続先のサービス側で絞っておく（権限の分離、接続元IPの制限、出金先の固定など）。

SaaSが主戦場であることに変わりはない。ただし国内SaaSには国内IaaSの上で動くものも少なくなく、IaaSの管理基盤の侵害はそのままSaaSの停止として現れる。今回のIDCFの事案がその実例である。

7. まとめ

CSAの重大脅威調査が示すのは、事業者起因の脅威がなくなったことではない。脅威としては残っているが重大度の上位から外れ、相対的に利用者起因の脅威が重大になった、ということである。2026年10月のIDCFクラウドとお名前.com デスクトップクラウドの事案は、この傾向が日本の国内IaaS/PaaS事業者にもそのまま当てはまるかを問い直している。

2件に共通するのは、利用者の設定ではなく事業者側のシステムの問題が原因だったことである。IDCFでは、利用者ごとに分離された環境を束ねる共通管理基盤が破られ、多数の利用者に一斉に影響が及んだ。共通管理基盤が侵害されると、利用者がVM内で行える対策だけでは防ぎきれない。クラウド環境における責任範囲として「VM内は利用者の責任」とする分担は、事業者が共通管理基盤を適切に管理することを前提としている。

国内事業者に求められるのは、この前提が成り立っていることを利用者に示すことである。具体的には、管理プレーンの分離と到達経路の制限、特権の分割、外部部品を含む脆弱性管理、共通要素の個別化、管理基盤から独立した復旧手段、そして管理基盤の統制の開示である。

利用者と調達側は、事業者の管理基盤が破られる事態を設計上の前提として扱い、復旧手段の独立性と管理基盤の統制を調達時に確認する必要がある。主戦場がSaaSに移った今も、その足元にあるインフラの管理基盤は、事業者と利用者の双方が改めて点検すべき対象である。

付録：事実関係の確度

このブログの記述	区分	根拠
ポータル認証システム（OSS）の脆弱性 → 管理コンソール → 仮想化基盤の管理者権限	公式に確認済み	IDCF第7報
IDCFがOSSを脆弱性診断の対象にしていなかった	報道	NHK（piyolog経由）。第7報の再発防止策（診断対象をOSSに拡大）と整合
IDCFでバックアップの取り出しが可能と判明したのは206顧客	公式に確認済み	IDCF第5報（194顧客）、第7報（206顧客）。取り出し可能と判明した数で、復旧が完了した数ではない
GMOで不正プログラムが確認されたのは一部の顧客の環境。全プラン停止は被害拡大防止の措置	公式に確認済み	GMO第1報
GMOで顧客情報の外部持ち出しを確認	公式に確認済み	GMO第4報。情報の種類と件数は未公表
GMOが独立したクラウド基盤上の代替サービスへの移行を案内	公式に確認済み	GMO第4報
GMOで社内から事前に課題が指摘されていた	代表の説明	熊谷代表のブログ（10月25日）。週刊アスキーの報道経由で確認
GMOの侵入経路、破られた層	未公表	GMOは「システムにセキュリティ上の問題が存在」とするのみ
攻撃者の主張（IDCF：7分で暗号化、239台のハイパーバイザー等。GMO：全VM共通の管理者アカウント等）	未確認	いずれも事業者は裏付けていない。本文では数字を根拠に使っていない
IDCFバックアップのイミュータブル機能は申請制で初期無効	公式文書	筆者が以前に確認したサービス範囲記述書。今回は再確認していない
重大脅威の傾向が国内事業者にもそのまま当てはまるとは限らない	仮説	2件の事案からの問題提起。業界全体を比較したデータはない

出典

CSA・CCM/CAIQ

• CSAジャパン「日本語資料集」14 重大脅威関連資料
• CSA「Top Threats to Cloud Computing 2024」
• Campus Technology「Human Factor Moves to No. 1 Cloud Threat」（2024年8月）
• MeriTalk「Cloud Security Alliance Report Lists Top 11 Threats」（2019年）
• CyberArk「The Egregious 11」
• CSA「CAIQ v4 Released: Changes from v3.1 to v4」
• CSF Tools「IVS-06: Segmentation and Segregation」（CCM v4.0）
• CSF Tools「IAM-10: Management of Privileged Access Roles」（CCM v4.0。IAM-09、IAM-14の名称も掲載）

IDCFクラウド

• IDCフロンティア「【第5報】不正アクセスによる障害に関する調査の進捗について」（2026年10月14日）
• IDCフロンティア「【第7報】不正アクセスに関する調査結果および今後の対応について」（2026年10月27日）
• IDCフロンティア トップページ（「ソブリンクラウド」の打ち出し）
• piyolog「IDCFクラウドへのランサムウェア攻撃についてまとめてみた」
• シックス・アパート「Movable Type クラウド版」障害の第3報（2026年10月9日）
• サイバー大学 第3報（2026年10月15日）

お名前.com デスクトップクラウド

• GMOインターネット 第1報（2026年10月21日）
• GMOインターネット 第2報（2026年10月22日）
• GMOインターネット 第4報（2026年10月24日）
• 週刊アスキー「GMO熊谷代表、不正アクセスで謝罪 事前に弱点指摘も防げず」
• piyolog「お名前 .com デスクトップクラウドへの不正アクセスについてまとめてみた」

以上

日本クラウドセキュリティアライアンス　業務執行理事
勝見　勉

数日前、ちょっと興味ある調査レポートを見つけたので、ご紹介します。タイトルは”How IT and Infosec Value Privacy”というもの。直接訳せば「プライバシにとってITと情報セキュリティはいかなる価値があるか」となります。ちょっと私の思いも加味して、このようなタイトルに変えてみました。

調査は、IAPP(International Association of Privacy Professionals)とTRUSTeが2015/12~2016/1に実施したもので、550人以上の専門家に対するアンケート調査結果をまとめたものです。専門家の内訳は、プライバシ関係が65%で、ITと情報セキュリティを合わせて35%の比率です。

ここで、この両者って、そんなに厳密に区別されているものなの？という疑問が、早くも湧くかもしれませんね。はい。多分この調査の主対象であるアメリカでは、あるいは多分ヨーロッパでも、両者はかなり別のものとして認識されているようです。調査内容を紹介していくと、ちょっと垣間見えてきます。でも、日本では、「プライバシ」と「個人情報」を余り区別して考えてないですよね。そして情報セキュリティと言えばほとんどの場合、個人情報漏洩対策がイコールのイメージになっている、っていう感じがしませんか？この辺からして、日本の感覚は違うのだと感じています。

ちょっと脱線ですが「個人情報」には「個人識別情報」と個人に関わる「機微情報」または「秘密情報」（まとめてほぼイコールプライバシ情報）とがあります。個人識別情報は、一般的には、個人と社会との接点で個人を識別するために必須の情報で、必要に応じて提供し、提供を受け、開示し、伝達し、記録されます。これを拒むと、社会生活はなかなか厳しいことになります。

一方で、個人識別情報といえども、他の情報と組み合わさることでプライバシ情報に転化します。ここが個人情報のややこしいところですが。例えば電車の定期券を買うのに、氏名住所生年月日などを提出します。個人識別ができないと定期券は発行できないからです。一方、氏名住所と、どこからどこまでの定期券かを組み合わせると、その本人の居住地域や勤務先の所在地がある程度推測できます。この辺からプライバシに関わる要素が出てくるので、電鉄会社は定期券の発行情報を、管理すべき情報として扱う必要が出てくる訳ですが。一方で、この両者が結び付くことで、落とした定期券が持ち主に戻ってきたりすることも可能になるので、やたら匿名化すればいいというものでもない、というところも、理解できると思います。

閑話休題。この調査はまず、「プライバシと情報セキュリティは重なる部分も別々の部分もある。ちょうど鎖の輪か、「ベン図」のように」と言っています。では両者は組織の中でどのように協業できるのか？ここから調査の問題意識は始まる訳です。（ところで日本では、両者が別のチームになっている組織ってかなりまれだろうとは思いますが。。。）

一番鍵となる質問「情報漏えい事故への対策として何が重要ですか？」に対しては、総合1位の答えは「プライバシチームとセキュリティチームの間のコミュニケーション」でした。第2位には「インシデントレスポンスへのプライバシチームの参加」となり、両者間の緊密な連携が最重要視されています。更には、情報漏洩対応専任チームの設置も重要度大となっています。プライバシとセキュリティが別のチームであったり、セキュリティ（インシデント）でなく「情報漏洩対応専任」チームの存在であったり、日本の実情とは大きくかけ離れた、先進的取り組みの実態を見る思いですね。

また、データを最小に保つことや、データの棚卸しとマッピング、つまりどんなデータがどこにあるかを把握しておくことも、対策チームに次いで高い重要度スコアを得ています。更に、社員に対する教育とトレーニングも重要視されています。教育とトレーニングを分けて考えるところも、示唆に富みますね。単に知識を注入する「教育」だけでは不十分で、それを実践に移せる、いざという時現場での対応に活かせるための「トレーニング」の大切さへの認知が浸透していることを伺わせます。

（＊https://iapp.org/resources/article/infographic-how-it-and-infosec-value-privacy/ から引用）

さて、もう一つの興味深い分析をご紹介しましょう。「情報漏洩対策の強化に、事故経験と規制当局の関与のどちらがより影響がありますか？」…こちらの答えは意外にも、日本の事情と似た結果になりました。すなわち、事故経験よりも規制当局の関与の方が効果があるという結論になったのです。

事故を経験した結果では、対策重点は余り変わりませんでした。チーム間コミュニケーション、従業員や役員のトレーニング等々。一方、規制当局との何らかの接触を経験した場合は、プライバシ対策費を増加させたり、チームを増強したり、プライバシープログラムの充実を図ったりしています。当然にも規制当局との関係強化に動く一方、意外にも、個人のプライバシ資格取得や、外部の専門家の活用には余り積極的になっていない、との分析結果が紹介されています。

（*　https://iapp.org/resources/article/how-it-and-infosec-value-privacy/　から引用）

より詳しい内容を知りたい方は、以下のサイトにアクセスしてみてください。フルレポートが載っています。また要約版サイトへのアクセスも載っています。

https://iapp.org/resources/article/how-it-and-infosec-value-privacy/

アメリカでは、プライバシ対策の認知は日本より浸透しているようです。そしてその面では、規制当局の存在や関係構築に対する意識も強いようです。日本はどのように成熟していくものやら。やっとプライバシーコミッショナーも置かれたところなので、これからなのかも知れません。

日本クラウドセキュリティアライアンス
業務執行理事　諸角昌宏

9月25日に行われた第16回CSA勉強会では、ID管理に焦点を当ててエクスジェンネットワークス株式会社　江川淳一氏と日本ビジネスシステムズ株式会社　宮川晃一氏に講演していただきました。非常にわかり易くまとまった内容で、最新のID管理の背景、状況、そして、今後の動向について説明していただきました。ここでは、その要点をピックアップして書いていくが、ID管理の奥の深さに対してうまく伝えられるかどうか、いささか心もとない。2週間後くらいに一般公開される本勉強会の資料をぜひご覧いただいて、理解を深めていただきたい。

1. ID管理とクラウド
   クラウド利用の拡大に伴い、クラウド上に機密情報を置くことが増えている。そのため企業のセキュリティ・ポリシーも変化してきている。今までは、ファイアウォールの中でのポリシーであったが、クラウド利用により機密情報がファイアウォールの外に出ていることを前提としたポリシー設定およびセキュリティ対策が必要となる。このような状況においてID管理として必要となるのが連携（フェデレーション）技術で、機密情報の一部を社内（オンプレミス）に残してセキュリティを守り、必要最低限の情報のみをクラウドに移行するという方法である。ID管理としてIdP（Identity Provider）とRP(Relying Party)を置き、IdをIdPで一括管理していく。このIdPをオンプレミスに置くかあるいは信頼できるクラウド事業者に置くことで、ID情報の機密を守っていくことになる。
2. プロビジョニングの必要性
   個人ベースであれば、ID情報の登録、変更は容易に行えるが、企業となると一括して事前登録や変更が行えることが必要になる。また、共有を必要とするシステム（スケジューリングや営業支援など）では、属性情報などを事前に配布しておくことが必要である。また、IDライフサイクル管理や内部統制対策としての統一したID管理としてプロビジョニングが必要になる。
3. 認証基盤システム
   以上のように、企業としてはID管理の基盤を必要とする。その理由は以下の4点である：
   – ユーザ利便性の向上
   – 管理効率の向上
   – 管理品質の確保
   – セキュリティリスクの低減

   では、実際にどのような基盤を用意するかであるが、以下の3つの要素に基づいたシステムを構成する必要がある：
   – ID情報マスターDB
   – IDM（IDライフサイクル管理、フェデレーション）
   – SSO（シングルサインオン）

4. IDaaS
   IDaaS（ID as a Service）は、SaaSに対するSSOを実現する専業のIDaaSのサービスとして展開されている。特に欧米では、社内のADとの双方向連携（オンプレ->IDaaS,　IDaaS->オンプレ）を行い、ID管理を含めてSSOを実現している。 さて、問題はIDaaSが日本で普及するかということであるが、欧米と違いID管理のところをどのように実現するかという問題がある。日本では、人事が所有している源泉のID情報をもとにID管理を行う必要があり、全体的なワークフローあるいはCSVでのやり取りを含んだ日本型IDaaSが必要になる。EXGEN社では、extic（EXGEN Trusted Identity Service）により、この日本のエンタープライズクラウド市場で要求されるIDaaS構成への対応を進めているとのことである。
5. 情報共有機会の増大に対する認証方式
   最後に、まったく違う企業間での情報共有（サブライチェーン、Industry4.0など）に対する認証をどのようにしていくかという問題がある。他社のIDまで管理することは実際には難しく、IDを発行することなしに認証を行うフェデレーション技術が重要になってくる。今まで述べてきたように、フェデレーションはクラウド環境では非常に有効なソリューションであるが、情報共有においても非常に有効である。簡単に言うと、IdPさえ立ててしまえば、それに基づいて認証し情報共有ができることになるからである。

以上のように、フェデレーションを中心としたID管理および認証基盤は今後益々重要になってくる。また、IDaaSの利用も拡大していくであろう。IDaaSについては、どのように信頼できるプロバイダを選定していくかが鍵になり、サービス契約をどうしていくか、また、リスクをどこまで取っていくことができるかを総合的に評価し利用していくことが必要である。

次に、JNSAのアイデンティティ管理WGの活動について、簡単に説明する。

まずWGの目的であるが、「アイデンティティ管理における、様々な課題をＷＧ討議の中で検討し、必要性の啓蒙および導入指針の提示による普及促進、市場活性化を目的に活動している」ということで、クラウド環境での適用も含め非常に幅広く活動を行っている。メンバーも43名ということで、WGとしては多くの方が参加している。今までの成果物には、　「クラウド環境におけるアイデンティティ管理ガイドライン」という書籍を出版し、また、「エンタープライズロール管理解説書」をウエブページから公開している。

2015年として、6つのテーマを掲げており、特に「IDの融合と分離の課題検討」を進めている。また、「ID管理チェックリスト作成」を新たに開始している。これに対しては、CSAジャパンも協業しており、一緒に活動していきたい。

JNSAのアイデンティティ管理WGでは、非常に深い議論・検討が進められているので、興味のある人はぜひ参加して貢献していただきたい。

以上、この分野は非常に奥が深くまた変化も激しいので、CSAジャパンとしても継続して勉強会等を通して情報を発信していきたいと考えている。

2015年2月19日
日本クラウドセキュリティアライアンス事務局長
勝見　勉

医療情報セキュリティセミナーin八王子に行ってきました

CSAジャパンの代表理事である笹原英司さんは、ITセキュリティの専門家ですが、「医薬学博士」の学位を持っているというスゴイ人です。そしてまたその活躍の場も、古くは労働省とか、世界的リサーチファームとか、そして今は在日米国商工会議所のヘルスケアIT小委員会委員長であったりして、とにかく広い!!　更にはNPOヘルスケアクラウド研究会の理事でもあります。そしてわがCSAジャパンでは代表理事を引き受けるとともに、「健康医療情報管理」「ビッグデータ」「モバイルユーザ」の3つものワーキンググループのリーダーも引き受けてもらっています。

そんな笹原さんのリーチの広さを改めて知ったのが八王子におけるセミナーでした。会場は「コワーキングスペース8Beat八王子」という、起業家や市民活動の人や同好グループに活動の場を格安で提供している、コミュニティハウスみたいな場所で。集まった人たちも、IT周りでコミュニティ活動をしているCode for Hachiojiとかそういった仲間。濃くてアットホームな雰囲気の中で、笹原さんの2時間の熱演がありました。

講演タイトルは「健康医療分野の海外サイバーセキュリティ最新動向」。内容は「健康医療分野のサイバー攻撃に起因する海外の情報漏えい事例」「健康医療のセキュリティ／プライバシー規制とサイバーセキュリティの動向」「健康医療へのシビックテクノロジー適用とセキュリティ／プライバシーのリスク」と、とても濃いんです。

まず、アメリカでの、サイバー攻撃による医療情報流出の事例ですが、今月になって発覚したAnthemの8000万件の漏えい事件は衝撃的です。笹原さんもまずはこれを取り上げました。盗まれた情報には、名前、誕生日、医療ID、社会保障番号、住所、メールアドレス、雇用情報、収入データが含まれるとのこと。社会保障番号は実質個人番号ですから、それと名前、住所、生年月日が分れば、完璧になりすましされてしまいますね。この他にも数百万件に上る医療情報漏えいが、サイバー攻撃や盗難によって起きているようです。

また、年末世界的に注目を集めたソニー・ピクチャーズの情報漏えい事件では、セレブの情報などが関心を呼びましたが、従業員の保健情報も盗まれていて、被害に遭った従業員からの集団訴訟も起きているとか。またアメリカの集団訴訟は、賠償が決まれば全被害者が対象になるので、1件は少額でも莫大な金額になりやすいのだとか。この辺はさすがに、専門的で詳しいな、と脱帽でした。

健康医療のセキュリティ／プライバシー規制の話では、米国のHIPAAとHITECHを説明してくれました。HIPAAは1996年に成立していて、サイバーリスクが注目されるより前から、情報保護への対応は進められている、と指摘してくれました。連邦プライバシー法制がないなど、取り組み姿勢が強いとは思われていないアメリカが、割と早くから手を打っているのは意外で、さすがよく見ておられると、またまた感心させられました。

さて、こう書いていくと、何せ2時間の熱演なのでとても紙数が足りません。幸い、資料をCSAのwebで公開して下さったので、後は皆さん、直接資料から学んで下さい。そしてもっと知りたければ、「健康医療情報管理」ワーキンググループに参加されてはいかがでしょうか。
http://www.cloudsecurityalliance.jp/healthcare_wg.html