1.  物理セキュリティ

どれほど数多くの保護を実装しても、攻撃者がコンピュータに物理アクセスすることで、 それらすべてが簡単に回避されるかもしれません。 しかしながら、機器に物理アクセスする攻撃者に対するセキュリティを決めるために、 取りうる対策が一応は存在します。 機器を鍵のかかる棚にしまうことで、攻撃者がケーブルを抜き、持ち去るのを防いでください。 攻撃者がハードディスクを絶対持ち逃げできないように、 コンピュータのケースに鍵をかけるのも良いアイデアです。 うまく権限とログイン制限を回避して、別ディスクからのブートができないように、 BIOS上でハードディスクをファーストブートディスクにし、 BIOSパスワードを設定するようにしてください。 悪意あるユーザがシングルユーザモードでブートして、システムに対する完全なアクセスを 取得できないように、LILOやGRUBのブートパスワードを設定することも重要です。 これについては3章の (GRUBパスワードの設定) や (LILO パスワードの設定) で詳細に触れます。

1.  デーモン/サービス設計

マシンで稼働させるべきサービスにどういったものがあるのか文書化から始めてください。 これによりシステムに対してより良いパーティション構成ができ、 より適切なセキュリティ対策を計画できます。 もちろん、もしデスクトップやファイアーウォール専用のような単一で単純な目的のサーバであれば、 これは不要です。 こうした場合は、おそらくsshdを除いて、あらゆるサービスを稼働させないのが賢明です。

また、このリストでシステム管理者が楽になることもあります。 現時点でのバージョン情報を管理することで、 それぞれのデーモンで脆弱性が発見されても、 最新に保つことが非常に簡単なことが分かるでしょう。

1.  パーティションの構成

パーティションのルール:

• ユーザが書き込めるディレクトリツリー(例 /home, /tmp) はすべて別なパーティションに置き、ディスク使用制限をかけなければいけません。 これは一人のユーザが全ファイルシステムを使いきってしまうリスクを減らすためです。 portage は/var/tmpをコンパイルの目的で使うので、 このパーティションは大きくしておく必要があります。
• ディストリビューションで配布される以外のソフトウェアをインストールしようとするディレクトリツリーはすべて、 別のパーティション上にあるべきです。 File Hierarchy Standardによれば、 このパーティションは/opt または /usr/localです。 もし、これらが別パーティションであれば、システムの再インストールをしなければいけなくなっても、 これらのソフトウェアは削除されることはありません。
• 特別なセキュリティのためには、静的なデータを読み込み専用の別パーティションに置くこともできます。 極端ないい方をすれば、CD-ROMのような読み込み専用のメディアを使ってみてください。

1.  rootユーザ

rootユーザはシステム上もっとも重要なユーザであり、必要なとき以外は絶対に使用してはいけません。 もし攻撃者にroot権限を奪取された場合、システムの信用を回復するには再インストールしかありません。

rootに関する大原則

• 普段使用するユーザを作成し、もしこのユーザにroot権限が必要であれば、 このユーザをwheelグループに追加してください。これにより、一般ユーザが rootにsuできるようなります。
• Xや他のユーザアプリケーションをrootで動かさないでください。 rootは確実に必要なときにだけ使うべきです。 もし一般ユーザで動かしているアプリケーションに脆弱性があった場合、 攻撃者はユーザレベルでのアクセス権を奪取できます。 ところが、もしアプリケーションがrootで動いている場合には、 攻撃者にrootでのアクセス権を奪取されてしまいます。
• rootとしてログインしているときは常に絶対パスを使用してください (または、rootのPATHだけに/binや/sbinのような、 保護されたディレクトリがあると考えられる場合には、常にsu -を使って、 ユーザの環境をrootのものに置き換えてください)。 rootをだまして意図しないアプリケーションを起動させることがありえます。 もしrootのPATHが保護されていたり、rootが絶対パスしか使わなければ、 このような事は起こらないでしょう。
• もし、ユーザがrootでいくつかのコマンドを実行する必要があるだけなら、 通常rootはあらゆる事が可能なので、その代わりにsudoを考慮してください。 ただし、このアクセスを誰にあたえるかにも注意してください。
• rootとしてログインしているときは決して、画面から離れないでください。

