Last Updated 2003/1/2

●Security INDEXへ

★TOP INDEXへ


NetworkWorld 2002年10月号掲載

セキュリティポリシーの書き方

セキュリティポリシーとはどのようなものなのか見てみよう。
セキュリティポリシーと関連ルール体系は、一般に次のような構成である。

(1)セキュリティポリシー=セキュリティに関する大方針
(2)スタンダード=指針、ガイダンス、ガイドライン
(3)プロシージャ=手順書

それぞれどのようなものかをイメージしていただくために、さらに詳しく見てみよう。

(1)セキュリティポリシー
セキュリティポリシーは宣言文のようなもので、抽象化したセキュリティ上の方針を記述するものだ。具体的なルールというよりも方針であり、例えば、

というように記述する。トリトンX社の情報資産が何か、とか、どうやって守るのか、ということを具体的に書くのは別のルールに任せて、ここでは「守らなければならない」という方針だけを示しているだけだ。
あるいは、 などと書く。ここでは不正に利用されていたり、改ざんされているというのがどういう状態なのか、どういう手順で誰に報告しなければならないのか、ということは書かず、原則的な義務だけを書いている。

(2)スタンダード(ガイドライン)
スタンダード(ガイドライン)はポリシーよりも具体的である。ここでは、組織や企業の業務のさまざまな局面で、どのような要件のセキュリティ保護策が必要か、ということを具体的に記述する。例えば、

というようなガイドライン群を作成する。内容には各ガイドラインの対象となる局面でのリスク管理策=セキュリティ要件を盛り込んで、ガイダンスに従って契約書等を作成すれば良いようにしてしまう。罰則などについても言及する。

(3)プロシージャ(手順書)
プロシージャはスタンダード(ガイドライン)よりも詳細に、具体的な一つ一つのオペレーションについて記述する。例えば、

というような文書を作成し、それぞれの作業手順を記述する。
例えばバックアップ手順書の中身は、
  1. DATテープを取り出し、最も古い世代のDATテープと入れ替える
  2. mtコマンドを使い、マウントして使用可能かどうかを確かめる
などと記述し、事情を知らないものが読んでも分かるような、読めばすぐにオペレーションできるようなものにしておく必要がある。

原則、このような文書が3種類必要だが、(2)スタンダード(3)プロシージャははっきりと分けられない場合もある。あるいは、無理矢理分けて記述する必要が無い場合もある。例えば、わざわざスタンダード(ガイドライン)にするまでもなく、決まりきった手順書が一つあれば良い場合などだ。または、ガイドラインを手順書のように細かく書いてしまう場合もある。もちろんそういう場合、無理にスタンダード(ガイドライン)とプロシージャ(手順書)に分ける必要は無い。セキュリティポリシーと関連ルール体系を作る目的は、関係者に基本的なセキュリティの方針をのみこませて、突発的な事態を含む業務の各局面でセキュリティ的に問題となるような行動を取らせないようにすることである。ルール体系の整合性が取れていなかったとしても、その目的を達することができれば良いはずだ。
さらに、(1)セキュリティポリシーもひとつにして、ポリシーであり、スタンダードでもあり、プロシージャでもある、という構成にする場合もある。
ただ、ポリシーは公開する可能性なども考えると(後述するが、筆者はセキュリティポリシーは公開した方が良い場合が多い、と考えている)、あまり細かいオペレーションなどが記述されていることは好ましくない。必要以上の情報を漏らすことはリスクを増大させることにつながるからだ。そういう意味では、ポリシーは抽象化されたスローガンのようなものにしておく方が良いだろう。 また、ポリシーは経営方針のようなものである。ということは大きな組織などにもなると、修正して再公布することになったときに内容を承認されて実際にオーソライズされるまでに手間や時間がかかってしまうことも有り得る。そういう場合などには、全体の基本方針としてポリシーを位置付けて、管理単位ごと、部署ごと、部局や支店ごとのルールをスタンダードやプロシージャで担当する方が良いだろう。職掌などと同じくルール体系上も管理の及ぶ範囲ごとにルールを分けてしまうのだ。そうするとルールそのものを変えることもそれほど躊躇しなくなるため、実効性があるルール体系にしやすいはずだ。

ではまず、おおもとの方針となるセキュリティポリシーはどうやって作れば良いだろうか?
一般的なセキュリティポリシーの作成手順は以下のとおり。

(1)情報資産洗い出し(プライオリティの設定)
(2)リスク分析
(3)ポリシー文書作成(優先度が高いものから。スタンダード、プロシージャという順に作成する)

理想的な手順としてはこのようになるが、(1)の情報資産洗い出し→プライオリティの設定というところは、数ある情報資産を列挙して、そのうち大事な資産はどれになるのか設定しましょう、という段取りである。このフェイズでプライオリティを設定しておくと、以降の作業はある程度範囲を絞り込めるのでラクになる。
範囲の絞込み、という点では、リスク分析を行なう前にセキュリティポリシーを作成しても良い。
もちろんこの場合作成するセキュリティポリシーはテンプレート文書や雛型文書を使って暫定的に作るものになる。後述するが、スタンダード(ガイドライン)やプロシージャ(手順書)と異なり、セキュリティポリシーは引用しやすい文書であり、暫定的に設定してもそれほど無理はないはずだ。であれば、範囲を限定するためにポリシーをまず設定する、という段取りも、これはアリである。 先にポリシーを設定する場合の段取りは、

(1)セキュリティポリシー設定(範囲の設定)
(2)情報資産洗い出し(範囲内。プライオリティの設定)
(3)リスク分析
(4)ポリシー文書作成(セキュリティポリシー自体の修正、スタンダード、プロシージャという順に作成する)

というものになるだろう。
リスク分析については別稿で述べる。
いずれのやり方を採用したとしても、最後にポリシー文書を作成する。

ではここでポリシーの仕様を考えてみよう。
セキュリティポリシーの仕様(ポリシーを書く上で注意すべきポイント)

セキュリティポリシー文書の構成はこのようなものになる。

宣言文と備考以外は必須だ。
まずその必須でない部分を見てみよう。
宣言文は、まさしく経営方針とでもいうようなもので、社長なり会長なりのその組織の最高責任者が「うちはセキュリティを守るぞ!えいえいおー!」とブチ上げるものだ。それは冗談としても、例えば、

「トリトンX社は情報サービスを生業とする企業である。「情報」を「サービス」する、あるいは「情報処理」を「サービス」する会社が、情報セキュリティを疎かにして良いわけがない。情報セキュリティを守ることは、会社の資産を守ることに他ならない。
現在では情報セキュリティを守ることは企業として必須の使命であり、トリトンX社の全スタッフはつねにそのことを念頭に置いて業務を遂行すること。情報セキュリティを守ることは同時に、トリトンX社が企業間の競争に参画しうる資格を得る、ということでもある。自らのビジネスを成功に導くために、全てのスタッフは主体的に情報セキュリティを守らなければならない」

などとブチ上げる。
例示は少し文学的すぎる表現だったかも知れないが、ここで宣言することは要するに「情報セキュリティを守る」ということが自分たちの主要な使命である、ということである。最高責任者がそれを宣言することで、経営計画、経営方針とセキュリティ方針が同等レベルのものである、ということを意識させるわけだ。平たく言えば「お墨付き」ということだ。
備考というのは別に無くても良さそうなニュアンスがあるが、必ずしもそうではない。どんなルール体系にも例外事項を設けなければならない場合がある。セキュリティポリシーの例外事項が、仮にあるならばここに書く。

例外事項の例:
「このセキュリティポリシーは、トリトンX社の海外場所には適用されない。海外場所は提携先と協議の上、作成されたポリシーに従う」
「このセキュリティポリシーは、Wトリトン社との部署合併を進める部署には適用されない。当該部署はWトリトン社の合併対象部署と協議の上、作成されたポリシーに従う」

原則としてポリシーに例外を作らない方が良いことはもちろんだが、企業や組織がさまざまな形態で業務融合したり、部署単位合併したり、部署ごとアウトソースするなどの流れがあることは無視できない。今までのように単純にトップダウンのヒエラルキーでくくれない組織形態が出てきている場合などは、やむを得ず例外とせざるを得ないこともある。適用しない、適用できない、というときは、リスクヘッジをきちんと記載した上で例外とすることも検討する。

