今回のコラムでは,システム管理者(UNIXのrootユーザーやWindows NT/2000のAdministrator)は,システムをセキュアに保つために,何を原則として守らねばならないかについて述べてみよう。

 一口に「システム管理者」といっても,そのスキルは千差万別である。そのため,「システムをセキュアに保て」と言われても,どこから手を付ければよいのかが分からない管理者は多いだろう。とりあえず,パブリック・ドメインのセキュリティ・ツールをインストールする管理者もいれば,セキュリティ・ホールが現れる可能性を小さくするために,システムを再設定する管理者もいる。また,ファイアウオールの内側に設置されたホストに対しては,何もする必要がないと考える管理者もいる。さらに,システム管理者にだれかを任命したものの,任命された本人は何から手をつければよいのかが分からず,任命者も何をどのように指示すればよいのかが分からないケースさえある。

 これらの対応は,いずれも「システムを脅威から防御する」という大前提に合致していないと言える。付け加えるならば,断片的であり,場当たり的である。戦略らしさが見当たらず,長期的な防衛に適していない。では,何を原則として,システム管理者は行動しなければならないだろうか。いまさら言われなくても,日々の作業からすでに体得している管理者も多いだろうが,その原則を以下に示していきたい。

原則1:内部犯行に注意する

 多くの攻撃者は,他の国や都市,あるいは他の組織に存在する,匿名で顔の見えない人物であると考えられている。インターネットには国境がない以上,この見方は一理ある。しかし,統計によれば,ほとんどのセキュリティ事件が内部犯行によるものである,という見解もある。もしこの見解が正しい場合,どのような犯行が考えられるだろうか。

  • 組織を脱退した後,プログラムやプロセスにエラーを引き起こし,長期にわたる不調をシステムに引き起こす

  • 組織を脱退する前に,重要なシステムの管理用パスワードを変更し,だれにもそのことを伝えない

  • 故意にバックアップ・メディアを消去する

  • あたかも通常のバックアップのように見せかけて,後でリカバリすることはできないバックアップを作成する

  • リカバリや再インストールをより困難にするためにOSや製品メディアを破損させる

 このように,リモートから攻撃されるよりも,内部犯行の方が被害は甚大になる可能性がある。内部犯行にはまず,十分注意しなくてはならない。

原則2:自分のシステム以外を信頼しない

 ネットワーク上にあるUNIXのrootは,そのネットワーク上の他のrootを信頼した設定が可能である。また,Windows NTネットワークのドメイン・モデル,Windows 2000ネットワークのフォレスト間にも,同様の設定ができる。

 信頼関係を作成しておけば,ほかのシステムにログインする際にパスワードを入力する必要などがなく,利便性は向上する。しかし,その一方でセキュリティは低下する。あるシステムへの攻撃が成功すると,信頼関係を使って他のシステムを攻撃することが可能だからだ。

 自システム以外は,安易に信頼しないことが重要である。また,信頼する場合には,十分に注意を払う必要がある。

原則3:自分自身を信頼しない

 自分を信頼しないことは,システム管理者にとってはよい習慣である。バスや列車の運転士のしぐさを思い出してみよう。必ず実行前に「指差し確認」して,これからする作業の確認を行っている。「慣れ」に任せず確認することで,単純なミスを大幅に減らすことができる。

 システム管理者はあまり暇な人種ではない。ユーザーの勝手な要求や期限に追われ,長時間の仕事に耐えなければならない場合がほとんどだろう。こういった場合,単純ミスが致命的な結果をもたらすことがある。それを防ぐには,作業前の確認が非常に有効だ。

原則4:侵入しようとする者に,「やったら捕まる」と思わせる

 最近は,近所の小さな文房具店から,大規模スーパーまで,「万引きをした場合には警察へ通報します」という張り紙をしている。また,わざと目に付く場所に,万引き防止機器や防犯カメラ,モニターを設置している。これらは犯罪に対する大きな抑止力となっている。

 同じように,管理者はアクセス・ログや作業履歴を適切に採取して,不正侵入に備えなければならない。ログがきちんと記録されていることが分かれば,侵入者は不正行為をためらうはずだ。

