1<- index ->3


2. セキュリティポリシー English

本書において、何度となくポリシーについて言及することになります。このような言及において、しばしば、特定のポリシーについての推奨にふれることがあります。読者のみなさんが、本書の後のほうで推奨されるポリシーを立案するにあたっては、このようなポリシーを作成・検討するやり方についての指針を反復するよりも、この章にある助言を適用すべきです。

 

2.1 セキュリティポリシーは、なぜ必要か? English

セキュリティに関連した意思決定をすることありますし、場合によっては、それがうまくいかないこともあります。つまり、管理者が、広範にわたってあなたのネットワークがどの程度セキュアか、あるいはそうでないのかを判定するとき、あなたのネットワークにどれだけの機能が必要か、さらに、あなたのネットワークの使い勝手はどうかを判定することがあります。しかし、まず最初にあなたのセキュリティの目標を明確にすることなしに、あなたは、よい意志決定をすることができません。あなたのセキュリティの目標が何であるのかを明確にしないことには、あなたは、有効にセキュリティツールを使いこなすこともできません。なぜならば、何をチェックすればよいのかわからないということですし、どのような制約を課すかがわからないということだからです。

例えば、あなたの目標は、おそらく、ベンダーの目標とは異なるものでしょう。ベンダーは、とかく自社製品の設定と運用をできるだけシンプルにしようとします。よって、デフォルトの設定は、しばしば全開になっています。(つまり、セキュアでないということです。) これによって、新製品をインストールすることは容易になりますが、同時に、このようなシステムと、これらを通じた他のシステムへのアクセスを、ユーザに開放したままにしてしまいます。

あなたの目標は、下記の相反する重要な要素によって決定されることになります。:

(1)   サービスの提供 VS セキュリティ -
ユーザが使用する個々のサービスは、それぞれに固有のセキュリティリスクをもっています。サービスによっては、そのリスクはそのサービスから享受できる便益よりも大きい場合がありますので、管理者がそれらにセキュリティ対策を施すのではなく 、そのサービスの停止を選択することもありえます。
 
(2)   操作性 VS セキュリティ -
最も使い勝手がよいシステムというものは、どんなユーザにもアクセスを許容してしまい、パスワードは要求しないものでしょう。; つまりセキュリティのないものということでしょう。パスワードを要求することによって、システムは幾分面倒になりますが、 安全にはなります。 別デバイスでのワンタイム パスワードの生成を要求することによって、システムは、さらに面倒になりますが、格段にセキュアになります。
 
(3)   セキュリティのコスト VS 損失のリスク -
セキュリティについては幾種類ものコストが発生します。: 金銭面(例: ファイアウオールやワンタイム パスワード ジェネレータのようなセキュリティハードウエアとソフトウエアを購入するコスト)、 性能(例 暗号化と復号化には時間がかかります。)、操作性(既に述べたとおりです。)などがあげられます。また、いくつものレベルのリスクがあります。: プライバシーの侵害(例 承認されていない者が情報を読むこと)、データの喪失(例 : 情報の破損や消失)、サービスが不能になる状態(例: データ保存スペースが満杯、計算資源の枯渇、ネットワークアクセスが不能)。それぞれのタイプのコストは、それぞれのタイプの損失に照らして見積もらなければなりません。

「セキュリティ ポリシー」と呼ばれる一式のセキュリティのルールについて、あなたの目標は、すべてのユーザ、運用スタッフおよび管理者との間で意見交換される必要があります。我々は 、より狭義の「コンピュータセキュリティポリシー」ではなく、この用語 (セキュリティポリシー)を使います。それは、この範疇には、すべてのタイプの情報技術、その技術によって蓄積される情報および扱われる情報が含まれるからです。

2.1.1 セキュリティポリシーの定義 English

セキュリティポリシーは、ルールについての公式な表明であり、組織体の技術と情報資産にアクセスできる状況にある人が、必ず守らなければならないものです。

2.1.2 セキュリティポリシーの目的  English

