Solaris のシステム管理 (基本編)

ユーザーアカウント管理のガイドライン

次の節では、ユーザーアカウントを作成するガイドラインと計画方法について説明します。

ネームサービス

大規模なサイトでユーザーアカウントを管理する場合、LDAP、NIS、NIS+ などのネームサービスまたはディレクトリサービスを使用できます。ネームサービスまたはディレクトリサービスを使うと、ユーザーアカウント情報を各システムの /etc 内のファイルに格納するのではなく、一元管理できます。ユーザーアカウントにネームサービスまたはディレクトリサービスを使用すれば、サイト全体のユーザーアカウント情報をシステムごとにコピーしなくても、同じユーザーアカウントのままシステム間を移動できます。ネームサービスまたはディレクトリサービスを使用すると、ユーザーアカウント情報を集中化および一元化して管理できます。

ユーザー (ログイン) 名

ユーザーは、ユーザー名 (ログイン名とも呼ばれる) を使って、自分のシステムと、適切なアクセス権を持つリモートシステムにアクセスできます。作成するユーザーアカウントそれぞれに、ユーザー名を選択しなければなりません。ユーザー (役割) 名は、次の条件を満たしていなければなりません。

複数のドメインにまたがることもあるユーザーの組織内で、固有であること。
2 文字から 8 文字の英数字を使用する (最初の文字は英字でなければならず、少なくとも 1 文字は小文字にする必要がある) 。

ユーザー名には、ピリオド (.)、アンダースコア (_)、ハイフン (-) を使用できますが、これらの文字により障害が発生するソフトウェアもあるため、使用はお勧めできません。

ユーザー名の標準的な作り方を決めておくと便利です。ユーザー名はユーザーが覚えやすいものにしてください。単純な規則の例としては、ユーザーのファーストネームの頭文字とラストネームの最初の 7 文字を使用します。たとえば、Ziggy Ignatz は zignatz になります。他のユーザー名と重複する場合は、ユーザーのファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 6 文字を使用します。たとえば、Ziggy Top Ignatz は ztignatz になります。さらに重複する場合、固有の名前になるまで、ファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 5 文字、および 1、2、3 などの数字を使用できます。

注 -

それぞれの新しいユーザー名は、システムまたは NIS や NIS+ のドメインに登録されているメール別名 (エイリアス) とは異なるものでなければなりません。そうしないと、メールは実際のユーザーにではなく別名に送られることがあります。

ユーザー ID 番号

ユーザー名に関連するものとして、ユーザー ID (UID) 番号があります。ユーザーがログインしようとするシステムは、UID 番号によってユーザー名を識別したり、ファイルとディレクトリの所有者を識別します。多数の異なるシステム上で、ある個人用に複数のユーザーアカウントを作成する場合は、常に同じユーザー名とユーザー ID を使用してください。そうすれば、そのユーザーは、所有権の問題を起こすことなく、システム間で簡単にファイルを移動できます。

UID 番号は、2147483647 以下の整数でなければなりません。また、通常のユーザーアカウントと特殊なシステムアカウントに必要です。次の表にユーザーアカウントとシステムアカウントに予約されている UID 番号を示します。

表 4-1 予約済みの UID 番号


ユーザー ID 番号	ユーザー/ログインアカウント	説明
0 - 99	`root`、`daemon`、`bin`、`sys`、など	システムアカウント
100 - 2147483647	通常のユーザー	汎用アカウント
60001 と 65534	`nobody` および `nobody4`	匿名ユーザー
60002	`noaccess`	アクセス権のないユーザー

0 から 99 までの UID 番号は予約されていますが、これらの番号でユーザーを追加することはできます。ただし、通常のユーザーアカウントには使用しないでください。システム上の定義により、root には常に UID 0、daemon には UID 1、擬似ユーザー bin には UID 2 が設定されます。また、UID が passwd ファイルの先頭にくるように、uucp ログインや、who、tty、ttytype などの擬似的なユーザーログインには低い UID を与えるようにしてください。

ユーザー (ログイン) 名と同様に、固有の UID を割り当てる方法を決めてください。企業によっては、固有の従業員番号に、管理者が 1000 を加えて固有の UID 番号を作成している場合もあります。

セキュリティ上のリスクを最小限に抑えるために、削除したアカウントの UID を再利用することは避けてください。どうしても UID を再利用する必要がある場合、はじめから作りなおして、新しいユーザーが前のユーザーの属性に影響されないようにしてください。たとえば、前のユーザーがプリンタの拒否リストに含まれていたためプリンタにアクセスできなかった場合、その属性を新しいユーザーにも適用するとは限りません。

大きな数値のユーザー ID とグループ ID の使用

UID とGID の値の制限が符号付き整数の最大値 (つまり、2147483647) に引き上げられました。

