※本記事にはプロモーション（広告）を含みます。

Linuxサーバーの権限設計はまず「最小権限の原則」を徹底することが出発点です。必要な操作だけを許可する形でユーザーとグループを設計すれば、設定ミスによる情報漏えいや誤操作のリスクを大幅に抑えられます。本記事ではLinuxのユーザー管理とグループ管理の基本構造から、実務で使えるパーミッション設計、sudoによる権限委譲の考え方までを体系的に整理します。バージョンによってコマンドの挙動が異なる場合があるため、実際の運用では利用しているディストリビューションの公式ドキュメントも合わせて確認してください。

目次

  • Linuxユーザー管理の基礎
  • グループ管理の仕組みと運用
  • パーミッション設計の基本
  • sudoによる権限委譲の設計
  • 実践的な権限設計パターン
  • よくある質問
  • まとめ

Linuxユーザー管理の基礎

Linuxのユーザー管理を理解するうえで最初に押さえるべきは、システムがユーザーを「名前」ではなく「UID(User ID)」という数値で識別している点です。ユーザー名は人間が扱いやすくするための表示上のラベルにすぎず、内部処理はすべてUIDを基準に行われます。この構造を知らずに設計を進めると、後からUIDの重複やroot権限の誤付与といったトラブルに気づきにくくなります。

ユーザーの種類とUIDの範囲

Linuxのユーザーは大きく分けて3種類存在します。UID0はrootユーザー専用で、システム上のあらゆる操作を制限なく実行できる特別な存在です。UID1〜999程度の範囲はシステムユーザーと呼ばれ、デーモンプロセスやミドルウェアの実行専用アカウントに割り当てられます。UID1000以降が一般ユーザー用の範囲で、実際にログインして作業する人間のアカウントはここに作成されます。この範囲はディストリビューションによって多少差があるため、/etc/login.defsの設定値で確認できます。

/etc/passwdの構造を読み解く

ユーザー情報は/etc/passwdファイルにコロン区切りで記録されています。各行は「ユーザー名:パスワード欄:UID:GID:コメント:ホームディレクトリ:ログインシェル」という7つのフィールドで構成されます。パスワード欄は現在ほとんどの環境で「x」と表示され、実際のハッシュ値は/etc/shadowに分離して保存される仕組みになっています。この分離により、一般ユーザーが読み取り可能な/etc/passwdからパスワードハッシュを直接盗み見ることができないよう保護されています。

フィールド内容設計上の注意点
ユーザー名ログイン時に使う識別子役割が分かる命名にすると監査しやすくなります
UID数値の一意識別子1000未満はシステム用途と重複させないよう注意します
GIDプライマリグループのID用途ごとにグループを分けると権限管理が明確になります
ホームディレクトリ個人用作業領域パーミッションを750程度に絞ると安全性が高まります
ログインシェル起動されるシェルログイン不要なアカウントは/usr/sbin/nologinを指定します

useradd・usermodによるアカウント操作

ユーザーの新規作成にはuseraddコマンドを使います。useradd -m -s /bin/bash -c "システム担当" tanakaのように実行すると、ホームディレクトリを自動作成しつつシェルを指定できます。既存ユーザーの設定を変更する場合はusermodコマンドを利用し、パスワードの有効期限やログインシェルの変更などをまとめて管理できます。アカウントを削除する際はuserdeleteではなくuserdelコマンドを使い、ホームディレクトリごと削除したい場合は-rオプションを付けます。誤って現役の共有ディレクトリまで削除しないよう、実行前にホームディレクトリの中身を確認する運用を徹底することが実務では欠かせません。

グループ管理の仕組みと運用

Linuxのグループ機能は、複数のユーザーに対して共通の権限をまとめて付与するための仕組みです。個々のユーザーに毎回同じ権限を設定する手間を省けるだけでなく、退職や異動によるアカウント変更が発生した際もグループの所属関係を変更するだけで対応が完結する点が実務上のメリットになります。

プライマリグループとセカンダリグループ

Linuxのユーザーは必ず1つのプライマリグループに所属し、加えて複数のセカンダリグループ（補助グループ）にも所属できます。プライマリグループは新規作成したファイルの所有グループとして自動的に反映される点が特徴です。一方セカンダリグループは、特定のリソースへのアクセス権を追加で付与したい場合に利用します。例えばWebサーバーの設定ファイルを編集する権限だけを一部のメンバーに与えたい場合、専用のグループを作成してセカンダリグループとして所属させる方法が現実的です。

/etc/groupとgroupaddコマンド

