機密ファイルへのアクセスを特定ユーザーだけに絞り込む実務設定手順

Linuxサーバーで秘密鍵・パスワードファイル・APIトークンを含む設定ファイルを扱うとき、アクセス権を正しく設定しないと、同一サーバーにログインしている他のユーザーに中身を読まれるリスクがあります。本記事では chmod・chown・setfacl を使った実務的なアクセス制限手順を、現場でよくある設定パターンとともに説明します。

まず結論：所有者だけが読み書きできる状態にする

対象ファイルを所有者だけが読み書きできる状態にするには、chmod 600 を使います。

# ファイルを作成してパーミッションを確認
$ echo "API_KEY=xxxxx" > /home/deploy/.env
$ ls -l /home/deploy/.env
-rw-r--r-- 1 deploy deploy 16 Jul 16 10:00 /home/deploy/.env

# 所有者のみ読み書きに制限
$ chmod 600 /home/deploy/.env
$ ls -l /home/deploy/.env
-rw------- 1 deploy deploy 16 Jul 16 10:00 /home/deploy/.env

この状態では deploy ユーザー本人しかファイルを読み書きできません。root ユーザーはシステム管理者権限でアクセスできますが、一般ユーザーはパーミッション拒否になります。

# 別ユーザーとしてアクセスを試みると拒否される
$ sudo -u anotheruser cat /home/deploy/.env
cat: /home/deploy/.env: Permission denied

Linuxのアクセス権は「誰が・何をできるか」の3層構造

ls -l の出力に表示されるパーミッション文字列は、左から「所有者（owner）」「グループ（group）」「その他（others）」の3層に分かれています。

-rw-r--r--
 ^^^  ^^^  ^^^
 所有者  グループ  その他
 rw-    r--    r--
（読み書き）（読み取りのみ）（読み取りのみ）

数値（8進数）表記では r=4・w=2・x=1 の合計で各層を表します。600 は「所有者：読み書き（6）、グループ：なし（0）、その他：なし（0）」という意味です。ファイルへのアクセスはこの3層を左から順に評価するため、所有者が一致した時点でグループ・その他のルールは参照されません。

用途別パーミッション設定パターン

実務でよく登場するパターンをまとめます。コピペしてそのまま使えます。

# SSH秘密鍵（所有者のみ読み取り。ssh コマンドは 400 または 600 以外を拒否する）
chmod 400 ~/.ssh/id_ed25519

# APIキー・パスワードファイル（所有者のみ読み書き）
chmod 600 /etc/myapp/.env

# 実行スクリプト（所有者のみ実行含む）
chmod 700 /usr/local/bin/backup.sh

# 設定ファイル（所有者読み書き、グループ読み取り）
chmod 640 /etc/myapp/config.yml

# 機密ファイルを格納するディレクトリ（所有者のみ一覧・入室可）
chmod 700 /home/deploy/secrets/

注意が必要なのはディレクトリです。ファイル単体のパーミッションを制限しても、親ディレクトリに x（実行＝入室）権限が残っていれば、パスを知っているユーザーはアクセスを試みられます。機密ファイルを置くディレクトリ自体も合わせて制限してください。

複数人への共有はグループ権限で管理する

「チームメンバー数人にだけ読み取りを許可したい」という場面は、グループを使うのが定石です。ある運用現場では、デプロイ用のAPIキーファイルをグループ権限で共有し、メンバーの追加・削除をグループ管理だけで完結させる運用をしています。担当者が異動になっても、グループから外すだけでアクセスを即時遮断できるため管理コストが下がります。

# グループを作成してメンバーを追加
$ sudo groupadd appteam
$ sudo usermod -aG appteam alice
$ sudo usermod -aG appteam bob

# ファイルのグループ所有者を変更し、グループに読み取りを許可
$ sudo chown deploy:appteam /etc/myapp/config.yml
$ sudo chmod 640 /etc/myapp/config.yml

# 確認
$ ls -l /etc/myapp/config.yml
-rw-r----- 1 deploy appteam 128 Jul 16 10:00 /etc/myapp/config.yml

usermod -aG の -a（append）オプションは必ず付けてください。-a を省略すると、ユーザーが所属している既存のグループがすべて解除されて指定グループのみになるという危険な挙動になります。グループ変更後は対象ユーザーが一度ログインし直さないと新しいグループが有効になりません。即時反映が必要なら newgrp appteam を実行します。

umaskでファイル作成時のデフォルト権限を制御する

ファイルを新規作成したとき「なぜか誰でも読める 644 になっていた」というケースの原因は大抵 umask の設定です。umask は「作成時に削除するパーミッション」を表すマスク値で、通常 0022 が設定されています。

# 現在の umask を確認
$ umask
0022

# umask 0022 の場合、ファイル作成時のデフォルトは 644（666 - 022）
$ touch test.txt && ls -l test.txt
-rw-r--r-- 1 user user 0 Jul 16 10:00 test.txt

# セキュリティを重視するなら umask 0027 を設定（その他への権限を完全に除外）
$ umask 0027
$ touch secret.txt && ls -l secret.txt
-rw-r----- 1 user user 0 Jul 16 10:00 secret.txt

umask の変更をシステム全体に永続適用するには、/etc/profile.d/ 配下にスクリプトを配置します。特定ユーザーだけに適用するなら ~/.bashrc または ~/.profile に記述します。

# 全ユーザーに適用する場合（/etc/profile.d/umask.sh として配置）
echo 'umask 0027' | sudo tee /etc/profile.d/umask.sh
sudo chmod 644 /etc/profile.d/umask.sh

より細かい制御が必要なときはACLを活用する

「所有者でもグループメンバーでもない特定の1ユーザーだけに読み取りを許可したい」など、3層構造では表現できない要件には setfacl（ACL：アクセス制御リスト）が有効です。Ubuntu・Debian・Rocky Linux・AlmaLinux など現代の主要ディストリビューションでは ACL はデフォルトで利用可能です。

# charlie だけに読み取りを追加で許可する
$ sudo setfacl -m u:charlie:r /etc/myapp/config.yml

# ACL 設定を確認
$ getfacl /etc/myapp/config.yml
# file: etc/myapp/config.yml
# owner: deploy
# group: appteam
user::rw-
user:charlie:r--
group::r--
mask::r--
other::---

# ACL 設定を削除する場合
$ sudo setfacl -x u:charlie /etc/myapp/config.yml

ACL が有効なファイルは ls -l の出力でパーミッション文字列の末尾に + が付きます（例：-rw-r-----+）。この + に気づかず chmod だけで管理しようとすると、ACL のルールが残ったまま意図しないアクセスを許してしまうことがあるため注意が必要です。ACL を含むファイルの権限を整理するには setfacl -b で ACL をすべて削除してから再設定するのが確実です。

アクセス制限の設定変更後は、必ず sudo -u 対象ユーザー または別ターミナルで実際にアクセスが拒否されることを確認してから作業を完了としてください。設定ミスは後から気づきにくく、変更直後の動作確認が情報漏洩防止の最後の砦になります。