Användare, roller och rättigheter i SQL Server - del 3
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
» Inloggning i SQL Server
Introduktion
Detta är tredje 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
Allmänt om rättigheter i SQL Server
Vi har tidigare i den här serien tittat på inloggning i SQL Server, vilket ger tillgång till själva servern, användare, vilka ger tillgång till databaserna i servern, samt gruppering av användare i roller. När man väl loggat in i SQL Server och anslutit sig till en databas man har tillgång till (dvs där det finns en användare kopplad till det inloggningskonto man loggat in med) så bestäms vilka aktiviteter man kan utföra av vilka rättigheter som är tilldelade användaren, eller de roller som användaren är medlem i. För en del aktiviteter som påverkar servern snarare än en specifik databas ligger rättigheterna på loginnivå istället för användare. Det finns tre sorters rättigheter i SQL Server:- Rättigheter för objekt
Dessa hanterar vem som får använda objekt i databasen - Rättigheter för uttryck
Hanterar rättigheter för uttryck som inte direkt rör objekt - Inbyggda rättigheterDe rättigheter som finns i de fördefinerade server- och databasrollerna
Objekt och ägare
Innan vi kommer in på rättigheter ska vi kort definiera vad ett objekt är. I SQL Server hanteras tabeller, procedurer, vyer, egendefierade datatyper etc som s k databasobjekt. Detta innebär att de finns lagrade i systemtabellen sysobjects och har ett antal gemensamma egenskaper. En av dessa egenskaper är ägare. Den som skapar ett objekt blir normalt sett också ägare till det. Dock kan man när man skapar objektet specificera vem som ska vara ägare till det om det inte ska vara den inloggade användaren. I alla databaser finns en specialanvändare som heter dbo (database owner). Alla logins som är medlemmar i serverrollen sysadmins har automatiskt tillgång till alla databaser, och deras login mappas mot användaren dbo. Det betyder att om en person inloggad som sa skapar en tabell så får den dbo som ägare, men om det är användaren eric (ej medlem i sysadmin) som skapar den så är det eric som är ägare till den. Observera att specialanvändaren dbo ej ska blandas samman med databasrollen db_owner. Även om eric är medlem i db_owner (men ej i serverrollen sysadmin) så kommer hans tabell fortfarande ägas av eric, inte dbo.När man referar till objekt i SQL-satser så gör man det med deras fullt kvalificerade namn. Det består av server.databas.ägare.objektnamn (ex. cartman.Northwind.dbo.Orders), men normalt sett skriver man inte ut server eller databas, vilket då implicerar den server och databas man är inloggad på. Ofta skrivs ej heller ägare ut, men det bör man göra eftersom flera objekt i en databas kan ha samma namn om de har olika ägare (eftersom de därmed har olika fullt kvalificerade namn). Om man enbart anger objektnamn så kontrollerar SQL Server först om det finns ett objekt med det namn man angivit, vilket ägs av den inloggade användaren och använder detta om det existerar. Gör det inte det så testar den om det finns ett som ägs av dbo, och använder isåfall det. Det innebär för det första att man kan referera till fel objekt (om man har rättighet till det), och för det andra så måste SQL Server göra två kontroller om det inte finns ett objekt som ägs av den inloggade användaren. Ta därför för vana att alltid ange objekt i formen ägare.objektnamn i alla SQL-satser. Ytterligare ett tips är att alltid ha dbo som ägare till alla objekt i databasen, just precis för att man så ofta inte anger objekt med dess ägare när man refererar till dem. Ibland vill man förstås ha specifika ägare till objekt, men om det ej behövs bör man använda dbo. Ett sista tips om objektnamn: undvik otillåtna tecken i namn på objekt. Exempel på sådana tecken är mellanslag och punkt. Om man ändå vill ha med dessa tecken i ett namn, eller använda sig av reserverade ord som namn på objekt, så måste man ange dessa namn med hakparenteser runt dem. Ex:
SELECT * FROM [min.databas].dbo.[min tabell]
Rättigheter för objekt
För att använda ett objekt måste man ha rättigheter för objektet. Dessa rättigheter kan sättas för varje objekt och de olika operationer man kan utföra på objektet, samt för varje användare och/eller roll i databasen. De rättigheter man kan sätta per objekt är följande:- Tabeller: För varje tabell kan man sätta SELECT-rättighet för att kunna läsa data, och INSERT, UPDATE och DELETE för att kunna modifiera data, samt REFERENCES för att låta tabeller med andra ägare referera till tabellen i foreign keys.
- Vyer: Rättigheter för vyer motsvarar de för tabeller, förutom REFERENCES.
- Kolumner: För specifika kolumner i tabeller och vyer kan man sätta SELECT, UPDATE och REFERENCES rättigheter (eftersom INSERT och DELETE påverkar hela rader kan man naturligtvis inte sätta dem på kolumnnivå)
- Funktioner: SELECT för tabellfunktioner, EXECUTE för skalära funktioner
- Procedurer: EXECUTE
Rättigheter för uttryck
För att sätta rättigheter att skapa databaser och objekt i databaserna kan man inte specificera objekträttigheter som ovan, utan för detta finns det en annan typ av rättigheter, vilka sätts per uttryck i SQL. Även om resultatet av en CREATE PROCEDURE faktiskt innebär att en INSERT görs i tabellen sysobjects så kan man inte hantera det genom att ge bara INSERT rättigheter på den tabellen, eftersom det dels görs fler INSERT (syscomments t ex) men framförallt för att man då inte skulle kunna skilja mellan rättigheten att skapa en procedur eller att skapa en tabell. De uttryck man kan sätta rättighet för listas nedan, och för varje uttryck gäller att man kan ge rättighet att helt enkelt exekvera det uttrycket:- BACKUP DATABASE
- BACKUP LOG
- CREATE DATABASE
- CREATE DEFAULT
- CREATE FUNCTION
- CREATE PROCEDURE
- CREATE RULE
- CREATE TABLE
- CREATE VIEW
Inbyggda rättigheter
I del 2 av artikelserien beskrev jag de fördefinierade server- och databasroller som finns, samt vilka rättigheter dessa roller har. Dessa rollers inbyggda rättigheter går ej att förändra, och det går ej heller att lägga till fler rättigheter för rollerna.En annan typ av inbyggda rättigheter är de som ägaren av ett databasobjekt har. Som jag beskrev tidigare i artikeln är det den användare som skapar ett objekt som blir dess ägare, om man inte explicit anger en annan användare som ägare. Den användare som är ägare till ett objekt har alltid fullständiga rättigheter för det. Ägaren till en tabell kan t ex läsa och skriva i den, ändra defintionen för tabellen samt hantera vilka rättigheter andra användare har på tabellen.
Hantera rättigheter
Det finns tre nyckelord för att hantera rättigheter. GRANT ger rättigheter för ett objekt eller uttyck, DENY förbjuder rättigheter och REVOKE tar bort de inställningar man gjort. I Enterprise Manager sätter man rättigheter genom att välja Properties för antingen en användare/roll eller ett objekt. Exemplen i koden nedan visar hur man hanterar rättigheter i T-SQL. För att köra exemplen ska man vara i databasen pubs, och det ska finnas en användare eric som är medlem i rollen thirdgraders. Man måste också vara inloggad som en användare som har rätt att utföra dessa uppgifter, t ex en systemadministratör (sa).
-- Ge användaren eric rätt att läsa i tabellen titles
GRANT SELECT ON dbo.titles TO eric
-- Ge rollen thirdgraders rätt att lägga till ny data i tabellen titles
GRANT INSERT ON dbo.titles TO thirdgraders
-- Förbjud rollen thirdgraders att exekvera proceduren byroyalty
DENY EXECUTE ON dbo.byroyalty TO thirdgraders
-- Ta bort alla rättighetsinställningar som satts för eric på titles
REVOKE ALL ON dbo.titles TO eric
För att ändra ägare för ett befintligt objekt kan man använda proceduren sp_changeobjectowner. Observera dock att det samtidigt nollställer alla rättigheter man ställt in för objektet.
-- Ändra ägaren av tabellen titles till eric
EXEC sp_changeobjectowner 'titles', 'eric'
Flera rättigheter
Eftersom man kan sätta rättigheter både för användare och roller, och användare dessutom kan vara med i flera roller, så är det mycket möjligt att en användare kan ha samma rättighet deklarerad för sig flera gånger. Det kan också hända att användaren personligen har en rättighet att utföra en viss aktivitet, medan en roll han är medlem i är förbjuden att utföra samma aktivitet. Resultatet blir då att användaren ej får utföra aktiviteten, eftersom DENY alltid väger tyngre än GRANT. Detta är viktigt att tänka på för att undvika fel när man hanterar rättigheter. Om man t ex har en användare som har tilldelats SELECT-rättighet på tabellen dbo.titles som man ej längre vill ska ha denna kan man ta bort den med ett REVOKE-kommando. Men, om användaren är medlem i en roll som även den har SELECT-rättigheter på dbo.titles så kommer användaren fortfarande kunna läsa från tabellen. Utför man istället ett DENY SELECT-kommando för användaren så kommer han inte att kunna läsa från dbo.titles längre, men han kommer fortfarande att som medlem i rollen ha de övriga rättigheter denna har.I sista delen av artikelserien ska jag visa några exempel på hur man kan använda SQL Servers rättighetssystem för att styra säkerhet och rättigheter.
0 Kommentarer