監修・NPO日本ネットワークセキュリティ協会 セキュリティ監査WG
文・河野省二（ディアイティ セキュリティビジネス推進室 室長）
地方自治体や中央省庁向けに情報セキュリティポリシー策定支援の現場では策定者の皆さんからいろいろな悩みを打ち明けられます。その中でもっとも多いのが、情報セキュリティ実施手順の作成が思うように進まないという問題です。
策定者の皆さんは、組織にとって必要な情報セキュリティ対策を検討しているのですが、それがどうしても「理想的なセキュリティを目指す」ということになってしまい、実際に運用するにはハードルが高くなってしまいがちです。
情報セキュリティマネジメントの確立という意味では高いレベルで良かったのかもしれませんが、具体的な情報資産のマネジメントを求められる情報セキュリティ監査では、セキュリティ対策を具体化するためのアイデアを出していく必要があります。
情報セキュリティ監査を前提に、「情報資産が正しく運用できていることを明確にするための証拠」を作り出すことのできる情報セキュリティマネジメント体制とは、どのようなものなのでしょうか。また、利用者が責任を持って情報セキュリティに取り組むためには、どのように情報セキュリティ実施手順を作成したらよいのでしょうか。
|
■システム管理者とセキュリティ担当者
情報セキュリティ実施手順は、「システム利用規定」と「システム利用手順書」に分かれます。前者はシステム管理者（運用責任者）が作成するもの、後者はセキュリティ担当者（利用責任者）が作成するものです。今回は、この「システム利用規定」と「システム利用手順書」について解説します。ポイントは「利用者側の責任について定めるシステム利用手順書を、利用者自らに作成させる」ということです。
 |
