先日、受講生の方からこんな相談を受けました。インストール、設定変更、ログの確認まで、全部rootでやってしまう。これは独学者に非常に多いパターンです。
この記事では、Linuxの権限設計を意識できる人が、なぜ現場で重宝されるのかを、20年以上サーバーを運用してきた経験と、3,100名以上を指導してきた中で見えてきた事実から解説します。
rootに頼らないサーバー運用の考え方、そしてそれが「スキル」ではなく「思想」であることまで踏み込んでお伝えします。
この記事のポイント
・権限設計を意識できる人は「事故を起こさない人」として現場で信頼される
・rootでの常時作業は便利さと引き換えに復旧不能な事故を招く
・sudo・グループ・ファイル権限の3階層で最小権限の原則を実装する
・権限は「技術」ではなく「運用思想」、独学で抜けやすい視点
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ「権限設計ができる人」が現場で重宝されるのか
私が現場で採用面接の相談を受けると、決まって出てくる質問があります。「技術力は同じくらいの2人、どちらを採るべきか」というものです。判断基準を一つに絞るなら、私はいつもこう答えています。「権限の話をしたときに、反射的に最小権限の発想が出てくる方を採ってください」と。
なぜか。権限設計ができる人は、事故を起こさない人だからです。そして現場で最もコストがかかるのは、優秀な人を採ることではなく、事故を起こす人を抱えることです。
20年以上サーバーを運用してきた中で、致命的な障害の多くは「権限が広すぎたから起きた」ものでした。設定ファイルを誤って削除、ログを誤って上書き、本番DBを誤って更新。いずれも「そもそもそのユーザーにその権限を与えてはいけなかった」という根本原因に行き着きます。
逆に、権限設計を意識できる人は、こうした事故の芽を仕組みで潰します。個人の注意力に頼らない。これが現場で重宝される最大の理由です。
rootに頼る運用の何が問題なのか
独学でLinuxを学んだ方に非常に多いのが、「作業は全部rootでやる」というスタイルです。確かに、rootで入ってしまえば権限エラーは出ません。何でもできます。速い。便利。しかし、この便利さの裏には、現場で決して許されないリスクが潜んでいます。
1. typoが即・本番事故になる
rootは制限がない分、タイプミスがそのまま破壊行為になります。「rm -rf /var/log/」と打つつもりで「rm -rf /」を叩いてしまった、は業界で語り継がれる古典的な事故です。一般ユーザーで作業していれば、そもそも権限エラーで止まります。「事故を起こす前に止まる」仕組み、これが権限の本質的な価値です。
2. 誰が何をやったか追跡できなくなる
複数人で運用するサーバーで全員がrootに直接ログインしていると、監査ログを見ても「誰が操作したか」が分かりません。「rootがやった」としか残らないからです。私のセミナーでも、この話をすると「うちの現場、まさにそれです」という方が必ずいます。障害対応の振り返りで「誰がいつ何をしたか」を特定できない現場は、改善が進みません。
3. 自動化・CI/CDと相性が悪い
最近の現場ではAnsibleやシェルスクリプトによる自動化が当たり前です。自動化スクリプトをrootで一気に動かす運用は、一度バグが混入すれば全台が同時に死ぬ、という最悪のシナリオを招きます。権限を絞って「この処理はこのユーザーでしか動かない」と設計しておくと、事故の影響範囲を最小に抑え込めます。
最小権限の原則を実装する3階層
「じゃあ具体的にどう設計するのか」という話に進みます。権限設計は、以下の3階層で考えると整理しやすくなります。1. sudoで「必要な操作だけ」許可する
sudoは単なる「rootになる道具」ではありません。「どのユーザーが、どのコマンドを、どの条件で実行できるか」を細かく制御する仕組みです。例えば、Webサーバー担当者には「systemctl restart httpd」だけ許可する、DB担当者には「mysqldump」だけ許可する、といった設計ができます。
# /etc/sudoers.d/web-operator の例 # webuserは httpd の再起動とログ閲覧のみ可能 webuser ALL=(root) NOPASSWD: /bin/systemctl restart httpd webuser ALL=(root) NOPASSWD: /usr/bin/tail -f /var/log/httpd/error_log
2. グループで「役割」を表現する
ファイルの所有グループを役割単位で設計すると、権限管理が非常に楽になります。例えば「webdev」グループに属するユーザーだけが/var/www配下を編集できる、といった設計です。# webdevグループを作り、メンバーを追加 # groupadd webdev # usermod -aG webdev taro # usermod -aG webdev hanako # /var/www をwebdevグループ所有にする # chown -R root:webdev /var/www # chmod -R 2775 /var/www # 確認 $ ls -ld /var/www drwxrwsr-x. 5 root webdev 4096 Apr 17 10:23 /var/www
3. ファイル権限で「最後の砦」を築く
sudoとグループで役割を設計したら、最後は個別ファイルの権限で締めます。設定ファイルは644、秘密情報を含むファイルは600、実行スクリプトは755、といった基本の型を守るだけでも、事故は大きく減ります。特に重要なのは、秘密鍵や認証情報ファイルです。600（所有者のみ読み書き）にしていないと、sshdはそもそも起動しません。これはOS側が「権限がゆるいファイルは信頼しない」という思想で作られているからです。
独学者が抜けやすい「運用思想」としての権限
ここまでの話を読んで「コマンドのテクニックの話か」と思った方、ここが一番伝えたいポイントです。権限設計は、技術というより「運用思想」です。コマンドを覚えれば書けるものではなく、「このサーバーで、このユーザーは何をしてよくて、何をしてはいけないか」を設計する思考体力が問われます。
独学者はここが抜けやすい。なぜなら、自宅の検証環境では「自分しか使わない」からです。全部rootでやっても誰も困らない。そして、その癖が本番現場に持ち込まれたときに事故が起きます。
私のセミナーでは、受講生の方には最初から「一般ユーザーで入って、必要なときだけsudoする」というスタイルを徹底してもらっています。最初は不便に感じるはずです。権限エラーが出るたびに手が止まります。
でも、その「手が止まる」経験こそが、現場で事故を起こさないエンジニアを育てます。rootで何でもできる快適さに慣れた人は、いざ本番環境に立ったときに手が滑ります。
「Operation not permitted」「sudo: a password is required」が出たときの対処法
権限を絞って運用していると、避けて通れないのがこの2つのエラーメッセージです。独学者がつまずきがちなので、初動の切り分け方をまとめます。・Operation not permitted：一般ユーザーで特権操作を試みたときに出る。まず
id と ls -l 対象ファイル で自分のユーザー・グループと、ファイルの所有者・権限を確認する。想定と合わない場合はsudoでやり直すか、sudoersの設計を見直す・sudo: a password is required：cron経由やスクリプト実行で頻発する。NOPASSWDを付けたsudoers行がちゃんと読み込まれているか、
sudo -l で対象ユーザーの許可一覧を確認する・sudoersの文法エラー：直接エディタで /etc/sudoers を編集すると、文法ミスでsudo自体が動かなくなる事故が起きる。必ず
visudo または visudo -f /etc/sudoers.d/ファイル名 で編集する現場でやってはいけないのは、エラーが出たからといって「とりあえずchmod 777」や「とりあえずrootで実行」に逃げることです。その対処は目の前のエラーを消すだけで、セキュリティホールを作り込むことになります。
今日から現場で使える3つの習慣
権限設計の思想を身につけるために、今日から実践できる習慣を3つ紹介します。・rootで作業しない：自宅の検証環境でも、一般ユーザーを作ってそこで作業する。必要なときだけsudoする
・ls -l を指差し確認する：新しく触るサーバーでは、作業対象ファイルの所有者・グループ・権限を必ず声に出して確認する
・sudoers を読む習慣をつける：現場のサーバーに入ったら /etc/sudoers と /etc/sudoers.d/ を一通り眺めて、「このサーバーは誰に何を許可しているか」を把握する
この3つを続けるだけで、半年後の自分は「権限を意識できる人」になっています。現場で「あの人に任せれば事故が起きない」と評価されるエンジニアは、こうした地道な習慣の積み重ねで作られます。
本記事のまとめ
権限設計を意識できる人は、事故を起こさない人として現場で信頼されます。| 意識すべきポイント | 具体的な行動 |
|---|---|
| rootに頼らない | su - 一般ユーザー名 で切り替え、必要なときだけ sudo コマンド を使う |
| sudoで操作を絞る | visudo -f /etc/sudoers.d/ファイル名 で許可コマンドを明示する |
| グループで役割を表現 | usermod -aG グループ名 ユーザー名 でチーム単位の権限を設計する |
| ファイル権限を締める | chmod 600 秘密ファイル名 と chmod 644 設定ファイル名 の型を守る |
| 運用を監査する | sudo -l -U ユーザー名 で現場の権限設計を読み解く習慣をつける |
rootに頼らない運用を「型」から身につけたいあなたへ
権限設計の思想は、コマンドを覚えるだけでは身につきません。
sudo・グループ・ファイル権限を「どう組み合わせて、どう現場で守るか」という全体像が必要です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linux 7.1でNTFSドライバが"復活"｜4年越しの全面書き直しをTorvaldsが承認した理由
- 前のページへ：Linuxのmanページが読みこなせる人ほど現場で強い理由｜ググる前に開く習慣が成長を加速させる
- この記事の属するカテゴリ：Linux学習ガイド・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます