最小権限の考え方
セキュリティの土台は「必要な人に、必要な分だけ、必要な間だけ権限を与える」という最小権限の原則です。常に管理者（root）で作業すると、ちょっとした操作ミスやマルウェアがシステム全体を壊しかねません。普段は一般ユーザで作業し、管理操作が必要なときだけ一時的に権限を借りる、という使い分けが基本です。ファイルのパーミッションも同じ発想で、誰でも書ける状態を避け、所有者とグループを適切に絞ります。
同じ rm -rf を打っても、ある人は「権限がありません」で助かり、ある人はシステムごと吹き飛ばす。
この差は、打った相手が誰かで決まる。ただの一般ユーザか、それとも何でもできる管理者 root か。たったその一点だ。
だからセキュリティで最初に身につけたいのが「最小権限の原則（principle of least privilege）」だ。必要な人に、必要な分だけ、必要な間だけ権限を与える、という考え方になる。
裏返せば「ふだんは強い権限を持たない」ということでもある。
root はパーミッションの審査を無条件で通過する。システム上のあらゆるファイルを読み書きでき、どんなプロセスでも止められる。
強力なぶん、ひとつの操作ミスが致命傷になる。消すディレクトリを打ち間違えただけで、一般ユーザなら止まるところを、root だと黙って実行され、システムが起動しなくなる。これは現実に起こる。
だからこそ、強い権限は「常時持つもの」ではなく「必要なときだけ借りるもの」と捉えるのが出発点になる。
🚫 なぜ常に root で作業してはいけないのか
root で作業し続ける危うさは、操作ミスだけにとどまらない。
もし作業中に踏んでしまったプログラムに悪意があったら、そのプログラムは「あなたの権限」で動く。
一般ユーザとして実行していれば、被害はそのユーザが触れる範囲（自分のホームディレクトリなど）に限られる。
だが root として実行していれば、話は別だ。システム全体を書き換える、別のユーザのデータを盗む、常駐する裏口（バックドア）を仕込む、といったことまで一気にやられかねない。
つまり「ふだん一般ユーザでいる」こと自体が、事故とマルウェアの被害範囲を小さく抑える防壁になっている。これは万一のときの被害を局所化するという意味で、最小権限の核心にあたる。
だからサーバ運用では、root への直接ログインそのものを禁止し、必要な操作だけを後述の sudo 経由で行う構成が標準になっている。
🪜 一般ユーザで作業し、必要なときだけ昇格する
実務での基本の流れは、こうだ。ふだんは自分用の一般ユーザでログインして作業する。管理操作が必要になった瞬間だけ一時的に権限を昇格し、終わったら一般権限に戻る。
この一時的な昇格を担うのが sudo というコマンドだ。`sudo dnf install httpd` のように、管理コマンドの前に付けて使う。
su で root に切り替わってずっと作業するのに比べ、sudo は「この1コマンドだけ管理者として実行する」。だから強い権限を持つ時間が最小限で済む。
さらに、誰がどのコマンドを sudo できるかは設定ファイルで細かく制御できる。「あるユーザにはサービスの再起動だけ許す」といった絞り込みも可能だ。
権限を持つ範囲（何ができるか）と時間（いつ持つか）の両方を絞る。この二段構えが最小権限を実践するコツになる。
ここまではユーザの権限の話だったが、同じ発想はファイルそのものにも効いてくる。
🔐 ファイルのパーミッションも最小権限で
最小権限の発想は、ファイルのパーミッション（permission）にもそのまま当てはまる。
Linuxの各ファイルには、所有者・グループ・その他という3区分それぞれに、読み（r）・書き（w）・実行（x）という3種類の許可（rwx）が設定されている。
`ls -l` で先頭に表示される `-rw-r--r--` のような並びがそれだ。
ここで「誰でも書き込める（その他に w が付いている）」状態は避けたい。第三者にファイルを書き換えられる隙になるからだ。
たとえば外から見えてはいけない秘密情報を含むファイルは、所有者だけが読み書きできる 600（`chmod 600 secret.conf`）に絞る。そのうえで所有者とグループを `chown` で適切な相手に設定する。
誰にどこまで許すかを必要最小限に絞ることが、情報漏えいや改ざんの入口を減らす。
逆に、秘密鍵や設定ファイルが 777（誰でも読み書き実行可）のようにゆるすぎると、それ自体がセキュリティの穴になる。SSH などは安全のため、そうしたファイルを受け付けないことすらある。
ここまでが正攻法だが、実は rwx だけを見ていると見落とす落とし穴がある。
🧩 SUID・共有ディレクトリなど見落としやすい点
rwx の並びをいくら睨んでも気づけない、やや進んだ注意点がある。実行時に一時的に所有者の権限で動く SUID というしくみだ。
`ls -l` で実行権の位置に x ではなく s が見える（`-rwsr-xr-x` など）ファイルがそれにあたる。passwd コマンドのように「一般ユーザが実行しても内部で特権処理が要る」場面で使われる。
便利な反面、不必要に SUID が付いた自作プログラムは権限昇格の踏み台になりかねない。安易に付けないのが鉄則だ。
また、複数人で書き込みを共有するディレクトリでは、各自が自分の作ったファイルだけ消せるよう「スティッキービット」を付ける。`chmod 1777 /shared` のように先頭に 1 を足す（/tmp がこの設定）。こうした配慮も最小権限の一部になる。
こうした細部まで含めて、最小権限は日々どう使えばよいのか。
🛠 実務の使いどころ
最小権限は、特別な日だけ意識する作法ではない。日々の操作の土台に据えるべき習慣だ。
新しくサーバを立てたら、まず作業用の一般ユーザを作って sudo を許可し、root の直接ログインを止める。
ファイルを置くときは「本当にその他ユーザに読ませてよいか・書かせてよいか」を一拍考えてからパーミッションを決める。
サービスを動かすときは、可能なら専用の権限の弱いユーザで動かす。こうした積み重ねが、いざ攻撃や事故が起きたときに被害を最小限に食い止める。
データベースやWebアプリも、それ専用のシステムユーザで動かし、必要なディレクトリにしか書き込めないようにしておく。そうすれば、そのサービスが破られても被害がそこで止まる。
「便利だから全部に強い権限を与える」誘惑に対し、「困らない範囲でいちばん弱い権限は何か」と問い直す。この問いを習慣にすることが、Linuxのセキュリティ全体を貫く背骨になる。
本トラックで扱う sudo・SSH 鍵認証・ファイアウォール・SELinux・アカウント管理は、いずれもこの最小権限という一本の思想を、それぞれの場所で形にしたものだ。そう捉えると、互いのつながりが見えてくる。