|
ITIL サービスデザイン − 情報セキュリティ管理 Vol.014 - 2009年06月22日
いきなりですが、ここまでの復習です。ITIL v3 の「サービスデザイン」に含まれるプロセスとして今までご紹介してきたものは、次の通りです。 ITIL v2 の「サービスデリバリ」と比べると、サービス・カタログ管理はサービスレベル管理から派生したもので、あとはだいたい同じようなものです。 「サービスデザイン」のプロセスはこのほかに、あとふたつあります。
です。これらは ITIL v2 にはなかったプロセスです。 「情報セキュリティ」と聞くと、どうしてもパスワードの管理だとか、社内への入退出管理だとか、営業マンのPC持ち出しについての取決めだとか、そうした具体的な施策に目がいきがちです。もちろんそれらも重要なのですが、ITILの世界では情報セキュリティの分野でさえも、IT中心ではなくビジネス中心に考える必要がある、と説いています。つまりITILにおける情報セキュリティ管理とは、ビジネスにおけるセキュリティとITセキュリティとを整合させること」であり、さらには「情報セキュリティが確実に効果的に管理されるようにすること」なのです。主役は IT ではありません。主役は、あくまでもビジネスです。 情報セキュリティといえば、一般には CIA という言葉がよく用いられています。CIA とは、次の３つの項目のことをいいます。
実際には、次の項目も念頭においておかなければなりません。
これらの考え方は ITIL に限ったことではありません。重要なのはこれらの項目に対する優先順位づけを、あくまでもビジネスとビジネス・プロセスに焦点をあわせて行なわなければならないということです。 企業における資源は、昔から「ヒト」「モノ」「カネ」と言われてきました。今やそれに加え「情報」も欠かせない資源です。その代えがたい資源である「情報」そのもの、およびその情報を取り扱うIT機器をセキュリティインシデントから守るのが、セキュリティ管理の重要な役割です。 さて、情報セキュリティ管理（ISM：Information Secury Management）の具体的な仕組みとして一般的、かつ代表的なものは、ISMS（Information Secury Management System）として知られています。また、ISMSの構築や実践のための規範は、ISO として国際規格化されています。ITIL でも、情報セキュリティ管理の具体的な活動に関しては ISMS、具体的には ISO 27001 を紹介しています。 （ちなみに ISO/IEC 27001 は ISMS に必要な要求事項を定め、ISO/IEC 27002 はその具体的な施策に関して定めています。ITIL が参照しているのは ISO/IEC 27001 だけです。具体的なやりかたについては言及しない、という ITIL らしさが、こんなところにも表れています。） ITIL では、ISMS をサポートするためには「４つのＰ」が必要である、と説いています。その４つのＰとは、次の通りです。 「人材（People）」 これらをバランスよく配備し、組織が情報セキュリティ・プロセスおよびコントロールを組織全体で体系的かつ一貫して設計、導入、管理、維持、実行することによって、高レベルのセキュリティフレームワークを構築することができるのです。 ISO 27001 において、フレームワークに含めるべき項目は次の５つです。 図１:ITセキュリティ管理のフレームワーク これは一般にいうところの「PDCAサイクル」です。さらに、そのPDCAサイクル全体をコントロールするための仕組みも必要です。業種・業態を問わず、セキュリティ管理を効果的に行うためには、ビジネス・プロセス全体において物理的、技術的両面における対策をビジネスの優先度と照らし合わせて実施することが必要ですし、その実施が効果的なものであったかどうかの評価も大切です。セキュリティ対策は、常にPDCAサイクル使ってチェックする確認する必要があります。 情報セキュリティ管理は、いわば「情報資産を安全に使えるようにする」ための活動です。情報資産が安全に使えないような何かが起きたのならば、それは「情報セキュリティインシデント」が発生したことになります。 ひとくちに「セキュリティ対策」とか「セキュリティ管理」といっても、様々な考え方があります。セキュリティインシデントが発生しないようにするとか、発生しても被害を最小限に食い止めるとか、被害が発生しても即座に復旧できるようにしておくとか・・・ITILでは「セキュリティ対策」という言葉を使わず、「セキュリティ・コントロール」と称しています。つまり、セキュリティレベルやセキュリティインシデントをコントロールしよう、という考え方ですね。セキュリティ・コントロールは、リスクのライフサイクル（潜在的に存在しているリスクが顕在化し、被害が発生し、それが収束するまで）の各段階に存在しています。それを図にしたものが、図２です。この図は ITIL書籍「サービスデザイン」に登場する図ですが、ここでは同書籍の本文と整合性をとるため、一部変更しています。 図２:脅威とインシデントに対するセキュリティ・コントロール この図をもう少し説明しましょう。 まず、脅威はあるがリスクがまだ顕在化していない状態、すなわちセキュリティインシデントが発生していない状態においては、そのセキュリティインシデントが発生しないように努めたり、発生してもその被害を最小限に食い止めるような措置を講じたりする対策が考えられます。すなわち、次のふたつです。
それにも係わらずセキュリティインシデントが発生してしまった場合は、その発生をすみやかに検出し、インシデントを無効化する必要があります。それが、次のふたつです。
セキュリティインシデントによって被害が発生してしまったのであれば、その被害を元の状態に戻すことが最後の活動になります。
これらのセキュリティ・コントロールの具体的な方法を決定したら、それを文書化する必要があります。文書化の中には、コントロール方法の運用、維持、改善の方法まで言及しておくほうが望ましいといえるでしょう。と同時に、それぞれのコントロールに関して定期的に評価すると共に、セキュリティインシデントが発生して各コントロールを発動することになった際には、その活動記録をとり、成果を報告する必要があります。 情報セキュリティ管理プロセスは、その目的や適用範囲から考えると、ITシステムだけでなく、ITサービスの内容すべてを考慮にいれなければなりません。つまり、守るべき「情報」であるデータと、そのデータを扱うITインフラストラクチャ、さらに、ITインフラが提供しているITサービス、さらにはその先にあるビジネスサービスに至るまできちんと把握しなければならないということです。その上で、セキュリティ・コントロールの要件をどうするかということを決めていきます。特に下記のような内容には注意が必要です。
セキュリティ・コントロールは全社規模に及びますし、たいていの場合膨大なコストがかかります。したがって情報セキュリティ方針の策定には、ITの上級マネジメント（CIOなど）の全面的な支援が必要です。さらに、事業の上級マネジメント（CEOなど）の全面的な支持とコミットメントを得られるのが理想的です。上級マネジメント層の情報セキュリティ方針は、事業ニーズを満たした上で、次の項目を含みます。
方針は、すべての顧客とユーザが利用可能であるべきで、これらのコンプライアンスはすべてのSLR、SLA、契約および合意に記載されます。すべてのセキュリティ方針は、少なくとも毎年レビューされ、必要な場合は改定されます。このように情報セキュリティ管理が扱う情報は、広範囲にわたり多く情報が複雑に絡むことになります。話が前後しますが、これらの活動を支えるための共通の仕組みが「情報セキュリティ管理システム（ISMS）」であり、そのための国際規格が ISO/IEC 27001 なのです。 次回は「サービスデザイン」の最後のプロセス、サプライヤ管理のお話です。お楽しみに。 |
