第7回クラウド利用者会議 レポート
2017年7月12日
CSAジャパン 諸角昌宏
第7回クラウド利用者会議では、BSIジャパン株式会社の中村良和氏に講演していただいた。会議は、6月27日(火)に開催し、クラウド利用者を中心として14名に参加いただいた。
今回は、「クラウドセキュリティに対する日本の認証規格」について講演していただくとともに議論を行った。
中村氏から、まず、日本の認証規格の状況について説明していただいた。
クラウドセキュリティに関する認証規格は、日本では以下の2つが展開されている。
- ISO/IEC 27018
27018は、パブリッククラウドにおけるプライバシのガイドラインを提供している。本規格の認証については認定機関が認証機関を認定するスキームは無く、認証機関が独自に認証サービスを提供する形しかない。認証スキームとしては、規格の適用範囲にもあるようにあくまでパブリッククラウドが対象であり、プライベートクラウドは対象とならない。また、PIIのProcessor（基本的にはプロバイダ）が対象であり、Controllerは対象にならないという規格の適用範囲となる。 - ISO/IEC 27017
27017は、以下の2つ構成を提供している：- 27002の実践規範に対する追加/拡張の管理策 27002の実践規範ではクラウド固有の要素が不足しているため、クラウド固有の要素を追加したものになっている。この際には27002も考慮した考えが必要となる。
- クラウド独自の追加管理策（附属書A）
27002の実践規範の項目では不足している、クラウド独自の管理策についてCLDと言う形でさらに追加の実践規範を設定している。ただし27017の本文の位置づけと同様である。
また、認証制度として以下の2つの注意点がある。
- 認証制度
他のクラウドを利用し、自社のクラウドサービスを提供しているクラウドサービスプロバイダーは、CSC（カスタマ）とCSP（プロバイダ）の両方の立場で見る必要がある（サプライチェーンを構成している可能性）。認証範囲はISO27001の認証している範囲内である必要があるため、クラウドサービスの提供が範囲外の場合はISO27001の適用範囲を拡大しなければならない。またISO27017の追加の管理策は原則除外ができない。
注意点： SIerの存在で、SIer的に動いている（カスタマのクラウド環境を構築している）が、クラウドサービス自体を提供していない場合には、CSPとして認証を取ることはできない。 - 審査員の力量
ISMS審査員がクラウドセキュリティの審査員になるためには、追加でクラウド基盤・要素技術などの力量が必要になる。
さて、中村氏の説明の後、いつものように参加者によるディスカッションが行われた。
まず、カスタマが要求したことに対して、プロバイダは情報を提供するのか、という点が議論になった。情報の提供を契約にしておくことが望ましいが、プロバイダが個別に契約することを行わないケースもある。しかしながら、現状では、ほとんどのプロバイダが情報を提供している。たとえば、AWSでは、セキュリティ管理策について詳細に書かれた「ホワイトペーパーのどこどこの記述を見てください」というレベルの回答は必ず返ってくるようである。また、少なくとも27017に基づくクラウドセキュリティ認証を取っているプロバイダであれば、情報を提供しなければならないことになる（開示レベルは組織によって違うと想定される）。したがって、カスタマ側のリスク管理上必要となる情報はプロバイダから何らかの形で提供されると思ってよさそうである。もちろん、27017で言っているように、プロバイダが情報を出さない、あるいは、プロバイダの管理策が不十分である場合には、カスタマが追加の管理策を行わなければならないという大原則があることは理解した上で進める必要がある。
次に、27017では、対象となるのがパブリッククラウドなのかプライベートクラウドなのかが明記されていない点に議論が移った。プライベートクラウドの場合には、27017の管理策の大部分が不要になるのではないかということである。たとえば、オンプレのプライベートクラウドを考えた場合、論理境界に絡むセキュリティ対策は基本的に要らなくなるのではないかという点である。ISMS自体は、もともとオンプレを前提としているという意見もあった。そのため、クラウドに移行した場合、ユーザがコントロールできる範囲がどこまでか、また、それを超えた場合の管理をどうするかを定めたのが27017であると考えるとしっくりくる。したがって、パブリッククラウド/プライベートクラウドの利用における現実に即した管理ということをベースに考える必要がある。
また、27017の使い勝手はどうなのかということも議論された。ISMS上は、リスク管理に基づいて作成した管理策に対して、27017（27002を含む）の管理策と照らし合わせた時にギャップが存在しないかどうかを確認するというのが手順になる。しかしながら、逆に、27017をベースにして管理策を作成し、後は気になるところだけ検討していくという方が合理的ではないかという意見が出た。これについては、そもそもの認証に対する考え方の問題であり、認証を受けるという観点からするとそうなるかもしれないが、リスク管理の観点からは、まず管理策を策定するというのが必要になるということになった。27017自体は良いフレームワークとして使うことが望ましいということである。
それから、クラウド環境でのデータ削除に関する議論も行われた。プロバイダは、データにアクセスできないようにすることで削除したと判断する（判断するしかない）が、これで本当に安全な削除と言えるのかどうかという点である。そもそもオンプレでの仮想化環境ではデータが安全に削除されたかどうかを気にすることは無いのに、クラウドではなぜリスクになるのかという意見が出た。カスタマは、プロバイダのデータ削除が不十分であれば、独自に削除方法を検討するというのが基本スタンスであり、これに基づいてプロバイダを評価するのが必要という議論の結論となった。
最後に、プロバイダの管理策を実証するにはどうすればよいのかという議論になった。プロバイダを直接監査することは難しいため、プロバイダが提供する情報をもとに判断することになるが、そもそもプロバイダが提供する情報として何が必要なのだろうかというである。監査に基づく証明書では不十分であり、なんらかの報告書（アセスメントレポート）が必要になるということになった。AWSでは、SOCのレポートも開示されており、これが報告書として使えるのではないかということになった。
以上のように、クラウドセキュリティ認証というものに対して、様々な観点から議論を進めることができた。また、文章では表せない（筆者の能力は別として）ところでの議論も活発に行われたため、非常に中身の濃い会議となった。
以上
「27017の使い勝手はどうなのか」という点についてのコメント。
27017のようにマネジメントシステム（PDCAのプロセスを含む規格、27001など）にアドオン（正確には27002にアドオンですが）する規格をセクター規格というそうです。この場合リスク特定・分析は本体（マネジメントシステム）で行い、対応時に引き当てる施策（管理策）に抜けが無いかをセクター規格を含めて確認することと27001の6本文にあります。セクタ規格は27009というセクタ規格を設計するための規格に則って作成されています。29151や27018についても同様でセクタ規格を利用してマネジメントシステムを拡充できるように設計されています。個々のセクタ毎に個別の登録証が必要な場合は認証機関毎のプライベート認証となることに留意が必要です。
「リスク特定・分析は本体（マネジメントシステム）で行い」ですが、クラウド固有のリスクを特定・分析するということが含まれます。やり方は、同じですが。
「プライベートクラウドの場合には、27017の管理策の大部分が不要になるのではないかということである」ということについてのコメント。
17788の定義によれば、”CSCに排他的に提供される～利用組織自身もしくはサードパーティーによって、所有・管理・運用され得る”とあります。単なるデータセンターでの自社所有機器の自社による運用だけでなく、第三者による所有・運用管理を含んでいるので、境界を定める必要がある場合があります。従って、”パブリッククラウド/プライベートクラウドの利用における現実に即した管理ということをベースに考える必要がある”という結論は妥当かなと思います。それにしても現実に即した境界はいかにも曖昧ですよね。いっそのこと”処理装置及び記憶装置の第三者による所有・運用・管理を含む場合”はプライベートクラウドという27017の範囲としたらどうかなと思ったりします。
「カスタマが要求したことに対して、プロバイダは情報を提供するのか、という点が議論になった。プロバイダの管理策が不十分である場合には、カスタマが追加の管理策を行わなければならないという大原則がある」という点につぃてのコメント
27017の示す”実施の手引”には、”CSPはCSCに～を提供すること”、”CSCはCSPに～の提供を求めること”という記述がある場合があります。上記のような記述（提供すること、提供を求めること）が無い場合は、27017の規格としては情報が提供されないことによるリスクはCSCが負担すべしということになります。これは、CSCはリスクに応じてCSPを選択すれば良いということを意味します。AWSのようにきっちり情報を提供してくれるCSPは選択しやすいですね。ちなみに、審査基準という側面で言えば”実施の手引”は審査基準ではありませんが、”実施の手引”が施行されていないことで当該管理策の求める要件が達成されない場合は当該管理策が不適合となる場合があるかもしれません。
これ、第1回のクラウド利用者会議で議論となった「プロバイダの透明性」と「カスタマのリテラシ」につながりますね。
AWSや海外のプロバイダは、セキュリティ対応状況を詳細に公開している。つまり、高い透明性をもって情報を公開し、カスタマがそれを見て判断できる。半面、日本国内は、セキュリティ対応状況を公開することはリスクに繋がるという考え方が多い。CSPがCSC向けに個別に情報提供を行うという負荷を考えたら、透明性を高めるというのが大きな選択肢になるのではないかと思う。
ISMS審査員がクラウドセキュリティの審査員になることに対して、求められる知識は何か」ということに関するコメント：
この件はよく話題となります。どの程度の”知識”が必要かというガイドラインが示されないままこの話が拡散するのはクラウドセキュリティの不透明感を印象付けないか心配です。27017の審査員として最低限必要なレベルという限定で言えば、27017及び関連する規格に登場する用語を理解するレベルということで、17788の用語集の理解ということになろうかと思います。実際、いきなりクラウドサービスパートナーとか言われても何のことやら分かりません。現場でクラウドのマネジメントシステムの運用の有効性を審査するとなれば、用語の理解に加えて、置かれた環境のCSP、CSC間の境界を判別するための知識（物理的境界、技術的境界、組織的境界）が必要と思います。これらはISMSの供給者管理でも扱うことになる知識エリアではないかと思います。仮想化やコンテナ、マイクロサービスなどはオンプレ環境とのミックスされた環境でも使用されており、ことさらクラウドセキュリティと言わなくても供給者管理やICTサプライチェーンで扱う知識分野と思います。