大きな組織でのUnixセキュリティに取り組む（第2回）
仕事をやろうとするとき、従業員はその手間を省くためにセキュリティ規則を曲げることがある。 単純なパスワードでも用が足りるのに、どうして訳のわからない複雑なパスワードが必要なんだ？ パスワードを共有すれば時間の節約になるのに、どうしてパスワードを秘密にしておくんだ？ ftpやrshを使った後で誰もが無効に戻すのを忘れてしまうなら、ずっと有効にしておけばいいじゃないか？ という具合である。
管理者は（ユーザがサーバにログオンしている場合はユーザも）、システムのセキュリティを気に掛ける必要がある。 なぜだろうか？ おそらくあなたは、攻撃者が侵入してくるのを心配しているから、あるいは、監査人や保険会社があるレベルのセキュリティを維持することを要求しているから、と答えるだろう。 こういった理由は、すべての人が理解している必要がある。 このことは明らかなように思えるが、実際に理解されているのは驚くほどまれなことである。 セキュリティスタッフは、セキュリティを本質的によいものであって、それを推進するにあたって何の理由付けも必要ないと考えがちである。 そのため、彼らは理由の説明を怠る。 しかし管理者は、セキュリティを本質的に厄介物であって、彼らの仕事を難しくするものだと考えがちである。 そのため、彼らに理由の説明をすることは絶対に欠かせない。 もちろん、セキュリティの弱点がどこにあるかをすべてのスタッフに詳しく教えることは非生産的かもしれないが、セキュリティ侵害の実例を交えて大まかに説明をすれば、人々にセキュリティへの関心を持たせることができる。
自分の組織にとってなぜセキュリティが重要なのかを理解したら、次に管理スタッフは規則がどんなものかを知る必要がある。 この際に確実に言えるのは、次のようなことだ。 第一に、管理者は、セキュリティ規則のうちいくつかは無意味だと考えるだろう、ということ。 第二に、管理者は、セキュリティ規則のうちいくつかは完全に実行不可能だと考えるだろう、ということである。 いくつかの懸念に関しては、管理者はおそらく完全に正しいだろう。 考え出された時点では完全に実行可能だと思えた規則が、実際の環境に当てはめると大きな不備があることが判明するのはよくあることだ。 たとえば、ある規則でNFSの使用を禁止しているとする。 しかし、もしその会社がNFSを必要とするアプリケーションに多額の投資をしたばかりであった場合、セキュリティ計画の立案者はいくらか譲歩しなければならないことになるだろう。
管理者の話を聞くべきである。 管理者がこのセキュリティ規則は実行不可能だと言うなら、その声を無視してはならない。 彼らがそう言う理由を知る必要がある。 理想を言えば、最終的にはすべての人が、その規則を修正するか、あるいはそれを実現できる方法があるということに（しぶしぶであったとしても）合意するべきだ。 管理者を関与させないのは、単に規則が無視されるように仕向けるだけである。 また、セキュリティスタッフを非難する口実を与えるだけかもしれない。 セキュリティスタッフには、少なくともそれだけの落ち度があるのだ。 場合によっては、ある規則を実行可能にするために、ベンダにソフトウェアを変更させることが必要になるかもしれない。 もしベンダが大企業で、あなたの組織が大口顧客でない場合、これは（試してみることはできるが）現実的ではないだろう。 もしベンダが比較的小さな会社であるか、そのソフトウェアがオープンソースである場合、変更できる可能性はかなり高くなるだろう。 あるいは、少なくとも、なぜ変更できないのか、代替案を含む十分な説明を受けられるだろう。
セキュリティアップデートが十分に行われていない場合、サーバ境界（ネットワーク境界ではないことに注意）を保護するために、許可されていないコマンドラインアクセスを阻止するセキュリティ規則は特に重要である。 技術面から見ると、これが意味するのは、アクセス可能なネットワーク上をパスワードが平文で送信されるのを防ぐ規則と、サーバがだまされて他のホストと信頼関係を結ぶのを防ぐ規則である。 これらの規則はtelnet、rsh、ftp、DNS、NIS、NFSなどのプロトコルを対象とする。 また、これらの規則にはパスワード規則を含む。 たとえば、弱いパスワードを禁止し、パスワードの期限切れを強制する技術的な規則である。 ほとんどの種類のUnix/Linuxでは、その他の高度なアカウント制御機能も利用できる。 たとえば、パスワードを辞書と照合し、パスワードが時間制限内に再利用されることを防ぎ、一定期間（通常は1か月）が経過したらパスワードを期限切れにするという機能である。
強力なパスワードを強制することは重要である。 CrackやJohn the Ripperなどのパスワードクラッカーを実行してみれば、そのことが身に染みてわかるはずだ。 よいパスワードを選択するよう社内のユーザを教育していない場合、これらのツールを使えば、1分以内に少なくとも数個のアカウントをクラックできる可能性が非常に高い。
ケンブリッジ大学のRoss Anderson氏は、パスワードを選択するための複数の方法について調査したことがある。 彼は、無作為に選択された単純なパスワードがどれだけセキュアか、どれだけ簡単に覚えられるかを調べ（もちろん、付箋にパスワードを書き留めるのは禁止）、その結果、覚えやすく、かつクラックされにくい1つの方法を見つけた。 この方法（頭文字法）では、ユーザにとって意味のあるフレーズの頭文字からパスワードを構成し、いくつかの文字の代わりに数字と句読点を使う。 たとえば、そのフレーズが”Hit me baby one more time — Britney Spears”の場合、パスワードは*Mb1mtBsのようになる。
パスワードの選択に頭文字法を使うよう、管理者に奨励すべきである。 と同時に、弱いパスワードを使っているユーザを見つけるために、定期的なクラッキングセッションを実行しよう。 誰かのパスワードがクラックされたという通知を内密に行い、その際に強力なパスワードの選択方法と強力なパスワードが必要な理由を一緒に伝えれば、そのユーザに自分のやり方を変えさせるには十分なはずだ。
大規模サーバ環境にこれらすべてのセキュリティが実現された後は、誰かがミスを犯したか故意に何かを変更したことによってシステムのセキュリティあるいは機能性が損なわれるというリスクが出てくる。 たとえば、ファイルパーミッションが変更されたり、設定ファイルが間違って修正される可能性がある。 そこで、セキュリティ規則の順守状況を調べるために、何らかの継続的なチェックが必要である。 これは、2年ごとの監査では十分ではないだろう。 しかし、複雑すぎたり、コストがかかりすぎることでは駄目だ。 毎日あるいは毎週、単純なシェルスクリプトを実行するだけで十分なはずである。 このスクリプトでは、可能な限りのすべてのチェックを行い、順守されていない点を報告し、また可能ならば、サーバが標準に適合するように自動的に問題を修正するべきだ。 スクリプトでサーバの自動修正を行う場合はたいへんな慎重さが求められるが、かといって、誰かが手作業で問題を修正した方がよいかというと、それはおそらく長続きはしないだろう。
すべての人に自分のユーザアカウントを守らせることが大事である。 ただし、誰も管理していないアカウントがある場合は、これは重要ではないかもしれない。 組織を辞めた人々のアカウントが残っていたり、まったく使用されていないアプリケーションによってインストールされたアカウントがあるかもしれない。 もちろん、誰かが会社を辞めたり部署を異動したときにアカウントを削除するための手順がきちんと文書で規定されているだろうが、手順が完璧ということは決してない。 そこで、補助的な手段が必要になる。 スクリプト（順守状況を継続的にチェックするスクリプトなど）で、まったく使用されていない、あるいは数か月間使用されていない休眠状態のアカウントをチェックしよう。 ただし、注意が必要である。 もしオンコール保守（依頼による保守）要員が午前3時にサーバにログオンできなくて、その理由が彼のアカウントが前月に自動的に削除されていたためだったとしたら、誰も感謝などしてくれないだろう。 自動的にアカウントを削除することはできるが、それを行う場合は、すべての管理者とユーザが、アクセスを必要とするすべてのサーバに定期的にログオンしていることが確実でなければならないし、アプリケーションアカウントを除外する必要もある。 これを行う1つの方法は、管理者が、管理対象のすべてのサーバに自動的にログオンするスクリプトを月に1回手作業で実行することだ。 ログオンするのは、（パスワード変更など、他の作業を行うこともできるが）単に最終ログイン時刻を更新するためである。
ソーシャルエンジニアリングは、攻撃者がサーバへのコマンドラインアクセスを獲得するためによく用いられる方法である。 多くのIT部署は大規模で、地理的に分散しており、ときには別々の国にチームがあることさえある。 管理者の中には、お互いに顔を合わせたことのない人々もいるかもしれない。 また、チームに新しい人が加わっても、しばらくの間、そのことに気付かない人々もいるかもしれない。 このような部署は、ソーシャルエンジニアリング攻撃の格好の標的となる。 標的の組織の内部事情について何らかの最小限の情報を手に入れた攻撃者は、正確に狙いを定めて電話をかけ、電話の相手をうまく納得させることができれば、アカウントを作成させたり、パスワードをリセットさせられる見込みが十分にある。
妙なことを言うと思われるかもしれないが、管理者たちが、誰がチームにいるか確実に知っているようにすべきである。 社内の管理チームがいくつかの場所に分散していることは、最近では珍しくない。 別々の国や、ときには別々の大陸に分散していることさえあるかもしれない。 誰かが電話を受けたとき、その人は誰が本物の管理者で誰がそうでないかをわかっている必要がある。 オフィスに驚くほど頻繁に新しいスタッフが入ってくるのに、誰も新しく入ってきた人々のことを話しもしない、ということもあり得る（たとえ間違って配属されてきたとしても、何日か経ってやっと、誰かがおずおずと「あの隅にいるのは誰で、何をしてるんだい？」と尋ねるまで、誰もそのことに気付かないのである）。 同じ道理で、セキュリティチームは管理者を、そして管理者チームはセキュリティ担当者を、双方からの簡単なコミュニケーション手段を通じてよく知っておくべきだと言える。 この手段については、単に電話連絡を可能にしておくことであっても、定期的なセキュリティニュースレターの送付であってもよい。 これはまったく簡単なことに思えるが、現代的な会社においては、最後に組織改変がされた後であなたがどの部署にいるかを、誰が他の部署にいるかを気にすることなく判断するのは難しい場合もある。
サーバをセキュアに保つことは人に誇れる功績であり、それを管理する人々は感謝を示されるべきだ、ということを認識しよう。 新人の教育はもちろん、現存スタッフの教育のため、継続的にセキュリティ研修を行い、セキュリティ意識の維持を図ろう。 常に管理者を関与させ、彼らの話を聞くようにしよう。 非セキュリティスタッフに、個人能力開発の一環として社外のセキュリティ研修コースを受講させることを検討しよう。
セキュリティ疲労というものを意識しよう。 時間が経過し、何もセキュリティの不備はない（発見されていない）。 すると、人々は自然に気を緩め始める。 あのすべての面倒なセキュリティ規則は何のためにあったのか？ セキュリティの問題なんてないじゃないか？ こうして、あなたが知らないうちに出発点に戻ってしまう。 これに対抗するには、いくつかの方法がある。 中でも最も簡単なのは、メディアで報道されるセキュリティ侵入事件に注意を払い、スタッフに詳細を回覧することである。 これで少なくとも、たとえ今、社内に侵入されていなくても、外には犯罪者がいるという意識を強く持たせ続けることができる。 監査を繰り返し行うことは重要だが、監査は正しく行う必要がある。 セキュリティ文書を監査しても、ほとんど意味がない。 ほとんどの攻撃者は、侵入を試みる前に侵入対象のセキュリティ規則をチェックしたりせず、何が実装されているかを調べるだけである。 したがって、たとえ少数であっても、実際のサーバに対して無作為抽出検査をした方がよい。 また、侵入実験をするべきである。 外部コンサルタントに社内ネットワークの内部へのアクセスを許可し、コンピュータへの侵入を試みてもらおう。 外部の人々を関与させるのは有益である。 それまで見過ごしていた問題を指摘してくれるかもしれないし、あなたの組織を他の組織と比較して、何らかのアドバイスを与えてくれるはずだ。
すべてがうまくいけば、業務を保護するのに十分で、かつ管理者が実行可能で所有者とユーザが受け入れ可能なセキュリティを実現できる。 また、すべてが非常にうまくいけば、さらに1年か2年でこのセキュリティを完全に実現できるだろう。
Iain Roberts――フリーランスのITコンサルタント。大規模Unix環境に関しては10年の経験がある
