Come documentare / tenere traccia delle autorizzazioni

Sono un amministratore di Windows, quindi quelli che si integrano con Windows saranno probabilmente di grande aiuto. La mia sfida principale a questo punto è solo con le condivisioni di file, ma con l'aumentare dell'utilizzo di SharePoint renderà solo più difficile.

Ho installato tutte le mie directory e sono consentiti molti gruppi di sicurezza che sono impostati con la politica di minor accesso necessario. Il mio problema è rintracciare tutto per motivi di risorse umane e conformità.

L'utente A necessita dell'autorizzazione per la risorsa 1. Deve ottenere l'approvazione dal gestore della risorsa 1 e quindi anche il gestore dei gestori deve approvare questo accesso. Una volta fatto tutto ciò, posso apportare la modifica. A questo punto lo stiamo semplicemente monitorando su carta ma è un tale onere e rischia di non essere conforme quando l'utente A viene riassegnato e non dovrebbe più avere accesso alla risorsa 1 tra gli altri scenari.

So che quello che sto cercando dovrebbe già esistere, ma non sapevo dove cercare e sto raggiungendo la comunità.

MODIFICARE:

Grazie per le risposte Penso che tocchino il lato tecnico e speriamo che la mia domanda non sia fuori tema. Avrei dovuto rendermi più chiaro sul mio obiettivo. Quali sistemi usi per mostrare a un revisore che su X data l'utente A ha avuto l'autorizzazione aggiunta / rimossa ed è stata approvata dal manager Y? Al momento ho un sistema di ticketing di base, ma non lo vedo in grado di fornire ciò di cui ho bisogno in un formato di facile comprensione.
Nella mia mente sto immaginando qualcosa che avrebbe un rapporto sull'utente A che mostrerebbe tutte le modifiche che erano state apportate alle loro autorizzazioni. Idealmente qualcosa che collega ad Active Directory sarebbe l'ideale, ma a questo punto spero di trovare qualcosa di più semplice. Spero che ci sia un'applicazione appositamente per questo.

Grazie!

È necessario un sistema di ticketing che fornisca 3 elementi:

1. Data / ora in cui le autorizzazioni sono state modificate (aggiunte o rimosse) per un determinato utente
2. Perché sono stati cambiati
3. Capacità di cercare questi cambiamenti

Praticamente tutti i sistemi di biglietteria forniscono già il numero 1 sotto forma di data di creazione del biglietto, data di modifica, ecc. Il numero 2 dipende da te per documentare il biglietto. Di solito si tratta di un'e-mail di approvazione del gestore risorse incollata nel ticket in cui si dice che possono avere accesso (o che l'accesso deve essere rimosso) e che tipo. Il numero 3 è il più importante e dipende dal sistema di ticketing, ma se si dispone di un sistema che non è facile da cercare, il lavoro viene tagliato per te. Se puoi semplicemente cercare l'utente in modo che tutti i ticket di autorizzazione siano collegati alle loro informazioni di contatto nel sistema di biglietteria, allora sei bravo, altrimenti stai essenzialmente documentando le tue modifiche in un buco nero.

Al di fuori di un sistema di ticketing che può eseguire questa operazione per tenere traccia delle modifiche (menzioni di avere un sistema di ticketing di base, quindi forse è necessario crearne uno migliore che consenta una migliore capacità di ricerca / reportistica), qualsiasi applicazione, utilità o script utilizzato fornirà solo un'istantanea delle autorizzazioni. Sei ancora bloccato con il "perché?" di chi ha accesso a cosa, che può essere adeguatamente documentato separatamente dall'applicazione poiché sarà probabilmente necessario acquisire l'e-mail originale o altro testo di approvazione dal gestore delle risorse. Una volta che lo hai, dove lo metti per associarlo ai risultati dell'applicazione?