原則5:複数のレイヤーで防御する

 システム管理者やネットワーク管理者,または技術設計者のよくある致命的なミスは,「マジノ線シンドローム」に陥ることである。「マジノ線シンドローム」とは,システムやサービスの保護を,1つのセキュリティ手段にすべて任せてしまうことである。

 例えば,ファイアウオールにシステム保護のすべてを任せる場合を考えてみよう。この場合には,ファイアウオールのアクセス・リストに,ひとつでもミスがあれば,外部の攻撃者が社内ネットワークへのアクセス権を取得できる可能性がある。

 これに対して,システムをレイヤーの集合体と考え,それぞれのレイヤーで防御するようにすれば,ひとつのミスが致命的な結果になることを防げる。例えば,ファイアウオールのフィルタに加えて,ルーターのフィルタリングも利用すれば,上記のような攻撃を防げる。

 複数のレイヤーで防御する理由は,クラッキング対策のためだけではない。システムを防御するセキュリティ・メカニズムは複雑で,複数の人間によって管理されている場合が大多数であろう。また,すべてのユーザーが,システムの構造を理解しているわけではなく,適切な教育を受けていない場合もある。そのため,設定ミスや操作ミスは必ずといっていいほど発生する。複数のレイヤーで防御していれば,そのミスが影響する範囲を最小限に抑えることが可能である。

 ただし,レイヤーごとの防御を導入すると,セキュリティが高まる一方で,利便性は低下する。例えば,レイヤーによる保護を導入すると,それまでは自由にアクセスできたサーバーやアプリケーションの利用に,パスワードの入力が必要になる場合がある。この場合,ユーザーから不平不満が寄せられることは火を見るよりも明らかだ。これについては,ユーザーに対する理解と協力を得る他に方法はない。

原則6:不要なサービス,パッケージは無効にする

 システム管理者が利用する多くのOSは,デフォルトでは多くの機能が有効になったままで出荷されている。必要がないサービスやパッケージは無効にしておく必要がある。

 例えば,リモートからの攻撃に気を病むシステム管理者であれば,単純なルールを適用できる。まず,一つひとつのサービス(デーモン)のアクセス・コントロールに悩む前に,必要がないサービス自体を止めてしまう。例えば,rpcbind デーモンが不要なら止めてしまう。あるいは,Alerter Serviceが不要であれば,デーモン自体を止めてしまう。そして,残った必要なサービスに対し,いかにアクセス・コントロールするのかを考えるのである。

 なお,ここで「必要」とは「なくてはならない」ということであり,「あれば便利」ということではない。

原則7:使う前に評価する

 筆者も含め,多くの人は新しい物が大好きだ。新しい物事には,新しい発見があり,興味は尽きない。当然,システム管理者も同じである。しかし,いくら興味があっても,システム管理者はすぐに飛びついてはいけない。新しいツールやパッケージなどがリリースされた場合,それをユーザーに提供する前にセキュリティ評価をしなければならない。

 評価の間,新しいツールを使えないユーザーからは不満の声が上がるだろう。しかし,一度提供したツールを,「セキュリティの問題があるから」と取り上げると,不満の声は倍以上になるはずだ。

 提供する前に評価することが,ユーザーの立場から,そしてセキュリティの観点からも重要である。

原則8:最悪の事態に備える

 楽観論,悲観論,どちらを選択しても構わない。しかし,システム管理者にとっては,悲しむべき現実かもしれないが,セキュリティ・リスクを軽減するための「奥の手」をいくつか準備しておく必要がある。それが,「最悪の事態に備える」ことである。

 いくら万全を期したつもりでも,侵入を許す可能性はある。その時に,被害を最小限に食い止める手だてを用意しておかなければならない。

 さて,以上8つの原則のうち,いくつ当てはまっただろうか。システム管理者やシステム管理者を任命する人,また,セキュリティについて戦略を練る立場であれば,これらの原則に沿った方法で,組織をセキュアに保つことが望ましい。


坂井順行 (SAKAI Yoriyuki)
株式会社ラック 不正アクセス対策事業本部
sakai@lac.co.jp


 IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は,その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え,専門家の立場から解説していただきます。