この節では、次のような許可されないアクセスからシステムを保護する方法について説明します。
侵入者がシステムにログインできないようにする方法
パスワードファイルの管理方法
許可されないスーパーユーザーが重要なシステムファイルやプログラムにアクセスできないようにする方法
システム上で 2 つのセキュリティバリアを設定できます。第 1 のセキュリティバリアは、login コマンドです。このバリアをクリアしてシステムにアクセスするには、ローカルシステムまたはネームサービス (LDAP、NIS、または NIS+) で認識されるユーザー名と対応するパスワードを入力しなければなりません。
第 2 のセキュリティバリアは、システムファイルとプログラムをスーパーユーザーしか変更または削除できないように設定することです。スーパーユーザーになろうとするユーザーは、root のユーザー名とその正しいパスワードを入力しなければなりません。
ユーザーがシステムにログインすると、login コマンドは /etc/nsswitch.conf ファイル内の情報に従って、該当するデータベースを照会します。このファイルのエントリには、files (/etc ファイルを指定する)、nis (NIS データベースを指定する)、 ldap (LDAP ディレクトリサービスを指定する)、および nisplus (NIS+ データベースを指定する) を含めることができます。このファイルの詳細は、nsswitch.conf(4) のマニュアルページを参照してください。ネームサービスまたはディレクトリサービスの詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』または『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
login コマンドは、入力されたユーザー名とパスワードを確認します。ユーザーのパスワードファイルに入っていない場合や、ユーザーのパスワードが正しくない場合は、システムへのアクセスが拒否されます。ユーザーがパスワードファイルにあるユーザー名を入力し、パスワードがそのユーザー名の正しいパスワードであるときは、そのユーザーにシステムへのアクセス権が与えられます。
システムにアクセスするときは、通常、従来のユーザーログインを使用するか、root ログインを使用します。また、多数の特別な「システム」ログインを使用すると、ユーザーは root アカウントを使用しなくても管理コマンドを実行できます。システム管理者は、これらのログインアカウントにパスワードを割り当てます。
次の表に、システムのログインアカウントとその用途を示します。システムログインは特殊な機能を実行し、それぞれに固有のグループ識別子番号 (GID) が付いています。これらの各ログインには固有のパスワードを設定し、必要のある人だけに知らせるようにしてください。
表 14-3 システムログイン|
ログインアカウント |
グループ ID |
用途 |
|---|---|---|
|
root |
0 |
ほぼ無制限で、ほかのすべてのログイン、保護、アクセス権より優先する。root アカウントはシステム全体へのアクセス権を持つ。root ログインのパスワードはきわめて厳密に保護する必要がある。root アカウントはほとんどの Solaris コマンドを所有する |
|
daemon |
1 |
バックグラウンド処理を制御する |
|
bin |
2 |
一部の Solaris コマンドを所有する |
|
sys |
3 |
多数のシステムファイルを所有する |
|
adm |
4 |
特定のシステム管理ファイルを所有する |
|
lp |
71 |
プリンタ用のオブジェクトデータファイルとスプールデータファイルを所有する |
|
uucp |
5 |
UNIX 間のコピープログラム、UUCP 用のオブジェクトデータファイルとスプールデータファイルを所有する |
|
nuucp |
9 |
システムにログインしてファイル転送を開始するためにリモートシステムで使用される |
パスワードが必要な eeprom コマンドのセキュリティも設定する必要があります。詳細については、eeprom(1M) のマニュアルページを参照してください。
ユーザーはシステムにログインするときに、ユーザー名とパスワードの両方を入力する必要があります。ログイン名は公開されますが、パスワードは秘密にして各ユーザー以外には知られないようにします。また、ユーザーが各自のパスワードを慎重に選択し、頻繁に変更するようにしなければなりません。
パスワードは、最初にユーザーアカウントを設定するときに作成されます。ユーザーアカウントのセキュリティを管理するために、パスワード有効期限を設定し、パスワードを定期的に強制変更することができます。また、ユーザーアカウントを無効にして、パスワードをロックすることもできます。パスワードの設定および管理の詳細については、『Solaris のシステム管理 (基本編)』の「ユーザーアカウントとグループの管理 (概要)」および passwd(1) のマニュアルページを参照してください。
ネットワークで NIS+ を使用している場合、パスワード情報は NIS+ データベースに保持されます。NIS+ データベース内の情報は、アクセス権を許可されたユーザーを制限することによって保護できます。passwd コマンドを使用すると、ユーザーの NIS+ パスワードを変更できます。
ネットワークで NIS を使用する場合、パスワードは NIS パスワードマップに保持されます。NIS では、パスワードの有効期間を指定できません。passwd コマンドを使用すると、ユーザーの NIS パスワードを変更できます。
ネットワークで /etc 内のファイルを使用している場合、パスワード情報はシステムの /etc/passwd ファイルと /etc/shadow ファイルに保持されます。ユーザー名などの情報は、パスワードファイル /etc/passwd に保持されます。暗号化されたパスワードは、/etc/shadow という「シャドウファイル」 に保持されます。このセキュリティ方式によって、暗号化されたパスワードにアクセスされることを防ぎます。/etc/passwd ファイルは、マシンにログインするユーザーであれば誰でも使用できますが、/etc/shadow ファイルを読み取ることができるのはスーパーユーザーだけです。passwd コマンドを使用すると、ローカルシステム上のユーザーのパスワードを変更できます。
ネットワーク上で LDAP が使用されている場合、パスワードとシャドウ情報は LDAP ディレクトリツリーの ou=people コンテナに格納されます。password -r ldap コマンドを使用すると、ユーザーの LDAP パスワードを変更できます。
標準シェルを使用すると、ユーザーはファイルを開く、コマンドを実行するなどの操作を行うことができます。制限付きシェル (rsh) を使用すると、ユーザーによるディレクトリの変更やコマンドの実行を制限できます。制限付きシェルは、/usr/lib ディレクトリにあります。制限付きシェルは、リモートシェル (/usr/sbin/rsh) ではありません。標準のシェルと異なる点は次のとおりです。
ユーザーはホームディレクトリに限定されるため、 cd コマンドを使用してディレクトリを変更できない。
ユーザーはシステム管理者が設定した PATH 内でしかコマンドを使用できないため、PATH 変数を変更できない。
ユーザーはホームディレクトリとそのサブディレクトリ内のファイルにしかアクセスできないため、絶対パス名でコマンドやファイルを指定できない。
ユーザーは > または >> を使用して出力をリダイレクトできない。
制限付きシェルを使用すると、システム管理者はユーザーによるシステムファイルの操作を制限できます。このシェルは、主として特定の作業を実行する必要のあるユーザーを設定するためのものです。制限付きシェルは完全にセキュリティ保護されてはおらず、あくまでも経験の少ないユーザーが問題を起こしたり問題に巻き込まれたりしないようにするために使用します。
制限付きシェルについては、rsh(1M) のマニュアルページを参照してください。
制限付きシェルよりさらにセキュリティを強化したシェルが、Secure Shell (ssh) です。Secure Shell を利用すると、セキュリティで保護されていないネットワーク上のリモートホストに、安全にアクセスすることができます。Secure Shell の使用方法については、第 5 章「Secure Shell の管理 (参照)」を参照してください。
システムには、スーパーユーザーモードに対して root パスワードが必要です。デフォルトの構成では、ユーザーはリモートのシステムに root としてログインできません。リモートログインするとき、ユーザーは自分のユーザー名でログインしてから、su コマンドを使用して root になる必要があります。この設定によって、システム上でスーパーユーザー特権を使用しているユーザーを追跡できます。
スーパーユーザーになりたい場合などは、su コマンドを使用して別のユーザーに変更する必要があります。セキュリティ上の理由から、su コマンドを使用中のユーザー、特にスーパーユーザーのアクセス権を取得しようとしているユーザーを監視する必要があります。
詳細は、「su コマンドを使用するユーザーを監視する方法」を参照してください。