標準的なLinuxパーミッションの限界
多くのシステム管理者は、伝統的なユーザー・グループ・その他(UGO)モデルを利用しています。chmodやchownは日常業務の90%をカバーしてくれますが、複雑なマルチユーザー環境では限界があります。以前、www-dataが所有する特定のログディレクトリに対して、開発者に書き込み権限を与える必要があるプロジェクトを担当したことがあります。グループ所有権を変更するとアプリケーションのロジックが壊れる可能性があり、かといって777パーミッションを付与するのはセキュリティ上の大きなリスクでした。
アクセス制御リスト(ACL)とファイル属性(Chattr)は、こうしたシナリオで必要とされる精度を提供します。ACLを使用すると、主要な所有権を変更することなく特定のユーザーに権限を割り当てることができます。一方、chattrはファイルを「不変(immutable)」にすることができ、rootユーザーが誤ってrm -rfコマンドを実行したとしてもファイルを保護できます。15以上の本番VPSインスタンスを管理してきた経験から、これらのツールは構成の乖離(コンフィグレーション・ドリフト)を防ぐために不可欠だと感じています。
環境の準備
Ubuntu 22.04、Debian 12、AlmaLinux 9などの最新ディストリビューションでは、通常デフォルトでACLサポートが有効になっています。レガシーなシステムや最小構成のコンテナイメージを使用している場合は、ユーティリティを手動でインストールする必要があるかもしれません。これはわずか200KB程度の小さなパッケージですが、非常に強力な制御を可能にします。
ACLツールのインストール
これらのパーミッション管理を開始するには、システムにaclパッケージがインストールされていることを確認してください。
# DebianまたはUbuntuユーザーの場合
sudo apt update && sudo apt install acl -y
# RHEL、CentOS、またはAlmaLinuxユーザーの場合
sudo yum install acl -y
ファイルシステムの互換性の確認
ACLを使用するには、ファイルシステムがACLをサポートしている必要があります。Ext4、XFS、Btrfsはネイティブでサポートしていますが、/etc/fstabを確認するかmountコマンドを実行することでマウントオプションを検証できます。最新のカーネルでは、これらの機能は通常デフォルトのマウントフラグに組み込まれているため、手動での設定が必要になることは稀です。
ACLによるアクセスの微調整
ACLは従来のパーミッションビットを拡張します。1つの所有者と1つのグループに制限される代わりに、複数のユーザーやグループの詳細なリストを作成し、それぞれに固有の読み取り、書き込み、実行権限を設定できます。
特定のユーザーへのアクセス権限の付与
例えば、rootが所有する設定ファイルに対して、”jdoe”というユーザーがフルアクセス権限を必要としているシナリオを想定してください。ファイルの所有者を変更する代わりに、setfaclコマンドを使用します。
sudo setfacl -m u:jdoe:rwx /var/www/html/config.php
-mフラグは、リストを変更(modify)することをシステムに伝えます。ls -lを実行すると、パーミッション文字列の末尾に+記号が表示されます(例:-rw-rwxr--+)。この記号は、そのファイルにACLが適用されていることを示す視覚的な合図です。
デフォルトACLによるパーミッションの自動化
強力なテクニックの1つに、ディレクトリにデフォルトACLを設定する方法があります。これにより、そのフォルダ内に作成されるすべての新しいファイルが、定義済みのパーミッションセットを自動的に継承するようになります。これは、共有チーム環境やデプロイパイプラインにおいて大幅な時間の節約になります。
# 今後作成されるすべてのファイルに対して 'developers' グループに rwx 権限を強制する
sudo setfacl -d -m g:developers:rwx /opt/project_files
ACL権限の取り消し
特定のエントリを削除したり、設定を完全にリセットしたりすることも簡単です。特定のユーザーを削除するには-xフラグを、すべての拡張パーミッションを削除して標準のUGO設定に戻すには-bフラグを使用します。
# 特定のユーザーのアクセス権を削除する
sudo setfacl -x u:jdoe /var/www/html/config.php
# ファイルからすべてのACLをクリアする
sudo setfacl -b /var/www/html/config.php
Chattr属性によるファイルのロック
ACLは「誰が」ファイルに触れられるかを定義しますが、chattrはファイルに対して「何ができるか」を定義します。これらの属性はファイルシステムレベルで機能します。非常に強力で、属性が削除されるまではrootユーザーであってもファイルを変更できなくなります。
不変ビット (+i)
これは/etc/resolv.confのような重要なシステムファイルにとって救世主となります。このビットを設定すると、再起動中にスクリプトや誤ったコマンドによってDNS設定が上書きされるのを防ぐことができます。
# ファイルをいかなる変更からもロックする
sudo chattr +i /etc/important_config.conf
このファイルを削除しようとすると、たとえsudoを使用しても「Operation not permitted(許可されていない操作)」エラーが発生します。ファイルを再度編集するには、まず明示的にsudo chattr -iを実行する必要があります。
追記専用ビット (+a)
この属性はセキュリティログに最適です。システムの末尾への新しいデータの追加は許可しますが、既存のエントリの削除や変更は禁止します。これは、改ざん防止機能を持つ基本的なロギングシステムを構築する簡単な方法です。
sudo chattr +a /var/log/custom_audit.log
検証とベストプラクティス
lsのような標準ツールでは、セキュリティ設定の全容を確認することはできません。適用した隠れたパーミッションレイヤーを確認するには、専用のコマンドを使用する必要があります。
getfaclとlsattrによる監査
ファイルに割り当てられているユーザーとグループの全リストを確認するには、getfaclを使用します。属性を確認するには、lsattrを使用します。ファイルが保護されている場合、lsattrの出力文字列にiやaが表示され、ファイルシステムレベルでロックされていることがわかります。
現場からの教訓
「パーミッションの乱立(スプロール)」は避けてください。何百もの個別のファイルに固有のACLを適用すると、セキュリティ監査が管理上の悪夢になります。AnsibleやChefなどの構成管理スクリプトで、非標準のACLをドキュメント化しておくことをお勧めします。
chattrはファイルシステムに依存することに注意してください。Ext4やXFSでは完璧に動作しますが、NFSのようなネットワークアタッチドストレージではこれらの属性が無視されることがよくあります。本番環境のセキュリティをこれらに頼る前に、必ず特定のストレージスタックでの動作をテストしてください。ACLとchattrを組み合わせることで、chmodだけでは実現できない堅牢な防御が可能になります。

