SQL Server-sikkerhedsovervejelser

DBA er vogter af dataene, og der er to aspekter ved at være værge. Den første er integritet. Det inkluderer opgaver som at kontrollere databasens konsistens, oprette sikkerhedskopier og, hvis der skulle opstå problemer, have en veldesignet, omfattende databasegendannelsesplan.

Det andet aspekt er sikkerhed. Det foreslår at sikre, at kun autoriserede brugere har adgang til dataene og kun til de data, de har brug for.

Du kan finde adskillige ressourcer dedikeret til sikkerhed på nettet. Jeg synes dog, at nogle vigtige ting mangler passende opmærksomhed. I denne artikel vil jeg gerne fokusere på disse muligheder og demonstrere, hvorfor det er vigtigt at være opmærksom på dem og håndtere dem korrekt.

En mission om at kompromittere en SQL-server

Lad os have et rollespil, hvor du er en hemmelig agent, og din mission, hvis du accepterer det, er at stjæle meget vigtige data fra TargetDB database hostet af en SQL Server. Du skal hente disse data og slette dem.

Det er muligt at få et login til dig, men hvert login på serveren har eksplicit NÆKTEDE tilladelser på måldatabasen og dataene. Den eneste information, som vores agent kan give dig, er den, der er genereret til verifikation af sikkerhedsprotokollen under oprettelsen af dit login.

Databaseoplysninger fra målserveren.

Servertilladelser:

Databasetilladelser:

Som enhver anstændig agent, lad os lave lektierne og tjekke, hvad du har med at gøre.

Du kan ikke bare logge ind og oprette forbindelse til TargetDB , da hver enkelt tilladelse nægtes til dit login og dens tilknyttede bruger eksplicit. Du skal komme ind fra en anden database.

En låst dør

Cross-database handlinger er ikke nemme ting at gøre. Betragt det som en lukket dør med to låse på. Vi vil ikke fokusere på de tekniske detaljer her, men du kan henvise til udvidelse af databaseefterligning ved at bruge EXECUTE AS MSDN-artiklen (jeg anbefaler stærkt at gøre det).

Den første lås er Stillid til godkendelsesværktøjet , og den anden er Stillid til databasen .

Lad os starte med den første lås. At have tillid til godkendelsesværktøjet betyder, at for at få adgang til en anden database B skal ejeren af database A tildeles (eksplicit eller implicit) AUTHENTICATE tilladelse i database B.

Vent et øjeblik! Godkendelsesværktøjet på databaseniveau er ejeren af selve databasen (bland det ikke sammen med db_owner databaserolle!).

Tjek databaseejere:

Selvom de følger ret god praksis ved at bruge én konto pr. server, hvilket ikke er SA , på denne måde har de venligt åbnet den første lås for dig.

Lad os fokusere på den anden lås.

På en eller anden måde skal du have en database oprettet på serveren med TRUSTWORTHY ejendom TIL . Den bedste praksis her er at indstille TRUSTWORTHY-databaseegenskaben til OFF .

Dette er tidspunktet, hvor vi bør sige:hvad hvis du allerede har sådan en database?

Det er MSDB-databasen.

Den anden lås er udført. Du behøvede ikke engang at bryde nogen af låsene.

Vigtigheden af rollen db_owner

Lige nu skal du håndtere én udfordring. På en eller anden måde skal du komme ind i MSDB-databasen med db_owner databaserolle, fordi den har implicit, efterlignende tilladelse.

Da MSDB normalt ikke er i databaseadministratorernes fokus, er denne mission ikke længere umulig. Lad os se, hvad du kan gøre, bare fordi du har en bruger med db_owner databaserolle i MSDB-databasen:

Prøv at oprette forbindelse til TargetDB :

Dette er en forventet fejl. Husk sikkerhedsprotokollen anvendt på det medfølgende login. Lad os starte det.

Prøv at oprette forbindelse til TargetDB og for at vælge måldata:

Det virker! Lad os ændre det og derefter bekræfte handlingen.

Det er alt.

Mission fuldført.

