Implicazioni sulla sicurezza e sulle prestazioni di "Visualizza stato server"

Questa domanda sottolinea che l'autorizzazione "Visualizza stato server" è necessaria per vari DMV (viste di gestione dinamica), ma non riesco a trovare nulla su chi fai e non vuoi concedere l'autorizzazione.

Ora ovviamente capisco i "minimi permessi" e perché non vorresti concederlo a nessuno, ma non trovo alcuna guida su come valutare se DOVREBBE essere concesso o meno.

Quindi, la mia domanda: quali sono le implicazioni in termini di sicurezza e prestazioni della concessione dell'autorizzazione "Visualizza stato server" dell'utente. Cosa possono fare che forse non dovrebbero essere autorizzati a fare ...

Aggiornamento : un'implicazione è che l'utente sarà in grado di utilizzare i DMV per esaminare le query. Se le query o i parametri della query possono contenere informazioni riservate che l'utente non sarebbe altrimenti in grado di vedere, consentendo VIEW SERVER STATE consentirebbe loro di farlo (ovvero dob = o ssn =).

Non ci sono problemi di prestazioni significative che posso pensare di concedere questa autorizzazione. Dal punto di vista della sicurezza, corri il rischio di consentire a un utente di vedere quali sono i tuoi dettagli sui punti deboli, quindi, ad esempio, un utente malintenzionato potrebbe visualizzare le tue statistiche di attesa più comuni, che potrebbero aiutarli a colpire un attacco DoS contro il tuo server .

È possibile? Decisamente. È probabile? Sono costretto a dire di no, ma ricorda che si stima che il 90 percento degli attacchi contro le aziende provenga da aggressori interni.

Come amministratore visualizzerai queste informazioni come nel tuo dominio (prestazioni / utilizzo dell'indice / ecc.) Ma ci sono ragioni potenzialmente convincenti che un'organizzazione di sviluppo vorrebbe queste informazioni per un grande sistema legacy che supportano, identificando le tabelle zombi che vengono toccate solo mediante processi di manutenzione, ad esempio.

Alla fine finisce sempre per essere un problema di "fortuna e generosità" poiché la richiesta di giustificare una particolare richiesta finisce per essere una scelta morbida e non una formula croccante. L'uso di schemi di buone pratiche senza guardare al contesto è di per sé un anti-schema piuttosto brutto e la realtà è che molti si avvicinano alle loro posizioni con il "parlare alla mano" come punto di partenza.

Per quanto riguarda le implicazioni sulle prestazioni, non ne sono a conoscenza per questo o altri permessi.

Per quanto riguarda:

Cosa possono fare che forse non dovrebbero essere autorizzati a fare

In poche parole, possono vedere cose che forse non dovrebbero vedere. E non pensarci in termini di solo SQL Server. Questa particolare autorizzazione regola anche i DMV come sys.dm_os_sys_info e molti altri che forniscono informazioni dettagliate sulla macchina host (hardware, servizi, ecc.). Non sempre sai quali informazioni possono essere utilizzate contro di te. E, anche se sei d'accordo con qualcuno che vede tutto ciò che è consentito da questa autorizzazione ora, a volte i DMV vengono aggiunti in Service Pack / Aggiornamenti cumulativi, e quindi forse viene scoperta una nuova informazione di cui non sei a conoscenza.

Non riesco a trovare alcuna guida su come valutare se DOVREBBE essere concesso o meno.

Dato che hai già menzionato il fatto di concedere alle persone le autorizzazioni minime necessarie, ciò a cui si riduce davvero è: qualcuno ha bisogno di questa autorizzazione per un utilizzo ad hoc ? Significato, qualcuno ha bisogno della flessibilità di venire con le proprie domande? La creazione di una o più procedure memorizzate e / o TVF a più istruzioni funzionerebbe? In tal caso, non è necessario concedere le autorizzazioni a nessun utente (che è quindi libero da qualsiasi cosa consentita da tale autorizzazione) e invece concedere le autorizzazioni al codice (che fa solo ciò che è codificato per fare). La firma del modulo è il modo in cui lo realizzi. Il concetto generale è:

1. Creare le procedure memorizzate e / o le TVF a più istruzioni per eseguire le azioni desiderate.
2. Concedere EXECUTEsu questi moduli a qualsiasi utente e / o ruolo siano necessari per eseguire queste azioni
3. Crea un certificato
4. Firma il / i modulo / i usando quel certificato (usando ADD SIGNATURE)
5. Copia il certificato nel [master]database (es. Crea un certificato [master]usando la chiave pubblica del certificato usato per firmare i moduli.
6. Creare un accesso dal certificato copiato [master]
7. Concedere le autorizzazioni a livello di istanza necessarie per tale accesso basato su certificato (che può includere l'aggiunta di ruoli a livello di istanza).

Per alcuni esempi, vedere:

• Come mantenere il ripristino della proprietà del database tra domini?

• Utilizza in modo facile e sicuro autorizzazioni di alto livello senza concederle a nessuno: a livello di server

È un problema di sicurezza. Non puoi mai sbagliare se segui il principio del privilegio minimo . In altre parole, se un principal di autenticazione non ha bisogno di un permesso particolare, allora non darglielo. Fornisci informazioni relative al tipo di serrature sulla tua porta ad altre persone che non hanno bisogno di sapere quello sulla tua casa? Spero di no. Probabilmente non farebbero nulla, ma non è ancora prudente.

Se basassimo i principi dei dati su fortuna e generosità, saremmo nei guai più grandi un po 'più spesso. La sicurezza è un aspetto che dovresti concedere solo quando puoi difendere il motivo per cui hai concesso. Stai semplicemente dando a qualcuno più informazioni di quelle che devono sapere . Non farlo Lo stato del server è ancora sensibile.