Controlelijst voor ACL-audit van thuis-NAS voor SMB-, NFS- en containertoegang

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

De veilige aanpak is om een op bewijs gebaseerde ACL-audit, die identiteiten, effectieve machtigingen en overerving via elk toegangspad in kaart brengt, te behandelen als een reeks waarneembare poorten en niet als één enkele opdracht.

Op een thuis-NAS die gedeelde gegevens exporteert naar SMB, NFS en containers, is het praktische risico hetzelfde: hetzelfde NAS-pad verleent via SMB, NFS en bind-mounts van containers verschillende effectieve toegang. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende test, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop wanneer de opslag instabiel wordt of de enige herstelbare kopie zou worden blootgesteld. De onderstaande workflow eindigt pas nadat de oorspronkelijke workload slaagt of het bewijs een escalatiegrens bereikt.

Bevries de machtigingstoestand en breng elke identiteit in kaart

Kies één representatieve share en leg de bijbehorende dataset of het bestandssysteem, exportnamen, SMB-sharedefinitie, NFS-export, bind-mounts van containers en huidige eigenaars vast. Leg numerieke UID- en GID-waarden vast op de NAS en in elke container; overeenkomende gebruikersnamen zijn geen bewijs dat de onderliggende identiteiten overeenkomen.

POSIX-ACL's voegen benoemde gebruikers, benoemde groepen, standaardvermeldingen en een masker toe dat hun effectieve rechten kan beperken. Het maskergedrag van POSIX-ACL's verklaart waarom het masker dat door getfacl wordt weergegeven, ervoor kan zorgen dat een ogenschijnlijk ruime vermelding zich beperkter gedraagt. Dat is essentieel bij het vergelijken van een opdrachtregelweergave met SMB- of NFS-gedrag.

Voer tijdens de inventarisatie geen recursieve chmod, chown of ACL-vervanging uit. Bewaar eerst de uitvoer van getfacl -p en de serviceconfiguratie; de basislijn slaagt wanneer elke clientidentiteit kan worden gekoppeld aan een numerieke identiteit aan de serverzijde of expliciet als niet-toegewezen is gemarkeerd.

Test effectieve toegang via elk protocol

Maak een speciale auditgebruiker en een wegwerpmap onder de share. Test vanuit Windows of macOS via SMB, vanaf een Linux-NFS-client en vanuit de doelcontainer afzonderlijk het weergeven, lezen, maken, hernoemen en verwijderen. Leg na elke bewerking de eigenaar, groep, modus, ACL en het gebruikte protocol vast.

Houd authenticatie en bestandssysteemautorisatie gescheiden. Een SMB-aanmelding kan slagen terwijl de toegewezen Unix-identiteit geen schrijfmachtiging heeft; een NFS-client kan een numerieke ID aanbieden die de server accepteert, maar die naar de verkeerde lokale eigenaar verwijst. Wijzig tussen tests slechts één identiteits- of ACL-variabele.

Een pad slaagt alleen wanneer de waargenomen rechten overeenkomen met de beoogde toegangsmatrix en nieuw gemaakte bestanden de verwachte eigenaar, groep en standaard-ACL krijgen. Als één protocol afwijkt, stop dan met brede wijzigingen en traceer eerst de toewijzingslaag van dat protocol voordat je het gedeelde bestandssysteem aanraakt.

Controleer overerving, maskers en containertoewijzingen

Vergelijk de standaard-ACL van de bovenliggende map met de toegangs-ACL op nieuw gemaakte bestanden en mappen. Controleer het ACL-masker na groepswijzigingen, bevestig of de SMB-service create- of directory-maskers toepast en identificeer toepassingen die bestanden atomair vervangen, omdat vervanging tot andere overerving kan leiden dan bewerkingen ter plaatse.

Controleer voor containers de runtimegebruiker, aanvullende groepen, toewijzing van gebruikersnaamruimten en het aan de host gekoppelde pad. De gerelateerde ZimaSpace-handleiding over databasetoegang op een via het netwerk gekoppeld Docker-volume is nuttig wanneer NFSv4-naamtoewijzing de falende laag is; deze audit blijft gericht op het aantonen van de end-to-end-rechten via alle drie de paden.

Los een toewijzingsprobleem niet op door de toepassing als root uit te voeren. Als de container het wegwerpbestand niet kan maken, stem dan de ondersteunde UID, GID of aanvullende groep ervan af op het NAS-beleid en herhaal dezelfde test voordat je een productiestructuur wijzigt.

Pas de beperktste correctie toe en bewaar het bewijs

Corrigeer één laag tegelijk: eerst identiteitstoewijzing, daarna groepslidmaatschap, vervolgens overgeërfde standaardinstellingen en als laatste uitzonderlijke bestands-ACL's. Pas wijzigingen toe op de wegwerpmap, controleer alle bewerkingen opnieuw en bereid pas daarna een beperkte wijziging voor de productiesubstructuur voor, met een opgeslagen terugdraai-ACL.

Start na de uitrol clients die inloggegevens cachen opnieuw of verbind ze opnieuw, koppel NFS opnieuw waar nodig en start alleen containers opnieuw waarvan de groepslijst bij het starten van het proces wordt vastgelegd. Herhaal dezelfde testmatrix en controleer of zowel bestaande als nieuwe bestanden zich gedragen zoals bedoeld.

De audit is afgerond wanneer elke toegestane en geweigerde actie overeenkomt met de vastgelegde matrix, nieuwe objecten correct overerven en de opgeslagen ACL de vorige toestand kan herstellen. Escaleer in plaats van blind recursief te werk te gaan wanneer eigenaarschap opzettelijk gemengd is, snapshots of harde koppelingen het terugdraaien bemoeilijken of de NAS-opslag fouten rapporteert.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.