Checkliste zur Überprüfung von Home-NAS-ACLs für SMB-, NFS- und Containerzugriff

Der sichere Ansatz besteht darin, ein beweisorientiertes ACL-Audit, das Identitäten, effektive Berechtigungen und Vererbung über jeden Zugriffsweg hinweg abbildet, als eine Folge beobachtbarer Prüfpunkte zu behandeln und nicht als einzelnen Befehl.

Bei einem Heim-NAS, das gemeinsame Daten für SMB, NFS und Container exportiert, besteht das praktische Risiko darin, dass derselbe NAS-Pfad über SMB, NFS und Container-Bind-Mounts unterschiedliche effektive Zugriffsrechte gewährt. Erfassen Sie die aktuelle Identität und den Wiederherstellungspunkt, beginnen Sie mit dem am wenigsten invasiven Unterscheidungsmerkmal, interpretieren Sie erfolgreiche und fehlgeschlagene Ergebnisse, bevor Sie eine weitere Variable ändern, und stoppen Sie, sobald der Speicher instabil wird oder die einzige wiederherstellbare Kopie offengelegt würde. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ausgeführt wird oder die Beweise eine Eskalationsgrenze erreichen.

Berechtigungsstatus einfrieren und jede Identität abbilden

Wählen Sie eine repräsentative Freigabe aus und erfassen Sie deren Dataset oder Dateisystem, Exportnamen, SMB-Freigabedefinition, NFS-Export, Container-Bind-Mounts und aktuelle Besitzverhältnisse. Erfassen Sie die numerischen UID- und GID-Werte auf dem NAS und in jedem Container; übereinstimmende Benutzernamen sind kein Beleg dafür, dass die zugrunde liegenden Identitäten übereinstimmen.

POSIX-ACLs fügen benannte Benutzer, benannte Gruppen, Standardeinträge und eine Maske hinzu, die deren effektive Rechte begrenzen kann. Das Maskenverhalten von POSIX-ACLs erklärt, warum die von getfacl angezeigte Maske einen scheinbar großzügigen Eintrag restriktiver wirken lassen kann. Das ist beim Vergleich einer Kommandozeilenansicht mit dem Verhalten von SMB oder NFS entscheidend.

Führen Sie während der Bestandsaufnahme keine rekursiven Befehle wie chmod, chown oder ACL-Ersetzungen aus. Speichern Sie zuerst die Ausgabe von getfacl -p und die Dienstkonfiguration. Die Ausgangsbasis ist erfüllt, wenn jede Clientidentität einer numerischen serverseitigen Identität zugeordnet werden kann oder ausdrücklich als nicht zugeordnet gekennzeichnet ist.

Effektiven Zugriff über jedes Protokoll testen

Erstellen Sie einen dedizierten Audit-Benutzer und ein temporäres Verzeichnis unterhalb der Freigabe. Testen Sie von Windows oder macOS über SMB, von einem Linux-NFS-Client und aus dem Zielcontainer jeweils getrennt das Auflisten, Lesen, Erstellen, Umbenennen und Löschen. Erfassen Sie nach jeder Operation Besitzer, Gruppe, Modus, ACL und verwendetes Protokoll.

Halten Sie Authentifizierung und Dateisystemautorisierung getrennt. Eine SMB-Anmeldung kann erfolgreich sein, während der zugeordnete Unix-Benutzer keine Schreibberechtigung besitzt. Ein NFS-Client kann eine numerische ID übermitteln, die der Server akzeptiert, die aber dem falschen lokalen Besitzer zugeordnet wird. Ändern Sie zwischen den Tests jeweils nur eine Identitäts- oder ACL-Variable.

Ein Pfad besteht den Test nur, wenn die beobachteten Rechte mit der vorgesehenen Zugriffsmatrix übereinstimmen und neu erstellte Dateien den erwarteten Besitzer, die erwartete Gruppe und die erwartete Standard-ACL erhalten. Wenn sich ein Protokoll unterscheidet, stoppen Sie umfassende Änderungen und verfolgen Sie zunächst die Zuordnungsschicht dieses Protokolls, bevor Sie das gemeinsame Dateisystem verändern.

Vererbung, Masken und Container-Zuordnungen prüfen

Vergleichen Sie die Standard-ACL des übergeordneten Verzeichnisses mit der Zugriffs-ACL neu erstellter Dateien und Verzeichnisse. Prüfen Sie die ACL-Maske nach Gruppenänderungen, bestätigen Sie, ob der SMB-Dienst Erstellungs- oder Verzeichnismasken anwendet, und ermitteln Sie, welche Anwendungen Dateien atomar ersetzen, da beim Ersetzen eine andere Vererbung entstehen kann als bei Änderungen an Ort und Stelle.

Prüfen Sie bei Containern den Laufzeitbenutzer, ergänzende Gruppen, die Zuordnung von Benutzer-Namespaces und den eingebundenen Hostpfad. Der zugehörige ZimaSpace-Leitfaden zu Datenbankzugriff auf einem netzwerkgebundenen Docker-Volume ist hilfreich, wenn die NFSv4-Namenszuordnung die fehlerhafte Schicht ist. Dieses Audit konzentriert sich weiterhin darauf, die durchgängigen Rechte über alle drei Pfade nachzuweisen.

Beheben Sie ein Zuordnungsproblem nicht, indem Sie die Anwendung als root ausführen. Wenn der Container die temporäre Datei nicht erstellen kann, gleichen Sie seine unterstützte UID, GID oder ergänzende Gruppe an die NAS-Richtlinie an und wiederholen Sie denselben Test, bevor Sie einen Produktivbaum ändern.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Die engste Korrektur anwenden und Beweise bewahren

Korrigieren Sie jeweils nur eine Schicht: zuerst die Identitätszuordnung, danach die Gruppenmitgliedschaft, anschließend die geerbten Standardeinstellungen und zuletzt spezielle Datei-ACLs. Wenden Sie Änderungen auf das temporäre Verzeichnis an, überprüfen Sie erneut alle Operationen und bereiten Sie erst danach eine begrenzte Änderung für den Produktivunterbaum mit einer gespeicherten Wiederherstellungs-ACL vor.

Starten Sie nach der Einführung Clients neu oder verbinden Sie sie erneut, wenn sie Anmeldedaten zwischenspeichern, hängen Sie NFS bei Bedarf erneut ein und starten Sie nur Container neu, deren Gruppenliste beim Prozessstart festgelegt wird. Wiederholen Sie dieselbe Testmatrix und überprüfen Sie, dass sowohl vorhandene als auch neue Dateien wie vorgesehen funktionieren.

Das Audit ist abgeschlossen, wenn jede erlaubte und verweigerte Aktion mit der dokumentierten Matrix übereinstimmt, neue Objekte korrekt erben und die gespeicherte ACL den vorherigen Zustand wiederherstellen kann. Eskalieren Sie, statt blind rekursiv vorzugehen, wenn Besitzverhältnisse absichtlich gemischt sind, Snapshots oder Hardlinks den Rollback erschweren oder der NAS-Speicher Fehler meldet.