Som du så, fokuserede jeg på en bestemt kombination af sikkerhedsdatabasekonfiguration. Disse var ejeren af databasen og TRUSTWORTHY database mulighed med særlig opmærksomhed på MSDB. Det præsenterede scenarie var blot et, hvor følsomme data kan kompromitteres på samme måde. Lad os gennemgå et andet muligt scenarie nu.

Databaseejer + TRUSTWORTHY

Lad os tjekke baggrundsdetaljerne begyndende med det velkendte problem:databaseejerskab. Hvilke loginoplysninger skal ejeren af din(e) database(r) bruge? Mange mennesker siger, at SA er et passende valg.

Jeg lavede en hurtig Google-søgning og fandt svar som følgende:

"Jeg kan ikke huske, at dette har været en bekymring for mig nogensinde. Andet end at se irriterende ud i rapporter, eller at være ude af stand til at fjerne brugeren, hvis de ejer en database, men jeg tror ikke, det påvirker serverdriften. Du kan bare vælge sa for konsekvens."

Eller

"Jeg tror ikke, at det burde være bekymrende at eje en database af SA eller nogen anden bruger. Det afgørende er, hvem der udfører 'hvad' i din database. Så det er en god idé at oprette brugere med gyldige privilegier. For nemheds skyld kan du angive ejeren som SA.”

Den nuværende situation er, at brug af SA-kontoen som databaseejer er den VÆRSTE praksis . Jeg synes personligt, at dette bør fremhæves på hver blog og i enhver dokumentation relateret til dette emne.

Hvis vi opretter brugere med kun gyldige privilegier, ville det være nok, men det er desværre ikke sådan, tingene normalt fungerer. Du skal være forberedt på de 'muligt værste' scenarier. Tænk bare på, hvad vi kunne gøre i vores tidligere eksempler, hvis standarddatabaseejeren var SA !

Lad os fortsætte med den anden mulighed, den TROLIGE database mulighed. Situationen er en smule bedre, men den har stadig et fælles problem. Som det almindeligvis anses for, er den bedste praksis her at Indstille 'Plideværdig' databaseegenskab til Fra . Vi har lige set, hvorfor denne mulighed er dårlig .

Men dette er ikke alt. Hvis du prøver at finde nogle scripts til at kontrollere denne egenskab, vil du sandsynligvis finde et script, der ligner dette:

SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'

sp_Blitz script, der kontrollerer SQL Server-sundheden, kontrollerer også standardindstillingerne for databaserne (inklusive TRUSTWORTHY som en standardværdi på 0) og rapporterer hver database, der har ikke-standardindstillinger. Men scriptet springer systemdatabaserne over.

Desuden er der en MS KB artikel, som fokuserer på dette emne. Se retningslinjerne for brug af TRUSTWORTHY-databaseindstillingerne i SQL Server:

Der er et kodeeksempel i artiklen, som viser de databaser, der har TRUSTWORTHY bit ON, og hvis databaseejere tilhører sysadmin-serverrollen:

SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'

Hvad er almindeligt i disse scripts? Hvert script udelukker MSDB, men som MS KB-artiklen bemærker, har du lige set det i vores "mission":

Bemærk :Som standard er TRUSTWORTHY-indstillingen sat til ON for MSDB-databasen. Ændring af denne indstilling fra dens standardværdi kan resultere i uventet adfærd fra SQL Server-komponenter, der bruger MSDB-databasen.

Jeg vil gerne understrege, at hovedfokuset i dette afsnit hverken er TRUSTWORTHY-databasemuligheden eller databaseejeregenskaben i sig selv, men kombinationen af disse to muligheder. Jeg har mest koncentreret mig om MSDB, fordi TRUSTWORTHY-indstillingen er sat til ON for MSDB-databasen som standard.

Konklusion

Det er alt for nu. Vi gennemgik og tjekkede de praktiske scenarier, der vedrører SQL Server-sikkerhed. Vi har også gennemgået så vigtige databasemuligheder, som ejeren af databasen og TRUSTWORTHY-databaseindstillingen.