Gentooでは一般ユーザがrootへsuするのを防ぐ手段がいくつかデフォルトでとられています。 デフォルトのPAM設定ではsuするためには"wheel"グループに所属する必要があります。

1.  セキュリティポリシー

システムやネットワークにたいしてセキュリティポリシーを作成する根拠がいくつかあります。

• よいセキュリティポリシーによって、単に異なる項目の寄せ集めではなく、 「システム」としてセキュリティの概要をまとめることができます。 たとえば、ポリシーがない状態では、 管理者はパスワードが平文で送られるため、telnetを停止させるかもしれません。 しかし、同じ脆弱性がある FTPはそのままにしてしまいます。 よいセキュリティポリシーのおかげで、セキュリティ対策が価値のあるものかどうかが確認できます。
• 問題判別や、監査の実施、侵入者の追跡などを行うため ネットワークトラフィックを遮断し、 ログイン記録とユーザのコマンドヒストリを点検し、 ユーザのホームディレクトリの中を見てみる必要があるかもしれません。 こうした点を書面でまとめなかったり、ユーザに周知せずにおいた場合、 これらの行動をいざとったとき法に違反することにもなりかねず、 あなたを法的な窮地に追い込むことになるかもしれません。
• ユーザアカウントの乗っ取りは、システムセキュリティに共通する最大級の脅威です。 セキュリティの重要性をユーザに説明しないままだったり、 (パスワードをポストイットに書いて机の上に貼らないなどの)どのように良 いセキュリティを習慣付けるか説明しないままでは、 安全なユーザアカウントなど望むべくもないでしょう。
• 侵入を追跡したりその後の弱点を確認する際に、 必要となれば、当局の調査官と同じくらい、 ドキュメントが十分にあるネットワークやシステムレイアウトが助けになります。 システムがプライベートネットワークにあり、許可されないアクセスが全て禁止されている、 という趣旨のセキュリティポリシー発行バナーは、 侵入者がいったん捕まった場合、起訴可能であることを示すのに役立ちます。

よいセキュリティポリシーの必要性がより明確になったでしょうか。

ポリシー自身はひとつのドキュメントもしくは複数のドキュメントであり、 ネットワークとシステムの機能(どんなサービスが提供されているか)、 利用規則、禁止項目、そして セキュリティの「ベストプラクティス」などをまとめたものです。 ユーザ全員はポリシーを知っていなければいけませんし、 最新に保つための変更点についても同様です。 ユーザにポリシーの理解を促すことと何故ポリシーに署名が必要なのか、 または直接ポリシーに反する行動をした場合にどうなるのか、 (これはポリシーに記載しておくべきです)という点について時間をかけることが重要です。 こうしたことは最低でも年に1度は繰り返し行われなければいけません、 なぜならば、ポリシーは書き換わることがありうるからです (もちろんユーザへポリシーそのものを思い出せるということもあります)。

セキュリティポリシーは最低でも次の項目を含むべきです。

• 利用規定
  • スクリーンセーバー
  • パスワード規定
  • ソフトウェアのダウンロードとインストールについて
  • ユーザが監視されている場合の情報提示
  • アンチウイルスソフトの使いかたについて
• 重要情報の取り扱い(すべての書類、電子情報)
  • 机の整理整頓と機密情報保管
  • 出かける前のPCのシャットダウン
  • 暗号の使用
  • 信用できる同僚との鍵取り扱い
  • 移動時の機密資料取り扱い
• 移動時のコンピュータ装置の取り扱い
  • 移動時とホテル滞在時のラップトップコンピュータの取り扱い

異なるユーザが異なるレベルやアクセスタイプを要求するかもしれません、 そしてポリシー自体はそれらをすべてに対応するため変更される可能性があります。

セキュリティポリシーというのは量が増えがちであり、重要な情報は忘れ去られがちです。 ITスタッフのポリシーは普通のユーザにとっては機密になる情報を含むことがあり、 区別して量を減らしたポリシーにするのが賢いやり方です。 たとえば、利用規程、パスワードポリシー、電子メールのポリシー、 リモートアクセスポリシーなどです。

ポリシーの例としては The SANS Security Policy Projectがあります。 もし、小規模のネットワークと上のポリシーが過剰と思う場合には Site Security Handbook (訳注:IPAによるRFC日本語訳)をみてください。