Dette spørgsmål påpeger, at “Vis servertilstand” -tilladelse er nødvendig for forskellige DMVer (dynamiske ledelsesvisninger), men jeg kan ikke finde noget om, hvem du gøre og ikke ønsker at give tilladelse til.

Nu forstår jeg naturligvis “mindst tilladelser”, og hvorfor du ikke bare vil give det til nogen, men jeg kan ikke finde nogen vejledning i, hvordan jeg vurderer, om det SKAL gives eller ej .

Så mit spørgsmål: Hvad er sikkerheds- og ydeevneimplikationerne ved at give en bruger “Vis servertilstand” tilladelse. Hvad kan de gøre, som de måske ikke burde have lov til at gøre …

Opdater : en implikation er, at brugeren kan bruge DMVer til at se på forespørgsler. Hvis forespørgslerne eller forespørgselsparametrene kan indeholde fortrolige oplysninger, som brugeren ellers ikke kunne se, ville VIEW SERVER STATE tillade dem at gøre det (dvs. dob = eller ssn =).

Svar

Der er ingen væsentlige præstationsproblemer, som jeg kan tænke på ved at give denne tilladelse. Fra et sikkerhedsperspektiv risikerer du at lade en bruger se, hvad du de fleste detaljer om dine svage punkter, så for eksempel kan en ondsindet bruger se dine mest almindelige ventestatistikker, hvilket kan hjælpe dem med at målrette et DoS-angreb mod din server.

Er dette muligt? Absolut. Er dette sandsynligvis? Jeg er tvunget til at sige nej, men husk, at det anslås, at 90 procent af angrebene på virksomheder er fra interne angribere.

Svar

Som administrator vil du se disse oplysninger som i dit domæne (ydeevne / indeksbrug / osv.), men der er potentielt tvingende grunde til, at en udvikling opmentorganisation ønsker disse oplysninger til et stort ældre system, de understøtter – identificering af zombieborde, der f.eks. kun berøres af vedligeholdelsesprocesser.

I sidste ende ender det altid med at blive et spørgsmål om “held og generøsitet” da opkaldet om, hvorvidt en bestemt anmodning er berettiget, ender med at blive et blødt valg og ikke en skarp formel. Anvendelsen af bedste praksis-mønstre uden at se på konteksten er i sig selv et ret grimt antimønster, og virkeligheden er, at mange nærmer sig deres positioner med “tale med hånden” som udgangspunkt.

Svar

Med hensyn til ydeevneimplikationer kender jeg ikke noget til denne eller andre tilladelser.

Med hensyn til:

Hvad kan de gøre, som de måske ikke burde have lov til at gøre

Enkelt sagt, de kan se ting at de måske ikke skulle se. Og tænk ikke på dette i form af bare SQL Server. Denne særlige tilladelse regulerer også DMVer som sys.dm_os_sys_info og en hel del andre, der giver indsigt i værtsmaskinen (hardware, tjenester osv.). Du ved ikke altid, hvilken info der kan bruges mod dig. Og selvom det er ok med nogen, der ser alt, der er tilladt i denne tilladelse nu, tilføjes undertiden DMVer i Service Packs / Kumulative opdateringer, og måske bliver et nyt stykke information udsat, som du ikke er opmærksom på.

Jeg kan ikke finde nogen vejledning i, hvordan jeg vurderer, om det SKAL gives eller ej.

Da du allerede har nævnt at give folk de nødvendige nødvendige tilladelser, hvad dette virkelig kommer ned til er: har nogen brug for denne tilladelse til ad hoc brug? Betydning, har nogen brug for fleksibiliteten ved at komme med deres egne forespørgsler? Ville oprettelse af en eller flere lagrede procedurer og / eller TVFer med flere udsagn fungere? Hvis det er tilfældet, behøver du ikke give tilladelser til nogen bruger (som derefter er fri til alt, hvad tilladelsen tillader), og i stedet giver du tilladelserne til koden (som kun gør, hvad det er kodet til at gøre). Modulunderskrivelse er, hvordan du opnår dette. Det generelle koncept er:

  1. Opret den (de) lagrede procedure (r) og / eller TVF (er) med flere udsagn for at udføre den eller de ønskede handlinger.
  2. Giv EXECUTE på disse moduler til enhver bruger og / eller rolle, der har brug for at udføre disse handlinger
  3. Opret et certifikat
  4. Underskriv modulet / modulerne ved hjælp af det certifikat (ved hjælp af ADD SIGNATURE)
  5. Kopier certifikatet til [master] -databasen (dvs. opret et certifikat i [master] ved hjælp af den offentlige nøgle af det certifikat, der blev brugt til at underskrive modulet / modulerne.
  6. Opret et login fra certifikatet kopieret til [master]
  7. Giv uanset instans- niveau permissio ns er nødvendige for det certifikatbaserede login (som kan omfatte tilføjelse af det til roller på instansniveau).

For nogle eksempler, se:

Svar

Det er et sikkerhedsproblem. Du kan aldrig gå galt, hvis du følger Princippet om mindst privilegerede . Med andre ord, hvis en godkendende hovedstol ikke har brug for en bestemt tilladelse, så don ” t give det til dem. Giver du oplysninger om typen af låse på din dør til andre mennesker, der ikke behøver at vide det om dit hus? Jeg håber ikke. De ville sandsynligvis ikke gøre noget, men det er stadig ikke klogt.

Hvis vi baserede dataprincipper ud af held og generøsitet, ville vi have større problemer ganske ofte. Sikkerhed er en aspekt, hvor du kun skal give, når du kan forsvare, hvorfor du gav. Du giver simpelthen nogen mere information, end de har brug for at vide . Gør det ikke. Servertilstand er stadig følsom.

Kommentarer

  • Hvem siger, at de giver det unødvendigt? OPen skal muligvis give det til nogen at undersøge et specifikt emne (f.eks. se på sys.dm_db_missing_index_details), og de vil vide, hvad risikoen er ved at gøre det.
  • Jeg tror jeg ' mangler jeg mærket med dette spørgsmål, kan jeg ikke ' ikke se noget i spørgsmålet, der indikerer nødvendigheden af tilladelsen.
  • @ThomasStringer: spørgsmålet er ikke ' t om nødvendighed, det ' handler om risiko . For at sætte det i monetære termer ved du måske, hvilke yderligere risici dette ville udsætte dine servere for, og så være i stand til at sige nej til en krone og ja til en million dollars. Jeg don ' t, men jeg vil.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *