こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「Linuxエンジニアになるための基礎」連載、第4回へようこそ。前回はDNFを用いたパッケージ管理と、依存関係やシステムアップデートの極意について学びました。
今回は、サーバーのセキュリティ基盤そのものである「ユーザー・グループ管理とアクセス制御（IAM: Identity and Access Management）」について、圧倒的な情報密度で徹底解剖します。Linuxシステムにおいて「誰が」「どのリソースに」「どのような操作を行えるか」を厳密にコントロールする技術は、悪意ある攻撃や内部不正からシステムを守るための最重要課題です。
先生、うちの開発チームに新しいメンバーが加わったんですが、面倒なのでサーバーの root パスワードをSlackで共有してみんなで使おうと思っています。これなら権限エラーで作業が止まることもないし、効率的ですよね？
コウ君、それはインフラエンジニアとして絶対にやってはいけない「最悪のアンチパターン」よ！root パスワードを共有してしまったら、誰が設定ファイルを書き換えたのか、誰が誤ってデータを削除したのか（監査ログ・トレーサビリティ）が全く追えなくなるわ。
エンタープライズの現場では、必ず「個人ごとのユーザー」を作成し、必要な権限だけを sudo で一時的に委譲する『最小特権の原則』を守らなければならないの。今日はそのプロの運用ルールを徹底的に叩き込むわよ！
📚 本連載のカリキュラム（全8回）
- 【第1回】ファイル・ディレクトリ管理と基本操作の極意
- 【第2回】テキスト処理と検索の魔法（grep / find / sed / awk）
- 【第3回】パッケージ管理の完全理解（apt / dnf / yum）
- 【第4回】ユーザー・グループ管理とアクセス制御の鉄則（本記事）
- 【第5回】プロセス管理とリソース監視（ps / top / kill）
- 【第6回】サービス管理とデーモン（systemctl）
- 【第7回】システムログの確認とトラブルシューティング（journalctl）
- 【第8回】アーカイブとバックアップ戦略（tar / gzip）
目次
第1章：アカウント情報の心臓部（passwd / shadow / group）
Linuxにおけるユーザーとグループの情報は、すべてプレーンテキスト（ただのテキストファイル）として特定のディレクトリに保存されています。プロのエンジニアは、コマンドだけでなく、裏でどのファイルが書き換わっているかを正確に理解しています。
1-1. /etc/passwd：ユーザー情報の公開データベース
システム上のすべてのユーザー情報が記録されているファイルです。誰でも読み取れる権限（644）になっています。1行につき1ユーザーの情報がコロン（:）区切りで7つのフィールドに分かれて記載されています。
# /etc/passwd の中身（抜粋）
root:x:0:0:root:/root:/bin/bash
nginx:x:998:996:Nginx web server:/var/lib/nginx:/sbin/nologin
kou:x:1001:1001::/home/kou:/bin/bash| フィールド | 例 (kou) | プロの視点・解説 |
|---|---|---|
| 1. ユーザー名 | kou |
ログイン時に使用する名前。 |
| 2. パスワード | x |
昔はここに暗号化パスワードがありましたが、セキュリティ上の理由で現在は「x」となり、実体は /etc/shadow に分離されています。 |
| 3. UID | 1001 |
User ID。Linuxカーネルは名前ではなくこの数値で権限を判断します。0は特権(root)、1〜999はシステムアカウント、1000以降が一般ユーザーです。 |
| 4. GID | 1001 |
Group ID（プライマリグループ）。 |
| 5. コメント | (空) | フルネームや連絡先など（GECOSフィールド）。 |
| 6. ホームディレクトリ | /home/kou |
ログイン直後の現在地（カレントディレクトリ）となるパス。 |
| 7. ログインシェル | /bin/bash |
ログイン後に起動するプログラム。ここが /sbin/nologin や /bin/false になっていると、そのユーザーはサーバーにログインできません（サービスアカウントの鉄則）。 |
1-2. /etc/shadow：暗号化パスワードの金庫
パスワードのハッシュ値（暗号化された文字列）や有効期限が保存されている、root権限でしか読み取れない（000）極めて機密性の高いファイルです。
# /etc/shadow の中身（抜粋）
kou:$y$j9T...省略...:19600:0:99999:7:::AlmaLinux 9以降では、デフォルトのパスワードハッシュアルゴリズムとして従来のSHA-512（$6$）に代わり、より総当たり攻撃（ブルートフォース）に強い yescrypt（$y$） が採用されており、堅牢性が飛躍的に向上しています。
第2章：ユーザー管理コマンドの極意（useradd / usermod）
設定ファイルを手動で編集するのはミス（構文エラー）の原因になるため、プロは必ず専用のコマンドを使用します。
2-1. useradd によるユーザー作成
単に useradd kou と打つだけでもユーザーは作成されますが、インフラ構築の現場ではオプションを組み合わせて、意図した通りの権限や環境を同時に設定します。
# -m: ホームディレクトリを作成する（デフォルトで作成される環境も多いが明示的につける）
# -s: ログインシェルを指定する
# -G: サブグループ（後述）を指定する
useradd -m -s /bin/bash -G wheel kou
# 作成したユーザーにパスワードを設定する（インタラクティブに2回入力）
passwd kou⚠️ サービスアカウント作成のベストプラクティス
アプリケーション（例：Node.jsや独自のデーモン）を動かすための専用ユーザーを作成する場合、そのユーザーで直接ログインされてしまうとセキュリティホールになります。プロは必ず -s /sbin/nologin（ログイン禁止）と -M（ホームディレクトリ不要）を指定して作成します。
例：useradd -M -s /sbin/nologin myapp_user
2-2. usermod による既存ユーザーの変更
作成済みのユーザーの情報を変更するのが usermod コマンドです。
# ユーザーのログインシェルを nologin に変更し、ログインを禁止（無効化）する
usermod -s /sbin/nologin kou
# ユーザーを新しいサブグループ（docker）に「追加」する（-aG の組み合わせが必須）
usermod -aG docker kouここで極めて重要なのが、グループを追加する際の -aG（append + Group）です。もし -a を忘れて usermod -G docker kou と打ってしまうと、これまで所属していたすべてのサブグループ（wheelなど）から外され、dockerグループだけになってしまうという致命的な事故が起きます。現場で最も多いミスの1つですので、絶対に覚えておいてください。
第3章：グループ管理と権限の委譲（groupadd / wheel）
Linuxの権限はユーザー個人だけでなく、「グループ」単位で管理されます。ファイルの所有グループを変えることで、チーム全員に読み書き権限を与えることが可能になります。
3-1. プライマリグループとサブグループ（セカンダリグループ）
Linuxのユーザーは、必ず1つの「プライマリグループ（主グループ）」に属し、さらに複数の「サブグループ（副グループ）」に所属することができます。
# ユーザーの所属グループを確認するコマンド
id kou
# 【出力例】
uid=1001(kou) gid=1001(kou) groups=1001(kou),10(wheel),994(docker)AlmaLinux（RHEL系）では、ユーザーを作成すると、同名のプライマリグループ（上記例では gid=1001(kou)）が自動的に作成される「ユーザープライベートグループ（UPG）方式」が採用されています。
3-2. RHEL系における最重要グループ「wheel」
AlmaLinuxやCentOSにおいて、wheel という名前のグループは特別な意味を持ちます。「wheelグループに所属しているユーザーは、sudo コマンドを使って root 権限（すべての管理者権限）を行使できる」という初期設定がなされているからです。
つまり、新人エンジニアに管理者権限を付与したければ、彼らのアカウントを wheel グループに追加（usermod -aG wheel ユーザー名）するだけで完了します。
第4章：パスワードポリシーと有効期限の管理（chage）
ISMS（情報セキュリティマネジメントシステム）やPCI-DSSなどのセキュリティ基準をクリアするためには、パスワードの定期変更や、アカウントの有効期限（退職者のアカウントを自動で無効化する等）を適切に管理する必要があります。これを行うのが chage コマンドです。
 | スーパーユーザーなら知っておくべきLinuxシステムの仕組み [ Brian Ward ] 価格:3960円 |
