SMB、NFS、コンテナアクセス向けホームNAS ACL監査チェックリスト

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Home NAS ACL Audit Checklist for SMB, NFS, and Container Access - Zima Store Online

安全なアプローチは、ID、実効権限、すべてのアクセス経路における継承を対応付ける証拠優先のACL監査を、単一のコマンドではなく、観測可能なゲートの連続として扱うことです。

共有データをSMB、NFS、コンテナへエクスポートするホームNASでは、実際のリスクは、同じNASパスがSMB、NFS、コンテナのバインドマウントを通じて異なる実効アクセスを許可することです。現在のIDと復旧ポイントを記録し、最も侵襲性の低い判別から始め、別の変数を変更する前に合否の結果を解釈し、ストレージが不安定になった場合、または復旧可能な唯一のコピーが露出する場合は中止します。以下のワークフローは、元のワークロードが成功するか、証拠がエスカレーション境界に達した時点でのみ完了します。

権限状態を凍結し、すべてのIDを対応付ける

代表的な共有を1つ選び、そのデータセットまたはファイルシステム、エクスポート名、SMB共有定義、NFSエクスポート、コンテナのバインドマウント、現在の所有権を記録します。NAS上と各コンテナ内で数値UIDおよびGIDを取得します。ユーザー名が一致していても、基盤となるIDが一致する証拠にはなりません。

POSIX ACLには、名前付きユーザー、名前付きグループ、デフォルトエントリ、および実効権限を制限できるマスクが追加されます。POSIX ACLのマスク動作では、getfaclに表示されるマスクによって、一見寛大なエントリがより狭く適用される理由を説明しています。これは、コマンドラインの表示とSMBまたはNFSの動作を比較する際に不可欠です。

インベントリ中に再帰的なchmod、chown、またはACLの置換を実行しないでください。まずgetfacl -pの出力とサービス設定を保存します。すべてのクライアントIDを数値のサーバー側IDに結び付けられるか、明示的に未対応として記録できれば、ベースラインは合格です。

各プロトコル経由の実効アクセスをテストする

専用の監査ユーザーと、共有配下に破棄可能なディレクトリを作成します。WindowsまたはmacOSからSMB経由で、LinuxのNFSクライアントから、そして対象コンテナから、一覧表示、読み取り、作成、名前変更、削除を個別にテストします。各操作の後に、所有者、グループ、モード、ACL、使用したプロトコルを記録します。

認証とファイルシステム認可を分けて考えます。SMBログインが成功しても、対応付けられたUnix IDに書き込み権限がない場合があります。NFSクライアントがサーバーに受け入れられる数値IDを提示しても、それが誤ったローカル所有者に解決されることがあります。テスト間では、1つのIDまたはACL変数だけを変更してください。

観測された権限が意図したアクセスマトリクスと一致し、新しく作成されたファイルに期待どおりの所有者、グループ、デフォルトACLが付与される場合にのみ、パスは合格です。1つのプロトコルだけが異なる場合は、広範な変更を中止し、共有ファイルシステムに触れる前に、そのプロトコルのマッピング層を追跡します。

継承、マスク、コンテナのマッピングを調べる

親のデフォルトACLと、新しく作成されたファイルおよびディレクトリのアクセスACLを比較します。グループ変更後のACLマスクを確認し、SMBサービスが作成マスクまたはディレクトリマスクを適用するかを確認します。また、ファイルをインプレース編集ではなくアトミックに置き換えるアプリケーションを特定します。置換によって、継承が異なる場合があるためです。

コンテナについては、実行時ユーザー、補助グループ、ユーザーネームスペースの再マッピング、バインドマウントされたホストパスを調べます。ネットワークマウントされたDockerボリューム上のデータベースアクセスに関するZimaSpaceの関連ガイドは、NFSv4の名前マッピング層が失敗している場合に役立ちます。この監査では、3つすべての経路におけるエンドツーエンドの権限の証明に焦点を置きます。

アプリケーションをrootとして実行して、マッピング問題を解決しようとしないでください。コンテナが破棄可能なファイルを作成できない場合は、サポートされているUID、GID、または補助グループをNASのポリシーに合わせ、本番ツリーを変更する前に同じテストを繰り返します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

最も限定的な修正を適用し、証拠を保持する

一度に1つの層を修正します。まずIDマッピング、次にグループメンバーシップ、その次に継承されたデフォルト、最後に例外的なファイルACLの順です。変更は破棄可能なディレクトリに適用し、すべての操作を再度確認してから、保存したロールバック用ACLとともに、本番サブツリーに対する範囲を限定した変更を段階的に適用します。

展開後は、認証情報をキャッシュするクライアントを再起動または再接続し、必要に応じてNFSを再マウントします。また、プロセス起動時にグループ一覧が固定されるコンテナだけを再起動します。同じテストマトリクスを繰り返し、既存ファイルと新規ファイルの両方が意図どおりに動作することを確認します。

許可および拒否されるすべての操作が記述したマトリクスと一致し、新しいオブジェクトが正しく継承され、保存したACLで以前の状態を復元できれば、監査は完了です。所有権が意図的に混在している場合、スナップショットやハードリンクによってロールバックが複雑になる場合、またはNASストレージがエラーを報告している場合は、無闇に再帰処理を行わず、エスカレーションしてください。