3. ISO27017管理策解説（クラウドサービスプロバイダ）
ここでは、ISO27017管理策の解説をしていきます。
今回は、『10.1.1 暗号による管理策の利用方針』～『12.6.1 技術的ぜい弱性の管理』まで解説します。
目次
※ ご覧になりたい項目をクリックすることで、該当のセクションにジャンプできます。
10.1.1 暗号による管理策の利用方針
この管理策はクラウドサービスを提供する側として、利用者から預かったデータを、そのまま保存しているのか、
暗号化して保存しているのかについての情報を、利用者側に公開することを要求しています。
ちなみに、IaaSを利用したSaaSの提供を行っている場合、自身が意図して暗号化処理を行っていなくても、IaaS側が勝手に暗号化してくれている場合もあります。その場合もまた、SaaS事業者は「～によって暗号化して保存しています」というように、主張することができます。
公開方法の例
公開する暗号化に関する情報としては、下記の2点があれば十分であると考えられます。
(1)どの情報を暗号化しているか
(2)どのような暗号化形式で行っているか
※ 必要に応じて鍵長などの情報も公開すべきでしょう。例えば、以下の例文ようなイメージです。
「お客様のパスワードはXXXによってハッシュ化されています。また、お客様から預かったマイナンバーはXXX方式で暗号化しています。それ以外のデータに関しては、暗号化処理は施しておりません。」
暗号化に関する情報を公開することは、利用者がセキュリティに関するルールを遵守するのに非常に役に立ちます。
例えば利用者が、ある業界団体に加盟していて、その業界団体のセキュリティガイドラインには、「XXXに関するデータは、XXXなどの方法により暗号化する必要がある」といった内容が書かれているとします。
その場合、いくら利用者がクラウドサービスを利用したいとしても、暗号化の情報が不明なクラウドサービスには、データを預けることが難しくなってきます。
そのような場合に、サービス提供者から提供される暗号化に関する情報は役に立ちます。
11.2.7 装置のセキュリティを保った処分又は再利用
IaaS事業者を想定した場合、サーバ機器などは定期的に入れ替え、不要なサーバ筐体は適切に廃棄する必要があります。この管理策では、その廃棄の手順をクラウドサービス利用者に開示しましょうということが要求されています。
機器からデータを取り出せないようにしたり、廃棄したりする手順は、「サニタイズ」と呼ばれます。NIST(米国国立標準技術研究所)が媒体のサニタイズに関する文書を発行しています(「NIST 800-88」などで検索してみてください)。
利用者への情報公開の手段の一つとして「NIST 800-88に従い、廃棄手順を実施しています」というのは一つの方法です。もちろん、NIST 800-88の方法とは異なる廃棄手順を取っている場合、この方法は使えません。なので、利用者を安心させるのに十分な内容を記載した、廃棄手順に関する情報を公開するべきです。
IaaSを利用しているSaaS事業者の場合の取り組み
ところで、IaaSを利用してSaaSを提供している事業者は、そもそも機器を有していないので、廃棄手順を明確にすることが難しいことがあります。
その場合は、例えば、利用しているIaaSの廃棄プロセスを調べて「自社ではやっていませんが、○○という手段で廃棄されるらしいですよ」という情報を開示することも、1つの方法です。また、規格をよく読むと、この管理策の対象は、装置だけではなく、データストレージやファイルも対象となっていることがわかります。ですので、利用者がブラウザ上でデータの削除操作をしたときに、それは見かけだけ見えなくなる「論理削除」なのか、完全にファイルやストレージから削除される「物理削除」なのかを開示することも、この管理策の実践のための方法になります。
12.1.2 変更管理
不特定多数のユーザーに向けたクラウドサービスは、全てのユーザーの希望する要件を取りまとめる事は不可能です。なのである意味、開発に終わりがないプロダクトと考えることができます。しかし、そんな開発・デプロイを繰り返していくうちに、中には良かれと思って追加した機能やデザインが、利用者の多くから不評を買うケースもあります。
さらに言えば、不評では収まらず、ボタンの位置が変わったことによって、利用者が誤った操作をしてしまい、間違えてデータを全て削除してしまったり、機密性の高い情報を一般に広く公開してしまう可能性もあります。そうなると、開発者側の責任が問われる可能性もあります。
そのような、ひょっとすると利用者のセキュリティに影響を与えてしまう可能性のある変更（規格では「クラウドサービスに悪影響を与える可能性のあるクラウドサービスの変更」という表現が使われています）は、実施する前に利用者に広く周知する必要があります。
周知の方法
周知には以下の方法が考えられます。
- 小さな影響の場合は、サービス開発者ブログ、リリースノート
- 中くらいの影響の場合は、サービスのトップページ
- 大きな影響の場合は、利用者に対するEメール
また、事前に「～という場合には利用者に通知します」という旨を含んだ利用規約やSLAを締結することも、利用者に安心感を与える材料になるため、積極的に検討すべきです。
12.1.3 容量・能力の管理
クラウドサービスを提供するということは、利用者に何らかの容量・能力を与えることになります。
この容量・能力とは、クラウドサービスによって、例えば、ファイルのアップロード保管の上限容量であったり、メッセージの1日あたり最大送信量であったり、最大メモリ使用量だったりします。
ところで、いくつかのクラウドサービスでは、「利用者の全員が同時に100%の容量・能力は消費しないであろう」という前提でシステム設計されている事があります。そのような設計は、クラウドサービスの特徴を積極的に活用した良い設計という事もできますが、もちろんリスクもありますので、少なくとも、利用者全体の消費容量・能力を常に把握し、自社が所有している容量・能力の全てを消費されないようにしておく必要があります。
逆に言えば、はじめから、全利用者が100%の資源(メモリ等)を利用しても、まだリソースに余裕がある設計にしているのであれば、この管理策で実施すべき内容は、少なくなるかもしれません。
クラウドサービスの利用者が増えるのは喜ばしいことですが、システム構成が初期のまま、すなわち、容量・能力のキャパシティが初期の状態から変わっていないと、資源の枯渇を招きかねません。
初期段階から、スケールアップ可能なシステムを前提にして構築することも大切です。
12.3.1 情報のバックアップ
「バックアップ」という名前が含まれた管理策ではありますが、ここでは「すべての利用者のデータを適切にバックアップしなさい」ということが要求されているわけではありません。
そうではなく、「いま自社が実施している利用者データのバックアップに関する情報を開示して、利用者に理解してもらいましょう」ということが趣旨になります。
なぜなら、この管理策の大きな目的は、バックアップの責任を空洞化させないことにあるからです。
そのため、あまり良くない例ですが、一切のバックアップを取得しておらず、「本サービスはお客様データのバックアップを一切取得しておりません。バックアップを取得したい場合は、お客様の責任で実施をお願いします。」と、広く公開することも、この管理策実践の一つの例になります。
もう少し現実的な話をすると、実際には、クラウドサービス提供者は、利用者データの多くをバックアップしていると思いますので、そのバックアップの範囲や、バックアップデータの保持期間などを、利用者に対して提供する必要があります。
また、もし自社でバックアップを取得していない部分があれば、その部分を利用者が利用者自身でバックアップ取得できるような仕組み（例えば、データの一括ダウンロード機能など）を提供することも、検討に値するでしょう。
ところで、サービスを運営していると、サービスを数カ月くらい前に退会した元利用者から「あの頃のデータって残ってたりしない？」などと聞かれる場合があります。
これに対する対応は各社によってバラバラだと思いますが、サービスによっては、利用規約などに、「退会後のデータの取り出しは一切受け付けません」などと明記している場合もあります。このような、過去の利用者に対するバックアップの提供に関する情報も、場合によっては開示しておくと良いかもしれません。
12.4.1 イベントログ取得
クラウド利用者の多くは、クラウド上に預けた情報資産が不正に利用されていないか、不安に感じているでしょう。しかし、もし仮に、いつ、だれが、情報資産を、どうしたのか、というログを提供できれば、利用者の不安を和らげることができ、利用者側の情報セキュリティレベルを向上させることが可能です。
この管理策では、そのようなログを取得するための機能を提供することを求めています。
1点、注意すべきなのは、この管理策は、他の管理策のような「ログ取得機能の仕様」を提供するわけではなく、「ログ取得を行う機能そのもの」を提供することが求められていることです。
つまり、12.3.1のバックアップの管理策で例示したような「ログは一切取得していません」といった情報提供では、この管理策を実践していることにはならないことに注意してください。
ただし、いくら「機能を提供する」といっても、その機能に関する「仕様や情報」を合わせて提供することは、利用者がクラウドサービスを選定するときの安心材料となり得ます。提供する情報の例としては、取得しているログの種類、ログの保管期間、ログの提供のタイミング(常時閲覧できるのか、申請が必要なのか)、などが考えられます。
特に、ログの保管期間などは、利用者がISMSの社内ルールとして、ログの保管期間を明確に定めている場合があるため、そのような会社にとっては、有益な情報になります。
12.4.4 クロックの同期
サービスによって提供されるログの時刻が、信頼できる時刻源からずれていたり、タイムゾーンの認識について利用者と齟齬がある場合は、利用者がログをチェック(監査)するときに、混乱が生じる可能性があります。
この管理策では、利用者に提供するログの時刻が、どのタイムゾーンなのか、どの時刻源と同期させているのか、ログのタイムゾーンを変更するにはどうしたら良いのか、といった、ログ時刻に関する情報を、利用者に対して提供することが求められています。
日本の利用者には、必ずしも日本標準時でログを提供する、ということが要求されているわけではありません。
しかし、その場合は、一般的な日本の利用者は日本時間でログが提供されると考えているであろうことを鑑みて、このログの時刻はUTCです、などと明記しておく必要があります。
同期させる方法としては、サーバにNTPを導入する方法、IaaSサービスを利用してSaaSサービスを提供している場合は、IaaSサービスの提供者から提供される時刻源を参照する方法、などが考えられます。
12.6.1 技術的ぜい弱性の管理
自社がクラウドサービスを提供するために利用しているプラットフォームやライブラリにも、もちろんぜい弱性が含まれている可能性があります。ぜい弱性の管理については、通常のISMS(JIS Q 27001)でも求められていますが、この管理策では、クラウドサービスの利用者に対して、提供しているクラウドサービスに関するぜい弱性管理の情報を提供することが求められています。
「ぜい弱性管理の情報を提供」とは言っても、何をどこまで提供すれば良いのかは難しい問題です。極端な話、サービスのWebページに「担当者がぜい弱性に関する情報を日々ウォッチしており、問題があれば速やかに対処します」の1文だけでも、情報を提供していることにはなります。
しかし、この管理策の意図する所は、サービス提供者の情報提供によって、利用者が安心してサービスを利用できることを目的としているため、例えば、以下の情報をユーザーに提供するといいでしょう。
(2)ぜい弱性が見つかったときの社内の対応フロー
(3)対応完了までの目標時間
(4)対応が完了したことの利用者への通知の有無
ただし、あまり詳細に、例えば、このサービスはXXXというライブラリを利用していて、そのライブラリの提供元サイトを見て、ぜい弱性をウォッチしています、などと書いてしまうと、ゼロデイ攻撃の格好の対象となってしまいます。「どこまでの情報なら出しても大丈夫か」について、社内で検討することは大切です。
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
