パスワードの管理と運用を考える：Linux管理者への道（1）（2/2 ページ）

» 2002年06月15日 00時00分公開

各サービスにおける検討事項

リモートログイン

　リモートログインサービスは、そのユーザーに許可されていることがすべて可能になるので、十分に注意して扱う必要があります。

　最近のディストリビューションの場合、通信データを暗号化するsshを使用するのが普通です。ただし、Telnetやrloginといったプロトコルも利用できます。Telnetやrloginではアカウント／パスワードが暗号化されずにネットワークに流れてしまうので、できる限り使用しないようにしましょう。

　ユーザーにリモートログインサービスを利用させる場合は、ユーザーにシェルを与える必要があります。しかし、例えばメールサーバとファイルサーバを利用するだけのユーザーにシェルは不要です。このようなユーザーには、実際に機能する/bin/bashのようなシェルの代わりに、/bin/falseのような機能しないシェルを与えておくのがよいでしょう。

　また、sshはデフォルトでrootユーザーの直接ログインを認めています。これは以下の2点において望ましくないので、特に理由がなければ設定を変更しておきましょう。

root権限を得るまでの認証が一段階
だれがroot権限を得て作業したのかをトレースするのが困難

　管理者はリモートからroot権限を奪えるようなセキュリティホールには敏感ですが、ローカルからのみroot権限を奪取できるようなセキュリティホールに対しては関心が薄くなる傾向があるのではないでしょうか。また、ローカルアタック可能なセキュリティホールにキッチリと対処している場合でも、セキュリティホールが発見されてからソフトウェアをバージョンアップするまでに、どうしてもタイムラグが生じてしまいます。こうしたことを考慮すると、ログインサービスには細心の注意を払う必要があるでしょう。

メールの受信

　メール受信で一般に利用されるプロトコルが、POP3あるいはIMAP4です。これらのプロトコルでは、データが暗号化されずに送られます。当然、ユーザーアカウントやパスワードも平文で流れています。ツールを使えば非常に簡単に盗聴できるので、安全だと断言できるネットワークやパスワードが漏れても問題ない場合以外は使用しないようにすべきです。

　通常、メールアカウントはシステムユーザーで扱っているので、そのユーザーでのリモートログインが可能な場合、非常に危険な状態になります。ただ、会社で使用するメールを自宅や出先でも受け取りたいという要望もあるため、制限するのはなかなか難しいのではないでしょうか？

　パスワードを守るにはやはり暗号化が必要になりますが、メール受信の際に暗号化する手段はいくつも考えられます。ただ、実際に運用していくうえで、使用するユーザーのことも考える必要があるでしょう。以下に例を示しますが、どれも一長一短があると思います。


暗号化の方法	説明
VPN	サーバ／クライアントともに設定が面倒。インターネット上は暗号化されるが、LAN内では平文でデータが流れる
APOP	受信作業を行うごとに、異なる使い捨てパスワードを利用。対応するメールクライアントが限られる
POP over SSL	対応するメールクライアントが少ない
POP over SSH	利用には相応のスキルが必要。すべてのユーザーに利用させるのは困難
Webメール＋SSL	サーバの構築に手間は掛かる（注）が、Webブラウザでの利用のため、操作は簡単
usermin＋SSL	userminの構築自体は簡単だが、必要以上のサービスも利用できるようになるという問題がある
注：IMP（http://www.trustbee.com/impjp/）というソフトを利用するのもいいでしょう

Windowsとのファイル共有（Samba）

　Sambaでファイルサーバを構築した場合、基本的にアカウント／パスワードを管理するファイルが異なります。インストールの仕方にもよりますが、デフォルトでは/usr/local/samba/private/smbpasswd、Red Hat Linux 7.xの場合は/etc/samba/smbpasswdで管理されます。

　これはWindowsとLinuxで認証方法が違うためですが、そのため同じユーザーアカウントとパスワードを別々に管理する必要があります。ただし、pam_smb、winbind、LDAPなどを利用してLinuxとWindowsのパスワードを統合する方法も存在します。

システムに求められる要件の把握

　システムに関する設定を行う場合や新規にサーバを構築する場合、事前にシステムをどのように運用していくのかを決定しておく必要があります。実際はさまざまな側面から考える必要がありますが、ここではパスワードに焦点を絞って考えます。

　初めに断っておきますが、正解に近い解はあっても、運用方法に正解はありません。というのも、システムに求められる要件はそれぞれ異なってくるからです。要件を熟考し、システムに合わせた選択をしていく必要があります。

