まず「金融機関等コンピュータシステムの安全対策基準・解説書」（以下、FISC安対基準）を縦に見てみよう。前出の記事にも掲載されているが、FISC安対基準には約300項目が掲載されている。大きく分けて、設備（データセンターなど）、運用（体制、管理など）、技術（システムの信頼性など）の3分類から成っている。重要なのはこの縦の網羅性である。システムの安全性を確保するための項目が、MECE（Mutually Exclusive and Collectively Exhaustive：無駄なく漏れなく）に列挙されており、極めて価値が高い。金融機関に限らず、一般の事業会社においても同基準を採用する事例が多いことが理解できる。

　セキュリティリファレンスは、これらのうち、本店・営業店の施設、ATMの設置など、クラウドコンピューティングとは無関係と思われる部分を除く約250項目を対象としている。

　次に、横に見てみよう。実はFISC安対基準が、システムの安全性に関する実装レベルを全て詳細に示しているわけではない点に注意したい。ここで示されていることは「○○は監視しなさい」とか「○○はテストしなさい」などの、いわば当然のことが列挙されているのみだ。具体的な実装基準は基本的に（FISC安対基準の）利用者（金融機関や一般企業）が自分で策定する。その「深度」はシステムの重要度に応じて企業が独自に判断することになる。

　以上が、FISC安対基準の縦と横だ。換言すると縦は「安全対策を実施すべき対象」を最大限示し、横は「その安全対策の適用にあたっての考え方」と例を示すフレームワークである。このとき、企業側が考えるべき事柄がある。まず縦の項目の取捨選択である。システムの特性を考慮して、明らかに関係のない項目は対象外としてよい。次に横の深度である。例えば「○○を監視をする」という項目について、実装レベルでは「ログを保管しておく」とするのか、「毎晩、ログをチェックする」のか、「リアルタイムで異常がないかモニタリングする」のか、監視のレベルにはさまざまある。対象となるシステムの重要性に応じて、どのレベルが適切かを判断し、実装することになる。

セキュリティリファレンスの大きな見方

　では、セキュリティリファレンス本体を見ていこう。まず縦方向だが、FISC安対基準の小項目ごとに1対1対応している。小項目はリスク管理すべき具体的な単位である。ここでは項目に対応する（実装する）主体は誰なのかという観点で「責任分界」という概念が重要だ。次の3種類がある。

図表2　責任分界の考え方

　どの項目が上記の3種のいずれに該当するのかは重要である。この責任分界を明瞭に示したということだけでも、セキュリティリファレンスの大きな成果といえる。今後の解説の中でも触れていくので留意していただきたい。

　では、いよいよセキュリティリファレンスを横に見てみる。ヘッダ部が色分けされているので左から順序良く説明していく。全体はおおむね図表3のような4つのブロックから成っている。

図表3　セキュリティリリファレンスのヘッダ部の解説

1. FISC安対基準からの引用転記
2. AWS側の対応について
3. 利用者側の対応について
4. 利用者側の対応のうち、クラウド特有の対応について

　上記の順序に従って説明を進める。

1．FISC安対基準からの引用転記

図表4　FISC安対基準からの引用転記部分《クリックで拡大》

　この部分は全てFISC安対基準の引用から成っている。ここで重要なのは、（5）と（6）だ。（5）が特定すべき「リスク管理項目」、（6）が「適用にあたっての考え方」を示している。（5）は各項目の趣旨に該当し、どのようなリスクや懸念を対象としているのかを明確にしている。（6）の記述には2種類あり、語尾が「～する」となっているものと「～が望ましい」となっているものがある。（7）はこれを記号で表示しており、「する」を必須の意味で「◎」「望ましい」を「○」で表示している。

2．AWS側の対応について

図表5　AWS側の対応状況部分《クリックで拡大》

　ここからがセキュリティリファレンスの実質的な本体である。まずはクラウド事業者（AWS）側の責任分担についてである。

　ミントグリーンの（1）は、FISC安対基準の各項目（中項目単位）に対するAWSの公式見解を表している。この公式見解は、実はFISC安対基準のために用意した回答ではなく、米国のCSA（※1）が主要クラウド事業者に対して行ったサーベイ「CAIQ」（※2）への公式回答である。CAIQの質問の粒度はFISC安対基準の中項目にほぼ対応しているが、AWSはその全てに対し包括的な回答を行っており、日本語版も公開している（PDF：「Amazon Web Services：リスクとコンプライアンス」付録A）。本セキュリティリファレンスでは、その回答をFISC安対基準の順序に従って並べ替えている。赤い（2）は、このリファレンス全体から見て適否結果を記載したものだ（当然、対象項目は全て適合可能となっている）。

※1　Cloud Security Alliance。日本支部サイトはCSAJP。

※2　Consensus Assessments Initiative Questionnaire

　オレンジ色の（3）は、AWSに責任分担があることを示している。図表2でAWSの責任分担に○が付いている項目は、ここに○が付与される。

　（4）は（3）に関する文書の公開状況を表す。一部は、非公開情報によるもの（本リファレンス作成者とAWS間でNDAを交わし、作成者側で問題がないことを確認したもの）もあり、その旨が表示されている。（5）（6）はその内容と、公開文書へのリンクが示されている。（7）は本セキュリティリファレンスのVer1.0では非公開としていた項目だが、Ver1.1で公開となった項目である。AWSが取得している第三者認証の取得状況から対応状況が類推できる場合に、その根拠を示している。

3．利用者側の対応について

図表6　利用者側の対応部分

　続いてユーザー側（AWSを利用する企業や、AWSを自社のサービスとして提供するSIerなど）の責任分担について記述されている部分について見ていこう。青の（1）は、ユーザー側で対応が必要な項目について○が付与されている。図表2でユーザーの責任分担に○が付いている項目は、ここに●が付与される。

　（2）は、ユーザー側の対応についてパターン分けを行っている。パターンは3種類あり、以下の通りである。

図表7　利用者側対応のパターン

　（3）は図表7「対策例の記載方法」に準じた内容を記載している。

4．利用者側の対応のうち、クラウド特有の対応について

図表8　クラウド特有の対応部分（例：運用27 バックアップを確保すること）《クリックで拡大》

　図表7のパターン2については、「AWS特有の対応方法」を利用すると効率よく実現できる。どのような機能やサービスを利用すればよいのかという点を明示したものが図表8である。

　クラウドで一般的に対応する方法を（1）～（5）に列挙し、AWSが持っている機能を（6）～（17）に列挙した。ユーザーがパターン2の対応で使うべき機能を、○（必須）や△（推奨）で明示している。

　例えば「運用27 バックアップを確保すること」では、AWSのAPI、IAM、Muti-AZ、EBS／SnapShotを使うと便利であることが図表8の例で示されている。

　以上でセキュリティリファレンスの縦と横が明確になった。これで全体構造が理解できたことになる。次回はいよいよ幾つかのリスク管理事項について具体的な読み解きの例を解説する。

渥美俊英（あつみ としひで）

電通国際情報サービス クラウドエバンジェリスト

90年代からインターネットバンキング、電子認証、セキュリティの技術開発を担当。最近は、企業システムにおけるフルクラウド化を推進中。クラウド利用促進機構（CUPA）総合アドバイザー、オープンソースビジネス推進協議会（OBCI）副理事長、Seasarファウンデーション理事。