ISO27017管理策解説（クラウドサービスカスタマ）3
ここでは、ISO27017管理策の解説をしていきます。
今回は、『11.2.7 装置のセキュリティを保った処分又は再利用』～『12.6.1 技術的ぜい弱性の管理』
まで解説します。
目次
※ ご覧になりたい項目をクリックすることで、該当のセクションにジャンプできます。
11.2.7 装置のセキュリティを保った処分又は再利用
自社で従業員のPCを廃棄する場合は、0クリアや初期化などを実施し、廃棄業者に委託することが一般的です。廃棄の経路で情報が流出しないようにするためです。
ところで、クラウドに情報を預けている場合、いくらクラウドと言っても、そのデータはクラウドの雲の中の何らかの物理的なサーバに保管されているわけですから、そのサーバが廃棄されるときに、適切な廃棄手順が定められ、実施されているかを確認する必要があります。もし、預けている情報の機密性がかなり高い場合は、廃棄証明書などを取得することも検討すべきでしょう。
また、IaaSの仮想サーバなどのクラウドサービスを利用していると、メンテナンスの都合上、仮想サーバのマイグレーション(別の物理サーバへの移行)がしばしば実施されます。
仮想サーバ移行元の物理サーバは、メンテナンスが終了した後には、おそらく再利用されるケースが多いでしょう。そのため、移行元のサーバから、自社のデータが確実に消去される仕組みになっておくことを確認することも、場合によっては必要となります。
12.1.2 変更管理
クラウドサービスの仕様は、良くも悪くも、コロコロと変わる場合が多いです。
例えば、今まで使えていた機能が突然使えなくなったり、急に新しい機能が追加されたり、デザインやボタンの位置が変更になったり、といった具合です。
クラウドサービスは、多くの場合、不特定多数のユーザーに向けたシステムで、オーダーメードシステムではないため、自社にとって嬉しくないサービスの変更は、ある程度は受け入れる必要があります。
しかし、セキュリティの観点で見ると、例えば、いままで非公開だった情報が急に公開になったり、メンテナンスで平日のお昼の時間帯にサービスが完全停止したりすると、いくら自社の要望に添えないといっても、ちょっと度が過ぎます。
そこで、この管理策では、そのような変更を適切に取り込む、変更管理手順を作りなさい、ということを要求しています。多くのクラウドサービスは、リリースノートと呼ばれるような、変更した内容を利用者にお知らせする仕組みを有しています。そのリリースノートを見て、セキュリティに関する重大な変更がないかを確認することも1つの方法です(ただし、リリースノートは、リリースされてから、変更の内容が投稿されるケースが多いため、注意が必要です)。
それ以外にも、メンテナンスの実施などによって、長期間サービスが停止する場合は「事前にEメールでの通知及びサービスのトップ画面に掲示します」などと、契約に記載しているサービスもありますので、そのような情報を事前に確認しておくことも大切です。
このような仕組みを上手く活用して、クラウドサービスの変更を事前に検知し、必要に応じて社内で周知・対策する仕組みづくりを行うことが大切です。
12.1.3 容量・能力の管理
クラウドサービスの特徴として、よく「スケーラブル」、すなわち「拡張可能性」という言葉が使われます。
これは、例えば、急にデータを保管する容量が必要となった場合でも、その必要な量に合わせて、保管できる容量を拡張することができる、というものです。
例えば、いま契約しているクラウドサービスのデータ保管容量が10GBまでだったとして、すでに9GB保管されていると仮定しましょう。ここに新しく3GBの情報を保管したい時、いくつかのクラウドサービスでは、追加で利用料を払うことによって、保管容量の10GBを、15GBや20GBのように拡張することが可能です。
ところが、この拡張は、即座かつ自動的に実施されるものもあれば、申込みをしてからしばらく時間が空き、反映されることもあります。後者の場合は、データをアップロードするまでの時間の空白ができてしまいますから、ビジネス上、あまり好ましくありません。
そのような事態を避けるために、クラウドサービスを使う前、もしくは利用中の定期的なタイミングで、そのクラウドサービスにおいて、現在自社が利用できる容量・能力(データ保存容量など)と、自社が現在利用している容量・能力を照らし合わせて、問題ないかを確認することが求められています。
また、将来的に自社がどれくらいの容量を利用するのかを検討(規格では「予測」という単語が利用されています)し、プランの変更や容量の拡張など、早めの対応を心がけることも大切です。
幸いなことに、多くのクラウドサービスには、容量・能力を使い切りそうになったタイミングでアラートメールなどの通知を出してくれるサービスが多いですので、そのようなサービスは有効に活用しましょう。
12.3.1 情報のバックアップ
クラウドサービス上に預けたデータのバックアップの責任は、しばしば問題となります。SaaSの利用の場合は、クラウドサービス提供者側に責任があることが一般的ですが、IaaSの場合は、利用者側に責任があることが一般的です。また、今は一般論を述べたのみで、上記に当てはまらないサービスも存在しています。
万が一、トラブルなどによりデータが滅失したときのために、データのバックアップに関する情報を、サービス提供者に要求することが求められています。
サービス提供者と利用者との間で、バックアップに関する責任がどちらにあるのか、明確にしておくべきです。
ちなみに、経産省のガイドラインを見ると、具体的にサービス提供者に情報を要求する内容として、「バックアップ機能および復元機能の有無」「利用者自身がバックアップを実施しなければいけない部分」「バックアップデータの暗号化の有無」「バックアップデータの保管場所」「バックアップデータの保管期間」などの例が掲載されています。サービスやデータの種類によっては、自社でバックアップを行う必要が生じる場合もあるでしょう。
その場合は、自社でバックアップの仕組みを整備し、実施する必要があります。
12.4.1 イベントログ取得
利用者によって、クラウドサービスに求めるログ取得の粒度はバラバラです。
例えば、ブラウザ経由で利用するクラウドサービスを考えてみると、内部統制の一貫などで、従業者のPCのブラウザ閲覧ログを取得している企業と、していない企業とでは、クラウドサービス側に要求するログ取得レベルが異なってくるはずです。
前者の場合は、ブラウザ閲覧ログを見れば、従業員がどんな動作をしているか、大まかな動きは取得できますが、後者の場合はそれが出来ず、従業者の動きを見るためには、クラウドサービスのログに完全に依存するしか無いからです。
クラウドサービスを利用する前には、あらかじめ、自社はクラウドサービスに対して、どのレベルのログ取得を求めているのかを定義し、そのレベルのログが取れるクラウドサービスを利用する事が望ましいです。
また、もう一つ見落としがちなのが、ログが保管される期間です。3日以内にログが消えてしまうようでは、何かインシデントが発生してしまったときに、活用することが難しい場合があります。
ログの種類と合わせて、期間も確認しておくようにしましょう。
12.4.3 実務管理者および運用担当者の作業ログ
利用するクラウドサービスによっては、クラウドサービスの実務や運用を行う管理者、すなわち特権ユーザーが、一般ユーザーのログを書き換えたり、削除したりすることが可能な場合があります。
12.4.1のログの管理策でログに関する情報を収集する際に、合わせて特権ユーザーがログに対してどのような操作が可能なのかを確認しておく必要があります。
また、12.4.1で取得されるログは、一般ユーザーの操作だけではなく、特権ユーザーの操作もしっかり記録されることを確認しておきましょう。
もし仮に、特権ユーザーが、ログを自由に編集できてしまう場合は、そのリスクを低減する方法を検討することが大切です。
例えば、ログの編集は特定のPCからのみ編集できるようにできないか、ログを編集したときにアラートができるようにできないか、ログファイルを読み取り専用にできないか、などが検討に値します。
内部不正はあまり考えたくはないですが、特権ユーザーが悪事を働かせる、あるいは、一般ユーザーが特権ユーザーに不正に権限昇格して悪事を働かせる、といったことも考えられます。
そのような事態を避けるために、特権ユーザーのログ操作をきちんと監視できるような体制を構築しましょう。
12.4.4 クロックの同期
外部から提供されるログを精査する時、ログに記載されている時刻をチェックする必要があります。なぜなら、社内のパソコンの時刻は日本標準時(UTC+9)なのにも関わらず、ログの時間が協定世界時(UTC)であった場合、ログの時間をわざわざ変換する必要があるからです。
また、あらかじめその「時刻がある一定時間ずれている」ことが分かっていれば良いのですが、分かっていなかった場合、ログ情報の信憑性が大きく低下することになります。国内のクラウドサービスを利用する場合は、多くの場合ログは日本標準時で提供されることが一般的ですが、海外のクラウドサービスの場合はそうではない可能性があります。あらかじめ、クラウドサービス上で取得されるログと、日本標準時とのズレを確認しておくと良いでしょう。
この管理策は、本来であれば、クラウドサービス提供者側に、ログのタイムゾーンと、時刻同期に関する情報(NTPの導入など)に関する情報を要求することが求められています。
もし仮に、1秒のズレも許されないログを取得する場合はしっかりと問い合わせるべきですが、多少のズレが許容できる場合は、自分のPCなどで確認するだけでも、問題になる可能性は低いと考えられます。
12.6.1 技術的ぜい弱性の管理
利用しているクラウドサービスも、人間が作ったものなので、なんらかのぜい弱性が含まれている可能性があります。また、日々セキュリティに関するニュースを見ていると、様々な製品のぜい弱性情報と、その対策方法が提供されています。
ところで、システムのぜい弱性の情報が公開され、その対策のパッチも公開されているのにも関わらず、利用しているサービスにそのぜい弱性が残ったままだと、預けている自社の情報が危機にさらされることになります。
そんな危険を避けるために、サービスの提供者が、サービスに関するぜい弱性をどのように管理しているのかを、あらかじめ確認しておく必要があります。
また、クラウドサービスの提供形態によれば、自社がぜい弱性に関する責任をもつ必要がある場合があります。
例えば、IaaSを利用している場合、利用している仮想サーバのOSに関するぜい弱性管理や、そこに導入しているライブラリに関するぜい弱性管理は、利用者側の責任になります。
まとめると、この管理策では、(1)クラウドサービス提供者がぜい弱性管理をどのように実施しているのかを確認する、(2)自社に責任のあるぜい弱性管理を特定し、実施する、の2つが求められていることになります。
取得される企業様の状況によって変わりますので、まずはお気軽にご相談ください。