グループ情報は/etc/groupファイルに「グループ名:パスワード欄:GID:所属ユーザーリスト」という形式で記録されています。新規グループの作成にはgroupaddコマンドを使い、groupadd developersのように実行するだけで完了します。既存ユーザーをセカンダリグループに追加する場合はusermodコマンドに-aGオプションを組み合わせます。-aを付け忘れると既存の所属グループがすべて上書きされてしまうため、この操作は特に注意が必要です。

  • グループ作成: groupadd finance
  • ユーザーをグループへ追加: usermod -aG finance tanaka
  • 所属グループの確認: groups tanakaまたはid tanaka
  • グループからの削除: gpasswd -d tanaka finance

グループ設計で避けたい失敗パターン

グループ設計でよくある失敗は、部署名だけで大雑把にグループを分けてしまい、実際に必要な権限単位と一致しないケースです。例えば「営業部グループ」を作っても、営業部の中に閲覧のみでよいメンバーと編集が必要なメンバーが混在していれば、結局個別に例外設定を追加する羽目になります。権限が必要な操作単位（読み取り専用・編集可能・管理者相当など）でグループを分割し、そのうえで人事上の所属とは別軸で運用する設計のほうが、長期的な保守性は高くなります。

パーミッション設計の基本

Linuxのファイルやディレクトリには、所有者(owner)・所有グループ(group)・その他(others)という3つの主体に対して、読み取り(r)・書き込み(w)・実行(x)の権限が個別に設定されています。この仕組みを正確に理解しないままchmod 777のような設定を安易に使うと、意図しない第三者からの改ざんリスクが生まれます。

rwx表記と数値表記の対応

パーミッションは記号表記(rwx)と数値表記(0〜7)のどちらでも指定できます。読み取り権限は4、書き込み権限は2、実行権限は1という重みが割り当てられており、これらを合計した数値で権限を表現します。例えば読み書き実行すべてを許可する場合は4+2+1で7、読み取りと実行だけなら4+1で5となります。この数値を所有者・グループ・その他の順に3桁並べることで、chmod 750のような設定が意味を持ちます。

数値記号意味
7rwx読み取り・書き込み・実行すべて許可
6rw-読み取りと書き込みのみ許可
5r-x読み取りと実行のみ許可
4r–読み取りのみ許可
0—権限なし

chmod・chown・chgrpの実践

ファイルの権限を変更するにはchmodコマンド、所有者を変更するにはchownコマンド、所有グループのみを変更するにはchgrpコマンドを使います。設定ファイル用のディレクトリであればchmod 750 /opt/app/configのように所有者とグループにのみアクセスを許可し、その他ユーザーからは一切アクセスできないようにする設計が一般的です。所有者とグループをまとめて変更したい場合はchown tanaka:developers file.txtのようにコロンで区切って指定できます。

特殊権限とディレクトリのデフォルト所有

通常のrwx以外に、SUID・SGID・スティッキービットという特殊な権限も存在します。特にSGIDをディレクトリに付与すると、そのディレクトリ内で新規作成されたファイルの所有グループが自動的に親ディレクトリと同じグループに揃うため、複数人で共同編集する共有ディレクトリの管理に役立ちます。設定はchmod g+s /shared/projectのように行い、数値表記では先頭に2を付けてchmod 2770のように指定します。SUIDについては実行ファイルの所有者権限で処理が走る強力な機能である一方、設定を誤ると権限昇格の脆弱性につながりかねないため、必要な場面以外では付与しない方針が無難です。

sudoによる権限委譲の設計

root権限をすべてのユーザーに共有パスワードで使い回す運用は、誰がいつ何を実行したのか追跡できなくなるため避けるべき方法です。sudoコマンドを使えば、一般ユーザーが自分のパスワードで一時的に管理者権限相当の操作を実行でき、かつ実行内容をログに残せます。

sudoersファイルとvisudoコマンド

sudoの権限設定は/etc/sudoersファイルに記述されますが、このファイルは直接テキストエディタで開いて編集すべきではありません。構文エラーが発生するとsudoコマンド自体が使えなくなり、最悪の場合システムから管理者権限で操作できなくなるためです。専用のvisudoコマンドを使えば、保存時に自動で構文チェックが走るため、記述ミスによるロックアウトを未然に防げます。

sudoグループの活用と個別権限の限定

多くのディストリビューションでは、wheelグループやsudoグループに所属させるだけで管理者権限を付与できる仕組みが用意されています。ただし全ユーザーをまとめてこのグループに入れてしまうと、最小権限の原則から外れてしまいます。特定のコマンドだけを許可したい場合は、sudoers内で%deploy ALL=(ALL) /usr/bin/systemctl restart nginxのように、許可するコマンドをピンポイントで指定する記述が有効です。これにより、デプロイ担当者にはサービスの再起動権限だけを与え、それ以外の管理操作はroot以外に許可しないという設計が実現できます。

操作ログの記録と監査

