ISO27017管理策解説（クラウドサービスカスタマ）4
ここでは、ISO27017管理策の解説をしていきます。
今回は、『13.1.3 ネットワークの分離』～『15.1.2 供給者との合意におけるセキュリティの取り扱い』
まで解説します。
目次
※ ご覧になりたい項目をクリックすることで、該当のセクションにジャンプできます。
13.1.3 ネットワークの分離
利用しているクラウドサービスのネットワーク構成はなかなか見ることが難しいため、ブラックボックス化しやすいです。そのため、この管理策では、自社のネットワークの分離に関する要求を、クラウドサービス側が適切に満たしていることを「検証」することを求めています。
ここで「検証」というワードが出てきましたが、なにも実際にハッキングみたいなことをする必要はなく、何らかの手段で「確かめる」というニュアンスで問題ありません。例えば、クラウドサービスのホワイトペーパーやWebページを見て確かめる、ネットワーク構成図を取り寄せて確かめる、クラウドサービス提供者側の技術者に話を聞いて確かめる、などのニュアンスです。これには画一的な答えはなく、自社が預ける情報の重要度などに応じて、どのように「確かめる」のかは議論の余地があります。
14.1.1 情報セキュリティ要求事項の分析及び仕様化
この14.1.1は、通常のISMS(JIS Q 27001)では、自社が開発するシステムに、セキュリティが確実に盛り込まれるために、開発を始める前に、セキュリティに関する要求や仕様をあらかじめ定めておきましょう、ということを求めています。このJIS Q 27001の管理策を実践することで、その開発したシステムに、セキュリティが確実に取り込まれていることを、ある程度、保証することが可能です。
ところが、クラウドサービスは既に外部で開発されているものを利用するため、そこにセキュリティが取り込まれているかどうかは分かりません。そのため、クラウドサービス利用前には、セキュリティが確実に盛り込まれているかどうかを、あらかじめ検証することが必要です。その検証作業こそが、この管理策で求められている内容になります。イメージ的には、委託先を選定するときに利用する「委託先への情報セキュリティアンケート」のクラウドサービス版のような感じです。
ところが、そのアンケートの項目をどうするか、という問題があります。なんらかの適切な方法で項目を構成すればいいと思うのですが、せっかくJIS Q 27017を読んでいるため、このJIS Q 27017に記載されている内容を羅列する形が良いのではないでしょうか。つまり、この管理策をむりやりシンプルにまとめるならば「JIS Q 27017に記載されている内容を、しっかりとクラウドサービス提供者に確認しましょう」と解釈することもできます。それ以外の方法としては、経産省やITU-Tなどが発行しているクラウドサービスに関するペーパーを参考にしながら、項目を独自で構成するのも良いでしょう。
14.2.1 セキュリティに配慮した開発のための方針
先ほどの14.1.1の管理策では、利用しようとしているサービスに「セキュリティに関する機能があるか」などといった、サービスの機能や仕様に関する内容を検証していました。
しかし、例えば、ログ取得機能と、不正ログイン通知機能、その他セキュリティに関するありとあらゆる機能が存在すれば、そのサービスは安全といえるのでしょうか。
例えば、システムを開発している人が書いたプログラムにバグがあると、その機能が正常に動かなかったり、急に停止してしまう可能性があります。これは、セキュリティにおける可用性の欠如です。
さらに、もっと重大なバグ、たとえば、他の利用者に自社のデータが見えてしまったりするケースも考えられます。つまり、「セキュリティ機能」だけでは、セキュリティインシデントを防ぐことは出来ないのです。
自社が預けた情報が、このようなケースに巻き込まれることを防ぐために、これからサービスを利用しようとしている会社ができることは、サービス提供者が何らかの適切な「開発手順」を有しているかどうかを確認することです。
適切な開発手順が存在し、それに則って開発を行えば、ある程度のバグの発生は防止できるだろうと考えられるからです。
「開発手順」というとピンと来ないかもしれませんが、要は開発におけるコーディング規約やテスト手順などのことを指しています。この類でもっとも有名な資料は、IPAが出版している「安全なウェブサイトの作り方」です。
少し話がそれてしまいますが、なんらかのシステムの開発を外部の会社に委託する場合は、そのシステムの要件に関するドキュメントの中に『最低限、この「安全なウェブサイトの作り方」に載っているセキュリティに配慮した開発を実施して下さい』などといった内容を明記することもあります。
今回はクラウドサービスですので、一利用者が一方的に「～～というガイドラインに則って開発してくれ」という事はできませんが、提供元がどのような開発方針を持っているのかを確認することは、十分可能です。
15.1.1 供給者関係のための情報セキュリティの方針
既にISMSを構築している組織ならば、委託先に関する何らかのルールが存在していると思います(ここでは、「委託先」という言葉を、規格に書かれている「供給者」と同義で利用します)。ところで「委託先」とは一体何でしょうか。利用しようとしているクラウドサービスの開発元は「委託先」に該当するのでしょうか。
この管理策では、「クラウドサービスの開発元も、委託先に含めましょう」ということが求められています。つまり、クラウドサービスを選定するときは、組織が定めた委託先の選定ルールに則って、サービスを選定する必要がある、ということです。
しかし、例えば委託先選定の方法として「アンケートを実施する」というルールを定めていたとしましょう。
その場合、クラウドサービス提供側は、大量の利用者を相手にサービスを提供しているため、わざわざその1社のために、アンケートに回答してもらえるとは考えにくいです。よって、多くの場合、委託先の選定ルールを変更する必要が発生します。社内の委託先管理規程を「クラウドサービス以外の委託先の場合は～という基準で選定し、クラウドサービスの場合は～という基準で選定する」といった文言に変更するイメージです。
ところで、委託先のセキュリティを保つためには、「選定」のフェーズだけではなく、その後の「管理」や、定期的な「見直し」なども必要です。そういった委託先管理に関する全体的な社内ルールも、クラウドサービスに適用できるように修正していく必要があります。
15.1.2 供給者との合意におけるセキュリティの取り扱い
この管理策は、誤解を恐れずに言ってしまうと、特に何もしなくても問題ありません。まず、この管理策が意図することは、「委託先を含む供給者と、セキュリティに関する実施内容を合意しましょう」ということです。例えば、契約書やSLAなどに、「パスワードの管理は利用者の責任です。システムのぜい弱性管理は提供者が責任を持って実施します。」みたいなことを書け、ということです。
ところで、そもそも、このJIS Q 27017規格とは何だったかを考え直してみると、規格のそもそもの大きなコンセプトの1つとして、「クラウドサービスの利用者と提供者との間の責任を明確に分けましょう」ということがあります。そのために、例えば、管理策6.1.1では双方で役割責任の割当てを確実に合意し、管理策12.3.1では、どちらがデータのバックアップをする必要があるのかを、検討してきたわけです。 よって、この管理策15.1.2は、この規格のコンセプトそのものに含まれているため、15.1.2を除いたJIS Q 27017に準拠することは、同時に15.1.2を満足することになると考えられます。
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
