Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics
Analysplattformssystem (PDW)
SQL-databas i Förhandsversion av Microsoft Fabric
Den här artikeln går igenom några grundläggande säkerhetsbegrepp och beskriver sedan en typisk implementering av behörigheter. Behörigheter i databasmotorn hanteras på servernivå via inloggningar och serverroller och på databasnivå via databasanvändare och databasroller.
SQL Database och SQL Database i Microsoft Fabric Preview innehåller samma alternativ i varje databas, men behörigheterna på servernivå är inte tillgängliga.
I SQL Database, se Självstudie: Skydda en databas i Azure SQL Database. Microsoft Entra ID-autentisering rekommenderas. Mer information finns i Självstudie: Skapa Microsoft Entra-användare med hjälp av Microsoft Entra-program.
I SQL Database i Microsoft Fabric Preview är Microsoft Entra-ID den enda autentiseringsmetod som stöds för databasanvändare. Roller och behörigheter på servernivå är inte tillgängliga. Mer information finns i Auktorisering i SQL-databasen i Microsoft Fabric.
Note
Microsoft Entra-ID kallades tidigare Azure Active Directory (Azure AD).
Security principals
Ett säkerhetsobjekt är den identitet som SQL Server använder, som kan tilldelas behörighet att vidta åtgärder. Säkerhetsobjekt är vanligtvis personer eller grupper av personer, men kan vara andra entiteter som låtsas vara människor. Säkerhetsobjekt kan skapas och hanteras med hjälp av de Transact-SQL exempel som visas i den här artikeln eller med hjälp av SQL Server Management Studio.
Logins
Inloggningar är enskilda användarkonton för att logga in på SQL Server Database Engine. SQL Server och SQL Database stöder inloggningar baserat på Windows-autentisering och inloggningar baserat på SQL Server-autentisering. Information om de två typerna av inloggningar finns i Välj ett autentiseringsläge.
Serverroller har åtgärdats
I SQL Server är fasta serverroller en uppsättning förkonfigurerade roller som ger en bekväm grupp med behörigheter på servernivå. Inloggningar kan läggas till i rollerna med hjälp av -instruktionen ALTER SERVER ROLE ... ADD MEMBER . Mer information finns i ÄNDRA SERVERROLL. SQL Database stöder inte fasta serverroller, men har två roller i master databasen (dbmanager och loginmanager) som fungerar som serverroller.
Användardefinierade serverroller
I SQL Server kan du skapa egna serverroller och tilldela behörigheter på servernivå till dem. Inloggningar kan läggas till i serverrollerna med hjälp av -instruktionen ALTER SERVER ROLE ... ADD MEMBER . Mer information finns i ÄNDRA SERVERROLL. SQL Database stöder inte användardefinierade serverroller.
Database users
Om du vill bevilja åtkomst för en inloggning till en databas skapar du en databasanvändare i databasen och mappar databasanvändaren till en inloggning. Databasanvändarnamnet är vanligtvis samma som inloggningsnamnet enligt konventionen, men det behöver inte vara detsamma. Varje databasanvändare mappar till en enda inloggning. En inloggning kan endast mappas till en användare i en databas, men den kan mappas som en databasanvändare i flera olika databaser.
Databasanvändare kan också skapas som inte har någon motsvarande inloggning. Dessa användare kallas inneslutna databasanvändare. Microsoft uppmuntrar användningen av inneslutna databasanvändare eftersom det gör det enklare att flytta databasen till en annan server. Precis som vid inloggning kan en oberoende databasanvändare använda antingen Windows-autentisering eller SQL Server-autentisering. Mer information finns i Gör databasen portabel med hjälp av inneslutna databaser.
Det finns 12 typer av användare med små skillnader i hur de autentiserar och vem de representerar. En lista över användare finns i SKAPA ANVÄNDARE.
Fasta databasroller
Fasta databasroller är en uppsättning förkonfigurerade roller som ger en bekväm grupp med behörigheter på databasnivå. Databasanvändare och användardefinierade databasroller kan läggas till i de fasta databasrollerna med hjälp av -instruktionen ALTER ROLE ... ADD MEMBER . Mer information finns i ÄNDRA ROLL.
Användardefinierade databasroller
Användare med behörigheten CREATE ROLE kan skapa nya användardefinierade databasroller för att representera grupper av användare med gemensamma behörigheter. Vanligtvis beviljas eller nekas behörigheter till hela rollen, vilket förenklar behörighetshantering och övervakning. Databasanvändare kan läggas till i databasrollerna med hjälp av -instruktionen ALTER ROLE ... ADD MEMBER . Mer information finns i ÄNDRA ROLL.
Other principals
Andra säkerhetsobjekt som inte beskrivs här är programroller och inloggningar och användare baserat på certifikat eller asymmetriska nycklar.
En bild som visar relationerna mellan Windows-användare, Windows-grupper, inloggningar och databasanvändare finns i Skapa en databasanvändare.
Typical scenario
Följande exempel representerar en vanlig och rekommenderad metod för att konfigurera behörigheter.
I Windows Active Directory eller Microsoft Entra ID
- Skapa en användare för varje person.
- Skapa Windows-grupper som representerar arbetsenheterna och arbetsfunktionerna.
- Lägg till Windows-användare i Windows-grupperna.
Om användaren ansluter till många databaser
Skapa en inloggning för Windows-grupperna. (Om du använder SQL Server-autentisering hoppar du över Active Directory-stegen och skapar SQL Server-autentiseringsinloggningar här.)
I användardatabasen skapar du en databasanvändare för inloggningen som representerar Windows-grupperna.
I användardatabasen skapar du en eller flera användardefinierade databasroller som var och en representerar en liknande funktion. Du kan till exempel ha en finansanalytikerroll och en försäljningsanalytikerroll.
Lägg till databasanvändarna i en eller flera användardefinierade databasroller.
Bevilja behörigheter till de användardefinierade databasrollerna.
Om användaren bara ansluter till en databas
I användardatabasen skapar du en innesluten databasanvändare för Windows-gruppen. (Om du använder SQL Server-autentisering hoppar du över Active Directory-stegen och skapar sql server-autentisering för den oberoende databasanvändaren här.)
I användardatabasen skapar du en eller flera användardefinierade databasroller som var och en representerar en liknande funktion. Du kan till exempel ha en finansanalytikerroll och en försäljningsanalytikerroll.
Lägg till databasanvändarna i en eller flera användardefinierade databasroller.
Bevilja behörigheter till de användardefinierade databasrollerna.
Det typiska resultatet just nu är att en Windows-användare är medlem i en Windows-grupp. Windows-gruppen har en inloggning i SQL Server eller SQL Database. Inloggningen mappas till en användaridentitet i användardatabasen. Användaren är medlem i en databasroll. Nu måste du lägga till behörigheter i rollen.
Assign permissions
De flesta behörighetsuttryck har följande format:
<authorization> <permission> ON <securable>::<name> TO <principal>;
<authorization>måste varaGRANT,REVOKEellerDENY.Etablerar
<permission>den åtgärd som du tillåter eller förbjuder. Det exakta antalet behörigheter skiljer sig mellan SQL Server och Azure SQL Database. Information om behörigheter finns i Behörigheter (databasmotor) och se diagrammet senare i den här artikeln.ON <securable>::<name>är typen av ett skyddbart objekt (server, serverobjekt, databas eller databasobjekt) och dess namn. Vissa behörigheter kräver<securable>::<name>inte eftersom det är tvetydigt eller olämpligt i kontexten. BehörighetenCREATE TABLEkräver inte klausulen<securable>::<name>(GRANT CREATE TABLE TO Mary;tillåter Mary att skapa tabeller).<principal>är säkerhetsobjektet (inloggning, användare eller roll) som tar emot eller förlorar behörigheten. Bevilja behörigheter till roller när det är möjligt.
Följande exempelsats ger behörigheten UPDATE i tabellen Parts eller vyn i Production schemat till rollen med namnet PartsTeam:
GRANT UPDATE ON OBJECT::Production.Parts TO PartsTeam;
Följande exempeluttryck ger behörigheten UPDATE på schemat Production och därmed på alla tabeller eller vyer som ingår i detta schema, till rollen med namnet ProductionTeam, vilket är en effektivare och mer skalerbar metod för att tilldela behörigheter än på enskild objektnivå.
GRANT UPDATE ON SCHEMA::Production TO ProductionTeam;
Behörigheter beviljas säkerhetsprincipaler (inloggningar, användare och roller) med hjälp av GRANT-instruktionen. Behörigheter nekas uttryckligen genom att använda kommandot DENY. En tidigare beviljad eller nekad behörighet tas bort med hjälp av REVOKE-satsen. Behörigheterna är kumulativa, där användaren får alla behörigheter som beviljats användaren, inloggningen och eventuella gruppmedlemskap; dock åsidosätter varje nekning av behörighet alla beviljanden.
Caution
Ett vanligt misstag är att försöka ta bort en GRANT med hjälp DENY av i stället för REVOKE. Detta kan orsaka problem när en användare får behörigheter från flera källor, vilket kan vara ett vanligt scenario. I följande exempel visas principen.
Gruppen Försäljning får SELECT behörigheter på OrderStatus-tabellen via instruktionen GRANT SELECT ON OBJECT::OrderStatus TO Sales;. Användaren Jae är medlem i Sales rollen. Jae har också beviljats SELECT behörighet till OrderStatus-tabellen under sitt eget användarnamn genom instruktionen GRANT SELECT ON OBJECT::OrderStatus TO Jae;. Anta att administratören vill ta bort GRANT från rollen Sales.
Om administratören kör
REVOKE SELECT ON OBJECT::OrderStatus TO Sales;korrekt behåller Jae åtkomsten till tabellenSELECTgenom deras enskildaOrderStatusuttalande.Om administratören felaktigt kör
DENY SELECT ON OBJECT::OrderStatus TO Sales;, nekas Jae, som medlem i rollenSales, åtkomstenSELECTeftersomDENYtillSalesåsidosätter deras individuellaGRANT.
Note
Behörigheter kan konfigureras med Hjälp av Management Studio. Leta reda på det skyddbara objektet i Object Explorer, högerklicka på det skyddbara objektet och välj sedan Egenskaper. Välj sidan Behörigheter . Mer information om hur du använder behörighetssidan finns på sidan Behörigheter eller Skyddsbara objekt.
Permission hierarchy
Behörigheter har en föräldra/barn-hierarki. Om du beviljar SELECT behörighet för en databas, inkluderar den även behörighet för alla (underordnade) scheman i databasen. Om du beviljar SELECT behörighet för ett schema innehåller SELECT det behörighet för alla (underordnade) tabeller och vyer i schemat. Behörigheterna är transitiva: om du beviljar SELECT behörighet för en databas inkluderar den behörighet för alla underordnade scheman och alla underordnade tabeller och vyer.
Behörigheter har också övergripande behörigheter. Behörigheten CONTROL för ett objekt ger dig normalt alla andra behörigheter för objektet.
Eftersom både den hierarki för förälder/barn och täckande hierarki kan påverka samma behörighet, kan behörighetssystemet bli komplicerat. Låt oss till exempel ta en tabell (Region), i ett schema (Customers), i en databas (SalesDB).
CONTROLbehörighet i tabellenRegioninnehåller alla andra behörigheter i tabellenRegion, inklusiveALTER,SELECT,INSERT,UPDATE, ochDELETEnågra andra behörigheter.SELECTi schematCustomerssom ägerRegiontabellen innehåller behörighetenSELECTförRegiontabellen.
Så SELECT behörighet i tabellen Region kan uppnås genom någon av dessa sex instruktioner:
GRANT SELECT ON OBJECT::Region TO Jae;
GRANT CONTROL ON OBJECT::Region TO Jae;
GRANT SELECT ON SCHEMA::Customers TO Jae;
GRANT CONTROL ON SCHEMA::Customers TO Jae;
GRANT SELECT ON DATABASE::SalesDB TO Jae;
GRANT CONTROL ON DATABASE::SalesDB TO Jae;
Bevilja minst behörighet
Den första behörigheten som anges tidigare (GRANT SELECT ON OBJECT::Region TO Jae;) är den mest detaljerade. Det uttalandet är den minsta möjliga behörigheten som beviljar SELECT. Det finns inga behörigheter för underordnade objekt. Det är en bra princip att alltid bevilja minsta möjliga behörighet, men du bör överväga att bevilja på högre nivåer för att förenkla beviljandesystemet.
Så om Jae behöver behörighet till hela schemat, beviljar du SELECT en gång på schemanivå i stället för att bevilja SELECT många gånger på tabell- eller vy-nivå. Databasens utformning kan avsevärt påverka hur framgångsrik den här strategin kan vara. Den här strategin fungerar bäst när databasen är utformad så att objekt som behöver identiska behörigheter inkluderas i ett enda schema.
Tip
När du utformar en databas och dess objekt planerar du från början hur program och användare får åtkomst till dessa objekt. Använd den här informationen för att styra åtkomsten till tabeller, vyer, funktioner och lagrade procedurer med hjälp av scheman. Med scheman kan du gruppera åtkomsttyper enklare.
Diagram över behörigheter
Följande bild visar behörigheter och deras relationer till varandra. Vissa behörigheter på högre nivå (till exempel CONTROL SERVER) visas många gånger. I den här artikeln är affischen alldeles för liten för att läsa. Du kan ladda ned den fullstora postern över behörigheter för databasmotorn i PDF-format.
En bild som visar relationerna mellan databasmotorns huvudnamn och server- och databasobjekt finns i Behörighetshierarki (databasmotor).
Behörigheter jämfört med fasta server- och fasta databasroller
Behörigheterna för fasta serverroller och fasta databasroller liknar, men inte exakt samma som, detaljerade behörigheter. Medlemmar i den fasta sysadmin-serverrollen har till exempel alla behörigheter för instansen av SQL Server, liksom inloggningar med behörigheten CONTROL SERVER .
Men att bevilja behörigheten CONTROL SERVER gör inte en inloggning till medlem i den fasta sysadmin-serverrollen , och att lägga till en inloggning till den fasta serverrollen sysadmin ger inte uttryckligen inloggningsbehörigheten CONTROL SERVER . Ibland kontrollerar en lagrad procedur behörigheter genom att kontrollera den fasta rollen och inte kontrollera den detaljerade behörigheten.
Om du till exempel vill koppla bort en databas krävs medlemskap i db_owner fast databasrollsfunktion. Motsvarande CONTROL DATABASE behörighet räcker inte. Dessa två system fungerar parallellt men interagerar sällan med varandra. Microsoft rekommenderar att du använder det nyare, detaljerade behörighetssystemet i stället för fasta roller när det är möjligt.
Monitor permissions
Följande visningar returnerar säkerhetsinformation. Alla säkerhetsrelaterade vyer finns i Säkerhetskatalogvyer (Transact-SQL).
| View | Description |
|---|---|
sys.server_principals
1 |
Inloggningar och användardefinierade serverroller på en server |
sys.database_principals |
Användare och användardefinierade roller i en databas |
sys.server_permissions
1 |
Behörigheter som beviljas för inloggningar och användardefinierade fasta serverroller |
sys.database_permissions |
Behörigheter som beviljats användare och användardefinierade fasta databasroller |
sys.database_role_members |
Databasrollmedlemskap |
sys.server_role_members
1 |
Medlemskap i serverroll |
1 Den här vyn är inte tillgänglig i SQL Database.
Examples
Följande satser returnerar användbar information om behörigheter.
A. Lista över databasbehörigheter för varje användare
Om du vill returnera explicita behörigheter som beviljats eller nekats i en databas (SQL Server och SQL Database) kör du följande Transact-SQL-instruktion i databasen.
SELECT perms.state_desc AS State,
permission_name AS [Permission],
obj.name AS [on Object],
dp.name AS [to User Name]
FROM sys.database_permissions AS perms
INNER JOIN sys.database_principals AS dp
ON perms.grantee_principal_id = dp.principal_id
INNER JOIN sys.objects AS obj
ON perms.major_id = obj.object_id;
B. Visa en lista över medlemmar i serverrollen
Kör följande instruktion för att returnera medlemmarna i serverrollerna (endast SQL Server).
SELECT roles.principal_id AS RolePrincipalID,
roles.name AS RolePrincipalName,
server_role_members.member_principal_id AS MemberPrincipalID,
members.name AS MemberPrincipalName
FROM sys.server_role_members AS server_role_members
INNER JOIN sys.server_principals AS roles
ON server_role_members.role_principal_id = roles.principal_id
LEFT OUTER JOIN sys.server_principals AS members
ON server_role_members.member_principal_id = members.principal_id;
C. Visa en lista över alla databashuvudnamn som är medlemmar i en databasnivåroll
Om du vill returnera medlemmarna i databasrollerna (SQL Server och SQL Database) kör du följande instruktion i databasen.
SELECT dRole.name AS [Database Role Name],
dp.name AS [Members]
FROM sys.database_role_members AS dRo
INNER JOIN sys.database_principals AS dp
ON dRo.member_principal_id = dp.principal_id
INNER JOIN sys.database_principals AS dRole
ON dRo.role_principal_id = dRole.principal_id;
Related content
- Säkerhet för SQL Server Database Engine och Azure SQL Database
- Security Functions (Transact-SQL)
- Säkerhetsrelaterade vyer och funktioner för dynamisk hantering (Transact-SQL)
- säkerhetskatalogvyer (Transact-SQL)
- sys.fn_builtin_permissions (Transact-SQL)
- Fastställa gällande behörigheter för databasmotorn
- Självstudie: Komma igång med databasmotorn
- Lektion 1: Skapa och fråga databasobjekt
- Självstudie: SQL Server Management Studio
- Handledning: Skriva Transact-SQL-satser