実は「金融機関等コンピュータシステムの安全対策基準・解説書」（以下、FISC安対基準）のどの項目においても、「データセンターの立ち入り検査を行わなければならない」とは記載されていない。前述した議論の根拠の1つと思われるのはFISC安対基準の「運57」という項目だ。ここには次のように記載されている（セキュリティリファレンスに中にも引用してある）。

図表9　「運57」の記載状況

　いかがだろうか。データセンターの場所を特定し、その設備を視察せよとは明記されていない。データセンターの立ち入り検査は必須ではないのである。ここで求められている「考え方」は「定められた方法によって管理する」ことであり、これをクラウド環境で実現するためには、クラウドの特性を踏まえた有効な管理方法を検討する必要がある。

　「管理と実体が一致しているかどうかを確認するためには、やはりデータセンターの立ち入り検査は必須だ」という意見もあるだろう。しかしよく考えてみる必要がある。この考え方はオンプレミス（自社の保有資産であるコンピュータリソースを他社のデータセンターに預ける場合）を想定している。そうであれば資産状況の把握（管理）と実体（データセンター内の物理機器）との一致（の確認）は当然必須だ。

　しかし、クラウドのデータセンター内では、そもそも全ての資産はクラウド事業者のものである。リソースは仮想化されており、サーバの論理的実体は流動的である。仮に自分が利用（管理）している機器類の物理的実体を特定できたとしても、サーバの論理的実体はクリック1つで別の筐体に移動したり消去したりすることが可能だ。このような状態での立ち入り検査は本来の目的を達成する手段としての意味を成さない。

　つまりパブリッククラウドに立ち入り検査をしても「FISC安対基準が想定しているリスク」を軽減できないのである。ここで、立ち入り検査は「手段」にすぎず、重要視すべきは図表9の最下行にある「不正使用、破壊、盗難」などのリスクの軽減という「目的」だということを冷静に思い返す必要がある。立ち入り検査が必須であり、それができなければ何も管理できないという考え方は、クラウドの利用においては手段と目的を入れ違えていることになるのだ。

　話を戻して、FISC安対基準で要求されている「定められた方法によって管理」はどのように行えば適切なのかを解説しよう。セキュリティリファレンスを「横」に見ていけばよい。図表5（1）「FISC安全対策基準に対するAWSの見解」には、AWSは「AWS利用者はゲストOS、ソフトウェア及びアプリケーションをコントロールし、利用者の機器に対する管理を行なう事ができます。またその管理は利用者の責任となります。」と書かれている。セキュリティリファレンスの考えでは、資産の管理はAWSとユーザーと両方の責任分担となる。従って、図表5（3）AWSの「対応状況」には○が、図表6（1）ユーザーの「対応要否」には●が付与されている。ここでは物理層と仮想化基盤など下位レイヤーの管理にはAWS、それより上位のゲストOSなどの管理はユーザーという責任分担となる。

図表10　資産管理の責任分担

　図表10の下側3レイヤーにおいてAWS側が適切な管理を行っていることは確認できる（データセンターの施設の管理については読み解き例2、物理サーバと仮想基盤については読み解き例4で触れる）。では、ユーザー側は何をすればよいのだろう。図表6（3）ユーザーで必要な「対策例」を見ると「機器については、管理責任者を明確にするとともに、関係者以外が容易に接近できない、重要なサーバなどは許可された人のみ操作ができるようにする措置をとる」とある。各インスタンス（＝ゲストOS）にアクセスできる担当者（＝ルート権限者）を特定し、許可された担当者のみがアクセス可能とせよというわけだ。従来的なシステムにおいても当然に行われていた管理手法である。この点については、オンプレミスでもクラウドでも考え方に何ら変わりはない。

読み解き例2　～設備

　前項とも関係が深いが、AWSで頻繁に言われることの1つに「データセンターの場所の開示」問題がある。AWSはデータセンターの場所を開示していない。AWS社員の大半も知らない様子であり、セキュリティ確保の観点から合理的といえる。「顧客に対して何でも開示するのが当然」という一種の感情論や、「開示しないとデータセンターがFISC安対基準に対応できているかどうか確認できない」という説もあり、よく議論になる点でもある。FISC安対基準とセキュリティリファレンスをベースに考えてみよう。

　FISC安対基準において、設備関連は「設01～設83」に記載されている。全般的に設備基準の各項目は、他の運用基準や技術基準に比べると、建屋の構造や電源・空調など実装レベルまで踏み込んだ記述が多い。小項目レベルでは「地震に備えて耐震措置を講ずること」のような大きなことから、「データセンターの所在を示した看板などは外部に出さないこと」のような細かいものまであるが、「場所を特定すること」という趣旨のことは直接的には書かれていない。