L'esecuzione di un'app o di uno script per determinare le autorizzazioni correnti in una struttura di file non fornisce neanche una buona traccia di controllo delle modifiche alle autorizzazioni per un utente. In sostanza sei bloccato con una grande istantanea delle autorizzazioni correnti in un singolo punto nel tempo. Quando lo esegui di nuovo, avrai un'altra grande istantanea delle autorizzazioni per i file. Anche se hai conservato la prima acquisizione delle autorizzazioni e l'hai confrontata con la recente acquisizione e le autorizzazioni sono cambiate, come lo leghi al motivo della modifica? Ancora una volta, questo ci riporta al sistema di ticketing poiché #s 1,2 e 3 sopra saranno tutti documentati in un unico posto.

Un altro problema che hai sollevato è il creep delle autorizzazioni (quando un utente viene riassegnato a un'altra autorizzazione e non ha più bisogno dell'accesso alla risorsa X, ma lo mantiene comunque, perché il fatto che non abbia più bisogno dell'accesso alla risorsa X non è stato gestito dall'IT Dept durante la transizione). L'UNICO modo per controllare ciò è comunicare alle risorse umane o a chiunque gestisca le riassegnazioni dei dipendenti che l'IT deve essere informato quando un dipendente viene riassegnato in modo che possano assegnare e revocare le autorizzazioni in modo appropriato. Questo è tutto. Non esiste un'applicazione magica che ti dica che un utente ha accesso alla risorsa X ma non dovrebbe più esserlo perché il loro lavoro è ora Y. In questo caso, la notifica umana in qualche forma deve essere data all'IT.

Se disponi già di un sistema di ticketing, ti suggerirei di creare un nuovo gruppo, tag, ecc. Nella tua applicazione per questi tipi di richieste e fare in modo che gli utenti inviino i biglietti per le modifiche alle autorizzazioni. Se il tuo sistema di biglietteria ti consente di inoltrare i biglietti ad altri utenti o di aggiungerli al biglietto, aggiungi i gestori richiesti e richiedi la verifica. Ciò ti consentirebbe di tenere un registro per coprire il tuo lavoro.

Come accennato in precedenza, creare un gruppo di sicurezza per ogni condivisione. Nel mio ambiente, avremmo condivisioni denominate FIN_Yearly, GEN_Public, MGM_Reports (ogni reparto ha il suo acronimo). I gruppi di sicurezza verranno quindi denominati SG_FIN_YearlyAdmin, SG_FIN_YearlyUser, SG_GEN_PublicAdmin ecc. L'utente è di sola lettura, l'amministratore è di lettura / scrittura.

Da qui è possibile creare, ad esempio SG_FinancialsManager; gruppi di sicurezza che includono altri gruppi di sicurezza al fine di semplificare l'accesso in base ai lavori che svolgono. Personalmente non lo facciamo perché confonde un po 'il tracciamento. Invece di controllare SG di una condivisione e vedere un sacco di SG con autorizzazioni, abbiamo invece un elenco di utenti. La preferenza personale, davvero, e dipenderà dalle dimensioni del tuo sito. Solitamente utilizziamo modelli utente per la gestione di nuovi utenti in posizioni specifiche.

Se il tuo sistema di biglietteria ti consente di cercare tra i biglietti precedenti, hai quasi finito. Se qualcuno ti richiede di rimuovere le autorizzazioni di un utente, puoi rintracciarlo. Se un utente si domanda perché non ha più accesso, puoi fornire loro il biglietto. Se un manager ti chiede chi ha accesso a cosa, stampa il gruppo di sicurezza richiesto.

In realtà ci sono diverse applicazioni commerciali per farlo. L'area viene talvolta definita "governance dei dati".

Un paio di esempi:

Varonis Data Governance Suite
http://www.varonis.com/products/data-governance-suite/index.html

Quest One Identity Manager - Data Governance Edition
http://www.quest.com/identity-manager-data-governance

Non li uso ma dopo aver studiato l'argomento e visto alcune dimostrazioni, l'ambito di ciò che può essere richiesto spiegherebbe il mercato. Queste applicazioni sono molto complesse e non economiche. Alcuni di essi hanno metodi molto sofisticati per agganciarsi alle piattaforme di archiviazione per tenere traccia degli elenchi di controllo degli accessi. Anche se non rientra nel tuo budget, le demo possono essere utili per avere un'idea di cosa fa un'applicazione come questa dal punto di vista funzionale.

