3<- index ->5


4. セキュリティサービスと手順 English

本章において、読者に、サイトをセキュアにするために必要な数多くの論点を紹介します。各節において、サイトにおいて情報とシステムを守るために要求されるセキュリティサービスや、その能力をも つ機能を説明します。それらの論点は、読者にそのコンセプトを紹介するのに、かなりレベルの高い内容となっています。

この章には、かなり多くの暗号についての記述があります。暗号についての詳細を紹介することは、本書の範疇外ですが、興味のある読者は、本書の「参考文献 」の章に掲げられている書籍や文献から、より多くの情報を得ることができます。

 

4.1 認(Authentication) English

何年もの間、ユーザを認証する手段として、標準的で手軽なパスワードが使用されてきました。もともと、このようなパスワードは、大型汎用機の端末においてユーザが自身を認証するために使われていました。当時は、(外部にも内部にも)ネットワークが無かったので、平文のパスワードが開示されるリスクは、高くありませんでした。現在、システムは、LAN に接続されており、さらに、このような LAN は、インターネットに接続されています。ユーザは、世界中からログインできるのです。; ユーザが使用可能なパスワードは、しばしば、そのような同一ネットワーク上において平文のまま、いつ誰に途中で捕捉されてもおかしくない状態で送信されています。そしてまさに、CERT/CC や他のインシデント対応チームは、平文パスワードを捕捉するパケット盗聴プログラムに関するすさまじい数のインシデントに直面しています。

ワンタイムパスワード(例: S/Key)、PGP およびトークンに基づいた認証デバイスのような新しい技術の出現によって、人々は、パスワードに相当する文字列を、秘密のトークンや PIN として使用するようになっています。もし、そのような秘密のトークンや PIN が、正しく選択・保護されていないとき、その認証は、簡単に破られてしまいます。

4.1.1 ワンタイムパスワード(OTP) English

既に述べたように、現在のネットワーク環境において、システムとネットワークのセキュリティとインテグリティ(完全性)に関心のあるサイトには、標準的で手軽なパスワードではない方法 への移行を検討することを薦めます。ネットワークにおけるトロイの木馬プログラム(例 : telnet や rlogin)と、ネットワークパケット盗聴プログラムに関連した多くのインシデントが発生しています。このようなプログラムは、平文、ホスト名 /アカウントおよび名前/パスワードの 3つを捕捉します。侵入者は、捕捉した情報を、それらのホストやアカウントに後でアクセスするために使用することができます。これは、下記の理由で可能となるのです。

1) パスワードは、操り返し使用されます。(それゆえ「再利用可能」なのです。)
2) パスワードは、ネットワーク上を平文で送られます。

この問題に対応するために、いくつかの認証技術が開発されています。このような技術のひとつとして、チャレンジレスポンス技術があり、これは 1回だけ使用できるパスワードを提供するものです。(通常「ワンタイムパスワード(OTP)」と呼ばれています。)サイトが使用を検討すべき数多くの入手可能な製品があります。その製品を使用する決定は、各組織体の責任においてなされることであり、各組織体は、独自に試用 ・選択すべきです。

4.1.2 Kerberos English

Kerberos は、分散ネットワークセキュリティシステムであり、セキュアでないネットワークに認証機能を提供します。アプリケーションの要求に従って、インテグリティと暗号化の機能も提供することができます。もともと、Kerberos は、MIT( Massachusetts Institute of Technology)において、1980 年代中頃に開発されました。Kerberos には、バージョン 4 と 5 の 2つの主だったリリースがあり、実用においてはこれらの間に互換性はありません。

Kerberos は、Kerberos サーバーとして知られる「鍵配布センター(KDC)」を使用する対称鍵データベースを採用しています。(「プリンシパル」と呼ばれる)ユーザもしくはサービスには、KDC との連絡の後に電子的な「チケット」が渡されます。これらのチケットは、プリンシパル間の認証に使用されます。すべてのチケットにはタイムスタンプがあり、そのチケットの有効期間を制限します。それゆえ、Kerberos クライアントとサーバーは、安全な時間の情報源をもつ必要があり、正確な時間を維持する必要があります。

