一般ユーザーから管理者権限で安全にコマンドを実行する実務手順

サーバー運用で「このコマンドだけroot権限が必要」という場面は日常的に発生します。直接rootでログインするのではなく、sudoコマンドを使って一般ユーザーのまま管理者操作を行う方法が現代Linuxの標準です。この記事では/etc/sudoersへの権限追加から実行ログの確認まで、すぐに使える手順を説明します。

作業前に自分のsudo権限を確認する

まず自分のアカウントにsudo権限が付与されているかを確認します。

sudo -l

「User alice may run the following commands」のような出力が得られれば権限があります。「is not in the sudoers file」と表示された場合は、root権限を持つユーザーに権限の追加を依頼するか、後述の手順でsudoersへ追記します。

/etc/sudoers に権限を追加する

/etc/sudoersは必ずvisudoコマンドで編集します。構文エラーがあると保存時に警告が出るため、設定ミスでsudoが一切使えなくなるという最悪の事態を防げます。テキストエディタで直接編集するのは厳禁です。

# まずrootに切り替える
su -
# sudoers を安全に編集する
visudo

方法1：グループごと権限を付与する（推奨）

個人アカウントを1件ずつ追加するより、グループで管理するほうが運用しやすくなります。RHEL系（Rocky Linux・AlmaLinux・CentOS Stream）ではwheelグループ、Ubuntu/Debianではsudoグループへの設定が標準です。いずれも初期インストール時点でほぼ有効になっています。

# RHEL系：wheelグループのユーザーに全コマンドを許可（デフォルトで有効）
%wheel  ALL=(ALL:ALL) ALL

# Ubuntu/Debian系：sudoグループ（デフォルトで有効）
%sudo   ALL=(ALL:ALL) ALL

ユーザーをグループに追加するにはusermodを使います。

# RHEL系
usermod -aG wheel alice

# Ubuntu/Debian系
usermod -aG sudo alice

グループ変更はログインし直すまで反映されません。newgrp wheelで即時反映させるか、いったんログアウトして再ログインします。

方法2：特定ユーザーを個別に追加する

作業用アカウントを一時的に追加したい場合など、個別指定も可能です。visudoで開いたファイル内に以下の行を追加します。

alice   ALL=(ALL:ALL) ALL

編集後は:wqで保存します。構文エラーがある場合はvisudoが保存を止めて警告します。エラーが出た場合はeキーで編集に戻り、修正してから保存します。

ユーザーごとの設定は/etc/sudoers.d/以下に別ファイルとして置くと管理しやすくなります。メインの/etc/sudoersを直接編集せずに済み、設定の追加・削除がファイル単位で完結します。

# /etc/sudoers.d/ 以下に置く場合も visudo -f を使う
visudo -f /etc/sudoers.d/alice

sudo でコマンドを実行する

権限が付与されたユーザーは、コマンドの先頭にsudoを付けるだけで管理者権限で実行できます。

# パッケージ更新（RHEL系）
sudo dnf update

# ファイアウォール設定の確認
sudo firewall-cmd --list-all

# サービスの起動・停止
sudo systemctl restart nginx

初回実行時は自分のパスワード（rootのパスワードではない）を求められます。一定時間（デフォルト5分）は再認証なしでsudoを続けて使えます。セッションをまたいで権限を延長したい場合はsudo -vでタイムアウトをリセットできます。

rootシェルに切り替えて複数の管理操作をまとめて行う

設定変更が連続する場合は、rootシェルに切り替えてから作業するほうが効率的です。かつてはsudo su -が広く使われていましたが、現在はsudo -iが推奨されています。sudo -iはrootのログインシェルを起動し、PATHなどの環境変数もrootのものに切り替わるため、管理コマンドの場所を確実に参照できます。

sudo -i
# プロンプトが # に変わりroot環境になる
# 作業が終わったら exit か Ctrl+D で元のユーザーに戻る
exit

rootシェルでの作業時間は最小限にします。誤操作の影響範囲が広くなるため、可能な限りsudo コマンド名の形で個別実行するほうが安全です。ある運用現場では「rootシェルは5分以内で完了する作業のみ、それ以上かかる場合は手順書を整備してからsudoで1コマンドずつ実行する」というルールを設けています。

実行ログで「誰が何を実行したか」を確認する

sudoの実行記録はsystemdのジャーナルに記録されます。journalctlで確認します。/var/log/messagesやsyslogを直接tailしていた旧来の手順は、systemd環境ではjournalctlに置き換えられています。

# sudoの実行ログをすべて表示
journalctl -t sudo

# 直近1時間分に絞る
journalctl -t sudo --since "1 hour ago"

# 特定ユーザーの操作だけ確認する
journalctl -t sudo | grep alice

出力は以下のように記録されます。実行したコマンドのフルパス・作業ディレクトリ・切り替え先ユーザーが残ります。

Jul 17 10:06:48 server1 sudo[1369]: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx
Jul 17 10:07:02 server1 sudo[1372]: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/dnf update

「user NOT in sudoers」のログが残っている場合は、権限のないユーザーが管理者コマンドを試みた記録です。不審なアカウントからの試行が見つかったら速やかに調査します。

NOPASSWD 設定は本番環境で慎重に

自動化スクリプトやCI/CDパイプラインから管理コマンドを実行する場合、パスワード入力をスキップするNOPASSWDオプションが必要になることがあります。ただしアカウントが侵害された際のリスクが高くなるため、全コマンドへのNOPASSWDは避け、必要なコマンドだけに限定します。

# 特定コマンドだけNOPASSWDにする（許容範囲）
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp

# 全コマンドNOPASSWDは本番では非推奨
# deploy ALL=(ALL) NOPASSWD: ALL

自動化用アカウントには必要最小限のコマンドのみ許可し、インタラクティブなログインシェルを無効化（/sbin/nologin）しておくと攻撃面を絞れます。