Un'osservazione che ho avuto durante la revisione è che in genere non eseguono il controllo a livello di file. Se lo facessero, non ci sarebbe alcun modo in cui scalare fino a centinaia di milioni o miliardi di documenti. Quindi in genere tengono traccia delle autorizzazioni solo a livello di directory.

Non so documentarli / rintracciarli , ma li assegno con i gruppi.

L'utente A deve accedere alla risorsa n. 1. Ricevono il permesso e li aggiungo al gruppo di accesso.
Continuano i loro affari fino a quando un giorno non vengono riassegnati / licenziati / qualunque cosa, a quel punto li rimuovo dal gruppo di accesso.

I registri di controllo delle modifiche del mio account indicano quando hanno ottenuto / perso l'accesso, quindi esiste una registrazione e i gruppi di accesso alle risorse sono in genere gruppi dipartimentali (risorse umane, IT, vendite, finanza, ecc.), Quindi gestire le riassegnazioni in genere significa cambiare il loro gruppo iscrizione comunque.

Questo tende a funzionare al meglio in ambienti più piccoli - per ambienti più grandi o in cui gli ACL diventano davvero complessi Zoredache ha una buona idea sul fatto che il sistema che esegue l'ACL-tweaking esegua anche la documentazione in una certa misura

Per iniziare la richiesta di aggiungere / rimuovere l'accesso, riassegnare gli utenti, ecc. Suggerirei carta elettronica (un sistema di biglietteria) - questo assicura che gli utenti non scivolino attraverso le fessure, ma richiede un buy-in aziendale generale per usare il sistema elettronico religiosamente .
Il vantaggio rispetto alla carta è che puoi ottenere qualcosa che puoi cercare e tutti possono fare la loro parte del processo dalla propria scrivania (i gestori possono approvare più rapidamente poiché non c'è una busta di posta tra gli uffici in movimento, l'IT può concedere / revocare l'accesso non appena come il biglietto appare nel cestino di qualcuno, ecc.)

Il modo migliore per trovare un'impostazione delle autorizzazioni è basato sul ruolo.

GG_HR GG_Finance ecc., Generalmente mappato sulla posizione o sulla business unit.

Da lì si creano gruppi locali che dispongono dell'autorizzazione per la risorsa, ad esempio la stampante o la directory Finance. LG_RoomXPrinter LG_Finance_Read LG_Finance_FullControl

Si creano gruppi globali per questi gruppi locali LG-> GG, quindi nei gruppi globali basati sul ruolo si aggiungono i gruppi globali basati sulle autorizzazioni.

GG_Finance <- LG_Finance_FullControl, LG_RoomXPrinter

Semplifica quando le persone entrano in un ruolo basta aggiungere il proprio account a un gruppo e le loro autorizzazioni fluiscono da quel ruolo e molto più facile da tracciare. (Ottimo anche se usi qualche tipo di sistema di gestione delle identità). Molto più facile quindi tenere traccia di chi ha quali autorizzazioni individuali, sai che se fanno parte del gruppo Risorse umane hanno autorizzazioni X.

Puoi semplicemente tenere traccia dei loro movimenti di gruppo quando sono richiesti tramite il tuo sistema di gestione dei lavori o eseguire script per individuare chi è in quale gruppo basato sui ruoli.

Due grandi utilità:

1. AccessEnum: http://technet.microsoft.com/en-us/sysinternals/bb897332
2. AccessChk: http://technet.microsoft.com/en-us/sysinternals/bb664922

AccessEnum ti consente anche di salvare i suoi risultati e poi confrontarli in futuro, il che sarà utile per cercare le modifiche.

Dovresti davvero prendere in considerazione la possibilità di abilitare il controllo delle modifiche alle autorizzazioni di file / cartelle e quindi raccogliere i registri di sicurezza del file server (manualmente o utilizzando qualsiasi strumento di gestione dei registri di eventi o SIEM, come Splunk) e utilizzarli per la tua documentazione. Analizza tutte le modifiche ai file DACL. Inoltre lo integri con AccessEnum e AccessChk come suggerito sopra.

E questo non ti libera dall'impostare le autorizzazioni di sicurezza appropriate e assegnarle solo tramite gruppi.