さて、ポリシー本文について見ていこう。
まずはこの文書に記述されたルールや方針に関する管理者、責任者はだれなのか、を記述する必要がある。これはポリシーを修正・変更する場合に必要となる情報だ。一般にはそのポリシーの対象範囲となる組織のトップが責任者であるべきだ。企業の場合は社長が責任者である。それは当然といえば当然で、セキュリティ上の経営方針についての責任はトップが負うべきものである。ポリシーの権威付け、強制力という面から見ても、その組織の最高責任者がポリシーにも責任を負うのが自然だ。
となれば、宣言文の中でセキュリティ上の方針を示し、ポリシーを遵守させることを宣言するのも最高責任者であるべきだ。
次に対象範囲についても記述しておく。
その組織内の業務すべてについてのポリシー、と言い切ることができれば簡単だが、組織や企業の形態も多様化しつつある現在、複雑化するその形態すべてを範囲の内とするポリシーを一気に作り上げることは難しいことも多いだろう。となると、特定の業務(例:セキュリティソリューション部の業務を範囲とする)や特定の組織(組織と業務は一致することが多いが)、というように範囲を絞ることにならざるを得ない。
範囲を絞るのであればなおさら、範囲については具体的に書いておく必要がある。
範囲は業務で特定されるだけではなく、例えば人である場合もある。例えば、社員のみ対象としビジネスパートナーの常駐社員などは対象外とする、とか、アルバイトやパートは範囲外とする、なども考えられる。もちろんセキュリティポリシーの適用対象から外れたからといって、管理の対象でなくなるわけではない。ビジネスパートナーの常駐社員を対象外とするならば、ビジネスパートナーとの契約で「セキュリティ侵害を起こさないこと。起こした場合は賠償する」などとリスクヘッジする必要がある。リスクをどこが負うかはビジネスパートナーとの取り決めになるが、どこが負うにしても全くフリーで活動できる、ということではない。
どちらがリスクを負うか、によって対象範囲とするかどうかが違ってくるというだけだ。
人への範囲が定義できたら、その中に登場する各プレイヤーの果たす役割(責務)について記述する。
例えば、一般的な社員の責務、情報資産の所有者・管理者としての責務、情報資産のユーザーとしての責務などを定義する必要がある。例を挙げると、 「ある情報の管理方法については、情報の所有者が決めなければならない」 というようなものだ。これは本文(条文)で定義しても良いが、プレイヤーの定義についてはどこかで記述しておく。
次に本文(条文)を書く。
本文(条文)は、これまでの中でいくつか例を挙げておいたが、例えば、

「われわれトリトンX社のスタッフは、所有する情報資産を守らなければならない」
「われわれトリトンX社のスタッフは、情報資産の改ざん・漏洩・破壊を発見したら、即セキュリティ委員会に届けなければならない」

というように条文の主体となる主語、および目的範囲、行動をくっきり書く。本文(条文)では「日常的な業務をこなす中での基本的な考え方やあるべき姿勢」を示すのだ。
逆に言えば、条文として書くものは「基本的な考え方」だけで良いのである。だからポリシーは抽象的だと言われるのだ。また、業務内容や業態に多少の違いがあっても、お客さんが居て、サービスや製品を提供している、という大多数の組織の目的と外れていなければ、ポリシーに大きな違いは出てこないはずだ。企業であろうと役所であろうと、行政府であろうとNPOであろうと、それぞれに「お客さん」が居るし、それぞれその「お客さん」に提供している「サービス」や「製品」があるのに違いはない。となると「お客さん」についての情報は守らなければならないし、守れなかったらその組織には大きな打撃になるだろうし、「サービス」や「製品」についての情報も守らなければならないし、やはり守れなかったら打撃になるはずだ。
ポリシーはどんな組織であってもあまり変わらないものである。
したがって、ポリシーは流用しやすいと言える(笑)。
ということは、自分で書き起こす場合でも、サンプルやテンプレートを参考にして書けばほぼ間違いは無い、ということでもある。あるいは、教科書などからも引用しやすい、ということでもある。サンプルをかき集めて作り上げる、というアプローチも意識しておいて損は無いだろう。