4-1. chage コマンドによるパスワードのライフサイクル管理
# ユーザー（kou）のアカウント有効期限・パスワード情報を確認する
chage -l kou
# パスワードの有効期限を90日に設定する（90日経過すると変更を強制される）
chage -M 90 kou
# アカウント自体の有効期限を 2027年3月31日 に設定する（期限を過ぎるとログイン不可）
chage -E "2027-03-31" kou
# 【プロの技】ユーザーに「次回のログイン時にパスワード変更を強制」する
chage -d 0 kou新しいアカウントを作成して初期パスワードを発行した際、プロは必ず chage -d 0 ユーザー名 を実行します。これにより、ユーザーが初回SSHログインした瞬間に「現在のパスワード」と「新しいパスワード」の入力を求められ、管理者（インフラエンジニア）ですらそのユーザーのパスワードを知らない状態（秘匿性の担保）を作り出すことができます。
第5章：su と sudo の決定的な違いと監査ログ
一般ユーザーから管理者権限（root）に昇格する際、su コマンドと sudo コマンドの2つの方法がありますが、エンタープライズ環境では su は原則非推奨となります。その理由を明確に理解しましょう。
5-1. su (Substitute User) の問題点
su - を実行すると、「rootユーザーのパスワード」を要求されます。つまり、複数人でシステムを管理する場合、全員にrootパスワードを教える必要が生じ、コウ君が提案したような「パスワードの共有化」という最悪の事態に陥ります。
5-2. sudo (Superuser DO) の圧倒的優位性
一方 sudo コマンド を実行すると、「実行している本人（一般ユーザー）のパスワード」を要求されます。これによりrootパスワードを誰にも教える必要がなくなります。
さらに重要なのが「監査ログ（Audit Trail）」です。
# /var/log/secure に記録される sudo の実行ログ
Aug 22 15:30:00 server sudo[1234]: kou : TTY=pts/0 ; PWD=/home/kou ; USER=root ; COMMAND=/bin/systemctl restart nginxこのように、「誰が（kou）」「どこで」「何のコマンドを（systemctl restart nginx）」「root権限で実行したか」が、すべて /var/log/secure に一言一句漏らさず記録されます。これが、インフラエンジニアが sudo を絶対の基準とする最大の理由です。
第6章：visudoによるアクセス制御の完全マスター
sudo コマンドの設定ファイルは /etc/sudoers ですが、このファイルは絶対に vim 等で直接編集してはいけません。万が一構文エラー（タイポなど）があると、誰も sudo できなくなり、システムから締め出される（ロックアウト）という大惨事になります。
必ず、構文チェック機構を備えた専用エディタである visudo コマンドを使用して編集します。
# sudoers ファイルを安全に編集する（保存終了時に自動で構文チェックが走る）
visudo6-1. sudoersの基本構文
設定の基本書式は以下の通りです。
誰が どこから=(誰として) 何のコマンドを
# 例1：wheelグループのメンバーは、すべてのホストから、すべてのアカウントとして、すべてのコマンドを実行できる
%wheel ALL=(ALL) ALL
# 例2：ユーザー kou は、Nginxの再起動コマンドだけをパスワードなしで実行できる（※パス指定必須）
kou ALL=(root) NOPASSWD: /bin/systemctl restart nginx⚠️ NOPASSWDの危険性と絶対パスの原則
スクリプトからの自動実行などで NOPASSWD: を指定する場合、許可するコマンドは必ず「絶対パス（例: /bin/systemctl）」で記述してください。もし相対パスで許可してしまうと、悪意あるユーザーがカレントディレクトリに同名の偽装スクリプトを置き、それをroot権限で実行させてシステムを乗っ取ることが可能になります。
6-2. エイリアス（Alias）を用いたプロの運用設計
大規模な組織では、権限を一人ひとり記述すると管理が破綻します。visudo には変数のようにグループ化できるエイリアス機能があります。
# User_Alias: 開発チームのメンバーを定義
User_Alias DEVELOPERS = kou, satou, suzuki
# Cmnd_Alias: Webサーバーに関連する操作コマンドを定義
Cmnd_Alias WEB_CMDS = /bin/systemctl restart nginx, /bin/systemctl reload nginx, /usr/bin/tail -f /var/log/nginx/error.log
# 権限の紐付け：開発チーム（DEVELOPERS）は、Web操作コマンド（WEB_CMDS）だけを実行できる
DEVELOPERS ALL=(root) WEB_CMDSこのように設定することで、「開発者にはWebサーバーの再起動とログ閲覧の権限だけを渡し、ユーザー追加やOSのアップデート権限は渡さない」といった、極めて緻密な『最小特権の原則（Principle of Least Privilege）』を具現化することができます。
第7章：【実践】プロが行うセキュアなユーザー追加プロセス
これまでの知識を総動員して、現場で「新しいインフラ運用メンバー（takahashi）のアカウントを作成し、完全な管理者権限を付与する」際の、一連のプロフェッショナルなコマンド操作を通しで見てみましょう。
# 1. ユーザーの作成（ホームディレクトリ作成、bash指定、wheelグループへの所属）
sudo useradd -m -s /bin/bash -G wheel takahashi
# 2. 一時的な初期パスワードの設定
sudo passwd takahashi
# 3. 初回ログイン時のパスワード変更を強制（セキュリティ担保）
sudo chage -d 0 takahashi
# 4. SSH公開鍵認証の準備（パスワード認証を禁止している本番環境を想定）
sudo mkdir -m 700 /home/takahashi/.ssh
# (ここに事前のやり取りで受け取った公開鍵 id_rsa.pub の中身を authorized_keys に書き込む)
sudo vi /home/takahashi/.ssh/authorized_keys
# 5. 権限と所有者の厳密な設定
sudo chmod 600 /home/takahashi/.ssh/authorized_keys
sudo chown -R takahashi:takahashi /home/takahashi/.ssh/
# 6. /etc/ssh/sshd_config で PermitRootLogin no になっていることを確認し、SSHを再起動この手順を踏むことで、rootへの直接ログインを禁止したまま、セキュアに新しい管理者を迎え入れることができます。
総まとめ：最小特権の原則がシステムを救う
第4回「ユーザー・グループ管理とアクセス制御の鉄則」、いかがだったでしょうか。
Linuxの要塞化において、ファイアウォールなどの外部防御と同じくらい重要なのが、この「内部の権限管理」です。
/etc/passwdと/etc/shadow： アカウント情報と暗号化パスワードの保管場所と権限の違いを理解する。usermod -aG： サブグループの追加時には絶対に-aを忘れない。chage -d 0： 初回ログイン時のパスワード変更強制で、管理者の関与をなくす。suではなくsudo： rootパスワードを封印し、すべてのアクションを/var/log/secureの監査ログに残す。visudoの徹底： 構文エラーによるロックアウトを防ぎ、エイリアスを用いて必要最小限の権限（最小特権の原則）だけを委譲する。
これらの鉄則を守ることで、誰がいつ何をしたかが透明化され、内部不正やヒューマンエラーによる被害を最小限に食い止める「堅牢なエンタープライズインフラ」を構築することができます。
次回、第5回は「プロセス管理とリソース監視（ps / top / kill）」です。「サーバーが重い！」「謎のプロセスが暴走している！」といったインフラの緊急事態に直面した際、OSの内部（メモリやCPU）で何が起きているのかを可視化し、沈静化させるためのプロの技術を解説します。お楽しみに！リナックス先生でした！
▼ 【セキュアなサーバー環境を自分で構築】 ▼
【rootパスワードを封印したセキュア運用に挑戦】
「高コスパおすすめVPS」
【セキュリティの知識を活かして年収アップ】
「ITエンジニア専門転職」
コメント