sudoで実行されたコマンドは標準で/var/log/auth.logやsecureログに記録されます。誰がどのタイミングでどのコマンドを実行したかを追跡できる状態を保つことは、インシデント発生時の原因調査にも直結します。加えてauditdのようなログ監査の仕組みを併用すれば、ファイルの読み書きやパーミッション変更といった操作までより詳細に記録できます。ログの保存期間や監視体制については、扱うシステムの重要度に応じて事前に運用ルールを定めておくことが望まれます。

実践的な権限設計パターン

ここまでの要素を組み合わせ、実際の業務システムで使える権限設計の考え方を整理します。

部署・役割別グループ設計の例

複数の部署が同一サーバーを利用する場合、役割ごとにグループを分割し、必要なディレクトリのみアクセスを許可する設計が基本形になります。以下は一例です。

グループ名用途付与する権限の目安
developersアプリケーションコードの編集/opt/appに対してrwx
deployデプロイ作業専用特定サービスの再起動コマンドのみ
readonly-audit監査担当の閲覧用ログディレクトリへの読み取りのみ
backup-opバックアップ運用担当バックアップ先ディレクトリへの書き込み

サービスアカウントの隔離

Webサーバーやデータベースなど、デーモンプロセスが使うサービスアカウントは人間用のログインアカウントとは明確に分離して設計します。ログインシェルを/usr/sbin/nologinに設定し、対話的なログインができない状態にしておくことで、万が一そのアカウントの資格情報が漏えいしてもリモートログインによる被害拡大を防ぎやすくなります。また、サービスごとに専用のUIDを割り当て、他のプロセスとファイルの所有権を混在させない設計が推奨されます。

定期棚卸しによる権限の見直し

権限設計は一度作って終わりではなく、定期的な棚卸しが必要な作業です。異動や退職に伴って不要になったグループ所属が残り続けると、意図しない範囲までアクセスできる状態が放置されてしまいます。lastlogコマンドで長期間ログインのないアカウントを洗い出し、getent groupで各グループの所属者一覧を定期的に確認する運用を組み込むと、権限の肥大化を防ぎやすくなります。棚卸しの頻度はシステムの重要度に応じて四半期ごとなど、あらかじめ社内ルールとして定めておくことが望ましい進め方です。

よくある質問

Q. rootとsudoはどちらを使うべきですか

常時rootでログインする運用は操作履歴の追跡が難しくなるため、一般ユーザーでログインしてsudoを都度使う運用のほうが監査性に優れています。root直接ログインは緊急時など限定的な場面にとどめる設計が一般的です。

Q. chmod 777を使ってもよい場面はありますか

全ユーザーに読み書き実行を許可する777は、第三者からの改ざんリスクを高めるため本番環境では避けるべき設定です。一時的な検証用ディレクトリなど、影響範囲が限定された場面以外での常用は推奨されません。

Q. UIDとGIDの重複は問題になりますか

UIDが重複すると同一のIDに複数のユーザー名が紐づく状態になり、ログの追跡やファイル所有者の特定が困難になります。新規作成時はuseraddが自動で空きIDを割り当てますが、手動指定する場合は既存IDとの重複がないか事前に確認する必要があります。

Q. グループのパスワードは設定すべきですか

/etc/groupにはグループパスワードの欄がありますが、現在のLinux運用ではgpasswdによるグループパスワード管理はほとんど使われません。多くの現場ではsudoやアクセス制御リスト(ACL)による権限管理が主流になっています。

Q. ACLはパーミッションとどう違いますか

通常のrwxパーミッションは所有者・グループ・その他の3主体しか指定できませんが、ACL(アクセス制御リスト)を使うと特定の複数ユーザーや複数グループに対して個別の権限を細かく設定できます。setfaclコマンドで設定し、getfaclコマンドで確認できるため、通常のパーミッションだけでは表現しきれない複雑な権限要件がある場合に検討する価値があります。

関連記事

まとめ

Linuxのユーザーとグループ管理は、UIDとGIDという数値識別の仕組みを理解することが土台になります。そのうえでプライマリグループとセカンダリグループを使い分け、rwxパーミッションを最小権限の原則に沿って設計すれば、不要なアクセス権が広がるリスクを抑えられます。sudoによる権限委譲とログ記録を組み合わせれば、root権限を安易に共有せずに運用の透明性を保てます。設計した権限は一度で完成させるものではなく、部署異動やサービス構成の変化に応じて定期的に棚卸しを行う前提で運用してください。具体的なコマンドオプションや設定ファイルの仕様は利用中のディストリビューションのバージョンによって差があるため、実際の設定変更前には公式ドキュメントで最新の挙動を確認することが安全な運用につながります。

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
ABOUT ME
たから
フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営