ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Trusted Extensions 管理者の手順 Oracle Solaris 10 1/13 Information Library (日本語) |
3. Trusted Extensions 管理者として開始 (タスク)
4. Trusted Extensions システムのセキュリティー要件 (概要)
構成可能な Oracle Solaris セキュリティー機能
セキュリティー機能を構成するための Trusted Extensions インタフェース
Trusted Extensions による Oracle Solaris セキュリティーメカニズムの拡張
Solaris Trusted Extensions (CDE) のカスタマイズ
5. Trusted Extensions でのセキュリティー要件の管理 (タスク)
6. Trusted Extensions でのユーザー、権利、および役割 (概要)
7. Trusted Extensions でのユーザー、権利、役割の管理 (タスク)
8. Trusted Extensions でのリモート管理 (タスク)
9. Trusted Extensions と LDAP (概要)
10. Trusted Extensions でのゾーンの管理 (タスク)
11. Trusted Extensions でのファイルの管理とマウント (タスク)
13. Trusted Extensions でのネットワークの管理 (タスク)
14. Trusted Extensions でのマルチレベルメール (概要)
16. Trusted Extensions のデバイス (概要)
17. Trusted Extensions でのデバイス管理 (タスク)
18. Trusted Extensions での監査 (概要)
19. Trusted Extensions のソフトウェア管理 (タスク)
システムのセキュリティーを低下させないため、管理者は、パスワード、ファイル、および監査データを保護する必要があります。ユーザーは、各自の役目を果たせるようにトレーニングを受ける必要があります。評価された構成の要件に矛盾しないように、このセクションのガイドラインに従ってください。
各サイトのセキュリティー管理者は、ユーザーがセキュリティー手順のトレーニングを受けたか確認します。セキュリティー管理者は、新しい従業員に次の規則を伝え、既存の従業員に対してもこれらの規則への注意を定期的に喚起する必要があります。
他人に教えないでください。
パスワードを他人に知られると、権限のない人物が自分と同じ情報にアクセスできることになります。
自分のパスワードを書き留めたり、電子メールのメッセージに入力しないでください。
推測しにくいパスワードを選択してください。
パスワードを電子メールで他人に送信しないでください。
画面をロックせずに、またはログオフすることなく、コンピュータから離れないでください。
ユーザーに指示を出すときに管理者は電子メールを信頼していないことに留意してください。管理者からの指示が電子メールで届いた場合は、最初に必ず管理者に確認してください。
電子メールの送信者情報は偽造されている可能性があることに注意してください。
作成したファイルとディレクトリのアクセス権は各自に責任があるため、自分で作成したファイルやディレクトリのアクセス権が適切に設定されていることを確認してください。権限のないユーザーに対して、ファイルの読み取り、ファイルの変更、ディレクトリの内容の表示、またはディレクトリへの追加を許可しないでください。
管理者のサイトでは、ほかにも提案を追加できます。
電子メールを使用してユーザーに指示を伝えるのは安全な方法ではありません。
管理者を装って送信された電子メールの指示は信用しないように、ユーザーに通知してください。これにより、偽の電子メールメッセージによって、ユーザーがパスワードを特定の値に変更したり、パスワードを公表したりする可能性を避けることができます。結果的に、攻撃者が入手したパスワードでシステムにログインし被害を与えることを防止できます。
システム管理者役割は、新しいアカウントを作成するときに一意のユーザー名とユーザー ID を指定する必要があります。管理者は新しいアカウントの名前と ID を選択するときに、ユーザー名とユーザー名に関連付ける ID のどちらもネットワーク全体で重複がなく、以前に使用されていないことを確認する必要があります。
セキュリティー管理者役割は、各アカウントの初期パスワードを指定し、これを新しいアカウントのユーザーに伝える責任があります。パスワードを管理するときに次の情報を考慮してください。
セキュリティー管理者役割になることができるユーザーのアカウントは、アカウントがロックされないように構成してください。これにより、少なくとも 1 つのアカウントは常にログイン可能で、ほかのアカウントがすべてロックされた場合でも、セキュリティー管理者役割になってこれらのアカウントを再度開くことができるようにします。
新しいアカウントのユーザーにパスワードを伝えるときには、他人に知られないような方法を使用してください。
アカウントのパスワードを知るべきではない第三者に知られた疑いがある場合は、パスワードを変更してください。
そのシステムが存続している間は、一度使用したユーザー名やユーザー ID は再利用しないでください。
ユーザー名やユーザー ID を再利用しないことで、次のような混乱を避けることができます。
監査記録を分析するときに、だれがどのアクションを実行したかがわからなくなる。
アーカイブしたファイルを復元するときに、どのユーザーがどのファイルを所有しているかわからなくなる。
管理者は、セキュリティーが重要なファイルについて、任意アクセス制御 (DAC) と必須アクセス制御 (MAC) の保護を正しく設定して保守する責任があります。重要なファイルには、次のようなファイルが含まれます。
shadow ファイル – 暗号化されたパスワードが含まれます。shadow(4) を参照してください。
prof_attr データベース – 権利プロファイルの定義が含まれます。prof_attr(4) を参照してください。
exec_attr データベース – 権利プロファイルの一部であるコマンドとアクションが含まれます。exec_attr(4) を参照してください。
user_attr file – ローカルユーザーに割り当てられている権利プロファイル、特権、および承認が含まれます。user_attr(4) を参照してください。
Audit trail – 監査サービスによって収集された監査記録が含まれます。audit.log(4) を参照してください。
注意 - LDAP エントリの保護メカニズムは、Trusted Extensions ソフトウェアで実施されるアクセス制御ポリシーの影響を受けないため、デフォルトの LDAP エントリを拡張したり、LDAP のアクセス規則を変更してはいけません。 |
ローカルファイルでは、パスワードは DAC によって表示から保護され、DAC と MAC の両方によって修正から保護されます。ローカルアカウントのパスワードは /etc/shadow ファイルに保持されます。このファイルを読み取ることができるのはスーパーユーザーだけです。詳細は、shadow(4) のマニュアルページを参照してください。
システム管理者役割は、ローカルシステムとネットワークで、すべてのグループに一意のグループ ID (GID) が設定されていることを確認する必要があります。
ローカルグループをシステムから削除する場合、システム管理者役割は次のことを確認する必要があります。
削除するグループの GID を持つオブジェクトはすべて、削除するか、別のグループに割り当てる必要があります。
削除対象のグループをプライマリグループとして所有するユーザーはすべて、別のプライマリグループに再割り当てされる必要があります。
アカウントをシステムから削除する場合、システム管理者役割とセキュリティー管理者役割は、次の操作を実行する必要があります。
各ゾーンのアカウントのホームディレクトリを削除します。
削除するアカウントに属するプロセスまたはジョブをすべて削除します。
そのアカウントが所有するオブジェクトをすべて削除するか、または所有権を別のユーザーに割り当てます。
ユーザーの代わりに、予定されている at または batch ジョブをすべて削除します。詳細は、at(1) および crontab(1) のマニュアルページを参照してください。
絶対にユーザー (アカウント) 名またはユーザー ID を再利用しないでください。