図1　CSAのSecurity Guidance for Critical Areas of Focus in Cloud Computing v2.1を基にした既知のリスクをガバナンス視点でレイヤー分けした図

　筆者は今回、アーキテクチャは情報ライフサイクル管理とセキュリティを構成する各ドメインを包含してデザインされている必要があり、その実装は法令を順守し、各種規格に基づく監査に耐えられなければならないと提案したい。ここに財政規律ドメインを加え事業継続性や災害対策として対応可能な程度が決定され、人材ドメインを加えて全体としてのガバナンス＝リスク管理の水準が決定されるだろう。

　物理セキュリティと事業継続・災害対策を同一ドメインで処理するCSAの整理は利用者視点では適切であっても実装まで範囲に入れた場合これは乱暴であると考え分割している。また、CSAの定義する仮想化ドメインはアーキテクチャに包含可能と考え記載を省いている。このモデルではアーキテクチャに包含される層がツールで処理される範囲を表し、それ以外の層がルールで処理される範囲を表している。

　なお、この整理はNIST定義準拠を前提として、アーキテクチャレベルでかなり多くの制約条件を負う点を留意願いたい。

　利用者視点で見るなら、アーキテクチャに包含される各ドメインのリスク情報は、外部からは監査結果（含む適合認証）とSLA（Service Level Agreement）の形で観測可能であるべきだ。事業継続性や災害対策については決算短信などのIR情報が活用できる上場企業または、電気通信事業法などの各種業法に基づいて公的機関に報告義務を負っている企業ならば観測可能だ。しかし、最終的にガバナンスを担保する人材については、観測が企業の役務である場合、有効な観測方法が現時点では存在しない（開発のみならず運用まで含めてオープンなオープンリソースとでもいうべき役務提供形態でも出現すれば話は違ってくるのだが）。ちなみに、今回掲載しているモデル整理は前回列記した諸規格の認証取得条件に照らしてみても少々厳しめにしている。例えば事業継続マネジメントシステム標準である事業継続性（BCMS）は認証取得に当たって財務要件は課していない。

事業者の安全基準を測るポイント

　ともあれ、利用者は取引を検討している事業者が提供する役務が、

• 各リスクドメインについて対応する機能を持っているか？
• 機能について、全般的な品質（QMS）、情報セキュリティ（ISMS）、可用性（ITSMS）、事業継続性（BCMS）といった各着眼点でPDCAサイクルを文書化して回し改善することを組織文化に定着させているか？
• 認証の取得範囲は？　事業者はSAS70や18号監査、さらに今後はISAE3402報告として利用者に認証内容などを提出可能か？
• 利用者への認証内容の提出に当たっての条件は？

といった観点で自身の要求と候補となる役務の内容や取引条件を比較することで、少なくとも既知の地雷＝リスクを踏むことが避けられる。もっと言うなら、どの地雷を踏むかを利用者責任で決断できる。もう一歩踏み込んで特定の利用目的、例えばクレジットカード情報とその取引情報を取り扱いたい場合はPCI DSS認定といった追加要件を付加して検討していけばよい。ただし、PCI DSS認定などについて、事業者視点で実装デザインを検討する場合、要件追加はアーキテクチャ制約の増大を伴うし、Rapid elasticityされた仮想資源上で組んだシステムで利用者が独自にPCI DSS認定を取得しようとすると非常に多くの問題に直面する（この件については別の機会に解説する）。

利用者と事業者の責任分界点

　ざっとチェックするべきポイントの種類と構造について眺めたところで、利用者と事業者の責任範囲がどこで区切られるのか（これを責任分界点という）、連載第1回「“オレオレクラウド”にはこりごり、クラウドの本質を知る」に記載したNIST定義モデルを使ってIaaSのケースを表してみる（図2）。

図2　NISTの定義モデルを使ったIaaSの責任分界点

　利用者がクラウド基盤をOn-demand Self-Serviceとして利用するインタフェースとなるWebサービスの安全はBroad network accessの利用者側までとなる。Rapid elasticityされた各種仮想資源の安全は、Resource poolから切り出された各種資源のバックエンドとMeasured Serviceとの接続点までについて事業者側が責任を持つことになる。裏返すとOn-demand self-Service接続するID管理などと、Rapid elasticityされた各種仮想資源の管理責任は利用者が負う。実は個々の要素に分解してしまえば目新しい要素は存在しない。