地方自治体の情報セキュリティ対策基準の「人的セキュリティ」の項には、「情報システム管理者」と「情報セキュリティ担当者」に関する記述があります。これらの役割をうまく利用し、情報セキュリティ実施手順作成を円滑に行う仕組み作りをしてみましょう。
「情報システム管理者」と「情報セキュリティ担当者」について簡単にまとめてしまえば、情報システム管理者とは運用責任者であり、情報セキュリティ担当者とは利用責任者のことを言います。
情報セキュリティ担当者というのは漠然とした名前ですが、具体的には、「部局等の各情報システムを利用し、その所管組織の情報セキュリティに関する権限及び責任を有する者」であり、地方自治体組織で言えば各部局の長がこの役職に就くことになっています。つまり、情報システム利用における、情報セキュリティに関する権限と責任を持っているのが、情報セキュリティ担当者です。
もちろん一つのシステムに複数の利用責任者がいることもありますし、情報システムの管理体制によっては情報システム管理者と情報セキュリティ担当者を兼務する場合もあります。ここで重要なのは、それぞれの役割に基づいてルール作り、文書作成を行うということです。どちらの立場でものを見ているのかを明確にしないと、より良い情報セキュリティ対策手順作成はできません。
システム利用規定を作成するのはそれほど難しくありません。従来通り、運用管理側でできることを中心にクライテリア（守るべき内容の一覧）を作成していけばよいでしょう。
このときに注意しなければいけないのは、運営者の責任と利用者の責任を明確にしなければいけないということです。
どこまでをお互いの責任範囲とするかについては、情報セキュリティ基本方針や人的セキュリティに関する対策基準を参照するとともに、システムのサービスレベル（別途参照）を考慮することも忘れてはいけません。
■システム利用手順書
──利用者側が実際の業務内容を反映させる
情報セキュリティ実施手順におけるシステム利用手順書には、システム利用規定に記載された利用者の責任範囲に基づいて、システムをどのように利用するかの方針を記載します。
例えば、「システム利用障害発生時には、直ちにシステム管理者に状況を報告すること」という規定がシステム利用規定に設定されていた場合、システム利用手順書ではこれを受けて、「利用者は、システム障害発生時には、添付の報告書テンプレートに必要事項を記載の上、セキュリティ担当者に連絡をすること」「セキュリティ担当者は利用者からの報告を速やかにシステム管理者に伝えること」といったの具体的な方法が記載されることになります。
もちろん免責事項についての記載を忘れてはいけません。システムを正しく利用しているにもかかわらず障害が発生した場合は、利用者側に責任が生じない（運用側の責任範囲である）ということを明確にしておかなければ、利用者の責任範囲が広くなってしまう可能性があるからです。
自治体などのシステムの場合、ひとつのシステムを複数の組織で利用することがあります。その利用方法はさまざまですが、具体的なセキュリティ対策は一つしか用意されておらず、不十分になる可能性があります。システム利用規定は、システム管理者が利用環境や業務内容を想定して決定していますが、業務内容に精通していない場合、セキュリティ対策にも見落としが出てしまいがちです。
十分なセキュリティを確保するためには、利用者側が実際の業務内容を反映した形で対策を行う必要があります。つまり、利用者側の責任について、利用手順書を利用者に作成してもらう必要があるということです。これが情報セキュリティ実施手順作成の難しい点であり、策定者の悩みになっているのですが、ここをクリアしないと確実なセキュリティ体制を敷くことはできません。
システム利用規定によって、システム管理者は運営側の責任を宣言し、システム利用手順書によってセキュリティ担当者は利用側の責任を宣言する。お互いが免責事項を提示することによって、責任範囲の明確化ができ、円滑な運営ができるようになるのです。
こうしてできたシステム利用手順書は、セキュリティ担当者が情報セキュリティ委員会で検討されることになります。委員会はこれを承認してシステム管理者に提出し、手順書の記載に問題がないと判断された場合、はじめてシステムを利用することができるようになります。
情報セキュリティ監査を受けるには、システム利用規定やシステム利用手順書に記載されたことが具体的に実施されている証拠を残す仕組みを作らなければいけません。
システム利用規定ではシステムが記録するログについて必要な範囲内で提示します。システム利用手順書ではこの内容を受けて、具体的な対策の実施が説明できないと判断した場合に、ログだけでは足りない内容について補足するための具体策を盛り込む必要があります。ただし、さまざまな記録はシステム側で一元管理できることが望ましいので、十分な情報が記録されないシステムにおいては、システム管理者とセキュリティ担当者の間で改善案を十分に話し合うと良いでしょう。
■情報システムにおける管理者の責任、利用者の責任
ここからは、個別の注意事項をいくつか述べたいと思います。
まず、管理者と利用者の関係についてです。管理者にとっての情報システムのセキュリティとは、これまではより堅牢なシステム構成を構築し、維持することでした。利用者がセキュリティを意識しない環境作りをすることはシステム管理者にとって重要な仕事です。しかし、この意識が強すぎると、利用現場ではかえって不十分なセキュリティ環境となってしまいます。
例えばファイアウォールの導入を考えてみてください。はたして、自分が参加しているネットワーク上にあるファイアウォールの設定がどのように行われていて、どのポートへの通信が許可されているかを利用者は知っているでしょうか。
多くの場合、利用者はこの情報を知りません。それは自分たちが参加しているネットワークにおいて、どのような振る舞いをして良いのかという判断基準を与えられていないということになります。どのような責任を持って、どのような利用をすれば良いのかが分からない、つまり、情報セキュリティ対策手順書作りのための基礎が確立されていない状態なのです。
このような問題が、利用者のセキュリティ意識の希薄さを生み、ネットワークの接続違反（モデムを利用した外部ネットワーク接続、ＣＤやFDDなどのメディアによるデータ移動）を増長させることになっています。
■組織内SLAを作り、責任範囲をハッキリさせる
サービスレベルとセキュリティの基準の整合性も、はっきりさせておくべきでしょう。
セキュリティ対策をどこまですれば良いのかという疑問と、情報セキュリティ実施手順をうまく作ることができないという問題の本質は同じところにあります。
まず、現状で問題が起きていない、そして問題が起きそうもないのに、これ以上なにをすればよいのかわからないということです。そして、そもそも問題が起きる（起きた）というのはどういう状態なのかがわからないということです。
例えば、明らかにネットワークに接続されないというのであれば、これはトラブルだと判断できますが、ネットワークが遅くなったというのはトラブルなのかどうかを判断できないということです。
読者の中には、ネットワークの速度の低下をトラブルだという方もいれば、許容範囲だという人もいるでしょう。
正解は「著者にもわからない」です。なぜなら、正常な動作が何かということが明確にされてないのに、異常かどうかは判断できないからです。
組織においてトラブル情報を正しく収集し、対策をしようと思ったら、どのような状態が正常なのかを決めておかなければいけません。
もちろんネットワークの速度だけではなく、様々なサービスの稼働時間や、システムのレスポンスというのもあるでしょう。これらのことがらについて運用者と利用者の間で取り決めたものをサービスレベル合意（SLA）といいます。その中でも組織の中での運用を前提としたものを、ここでは組織内SLAと呼ぶことにします。
組織内SLAを定義するためには、次のことに考慮する必要があります。
- 運営者も利用者も同じ判断ができる基準
- サービスレベルの現実性と免責事項
- サービスレベルを維持するための利用者の責任
- サービスレベルを維持できない場合のペナルティ など
例えばWindows Serverでファイルサーバを運営する場合、Windowsのセキュリティパッチの配布状況などもサービスレベルに大きく関わってきます。再起動が必要なパッチの場合は起動時間が稼働時間から差し引かれるためです。運営側はこの値をしかたないものだと考えたとしても A利用者の立場になればサービスが停止していると考えるでしょう。大規模なシステムほど起動に時間がかかるでしょうから注意してください。
ちなみに99.9パーセントの稼働率というのは、年間の停止時間が8.76時間です。これを十分な時間と考えるかどうかは、それぞれのシステムによって異なるでしょう。以下にSLAに必要な項目について記載します。具体的な内容については総務省の発行する「公共ITにおけるアウトソーシングに関するガイドライン」を参照してください。
＜SLAに必要な項目＞
- サービス要件
- サービス内容
- サービスレベル定義
- サービスレベルの測定方法
- 利用者の責任
- ペナルティ
- 免責事項 など
◆ ◆ ◆
利用者の情報セキュリティリテラシーを持たせることがむずかしいという話をよく耳にしますが、今回の説明したシステム利用手順書作成のように、利用者がセキュリティ対策の策定に参加できる／せざるを得ない体制を作ることで、少しずつセキュリティというものについて考えることができるようになるのではないでしょうか。
利用者自身の責任範囲の明確化、これができたとき組織のセキュリティはより確実なものとなるのだと思います。
|
|