　例えば「設34」では、「データセンターの内装が（日本の）建築基準法や消防法に準ずること」という記述がある。これらに対しAWSは、中項目単位（設31～設36）で包括的に問題ない旨を回答している。図表5（3）AWSの「対応状況」によれば、その内容は、「ISO27001 附属書 A. 9.1」あるいは「AWS SOC2 タイプ2レポート」に記載されているとしている。AWSはこれらの認証を取得しているので、「環境的なリスクに対する物理的な保護」は確立しており、さらに第三者によって確認されていることが分かる。

　基本的にはこの回答で十分とも考えられので、ここで非金融機関のユーザー企業が納得するのであれば、この先の検討作業コストを軽減できることになる。

　金融機関などはFISC安対基準の小項目単位でリスクを特定し管理する必要があり、日本の建築基準法や消防法の準拠状況について確認が必要だ（ISO27001やSOC2レポートは日本の法律について記載はない）。セキュリティリファレンスでは、AWSとNDAを交わした上でこの点の確認を行っている。結論から言えば図表5（3）に「◯」とあり、「設34」については問題ないことが確認済みである。確認内容についてはNDA事項でもあり公開版（後述）には記載されておらず、詳細版（後述）に記載していることが示されている（図表5（4））。

読み解き例3　～データの管理（バックアップやアクセス制限）

　施設やコンピュータリソースに関する読み解きに引き続き、データ（ユーザーデータ）の扱いについて説明しておこう。図表10にもあるが、データはゲストOSより上のレイヤーにあり、AWSはデータにはタッチできない。従って、データの管理責任は一義的にユーザーにあることが明確だ。

　FISC安対基準では、「運27」でデータ管理に触れている。記載内容は以下の通りである。

図表11　「運27」の記載状況

　図表11「考え方」の末尾が「～すること」なので、図表4（7）の記号は「◎」（必須）となっている。しかし記載内容をよく見れば、実装レベルを明示しておらず、ユーザーの責任で検討することになる。

　さて、図表5（1）「FISC安全対策基準に対するAWSの見解」を見ると、AWSがデータ管理はユーザーの責任であると述べていることが分かる。よって図表5（3）AWSの「対応状況」は「－」となっており、逆に図表6（1）ユーザーの「対応要否」は●となっている。よって、この小項目の対応は純粋にユーザーの責任であることが分かる。

　ユーザーの対応パターンについて図表6（2）「対応パターン」を見ると、図表7で言うパターン2「AWSのサービスを使って対応可能」であることが分かる。具体的な方法は図表6（3）ユーザーの「対応例」に記載されており、その内容は「通常のシステム運用と同様に、データファイルの授受、保管方法を定め、実施する。」と記されている。ここはFISCの記述を引用している。この点についてはオンプレミスでもクラウドでも考え方に何ら変わりはない。では、これをクラウドで実現（実装）するのはどうすればよいのか。そこから先は図表8を参考に実装することになる。この部分は「クラウド利用の責任分担が分かる、FISC対応リファレンスの見方」でも触れたので、参考にしていただきたい。

読み解き例4　～監視

　最後に「異常事態に備えた監視」について見ていこう。FISC安対基準では「運60」に該当する。

図表12　「運60」の記載状況

　ここでは「異常状態早期発見のため、監視対象、監視内容および監視方法を定めること」という「考え方」が記述されている。図表4（7）は◎であり、この項目に対応することは必須である。

　図表5（1）「FISC安全対策基準に対するAWSの見解」を見ると、AWSは「AWS利用者はゲストOS、ソフトウェア及びアプリケーションをコントロールし、監視手順を定義する責任があります。」と述べられている。ゲストOS（と上位層）についてのみ述べられているが、逆に言うと仮想化基盤についてはAWSに責任があることが示唆される（図表10の通りである）。セキュリティリファレンスでは、この点で責任分担が明確になっていると考えている。

　後の手順は既に見た通りである。

　まず、AWS側は以下の通りだ。

• 図表5（3）AWSの「対応状況」は○（必須）であり、
• 図表5（4）によればAWSの公開文書に関連記述がある。公開文書にはAWSが仮想基盤の管理を徹底していることが記載されている。その内容の一部を紹介すると、
• 図表5（5）にある通り（AWSの内部では）「運用上の重要計測値が早期警戒閾値を超える場合に運用管理担当者に通知されるよう、アラームが設定されています」となる。そのエビデンスとして、
• 図表5（6）「公開文書への参照」には、「Amazon Web Services：セキュリティプロセスの概要／モニタリング、Amazon CloudWatch のセキュリティ」と記載され、資料名と該当する章の見だしまでが特定されている。このような確認を多数の項目で平易に行える点が、セキュリティリファレンスの大きなメリットの1つであることがあらためて分かっていただけると思う。

