È un approccio raccomandato / valido per le autorizzazioni del file server?

I file server sono un dato di fatto nell'IT e sono curioso di sapere se esistono pratiche generalmente accettate (esito a utilizzare qui la parola "migliore") per come creare gruppi e applicare le autorizzazioni per la gestione dell'accesso client a una cartella condivisa su un file server.

Nel mio attuale lavoro, ho finito per ereditare un bel po 'di modi diversi di farlo, che vanno da dozzine di gruppi sugli ACL a mettere i singoli utenti direttamente sul filesystem. Il mio compito era quello di ripulire il caos e trovare un modo standardizzato di affrontarlo in tutta l'azienda (ambiente di grandi dimensioni, 150k di personale, 90k di computer client, 100 di file server).

Dalla mia comprensione del problema, sembra che tu abbia almeno bisogno di un gruppo per livello di accesso richiesto per risorsa protetta. Questo modello sembra offrire la massima flessibilità in quanto non è necessario toccare nuovamente le autorizzazioni del filesystem a meno che non sia necessario supportare un livello di accesso diverso. L'aspetto negativo è che creerai più gruppi rispetto al riutilizzo dello stesso gruppo su più risorse condivise.

Ecco un esempio che mostra cosa intendo:

Esiste una condivisione chiamata "Risultati del test" su un file server chiamato FILE01 e ci sono persone che hanno bisogno di accesso in sola lettura, accesso in lettura e scrittura e controllo completo. 1 risorsa protetta * 3 livelli di accesso = 3 gruppi di sicurezza. Nel nostro ambiente AD, li creiamo come gruppi universali in modo da poter aggiungere facilmente utenti / gruppi da qualsiasi dominio della foresta. Poiché ogni gruppo fa riferimento in modo univoco a una cartella condivisa e al livello di accesso, i nomi dei gruppi incorporano quei dati "chiave" e le autorizzazioni sono quindi:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

In genere, includiamo anche l'account SYSTEM integrato e anche gli amministratori integrati con accesso Controllo completo. Qualsiasi modifica a chi ottiene effettivamente l'accesso a questa condivisione può ora essere gestita utilizzando le appartenenze ai gruppi anziché dover toccare l'ACL (aggiungendo gruppi "Ruolo" che rappresentano ruoli aziendali specifici come Manager, Tecnici, Analisti QA, ecc. O singoli individui utenti per l'accesso unico).

Due domande:

1) Questo è in realtà un approccio consigliato o valido per la gestione delle autorizzazioni o mi manca una soluzione più semplice ed elegante? Sarei particolarmente interessato a tutte le soluzioni che usano l'ereditarietà ma mantengono comunque la flessibilità nel non dover ri-ACL gran parte dei filesystem quando le cose cambiano.

2) Come gestite le autorizzazioni del file server e la struttura dei gruppi nel vostro ambiente? Punti bonus per coloro che lavorano anche in ambienti di grandi dimensioni.

Il mio approccio è di non utilizzare le autorizzazioni per i file a livello di file / directory; utilizzare le autorizzazioni a livello di condivisione file e impostare l'intera unità dati del file system del server su Controllo completo di tutti (che diventa discutibile).

Nel corso degli anni (10+), ho scoperto che le autorizzazioni NTFS sono più complesse e portano a più errori. Se le autorizzazioni sono impostate in modo errato o l'eredità viene interrotta, si espongono i dati ed è difficile trovarli e vederli. Inoltre, sei esposto al problema di spostamento / copia ... gli utenti che spostano i file spostano anche l'ACL del file, mentre la copia eredita l'ACL di destinazione.

Usa i tuoi gruppi di lettura / scrittura allo stesso modo, ma sull'intera condivisione di file usando Comp Mgmt MMC. Non fare il pieno ... gli utenti si spareranno con conoscenza parziale / migliori intenzioni.

Questo approccio non è male. Di norma, non utilizzare mai singoli utenti per aggiungere autorizzazioni: utilizzare un gruppo. I gruppi possono tuttavia essere utilizzati su più risorse. Ad esempio, HR potrebbe avere accesso RW ai file mentre MANAGERS potrebbe avere R. È inoltre possibile impostare l'Enumerazione basata sull'accesso. Dai un'occhiata al seguente webcast:

Techcast Webcast: serie di amministrazione di Windows Server 2003 (parte 4 di 12): gestione dei gruppi (livello 200)

