4. ISO27017管理策解説（クラウドサービスプロバイダ）
ここでは、ISO27017管理策の解説をしていきます。
今回は、『13.1.3 ネットワークの分離』～『16.1.7 証拠の収集』まで解説します。
目次
※ ご覧になりたい項目をクリックすることで、該当のセクションにジャンプできます。
13.1.3 ネットワークの分離
この管理策では、大きく2つの事が求められています。
1つ目は、利用者のネットワーク環境を適切に分離することを求められています。
いわゆる「マルチテナント環境におけるネットワーク分離」ですが、要するに、ある利用者が他の利用者の領域にアクセスし、悪事を働かせないようにするため、ネットワーク環境を適切に分離することを意味しています。
しかしながら必ずしも、顧客ごとにネットワークを完全に分離する所までは求められていません。
2つ目は、クラウドサービス提供者の社内ネットワークと、クラウドサービスそのものを分離させることを求められています。
SaaSのクラウドサービス提供のために、IaaSを利用している場合は大きな問題にはなりません。しかし、例えばクラウドサービスを提供するインフラを自社で所有している場合は、自社が業務で利用するネットワークと、クラウドサービス用のネットワークは確実に分離しておくべきですし、クラウドサービスの管理者であっても、クラウドサービス内のネットワーク(※)にアクセスするためには、しっかりした申請を行うようにする必要があるでしょう。
さらに、規格上に、「クラウドサービス利用者が要求してきた場合には、利用者によるネットワーク分離技術の検証を助ける事が望ましい」とも書かれています。
何をもって「検証」と言うかはサービスによって様々です。例えば機密保持を結んだ上でのネットワーク構成図の提供や、利用者側によるペネトレーションテストの実施は、検証の手段だと考えることができます。
※ 特に、顧客のデータなどが保管されている領域
14.1.1 情報セキュリティ要求事項の分析及び仕様化
通常、伝統的なシステム開発は、利用者からの要件や要求事項に基づいてシステムを開発していきますが、多くのクラウドサービスは、それとは異なります。
クラウドサービスは、利用者の要件が明確に見えているわけではなく、何らかの方法で「利用者は～を求めているであろう」ということを推定し、それを元にシステムを開発していくことになるケースがほとんどです。
これはつまり利用者側からみると、言い方は悪いですが「仕様がよくわからないシステムを手探りで使う」ということになります。このサービスにはどのような機能があって、どういった動作をするのかを、利用者はWebサイトの使い方ページなどを見て理解を深めることになります。
利用者にとって仕様がわからないということは、当然セキュリティに対する仕様も分からないといえます。
そこでこの管理策では、クラウドサービス事業者が、自身のWebページでそのサービスの使い方ページを公開しているように、セキュリティに関する情報(仕様)も、可能な限り利用者に公開することを求めています。
ところで、利用者に情報を伝達する、公開するという作業は、いままで解説してきた管理策でも求められてきました。この14.1.1は、それらの管理策を包含していると考えることもできます。
実際のJIS Q 27017の管理策に書かれている記述は、正直分かりにくいですが、経産省のガイドラインには以下のようにシンプルに書かれています。
「クラウド事業者は、クラウドサービスで実装（提供）している情報セキュリティ対策及び機能を列記し、開示することが望ましい」
こちらのほうが、イメージが掴みやすいですね。
14.2.1 セキュリティに配慮した開発のための方針
クラウドサービスを実際に開発しているエンジニアやプログラマーは、セキュリティには十分に注意して、開発を実施していることと思います。
自社サービスにバグがあれば、利用者の信頼性の低下に繋がりかねません。ところが、「セキュリティに十分注意して開発しています」というのは、全エンジニア・プログラマーに共通だと思いますが、それを実現するための手段は、意外とバラバラだったりします。
安全な開発という証拠
例えば、社内で独自のコーディング規約や、テストに関するルールなどが存在し、それに従って開発を行っている場合もあれば、外部の組織が発行している「～開発ガイドライン」などに則った開発スタイルを取っている場合もあるでしょう。
また、特に開発に関するドキュメントは無いにしろ、エンジニア全員が経験豊富なので、バグを生み出す可能性は十分低いだろうと判断している会社もあるかと思います。
この管理策は利用者に対して、「自社が安全に開発をしている証拠」を提示することを求めています。
この管理策の最も簡単な実践方法は、Webページのどこかに「このサービスは、○○が発行する～～開発ガイドラインに則って開発されています」と1文追加することです(ちなみに、このような文脈では、しばしば、IPAが発行している「安全なウェブサイトの作り方」が登場します)。
もし、組織が独自で開発ガイドラインを作成し、それに則って開発を行っている場合、その旨を、すなわち「自社の開発ガイドラインに則って開発を行っています」といった内容を記載すればよいでしょう。
また、この管理策は必ず何かのガイドラインに従って開発を行うことを要求しているわけではありません。
自社に何も開発ガイドラインがない場合は、利用者に対して開発が安全に実施されていることを証明できる何かを開示できれば問題ありません。
例えば、「開発者に対する教育制度」、「組織のコードレビュー文化の紹介」、「第三者によるぜい弱性診断の定期的な受審」などがこれらに当たります。
15.1.2 供給者との合意におけるセキュリティの取り扱い
この管理策は、14.1.1とよく似ています。
14.1.1では、「情報セキュリティ機能」に関する情報を、利用者に提供することを求めていました。しかしここでは「情報セキュリティ対策」を特定し、合意の一部とすることを求めています。
「情報セキュリティ機能」というのは、サービスにおいて利用者が利用できる機能のことです。例えば、ログイン履歴を見る、パスワードを変更する、二要素認証の設定をする、などです。サービス固有のセキュリティ対策、と言ったイメージでしょうか。
一方、「情報セキュリティ対策」というのはサービスの機能だけではなく、組織が行う対策も含まれます。
例えると、「利用者から預かったデータが閲覧できるのは、運用チームのごく限られた人間のみで、よほどの事情がない限り閲覧することはありません」というのは、セキュリティ機能ではありませんが、セキュリティ対策には該当します。
前述のような内容を、利用者との合意の一部（契約書に含めるなど）としましょう、ということを求めています。
ところで、今までの管理策の中にも「合意しましょう」と書かれた部分が幾つかありました。
6.1.1や8.1.5などです。この管理策15.1.2は、それらの管理策を含んでいると考えることもできます。
場合によっては、合意を求める管理策を適切に実施しているのであれば、この15.1.2は「特に何もしなくても自動的に管理策を実施していることになる」と考えることも可能です。
逆に、今まで合意ではなく「情報を提供する」と書かれた管理策もいくつもありました。
それらの情報提供をただの「情報提供」だけで終わらせず、合意の一部として含めることも検討すべきかもしれません。
15.1.3 ICTサプライチェーン
クラウドサービスの特徴のひとつに「サプライチェーンが長くなりやすい」という点があげられます。
具体例を以下に挙げます。あるA社のSaaSを利用しているエンドユーザーは、そのSaaSだけを利用していると考えているかもしれませんが、実はA社は、そのSaaSを動かすためにB社のPaaSを利用しており、B社に聞いてみると、そのPaaSも、実際はC社のIaaSの上で動いている、といったことが可能性としてあり得ます。
この何が問題かというと、エンドユーザーがA社に預けた（逆を返せば、A社にしか預けていないとエンドユーザーは考えている）情報が、B社やC社の手にも渡ることにより、エンドユーザーはA社のサービスを使うだけなのに、
A社とB社とC社の、合計3社のセキュリティレベルをチェックする必要が生じてしまいます。
それを回避するのがこの管理策です。
この管理策では、A社はB社やC社のセキュリティレベルを、B社はC社のセキュリティレベルを、十分に高い水準であることを確実にすることを求めています。要はSaaS事業者の場合は、IaaSやPaaSを選定するときに、セキュリティレベルを考慮した選定を行う責任があることを意味しているのです。
C社で情報漏えいが起こり、先ほど登場したエンドユーザーの情報漏えいが発生した場合、それはC社の責任でもあり、B社の責任でもあり、A社の責任でもあります。
エンドユーザーは、こうすることで、A社だけをセキュリティレベルのチェックの対象とすれば、問題ない事になります。
いろいろと理論的な話をしましたが、実際は何をすればいいかといえば、ひとつの例ですが、A社は自分自身が「クラウドサービス提供者」かつ「クラウドサービス利用者」であることを自覚し、B社やC社のクラウドサービス利用者として JIS Q 27017に掲載されている「クラウドサービスカスタマ」の管理策の内容を実践することが考えられます。
ところでJIPDECが運営している「ISMSクラウドセキュリティ認証」を取得する場合には、自社がクラウドサービスプロバイダとして認証を取得する場合、そのクラウドサービスの提供に別のクラウドサービスを利用している場合は、クラウドサービスカスタマの立場としても振る舞う必要があることを求めています。(JIP-ISMS517 4.1より)。
このJIP-ISMS517 4.1の要求事項を満たすことは、この管理策を満たすと考えても問題ないケースも多いでしょう。
16.1.1 責任及び手順
あまり考えたくないことですが、もしクラウドサービス上で何らかのセキュリティインシデント(例えば、情報の漏えい、サービスの停止など)が発生してしまった場合、データを預かっている利用者にその旨を適切に通知する必要があります。
しかし、些細なインシデント、例えば「エラーメッセージに誤字がありました」なども通知する必要があるのでしょうか。
また通知はどのようなタイミングで、どのような方式で行うべきでしょうか。
上記のようなことを決定するのが、この管理策の意図です。
実際の規格には、決定すべき事項が6つ書かれています。例えば一番初めに書かれている「報告するインシデントの範囲」を見てみましょう。
先ほどのエラーメッセージの例は大げさでしたが、実際に何かインシデントが発生した場合は、クラウドサービス提供者としては「本当はインシデントがあったことを公開したくないんだけど…でも公開しなきゃダメだよね…」という葛藤に悩まされることになります。
このようなケースに備えて「XXに当てはまる場合は必ず公開する」という、公開の基準を定めておくべきです。
しかし実情としてここの基準を厳しくしすぎると、いくら透明性が高いと言っても、最終的にはサービスの信頼が失墜してしまいます。ですので、1つの例ですが、「お客様に実害を与えた可能性があるかどうかを判断基準とし、実害があったケースのみ公開する」としてしまう手法もあります。もちろんこの基準はケースによりけりです。
また、この管理策ではインシデントの通知について決定した事項を、利用者に文書として提供する必要があります。インシデントの通知基準、通知の目標時間、連絡窓口などを、Webページに記載する、利用規約に記載するなどの手法で利用者に理解してもらうようにしましょう。
16.1.2 情報セキュリティ事象の報告
先ほどの管理策16.1.1と似ていますが、少々異なります。
クラウドサービス上で何かインシデントが発生した場合、それを利用者に対して通知する必要があり、その通知経路を整備しておく必要があります。
主な通知方法は、電話やメール、Webページへの掲載が一般的です。最近はTwitterなどを利用して第一報を報告するクラウドサービスも見かけるようになりました。
通知方法に決まりはありませんが、利用者のわかりやすい手法で、情報提供をする仕組みを整備し、利用者にあらかじめ伝達しておくことが求められています。
また、インシデントは必ずサービス提供者側が見つける訳ではなく、場合によっては利用者から報告を受け、初めて発覚することもあります。
特に多くのユーザーがいるクラウドサービスの場合は、その傾向が顕著です。前述のようなケースに備えて、利用者からインシデントに関する問合せを受ける窓口も整備しておくと良いでしょう。もちろん、この窓口の存在はあらかじめ利用者に伝達しておくか、もしくはわかりやすい位置に設置しておく必要があります。
そして忘れてはいけないのが、インシデントの対応中、もしくは対応が終わった後、「対応が終わりました」という報告をすることです。対応中にリアルタイムで対応状況を配信することは難しいかもしれませんが、せめて対応が終わった後には、その原因や対応策を利用者に対して公開するべきでしょう。
利用者はそれを見ることで、無事にインシデントが収束したことを確認し、安全にWebサービスを利用することができます。
16.1.7 証拠の収集
社内のシステムや、自社で開発・運用しているシステムであれば、システムの不具合や、あるいはシステム上で内部不正があった場合、システムに保管されたデータやログデータを分析することで、原因を追求することができます。
裁判などの大事になった場合は、そのデータを保全することで、裁判における法的証拠として示すことができるかもしれません（これを「デジタル・フォレンジック」といいます）。
ところで、クラウドサービスの利用者の立場になって、このデジタル・フォレンジックについて考えてみます。例えば、内部不正が起こったシステムが「外部事業者が提供しているクラウドサービス」だった場合、その提供者に「ログが欲しい」と要請することがあるかもしれませんが、提供者によっては、セキュリティの都合上、その要請が拒否されるかもしれません。
提供者の立場から考えると、ログデータを顧客ごとに分離しておらず、すべての顧客のログを1つのデータ領域に保管していた場合、特定の顧客のログデータを取り出すことが難しく、利用者の要請に答えられない場合もあります。
このように、クラウドサービスを利用していると、デジタル・フォレンジックの取り組みが妨げられるかもしれません。そのため、クラウドサービスの提供者と利用者の両者は、事前に「要請があった場合、ログデータなどのデジタル証拠となりうるデータを提供することが出来るか」について、合意しておくことが必要になります。
この管理策は、「要請があった場合について、必ずデジタル証拠となりうるデータを提供しなければならない」ことを要求している訳ではありません。事前に「提供できるかできないか」について、クラウドサービス提供者と利用者との間で合意をしておく事が求められています。利用者の立場から見ると、仮に「提供できない」クラウドサービスを利用する場合は、万が一の場合、自社に裁判上有利になる法的証拠が入手できない可能性があるリスクを、受容する必要があります。
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