Kerberos の典型的な側面は、アプリケーションレベルにおける統合です。典型的なアプリケーションとして、FTP、telnet、POP、NFS などが Kerberos システムと統合されています。様々なレベルで実装する、様々な実装形態があります。最新情報は、下記の URL で、Kerberos FAQ をご覧ください。
http://www.ov.com/misc/krb-faq.html (現在、リンク切れ。)

4.1.3 秘密のトークンと PIN の選択と保護 English

秘密のトークン選択するときには、それらを慎重に選ぶようにして下さい。パスワードの選択と同様、それらを推測しようと企む者に対して、強いものである必要があります。つまり、それらはいかなる国語のひとつの単語であっても、いかなる業界用語、隠語などであってはいけません。理想的には、それらは、短いよりも長い方が望ましく、前部と後部に、文字とデジットと他の文字を組み合わせたパスフレーズから成るものが望まれます。

秘密のトークンが選択されたら、これらの保護が非常に重要です。(トークンカードのように、)ハードウエアデバイスへの PIN として使用されるものもあり、これらは、関連付けられているデバイスと同じ場所に書かれたり、置かれたりしてはなりません。他には、PGP( Pretty Good Privacy )の秘密鍵のようなものも、不正アクセスから保護される必要があります。

この論点について最後にひとつ述べておきます。PGP のような暗号製品を使用するときには、鍵の長さの決定に注意し、あなたのサイトのユーザがそのようにする訓練を受けているかを確認してください。技術が進むにつれて、安全上要求される、最低限の鍵の長さは伸び続けています。あなたのサイトが、使用されているすべての暗号があなたの期待通りに保護機能を提供しているかを確認できるように、この技術についての最新の知識についていけているかを確認してください。

4.1.4 パスワード保証 English

標準的で手軽なパスワードの使用をやめる必要性については強調しすぎることはないのですが、組織体によってはそれらを使用し続けるところもあるでしょう。こうした組織体は、より良い技術の使用に移行することが推奨されるのですが、暫定的に、我々は伝統的なパスワードの選択と保守を助けるのために、 次のアドバイスをします。ただし、これらの手段も盗聴プログラムによる開示に対しては有効な保護ではないことを覚えておいてください。

(1)   強いパスワードの重要性 -
(すべてではないにしろ)システムの突破の多くの場合、侵入者は、システム上のアカウントへのアクセスを得る必要があります。 その目的を達する典型的なやり方は、正規のユーザのパスワードを推測することによるものです。これはしばしば、システムのパスワードファイルに対して非常に大きな辞書を 使用する、自動化されたパスワード解析プログラムを実行することによって行われます。パスワードがこのようなやり方であばかれるのを防ぐ唯一の方法は、慎重に、容易には推測されないパスワードを選択することです。(つまり 、字数、綴り、厳守すべき文字の組み合わせです。)パスワードはまた、システムがサポートしていて、ユーザが扱える範囲で、できるだけ長くすべきです。
 
(2)   デフォルトパスワードの変更 -
多くのオペレーティング システムとアプリケーション プログラムは、デフォルトのアカウントとパスワードをもつようにインストールされます。これらは直ちに、推測されたりクラックされないものに変更しなければなりません。
 
(3)   パスワードファイルへのアクセス制限 -
サイトは特に、潜在的な侵入者がそれらをクラッキングのために手に入れないようにするために、ファイルの暗号化されたパスワードの部分を守ろう とすることでしょう。効果的なテクニックのひとつとして、シャドウ パスワードの利用があげられれます。これは、標準ファイルのパスワードのフィールドが、ダミーもしくは偽のパスワードをもつ、というものです。正規のパスワードを納めたファイルは、システム上の別の場所に保護せれます。
 
(4)   パスワードエイジング(計画的陳腐化) -
いつ、どのようにパスワードを発行するかは、セキュリティコミュニティにおいて今でも論争のある論点です。アカウントが使用されなくなったら、パスワードは保持されてはならないことは 一般に受け入れられていまが、ユーザが現在使用中のよいパスワードを変更することについては白熱した議論がなされています。パスワード変更の主張は、破られたアカウントの使用継続の防止との関連があります。しかし反対論は、定期的なパスワード変更によって、ユーザはパスワードを見えるところに書くようになってしまったり、(例えば端末に貼り付けること。) 推測が容易な非常に単純なパスワードを選ぶようになってしまう、と主張します。侵入者は、捕捉もしくは推測されたパスワードを後ではなくすぐに使用する可能性が高いことも述べておく必要があります。この場合、パスワードエイジングは 、ほとんど保護策になりません。

このジレンマに対する決定的な回答はありませんが、パスワードポリシーは、この論点に直接的に対応し、どれ位の頻度でユーザがパスワードを変更しなければならないかについてのガイドラインを提供すべきです。確かにパスワードの定期的な変更は 、通常、大部分のユーザにとっては さほど困難ではありませんので、あなたはその導入を検討すべきです。パスワードは、少なくとも、特権アウントが変更されたとき、 個人において重要な変更がなされたとき(特に、これが管理者の場合には!) アカウントが変更されたときには変更されることが推奨されています。さらに、もし特権アカウントのパスワードが変更されたときには、システム上のすべてのパスワードが変更される必要があります。
 

(5)   パスワード/アカウントのブロッキング -
事前に定義された認証の失敗の回数の後に、アカウントを使用不能にすることの有用性を見出しているサイトがあります。 もし、あなたのサイトでこのメカニズムを採用するのでしたら、このメカニズムを「宣伝」しないことを薦めます。使用不能にした後に、たとえ正しいパスワードが入力されても、表示されるメッセージは、失敗したログインのときのままにしておかなければなりません。このメカニズムを実装することによって、正規のユーザが、彼らのアカウントが再度使用できるようにシステム管理者に要求するようにすることが必要になります。
 
(6)   finger デーモンについて -
デフォルトで、finger デーモンは、システムとユーザについての かなりの情報を表示します。例えば、これはすべてのユーザの現在使用中のシステムのリストや、 特定のユーザの .plan ファイルのすべての内容を表示することができます。この情報は侵入者によって、ユーザ名を特定し、彼らのパスワードを推測するのに利用される可能性があります。 サイトでは、finger を、表示される情報を制限するようにすることを 検討するよう、お薦めいたします。

 

4.2 守秘性 English

あなたのサイトが、認可されていない主体に開示されることを防ごうとする情報資産があります。オペレーティングシステムには、管理者がシステム上の誰がアクセスできて、ファイルの中身を「見る」ことができるか、をコントロールすることができるようにする組み込みのファイル保護メカニズムがあることがあります。守秘性確保のためのより強力なやり方として、暗号によるものがあります。暗号は、データをスクランブルすることによって行われ、その結果、認可されたユーザもしくはオーナー以外の者がその平文を手にする ことは、非常に困難で、時間がかかります。その情報の認可されたユーザとそのオーナーは、そのテキストを読める (クリア テキスト)形式に容易に復号できる復号鍵を持っています。我々は、各サイトに、守秘性を確保し、価値ある情報を守るために、暗号を使用することを薦めます。

暗号の使用は、政府とサイトの規制によってコントロールされていることがあるので、我々は管理者に、それらを採用する前に、その使用そ制限している法 もしくは政策について勉強することを強くお薦めいたします。 この目的で入手可能な様々なアルゴリズムやプログラムについて検討することは、この文書の範疇外ですが、UNIX の暗号プログラムは簡単に破られることが 分かっているので、我々は、その安易な使用に対して警告いたします。我々は、みなさんに、すべてのアルゴリズム/製品を使用する前に、その暗号の強度を理解する時間をとることも強くお薦めします。大部分のよく知られた製品は、よく文書化されているので、これはさほど大変な作業ではありません。

 

4.3 インテグリティ(完全性) English

管理者として、あなたは、(例えば、オペレーティングシステムファイル、企業情報等の)情報が不正に改変されていないことを確認しようとすることでしょう。つまり、あなたのシステム上の情報の インテグリティ(完全性)についての、ある種の保証を望むことでしょう。これを実現する方法のひとつとして、変更されていないファイルのチェックサムをとって、そのチェックサムをオフラインで蓄積し、定期的に(もしくは必用に応じて) オンラインファイルのチェックサムが変更されていないことをチェックする方法があります。(これは、データが改変されていないことを示します。)

オペレーティングシステムには、チェックサムをとるプログラムが付属しているものがあります。例えば、UNIX の sum プログラムです。しかし、これらではあなたが望む保護機能は得られないでしょう。ファイルが UNIX の sum プログラムのと同様な結果を得るように改変されることがありうるのです!それゆえ我々は、あなたがインテグリティの保証のためにチェックサムをとるために使うのには、メッセージダイジェスティングプログラム MD5 [ref] のように暗号的に強いプログラムを使用することを提案します。

例えば、電子メールのメッセージを 2者間においてやり取りするときのように、インテグリティ(完全性)の保証が要求される他のアプリケーションもあります。この能力をもった製品は、入手可能です。あなたが、これを望んでいたと判断したら、それが提供する識別技術を試してください。

 

4.4 認可(Authorization) English

認可とは、システムのプロセス、ひいてはユーザに権限を与えることをいいます。これは、ユーザを識別するのに用いられる認証という用語とは異なります。認証されると(信頼性をもって)ユーザの

が認可によって決定されます。

すべての資源(オブジェクト)について、各ユーザの認可された行為 (とユーザプロセス)を明確にリストすることは、通常のシステムでは不可能です。現実のシステムでは、そのような技術は、認定を許可、チェックする過程を 単純化して使用されています。

UNIX システムで普及しているひとつのアプローチは、個々のオブジェクトに下記の 3つのユーザのクラスを割り当てるやり方です。:

オーナーとは、そのオブジェクトの作者と、スーパーユーザによってオーナーとされたユーザの両方です。オーナーのパーミッション(read、write、execute)は、オーナーにだけ適用されます。グループとは、オブジェクトへのアクセス権限を共有するユーザの集まりです。グループのパーミッション(read、write、execute)は、 そのグループ内の(オーナー以外の)すべてのユーザに適用されます。ワールドとは、そのシステムへのアクセスができるその他すべての人のことをいいます。ワールドのパーミッション(read、write、execute)は、 (そのオーナーとそのグループのメンバー以外の)すべてのユーザに適用されます。

もうひとつのアプローチは、オブジェクトごとに、すべての許可されたユーザ (もしくはグループ)の識別をもったリストを添付する方法です。これがアクセスコントロールリスト(ACL)です。ACL の長所は、(オブジェクトひとつに対して集中管理するリストによって、) それらは容易に維持管理できることと、誰が何にアクセスできるかを視覚的にチェックすることが容易であることです。欠点は、そのようなリストを蓄積するのに追加的な資源が要求され、大規模システムには、膨大な数のそのようなリストが要求されることです。

 

4.5 アクセス English

4.5.1 物理的アクセス English

ホストへの物理的アクセスを、そのホストを使用することが想定されている人々にのみアクセスを許すように制限してください。ホストには、

が含まれます。 人々の職場環境がアクセス制限とうまく整合していることをご確認ください。; さもなくば、彼らはあなたの物理的セキュリティを回避する方法を見つけてしまいます。(例 閉じたドアを開けてしまう。)

オリジナルとバックアップのデータのコピーとプログラムを安全に保管してください。それらをバックアップ目的で良い保管状態に保つこととは別に、それらは盗難から守られている必要があります。ダメージ(破壊)についての考慮ばかりでなく、盗難防止のためにも、 バックアップを、オリジナルとは別の場所に保存することが重要です。

(ノート PC などの)ポータブルホストには、特にリスクがあります。たとえあなたのスタッフの PC が盗難にあっても、問題が起きないようになっているかをご確認ください。PC 上でどのようにデータが保護されるべきか (例 : 暗号化)とともに、PC のディスク上に 保存することが許されるべきこの種のデータのためのガイドラインを作成することをご検討ください。

物理的アクセスが制限されるべき他の問題領域として、部屋に、ファイルサーバー、ネームサーバー、ホスト機、ルーターのような重要なネットワークの要素を固定することがあります。

4.5.2 ウォークアップネットワーク接続 English

我々は、「ウォークアップ」接続という用語を、ユーザにポータブルホストをネットワークに接続する便利な方法を提供するために配置されたネットワーク接続ポイントの意味で使います。

これは、すべてのユーザに承認されていないホストをあなたのネットワークに接続することを許すことになることを念頭において、このサービスを提供することが必要かどうかをご検討ください。これは IPスプーフィング、パケット盗聴などのようなテクニックによる攻撃のリスク を増大させます。ユーザとサイトの経営管理者は、関連のリスクを評価する必要があります。もし、ウォークアップ接続を提供すると決定する場合には、サービスを 慎重に計画し、あなたが必要な物理的アクセスセキュリティを確認できるように物理的にどこでそれを提供するかを決定してください。

ウォークアップホストは、そのユーザがあなたのネットワーク上の資源にアクセスすることを許可される前に、認証される必要があります。代替策として、物理的アクセスをコントロールすることは可能でしょう。例えば、このサービスが学生によって使用される場合、あなたはウォークアップ接続のソケットを学生のラボ(研究室)内でのみ 提供することになります。

あなたが、あなたの環境内で、ビジター(訪問者)がホームネットワークに 接続できるようにウォークアップアクセスを提供するとき、(例: 電子メールを読むため等)内部ネットワークとは接続されていない 独立のサブネットの使用をご検討ください。

空室のオフィスのような、監視されていないネットワークへのアクセスがあるところすべてに目を配ってください。配線室でそのような領域を切断するのが見識であり、セキュアハブの使用と、承認されていないホストを接続する試みを監視することをご検討ください。

4.5.3 他のネットワーク技術 English

ここで検討する技術には、X.25、ISDN、SMDS、DDS、フレームリレーが含まれます。これらすべては、電話交換を通す物理的リンク経由で提供され、これらが横道にそらされる可能性も提供します。 クラッカーは、データ ネットワークと同様に、電話スイッチにも興味があるのは確かです!

スイッチ技術については、可能な限り、常設のバーチャル回線 (Permanent Virtual Circuit)もしくは閉じたユーザ グループをご使用ください。認証と暗号化(例: IPv6)を提供する技術は、急速に進歩しています。; セキュリティが重要なところではリンクの際に、これらの使用を検討してください。

4.5.4 モデム English

4.5.4.1 モデム回線の管理の必要性 English

モデムは便利なアクセスをサイトのユーザに提供しますが、同時に、これらはサイトのファイアウォールの効果的な迂回路を提供しかねません。この理由で、正しいモデムのコントロールを維持することが重要です。

正規の承認なしに、ユーザにモデム回線につなぐことを許してはいけません。これには、臨時の接続も含まれます。 (例: 一晩だけモデムを FAX もしくは電話回線のプラグに挿す。)

すべてのあなたのモデム回線のレジスターの保守を行い、あなたのレジスターを最新に保つようにしてください。定期的に(理想的には自動的に)サイトに承認されていないモデムがないかをチェックしてください。

4.5.4.2 ダイアルインユーザが認証される必要性 English

あなたのネットワーク上の何かにユーザがアクセスできる前に、ユーザ名とパスワードのチェックがなされる必要があります。通常のパスワードセキュリティの考慮事項が特に重要です。
4.1.1 をご覧ください。)

電話回線は盗聴される可能性があり、携帯電話へのメッセージを横取りすることは極めて容易であることを銘記してください。最近の高速モデムは、より洗練されたモジュレーションテクニックを使用しており、いくぶん監視することを難しくしていますが、ハッカーがあなたの回線上で盗聴する方法を知っているとみなすのが慎重であるといえます。この理由により、可能であればワンタイムパスワードを使用すべきです。

すべてのユーザが同様に認証されるように、ひとつだけのダイアルインポイントを設けることが有益です。 (例: ひとつの大きなモデムプール)

ユーザは、たまにパスワードを誤って入力することがあります。初回と 2度めの失敗ログインの後に、短時間の遅れ(例えば 2秒)を設定し、3度めの後に切断するようにしてください。これによって、自動化されたパスワード攻撃を遅くすることができます。ユーザ名、パスワード、もしくはその両方が誤っていることを、ユーザに知らせてはいけません。

4.5.4.3 コールバック機能 English

ダイアルインサーバーには、コールバック機能を提供するものがあります。 (つまり、ユーザがダイアルインして認証されると、そのシステムはそのコールを切断し、特定の番号でコールバックします。) コールバックは有用です。それは、もし誰かがユーザ名とパスワードを推測しようとすると、接続は切断され、そのシステムはパスワードがクラックされた本来のユーザにコールバックします。; サーバーからのランダムなコールは疑うべきです。これは、ユーザは、ひとつの場所(サーバーがコールバックするように 設定されている場所)からのみログインすることができ、 当然、コールバック場所に電話料金が課されることを意味します。

この機能は注意して使う必要があります。; これは簡単にバイパスされる可能性があるのです。最低限、折り返しのコールは必ずしも(最初に)かかってきたモデムと同じものによるとは限らないないことを認識してください。結局、コールバックはモデムのセキュリティを改善することができますが、これだけに頼るべきではありません。

4.5.4.4 すべてのログインのログを採る English

すべてのログインは、成功であろうと失敗であろうとログを採る必要があります。しかし、ログの中に正しいパスワードを残してはいけません。 単に成功したログインとして、それらのログを採ってください。大部分の誤ったパスワードは、承認されたユーザによるミスタイプなので、それらは本来のパスワードとは 1文字違うだけなのです。それゆえ、もしあなたがそのようなログを安全に保持できないのならば、ログを採ってはいけません。

もし、Calling Line Identification(コールしている回線の識別)が、入手可能であれば、各ログインの回線番号を記録してその利点を活用しましょう。Calling Line Identification によって発生するプライバシーの論点に 注意をはらってください。 Calling Line Identification は信頼できるものではないことも ご認識ください。 (それは、侵入者は、電話スイッチへの侵入方法を知っており、電話番号を転送したり、他の変更を行うからです。); 情報としての目的にのみそのデータを使用し、認証のために 使用してはいけません。

4.5.4.5 開始のバナーを慎重に選択する English

多くのサイトでは開始のバナーに、dayファイルにあるメッセージをシステムのデフォルト設定に使用しています。残念ながら、これにはホスト ハードウエアのタイプ、もしくは ホスト上にあるオペレーティング システムが含まれていることがよくあります。これが潜在的な侵入者に価値ある情報を提供してしまう可能性があります。各サイトは、必要な情報だけをもつように注意して、自らの専用のログインバナーを作成すべきです。

短いバナーを表示するようにしてください。ただし、「気をそそる」名前を表示してはいけません。 (例: XYZ大学です。学生記録システムです。) そうではなく、あなたのサイト名、セッションが監視されているという短い警告、ユーザ名/パスワードプロンプトを表示しましょう。バナーに盛り込む文章に関連して起きうる法的な論点を検証してください。

高度なセキュリティの応用として、「ブラインド(blind)」パスワードの使用を検討してください。(つまり、ユーザがパスワードを打ち込むまでは、かけられたコールに反応しないものです。) これは機能していないモデムのふりをするのに有効です。

4.5.4.6 ダイアルアウト認証 English

ダイアルアウトユーザも認証される必要があります。その主な理由は、あなたのサイトが彼らの電話料金を支払わなければならないからです。

認証されていないダイアルインコールからのダイアルアウトを許可してはいけません。また、認証されたものからのコールを許可するかどうかもご検討ください。ここでの目的は、コールの主があなたのモデムプールをログインの連鎖の一部として、使用することを防ぐことにあります。特にハッカーが、あなたのサイトにある複数のホストを通る経路を設けている場合、検知するのが困難です。

最低限、同一のモデムと電話の回線を、ダイアルインとダイアルアウトの両方に使用することを許してはいけません。 これは、独立したダイアルインとダイアルアウトのモデムプールを運用すれば、容易に実装することができます。

4.5.4.7 あなたのモデムのプログラミングをできる限り「防弾」にする English

モデムは、使用中にはプログラム変更できないことを確認してください。最低限、3つのプラスサインがあなたのダイアルインモデムをコマンドモードにしないことをご確認ください!

あなたのモデムを、新しいコールが開始されるたびに、あなたの標準設定をリセット(再設定)するようにプログラムしてください。こうできないときには、コールの終了ごとにそれらをリセットしてください。この注意事項は、あなたを突発的なモデムのプログラム変更から守ってくれます。すべてのコールの終了時と開始時にリセットすることによって、新規のコールの主は前のコール主のセッションを引き継がないようにすることを、より高いレベルで確保することができます。

あなたのモデムが完全にコールを切断することをチェックしてください。ユーザがアクセスサーバーからログアウトするときに、そのサーバーが電話回線を正しくハングアップさせるかを検証してください。そのサーバーが、ユーザが予期せずハングアップしたときに、どこからのセッションが活動状態にあったか、ログアウトを監視することも同等に重要です。

 

4.6 監査  English

この項においては、ネットワークでの活動によって生成されるデータの収集の手続きを記述いたします。これは、ネットワークのセキュリティを分析すること、 および、セキュリティインシデントへの対応に有用です。

4.6.1 収集すべきもの English

監査データには、すべての人々、プロセス、もしくはネットワーク中の他の主体によって異なるセキュリティ レベルを達成しようとする、すべての試みが含まれる必要があります。これには、

が含まれます。特に、公開サーバーに対する「匿名(anonymous)」もしくは「ゲスト」アクセスに注意することが重要です。

実際に収集すべきデータは、サイトごと、サイト内でのアクセスの種類によって異なるでしょう。一般に、収集する情報には以下のものがあります。:

当然、そのシステムで入手可能なもの、その情報を保存するためにどれだけの領域が確保できるか、によって、これ以外にも集められるべき多くの情報があります。

非常に重要な注意事項:
パスワードを収集しはいけません。これは、仮に監査記録が不正にアクセスされたときには、甚大なセキュリティ問題を引き起こす可能性があります。誤ったパスワードも収集し てはいけません。その理由は、それらは正しいパスワードとたった 1文字違いということがよくあるからです。

4.6.2 収集のプロセス English

収集のプロセスは、ホスト、もしくはアクセスされる資源ごとに定められる必要があります。データの重要性と、例えばサービスが妨害されているときなどに身近にそれをもつ必要性に応じて、データは、それが必要とされるまでローカルに保存したり、もしくは、個々のイベントが起きた後で保存場所に転送することができます。

基本的に、監査記録を保存する方法には 3つあります。:

それぞれの方法には利点と欠点があります。

ファイルシステムでログを採ることは、3つの方法の中で最も資源が集中しており、最も設定するのが容易です。この方法では分析するために記録に手軽にアクセスすることができ、攻撃が進行中の場合、このことが重要となります。ファイルシステムでログを採ることはまた、最も手軽な方法でもあります。もしログを採るホストがいたずらされるときには、通常、そのファイルシステムがまっ先にいじられます。; 侵入者は、容易に侵入の痕跡を隠すことができます。

1度だけ書き込めるデバイス上に監査データを収集することは、単なるファイルの方法よりも設定に少し労力を要しますが、これには、大きくセキュリティを強化する明らかな利点があります。それは、侵入者が、侵入が起きたことを示すデータを改ざんすることができないからです。この方法の欠点は、保存メディアを用意し続ける必要性があることと、そのメディアの費用です。データもまた、手軽には見ることができません。

ラインプリンターにログをとることは、永続的なログと、緊急のログが必要とされるシステムでは有用です。リアルタイムシステムは、失敗や攻撃の瞬間が記録されるこの一例です。レーザープリンターもしくは、データを貯める他のデバイス(例 : プリントサーバー) は、バッファが重要な瞬間に必要なデータを含んでいるときには、データの消失に悩むことでしょう。「紙の記録」を書き出すことの欠点は、プリンターを維持管理する必要があることと、記録を手で検索する必要があることです。また、印刷される莫大な量の紙の保管場所の論点もあります。

上記のそれぞれのログをとる方法については、ログを生成するデバイスと、実際にログを採るデバイス(つまり、ファイルサーバー、テープ/CD-ROM ドライブ、プリンターのこと。)の間の経路の安全を確保する論点もあります。もし、その経路がいたずらされると、ログの採取が止まったり、成りすまされたり、 その両方が起きる可能性があります。理想的には、ログを採るデバイスは、1本の単純な、ポイント トゥ ポイントの ケーブルで、直接、接続されているのが望ましいといえます。それは通常、実践的でないので、その経路は、最小限のネットワークとルーターしか通らないようにすべきです。たとえログが妨害されても、 なりすましは、暗号的なチェックサムで防ぐことができます。(ログ自体を暗号化することはおそらく不要でしょう。なぜならば、基本的にそれらは秘密情報を含んでいてはいけないからです。)