どのようなサービスを利用するのか

　システムに求められる要件は、場合によって大きく変わってきます。パスワードに焦点を当てても、「どのようなサービスを立ち上げるのか」「そのうち認証が必要なサービスは何なのか」を整理しておきましょう。利用するプロトコルによって、「暗号化が必要なのか」など考えることは違います。

だれに利用されるのか

　システムがいろいろな用途で使用されるとしても、すべてのユーザーにすべてのサービスが必要だとは限りません。メールや社内のファイルサーバはだれもが利用するものだとしても、すべてのユーザーがシステムにログインして作業するわけではないことに注意しましょう。

どこから利用されるのか

　通信はLAN内だけで発生するのか、インターネット経由でのアクセスがあるのかも考えることの1つでしょう。例えば、メールを社内だけでなく自宅から読み出したい、携帯端末からも操作したいといった要望もあると思います。

ユーザーアカウント／パスワードの管理方法

　ユーザーアカウント／パスワードの管理方法を決定する場合、「セキュリティ」を考慮しなければならない管理者の立場とともに、「使い勝手」を求めるユーザーの視点からも考えるべきです。また、運用の手間といったことも考えておきたいところでしょう。ここでは、考えられる主な項目について、それぞれの視点で分析します。

パスワードを統合するか？分散するか？

　パスワードを分散させる意義としては、パスワードが破られることによって芋づる式にクラックされる危険を回避することが挙げられます。複数のサーバに同じパスワードを設定する場合を考えれば分かるでしょう。

　しかし、ユーザーの使い勝手や管理の手間から考えると、パスワードは統一したいところです。セキュリティを高めるために必要であれば仕方がないのですが、あまり多くのしかも複雑なパスワードをユーザーに使用させると、パスワードをメモした紙をディスプレイや机に張ってしまうユーザーが出てくる可能性もあります。どこに妥協点を見いだすかを考慮する必要があります。

　ただし、一般ユーザーは1つのパスワードに統一させたとしても、rootパスワードはサーバごとに設定すべきです。

パスワードを変更させる方法の検討

　もともとLinuxには、短過ぎたり辞書攻撃に弱いパスワードが設定できない機構（pam_cracklib）や定期的にパスワードの変更を求める仕組みがあります。

　管理の手間を減らすには、できるだけ個々のユーザーにパスワードを管理させた方が都合が良いのですが、定期的なパスワード変更をシェル上で行えるほどのスキルをすべてのユーザーに求めるのは難しいでしょう。いくらパスワード変更を呼び掛けても、それに必要な手段を提供しなければうまくいくはずがありません。

　システムを利用するユーザーに、どのようなインターフェイスを提供できるでしょうか？以下に有効と思われる2つの方法を示します。

sshアクセスによるパスワード変更

　sshを利用するユーザーに対しては、/etc/shadowで設定した有効期限の警告や、pam_cracklibによる安易なパスワードの設定制限が可能です。

　sshログインが認められるほどのユーザーであれば、シェル上での作業に支障はないと考えられるので、この方法でもユーザースキルの面の問題はないでしょう。

　では、シェルコマンドに対する知識のないユーザーに対してはどうでしょうか？先に、通常のシェルを与える必要のないユーザーには、シェルとして/bin/falseを与えるのがよいと書きましたが、パスワードの変更を自分で行わせたい場合は/usr/bin/passwdを与える方法があります。こうすることで、パスワード変更のみ可能になります。シェルとして/usr/bin/passwdを与えられたユーザーがsshでログインすると、パスワードプロンプトがいきなり表示され、設定が終わると接続が切断されます。使い勝手はあまり良くはありませんが、コマンドを入力するといった操作が不要なので、少しの説明でほとんどのユーザーが利用可能になると思われます。

Webブラウザを使った設定

　使い勝手を考えると、Webブラウザ上での作業がベストです。userminなどのツールを使用すれば、Webブラウザ上で簡単にパスワード変更などの作業が行えます。ただし、usermin経由でパスワードを変更する場合は、/etc/shadowによるパスワードの変更可能最低日数やpam_cracklibによる安易なパスワードに対する制限機能を利用できないことに注意が必要です。また、パスワードがネットワークに流れるので、SSLによる暗号化は必須になってきます。

　今回は、パスワードの概論的な内容になりました。次回は具体的なシステムを想定し、今回紹介した方法のいくつかを組み合わせて構築する手順を紹介します。

「次回」へ