　ガバナンスの観点で見るとオンプレミスシステムで全リスクドメインを統治できていた利用者なら、何ら抵抗なくクラウドが利用できることが分かるだろう。要するにオンプレミスからクラウド（IaaS）への移行は利用者システムの低位層についてバリューチェーンを外延しているにすぎない。ただし、Rapid elasticityとMeasured Serviceを前提としたバリューチェーンの外延であるためにバリューチェーンを構成する利用者、各事業者が各種認証取得、ISAE3402報告対応するなどの管理・運用水準の開示体制（取引条件の明確化と解することもできる）を整備してガバナンス体制を「見える化」し、バリューチェーンを迅速に拡張、組み替え可能にしていく必要がある点に特徴があるといえる。もちろんRapid elasticity要件を緩めれば管理・運用水準をリアルタイムに判定する必要はなくなるが、将来的にはこういったガバナンス仕様と運用実績とでもいった情報はリアルタイムに交換されるようになるだろう。

　このような動的バリューチェーンとでもいう機能の実装を考慮するなら認証認可系ではSAMLなどを使ったtrusted circleや、より柔軟なXACMLのルールなどの採用が考えられるだろう。マシンイメージやその制御、管理についてはDMTF OVFやSM CLP、CIMI CIM、情報ライフサイクル管理についてはSNIA CDMIが有力だ。伝送路の制御、管理については昨今話題のOpenFlow（参考：次世代データセンターネットワークを実現、OpenFlowとは何か？）の他にもVRFやVXLAN（参考：「VXLAN」入門──VLANを拡張する新標準とその必要性）など魅力的な技術が出てきている。プロセスモデルまで踏み込むならCIMやCDMIとTMF SIDの互換性を確保してTMF eTOMに収容する方法に期待している。とはいえ、バリューチェーンの組み替え、もっと言うならクラウド事業者の使い分け、に踏み込むとまだまだ乗り越えなければならない課題が多い。このあたりの話題も今後取り扱いたい。

　さて、ここでようやく冒頭の疑問に答える準備ができた。クラウドは安全か？　この問いの基となった経済産業省企業IT動向調査結果を踏まえ、オンプレミスと比較してクラウドは安全か？　とすれば、比較対象となるオンプレミスシステムのガバナンス体制と同等以上のガバナンス体制を持つ事業者を利用し、バリューチェーン全体のガバナンスを維持すればオンプレミスより安全であると期待できる。しかし、ここまで読み進んだ方なら既にご理解いただけているはずだが、この問答にあまり意味はない。クラウド、オンプレミスを問わず、システムの安全がどの程度確保できるかはバリューチェーン全体をどのように統治しているかにかかっている。冒頭の調査結果にあった利用企業の不安を払拭するには事業者側が今後どれだけ自身のガバナンス体制について説明責任を果たせる体制を整備し公開できるかにかかっている。

情報セキュリティのインシデント

　ここまで簡単にリスクドメインと責任分界点について整理してきたが、実際に発生しているインシデントはどうなっているのだろうか？　リスクドメインを網羅したインシデント統計はまだ存在しないので、JNSAの情報セキュリティインシデントに関する調査報告書（2010年版）を紹介する（図3）。

図3　JNSAの情報セキュリティのインシデント調査結果

　この調査によると、2010年の漏えい人数は557万9316人、インシデント件数1679件、想定損害賠償額1215億7600万円、1件当たり平均損害賠償額7556万円になったという。ガバナンスの観点から発生原因に注目すると、管理ミスや誤操作、紛失・置き忘れなど、利用者責任となるインシデントが発生件数の95.3％を占めていることが分かる。今回見てきたように安全なクラウド利用を目指してオンプレミスからの移行計画を策定、実施すると、利用者は自身のガバナンスの「見える化」を要求されるので結果的に統治水準の向上が期待できる。誤解を恐れないならガバナンスを考慮したクラウド利用はJNSAが指摘する従来型インシデントを減少させる効果が期待できる。

　筆者がここで“従来型インシデント”と形容したのには理由がある。クラウド利用が進展し、ポータビリティ・相互運用性が高まり、事業継続・災害対策などの観点も含めて利用者が国を跨いで仮想資源を利用しだすと、法務・電子証拠開示ドメインで、これまで国内で事業が完結してきた利用者にはあまりなじみのないインシデントに直面するようになると予想しているからだ。米国愛国者法（パトリオット法という通称で制定当時、日本でもニュースに取り上げられた）やEUデータ保護指令など、たとえその仮想資源を支えるリソースプールが日本国内にあったとしてもかかわってくる海外の法規が既に存在する。次回以降クラウドと法についても紹介していく。

川田大輔（かわだ だいすけ）

Cloud Architect、クラウド設計屋。18年に渡り大手ソフトウェア／ハードウェアメーカーでのマーケティング、ITベンチャーでの事業開発、技術開発、技術投資業務を経験し、2009年より現職。技術からマーケティングまで包括したICT関連事業の立ち上げを専門にしている。近作はNIST準拠のOSS Cloud Architecture、copse。

本稿での記述内容は個人の見解であり、その責任は全て筆者個人に帰するもので、所属する組織を代表する意見ではありません。