アカウント管理
アカウント設計
商用、あるいは長期にわたりサーバの保守運用を想定しているのであれば適切に設計をしておく
共通設計
- 命名規則
システムで共通する命名規則を定めておく、ひと目や伝聞で聞いた際でも用途や目的がわかるようわかりやすい命名がいい
プロジェクト固有の識別子を必ず付け、他プロジェクトで利用しているユーザの再利用や混在が無いように注意
また命名規則は絶対ではなく、ユーザー用途や運用の中で柔軟性を持てるようにしてお - ID
サーバ上で意識される UID/GIF は全サーバで統一しておくこと
サーバ間でのファイル連携やサーバ上作業においてパーミッションの統一性、管理を行ないやすいようにしておく
グループ設計
なにかの作業や権限、アクセス制御を行う場合は基本的にはグループ単位で制御を行なうように考える
例えば SSH の許可ユーザーを制限したい場合、 sshd_config の AllowUser ではなく AllowGroup で管理し運用を楽にする
そのために SSH 接続を許可するグループ等を作成し、そのグループにユーザーを所属させる運用をする
同様に管理者権限への昇格許可 wheel グループ、 su / sudo 上で制御するグループ等を定義検討する
- グループの定義例
| group | gid | example |
|---|---|---|
| OS system groups | 0 ~ 999 | Group reserved by OS |
| Application groups | 1000 ~ 1999 | Additional application group |
| OS maintenance groups | 10000 ~ 10999 | |
| Application maintenance groups | 11000 ~ 11999 | |
| Content maintenance groups | 12000 ~ 12999 |
ユーザー設計
- ログインディレクトリ
ユーザーがOSにログインした際のホームディレクトリを定義する
利用用途に応じて適切な権限のディレクトリをホームディレクトリとし、アクセス権限や移動権限を制御しやすくする
OSログインを行うユーザーには必ず個別のホームディレクトリを用意しておき、環境ファイルや history ファイルなどのユーザー環境ファイルが重複しないようようにすること - 管理者ユーザーの直接ログイン
管理者権限をもつユーザーからの直接ログインの可否を定義する
開発環境やインターネット公開されていない環境等を除き、基本的には管理者ユーザーの直接ログインは行わないようにし、 一般権限ユーザーがログイン後 su / sudo 等で権限昇格するように運用すること - 認証方法
ユーザーのOSアクセスを行う際の認証方法をシステム全体で統一しておく - ユーザー、認証のロック
複数回の認証失敗を行った場合に対象のユーザーをロックするか、パスワードを無効化するか、ロックはいつまで行うかなどを定義する
Redhat / CentOS では標準で Pam により認証失敗回数によるユーザーロック機能をサポートする - パスワードセキュリティ
パスワードに求める文字種、文字数制限をシステム全体で統一しておく
パスワードの定期変更を求める場合、パスワード履歴は何世代保持させるか（前回と似たパスワードの繰り返し利用を防ぐため）
パスワードサイクルは何日間隔にするかも定義、統一しておく
標準の機能ではパスワードサイクルの管理を行う機能は無いため、別途システムの導入等を検討する - ユーザーの定義例
| user | uid | example |
|---|---|---|
| OS system users | 0 ~ 999 | Group reserved by OS |
| Application users | 1000 ~ 1999 | Additional application users |
| OS maintenance users | 10000 ~ 10999 | |
| Application maintenance users | 11000 ~ 11999 | |
| Content maintenance users | 12000 ~ 12999 |