Checklist di audit ACL per NAS domestici per accesso SMB, NFS e container

L'approccio sicuro consiste nel trattare un audit ACL basato innanzitutto sulle evidenze, che mappa identità, autorizzazioni effettive ed ereditarietà lungo ogni percorso di accesso, come una sequenza di controlli osservabili, non come un singolo comando.

Su un NAS domestico che esporta dati condivisi tramite SMB, NFS e container, il rischio pratico è che lo stesso percorso del NAS conceda livelli di accesso effettivi diversi tramite SMB, NFS e mount bind dei container. Registra l'identità attuale e il punto di ripristino, inizia dal discriminante meno invasivo, interpreta i risultati positivi e negativi prima di modificare un'altra variabile e fermati quando lo storage diventa instabile o l'unica copia recuperabile verrebbe esposta. Il flusso di lavoro seguente termina solo quando il carico di lavoro originale ha esito positivo oppure le evidenze raggiungono una soglia di escalation.

Blocca lo stato delle autorizzazioni e mappa ogni identità

Scegli una condivisione rappresentativa e registra il relativo dataset o filesystem, i nomi delle esportazioni, la definizione della condivisione SMB, l'esportazione NFS, i mount bind dei container e la proprietà attuale. Acquisisci i valori numerici di UID e GID sul NAS e all'interno di ogni container; la corrispondenza dei nomi utente non dimostra che le identità sottostanti coincidano.

Le ACL POSIX aggiungono utenti denominati, gruppi denominati, voci predefinite e una maschera che può limitare i relativi diritti effettivi. Il comportamento della maschera ACL POSIX spiega perché la maschera mostrata da getfacl può far sì che una voce apparentemente permissiva si comporti in modo più restrittivo, un aspetto essenziale quando si confronta la vista dalla riga di comando con il comportamento SMB o NFS.

Non eseguire chmod, chown o sostituzioni ricorsive delle ACL durante l'inventario. Salva prima l'output di getfacl -p e la configurazione dei servizi; la baseline è superata quando ogni identità client può essere associata a un'identità numerica sul server oppure contrassegnata esplicitamente come non mappata.

Testa l'accesso effettivo tramite ogni protocollo

Crea un utente dedicato all'audit e una directory temporanea sotto la condivisione. Da Windows o macOS tramite SMB, da un client Linux NFS e dal container di destinazione, testa separatamente l'elenco, la lettura, la creazione, la ridenominazione e l'eliminazione. Dopo ogni operazione, registra proprietario, gruppo, modalità, ACL e protocollo utilizzato.

Mantieni distinti autenticazione e autorizzazione del filesystem. Un accesso SMB può riuscire mentre l'identità Unix mappata non dispone dell'autorizzazione di scrittura; un client NFS può presentare un ID numerico accettato dal server, ma che viene associato al proprietario locale sbagliato. Tra un test e l'altro modifica una sola variabile relativa all'identità o all'ACL.

Un percorso supera il test solo quando i diritti osservati corrispondono alla matrice di accesso prevista e i file appena creati ricevono il proprietario, il gruppo e l'ACL predefinita attesi. Se un protocollo si comporta diversamente, interrompi le modifiche generalizzate e traccia il livello di mappatura di quel protocollo prima di intervenire sul filesystem condiviso.

Esamina ereditarietà, maschere e mappature dei container

Confronta l'ACL predefinita del parent con l'ACL di accesso dei file e delle directory appena creati. Controlla la maschera ACL dopo le modifiche ai gruppi, verifica se il servizio SMB applica maschere di creazione o di directory e individua le applicazioni che sostituiscono i file atomicamente, poiché la sostituzione può produrre un'ereditarietà diversa rispetto alle modifiche sul posto.

Per i container, esamina l'utente del runtime, i gruppi supplementari, la rimappatura dello user namespace e il percorso dell'host montato tramite bind. La guida correlata di ZimaSpace sull'accesso ai database su un volume Docker montato via rete è utile quando il livello che non funziona è la mappatura dei nomi NFSv4; questo audit rimane focalizzato sulla dimostrazione dei diritti end-to-end lungo tutti e tre i percorsi.

Non risolvere un problema di mappatura eseguendo l'applicazione come root. Se il container non riesce a creare il file temporaneo, allinea il suo UID, GID o gruppo supplementare supportato con la policy del NAS e ripeti lo stesso test prima di modificare qualsiasi albero di produzione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Applica la correzione più circoscritta e conserva le evidenze

Correggi un livello alla volta: prima la mappatura delle identità, poi l'appartenenza ai gruppi, quindi le impostazioni predefinite ereditate e infine le ACL eccezionali dei file. Applica le modifiche alla directory temporanea, verifica nuovamente tutte le operazioni e solo dopo prepara una modifica circoscritta per il sottoalbero di produzione, con un'ACL di rollback salvata.

Dopo il rilascio, riavvia o riconnetti i client che memorizzano nella cache le credenziali, rimonta NFS dove necessario e riavvia solo i container il cui elenco dei gruppi viene fissato all'avvio del processo. Ripeti la stessa matrice di test e verifica che sia i file esistenti sia quelli nuovi si comportino come previsto.

L'audit si conclude quando ogni azione consentita e negata corrisponde alla matrice documentata, i nuovi oggetti ereditano correttamente le impostazioni e l'ACL salvata può ripristinare lo stato precedente. Escala invece di procedere ciecamente in modo ricorsivo quando la proprietà è volutamente mista, snapshot o hard link complicano il rollback oppure lo storage del NAS segnala errori.