最小権限の考え方
セキュリティの土台は「必要な人に、必要な分だけ、必要な間だけ権限を与える」という最小権限の原則です。常に管理者（root）で作業すると、ちょっとした操作ミスやマルウェアがシステム全体を壊しかねません。普段は一般ユーザで作業し、管理操作が必要なときだけ一時的に権限を borrow する、という使い分けが基本です。ファイルのパーミッションも同じ発想で、誰でも書ける状態を避け、所有者とグループを適切に絞ります。
セキュリティを考えるとき、最初に身につけたい姿勢が「最小権限の原則（principle of least privilege）」です。これは「必要な人に、必要な分だけ、必要な間だけ権限を与える」という考え方で、裏返せば「ふだんは強い権限を持たない」ということでもあります。Linuxには何でもできる管理者ユーザ root が存在しますが、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 などは安全のためにそうしたファイルを受け付けないことすらあります。
SUID・共有ディレクトリなど見落としやすい点
やや進んだ注意点として、実行時に一時的に所有者の権限で動く SUID というしくみがあります。`ls -l` で実行権の位置に x ではなく s が見える（`-rwsr-xr-x` など）ファイルがそれで、passwd コマンドのように「一般ユーザが実行しても内部で特権処理が要る」場面で使われます。便利な反面、不必要に SUID が付いた自作プログラムは権限昇格の踏み台になりかねないため、安易に付けないのが鉄則です。また、複数人で書き込みを共有するディレクトリでは、各自が自分の作ったファイルだけ消せるよう「スティッキービット」を付ける（`chmod 1777 /shared` のように先頭に 1 を足す、/tmp がこの設定）といった配慮も最小権限の一部です。
実務の使いどころ
最小権限は、特別な日だけ意識する作法ではなく、日々の操作の土台に据えるべき習慣です。新しくサーバを立てたら、まず作業用の一般ユーザを作って sudo を許可し、root の直接ログインを止める。ファイルを置くときは「本当にその他ユーザに読ませてよいか・書かせてよいか」を一拍考えてからパーミッションを決める。サービスを動かすときは、可能なら専用の権限の弱いユーザで動かす。こうした積み重ねが、いざ攻撃や事故が起きたときに被害を最小限に食い止めます。データベースやWebアプリも、それ専用のシステムユーザで動かし、必要なディレクトリにしか書き込めないようにしておけば、そのサービスが破られても被害がそこで止まります。「便利だから全部に強い権限を与える」誘惑に対し、「困らない範囲でいちばん弱い権限は何か」と問い直す——この問いを習慣にすることが、Linuxのセキュリティ全体を貫く背骨になります。本トラックで扱う sudo・SSH 鍵認証・ファイアウォール・SELinux・アカウント管理は、いずれもこの最小権限という一本の思想を、それぞれの場所で形にしたものだと捉えると、互いのつながりが見えてきます。