管理者アカウントへの昇格を特定グループだけに限定する手順

rootパスワードを知っている一般ユーザー全員が su - でrootに昇格できる状態は、退職者対応や内部不正のリスクを高めます。PAMの設定を1行変更するだけで、root昇格を wheel グループのメンバーだけに絞り込めます。手順は「グループへの追加」と「設定ファイルの1行編集」の2ステップです。

まず結論：2ステップで設定は完結する

許可するユーザーを wheel グループへ追加し、/etc/pam.d/su のコメントアウトを1行外すだけです。

# 手順1: ユーザーをwheelグループへ追加（AlmaLinux / Rocky Linux / RHEL 8以降）
usermod -aG wheel alice

# グループへの追加を確認
id alice
# uid=1001(alice) gid=1001(alice) groups=1001(alice),10(wheel)

グループへの追加は現在ログイン中のセッションには即座に反映されません。対象ユーザーは一度ログアウトして再ログインし、id コマンドで wheel グループが表示されることを確認してください。

PAM設定ファイルを編集して制限を有効にする（RHEL系）

AlmaLinux 8/9・Rocky Linux 8/9・RHEL 8/9 では、/etc/pam.d/su にすでに次の2行がコメントアウト済みで用意されています。どちらを有効にするかで動作が変わります。

#auth		sufficient	pam_wheel.so trust use_uid
#auth		required	pam_wheel.so use_uid

sufficient trust はwheelグループのメンバーをrootパスワードなしで昇格させる設定です。required はrootパスワードの入力を引き続き求めつつ、非wheelメンバーを拒否する設定です。本番環境では下の行（required）を有効にするのが原則です。

# バックアップを必ず取ってから編集する
cp /etc/pam.d/su /etc/pam.d/su.bak
vi /etc/pam.d/su

# 変更前（コメントアウトされている）
#auth		required	pam_wheel.so use_uid

# 変更後（先頭の # を削除するだけ）
auth		required	pam_wheel.so use_uid

設定ファイルを保存すれば即座に反映されます（デーモンの再起動は不要）。use_uid は su を実行したユーザーの実効UIDでグループ判定するオプションです。これを省略すると意図どおりに動作しない環境があるため、必ず付けてください。

古いドキュメントでは /lib/security/pam_wheel.so のようにモジュールのフルパスが記述されています。CentOS 6以前の名残ですが、現代のシステムではPAMがライブラリパスを自動解決するため pam_wheel.so だけで正しく動作します。同様に、古い資料に登場する pam_stack.so service=system-auth という記述も現在は廃止されており、現代の設定ファイルでは substack や include ディレクティブに置き換わっています。古い設定を流用する際は必ず現在の /etc/pam.d/su の内容を確認してから変更箇所だけを修正してください。

Ubuntu・Debian系での手順

Ubuntu・Debian系では慣習上 wheel グループではなく sudo グループを使います。PAMの group= オプションで対象グループを明示的に指定するのがポイントです。

# sudoグループへ追加（Ubuntu / Debian）
usermod -aG sudo alice

# 確認
groups alice

cp /etc/pam.d/su /etc/pam.d/su.bak
vi /etc/pam.d/su

# 変更前
# auth    required   pam_wheel.so

# 変更後（sudoグループに限定する）
auth    required   pam_wheel.so group=sudo

group=sudo を指定しないと、デフォルトの動作では root グループのメンバー判定になる場合があります。意図したグループで動作させるために明示指定を推奨します。

設定が正しく効いているか動作確認する

動作確認は「制限されるケース」と「通過するケース」の両方を必ず試してください。設定ミスでrootへの昇格が一切できなくなるリスクがあるため、確認中はrootのセッションを別端末で開いたまま作業することを強くお勧めします。

# wheelグループ外のユーザーでテスト（正しいrootパスワードを入力しても拒否される）
[bob@server ~]$ su -
Password:
su: Authentication failure

# wheelグループのメンバーでテスト（rootパスワードで昇格できること）
[alice@server ~]$ su -
Password:
[root@server ~]#

両方の挙動が期待どおりであれば設定完了です。うまく動かない場合は id ユーザー名 で wheel グループへの所属を再確認し、ログイン済みセッションに古いグループ情報が残っていないか（再ログインが済んでいるか）をチェックしてください。

また、wheel グループに誰も追加されていない状態で制限を有効にすると、rootパスワードを知っていても一般ユーザーからrootへの切り替えが一切できなくなります。作業前に自分自身が wheel グループに入っているかを id コマンドで確認しておくことが鉄則です。

sudoとの使い分けと実務上の注意点

今回の設定はあくまで su コマンドのPAM制御です。/etc/pam.d/sudo や /etc/pam.d/sshd は別ファイルを参照するため、SSH接続や sudo の動作には影響しません。

現代のサーバー運用では su よりも sudo が推奨されます。sudo はコマンド単位で権限を委譲でき、操作ログがRHEL系では /var/log/secure、systemdベースの環境では journalctl で追跡できます。退職者が出たときもアカウントを無効化するだけで権限を完全に剥奪できるため、監査要件があるシステムでは su を廃止して sudo -i だけを許可する構成も検討してください。

ある運用現場では、本設定の導入後に /etc/sudoers の棚卸しも同時に行い、不要な NOPASSWD 設定を削除したことで、大幅なセキュリティ改善につながった例があります。rootへの昇格経路を整理する機会に、sudo の権限設定も見直すと効果的です。