セキュリティポリシーの主目的は、ユーザ、スタッフおよび管理者に、技術と情報資産を守るために求められる義務を伝達することです。ポリシーは、このような義務に合うように、その役割を定める必要があります。他の目的として、コンピュータシステムやネットワークを購入・設定・監査するための出発点としての目的があげられます。それゆえ、最低限の条件であるセキュリティポリシーが 無くしてセキュリティツールを使おうとしても意味がありません。

AUP( Appropriate Use Policy:適切な使用法のポリシー)も、セキュリティポリシーの一部といえます。これには、ユーザが様々なシステムのコンポーネント上で何をしてよいのか、何をしてはいけないのかが記述される必要があり、これには、そのネットワーク上で許可される通信のタイプが含まれます。AUP は、あいまいさや誤解を防ぐために、可能なかぎり明快である必要があります。

例えば、AUP では USENET のニュースグループで禁止されているすべてのことがらが、掲げられるかもしれません。(注意: AUP は、サイトによっては Acceptable Use Policy の略語とされています。)

2.1.3 ポリシーを形成するのにあたって誰が関与すべきか?   English

セキュリティポリシーを適切で有効なものとするためには、その組織内のすべての階層の従業員の受容と支持が必要です。次にセキュリティポリシーの文書の作成とレビューに参画すべき人々のリストを示します。:

(1)   サイトのセキュリティの管理者
(2)   情報技術のテクニカルスタッフ(例: コンピュータセンター派遣のスタッフ)
(3)   その組織内の大きなユーザ グループの管理者(例: 事業部、 大学内のコンピュータサイエンス学科等)
(4)   セキュリティ IRT (Incident Response Team)
(5)   セキュリティポリシーによって影響を受ける各ユーザグループの代表者
(6)   経営管理者
(7)   法律顧問 (それが適当である場合)

上記のリストは、多くの組織における典型例ですが、必ずしもこのままである必要はありません。以下のような案も考えられます。

組織体によっては、EDP 監査の原則を含めるのが適切であることもあるでしょう。ポリシーの表明が、広く受容されるようになるのであれば、このグループに参画することは重要であるといえます。法律顧問の役割は、国ごとに異なることも述べておきます。

 

2.2 よいセキュリティポリシーを策定するのに必要なものとは?  English

よいセキュリティポリシーの特徴を下記に掲げます。:

(1)   システム管理の実務や実効性のある使用にあたってのガイドラインの発表、 もしくは、他の手法において具体化することができるものである必要があります。
 
(2)   セキュリティツールによって、適切に補強することができる必要があり、実質的に技術的な防御ができないときは、認可によって補強する必要があります。
 
(3)   ユーザ、管理者および経営管理者の責任の範囲を明確に定義する必要があります。

よいセキュリティ ポリシーのコンポーネントは、下記のものから構成されます。:

(1)   コンピュータ テクノロジー調達ガイドライン これは、要求される、あるいは、よりふさわしいセキュリティの機能の条件を明らかにするものです。これらは 、既存の購買ポリシーとガイドラインを補完するものである必要があります。
 
(2)   プライバシーポリシー これは、下記のような論点についてのプライバシーのあり方を定義するものです。
  • 電子メールのモニタリング(監視)
  • キー ストロークのロギング(履歴)
  • ユーザのファイルへのアクセスのロギング(履歴)
(3)   アクセスポリシー これは、資産の消失や開示から守るために、ユーザ、運用スタッフおよび経営管理者のための許される使用法についてのガイドラインを作ることによって 、アクセス権限と特権を定義するものです。これは、下記の項目のガイドラインとなっていなければなりません。
  • 外部接続
  • データ コミュニケーション
  • ネットワークに接続するデバイス
  • システムへの新しいソフトウエアの追加搭載