4.6.3 収集データの保存方法 English

監査データの収集は、急速にバイト数を消費することになるので、この情報の保存可能性についてはあらかじめ検討される必要があります。必要とされる保存領域を減らす方法があることはあります。まず、多くの方法でデータを圧縮することができます。または、そのデータの概略だけを長期保存するアーカイブに保存して、データを短い時間ごとに保存することによって必要とされる領域を最小限にすることができます。後者の方法の主だった欠点は、インシデント対応と関連があります。しばしばインシデントは、サイトがそれを認知し、調査し始めるかなりの前から継続していることがあるのです。そのようなときには、詳細な監査ログを入手できるようにしておくことが非常に有益です。もしこれらが単なるサマリー( 要約)だったら、インシデントに対処する十分な詳細情報が得られないでしょう。

4.6.4 監査データの扱い方と保存 English

監査データは、サイトで最も慎重に保全されるデータとして扱われて、バックアップを採る必要があります。侵入者が監査ログへのアクセスを得ようとするとき、そのデータのみならず、システム自身もリスクにさらされることになります。

監査データは、また、調査、検知、インシデントに備えての準備の鍵となりえます。この理由で、どのように監査データが扱われるかを決定するときに、法律顧問の助言を求めることを助言します。これはインシデントが起きる前になされる必要があります。

もし、インシデント以前にデータの扱い方の計画が適切に定められていない場合、何かか起きたときに助ける方法がなく、データの正しくない扱い方に起因する悪い結果に陥ることになります。

4.6.5 法的な考慮事項 English

監査データの内容によっては、数多くの法的な疑問があります。これは、あなたの法律顧問に対応願う必要がある問題を提起します。もし、あなたが監査データを収集、保存するならば、その存在とその内容の両方による結果に備える必要があります。

第 1 の問題領域は、個人のプライバシーに関するものです。例えば、監査データには個人情報が含まれることでしょう。たとえシステムのセキュリティの定例のチェックにおいてさえも、データの検索は、プライバシーの侵害を招く恐れがあります。

第 2 の関心のある領域は、あなたのサイトを起源とする侵入行為の認識に関するものです。もし、組織体が監査データを保持しているとき、インシデントを探すためにそれを吟味する責任があるのでしょうか? もし、ある組織体のホストが、他の組織体へ攻撃の踏み台として使われた場合、2番目の組織体は、最初の組織体が見過ごしたことを立証するのに、その組織体の監査データを使用することができるのでしょうか?

上記の例を、わかりやすく話し、監査データに関連した法的な論点を考慮するように、あなたの組識体を促す必要があります。

 

4.7 バックアップ English

バックアップを作成する手続きは、コンピュータシステムの運用についての古典的な領域です。本書の文脈において、バックアップは、サイトのセキュリティの全体計画の一部として扱っており、バックアップには、この文脈において重要な観点がいくつかあります。:

(1)   あなたのサイトがバックアップを作成しているかを確認してください。
(2)   あなたのサイトがバックアップに、サイト以外のストレージ(保存)を使用しているかを確認してください。ストレージ(保存)サイトは、そのセキュリティとその可用性の両方の観点から慎重に選択される必要があります。
(3)   あなたのバックアップがサイト以外にあるのでしたら、さらなる情報の保護のために、それを暗号化することを検討してください。しかし、将来、いつでもデータを復元できるように、よい鍵管理スキームが必要となることを認識してください。また、将来、復号する必要があるときに必要な復号プログラムへのアクセスができることを確認してください。
(4)   あなたのバックアップは良くできているとは限りません。サイトがインシデントを認知するまでに長い時間がかかった、多くのコンピュータセキュリティのインシデントの例があります。このような場合、被害を受けたシステムのバックアップも侵されています。
(5)   定期的に、あなたのバックアップの正確性とインテグリティ(完全性)を検証してください。

->5