L'enumerazione basata sull'accesso può semplificare anche la vita:

Enumerazione basata sull'accesso

ABE può aiutare a ridurre il numero di diverse condivisioni che devi amministrare.

Il tuo approccio è sostanzialmente il modo in cui lo approccerei.
Le uniche cose che aggiungerei sono queste:

1) Aggiungerei al tuo schema di "ruoli" valutando ciò di cui hanno bisogno attraverso i server, non su un solo server che probabilmente ti imbatterai in valori anomali, ma la mia teoria con quelli è quando ti imbatti in loro, creare un altro gruppo. nella mia esperienza in cui esiste un valore anomalo ce ne sono molti.

2) VOGLIAMO VIVAMENTE di rivalutare la necessità di gruppi Universal per tutto mentre si prende un colpo di replica con loro mentre i membri e i gruppi all'interno del gruppo Universal vengono replicati sui server del catalogo globale mentre con Domain Local e Global solo il gruppo è replicato nei server di catalogo globale. Quindi, se si effettua una modifica in un gruppo universale, si avvia una replica, mentre con il globale e il dominio locale non lo fa.

Il metodo di utilizzo del gruppo di risorse per ciascun livello di accesso è corretto. L'unica cosa che prenderei in considerazione è l'utilizzo di gruppi locali di dominio per le risorse. Non è necessario utilizzare Universal Group se si stanno creando gruppi di risorse specifici del server.

L'aspetto negativo dell'utilizzo di gruppi locali di dominio per le risorse è che si finisce con più gruppi totali. Il lato positivo è che hai meno problemi con la replica, come notato da Zypher.

L'approccio proposto sembra abbastanza solido. Una cosa da tenere d'occhio è il modo in cui inizialmente hai impostato le condivisioni di file. È consigliabile disporre di un'unica condivisione di livello superiore, contenente sottocartelle a cui assegnare le autorizzazioni di gruppo. NTFS può quindi ignorare la "Traverse Folder / Execute File" nella cartella di livello superiore e consentire l'accesso alla sottocartella.

La struttura apparirà quindi come \ nomeserver \ nomecondivisione \ cartella-gruppo, con le autorizzazioni di condivisione che devono solo essere impostate sulla cartella "nomecondivisione" e le autorizzazioni NTFS effettive impostate sulla cartella "cartella-gruppo".

Il tuo file server sarà in grado di funzionare meglio anche con questo tipo di installazione.

Altre cose generali che farei è avere una convenzione di denominazione per i gruppi in modo tale che il nome del gruppo corrisponda al nome della cartella del gruppo (con FC / RW / RO aggiunto se desiderato) e inserire l'UNC nella cartella nella descrizione del gruppo (in modo che lo script di accesso sia in grado di rileggerlo e impostare un mapping di unità in quel modo, nonché in modo da poter vedere più facilmente quali cartelle condivise si applicano a quali gruppi).

La pratica standard che uso per il file server Windows da Windows 2000 (descritta nella serie Mastering Windows Server di Mark Minasi, quindi cerca lì ulteriori informazioni) è quella di utilizzare gruppi che sono locali al file server stesso per l'annidamento.

Ad esempio, considera un file server chiamato KERMIT in un dominio chiamato MUPPETS.

Supponiamo che KERMIT abbia alcune condivisioni di file:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Crea gruppi locali su KERMIT per l'accesso e concedi loro le autorizzazioni sul file system esattamente come hai specificato (ovvero un gruppo per livello di accesso per condivisione)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Poiché si tratta di gruppi locali, è possibile inserire in essi qualsiasi altro gruppo o utente desiderato: gruppi locali di dominio, gruppi globali, gruppi universali, account utente da qualsiasi dominio della foresta. La gestione dei diritti è ora locale ai gruppi del file server anziché al file system o all'AD.

Ciò aggiunge un ulteriore livello alla gestione dei gruppi, ma ha il vantaggio di consentire agli amministratori (diciamo) locali del sito di gestire i propri file server senza richiedere altro che i diritti di amministratore per quel file server. Se si dispone di una sorta di struttura di filiali federata, in cui ogni tipo di ufficio fa la propria cosa con i propri server, questo può essere un vero vantaggio. Potrebbe non essere necessario concedere i diritti di amministratore di dominio AD a poche decine di amministratori di siti locali.

Inoltre, evita che l'AD sia ingombro di molti gruppi (un gruppo per livello di accesso per condivisione per server può sommarsi molto rapidamente) e riduce al minimo la replica dei gruppi tra GC. Ti consente di riservare i tuoi gruppi AD per ruoli anziché autorizzazioni.

Se il tuo ambiente è rigorosamente standardizzato e tutti i file server sono identici e replicati, ovviamente questo è un ulteriore livello di gruppi che non ti serve. Inoltre, se sai che hai bisogno di un particolare gruppo AD per avere gli stessi diritti su una condivisione esistente su ogni singolo file server, avrai bisogno di un po 'di automazione per mantenerlo.

In breve, più i tuoi file server sono diversi l'uno dall'altro, più ha senso usare gruppi locali di macchine. Più sono simili, più si desidera utilizzare il sistema che si sta attualmente utilizzando.

Sto osservando una migrazione da NetWare a Windows Server 2008, quindi ultimamente mi è venuto in mente molto. Server 2008 (e in una certa misura Server 2003R2) ha alcune funzioni molto carine che facilitano davvero questa transizione. Server 2008 viene fornito con enumerazione basata sull'accesso pronta per l'uso. Questa è una funzione molto bella che consente agli utenti di vedere solo le directory in cui hanno diritti. Se hai una condivisione come ...

\\ user-casa-SRV \ case \

Senza ABE l'utente finale vedrebbe decine / centinaia / migliaia di directory. Con ABE l'utente finale ne vedrebbe solo uno. Lo stesso vale per le condivisioni condivise. Con ABE puoi avere un unico enorme volume per tutte le tue directory dipartimentali, se lo desideri, e non spammare il diavolo dei tuoi utenti con le directory in cui non riescono a entrare. Pur non essendo un problema ACL, è in qualche modo correlato, quindi lo sollevo.

Un'altra cosa che Server 2008 sembra fare meglio delle sue versioni precedenti è l'ereditarietà ACL. Sembra solo più veloce nel propagare fino alla foglia un cambiamento di ACL nella parte superiore di un grande albero.

Grazie alla nostra eredità di Netware, abbiamo un gran numero di gruppi che sono nominati in base a chi è in essi, con alcuni là fuori nominati per ciò a cui danno accesso. Per le directory che hanno regolato l'accesso, utilizziamo anche la nomenclatura "RO" "Full".

Abbiamo un volume "condiviso" monolitico (ancora su NetWare, ma prevediamo di averlo monolitico quando ci spostiamo su Windows) che è il singolo volume condiviso per tutti i 4.400 lavoratori e contiene oltre 3,5 milioni di file. Le directory di livello superiore sono tutti i nomi dei dipartimenti e ogni dipartimento regola ciò che accade al loro interno. Ci sono alcune eccezioni per i dipartimenti molto grandi, quelli hanno un 2 ° livello di directory con ACL.

Nel mio ultimo lavoro siamo stati anche in grado di impostare le autorizzazioni in modo che i dipendenti delle risorse umane che si candidano per i lavori non siano in grado di vedere i dati delle loro applicazioni sul loro server. Ci sono voluti alcuni filtri per i diritti ereditari per farlo, che è simile al tag "blocco ereditarietà" su Windows. La parte difficile lì stava documentando tutto, ma ha funzionato .

Uno scenario ottimale è quello di aggiungere ogni utente a un solo gruppo di sicurezza per il ruolo lavorativo dell'utente. Il ruolo quindi è l'accesso delegato dove necessario.

Allo stesso modo, a una cartella condivisa dovrebbe essere concesso l'accesso usando gruppi di sicurezza "risorsa", come nell'esempio "FILE01-Test Results-RW". Ciò conterrà i ruoli di lavoro, i ruoli di reparto o altri gruppi applicabili.

Il vantaggio di questo design è che deleghi l'accesso su base per gruppo (team, dipartimento, ecc.) E non un accesso unico che può essere difficile da tracciare. Quando un utente si trasferisce in un altro reparto, è necessario ripulire tutto il vecchio accesso.

L'aspetto negativo è che i gruppi possono essere utilizzati in modo improprio. Fare chiare distinzioni su ciò a cui vengono utilizzati i gruppi, in modo che i gruppi di risorse assegnati a una condivisione non vengano riutilizzati come se fossero gruppi dipartimentali, creando un disordinato disordine di accesso.