ISO27017管理策解説（クラウドサービスカスタマ）1
ここでは、ISO27017管理策の解説をしていきます。
今回は、『5.1.1.情報セキュリティのための方針群』～『8.2.2 情報のラベル付け』まで解説します。
目次
※ ご覧になりたい項目をクリックすることで、該当のセクションにジャンプできます。
5.1.1情報セキュリティのための方針群
クラウドサービスに関する方針を、「トピック固有の方針」として定義する、という表現があります。ここでいう「トピック」とは、JIS Q 27002の5.1.1で述べられている「トピック」と同様だと考えるのが自然でしょう。
簡単のために、ここでは「方針」のことを「ルール」と呼び変えます。
既にISMSを構築している組織では、情報セキュリティに関する様々なルールが存在していると思います。例えば、スマートフォンの業務利用のルールであるとか、委託先の管理のルールなどです。そういった、セキュリティに関する各ルールを、JIS Q 27002では「トピック固有の個別方針」と呼んでいます。
つまり、JIS Q 27017の5.1.1で求められる対策は、今例に述べた、組織の中に既に存在している「スマートフォン利用ルール」や「委託先管理ルール」などと同じように、「クラウドサービス利用のルール」を作成しましょうということです。
どういった中身にすればいいかは、JIS Q 27017の5.1.1に具体的に述べられています。
しかし、実際にルールを作成するときは、ここを参考にするよりかは、JIS Q 27017のCSCの管理策を総ざらいしたものを社内ルールとしてまとめるという方法をお奨めします。なぜなら、「27017の管理策検討」と「この5.1.1で求められているルール作成」を同時に進めることができるからです。
そう考えると、この管理策は「JIS Q 27017に書いてある管理策をしっかり検討して、社内ルールとして確立しましょう」と述べているようにも見えます。
6.1.1 情報セキュリティの役割及び責任
おそらく、多くの企業のクラウドサービスの利用に関する心配事第1位は、「自社の情報が流出してしまったらどうしよう」ではないでしょうか。
一度でも情報が流出してしまったら、お詫びの対応や信用の失墜など、多くの損害が発生するわけですが、さて、クラウドサービス上で情報流出が起こってしまった場合、それはクラウドサービス提供側の責任でしょうか、それとも、利用側の責任でしょうか。
この6.1.1では、そのようなインシデントが発生しないためや、万が一発生してしまった場合などの責任範囲を明確にし、各自が実施しなければいけないセキュリティ対策を両者でしっかりと割り当て、理解しましょうという事を求めています。
そして、その割り当ては、合意書（契約書や利用規約など）により、合意することが求められています。
シンプルに言えば、利用規約に書いてある内容を理解し、自社がクラウドサービスを利用するに当たって、やらなければいけないセキュリティ対策をしっかりやりましょう、ということです。
また、このセキュリティ対策を実施するときに、自社では解決できない問題に出会うこともあります。
例えば、サーバの管理責任が自社にあるIaaSサービスを利用していて、サーバにウィルス対策ソフトを導入しようとしたが、導入が上手くいかない時などです。
そういったときに、サービス提供者側に問い合わせができる窓口が事前にあるかどうかを確認しておくことも必要です。
6.1.3 関係当局との連絡
クラウドサービスを利用することは、自社の管理外に自社の情報を置くことになるため、当然それに関連する関係組織は特定しておく必要があります。
経産省のガイドラインには、クラウドサービスの利用に関して特定しておくべき組織の例として、以下の4つを挙げています。
b) クラウドサービスの事業者団体
c) クラウドサービスに関連する省庁や団体
d) クラウドサービス関連のニュースソース
クラウドサービスに関する団体の情報は、Googleなどで検索すれば様々見つけることが出来ます。
また、上記以外にも、例えば利用しているクラウドサービスが、Amazonが提供するAWS上の仮想サーバで動いている場合は、Amazonの連絡窓口や障害情報のページを特定しておくことも必要かもしれません。
7.2.2 情報セキュリティの意識向上、教育及び訓練
この管理策は、シンプル「クラウドに関する教育を実施しましょう」ということを述べています。
簡単に言うならば、ISMSの活動として、年1回(もしくは、定められた頻度で)実施しているセキュリティの教育の中に、クラウドに関する内容を含めましょう、ということです。
JIS Q 27017には、具体的な教育の内容が4つ掲載されています。
ただし、特徴的な内容が1つあります。それは、「クラウドに関する教育は、経営陣や監督者にも提供する」と書かれている部分です。
しばしば、経営陣と現場との間で、クラウドに関する理解や温度差が大きすぎる、という話を耳にします。
そういった差を無くすためにも、トップにもクラウドに関する理解を深めてもらうことは大切です。
8.1.1 資産目録
自社の情報を管理する上で、どのクラウドサービスに、どんな自社の情報を保管しているかを把握することは、役に立ちます。
この管理策では、クラウドサービス上に保管されている自社のデータを洗い出して、資産目録に記載することを要求しています。
すでにISMSを構築した段階で、クラウドサービスに預けている情報資産をまとめて洗い出している場合は、洗い出しを追加で実施する必要はないでしょう。
ただ、この管理策では、洗い出し以外にもう一つ「資産を保持している場所を示す」ことが求められています。場所を示す方法として「クラウドサービス名」が例としてあげられていますが、それ以外にも「クラウドサービスを運営している会社」などでも良いでしょう。
とにかく、自社のデータが誰の手に渡っているのかは、把握しておけるようにしておきたいです。
ちなみに、洗い出すデータの具体例としては、IaaSの利用を想定するならば、ソースコード、認証情報（暗号鍵など）、各種ログ、各種バックアップデータ、DB内のデータなどが考えられます。
8.2.2 情報のラベル付け
ISMSを構築した段階で、組織の中における情報の分類体系は、少なからず定まっていることと思います。
「機密情報」「社外秘情報」「一般情報」といった分類が一般的でしょうか。
他にも、会社によっては、ファイルの名前の付け方や、保管場所まで定めている場合もあるでしょう。
例えば、「社外秘のファイルは、ドキュメントの左上に「社外秘」と入れて、○○フォルダに保存する」などです。
この管理策では、そのような情報へのラベル付けを、クラウドサービス上でも実現できるようにしましょう、ということを求めています。
例えば、ファイルの受渡を行うクラウドサービスを利用していて、機密情報は受渡が完了し次第速やかに削除するというルールが設定されたとしましょう。
もし、機密情報に適切なラベル付け機能（ファイルのタグ付け機能など、何らかのメタデータを付与できる機能）があれば、その機能を使って検索し、機密情報をまとめて削除できるかもしれません。
また、DropboxやBox, Google Driveを始めとした、多くのクラウドストレージサービスでは、アップロードしたファイルの名称を変更したり、フォルダ分けすることができます。
その機能を利用すれば、機密情報と一般情報を分離し、適切な情報管理が実現できるかもしれません。
要は、ISMS構築時に定めた情報管理のルールや分類は、クラウド上でもその分類体系が保たれるように工夫しましょう、ということです。
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
