Linuxでsudo権限の付与と削除を行う方法を完全解説

Linuxでsudo権限を付与・削除するには、その端末でどのグループやsudoersルールが許可を与えているかを先に確認します。Ubuntu/Debian系のsudoグループと、RHEL系のwheelグループを混同せず、グループから外しただけで既存のrootプロセスまで終了するとは考えないでください。

この記事は、管理者が承認済みの利用者と操作範囲を設定するための手順です。現在sudoを使えない利用者が自分で制限を回避する手順ではありません。変更前に別の正常な管理者経路、設定バックアップ、復旧方法を確保し、唯一の管理者を締め出さないようにします。実機で権限付与・削除を実行した検証結果は含みません。

目次

sudoは別ユーザーとして許可されたコマンドを実行する仕組み

sudoの実行先は既定ではrootですが、ポリシーによって別ユーザーも指定できます。パスワード認証と「そのコマンドを許可するか」という権限判定は別です。通常は実行者のパスワードを確認しますが、設定で挙動が変わる場合もあります。ログがあっても、起動したシェルの全操作まで常に記録されるとは限りません。

whoami
id
sudo -l

idは現在のプロセスの所属グループ、sudo -lは自分に許可された操作の確認に使います。別ユーザーの一覧を調べるsudo -l -U usernameは通常、管理者側の権限が必要です。リスト表示の成功を、そのユーザーに全コマンドを許可した証拠にしないでください。

付与前に既存ユーザーと権限の出所を確認する

getent passwd username
id username
getent group sudo
getent group wheel

usernameは対象の実際のユーザー名へ置き換えます。存在しない利用者を無条件に追加せず、ローカルアカウントかLDAP/SSSDなどの中央管理アカウントかを確認します。新規アカウントが必要な場合も、組織の作成・認証・失効手順に従ってください。adduserの挙動はディストリビューションで同じとは限りません。

グループ名だけでは権限は決まりません。sudoersにそのグループを許可するルールがあること、別の個別ルールや中央ポリシーがないかを管理者が確認します。

Ubuntu/Debian系:sudoグループへ追加する例

sudo usermod -aG sudo username

既存のsudoグループが管理者権限を許可する構成で、広い管理権限の付与が承認されている場合の例です。-aを省いたusermod -Gは、指定しなかった補助グループを外す可能性があります。既存の所属を維持して追加するため-aGを使います。

RHEL系:wheelグループへ追加する例

sudo usermod -aG wheel username

RHEL系ではwheelを使う構成が一般的ですが、管理者が実際のsudoersの%wheelルールを確認します。Ubuntuの例と両方を続けて実行する手順ではありません。作業後は対象ユーザーが新しいログインセッションでidとsudo -lを確認します。現在の端末内だけでグループ情報が更新されたと決めつけないでください。

sudoersを変更するならvisudoと全体チェックを使う

sudo visudo

visudoは同時編集や構文誤りを検査しますが、「権限を広げすぎていない」ことまで保証しません。構文エラーが表示されたら修正するか保存を中止し、強制保存するQを使って進めないでください。nanoならCtrl+Oで保存、Ctrl+Xで終了、viならEsc後に:wqで保存終了というように、開いたエディターの操作に従います。

sudo visudo -c
sudo -l -U username

個別の断片だけでなく、includeされた設定を含む全体をチェックします。所有者・権限も確認し、一般ユーザーが書き換えられる状態へ緩めません。確認を終えるまで復旧用の管理者セッションを閉じず、別セッションで対象者の許可・不許可を試験します。

sudoersのALLは限定権限ではない

username ALL=(ALL:ALL) ALL

これは特定作業だけでなく、すべてのコマンドを許可する広いルールの例です。構文の確認用であり、困ったら追加する推奨値ではありません。実行者、ホスト、実行先ユーザー/グループ、コマンドの順に範囲を読みます。%sudoのような先頭%はグループを表します。

最小権限では実行ファイルだけでなく引数と入力も限定する

apt-get、systemctl、git、make、mysqlなどを引数なしで丸ごと許可しても、安全な最小権限とは限りません。プログラムや設定、スクリプト、外部コマンドを読み込む機能があれば、想定以上の操作につながります。許可するコマンドの実際の機能と、利用者が書き換えられるファイルを確認してください。

username ALL=(root) /usr/bin/id ""

