Användare, roller och rättigheter i SQL Server - del 4
Förord
Att hantera rättigheter i SQL Server är ett ganska stort område, med många möjligheter. Många väljer dock de enkla och säkerhetsmässigt sämre vägarna eftersom de inte kräver så mycket administration. I dessa artiklar ska jag visa vilka sätt man kan hantera rättigheter på, samt visa att det faktiskt inte är så mycket jobb att administrera dem.Innehåll
»»
»
»
»
»
»
»
»
Relaterade artiklar
» Användare, roller och rättigheter i SQL Server - del 1» Användare, roller och rättigheter i SQL Server - del 2
» Användare, roller och rättigheter i SQL Server - del 3
» Inloggning i SQL Server
Introduktion
Detta är sista delen i en serie artiklar som behandlar hantering av användare, roller och rättigheter i SQL Server. Artiklarnas innehåll är följande:Del 1: Inloggningar och användare
Del 2: Roller
Del 3: Rättigheter
Del 4: Olika lösningar för rättighetshantering
Uppgiften
Det finns massor av definitioner av vad en databas är, men en väldigt enkel och generell beskrivning som jag brukar använda är denna:En centraliserad samling av data, med funktionalitet för insättning och uttag av datan.
Nyckelordet här är centraliserad. Med detta menar jag att datan tillhör inte en specifik applikation, utan den hanteras centralt av ett databashanteringssystem (DBMS) vilket tillhandahåller funktioner för att hantera datan. I denna hantering ingår styrning av rättigheter för vilka användare och/eller applikationer som får använda datan och hur de får använda den.
Med SQL Server som DBMS har man ett flertal möjligheter att hantera tillgången till datan. I tidigare artiklar i denna serie har jag beskrivit hur man administrerar rättigheter till data genom inloggningskonton, användare och roller. I denna sista del ska jag beskriva några exempel på hur man kan gå tillväga för att sätta upp ett rättighetssystem.
Inloggning med SQL Server-konton
En vanlig metod i applikationer med många användare som behöver olika rättigheter är att ge varje användare ett inloggningskonto i SQL Server. Detta konto knyter man sedan till användare i den eller de databaser användaren ska ha tillgång till, och sedan sätter man rättigheter på databasobjekt för användarna och/eller roller man skapar och delar in användarna i. När en användare ska använda applikationen får han först skriva in sitt inloggningsnamn och lösenord till SQL Server i en ODBC-inloggningsruta, och därefter används dessa uppgifter tillsammans med en DSN för att specificera vilken SQL Server instans som ska anslutas till och på vilket sätt det ska göras. Administrativt är det hyfsat enkelt att sköta, med en domän med central inloggning kan man 'pusha' ut DSN-uppgifterna till varje klientdator och i SQL Server skapar man nya inloggningskonton för nya användare i t ex Enterprise Manager. På detta sätt kan man styra precis vilka rättigheter varje användare ska ha, och en fördel gentemot att använda Windows-användare (se nedan) är att användarna inte behöver vara inloggade på maskinen de arbetar från, det räcker att de loggar in i applikationen. Det kan vara användbart om det är en webbapplikation som användaren ska använda, där applikationen körs från en webbserver. Nackdelar är att man inte kan sätta upp alls samma användarpolicys iför SQL Server-konton som man kan i Windows. T ex kan man inte konfigurera hur ofta lösenord måste bytas ut, vilket tillsammans med en del andra faktorer innebär att man normalt rekommenderar att använda enbart integrerad Windows-inloggning i SQL Server om man vill ha hög säkerhet.
Inloggade användare i Windows
Om applikationen man ska köra är en Windows-applikation som man ska köra från sin klientdator där man redan är inloggad i operativsystemet kan det vara en bra idé att använda integrerad Windows-inloggning istället för SQL Server-konton. Man kan fortfarande använda en DSN för att definiera vilken SQL Server-instans man ska koppla sig mot, men det går naturligtvis även bra att bygga in denna information i applikationens kod. Styrningen av rättigheter i SQL Server är densamma, man ger en Windows-användare rätt att använda instansen (logga in), kopplar denna Windows-användare till en användare i den databas som ska användas och sätter sedan rättigheter för denna användare. Man kan naturligtvis fortfarande placera databasanvändaren i en eller flera roller och sätta rättigheter för dem. På detta vis slipper användaren göra en extra inloggning och har därmed ett lösenord färre att komma ihåg, och precis som jag beskrev ovan har man större möjlighet att styra säkerhetspolicys och man får en bättre säkerhet överlag. Det finns egentligen inga nackdelar med att använda integrerad Windows-inloggning om miljön tillåter det, dvs att man har en domän som användarna loggar in i, och applikationen de använder körs när de är inloggade i Windows med denna användare, men det finns naturligtvis situationer då det inte är möjligt att göra det och man tvingas använda SQL Server-konton istället.
Grupper i Windows
Har man ett riktigt stort nätverk med många användare som alla ska ha tillgång till SQL Server kan det vara väldigt tidskrävande att arbeta med att ge dem tillgång till SQL Server, mappa dem mot användare i databaser och sätta rättigheter för alla. Om man samtidigt har användargrupper definierade i domänen där Windows-användarna redan är indelade i grupper som motsvarar vad de ska kunna göra i databasen, t ex administratörer, marknadsföring, kundsupport etc så kan man använda dessa grupper istället för användarna. Genom att ge en användargrupp i Windows-domänen tillstånd att koppla sig mot SQL Server-instansen får automatiskt alla medlemmar i den gruppen rätt att göra det. Därefter gör man i SQL Server ingen skillnad på om det är en enskild Windows-användare som loggat in eller om det är medlemskapet i en grupp som gett tillstånd att logga in. Man skapar som vanligt en användare i den databas som ska användas och mappar domänanvändargruppen till denna databasanvändare. Sedan kan man som vanligt skapa databasroller och dela in databasanvändarna i dessa, men eftersom användarna redan motsvarar grupper av domänanvändare så är detta ofta inte nödvändigt.
Hantering av rättigheter i applikationen
De tre varianter som hittills presenterats är alla exempel på hur rättigheter kan hanteras av en databasadministratör med kunskaper i SQL Server. Dock är det i många företag, framförallt mindre sådana, ofta så att det inte finns någon dedikerad person för att ansvara för detta. De som ansvarar för ett system har ofta inte tillräckliga kunskaper i SQL Server och därför ser man hanteringen av användare, roller och rättigheter i SQL Server som ett svårt område. Det kan också vara så att utvecklarna av systemet inte har dessa kunskaper, men man vill ändå se till att användarna loggar in i systemet och kan ha olika rättigheter i det. Istället väljer man att hantera rättigheterna i applikationen. Det vanligaste scenariot är att man låter applikationen logga in med ett SQL Server-konto, vilket är mappat mot en databasanvändare med mer eller mindre fullständiga rättigheter i databasen. Användaren är ofta helt enkelt medlem i databasrollen db_owner vilket ger den fullständiga rättigheter i databasen. Sedan skapar man en eller flera tabeller för att lagra användare för applikationen samt vilka rättigheter de har. När en användare sedan ska använda systemet får de skriva in inloggningsnamn och lösenord, men dessa uppgifter används alltså inte för att logga in i SQL Server (vilket applikationen gör automatiskt genom det SQL Server-konto man skapat) utan istället jämförs de med datan i användartabellen. Om det finns en användare i tabellen med det inloggningsnamn och lösenord som angivits så anser man att inloggningen är validerad. Rättigheter sätts sedan inte per databasobjekt utan istället definieras och valideras detta av applikationen.Som jag nämnde tidigare tror jag att man väljer en rättighetshantering av denna typ pga bristande kompetens i SQL Servers inbyggda hantering för detta. Visst kan det i enstaka fall finnas affärsregler och situationer som gör att man måste hantera rättigheter inom applikationen, men generellt sett anser jag att man ska undvika att göra det. Dels strider det mot själva definitionen av en databas, att den ska kunna utnyttjas av flera nuvarande och framtida applikationer istället för att bindas till en viss applikation just nu, men det skapar också ett antal problem. Dels är det ett antal säkerhetsproblem man ställs inför, men några av dessa kan man hantera genom att använda applikationsroller (se nästa stycke). Men det är även rent hanteringsmässiga problem, istället för att låta administratörer utnyttja sin kompetens och SQL Servers verktyg (inbyggda och tredjeparts) så tvingar man dem att administrera rättigheter genom enbart en applikation. Om man i framtiden behöver ändra på rättighetssystemet innebär det ofta att ändringar måste göras i applikationskoden.
Applikationsroller
Det största problemet med att hantera rättigheter genom applikationen är dock säkerhetsaspekten. Eftersom alla användare loggar in med samma inloggningskonto i SQL Server så innebär det att alla har egentligen samma rättigheter, det är bara applikationens funktionalitet som bestämmer vem som får göra vad. Men vad händer då om någon hittar ett sätt att skicka ett kommando till SQL Server utöver de som är tänkta att användas i applikationen? Det kan t ex göras med s k SQL Injection (se mer i min artikel Unclosed quotationmark - ett vanligt säkerhetsproblem), vilket i korthet innebär att man utnyttjar dåligt skriven kod för databasaccess i applikationen för att skicka vilka SQL-uttryck som helst till SQL Server. Om det konto som applikationen loggar in mot SQL Server med då har fullständiga rättigheter i databasen innebär det att användaren kan göra vad som helst i databasen, t ex ta bort användartabellen. I värsta fall loggar applikationen in med kontot sa (systemadministratör med fullständiga rättigheter i hela SQL Server-instansen) och då kan man ta bort hela databaser, köra operativsystemskommandon etc. Tyvärr är det många fler applikationer än man tror som loggar in som sa.Även om man har skyddat sig mot SQL Injection, eller om man har skapat ett inloggningskonto med bara precis de rättigheter användarna i applikationen behöver vilket applikationen loggar in med så innebär det fortfarande att alla användare av applikationen faktiskt har samma rättigheter i databasen. Det är bara applikationens funktionalitet som begränsar vad de kan göra, men bara genom applikationen. Om någon har tillgång till de inloggningsuppgifter applikationen använder för att logga in kan de använda dessa för att logga in i SQL Server med vilket verktyg som helst, t ex Enterprise Manager eller Query Analyzer. Med dessda kan de utföra allt som applikationen kan utföra, vilket ofta är mer än vad de kan göra som användare av applikationen. Dessa inloggningsuppgifter kan vara svåra att skydda helt. Ibland ligger de helt enkelt bara i en textfil som applikationen läser (global.asa är valigt för webbapplikationer), och kan någon då komma åt denna fil har de skaffat sig inloggningsuppgifter till SQL Server. Ibland hårdkodar man dem i applikationen, men att plocka ut strängar ur exekverbara filer är ofta ganska trivialt. Visst kan man skydda sig till viss del genom att kryptera uppgifterna, men krypteringen kan naturligtvis knäckas.
Här kan dock applikationsroller vara en viss hjälp. Som jag beskrev i del 2 är applikationsroller en speciell typ av roller vilken ej har några medlemmar, men man kan sätta rättigheter på databasobjekt för dem precis som för andra roller eller databasanvändare. Genom att låta applikationen logga in med ett inloggningskonto som inte har några rättigheter alls mer än att just ansluta sig till en databas och sedan använda sig av applikationsroller kan man förhindra att någon med applikationens inloggningsuppgifter använder databasen med andra verktyg. Även om de får tag i applikationens inloggningsnamn och lösenord kan de inte göra mer än att ansluta till databasen i t ex Query Analyzer, de har inga rättigheter att ens läsa någon data från den. När någon skriver in sina inloggningsuppgifter i applikationen och valideras av denna (genom att jämföra med värden i en användartabell) så kan applikationen sedan låta denna användarens uppkopplingar mot SQL Server anta medlemskap i den applikationsroll som har de rättigheter den användaren ska ha.
0 Kommentarer