ただし、60000 を超える UID と GID は機能的に完全でなく、多くの Solaris の機能と互換性がありません。したがって、60000 を超える UID と GID を使用することは避けてください。

次の表では、Solaris の以前のリリースとの相互運用性について説明します。

表 4-2 60000 を超える UID と GID の相互運用性に関する問題


項目	製品またはコマンド	問題または注意
NFS^TM 互換性	SunOS^TM 4.0 NFS ソフトウェアおよびその互換バージョン	NFS サーバーとクライアントのコードは、大きな UID と GID を 16 ビットに切り捨てる。これによって、大きな UID と GID を使用している環境において SunOS 4.0 およびその互換バージョンのシステムを使用すると、セキュリティの問題が発生する可能性がある。SunOS 4.0 およびその互換バージョンのシステムにはパッチが必要である。
ネームサービスの相互運用性	NIS ネームサービスおよびファイルベースのネームサービス	60000 を超える UID を持つユーザーは、Solaris 2.5 およびその互換バージョンが動作しているシステムでは、ログインしたり、`su` コマンドを使用できるが、そのユーザーの UID と GID は 60001 (nobody) に設定される。
	NIS+ ネームサービス	60000 を超える UID を持つユーザーは、Solaris 2.5 およびその互換バージョンと NIS+ ネームサービスが動作しているシステムではアクセスが拒否される。

表 4-3 大きな UID と GID の制限の要約


UID または GID の値	制限
60003 以上	この分類のユーザーが、Solaris 2.5 およびそれ以前の互換バージョンと NIS ネームサービスまたはファイルネームサービスが動作しているシステムにログインすると、`nobody` の UID および GID を取得する。
65535 以上	NFS バージョン 2 ソフトウェアが動作している Solaris 2.5 およびその互換バージョンのシステムでは、この分類の UID は 16 ビットに切り捨てられる。その結果、セキュリティの問題が発生する場合がある。この分類のユーザーが `cpio` コマンド (デフォルトのアーカイブフォーマットを使用する) を使用してファイルをコピーすると、ファイルごとにエラーメッセージが表示されて、UID と GID はアーカイブにおいて `nobody` に設定される。 SPARC システム: この分類のユーザーが SunOS 4.0 およびその互換バージョンで動作可能なアプリケーションを実行すると、一部のシステムコールから `EOVERFLOW` が戻されて、そのユーザーの UID と GID は `nobody` にマップされる。 IA システム: この分類のユーザーが SVR3 互換のアプリケーションを実行すると、一部のシステムコールから `EOVERFLOW` が返される場合がある。 IA システム: この分類のユーザーが、マウントされた System V ファイルシステムでファイルまたはディレクトリを作成しようとした場合、System V ファイルシステムは `EOVERFLOW` エラーを返す。
100000 以上	`ps -l` コマンドは最大 5 桁の UID を表示する。したがって、99999 より大きな UID または GID を含むときは、出力される列が揃わない。
262144 以上	この分類のユーザーが `cpio` コマンド (`-H odc` フォーマットを使用する) または `pax -x cpio` コマンドを使用してファイルをコピーすると、ファイルごとにエラーメッセージが戻されて、UID と GID はアーカイブにおいて `nobody` に設定される。
1000000 以上	この分類のユーザーが `ar` コマンドを使用すると、そのユーザーの UID と GID はアーカイブにおいて `nobody` に設定される。
2097152 以上	この分類のユーザーが `tar` コマンド、`cpio -H ustar` コマンド、または `pax -x tar` コマンドを使用すると、そのユーザーの UID と GID は `nobody` に設定される。

パスワード

ユーザー名は公表されますが、パスワードを知っているのは各ユーザーだけでなければなりません。各ユーザーアカウントには、6 文字から 8 文字の英数字と特殊文字を組み合わせたパスワードを割り当ててください。ユーザーアカウントを作成するときにユーザーのパスワードを設定します。ユーザーは、システムに初めてログインするときにそのパスワードを変更できます。

コンピュータシステムのセキュリティを強化するには、ユーザーにパスワードを定期的に変更するよう指示してください。高いレベルのセキュリティを確保するには、ユーザーに 6 週間ごとにパスワードを変更するよう要求してください。低いレベルのセキュリティなら、3 ヵ月に 1 度で十分です。システム管理用のログイン (root や sys など) は、毎月変更するか、root のパスワードを知っている人が退職したり交替したりするたびに変更してください。

コンピュータセキュリティが破られる原因の多くは、正当なユーザーのパスワードが解読される場合です。ユーザーについて何か知っている人が簡単に推測できるような固有名詞、名前、ログイン名、パスワードを使わないよう各ユーザーに対して指示してください。

良いパスワードの例としては以下のようなものが考えられます。

