AlmaLinux 9 のサーバーを運用するうえで、ユーザーとグループの管理は避けて通れない基本操作です。本記事では、ユーザーの追加・変更・削除、グループ管理、パスワードポリシー、sudo による特権管理、UID/GID の採番ルール、アカウントのロック・無効化、umask の設定まで、企業のサーバー運用チームが日常的に扱う作業を実行例つきでまとめています。入社1〜3年目のインフラエンジニアが、現場でそのまま使えるリファレンスとして活用できる構成です。
コマンド早見表
| やりたいこと | コマンド |
|---|---|
| ユーザー追加 | useradd -m -c ‘GECOS’ -s /bin/bash -G wheel ユーザー名 |
| ユーザー情報変更 | usermod -aG グループ ユーザー名 |
| ユーザー削除 | userdel -r ユーザー名 |
| グループ追加 | groupadd -g GID グループ名 |
| グループ名変更 | groupmod -n 新名 旧名 |
| グループ削除 | groupdel グループ名 |
| パスワード設定 | passwd ユーザー名 |
| パスワード有効期限設定 | chage -M 90 -W 14 -I 30 ユーザー名 |
| パスワード有効期限確認 | chage -l ユーザー名 |
| sudo 権限編集 | visudo |
| 自分の sudo 権限確認 | sudo -l |
| ユーザー情報確認 | id ユーザー名 |
| ログイン履歴 | last / lastlog |
| アカウントロック | passwd -l ユーザー名 |
| アカウントアンロック | passwd -u ユーザー名 |
| ロック状態確認 | passwd -S ユーザー名 |
| umask 確認 | umask / umask -S |
| 孤立ファイル捜索 | find / -nouser -o -nogroup |
前提条件
| 項目 | 値 |
|---|---|
| OS | AlmaLinux 9.6(Sage Margay) |
| カーネル | 5.14.0-570.12.1.el9_6.x86_64 |
| インストールタイプ | 最小限のインストール(Minimal Install) |
| 実行ユーザー | developer(UID 1000、wheel グループ所属、sudo 権限あり) |
| プロンプト記号 | # は root 権限での実行、$ は一般ユーザーでの実行 |
1. ユーザー管理の仕組み
Linux のユーザー管理は、4 つの設定ファイルで構成されています。コマンドを実行する前に、これらのファイルの構造を理解しておくと、トラブル発生時に原因を特定しやすくなります。
/etc/passwd
すべてのユーザーアカウント情報を保持するファイルです。各行が 1 ユーザーに対応し、コロン区切りで 7 つのフィールドがあります。
実行コマンド:
$ getent passwd developer
実行結果:
developer:x:1000:1000:developer:/home/developer:/bin/bash
| フィールド | 値の例 | 意味 |
|---|---|---|
| ユーザー名 | developer | ログイン名 |
| パスワード | x | x は /etc/shadow にハッシュが格納されていることを示す |
| UID | 1000 | ユーザー ID(数値) |
| GID | 1000 | プライマリグループ ID |
| GECOS | developer | コメント欄(氏名や連絡先を記載する。GECOS はかつての汎用電子計算機互換オペレーティングシステムの略称に由来する) |
| ホームディレクトリ | /home/developer | ログイン時のカレントディレクトリ |
| ログインシェル | /bin/bash | ログイン時に起動されるシェル |
/etc/passwd の先頭には、OS インストール時に作成されるシステムアカウントが並んでいます。
実行コマンド:
$ head -5 /etc/passwd
実行結果:
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
root の UID は 0 で、すべてのシステム操作が可能な特権アカウントです。bin、daemon、adm などのシステムアカウントは、ログインシェルが /sbin/nologin に設定されており、対話的なログインはできません。
/etc/shadow
パスワードのハッシュ値と有効期限情報を保持するファイルです。root のみ読み取り可能で、一般ユーザーからは閲覧できません。
developer ユーザーの shadow エントリ例を示します。
developer:$6$edCdSYECF2n2dE7e$k3mQF0GrSiOPHuc.i4HwI22q4KK29UUBklcQYgtn2ff7i7O3sYSn7p9QpnvjqN3aFP5T6wZHLSzk9sBW1Ca6o.::0:99999:7:::
| フィールド | 意味 |
|---|---|
| $6$… | SHA-512($6$)でハッシュ化されたパスワード |
| !!(2つの感嘆符) | パスワード未設定(ログイン不可) |
| *(アスタリスク) | アカウントが無効化されている |
| 空欄 | パスワードなしでログイン可能(セキュリティ上危険) |
コロンで区切られた残りのフィールドは、最終パスワード変更日(エポックからの日数)、最短変更間隔、最長有効日数、警告日数、無効化猶予日数、アカウント有効期限、予約フィールドです。
/etc/group
グループ情報を保持するファイルです。各行が 1 グループに対応し、コロン区切りで 4 つのフィールドがあります。
実行コマンド:
$ getent group wheel
実行結果:
wheel:x:10:developer
| フィールド | 値の例 | 意味 |
|---|---|---|
| グループ名 | wheel | グループの名前 |
| パスワード | x | 通常は使用しない(x で固定) |
| GID | 10 | グループ ID(数値) |
| メンバーリスト | developer | このグループに所属するユーザー(カンマ区切り) |
メンバーリストに表示されるのは補助グループとして所属しているユーザーです。プライマリグループとしてのみ所属しているユーザーはここには表示されません。
/etc/login.defs
ユーザー作成時のデフォルト値やパスワードポリシーの初期値を定義するファイルです。useradd コマンドや passwd コマンドがこの設定を参照します。
AlmaLinux 9 のデフォルト設定値は以下の通りです。
UMASK 022
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_WARN_AGE 7
UID_MIN 1000
UID_MAX 60000
GID_MIN 1000
GID_MAX 60000
CREATE_HOME yes
| 設定項目 | デフォルト値 | 意味 |
|---|---|---|
| UID_MIN | 1000 | 一般ユーザーに割り当てる UID の最小値 |
| UID_MAX | 60000 | 一般ユーザーに割り当てる UID の最大値 |
| PASS_MAX_DAYS | 99999 | パスワードの最長有効日数(99999 は実質無期限) |
| PASS_MIN_DAYS | 0 | パスワード変更後、次に変更できるまでの最短日数 |
| PASS_WARN_AGE | 7 | パスワード期限切れの何日前から警告するか |
| CREATE_HOME | yes | useradd 時にホームディレクトリを自動作成するか |
| UMASK | 022 | ユーザー作成時のホームディレクトリに適用される umask 値 |
PASS_MAX_DAYS のデフォルトは実質無期限
AlmaLinux 9 のデフォルトでは PASS_MAX_DAYS が 99999(約273年)に設定されています。企業の運用では、セキュリティポリシーに従い 90 日程度に変更するのが一般的です。変更方法は第 4 章で解説します。
2. ユーザーの追加・変更・削除
useradd でユーザーを追加する
新しいユーザーを作成する基本コマンドです。企業の運用では、GECOS フィールドに氏名を記載し、必要なグループへの所属も同時に指定します。
実行コマンド:
# useradd -m -c 'Test User 01' -s /bin/bash -G wheel testuser01
| オプション | 意味 |
|---|---|
| -m | ホームディレクトリを作成する(/etc/login.defs の CREATE_HOME=yes なら省略可だが、明示推奨) |
| -c ‘Test User 01’ | GECOS フィールドに氏名やコメントを設定する |
| -s /bin/bash | ログインシェルを指定する |
| -G wheel | 補助グループに wheel を追加する(sudo 権限が必要な場合) |
作成結果を確認します。
実行コマンド:
$ id testuser01
実行結果:
uid=1001(testuser01) gid=1001(testuser01) groups=1001(testuser01),10(wheel)
UID 1001 が自動採番され、プライマリグループとして testuser01(GID 1001)が作成され、補助グループとして wheel(GID 10)に追加されています。
useradd のデフォルト値と /etc/skel
useradd コマンドのデフォルト設定は useradd -D で確認できます。この設定は /etc/default/useradd に保存されています。
実行コマンド:
# useradd -D
実行結果:
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes
/etc/skel は、新規ユーザーのホームディレクトリにコピーされるテンプレートディレクトリです。企業で統一した .bashrc や .vimrc を配布したい場合は、/etc/skel にファイルを配置しておきます。
usermod でユーザー情報を変更する
既存ユーザーの属性を変更するコマンドです。最も多い操作は、補助グループの追加です。
実行コマンド:
# usermod -aG wheel testuser01
-a を付け忘れると既存の補助グループがすべて削除される
usermod -G wheel testuser01 のように -a(append)を付けずに実行すると、testuser01 の補助グループが wheel のみに上書きされます。それまで所属していた他の補助グループはすべて外れます。グループ追加時は必ず -aG をセットで使用してください。誤って実行した場合は、usermod -aG グループ1,グループ2 ユーザー名 で再設定します。
ログインシェルの変更は -s オプションで行います。サービスアカウントなど対話的なログインが不要なユーザーには /sbin/nologin を設定します。
実行コマンド:
# usermod -s /sbin/nologin testuser01
切り戻し方法:
# usermod -s /bin/bash testuser01
ホームディレクトリの変更は -d オプションと -m オプションを組み合わせます。-m を付けると、旧ディレクトリの内容が新ディレクトリに移動されます。
実行コマンド:
# usermod -d /home/testuser01_new -m testuser01
切り戻し方法:
# usermod -d /home/testuser01 -m testuser01
userdel でユーザーを削除する
ユーザーを削除する前に、必ずホームディレクトリのバックアップを取得してください。削除後はデータを復元できません。
バックアップの実行コマンド:
# tar czf /backup/testuser01_home_$(date +%Y%m%d).tar.gz /home/testuser01
ユーザー削除の実行コマンド:
# userdel -r testuser01
-r オプションを付けると、ホームディレクトリとメールスプールも同時に削除されます。-r を付けずに削除すると、ホームディレクトリが残り、所有者のいないファイル(孤立ファイル)になります。
孤立ファイルの捜索
ユーザー削除後に、ファイルシステム上に所有者のいないファイルが残っていないか確認します。NFS 共有領域やアプリケーションのデータディレクトリに残存していることがあります。
実行コマンド:
# find / -nouser -o -nogroup 2>/dev/null
出力があった場合は、ファイルの内容を確認したうえで、必要に応じて所有者を変更するか削除してください。
3. グループの追加・変更・削除
Linux では、ファイルやディレクトリのアクセス権をグループ単位で制御します。プロジェクトチームやアプリケーション単位でグループを作成し、所属メンバーを管理するのが一般的な運用です。
プライマリグループと補助グループの違い
Linux のユーザーには必ず 1 つのプライマリグループと、0 個以上の補助グループが割り当てられます。
- プライマリグループ:ユーザーがファイルを作成したとき、そのファイルのグループ所有者になるグループ。/etc/passwd の GID フィールドで指定される
- 補助グループ:追加のアクセス権を得るために所属するグループ。/etc/group のメンバーリストに記載される
groupadd でグループを追加する
実行コマンド:
# groupadd -g 1001 appteam
-g オプションで GID を明示的に指定しています。複数サーバーで GID を統一する場合は、必ず GID を指定して作成します。GID を省略すると、システムが自動的に次の空き番号を割り当てます。
作成結果を確認します。
実行コマンド:
$ getent group appteam
実行結果:
appteam:x:1001:
groupmod でグループ名を変更する
実行コマンド:
# groupmod -n devteam appteam
実行結果:
$ getent group devteam
実行結果:
devteam:x:1001:
GID は変わらずグループ名のみが変更されます。ファイルのアクセス権は GID で管理されているため、グループ名の変更によるアクセス権への影響はありません。
切り戻し方法:
# groupmod -n appteam devteam
groupdel でグループを削除する
実行コマンド:
# groupdel devteam
プライマリグループに設定されているユーザーがいると削除できない
あるグループがいずれかのユーザーのプライマリグループに設定されている場合、groupdel は「cannot remove the primary group of user」エラーで失敗します。先にそのユーザーのプライマリグループを別のグループに変更(usermod -g 新グループ ユーザー名)するか、ユーザー自体を削除してから実行してください。
4. パスワード管理とポリシー設定
passwd でパスワードを設定する
ユーザー作成直後はパスワードが設定されていないため、ログインできません。passwd コマンドでパスワードを設定します。
実行コマンド:
# passwd testuser01
対話形式で新しいパスワードの入力を 2 回求められます。
chage でパスワード有効期限を設定する
企業のセキュリティポリシーでは、パスワードの定期変更を求められるのが一般的です。chage コマンドで個別ユーザーの有効期限を設定します。
実行コマンド:
# chage -M 90 -W 14 -I 30 testuser01
| オプション | 意味 |
|---|---|
| -M 90 | パスワードの最長有効日数を 90 日に設定する |
| -W 14 | 期限切れの 14 日前から警告メッセージを表示する |
| -I 30 | 期限切れ後 30 日間はログイン時にパスワード変更を強制し、30 日を過ぎるとアカウントが無効化される |
設定内容を確認します。
実行コマンド:
$ chage -l developer
実行結果:
最終パスワード変更日 :なし
パスワード期限: : なし
パスワード無効化中 : なし
アカウント期限切れ : なし
パスワードが変更できるまでの最短日数 : 0
パスワードを変更しなくてよい最長日数 : 99999
パスワード期限が切れる前に警告される日数 : 7
上記は変更前の developer ユーザーの例です。PASS_MAX_DAYS が 99999 のため「パスワード期限: なし」と表示されています。
初回ログイン時にパスワード変更を強制する
新規ユーザーに初期パスワードを設定した後、初回ログイン時にパスワードの変更を強制する運用が一般的です。
実行コマンド:
# chage -d 0 testuser01
-d 0 は「最終パスワード変更日を 1970年1月1日(エポック)に設定する」という意味です。これにより、次回ログイン時にパスワードの有効期限切れと判定され、変更を求められます。
/etc/security/pwquality.conf でパスワードの複雑性を設定する
pwquality.conf は、PAM(Pluggable Authentication Modules:認証処理をモジュール化する仕組み)の pam_pwquality モジュールが参照する設定ファイルです。パスワードの最小文字数や、含めるべき文字種を制御します。
AlmaLinux 9 のデフォルトでは、すべての設定がコメントアウトされています。企業のセキュリティ要件に合わせて以下のように設定します。
実行コマンド:
# vi /etc/security/pwquality.conf
設定内容:
minlen = 12
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
| 設定項目 | 値 | 意味 |
|---|---|---|
| minlen | 12 | パスワードの最小文字数を 12 文字にする |
| dcredit | -1 | 数字を最低 1 文字含むことを必須にする(負の値は必須文字数) |
| ucredit | -1 | 大文字を最低 1 文字含むことを必須にする |
| lcredit | -1 | 小文字を最低 1 文字含むことを必須にする |
| ocredit | -1 | 記号を最低 1 文字含むことを必須にする |
切り戻し方法:各行をコメントアウト(行頭に # を追加)すると、デフォルト設定に戻ります。
/etc/login.defs でパスワードポリシーの初期値を変更する
/etc/login.defs の設定は、新規ユーザー作成時の初期値として適用されます。既存ユーザーには影響しません。既存ユーザーの設定を変更するには chage コマンドを使用してください。
企業での一般的な設定例を示します。
PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_WARN_AGE 14
| 設定項目 | 推奨値 | 理由 |
|---|---|---|
| PASS_MAX_DAYS | 90 | 90 日ごとのパスワード変更を強制する |
| PASS_MIN_DAYS | 1 | パスワード変更直後に再変更して元に戻す行為を防止する |
| PASS_WARN_AGE | 14 | 期限切れの 14 日前から警告を表示し、変更忘れを防ぐ |
5. sudo による特権管理
sudo は、一般ユーザーが root 権限でコマンドを実行するための仕組みです。初期設定編では「wheel グループに追加して sudo を有効化する」基本操作を扱いましたが、本章では「最小権限の原則に基づいた sudo 設計」を解説します。
visudo で sudoers を編集する
sudoers ファイルの編集には必ず visudo コマンドを使用します。visudo は保存時に構文チェックを行い、文法エラーがあると警告を表示して保存をキャンセルします。vi で直接 /etc/sudoers を編集すると、構文エラーがあってもそのまま保存され、sudo が使用不能になるリスクがあります。
実行コマンド:
# visudo
AlmaLinux 9 のデフォルトの sudoers 設定(有効行の抜粋)は以下の通りです。
Defaults !visiblepw
Defaults always_set_home
Defaults match_group_by_gid
Defaults always_query_group_plugin
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
%wheel ALL=(ALL) ALL は「wheel グループのメンバーは、すべてのホストで、すべてのユーザーとして、すべてのコマンドを実行できる」という意味です。
sudoers の構文エラーは sudo 不能を引き起こす
visudo を使わずに /etc/sudoers を直接編集して構文エラーを書き込むと、すべてのユーザーが sudo を実行できなくなります。SSH 経由のリモート接続で作業中にこの状態になると、root 権限を取得する手段がなくなる可能性があります。回復手順は第 13 章「トラブルシューティング」で解説します。
/etc/sudoers.d/ で個別設定を管理する
/etc/sudoers を直接変更する代わりに、/etc/sudoers.d/ ディレクトリに個別のファイルを配置する方法が推奨されます。OS アップデート時に /etc/sudoers が上書きされても、/etc/sudoers.d/ 内のファイルは保持されるためです。
実行コマンド:
# visudo -f /etc/sudoers.d/appteam
設定内容の例:
%appteam ALL=(ALL) /usr/bin/systemctl restart httpd, /usr/bin/systemctl restart nginx
上記の設定では、appteam グループのメンバーに httpd と nginx の再起動のみを許可しています。この設定により、アプリケーションチームが Web サーバーのデプロイ後に自分たちで再起動できるようになりますが、それ以外の root 操作は許可されません。
NOPASSWD の限定使用
NOPASSWD を設定すると、sudo 実行時にパスワード入力を求められなくなります。監視ツール(Zabbix Agent や Nagios NRPE)がシステム情報を取得する際に使用する場面がありますが、一般ユーザーへの安易な適用はセキュリティリスクになります。
監視ツール用の設定例:
zabbix ALL=(ALL) NOPASSWD: /usr/sbin/dmidecode, /usr/bin/systemctl status *
NOPASSWD を ALL に設定してはいけない
NOPASSWD: ALL を設定すると、そのユーザーのアカウントが侵害された場合に攻撃者がパスワードなしで root 権限を取得できます。NOPASSWD は必要最小限のコマンドに限定し、設定した理由をコメントで残してください。
sudo -l で権限を確認する
自分に付与されている sudo 権限を確認するコマンドです。
実行コマンド:
$ sudo -l
実行結果(wheel グループ所属の場合):
ユーザー developer は alma-main 上で コマンドを実行できます:
(ALL) ALL
sudo のログを確認する
sudo の実行ログは、誰がいつどのコマンドを root 権限で実行したかを追跡するために重要です。監査対応やインシデント調査で必要になります。
実行コマンド:
# journalctl _COMM=sudo --no-pager -n 20
/var/log/secure にも sudo の実行ログが記録されます。
実行コマンド:
# grep sudo /var/log/secure
6. UID/GID の統一管理
複数のサーバーを運用する環境では、UID と GID を全サーバーで統一しておくことが重要です。特に NFS(Network File System)で共有ディレクトリを使用する場合、UID/GID が不一致だと、別のユーザーのファイルにアクセスできてしまう、あるいはアクセスが拒否されるといった問題が発生します。
UID の採番ルール(企業での管理例)
/etc/login.defs で UID_MIN=1000、UID_MAX=60000 が設定されています。この範囲内で、組織の運用ルールに基づいた採番体系を設計します。
| UID 範囲 | 用途 |
|---|---|
| 0 | root |
| 1〜999 | システムアカウント(useradd -r で作成) |
| 1000〜1999 | 正社員 |
| 2000〜2999 | 協力会社・外部パートナー |
| 3000〜3999 | サービスアカウント(アプリケーション用) |
| 60001〜65534 | 予約(使用しない) |
この採番ルールを UID 台帳(スプレッドシートやCMDB)で管理し、新規ユーザー作成時に台帳から次の番号を払い出します。
UID の棚卸し
定期的に全ユーザーの UID を確認し、台帳との整合性を検証します。
実行コマンド:
$ getent passwd | awk -F: '{print $3,$1}' | sort -n
実行結果(抜粋):
0 root
1 bin
2 daemon
3 adm
4 lp
74 sshd
996 chrony
997 polkitd
998 sssd
999 systemd-coredump
1000 developer
1001 testuser01
UID 順にソートされた一覧が表示されます。台帳と突き合わせて、不明なアカウントが存在しないか確認してください。
7. ユーザー情報の確認コマンド
id(UID・GID・所属グループの確認)
実行コマンド:
$ id developer
実行結果:
uid=1000(developer) gid=1000(developer) groups=1000(developer),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
UID、プライマリ GID、所属する全グループ、SELinux コンテキストが 1 行で確認できます。
whoami / groups
実行コマンド:
$ whoami
実行結果:
developer
実行コマンド:
$ groups developer
実行結果:
developer : developer wheel
whoami は現在の実行ユーザー名を表示します。su や sudo で別のユーザーに切り替えた際に、今どのユーザーとして操作しているかを確認するのに使います。groups は指定ユーザーの所属グループを表示します。
getent(LDAP 環境でも使える統合検索)
getent は、/etc/passwd や /etc/group だけでなく、LDAP(Lightweight Directory Access Protocol:ディレクトリサービスにアクセスするためのプロトコル)や SSSD 経由のユーザー情報も統合的に検索できます。企業では Active Directory 連携で LDAP 認証を導入しているケースがあり、その場合は cat /etc/passwd では LDAP ユーザーが表示されません。getent を使えば、ローカルアカウントと LDAP アカウントの両方を取得できます。
実行コマンド:
$ getent passwd developer
実行結果:
developer:x:1000:1000:developer:/home/developer:/bin/bash
実行コマンド:
$ getent group wheel
実行結果:
wheel:x:10:developer
last / lastlog(ログイン履歴)
last はログイン・ログアウトの履歴を新しい順に表示します。lastlog はユーザーごとの最終ログイン日時を表示します。
実行コマンド:
$ last -n 10
実行コマンド:
$ lastlog
長期間ログインがないアカウントは、退職や異動で不要になったアカウントの可能性があります。定期的な棚卸し(第 12 章で解説)の際に確認してください。
w(現在ログイン中のユーザー)
実行コマンド:
$ w
現在ログイン中のユーザー、ログイン元、実行中のコマンドが表示されます。メンテナンス作業前に、他のユーザーがログインしていないか確認する際に使用します。
8. su と sudo の使い分け
su と su – の違い
su と su -(ハイフン付き)は動作が異なります。ハイフンを付けると、対象ユーザーのログインシェルとして起動し、環境変数や PATH が正しく設定されます。
| コマンド | 動作 | 環境変数 |
|---|---|---|
| su root | root に切り替えるが、現在のシェル環境を引き継ぐ | 元のユーザーの PATH や HOME が残る |
| su – root | root のログインシェルとして起動する | root の PATH、HOME、LANG などが設定される |
su でハイフンを付け忘れると PATH が通らないことがある
su root では /sbin や /usr/sbin が PATH に含まれない場合があり、systemctl や firewall-cmd などの管理コマンドが「command not found」になることがあります。root に切り替える際は su - を使用してください。
su と sudo の比較
| 項目 | su – | sudo コマンド | sudo -i |
|---|---|---|---|
| 必要なパスワード | root のパスワード | 自分のパスワード | 自分のパスワード |
| 監査ログ | su の実行のみ記録される | 実行したコマンドが記録される | シェル起動が記録される |
| 権限の範囲 | root の全権限 | sudoers で許可されたコマンドのみ | root の全権限 |
企業の運用では、sudo 経由での操作が推奨されます。理由は以下の 2 点です。
- sudo は実行されたコマンドを /var/log/secure に記録するため、「誰が何を実行したか」を追跡できる
- root パスワードを複数人で共有する必要がなく、パスワード漏洩のリスクを低減できる
9. アカウントのロック・無効化
退職者のアカウント停止や、セキュリティインシデント発生時のアカウント緊急ロックなど、アカウントを無効化する場面は頻繁にあります。方法によって無効化の範囲が異なるため、状況に応じて使い分ける必要があります。
passwd -l / usermod -L でパスワードをロックする
実行コマンド:
# passwd -l testlock
ロック状態を確認します。
実行コマンド:
# passwd -S testlock
実行結果:
testlock LK 2026-03-24 0 99999 7 -1 (パスワードはロック済み。)
LK はパスワードがロックされている状態を示します。その他のステータスは以下の通りです。
| ステータス | 意味 |
|---|---|
| PS | パスワードが設定されている(通常の状態) |
| LK | パスワードがロックされている |
| NP | パスワードが設定されていない |
passwd -u / usermod -U でアンロックする
実行コマンド:
# passwd -u testlock
usermod -L と usermod -U も同じ機能ですが、/etc/shadow のパスワードハッシュ先頭に ! を付加・除去する点は同一です。
パスワードロックだけでは SSH 鍵認証は止まらない
passwd -l や usermod -L はパスワード認証をロックするだけです。SSH 公開鍵認証が設定されている場合、鍵認証によるログインは引き続き可能です。SSH 鍵認証も含めてログインを完全に禁止するには、ログインシェルを変更してください。
usermod -s /sbin/nologin でログインを完全に禁止する
ログインシェルを /sbin/nologin に変更すると、パスワード認証・鍵認証を問わず、対話的なログインが拒否されます。
実行コマンド:
# usermod -s /sbin/nologin testlock
切り戻し方法:
# usermod -s /bin/bash testlock
chage -E でアカウントの有効期限を設定する
契約期間が決まっている外部パートナーのアカウントには、あらかじめ有効期限を設定しておきます。
実行コマンド:
# chage -E 2026-06-30 testlock
2026年6月30日を過ぎると、このアカウントは自動的に無効化されます。
有効期限を解除する切り戻し方法:
# chage -E -1 testlock
10. システムアカウントとサービスアカウント
アプリケーションやデーモンプロセスを実行するための専用アカウントを「サービスアカウント」と呼びます。root でアプリケーションを実行すると、脆弱性を突かれた場合にシステム全体が侵害されるリスクがあるため、最小権限の原則に基づいて専用のアカウントで実行します。
サービスアカウントの作成
実行コマンド:
# useradd -r -s /sbin/nologin -d /opt/myapp -M myappsvc
| オプション | 意味 |
|---|---|
| -r | システムアカウントとして作成する(UID が 1000 未満になる) |
| -s /sbin/nologin | 対話的なログインを禁止する |
| -d /opt/myapp | ホームディレクトリのパスを指定する(実際のディレクトリは作成しない) |
| -M | ホームディレクトリを作成しない |
作成結果を確認します。
実行コマンド:
$ id myappsvc
実行結果:
uid=995(myappsvc) gid=995(myappsvc) groups=995(myappsvc)
実行コマンド:
$ getent passwd myappsvc
実行結果:
myappsvc:x:995:995::/opt/myapp:/sbin/nologin
UID が 995(1000 未満)で割り当てられ、ログインシェルが /sbin/nologin に設定されていることが確認できます。
代表的なシステムアカウント
AlmaLinux 9 にデフォルトで作成されるシステムアカウントの一部を紹介します。
| アカウント名 | 用途 |
|---|---|
| root | システム管理者(UID 0) |
| nobody | 権限を持たないアカウント。NFS やプロセスの権限分離に使用される |
| apache | Apache HTTP Server の実行ユーザー(httpd パッケージインストール時に作成) |
| sshd | SSH デーモンの権限分離に使用されるアカウント |
| chrony | NTP クライアント(chronyd)の実行ユーザー |
| polkitd | PolicyKit 認可デーモンの実行ユーザー |
11. umask によるデフォルトパーミッション
umask(user file-creation mode mask)は、新規ファイルやディレクトリを作成する際に「付与しないパーミッション」を指定する値です。
現在の umask 値を確認する
実行コマンド:
$ umask
実行結果:
0022
実行コマンド:
$ umask -S
実行結果:
u=rwx,g=rx,o=rx
umask -S はシンボリック形式で「結果的に付与されるパーミッション」を表示します。
umask の計算方法
ファイルとディレクトリではベースパーミッションが異なります。
| 対象 | ベース | umask 0022 の場合 | 結果 |
|---|---|---|---|
| ファイル | 0666 | 0666 – 0022 | 0644(rw-r–r–) |
| ディレクトリ | 0777 | 0777 – 0022 | 0755(rwxr-xr-x) |
AlmaLinux 9 のデフォルト umask は 0022 です。この設定では、新規ファイルは所有者が読み書き可能、グループとその他は読み取りのみです。
umask の設定箇所
umask はシェルの起動時に読み込まれる設定ファイルで定義します。
| 設定ファイル | 適用範囲 |
|---|---|
| /etc/profile | 全ユーザーのログインシェル |
| /etc/bashrc | 全ユーザーの bash 起動時 |
| ~/.bashrc | 個別ユーザーの bash 起動時 |
企業セキュリティでの umask 変更
セキュリティ要件が厳しい環境では、umask を 0027 や 0077 に変更します。
| umask | ファイル | ディレクトリ | 用途 |
|---|---|---|---|
| 0022 | 0644(rw-r–r–) | 0755(rwxr-xr-x) | デフォルト(一般的な共有環境) |
| 0027 | 0640(rw-r—–) | 0750(rwxr-x—) | その他ユーザーからの読み取りを禁止 |
| 0077 | 0600(rw——-) | 0700(rwx——) | 所有者のみアクセス可能(最も厳格) |
全ユーザーに適用する場合は /etc/profile に記載します。
設定例:
umask 0027
切り戻し方法:該当行を umask 0022 に変更するか、行を削除してください。変更後、新しいシェルセッションから有効になります。
12. アカウントライフサイクル(企業運用チェックリスト)
企業でのアカウント管理は、入社から退職までのライフサイクル全体をカバーする運用設計が必要です。以下に、各フェーズで実施する作業をまとめます。
入社時
- UID 台帳から次の UID を払い出す
- useradd で UID を指定してアカウントを作成する
- 初期パスワードを設定し、
chage -d 0で初回ログイン時の変更を強制する - 必要なグループに追加する(
usermod -aG) - chage でパスワード有効期限を設定する
入社時のコマンド実行例:
# useradd -m -u 1002 -c 'Tanaka Taro' -s /bin/bash -G wheel tanaka
# passwd tanaka
# chage -d 0 -M 90 -W 14 -I 30 tanaka
異動時
- 新しい部署のグループに追加する(
usermod -aG 新グループ ユーザー名) - 旧部署のグループから外す(
gpasswd -d ユーザー名 旧グループ) - sudo 権限の見直し(/etc/sudoers.d/ の該当ファイルを修正)
グループからの除外コマンド:
# gpasswd -d tanaka old-team
退職時
- パスワードをロックする(
passwd -l ユーザー名) - ログインシェルを変更する(
usermod -s /sbin/nologin ユーザー名) - ホームディレクトリをバックアップする
- 一定期間(社内規定に従い 30〜90 日程度)経過後にアカウントを削除する
退職時のコマンド実行例:
# passwd -l tanaka
# usermod -s /sbin/nologin tanaka
# tar czf /backup/tanaka_home_$(date +%Y%m%d).tar.gz /home/tanaka
定期棚卸し(月次または四半期)
以下のコマンドを定期的に実行し、不要なアカウントや異常な状態がないか確認します。
| 確認項目 | コマンド |
|---|---|
| 長期間ログインのないアカウント | lastlog |
| 孤立ファイルの有無 | find / -nouser -o -nogroup 2>/dev/null |
| パスワードのロック状態 | passwd -S ユーザー名 |
| UID 一覧の確認 | getent passwd | awk -F: ‘{print $3,$1}’ | sort -n |
13. トラブルシューティング
usermod -G でグループが消えた
症状:usermod -G wheel testuser01 を実行した後、testuser01 が以前所属していたグループ(例:appteam、devteam)からすべて外れていた。
原因:-G のみで -a(append)を付けなかったため、補助グループが指定したグループのみに上書きされた。
対処方法:元のグループをすべて指定して再設定する。
実行コマンド:
# usermod -aG wheel,appteam,devteam testuser01
予防策:グループ追加時は必ず usermod -aG を使用する。
userdel で「user is currently used by process」が表示される
症状:userdel testuser01 を実行すると「userdel: user testuser01 is currently used by process XXXX」エラーが発生する。
原因:対象ユーザーが実行中のプロセスが存在する。ログインセッションが残っている、またはバックグラウンドプロセスが動作中の場合に発生する。
対処方法:対象ユーザーのプロセスを確認し、停止してから削除する。
実行コマンド:
# ps -u testuser01
プロセスを確認した後、対象プロセスを停止します。
実行コマンド:
# kill プロセスID
プロセス停止後に userdel を再実行してください。
sudoers の構文エラーで sudo が使えなくなった
症状:sudo を実行すると「syntax error」や「no valid sudoers sources found」が表示され、すべてのユーザーで sudo が使用不能になった。
原因:/etc/sudoers または /etc/sudoers.d/ 内のファイルに構文エラーがある。visudo を使わずに直接ファイルを編集した場合に発生する。
対処方法:
- 別の TTY(端末)から root で直接ログインする(Ctrl+Alt+F2 など、物理コンソールまたは仮想コンソール)
- root でログイン後、visudo を実行して構文エラーを修正する
- リモート接続のみの環境で root ログインが無効な場合は、サーバーの管理コンソール(ILO、iDRAC、仮想マシンのコンソール)から root でログインする
実行コマンド(root でログイン後):
# visudo
sudoers の編集は必ず visudo 経由で行う
この問題を未然に防ぐため、/etc/sudoers および /etc/sudoers.d/ のファイルは、直接 vi で開かず、必ず visudo または visudo -f ファイルパス で編集してください。visudo は保存前に構文チェックを実行し、エラーがある場合は保存をキャンセルします。
パスワードをロックしたのに SSH ログインできてしまう
症状:passwd -l でアカウントをロックしたが、対象ユーザーが SSH で引き続きログインできている。
原因:passwd -l はパスワード認証のみをロックする。SSH 公開鍵認証(~/.ssh/authorized_keys)が設定されている場合、鍵認証によるログインはロックの対象外となる。
対処方法:ログインシェルを /sbin/nologin に変更して、すべての認証方式でログインを拒否する。
実行コマンド:
# usermod -s /sbin/nologin 対象ユーザー
SSH 鍵認証については、SSH設定編で詳しく解説しています。セキュリティ強化の全体像はセキュリティ強化編を参照してください。
