Metodtips för säkerhet med inneslutna databaser

Artikel
2025-03-05

gäller för:SQL Server Azure SQL Managed Instance

Inneslutna databaser har vissa unika hot som bör förstås och minimeras av SQL Server Database Engine-administratörer. De flesta hoten är relaterade till autentiseringsprocessen ANVÄNDARE MED LÖSENORD, vilket flyttar autentiseringsgränsen från databasmotornivån till databasnivå.

Användare i en innesluten databas som har behörigheten ALTER ANY USER, till exempel medlemmar i db_owner och db_accessadmin fasta databasroller, kan bevilja åtkomst till databasen utan kunskap eller behörighet eller SQL Server-administratören. Att ge användare åtkomst till en innesluten databas ökar den potentiella attackytan mot hela SQL Server-instansen. Administratörer bör förstå den här delegeringen av åtkomstkontroll och vara mycket försiktiga med att ge användare i den inneslutna databasen ÄNDRA ALLA ANVÄNDARE behörighet. Alla databasägare har behörigheten ALTER ANY USER. SQL Server-administratörer bör regelbundet granska användarna i en innesluten databas.

Komma åt andra databaser med gästkontot

Databasägare och databasanvändare med ALTER ANY USER behörighet kan skapa oberoende databasanvändare. När du har anslutit till en kontrollerad databas på en instans av SQL Server kan en användare av den kontrollerade databasen komma åt andra databaser i databasmotorn om de andra databaserna har aktiverat gäst kontot.

Skapa en duplicerad användare i en annan databas

Vissa program kan kräva att en användare har åtkomst till mer än en databas. Detta kan göras genom att skapa identiska oberoende databasanvändare i varje databas. Använd SID-alternativet när du skapar den andra användaren med lösenord. I följande exempel skapas två identiska användare i två databaser.

USE DB1;  
GO  
CREATE USER Carlo WITH PASSWORD = '<strong password>';   
-- Return the SID of the user  
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';  
  
-- Change to the second database  
USE DB2;  
GO  
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;  
GO

Om du vill köra en fråga mellan databaser måste du ange alternativet TRUSTWORTHY i den anropande databasen. Om användaren (Carlo) som definierats ovan till exempel finns i DB1, för att köra SELECT * FROM db2.dbo.Table1; måste inställningen TRUSTWORTHY vara på för databas DB1. Kör följande kod för att ange inställningen TRUSTWORTHY på.

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Om en innesluten databasanvändare med lösenord skapas med samma namn som en SQL Server-inloggning, och om SQL Server-inloggningen ansluter och anger den inneslutna databasen som den ursprungliga katalogen, kommer SQL Server-inloggningen inte att kunna ansluta. Anslutningen kommer att utvärderas som den inneslutna databasanvändaren med lösenordsprincip i den inneslutna databasen istället för som en användare baserad på SQL Server-inloggningen. Detta kan orsaka en avsiktlig eller oavsiktlig överbelastningsbelastning för SQL Server-inloggningen.

Som bästa praxis bör medlemmar i sysadmin fast serverroll överväga att alltid ansluta utan att använda det ursprungliga katalogalternativet. Detta ansluter inloggningen till huvuddatabasen och undviker försök av en databasägare att missbruka inloggningsförsöket. Sedan kan administratören ändra till den inneslutna databasen med hjälp av instruktionen USE<database>. Du kan också ange standarddatabasen för inloggningen till den inneslutna databasen, som slutför inloggningen till masteroch sedan överför inloggningen till den inneslutna databasen.
Vi rekommenderar att du inte skapar oberoende databasanvändare med lösenord som har samma namn som SQL Server-inloggningar.
Om dubblettinloggningen finns ansluter du till huvuddatabasen utan att ange en första katalog och kör sedan kommandot USE för att ändra till den inneslutna databasen.
När inneslutna databaser finns bör användare av databaser som inte innehåller databaser ansluta till databasmotorn utan att använda en första katalog eller genom att ange databasnamnet för en icke-innesluten databas som den första katalogen. Detta undviker att ansluta till den inneslutna databasen som är under mindre direkt kontroll av databasmotoradministratörerna.

Öka åtkomsten genom att ändra inneslutningsstatus för en databas

Inloggningar som har behörigheten ALTER ANY DATABASE, till exempel medlemmar i dbcreator fast serverroll och användare i en icke-innesluten databas som har behörigheten CONTROL DATABASE, till exempel medlemmar i den db_owner fasta databasrollen, kan ändra inneslutningsinställningen för en databas. Om inneslutningsinställningen för en databas ändras från NONE till antingen PARTIAL eller FULL, kan användaråtkomst beviljas genom att skapa inneslutna databasanvändare med lösenord. Detta kan ge åtkomst utan sql Server-administratörernas vetskap eller medgivande. Om du vill förhindra att databaser ingår anger du alternativet Databasmotorinnesluten databasautentisering till 0. Om du vill förhindra anslutningar av inneslutna databasanvändare med lösenord för valda inneslutna databaser använder du inloggningsutlösare för att avbryta inloggningsförsök av inneslutna databasanvändare med lösenord.

Koppla en innesluten databas

Genom att koppla en innesluten databas kan en administratör ge oönskade användare åtkomst till instansen av databasmotorn. En administratör som är bekymrad över den här risken kan aktivera databasen i RESTRICTED_USER läge, vilket förhindrar autentisering för oberoende databasanvändare med lösenord. Endast huvudkonton som har auktoriserats via inloggningar kommer att kunna komma åt databasmotorn.

Användare skapas med hjälp av de lösenordskrav som gäller när de skapas och lösenord kontrolleras inte igen när en databas är ansluten. Genom att koppla en innesluten databas som tillät svaga lösenord till ett system med en striktare lösenordsprincip kan en administratör tillåta lösenord som inte uppfyller den aktuella lösenordsprincipen på den anslutande databasmotorn. Administratörer kan undvika att behålla de svaga lösenorden genom att kräva att alla lösenord återställs för den anslutna databasen.

Lösenordsprinciper

Lösenord i en databas kan krävas för att vara starka lösenord, men kan inte skyddas av robusta lösenordsprinciper. Använd Windows-autentisering när det är möjligt för att dra nytta av de mer omfattande lösenordsprinciper som är tillgängliga från Windows.

Kerberos-autentisering

Oberoende databasanvändare med lösenord kan inte använda Kerberos-autentisering. När det är möjligt kan du använda Windows-autentisering för att dra nytta av Windows-funktioner som Kerberos.

Offline ordboksattack

Lösenordshasherna för databasanvändare som tillhör den inneslutna databasen och har lösenord lagras i den inneslutna databasen. Alla som har åtkomst till databasfilerna kan utföra en ordlisteattack mot de oberoende databasanvändarna med lösenord i ett oreviderat system. För att minska det här hotet begränsar du åtkomsten till databasfilerna eller tillåter endast anslutningar till inneslutna databaser med hjälp av Windows-autentisering.

Undfly en innesluten databas

Om en databas är delvis isolerad bör administratörer av SQL Server regelbundet genomföra en granskning av funktionerna för användare och moduler i inneslutna databaser.

Överbelastningsattack genom AUTO_CLOSE

Konfigurera inte inneslutna databaser för automatisk stängning. Om den stängs förbrukar öppnandet av databasen för att autentisera en användare ytterligare resurser och kan bidra till en överbelastningsattack.

Se även

inneslutna databaser
Migrera till en delvis innesluten databas

Dela via