これは、また、すべての要求される通知メッセージについて記述される必要があります。(例: 接続時のメッセージは、承認された使用法とラインモニタリングについての警告をするものである必要があり、単に"Welcome"といったものであってはなりません。
 

(4)   説明責任ポリシー これは、ユーザ、運用スタッフおよび経営管理者の責任を定義するものです。これは、監査する主体を特定するとともに、インシデントに対応するガイドラインを提供するものである必要があります。(つまり、何かそのようなことが検出されたときにはどうしたらよいかということです。)
 
(5)   認証ポリシー これは、信頼を築くもので、有効なパスワードポリシーとリモートからの認証と認証デバイスの使用ガイドラインを設けることによってなされます。 (例: ワンタイムパスワードと、それを生成するデバイス)
 
(6)   可用性表明 これは、ユーザに資源の可用性についての計画を示すものです。これは、運用時間と保守のためのダウンしている期間を明らかにするとともに、代理機能と復旧の論点にも言及している必要があります。それには、システムとネットワークの障害を報告する連絡先情報も含まれている必要があります。
 
(7)   情報システムとネットワークの保守ポリシー これは、テクノロジーをどのように扱ったり、アクセスすることが、内部・外部 の両方のメンテナンス(保守)担当者に認められているか、を記述するものです。ここで示されなければならない重要な論点は、 「リモート メンテナンスがみとめられているか」ということと、「そのようなアクセスが、どのようにコントロールされるか」ということです。他にに、ここで検討すべき領域は、アウトソーシングと、いかにそれが管理されるかということです。
 
(8)   違反の報告のポリシー これは、
  • どのようなタイプの違反が報告されなければならないか (例: プライバシーとセキュリティ、内部と外部)

ということと、

  • 誰に報告されなければならないか

を示すものです。脅かすのではない雰囲気で、匿名での報告を許可することによって、発見された際には、より多くの報告が寄せられるようになるでしょう。
 

(9)   サポート情報 これは、ユーザ、スタッフおよび経営管理者に、それらのタイプのポリシー違反の連絡先情報を知らせるものです。; また、外部へのセキュリティのインシデントについての質問についての扱い方や、機密情報や知的財産権のある情報についてのガイドラインも示します。; さらに、セキュリティの手順や企業(独自)のポリシーや国の法律や規制等の関連情報の参照を示します。

あなたのセキュリティポリシーに影響を与える制限事項もあります。(例: ラインモニタリング) セキュリティポリシーの作成者は、そのポリシーの作成においては、法的な助言を求めることも考慮すべきです。少なくとも、そのポリシーは、法律顧問によってレビューされる必要があります。

あなたのセキュリティポリシーが完成したら、それについて、ユーザ、スタッフおよび管理者との間で意見交換される必要があります。すべての関係者から表明文書にサイン(署名)をもらうことは、それを読み、理解し、そのポリシーに同意するということであり、一連の過程の中でも重要なところです。最後に、あなたのポリシーは、あなたのセキュリティについてのニーズをうまくサポートしているかを確認するために 、通常の条件でレビューされる必要があります。

 

2.3 ポリシーの柔軟性の確保  English

セキュリティポリシーが、長期間にわたって柔軟性を持ち続けるようにするためには、骨格をなすセキュリティコンセプトに基づいて、十分に柔軟である必要があります。セキュリティポリシーは、(大部分は)詳細なハードウエアやソフトウエアの環境 からは切り離されているべきです。(それは、特定のシステムとなると、すぐに更新されたり変更されたりするからです。)このポリシーを更新する方式は、明確に文書化される必要があります。これには、手順、参画する人およびその変更について署名すべき人が含まれます。

また、すべてのルールには例外があることを認識しておくことも重要です。可能である限り、ポリシーにはどのような一般原則の例外があるのかまで記載される必要があります。例えば、どのような状況下で(システム)管理者がユーザのファイルを調べることができるか等があげられます。また、複数のユーザが同じユーザID を共有する場合もあるでしょう。例えば、ルートユーザが存在するシステムにおいて、複数のシステム管理者が、ルートのパスワードを知っていて、そのアカウントを使用するようになっていることでしょう。

また、「ごみ探索シンドローム(Garbage Truck Syndrome)」と呼ばれる状況もあります。これは、サイトの重要人物が、その仕事をできない場合に何が起きるかということを表現しています。(例えば、急病である場合や予期せず退社してしまった場合です。)最高のセキュリティとは、結局、最小限の情報の流布ということですが、反面、機密情報を喪失するリスクは、情報が共有されていないときに高いのです。あなたのサイトにとって妥当なバランスを決定することが重要です。


->3