DBA är väktaren av data, och det finns två aspekter av att vara väktare. Den första är integritet. Det inkluderar uppgifter som att kontrollera databasens konsistens, skapa säkerhetskopior och, om några problem skulle uppstå, ha en väl utformad, omfattande databasåterställningsplan.
Den andra aspekten är säkerhet. Det föreslår att man ser till att endast auktoriserade användare har tillgång till data och endast till data som de behöver.
Du kan hitta många resurser dedikerade till säkerhet på webben. Jag tror dock att vissa viktiga saker saknar lämplig uppmärksamhet. I den här artikeln skulle jag vilja fokusera på dessa alternativ och visa varför det är viktigt att vara medveten om dem och att hantera dem på rätt sätt.
Ett uppdrag att kompromissa med en SQL-server
Låt oss ha ett rollspel där du är en hemlig agent, och ditt uppdrag, om du accepterar det, är att stjäla mycket viktig data från TargetDB databas värd av en SQL Server. Du måste skaffa denna data och radera den.
Det är möjligt att få en inloggning åt dig, men varje inloggning på servern har uttryckligen NEKRADE behörigheter för måldatabasen och data. Den enda information som vår agent kan ge dig är den som genereras för verifiering av säkerhetsprotokollet under skapandet av din inloggning.
Databasinformation från målservern.
Serverbehörigheter:
Databasbehörigheter:
Som varje anständig agent, låt oss göra läxorna och kolla vad du har att göra med.
Du kan inte bara logga in och ansluta till TargetDB , eftersom varje enskild behörighet nekas för din inloggning, och dess mappade användare uttryckligen. Du måste komma in från en annan databas.
En låst dörr
Korsdatabasåtgärder är inte lätta saker att göra. Se det som en stängd dörr med två lås på den. Vi kommer inte att fokusera på de tekniska detaljerna här, men du kan hänvisa till Extending Database Impersonation genom att använda EXECUTE AS MSDN-artikeln (jag rekommenderar starkt att du gör det).
Det första låset är Lita på autentiseringsenheten , och den andra är Lita på databasen .
Låt oss börja med det första låset. Att lita på autentiseringsverktyget innebär att för åtkomst till en annan databas B måste ägaren av databas A ges (explicit eller implicit) AUTHENTICATE behörighet i databas B.
Vänta en minut! Autentiseringsenheten på databasnivå är ägaren till själva databasen (blanda inte ihop den med db_owner databasroll!).
Kontrollera databasens ägare:
Även om de följer ganska god praxis genom att använda ett konto per server, vilket inte är SA , på detta sätt har de vänligt öppnat det första låset för dig.
Låt oss fokusera på det andra låset.
På något sätt måste du ha en databas skapad på servern med TRUSTWORTHY egenskap PÅ . Den bästa praxisen här är att ställa in databasegenskapen TRUSTWORTHY till AV .
Detta är den tid då vi borde säga:tänk om du redan har en sådan databas?
Det är MSDB-databasen.
Det andra låset är klart. Du behövde inte ens bryta något av låsen.
Vikten av rollen db_owner
Just nu måste du ta itu med en utmaning. På något sätt måste du komma in i MSDB-databasen med db_owner databasroll eftersom den har implicit, imitera behörighet.
Eftersom MSDB vanligtvis inte är i databasadministratörernas fokus är detta uppdrag inte omöjligt längre. Låt oss se vad du kan göra bara för att du har en användare med db_owner databasroll i MSDB-databasen:
Försök att ansluta till TargetDB :
Detta är ett förväntat fel. Kom ihåg säkerhetsprotokollet som tillämpas på den angivna inloggningen. Låt oss börja.
Försök att ansluta till TargetDB och för att välja måldata:
Det fungerar! Låt oss ändra det och efter det verifiera åtgärden.
Det är allt.
Uppdrag fullbordat.
Som du såg fokuserade jag på en speciell kombination av säkerhetsdatabaskonfiguration. De var ägaren till databasen och TRUSTWORTHY databasalternativ med särskild uppmärksamhet på MSDB. Det presenterade scenariot var bara ett där känsliga uppgifter kan äventyras på samma sätt. Låt oss se över ett annat möjligt scenario nu.
Databasägare + TRUSTWORTHY
Låt oss kontrollera bakgrundsdetaljerna från det välkända problemet:databasägande. Vilka inloggningsuppgifter ska ägaren till din(a) databas(er) använda? Många säger att SA är ett lämpligt val.
Jag gjorde en snabb Google-sökning och hittade svar som följande:
"Jag kommer inte ihåg att det här har varit ett problem för mig någonsin. Annat än att se irriterande ut i rapporter, eller att inte kunna ta bort användaren om de äger en databas, men jag tror inte att det påverkar serverdriften. Du kan bara välja sa för konsekvens.”
Eller
"Jag tror inte att det borde vara något problem att äga en databas av SA eller någon annan användare. Det viktiga är vem som utför "vad" i din databas. Så det är en bra idé att skapa användare med giltiga privilegier. För enkelhetens skull kan du ange ägaren som SA.”
Den nuvarande situationen är att att använda SA-kontot som databasägare är den VÄRSTA praxis . Jag tycker personligen att detta bör lyftas fram på varje blogg och i varje dokumentation, relaterad till detta ämne.
Om vi skapar användare med endast giltiga privilegier skulle det räcka, men tyvärr är det inte så det brukar fungera. Du måste vara beredd på de "möjligt värsta" scenarierna. Tänk bara på vad vi skulle kunna göra i våra tidigare exempel om standarddatabasägaren var SA !
Låt oss fortsätta med det andra alternativet, det TILLITLIGA databasalternativ. Situationen är lite bättre men den har fortfarande ett vanligt problem. Som det vanligtvis anses vara den bästa praxisen här är att Ställa in databasegenskapen "pålitlig" på av . Vi har precis sett varför det här alternativet är dåligt .
Men detta är inte allt. Om du försöker hitta några skript för att kontrollera den här egenskapen, kommer du förmodligen att hitta ett skript som liknar detta:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'sp_Blitz skript som kontrollerar SQL Server-tillståndet kontrollerar också standardinställningarna för databaserna (inklusive TRUSTWORTHY som standardvärde på 0) och rapporterar varje databas som har icke-standardinställningar. Men skriptet hoppar över systemdatabaserna.
Dessutom finns det en MS KB-artikel, som fokuserar på detta ämne. Se riktlinjerna för användning av TRUSTWORTHY-databasinställningarna i SQL Server:
Det finns ett kodexempel i artikeln, som listar databaserna som har TRUSTWORTHY-biten ON, och vars databasägare tillhör 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'
Vad är vanligt i dessa skript? Varje skript utesluter MSDB, men som MS KB-artikeln noterar har du precis sett det i vårt "uppdrag":
Obs :Som standard är TRUSTWORTHY-inställningen inställd på ON för MSDB-databasen. Att ändra denna inställning från dess standardvärde kan resultera i oväntat beteende hos SQL Server-komponenter som använder MSDB-databasen.
Jag skulle vilja betona att huvudfokus i detta avsnitt varken är databasalternativet TRUSTWORTHY eller databasägarens egendom, utan kombinationen av dessa två alternativ. Jag har mest koncentrerat mig på MSDB eftersom TRUSTWORTHY-inställningen är inställd på ON för MSDB-databasen som standard.
Slutsats
Det var allt tills vidare. Vi gick igenom och kollade de praktiska scenarierna som relaterar till SQL Server-säkerhet. Vi har också granskat sådana viktiga databasalternativ, som ägaren till databasen och databasinställningen TRUSTWORTHY.
Jag ville bara sätta fokus på dessa alternativ eftersom – eftersom de är kritiska, särskilt när vi pratar om dem i kombination.