6. ISO27017管理策解説（クラウドサービスプロバイダ）
ここでは、ISO27017管理策の解説をしていきます。
今回は、『6.3.1 クラウドコンピューティング環境における役割及び責任の共有及び分担』～『13.1.4 仮想及び物理ネットワークのセキュリティ管理の整合』まで解説します。
目次
※ ご覧になりたい項目をクリックすることで、該当のセクションにジャンプできます。
6.3.1 クラウドコンピューティング環境における役割及び責任の共有及び分担
クラウドサービスを利用している組織と、クラウドサービスを提供している組織との間で、明確に責任分界を定めたのが、管理策6.1.1でした。6.1.1以外にも、このJIS Q 27017に記載されている管理策を遵守するために、提供者側で実施すべき内容も多く登場しました。
この管理策では、それらの「クラウドサービス提供者が実施すべき役割(内容)」を明確にし、その役割を、社内の従業員に対して伝達・分配することを求めています。
利用規約には、「バックアップは日次で実施します」と書いているのにもかかわらず、肝心のクラウドサービスを開発運用しているチームがそのことを把握していないと、元も子もありません。この問題は、特に仕様変更が起こった場合に顕在化しやすいです。サービス開発・運用側で企画した仕様変更が、法務部門や営業部門に適切に伝わっておらず、サービス利用規約や公開情報が、適切に更新されない可能性があります。
そういった事態を防ぐためにも、自社が実施すると宣言した役割は、適切に従業者に対して伝達しておくことが求められています。
多くの場合、自社が提供するサービスごとに「プロダクトオーナー」や「クラウドサービス責任者」などを定めることがあります。そして、その定められた役職の人が、各部門を横断/調整する責任を負うケースが多いです。
8.1.5 クラウドサービスカスタマの資産の除去
利用者が退会したときに、その利用者のデータをどう取り扱うかは、意外と難しい問題です。
セキュリティ的には速やかに削除することが模範解答なのかもしれませんが、実際問題、数カ月後に利用者から「ログ残ってませんか…」と聞かれたり、オペレーション的に、退会者が発生するたびにすぐに削除するのは手間がかかったりすることから、即時削除は意外と難しかったりします。
この管理策では、利用者が退会したときに、利用者のデータがどのタイミングで削除されるのかを利用者と合意しておくことを求めています。
例えば「預かったデータは、退会後X日以内に完全に削除します」という内容を公開しておくことは、この管理策の、1つの実践例です。もし、退会しても消えないデータがあるならば「但し、XXデータに関しては、退会後も、こちら側で削除操作をすることはありません」といった断りを入れておくことが必要です。
退会時の削除で忘れがちなのは、データベースではなく、ストレージに保管されている画像ファイルや動画ファイルなどのコンテンツの削除です。これらも、ユーザー退会時から一定期間後にしっかり削除されるようにしておきたいです。
他にも、ログの削除も難しい問題です。多くのユーザーが利用するクラウドサービスの場合は、ログの中に複数のユーザーの記録が残る場合があり、退会ユーザーのログのみを削除することは難しいケースがあります。
しかし、最低限、個人情報やクレジットカード情報などの機密情報だけは、退会後には削除できるようにしておくべきでしょう。
9.5.1 仮想コンピューティング環境における分離
この管理策では、論理的分離を確実に実施することを求めています。論理的分離といっても様々なレイヤーがあり、IaaSを提供している場合には仮想サーバの分離を、SaaSの場合は、ある利用者が他の利用者のデータコンテンツにアクセス出来ないようにアクセス制御を行うことが、いわゆる「分離」に該当すると考えられます。
また、あたりまえのことですが、分離は利用者の悪意ある操作に対して堅牢である必要があります。IaaSの場合は、悪意ある利用者が、仮想サーバ内で何か特殊なソフトウェアを用いて、別の仮想サーバの領域にアクセスしてしまうというリスクがあります。
SaaSの場合は、いわゆるSQLインジェクションのような攻撃により、論理的には分離されているはずの、他のユーザーのデータが漏えいしてしまうリスクがあります。
そのようなリスクを考慮し、堅牢な分離を実施することが求められています。
さらに、この管理策では、「社内環境とクラウド環境とを適切に分離する」ことも要求しています。
何を持って適切な分離というかは難しいですが、社内ネットワークに接続できる人間が、だれでも、提供しているクラウドサービスの環境にアクセスできるような状態は望ましくありません。
社内ネットワークから、クラウドサービス環境へアクセスするためのアカウントの管理や、接続ログの取得・レビューなどを実施する必要があるでしょう。
9.5.2 仮想マシンの要塞化
提供しているサービスのサーバ管理を自社で行っている場合は、そのインフラのセキュリティ対策も実施する必要があります。当たり前のことですが、改めてしっかり実施しましょうということが、この管理策には書かれています。具体例として5つのセキュリティ対策が掲載されていますが、いくつか見てみましょう。
まずはポートの制限です。仮想サーバにかかわらず、サーバ・ネットワークセキュリティでは必須の内容ですが、外部からの攻撃を避けるため、ポートの開放は最小限にしておく必要があります。場合によっては、セキュリティを高めるために、デフォルトのポート番号を変更する（例えば、SSHのポートをデフォルトの22番から変更するなど）ことも検討する必要があるでしょう。 次に、サービスの制限です。サービスの定義は何かと問われれば、OSによって色々だと思いますが、例えばLinux系のOSだと、不要なデーモン（常駐プログラム）を停止・削除することは、サービスを制限することの1つの実践例だといえます。
サーバの初期状態だと、実際そのサービスの機能に必要のないデーモンが起動している可能性があります。
不要なデーモンを停止することは、セキュリティレベルの向上だけではなく、サーバ負荷の軽減にもつながるため、一石二鳥の取り組みになります。
12.1.5 実務管理者の運用のセキュリティ
今まで、クラウドサービスは利用者と提供者との間で責任分界が曖昧になりやすいという話をしてきました。
この管理策も、その責任分界の延長の議論になります。例えば、クラウドサービス利用者が、クラウドサービスを利用中に、意図せず間違ったボタンを押してしまい、データが全て消えてしまったことを想定してみてください。
これは利用者の責任でしょうか？それとも、わかりにくい位置にボタンを設計した提供者の責任でしょうか？
この管理策では、利用者がクラウド上で、確実に・間違いなく操作を行うための責任は、提供者側にもあると考え、提供者側が手順書やマニュアルを整備し、利用者に提供することが求められています。よくある「ヘルプ」ページも、1つのマニュアルとして考える事ができます。 なお、全てのクラウドサービス上の操作を手順化する必要はありません。「これを間違えるとサービス利用の請求額が莫大になってしまう」、「これを間違えるとデータが全て消えてしまう」、「これを間違えると仮想ネットワークの設定情報が全てリセットされてしまう」といった、利用者側にとって重要だと思われる操作に関して、手順書を提供していれば十分でしょう。
また、手順書といえば、数年前に作ったものがあるが、最近のシステムのバージョンアップについていけず、デザインや機能が古いままのような手順書も存在します。システムのバージョンアップに対して、マニュアルの修正がリアルタイムで行われる仕組みを作っておくことも、大切かもしれません。
12.4.5 クラウドサービスの監視
「監視」という単語は、実は管理策「12.1.3容量・能力の管理」でも登場しました。そこでは、クラウドサービスの提供者は、資源不足によるサービスの停止などを防止するために、サービス全体の利用容量や能力(メモリ、CPU等)を「監視」しましょうということが求められていました。
ところで、資源が気になるのは、サービス提供者だけではありません。多くのクラウドサービスは、利用者が利用できる資源の最大値（例えば、クラウドサービス上に保管できるデータの容量）は決まっていますから、利用者は、その容量が一杯にならないか、常に気にしながらサービス利用を行うことになります。
提供者は、その手伝いを行う必要があります。利用者側が適切に容量・能力を「監視」できるように、提供者は、各利用者の現在のメモリ利用率や、過去の利用状況などの統計データを提供することが求められています。
また、この管理策では、容量・能力の監視に関する情報の提供だけではなく、サービスの不正利用を監視する機能の提供にも言及しています。基本的に利用者は、一度、提供者に預けてしまったデータがどう扱われているのか、流出していないか等を知る術はありません。そのような、利用者が預けたデータに対するセキュリティが喪失していないかを、利用者自らが監視できる機能を提供することが望ましいです。
具体的には、SaaSの場合は、預けたデータの操作ログや、どのIPアドレスからデータが閲覧されたかのログなどが、IaaSの場合は、先程挙げた、仮想マシンの負荷等を監視できる機能が、それに該当するでしょう。
13.1.4 仮想及び物理ネットワークのセキュリティ管理の整合
仮想ネットワークと物理ネットワークを接続するときには、しばしば問題が生じる可能性があります。
例えば、社内のネットワーク環境から、仮想ネットワークが構築されているクラウドコンピューティング環境に、大量のデータを送信する場合、クラウド上の仮想ネットワークの帯域が貧弱であると、正常に動作しない可能性があります。
また、仮想サーバを物理的な筐体の上に構築する場合、容量・能力を適切に考慮した設計を行わないと、物理的な制約により、仮想サーバが十分なパフォーマンスを発揮できないことも考えられます。この管理策では、上記のような事態を避けるために、物理ネットワーク上で構築される仮想ネットワークに関するルールを決定することを求めています。
この管理策は、自社でクラウドのインフラを管理しているクラウドサービス提供者が対象となります。
具体的には、自社のサーバやデータセンター上でクラウドサービスを稼働させている場合です。逆に、IaaSやPaaSの基盤を借りてクラウドサービスを提供している場合、この管理策は、適用除外することができます。
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
