ユーザ権限とsudo
sudo は「この1コマンドだけ管理者として実行する」ための仕組みです。root に直接ログインする代わりに、許可された一般ユーザが自分のパスワードで管理操作を行えます。誰が何を sudo できるかは /etc/sudoers で定義され、編集には文法チェック付きの visudo を使います。sudo を通した操作はログに残るため、「いつ・誰が・何をしたか」を後から追える点も安全管理に役立ちます。
root のパスワードをチーム全員で共有し、みんなでログインする。よくある運用だが、これが危うい。
何か事故が起きても、誰が何をしたか分からなくなる。パスワードが一度漏れれば、被害は甚大だ。
この困りごとを根本から解くのが sudo（superuser do）である。
許可された一般ユーザが「この1コマンドだけを管理者として実行する」ための仕組みだ。各自は自分のアカウントとパスワードのまま、必要な管理操作だけを行える。
使い方は単純で、管理者権限が要るコマンドの前に sudo を付けるだけだ。たとえば `sudo dnf install httpd` でパッケージを導入し、`sudo systemctl restart sshd` でサービスを再起動する。
実行すると初回に自分のパスワードを尋ねられる（root のパスワードではない点に注意）。認証が通ると、一定時間は再入力なしで続けて sudo を使える。
この猶予は既定でおおむね5分ほどだ。ターミナルを離れる時間が長ければ、再び聞かれる。
では、ずっと root になれる su とは何が違うのか。
⚖ sudo と su の違い
似た仕組みに su（switch user）がある。`su -` とすると root に切り替わり、以後ずっと root として作業できる。
だが、これは強い権限を長時間持ち続けることになり、最小権限の観点からは好ましくない。また su は root のパスワードそのものを必要とする。
対して sudo は、root のパスワードを配らずに、自分のパスワードで、1コマンドだけ、必要な範囲に限って権限を借りる方式だ。
どうしても複数の管理コマンドを連続で打ちたいときは `sudo -i`（または `sudo su -`）で対話的な root シェルに入れる。ただし用が済んだら exit で速やかに抜ける、という節度が大切になる。
基本は「su で居座らず、sudo で都度借りる」と覚えてほしい。
では、その「誰に何を許すか」は、どこで決まっているのか。
📜 誰が何を sudo できるか — /etc/sudoers と visudo の役割
sudo の権限は /etc/sudoers という設定ファイルで定義される。
ここに「どのユーザ（またはグループ）が・どのホストで・誰として・どのコマンドを実行できるか」を1行で記述する。
たとえば `user01 ALL=(ALL) ALL` は「user01 はすべてのホストで、すべてのユーザとして、すべてのコマンドを sudo できる」という意味だ。
コマンドを絞りたいときは末尾を具体的に書く。`user01 ALL=(ALL) /usr/bin/systemctl restart httpd` のようにすれば、そのユーザは httpd の再起動だけを sudo できる、という最小権限の設定になる。
RHEL/MiracleLinux系では、wheel グループに入れたユーザに sudo を許す設定が用意されている。`%wheel ALL=(ALL) ALL` という行が該当する（先頭の % はグループを表す）。
そのため、あるユーザに管理権限を与える最も手軽な方法は `usermod -aG wheel user01` で wheel グループに追加することだ（-aG の a を忘れると既存グループから外れてしまうので必ず付ける）。
ところで、この sudoers を直接エディタで開いて編集してはいけない、という鉄則がある。なぜか。
🛡 sudoers は必ず visudo で編集する
ここで強く守ってほしいのが、sudoers ファイルを直接エディタで開かず、必ず visudo コマンドで編集することだ。
理由は、しくじったときの代償が大きすぎるからである。
sudoers に文法エラーがあると sudo 自体が動かなくなる。しかも修正にはその sudo が必要、という八方塞がりに陥りかねない。
visudo は保存時に文法チェックを行う。誤りがあれば警告して書き込みを止めてくれる。この最悪の事故を防ぐための安全装置だ。
設定を1か所にまとめず分割したいときは、/etc/sudoers.d/ ディレクトリ以下に個別ファイルを置く方法が推奨される。その場合も `visudo -f /etc/sudoers.d/user01` のように visudo 経由で編集する。
本体の sudoers には、このディレクトリを読み込む `#includedir /etc/sudoers.d` という記述が含まれている。
さて、ここまで安全に設定した sudo には、もうひとつ見逃せない価値がある。
📝 ログに残るという価値、よくある失敗
sudo の大きな利点は、いつ・誰が・どのコマンドを実行したかがログに残ることだ。
RHEL/MiracleLinux系では /var/log/secure に記録され、`sudo journalctl` でも追える。
何か問題が起きたとき「直前に誰が何をしたか」を後から追跡できる。これは安全管理と原因究明の両面で大きな意味を持つ。
一方でよくある失敗もある。リダイレクトを伴う `sudo echo xxx > /etc/foo` だ。
これは sudo が効くのは echo の部分だけで、ファイルへの書き込み（>）は元の一般権限のまま行われるため「許可がありません」になる。
この場合は `echo xxx | sudo tee /etc/foo` のように tee を使うのが定石だ。同じ理由で、別ファイルを sudo で開きたいときも `sudo vi /etc/hosts` のようにエディタ自体を sudo で起動する。
また、すべてに `sudo -i` で root シェルに入って作業する癖は、せっかくの最小権限とログの粒度を台無しにする。
必要なコマンドにだけ sudo を付ける。この基本を崩さないことが、sudo を安全に使い続けるコツだ。
こうした注意点を踏まえて、現場では sudo をどう位置づけるのか。
🛠 実務の使いどころ
実務では、sudo は単なる「管理者になる手段」ではない。権限を安全に分配し、操作を記録するための運用基盤として使う。
サーバ構築の初手として、作業用の一般ユーザを wheel グループに入れて sudo を許可し、root の直接ログインは SSH 側で禁止する。これがほぼ定型の流れだ。
複数人で運用するなら、各自に個別アカウントを与えて全員 sudo 経由で作業させ、共有の root パスワードに頼らないようにする。
こうしておけば /var/log/secure を見るだけで「誰が・いつ・何をしたか」を追え、監査にも障害対応にも役立つ。
さらに踏み込むなら、運用担当の役割ごとに sudoers でコマンドを絞る。たとえばアプリ担当にはサービスの再起動とログ閲覧だけを許す、といった最小権限の分配も可能だ。
万能の root を全員で共有するのではなく、必要な権限を必要な人に必要なだけ配る。sudo はその思想を日々の運用で実現するための、最も基本的な道具立てなのである。