Den här frågan påpekar att ”View Server State” -behörighet krävs för olika DMV: er (dynamiska hanteringsvyer), men jag kan inte hitta något om vem du gör och vill inte ge tillstånd till.
Nu förstår jag självklart ”minst behörighet”, och varför skulle du inte bara vilja ge det till någon, men jag kan inte hitta någon vägledning om hur man ska utvärdera om det FÅR beviljas eller inte .
Så, min fråga: Vilka är säkerhets- och prestandakonsekvenserna av att bevilja en användare ”View Server State” -behörighet. Vad kan de göra för att de kanske inte skulle få göra …
Uppdatera : en implikation är att användaren kommer att kunna använda DMV för att titta på frågor. Om frågorna eller frågeparametrarna kan innehålla konfidentiell information som användaren annars inte skulle kunna se, skulle VIEW SERVER STATE tillåta dem att göra det (dvs. dob = eller ssn =).
Svar
Det finns inga betydande prestandafrågor som jag kan tänka mig från att bevilja denna behörighet. Ur ett säkerhetsperspektiv riskerar du att låta en användare se vad du de flesta detaljer om dina svaga punkter, så till exempel kan en skadlig användare se din vanligaste väntestatistik, vilket kan hjälpa dem att rikta en DoS-attack mot din server.
Är det möjligt? Definitivt. Är det här troligtvis? Jag är tvungen att säga nej, men kom ihåg att det beräknas att 90 procent av attackerna mot företag kommer från interna angripare.
Svar
Som administratör skulle du se denna information som i din domän (prestanda / indexanvändning / etc) men det finns potentiellt tvingande skäl som en utveckling Opmentorganisation vill ha den här informationen för ett stort äldre system som de stöder – identifiera zombietabeller som bara berörs av exempelvis underhållsprocesser.
I slutändan blir det alltid en fråga om ”tur och generositet” eftersom samtalet om huruvida en viss begäran är motiverad blir ett mjukt val och inte en skarp formel. Användningen av bästa praxismönster utan att titta på sammanhanget är i sig ett ganska otäckt antimönster och verkligheten är att många närmar sig sina positioner med ”prata med handen” som utgångspunkt.
Svar
När det gäller prestandakonsekvenser är jag inte medveten om något för detta eller annat tillstånd.
Angående:
Vad kan de göra för att de kanske inte ska få göra
Enkelt uttryckt, de kan se saker att de kanske inte skulle se. Och tänk inte på detta i termer av bara SQL Server. Denna specifika behörighet reglerar också DMV: er som sys.dm_os_sys_info och en hel del andra som ger inblick i värdmaskinen (hårdvara, tjänster etc.). Du vet inte alltid vilken information som kan användas mot dig. Och även om du är ok med att någon ser allt som är tillåtet enligt denna behörighet nu, ibland läggs DMV till i Service Packs / Kumulativa uppdateringar, och så kanske en ny information blir utsatt som du inte är medveten om.
Jag kan inte hitta någon vägledning om hur jag ska utvärdera om det FÅR beviljas eller inte.
Eftersom du redan nämnde att ge människor de minsta behörigheterna som behövs, vad det egentligen handlar om är: behöver någon detta tillstånd för ad hoc användning? Menande, behöver någon flexibiliteten att komma med sina egna frågor? Skulle en eller flera lagrade procedurer och / eller TVFs med flera uttalanden fungera? Om så är fallet behöver du inte bevilja behörigheter någon användare (som sedan är fri till allt som tillåts av den behörigheten) och istället bevilja behörigheterna till koden (som bara gör vad den är kodad för att göra). Modulsignering är hur du uppnår detta. Det allmänna konceptet är:
- Skapa de lagrade proceduren (erna) och / eller TVF: erna med flera uttalanden för att utföra önskad åtgärd.
- Bevilja
EXECUTEpå dessa moduler till vilken användare och / eller roller som helst för att utföra dessa åtgärder - Skapa ett certifikat
- Signera modulen / modulerna med det certifikatet (med
ADD SIGNATURE) - Kopiera certifikatet till
[master]-databasen (dvs. skapa ett certifikat i[master]med den offentliga nyckeln av certifikatet som används för att signera modulen / modulerna. - Skapa en inloggning från certifikatet som kopieras till
[master] - Bevilja vilken instans som helst- nivå permissio ns är nödvändiga för den certifikatbaserade inloggningen (som kan inkludera att lägga till den i roller på instansnivå).
För några exempel, se:
Svar
Det är ett säkerhetsproblem. Du kan aldrig gå fel om du följer Principen för minst privilegierade . Med andra ord, om en autentiserande rektor inte behöver ett visst tillstånd, då behöver du inte ” t ge dem dem. Ger du ut information om vilken typ av lås på din dörr till andra människor som inte behöver veta det om ditt hus? Jag hoppas inte. De skulle nog inte göra någonting, men det är fortfarande inte klokt.
Om vi baserade dataprinciper på grund av tur och generositet skulle vi ha större problem ganska ofta. Säkerhet är en aspekt där du bara ska bevilja när du kan försvara varför du beviljade. Du ger helt enkelt någon mer information än de behöver veta . Gör det inte. Serverstatus är fortfarande känsligt.
sys.dm_db_missing_index_details) och de vill veta exakt vilka risker det innebär.