　次にユーザー側の対応について。

• 図表6（1）ユーザーの「対応要否」にある通り●（必要）であり、
• 図表6（2）「対応パターン」を見ると（図表7で言う）パターン2「AWSのサービスを使って対応可能」であることが明示される。その対応方法は、
• 図表6（3）ユーザーの「対策例」に次のように書かれている。「AWS Cloudwatch等を利用して、監視体制を整備する。また、異常状態や不正使用を発見したときの対応方法を明確にしておく」。そして利用すべき機能として、
• 図表8（10）「CloudWatch」に○が付いている。

　このようにセキュリティリファレンスを活用すると、「運60」で求められるリスク管理項目について、考え方、対策を平易に把握することができる。

公開版（サマリー版）と詳細版の違い

　以上、セキュリティリファレンスの読み解き方を概説した。なお、セキュリティリファレンスには公開版（サマリー版）と詳細版がある。解説の中でも軽く触れたが、小項目単位でリスクを確認する上で、公開文書などでは直接特定できない内容もある。このような事項についてセキュリティリファレンスではAWSとNDAを交わした上で確認を行っており、確認済み（◯）であることは公開版にも記載されているが、確認内容は詳細版にのみ記載されている。詳細版の利用に際してはエンドユーザーとAWSとの間でNDAの締結が必須となる。これらの事情により詳細版は、セキュリティリファレンス作成者（7社）が関わる実プロジェクトの中で使うことを前提としている。それ以外の開示依頼は対象としていないのでご了承いただきたい。

　まれに「詳細版には、AWSのデータセンターの場所が書いてありそうだ」と思い込んだ方から興味本位の開示依頼が来ることがあるが、本稿をお読みいただいた方にはご推察いただける通り、そのような情報は全く掲載されていない。

　本稿をよく読み直していただければ公開版でも十分な情報が含まれていることが理解できよう。公開版は再利用しやすいようにMicrosoft Excelシートでも無償で開示され、改編、再配布まで許諾している。公開版は、以前の記事で紹介された作成者7社のいずれのWebサイトからもダウンロードできる。

　ISIDのWebサイトはこちらである。存分に活用いただければ幸いである。

セキュリティリファレンスの最新動向

　2013年3月に、FISC安対基準が2年ぶりに改定され「第8版追補」が発表された。セキュリティリファレンス（Ver1.1）が参照している「第8版」から、設備、運用、技術の39項目について、変更・追記が行われている。さらに「運108」が新規追加され、全体として306項目になっている。「運108」は、「クラウドサービスの利用」に関する項目だ。「金融機関がクラウドを利用すること」をFISCが前提としはじめたということで、大いに注目される。

　「第8版追補」は、金融のみならず広い業界に向けて、新しい技術の出現や環境変化に対応してどのように重要なシステムの安全を管理すべきかを明らかにしている。非常に示唆に富むガイドラインだといえる。

FISC安対基準第8版（右）と第8版追補（左）

　セキュリティリファレンスも、「第8版追補」に対応したVer1.2を2013年10月にリリースする予定である。機会があれば稿をあらためて紹介したい。

　金融庁の外郭団体という、ややもすると保守的なイメージのあるFISCだが、前述のようにクラウドも含めて新しい時代の流れに着実に対応している。繰り返すが、FISC安対基準は非金融の利用者にとっても価値のある文書だ。われわれもクラウドという革新的な技術トレンドを積極的に取り込んで、ビジネスの発展を期したい。セキュリティリファレンスがそのための有力な武器となることは間違いない。本稿が読者各位のお役に立つことを祈念して筆を置きたい。

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

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

90年代からインターネットバンキング、電子認証、セキュリティのシステム開発、全社技術支援を担当。最近は、企業システムにおけるフルクラウド化を推進中。クラウドファースト時代に生き残れるSIerを模索中。業務システムでクラウドを安心安全に使える仕組み作りに関心。「金融機関向け『Amazon Web Services』対応セキュリティリファレンス」策定コアメンバー、経産省クラウドセキュリティガイドライン活用ガイド執筆メンバー、JASA-クラウドセキュリティ推進協議会、クラウド利用促進機構（CUPA）総合アドバイザー、オープンソースビジネス推進協議会（OBCI）副理事長、Seasarファウンデーション理事。