英語の単語を組み合わせたフレーズ (たとえば、beammeup)
フレーズ内の各単語の頭文字だけを集めた、意味のない文字列 (たとえば、SomeWhere Over The RainBow から取った swotrb)
文字を数字や記号に代えた単語 (たとえば、snoopy を sn00py にする)

次のものは、パスワードに不適当です。

自分の名前そのもの、逆読み、飛ばし読みのもの
家族やペットの名前
免許証番号
電話番号
社会保険の番号
従業員番号
趣味に関係のある名前
季節に関係のある名前 (たとえば 12 月に Santa を使うなど)
辞書にある単語

パスワードの有効期限を設定する

NIS+ または /etc 内のファイルを使用してユーザーアカウント情報を格納する場合は、ユーザーのパスワードにパスワード有効期限を設定できます。パスワード有効期限の設定によって、ユーザーに定期的なパスワード変更を強制したり、あるパスワードを保持するのに必要な最低日数以前にパスワードを変更するのを防止したりできます。不正ユーザーが、古くて使用されていないアカウントを使用して、発覚せずにシステムのアクセス権を得るような場合を防止するために、アカウントが無効になる日付を設定することができます。パスワードの有効期限属性を設定するには、passwd コマンドまたは Solaris Management Console のユーザーツールを使用します。

ホームディレクトリ

ホームディレクトリは、ユーザーが専有ファイルを格納するのに割り当てられるファイルシステムの一部分です。ホームディレクトリに割り当てる大きさは、ユーザーが作成するファイルの種類と作業によって異なります。

ホームディレクトリは、ユーザーのローカルシステムまたはリモートファイルサーバーのどちらにでも配置できます。どちらの場合も、慣例により、ホームディレクトリは /export/home/username として作成します。大規模なサイトでは、ホームディレクトリをサーバーに格納してください。ホームディレクトリのバックアップおよび復元を容易に行うことができるようにするために、各 /export/homen ディレクトリに対して別々のファイルシステム (たとえば、/export/home1、 /export/home2 など) を使用してください。

ホームディレクトリが配置される位置に関係なく、ユーザーは通常 /home/username という名前のマウントポイントを介してホームディレクトリにアクセスします。Autofs を使用してホームディレクトリがマウントされていると、どのシステムでも /home マウントポイントの下にディレクトリを作成することは許可されません。Autofs が使用されていると、システムはマウントされている /home を特別なものと認識します。ホームディレクトリの自動マウントについての詳細は、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「autofs 管理作業の概要」を参照してください。

ネットワーク上の任意の位置からホームディレクトリを使用するには、 /export/home/username ではなく、常に $HOME という環境変数の値によって参照するようにしてください。前者はマシンに固有の指定です。さらに、ユーザーのホームディレクトリで作成されるシンボリックリンクはすべて相対パス (たとえば ../../../x/y/x ) を使用する必要があります。こうすることによって、そのリンクはどのシステムにホームディレクトリがマウントされても有効になります。

ユーザーの作業環境

ファイルを作成して格納するホームディレクトリの他に、ユーザーには仕事をするために必要なツールとリソースにアクセスできる環境が必要です。ユーザーがシステムにログインするとき、C、Korn、Bourne シェルなどユーザーの起動シェルで定義される初期設定ファイルによって、ユーザーの作業環境が決定されます。

ユーザーの作業環境を管理するのに便利な方法として、カスタマイズしたユーザー初期設定ファイル (.login、.cshrc、.profile) をユーザーのホームディレクトリに置くという方法があります。ユーザー初期設定ファイルをユーザー用にカスタマイズする詳細については、「ユーザーの作業環境のカスタマイズ」を参照してください。ユーザー初期設定ファイルをカスタマイズした後、新しいユーザーアカウントを作成するときにそれらをユーザーのホームディレクトリに追加できます。

1 回だけ行う作業としてお勧めするのは、「スケルトンディレクトリ」と呼ばれる別々のディレクトリをサーバーに設定することです (ユーザーのホームディレクトリが格納されるのと同じサーバーを使用できます)。スケルトンディレクトリによって、タイプの異なるユーザーに合わせてカスタマイズしたユーザー初期設定ファイルを格納できます。

注 -

システム初期設定ファイル (/etc/profile、/etc/.login) を使用してユーザーの作業環境を管理しないでください。これらのファイルはローカルシステムに存在するため、集中管理されません。たとえば、Autofs を使用してネットワーク上の任意のシステムからユーザーのホームディレクトリをマウントした場合、ユーザーがシステム間を移動しても環境が変わらないよう保証するには、各システムでシステム初期設定ファイルを修正しなければならなくなります。

また、役割によるアクセス制御でユーザーアカウントをカスタマイズする方法もあります。詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (概要)」を参照してください。