Dette spørsmålet påpeker at «View Server State» -tillatelse er nødvendig for forskjellige DMV-er (dynamiske administrasjonsvisninger), men jeg kan ikke finne noe om hvem du gjøre og ikke vil gi tillatelse til.
Nå forstår jeg selvfølgelig «minst tillatelser», og hvorfor du ikke bare vil gi det til noen, men jeg kan ikke finne noen veiledning om hvordan jeg skal vurdere om det BØR gis eller ikke .
Så, spørsmålet mitt: Hva er sikkerhets- og ytelsesimplikasjonene ved å gi en bruker «View Server State» -tillatelse. Hva kan de gjøre som de kanskje ikke burde ha lov til å gjøre …
Oppdater : en implikasjon er at brukeren vil kunne bruke DMV for å se på spørsmål. Hvis spørringene eller spørringsparametrene kan inneholde konfidensiell informasjon som brukeren ellers ikke kunne se, vil tillatelse av VIEW SERVER STATE tillate dem å gjøre det (dvs. dob = eller ssn =).
Svar
Det er ingen viktige ytelsesproblemer som jeg kan tenke på å gi denne tillatelsen. Fra et sikkerhetsperspektiv risikerer du å la en bruker se hva du de fleste detaljer om dine svake punkter, så for eksempel kan en ondsinnet bruker se de vanligste ventestatistikkene dine, noe som kan hjelpe dem med å målrette et DoS-angrep mot serveren din.
Er dette mulig? Definitivt. Er dette sannsynligvis? Jeg er tvunget til å si nei, men husk at det anslås at 90 prosent av angrepene mot selskaper er fra interne angripere.
Svar
Som administrator vil du se på at denne informasjonen er i domenet ditt (ytelse / indeksbruk / etc), men det er potensielt tvingende grunner til at en utvikling Opment Organization vil ha denne informasjonen for et stort eldre system de støtter – å identifisere zombie-tabeller som bare berøres av for eksempel vedlikeholdsprosesser.
Til slutt ender det alltid med å bli et spørsmål om «flaks og sjenerøsitet» siden samtalen om hvorvidt en bestemt forespørsel er berettiget, ender opp med å være et mykt valg og ikke en skarp formel. Bruk av beste praksis-mønstre uten å se på kontekst er i seg selv et ganske stygt antimønster, og virkeligheten er at mange nærmer seg sine posisjoner med «snakk med hånden» som utgangspunkt.
Svar
Når det gjelder ytelsesimplikasjoner, er jeg ikke kjent med noe som helst for denne eller andre tillatelser.
Angående:
Hva kan de gjøre som de kanskje ikke burde ha lov til å gjøre
Enkelt sagt, de kan se ting at de kanskje ikke skulle se. Og ikke tenk på dette når det gjelder bare SQL Server. Denne spesielle tillatelsen styrer også DMV-er som sys.dm_os_sys_info og ganske mange andre som gir innsikt i vertsmaskinen (maskinvare, tjenester osv.). Du vet ikke alltid hvilken informasjon som kan brukes mot deg. Og selv om det er greit med noen som ser alt som er tillatt av denne tillatelsen nå, blir det noen ganger lagt til DMV-er i Service Packs / Kumulative oppdateringer, og kanskje en ny informasjon blir utsatt som du ikke er klar over.
Jeg kan ikke finne noen veiledning om hvordan jeg skal evaluere om det SKAL gis eller ikke.
Siden du allerede nevnte å gi folk de minste tillatelsene som trengs, er dette dette egentlig egentlig: trenger noen denne tillatelsen for ad hoc bruk? Betyr, trenger noen fleksibiliteten til å komme med sine egne spørsmål? Ville det å lage en eller flere lagrede prosedyrer og / eller TVFer med flere utsagn fungere? I så fall trenger du ikke å gi tillatelser noen brukere (som da er fri til alt som er tillatt av den tillatelsen), og i stedet gir du tillatelsene til koden (som bare gjør det den er kodet for å gjøre). Modulesignering er hvordan du oppnår dette. Det generelle konseptet er:
- Opprett den lagrede prosedyren (e) og / eller TVF (erne med flere utsagn) for å utføre den / de ønskede handlingene.
- Gi
EXECUTEpå disse modulene til hvilken bruker og / eller rolle som helst for å utføre disse handlingene - Opprett et sertifikat
- Signer modulen (e) ved hjelp av det sertifikatet (ved hjelp av
ADD SIGNATURE) - Kopier sertifikatet til
[master]-databasen (dvs. opprett et sertifikat i[master]ved hjelp av den offentlige nøkkelen av sertifikatet som brukes til å signere modulen (e). - Opprett en pålogging fra sertifikatet som er kopiert til
[master] - Gi uansett tilfelle- nivå permissio ns er nødvendig for den sertifikatbaserte påloggingen (som kan inkludere å legge den til roller på instansnivå).
For noen eksempler, se:
Svar
Det er et sikkerhetsproblem. Du kan aldri gå galt hvis du følger Prinsippet om minst privilegerte . Med andre ord, hvis en autentiserende rektor ikke «t trenger en bestemt tillatelse, så ikke» t gi det til dem. Gir du informasjon om typen lås på døren til andre mennesker som ikke trenger å vite det om huset ditt? Jeg håper ikke det. De ville sannsynligvis ikke gjøre noe, men det er fortsatt ikke forsvarlig.
Hvis vi baserte dataprinsipper på grunn av flaks og generøsitet, ville vi ha større problemer ganske ofte. Sikkerhet er en aspekt der du bare skal gi når du kan forsvare hvorfor du ga. Du gir rett og slett noen mer informasjon enn de trenger å vite . Ikke gjør det. Servertilstanden er fremdeles følsom.
sys.dm_db_missing_index_details), og de vil vite hva risikoen er for å gjøre det.