これは/usr/bin/idを引数なしでrootとして実行するだけの、構文説明用の小さい例です。末尾の空文字列""は「引数なし」に限定します。実際のパスはcommand -v idで確認します。業務で必要な操作がないのにこのルールを追加する必要はありません。引数を省略する記述は任意の引数を許可し得るため、同じ意味ではありません。

サービス再起動の委任なら、実行先ユーザー、正確なコマンドパス、許可する引数、対象ユニットを限定し、ユニットファイルや起動スクリプトも利用者が書けないことを確認します。ワイルドカードや否定ルールだけで広いALL許可を安全にできるとは考えないでください。

/etc/sudoers.dで用途ごとに分ける

sudo visudo -f /etc/sudoers.d/team-ops
sudo visudo -c

メイン設定がそのディレクトリをincludeしている場合に使います。team-opsのように用途が分かるファイル名にし、読み飛ばされるドットを含む名前や末尾~を避けます。単独ファイルの構文が正しくても、全体との競合・重複を確認します。バックアップは有効なinclude対象として読み込まれない、安全な別の保管先へ置きます。

NOPASSWDや自動化スクリプトの注意点

NOPASSWDは認証を省略する指定で、コマンドの権限範囲を狭くする指定ではありません。必要性がある自動化に限り、対象ユーザー・実行先・引数を限定します。利用者が編集できるスクリプト、親ディレクトリ、設定ファイル、PATH上の依存コマンドをroot実行させる設計は避けます。

「sudoグループへ追加 → sleep 3600 → 削除」というスクリプトは1時間の権限失効を保証しません。途中終了・再起動・認証の失効で削除されない可能性があり、削除できても既存の昇格済みプロセスが残ります。期限付きアクセスは管理基盤や承認・回収の仕組みで実装し、回収できたことを検証してください。

sudo権限を取り消す:許可元を全て確認する

グループ由来なら管理者が該当グループから外します。次はローカルの補助グループの例で、実環境の一方だけを使います。ユーザー自体を削除する操作ではありません。主グループや中央管理の所属は管理方式に従って変更します。

# sudoグループ由来の場合
sudo gpasswd -d username sudo

# wheelグループ由来の場合
sudo gpasswd -d username wheel

Debian/Ubuntu系ではsudo deluser username sudoというグループ削除の書式もありますが、最後のグループ名を省略するとユーザー削除の意味になるため注意します。対象と引数を確認してから実行してください。

個別ルールなら、そのルールがあるファイルをvisudoで変更します。/etc/sudoersだけでなくsudoers.d、他の許可グループ、LDAP/SSSDなどの中央ポリシーも確認します。一行をコメントアウトしただけで全ての経路が消えるとは限りません。

sudo visudo -c
id username
sudo -l -U username

照会のエラーと「許可がない」という結果を区別し、新しいログインセッションでも期待するコマンドが拒否されるか確認します。単にリストが空に見えることを失効成功の唯一の条件にしません。

既存セッション・rootプロセス・認証キャッシュは別問題

グループ変更は既存セッションの補助グループへ自動反映されない場合があります。また、一度rootで起動したシェルやプロセスはsudoersを変更しても自動終了しません。緊急の失効では、管理者がログインセッションや昇格済みプロセス、他のアクセス手段を調査し、業務影響を踏まえて対処します。

sudo -kは呼び出したユーザーの認証キャッシュを無効にするためのもので、sudoers権限そのものを取り消すコマンドではありません。NOPASSWDルールや既に動いているプロセスの停止にもなりません。

ログ・見直し・復旧の確認

ログの保存先は環境によりjournal、/var/log/auth.log、/var/log/secureなど異なります。sudoの許可・拒否、実行者、対象コマンド、時刻を確認し、必要ならI/Oログなどの運用を別途設計します。パスワードや機密引数を記録・共有しないよう注意してください。

権限を失ってsudoが使えなくなった場合は、既存の別管理者や承認されたコンソール復旧手順へ引き継ぎます。所有者やパーミッションを無差別に緩めて直そうとしません。変更記録には付与理由、対象範囲、期限、検証結果、撤去確認を残すと棚卸しに役立ちます。

公式資料

Sudo:visudoマニュアル / Arch Linux配布のsudoersマニュアル / Red Hat:sudoアクセスの管理 / Ubuntu:usermod

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次