Această întrebare subliniază că este necesară permisiunea „Vizualizare stare server” pentru diverse DMV (vizualizări de gestionare dinamică), dar nu pot găsi nimic despre cine sunteți faceți și nu doriți să acordați permisiunea pentru.
Acum bineînțeles că înțeleg „cele mai puține permisiuni” și de ce nu ați vrea să le acordați nimănui, dar nu pot găsi niciun fel de orientare cu privire la modul de evaluare dacă TREBUIE să fie acordat sau nu .
Deci, întrebarea mea: Care sunt implicațiile de securitate și performanță ale acordării unui utilizator permisiunea „Vizualizare stare server”. Ce pot face pentru că nu ar trebui să li se permită să facă …
Actualizați : o implicație este că utilizatorul va putea folosi DMV pentru a examina întrebările. Dacă interogările sau parametrii de interogare pot conține informații confidențiale pe care utilizatorul nu le-ar putea vedea, permițând VIEW SERVER STATE le-ar permite să facă acest lucru (de exemplu, dob = sau ssn =).
Răspuns
Nu există probleme semnificative de performanță la care să mă gândesc din acordarea acestei permisiuni. Din perspectiva securității, riscați să lăsați un utilizator să vadă ce cele mai multe detalii despre punctele dvs. slabe, așa că, de exemplu, un utilizator rău intenționat ar putea vedea cele mai frecvente statistici de așteptare, ceea ce i-ar putea ajuta să direcționeze un atac DoS împotriva serverului dvs.
Este posibil? Cu siguranță. probabil? Sunt obligat să spun Nu, dar amintiți-vă că se estimează că 90% din atacurile împotriva companiilor provin de la atacatori interni.
Răspuns
În calitate de administrator, ați vedea aceste informații ca fiind în domeniul dvs. (performanță / utilizarea indexului / etc), dar există motive potențial convingătoare pentru care o dezvoltare organizația de echipamente ar dori aceste informații pentru un sistem vechi pe care îl susțin – identificarea tabelelor de zombi care sunt atinse doar de procesele de întreținere, de exemplu.
În cele din urmă, întotdeauna ajunge să fie o problemă de „noroc și generozitate”. întrucât apelul cu privire la justificarea oricărei cereri particulare ajunge să fie o alegere simplă și nu o formulă clară. Utilizarea modelelor de bune practici fără a privi contextul este în sine un anti-model destul de urât, iar realitatea este că mulți își abordează pozițiile cu „vorbește la mână” ca punct de plecare.
Răspuns
În ceea ce privește implicațiile privind performanța, nu știu niciunul pentru această sau orice altă permisiune.
În ceea ce privește:
Ce pot face pentru că nu ar trebui să li se permită să facă
Pur și simplu, pot vedea lucruri că poate nu ar trebui să vadă. Și nu vă gândiți la acest lucru în termeni de doar SQL Server. Această permisiune specială guvernează, de asemenea, DMV-uri, cum ar fi sys.dm_os_sys_info și multe altele care oferă informații mașina gazdă (hardware, servicii etc.). Nu știi întotdeauna ce informații pot fi folosite împotriva ta. Și, chiar dacă sunteți în regulă ca cineva să vadă tot ce este permis de această permisiune acum, uneori DMV-urile sunt adăugate în Service Packs / Cumulative Updates și, deci, poate că este expusă o nouă informație de care nu știți.
Nu pot găsi nicio orientare cu privire la modul de evaluare dacă TREBUIE acordat sau nu.
Întrucât ați menționat deja că acordați oamenilor permisiunile minime necesare, la ce se rezumă cu adevărat: are cineva nevoie de această permisiune pentru utilizarea ad hoc ? Adică, cineva are nevoie de flexibilitatea de a veni cu propriile întrebări? Ar funcționa crearea uneia sau mai multor proceduri stocate și / sau TVF cu mai multe declarații? Dacă da, atunci nu trebuie să acordați permisiuni oricărui utilizator (care este apoi liber de orice este permis de permisiunea respectivă) și, în schimb, acordați permisiunile codului (care face doar ceea ce este codificat să facă). Semnarea modulului este modul în care realizați acest lucru. Conceptul general este:
- Creați procedurile stocate și / sau TVF-urile cu mai multe instrucțiuni pentru a efectua acțiunile dorite.
- Acordați
EXECUTEpe aceste module pentru orice utilizator și / sau roluri trebuie să efectueze aceste acțiuni - Creați un certificat
- Semnați modulele folosind acel certificat (folosind
ADD SIGNATURE) - Copiați certificatul în baza de date
[master](adică creați un certificat în[master]folosind cheia publică a certificatului utilizat pentru semnarea modulului (modulelor). - Creați o autentificare din certificatul copiat în
[master] - Acordați orice instanță- nivel permis Ns sunt necesare pentru acel login bazat pe certificat (care poate include adăugarea acestuia la roluri la nivel de instanță).
Pentru câteva exemple, consultați:
Răspunde
Este o problemă de securitate. Nu poți greși niciodată dacă urmați Principiul celor mai puțin privilegiați . Cu alte cuvinte, dacă un director de autentificare nu „are nevoie de o anumită permisiune, atunci nu” Nu le oferiți. Dăți informații cu privire la tipul de încuietori de la ușă altor persoane care nu trebuie să știe asta despre casa ta? Sper că nu. Probabil că nu vor face nimic, dar încă nu este prudent.
Dacă ne-am baza principiile de date în afara norocului și a generozității, am avea probleme mai mari destul de des. Securitatea este o aspect în care ar trebui să acordați doar atunci când puteți apăra de ce ați acordat. Pur și simplu oferiți cuiva mai multe informații decât trebuie să știe . Nu o faceți. Starea serverului este încă sensibilă.
sys.dm_db_missing_index_details) și vor să știe care sunt exact riscurile de a face acest lucru.