さて、次にスタンダード(ガイドライン)とプロシージャ(手順書)について見てみよう。
情報セキュリティポリシー文書を作成するとき、実は一番難しいのがこのガイダンスを仕上げる部分である。前述のようにポリシーを書くことはそれほど難しくないが、ガイダンス(スタンダード、プロシージャ)を書く場合、業務や運用などの手順を具体的に設計して、漏れや穴が無いかどうかを見極めることができないとならない。また、分析したリスクが低減されているかどうか、他に想定できるリスク管理策とどちらが相応しいのか、その判断も出来ないとならない。そういうノウハウが必要となるため難しいのだ。そういう判断の、少なくとも材料までは専門家を入れて助言を聞くということが近道だ。
ただし、ガイダンス(スタンダード、プロシージャ)を書くときに、当事者である現場スタッフが全く関与できないかというと、そうではない。
ガイダンス文書を書く場合、業務プロセスについて理解し把握していなければ書けない。外部のコンサルタントが入って、そして把握するという段取りもあるが、それよりも組織のプロパーとしてその業務の真っ只中に居るスタッフがガイダンス作成に関わる方が良い。何度も書くが、現場と乖離したルールは無視されてしまうのがオチだからだ。
現場のスタッフを巻き込む効果はまだある。それは宣伝、フィードバックだ。 何度もレビューを行なうたび、あるいはガイダンス作成作業の進捗を直属の上司(現場の管理者)に報告するたびに、どんな内容のルールが作られているのか、どんな考え方で作っているのかを宣伝することになる。そしてそこでの反応を確かめることで、現場の真摯な声のフィードバックを得ることもできるのだ。言ってみれば現場のスタッフを「宣伝マン」としても利用し、「フィードバックレポーター」としても利用するわけだ。
おまけに現場スタッフは当然ながら業務の現場を知っている。これは巻き込まない手は無いだろう(もちろんいつも問題となるのは、現場からスタッフをある時間引っこ抜かなければならない、ということだが、調整交渉してでも引っこ抜く価値はある)。
人材がそろえば書き始める。
ガイダンス文書を書く上で参考になるのは、なんと言ってもセキュリティ標準だろう。ISO17799(BS7799)はガイダンスへの一般的な要件をチェックするのに使える。ISO13335(GMITS)のPart4にはセーフガード(要するにリスク管理策、セキュリティ対策のことだ)に関してさまざまな記述がある。その中にルールや業務遂行手順への要件もあるので参考になる。
人材と参考文献の準備が整ったら、漠然とスタンダード(ガイドライン)、プロシージャ(手順書)などと書いてきたが、その分け方を考えてみよう。
ガイドラインと手順書の違いはどこにあるのだろうか?
一番シンプルな見方は、

というものだろうか。
例えば、顧客との契約行為はいろいろな業務で発生する。しかし、「インターネット向け公開Webサーバーのバックアップ手順」というのは特定業務の特定のオペレーションに限られる。企業や組織のさまざまな業務を切り出して、複数のパターンが有るときはリスク管理要件をガイドラインにまとめ、一つ二つのパターン以外無い場合は手順書に落としてしまう。・・・というような切り分けがわかりやすいのではないだろうか。
業務を切り出すことは普通そんなに難しいことではないはずだ。ISO9000の品質管理的な考え方を援用するとさらに分かりやすい。切り出した業務をいくつかのプロセスに分割し、各プロセスのinputとoutputを考える。品質管理はまさにそういう形で業務フローを作り出すために有効だ。
セキュリティポリシーを作る目的は、ある意味品質を管理することに近い。したがって同じような分析、同じようなアプローチを取っているし、方法論をそのまま使えることも多い。このあたりは別稿で述べるが、ISOやBSなどの標準は洗練されたテンプレートでもあるため、積極的に援用すべきである。
また、日本ネットワークセキュリティ協会のセキュリティポリシーワーキンググループが、セキュリティポリシーのサンプル(現在は0.91版)を公開している。サンプルはポリシーそのものと、29のスタンダード(標準)から成り、一般的にインターネット接続を利用し、かつ自社で公開セグメント(DMZ)を運営している企業をモデルにしている。業務の中で情報セキュリティに関わる部分はほぼすべてが用意されているため、書き方等を含めてぜひ参考にしたい。

本稿の最後に、JNSAポリシーとセキュリティ標準以外の参考文献などを示しておく。
「セキュリティポリシーでネットビジネスに勝つ」三輪信雄・著(NTT出版、2000年6月、ISBN4-7571-0034-5)
「ネットワーク危機管理入門」上原孝之・著(翔泳社、2000年7月、ISBN4-88135-914-2)
「国際セキュリティ標準ISO/IEC 17799入門」田渕治樹・著(オーム社、2000年12月、ISBN4-2749-4633-9)
「セキュリティポリシーの作成と運用」Thomas R. Peltier・著、三輪信雄・監訳、ISPP翻訳有志・訳(ソフトバンクパブリッシング、2001年12月、ISBN4-7973-1468-0)

Copyright © 2002-2003 Sonoda Michio

●Security INDEXへ

★TOP INDEXへ