Deze vraag wijst erop dat “View Server State” toestemming vereist is voor verschillende DMV “s (dynamische beheerweergaven), maar ik kan niets vinden over wie je wel en niet de toestemming willen geven aan.
Nu begrijp ik natuurlijk “de minste toestemmingen”, en waarom je het niet zomaar aan iemand zou willen verlenen, maar ik kan geen richtlijnen vinden om te beoordelen of het MOET worden verleend of niet .
Dus mijn vraag: wat zijn de veiligheids- en prestatie-implicaties van het verlenen van een gebruiker “View Server State” -machtiging. Wat kunnen ze doen dat ze misschien “niet mogen doen …
Update : een implicatie is dat de gebruiker in staat zal zijn om DMVs te gebruiken om naar vragen te kijken. Als de queries of queryparameters vertrouwelijke informatie kunnen bevatten die de gebruiker anders niet zou kunnen zien, zou het toestaan van VIEW SERVER STATE hen dat toestaan (dwz dob = of ssn =).
Answer
Er zijn geen significante prestatieproblemen die ik kan bedenken bij het verlenen van deze toestemming. Vanuit een beveiligingsperspectief loopt u het risico een gebruiker te laten zien wat u de meeste details over uw zwakke plekken, dus een kwaadwillende gebruiker kan bijvoorbeeld uw meest voorkomende wachtstatistieken bekijken, wat hen zou kunnen helpen een DoS-aanval op uw server te richten.
Is dit mogelijk? Absoluut. Is dit waarschijnlijk? Ik ben gedwongen nee te zeggen, maar onthoud dat naar schatting 90 procent van de aanvallen op bedrijven afkomstig is van interne aanvallers.
Antwoord
Als beheerder zou u zien dat deze informatie zich in uw domein bevindt (prestatie / indexgebruik / enz.), maar er zijn potentieel dwingende redenen waarom een ontwikkeling een organisatie zou deze informatie willen voor een groot legacysysteem dat ze ondersteunen – bijvoorbeeld het identificeren van zombietabellen die alleen worden aangeraakt door onderhoudsprocessen.
Uiteindelijk wordt het altijd een kwestie van “geluk en vrijgevigheid” omdat de vraag of een bepaald verzoek gerechtvaardigd is, uiteindelijk een zachte keuze is en geen scherpe formule. Het gebruik van best practice-patronen zonder naar de context te kijken, is op zichzelf een behoorlijk akelig antipatroon en de realiteit is dat velen hun standpunt benaderen met “praat met de hand” als uitgangspunt.
Antwoord
Wat betreft de gevolgen voor de prestaties, ik ben mij niet bewust van enige toestemming voor deze of enige andere toestemming.
Met betrekking tot:
Wat kunnen ze doen dat ze misschien” niet mogen doen
Simpel gezegd, ze kunnen dingen zien dat ze misschien niet zouden moeten zien. En denk hier niet aan alleen in termen van SQL Server. Deze specifieke toestemming is ook van toepassing op DMVs zoals sys.dm_os_sys_info en een flink aantal andere die inzicht geven in de gastmachine (hardware, services, enz.). Je weet niet altijd welke informatie tegen je kan worden gebruikt. En zelfs als je het goed vindt dat iemand nu alles ziet wat door deze toestemming is toegestaan, worden soms DMVs toegevoegd in Service Packs / Cumulatieve Updates, en dus wordt er misschien een nieuw stukje informatie onthuld waarvan je niet op de hoogte bent.
Ik kan “geen advies vinden om te beoordelen of het MOET worden toegekend of niet.
Aangezien u al zei dat u mensen de minimaal benodigde machtigingen moet geven, komt dit in feite neer op: heeft iemand deze toestemming nodig voor ad hoc gebruik? Dit betekent dat iemand de flexibiliteit nodig heeft om met zijn eigen vragen te komen? Zou het creëren van een of meer opgeslagen procedures en / of multi-statement TVFs werken? Als dit het geval is, hoeft u geen gebruiker toestemming te verlenen (die dan vrij is voor alles wat door die toestemming wordt toegestaan), en in plaats daarvan verleent u de rechten aan de code (wat alleen doet waarvoor het is gecodeerd). Moduleondertekening is hoe u dit bereikt. Het algemene concept is:
- Maak de opgeslagen procedure (s) en / of multi-statement TVF (s) om de gewenste actie (s) uit te voeren.
- Verleen
EXECUTEaan deze modules aan welke gebruiker en / of rollen dan ook nodig hebben om deze acties uit te voeren - Maak een certificaat
- Onderteken de module (s) met dat certificaat (gebruik
ADD SIGNATURE) - Kopieer het certificaat naar de
[master]-database (dwz maak een certificaat in[master]met behulp van de openbare sleutel van het certificaat dat is gebruikt om de module (s) te ondertekenen. - Maak een login van het certificaat gekopieerd naar
[master] - Verleen welke instantie dan ook- niveau permissio ns zijn nodig voor die op certificaten gebaseerde aanmelding (wat kan betekenen dat deze aan rollen op instantieniveau moet worden toegevoegd).
Voor enkele voorbeelden, zie:
Antwoord
Het is een beveiligingsprobleem. Je kunt nooit fout gaan als u volgt het Principe van de minst geprivilegieerde . Met andere woorden, als een authenticerende principal “geen nodig een bepaalde toestemming heeft, doe dat dan niet” Geef het aan hen Geeft u informatie over het soort sloten op uw deur aan andere mensen die dat niet hoeven te weten over uw huis? Ik hoop van niet. Ze zouden waarschijnlijk “niets doen, maar het is nog steeds niet verstandig.
Als we gegevensprincipes zouden baseren op geluk en vrijgevigheid, zouden we vaker in grotere problemen komen. Beveiliging is een aspect waar je alleen moet toekennen als je kunt verdedigen waarom je hebt verleend. Je geeft iemand gewoon meer informatie dan nodig is . Doe het niet. De serverstatus is nog steeds gevoelig.
sys.dm_db_missing_index_detailste kijken) en ze willen weten wat de risicos hiervan precies zijn.