セキュリティの条件

ユーザーの日々の作業が、設定された構成の条件と矛盾しないようにする必要がある場合、この節の規則は特に重要です。システムのセキュリティが脅かされないように、管理者はパスワード、ファイル、および監査データが保護されることを保証する必要があります。

セキュリティの条件に関するユーザーの研修

セキュリティ管理者は、ユーザーの研修も設定する必要があります。以下の規則は、新入社員に手渡すとともに、従来の社員にもこれらの規則の存在を折を見て確認する必要があります (ここに示した以外の提案が必要な場合もあります)。

すべてのユーザーの規則

• 自分のパスワードは誰にも教えないこと。自分のパスワードを知られると、認証なしに、つまり、権限のない者が自分と同じ情報にアクセスできることになります。

  • 自分以外の誰にもパスワードは教えない

  • パスワードを書き留めたり、電子メールにそれを明記したりしない。

• 連想しにくいパスワードを使用すること。

  この条件は、表 2-1 に示すように、トラステッドパスメニューでパスワードを変更する際にも必須になっています。

• 画面をロックしたりログアウトしないまま自分のワークステーションの席を離れない。

• 送信者情報を偽造するためにメールが書き換えられることがあることを留意すること。

• 管理者は、ユーザーに指示を出すときに電子メールには依存しないことに留意すること。電子メールによる指示に従う前に、それが確実に管理者からの電子メールであることを検証する必要がある。

• パスワードを他人に電子メールで送信しないこと。

• 作成したファイルやディレクトリのアクセス権は作成者に責任がある。権限を持たないユーザーによるファイルの読み取り、変更、およびディレクトリの内容の一覧表示、ディレクトリへの書き込みができないように許可が設定されていることを確認すること。

ユーザーアカウントと役割アカウントのセキュリティ

セキュリティ管理者役割は、各アカウントに対する最初のパスワードを指定します。セキュリティ管理者役割が選択したパスワードは、表 2-1 に示すようなトラステッドパス (TP) メニューでのパスワード変更で求められているものと同じ条件を満たす必要があります。これらの条件を表 2-1 に示します。

新規にローカルアカウントあるいは NIS+ 管理アカウントを作成するときに、管理役割は、一意のユーザー名を指定する必要があり、セキュリティ管理役割は、一意のユーザー ID を指定する必要があります。新規アカウントに名前や ID を選択するときは、管理者は、ユーザー名および関連 UID ともネットワーク上の他のものと重複しないことを確認しなければなりません。

システムが同一である限り、管理者は、ユーザー名やUID は、同じものを決して再使用しないようにする必要があります。ユーザー名や UID を再使用しないことによって、次のような混乱を防ぐことができます。

• 監査レコードの解析中、どのユーザーがどのアクションを実行しているか

• アーカイブファイルの復元中、どのユーザーがどのファイルを所有しているか

セキュリティ管理者役割は、いつでもどのアカウントのパスワードも変更できる権限があります (セキュリティ管理者役割のパスワードは例外で、「自分を変更することを許可」承認を必要とします)。パスワードが誰か他の者によって知られたかもしれないと思われるときは、セキュリティ管理者は、そのアカウントのパスワードを変更する必要があります。セキュリティ管理者は、他の誰にも知られない方法により、そのアカウントにパスワードを手渡す必要があります。

管理者は、何らかの作業を始める指示をユーザーに与えるときに電子メールは使うべきではなく、ユーザーには、管理者からのメールであることを装ってくる指示を信用しないように指示する必要があります。それによって、偽の電子メールでユーザーにパスワードをある値に変更するか公表する指示を与えて、そのパスワードを使用してログインを行い、システムに被害を与えるといった事態を防ぐことができます。

アカウントのためにパスワードの指定を行うセキュリティ管理者役割は、セキュリティ管理役割になることのできるアカウントが「常に開く」に設定されていることを確認しておく必要があります。そうすることによって、少なくとも 1 人のアカウントが常にログインできる状態で、セキュリティ管理役割になることができ、仮にアカウントのすべてがロック状態になってもそれらを再びオープンすることができるようになります。

情報の保護

管理者は、責任をもって機密性の高いファイル (暗号化されたパスワードを含む shadow(4) ファイル、ローカルな tsoluser(4) および tsolprof(4) データベース、監査トレール) の DAC および MAC 保護を行う必要があります。

NIS+ テーブルに適用される保護メカニズムは、Trusted Solaris システムで実施されているアクセス制御ポリシーの配下にないため、デフォルトの NIS+ テーブルの拡張やテーブルへのアクセスルールの変更は一切行うべきではありません。

パスワードの保護

ローカルファイルでは、DAC によりパスワードを見ることはできません。また、DAC と MAC によりパスワードが変更ができないように保護されています。ローカルアカウントのパスワードは、shadow (4) ファイルで保守されており、スーパーユーザーからしか読むことができません。

trusted4% ls -l /etc/shadow
-r------- 1 root

セキュリティ管理者役割は、DAC および MAC 属性が /etc/shadow ファイル用に変更されることのないようにしなければなりません。shadow ファイル上で保守をしなければならない属性を次の表に示します。

NIS+ passwd.org_dir テーブルのパスワードフィールドは、NIS+ アクセスがテーブル内のフィールドに限定されていることで保護されています。ユーザーや管理者が passwd.org_dir テーブルを見ようとしても、表示される符号化されたパスワードは、そのアカウントに属するものだけです。

次の例では、niscat(1) コマンドを起動したユーザーである roseanne は、自分自身のアカウントの符号化されたパスワードを見ることはできても、他のユーザーである ricc のパスワードフィールドには、*NP* と表示されるだけであることを示しています。

trusted5% whoami
roseanne
trusted6% niscat passwd.org_dir
. . .
ricc:*NP*:33333:10:Ric Cheshire:/home/ricc:/bin/csh:*NP*
roseanne:0dk1EW44:10:Roseanne Sullivan:/home/roseanne:/bin/csh:38442::::::
 

また、次の例に示すとおり、shadow.org_dir テーブルはありません。

trusted5% niscat shadow.org_dir
shadow.org_dir: Not Found, no such name

グループの作成

管理者は、ローカルシステムとネットワークに対して、どのグループも一意の GID を持っていることを確認しておく必要があります。

ユーザーの削除

システムからアカウントを削除するとき、管理者およびセキュリティ管理者は次のアクションを実行する必要があります。

• そのアカウントのホームディレクトリの削除

  必要に応じて、「MLD を削除するには」を参照してください。

• 削除したアカウントに属するプロセス、ジョブをすべて除去する。

  • そのアカウントが所有していたオブジェクトはすべて削除するか、他のユーザーに所有権を割り当てます。

  • そのユーザーが代表になってスケジュールが組まれていた at またはバッチ処理をすべて削除します。必要であれば、at(1) と crontab(1) のマニュアルページも参照してください。

• ユーザー (アカウント) 名および UID は決して再利用しない。

グループの削除

ローカルグループがシステムから削除されるとき、管理者役割は次のことを行う必要があります。

• 削除されたグループの GID の付いたオブジェクトをすべて削除するか、他のグループに割り当てる

• 削除されたグループに一次グループとして属していたユーザーの一次グループを他のグループに再割り当てする