Dela via

Gör databasen portabel med hjälp av inneslutna databaser

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSQL-databas i Förhandsversion av Microsoft Fabric

Använd oberoende databasanvändare för att autentisera SQL Server- och Azure SQL Database-anslutningar på databasnivå. En innesluten databas är en databas som är isolerad från andra databaser och från instansen av SQL Server eller SQL Database (och master databasen) som är värd för databasen.

SQL Server stöder oberoende databasanvändare för både Windows- och SQL Server-autentisering. När du använder SQL Database kombinerar du oberoende databasanvändare med brandväggsregler på databasnivå.

Den här artikeln granskar fördelarna med att använda den inneslutna databasmodellen jämfört med den traditionella inloggnings-/användarmodellen och Windows- eller brandväggsregler på servernivå. Specifika scenarier, hanterbarhet eller programaffärslogik kan fortfarande kräva användning av den traditionella inloggnings-/användarmodellen och brandväggsregler på servernivå.

Traditionell inloggnings- och användarmodell

I den traditionella anslutningsmodellen ansluter Windows-användare eller medlemmar i Windows-grupper till databasmotorn genom att ange användar- eller gruppautentiseringsuppgifter som autentiseras av Windows. Eller så kan användarna ange både ett namn och lösenord och ansluta med hjälp av SQL Server-autentisering. I båda fallen master måste databasen ha en inloggning som matchar de anslutande autentiseringsuppgifterna.

När databasmotorn har bekräftat autentiseringsuppgifterna för Windows-autentisering eller autentiserar autentiseringsuppgifterna för SQL Server försöker anslutningen vanligtvis ansluta till en användardatabas. Om du vill ansluta till en användardatabas måste inloggningen mappas till (dvs. associerad med) en databasanvändare i användardatabasen. Anslutningssträngen kan också ange anslutning till en specifik databas, vilket är valfritt i SQL Server men som krävs i SQL Database.

Den viktiga principen är att både inloggningen master (i databasen) och användaren (i användardatabasen) måste finnas och vara relaterade till varandra. Anslutningen till användardatabasen har ett beroende av inloggningen i master-databasen. Det här beroendet begränsar möjligheten för databasen att flyttas till en annan SQL Server-instans eller Azure SQL Database-server.

Om en anslutning till master databasen inte är tillgänglig (till exempel om en övergång pågår) ökar den totala anslutningstiden, eller så kan anslutningen leda till timeout. En otillgänglig anslutning kan minska skalbarheten för anslutningen.

Oberoende databasanvändarmodell

I den inneslutna databasanvändarmodellen finns inte inloggningen master i databasen. I stället sker autentiseringsprocessen i användardatabasen. Databasanvändaren i användardatabasen har ingen associerad inloggning i master databasen.

Den inneslutna databasanvändarmodellen stöder både Windows-autentisering och SQL Server-autentisering. Du kan använda den i både SQL Server och SQL Database.

Om du vill ansluta som en innesluten databasanvändare måste anslutningssträngen alltid innehålla en parameter för användardatabasen. Databasmotorn använder den här parametern för att veta vilken databas som ansvarar för att hantera autentiseringsprocessen.

Aktiviteten för den inneslutna databasanvändaren är begränsad till autentiseringsdatabasen. Databasanvändarkontot måste skapas separat i varje databas som användaren behöver. Om du vill ändra databaser måste SQL Database-användare skapa en ny anslutning. Oberoende databasanvändare i SQL Server kan ändra databaser om en identisk användare finns i en annan databas.

I Azure stöder SQL Database och Azure Synapse Analytics identiteter från Microsoft Entra ID (tidigare Azure Active Directory) som oberoende databasanvändare. SQL Database stöder oberoende databasanvändare som använder SQL Server-autentisering, men inte Azure Synapse Analytics. Mer information finns i Ansluta till SQL Database med hjälp av Microsoft Entra-autentisering.

När du använder Microsoft Entra-autentisering kan användare upprätta anslutningar från SQL Server Management Studio med hjälp av Universell autentisering i Microsoft Entra. Administratörer kan konfigurera universell autentisering för att kräva multifaktorautentisering, vilket verifierar identiteten med hjälp av ett telefonsamtal, sms, smartkort med PIN-kod eller mobilappsavisering. För mer information, se Använda Microsoft Entra multifaktorautentisering.

För SQL Database och Azure Synapse Analytics krävs alltid databasnamnet i anslutningssträngen. Därför behöver du inte ändra anslutningssträngen när du byter från den traditionella modellen till den inneslutna databasanvändarmodellen. För SQL Server-anslutningar måste namnet på databasen läggas till i anslutningssträngen, om den inte redan finns.

Important

När du använder den traditionella modellen kan roller på servernivå och behörigheter på servernivå begränsa åtkomsten till alla databaser. När du använder den inneslutna databasmodellen kan databasägare och databasanvändare som har behörigheten ALTER ANY USER bevilja åtkomst till databasen. Den här behörigheten minskar åtkomstkontrollen för högprivilegierade serverinloggningar och utökar åtkomstkontrollen till att omfatta användare av högprivilegierade databaser.

Firewalls

SQL Server

För SQL Server gäller Windows-brandväggsregler för alla anslutningar och har samma effekter på inloggningar (traditionella modellanslutningar) och oberoende databasanvändare. Mer information om Windows-brandväggen finns i Konfigurera Windows-brandväggen för databasmotoråtkomst.

SQL Database-brandväggar

SQL Database tillåter separata brandväggsregler för anslutningar på servernivå (inloggningar) och för anslutningar på databasnivå (oberoende databasanvändare). När SQL Database ansluter till en användardatabas kontrollerar den först databasens brandväggsregler. Om det inte finns någon regel som tillåter åtkomst till databasen kontrollerar SQL Database brandväggsreglerna på servernivå. Kontroll av brandväggsregler på servernivå kräver åtkomst till SQL Database-serverns master databas.

Brandväggsregler på databasnivå, i kombination med oberoende databasanvändare, kan eliminera behovet av att komma åt master serverns databas under anslutningen. Resultatet är förbättrad skalbarhet för anslutningar.

Mer information om SQL Database-brandväggsregler finns i följande artiklar:

Syntaxskillnader

Traditionell modell Oberoende databasanvändarmodell
När du är ansluten till master databasen:

CREATE LOGIN login_name WITH PASSWORD = 'strong_password';

När du sedan är ansluten till en användardatabas:

CREATE USER 'user_name' FOR LOGIN 'login_name';		 När du är ansluten till en användardatabas:

CREATE USER user_name WITH PASSWORD = 'strong_password';
Traditionell modell Oberoende databasanvändarmodell
Så här ändrar du ett lösenord i databasens master kontext:

ALTER LOGIN login_name WITH PASSWORD = 'strong_password';		 Så här ändrar du ett lösenord i kontexten för användardatabasen:

ALTER USER user_name WITH PASSWORD = 'strong_password';

SQL-hanterad instans

Azure SQL Managed Instance fungerar som SQL Server lokalt i kontexten för inneslutna databaser. Se till att ändra databasens kontext från master databasen till användardatabasen när du skapar den inneslutna användaren. Dessutom bör det inte finnas några aktiva anslutningar till användardatabasen när du anger inneslutningsalternativet. Använd följande kod som guide.

Warning

Följande exempelskript använder en kill -instruktion för att stänga alla användarprocesser i databasen. Se till att du förstår konsekvenserna av det här skriptet och att det passar ditt företag innan du kör det. Kontrollera också att inga andra anslutningar är aktiva i din SQL Managed Instance-databas eftersom skriptet stör andra processer som körs på databasen.

USE master;

SELECT * FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test')

DECLARE @kill_string varchar(8000) = '';
SELECT @kill_string = @kill_string + 'KILL ' + str(session_id) + '; '
FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test') and is_user_process = 1;

EXEC(@kill_string);
GO

sp_configure 'contained database authentication', 1;
GO

RECONFIGURE;
GO

SELECT * FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test')

ALTER DATABASE Test
SET containment=partial

USE Test;
GO

CREATE USER Carlo
WITH PASSWORD='Enterpwdhere*'

SELECT containment_desc FROM sys.databases
WHERE name='Test'

Remarks

  • Databasanvändare med begränsningar måste aktiveras för varje instans av SQL Server. Mer information finns i Innesluten databasautentisering (serverkonfigurationsalternativ).
  • Oberoende databasanvändare och inloggningar med icke-överlappande namn kan samexistera i dina program.
  • Anta att en inloggning i master databasen har namnet name1. Om du skapar en innesluten databasanvändare med namnet name1, när ett databasnamn anges i anslutningssträngen, väljs kontexten för databasanvändaren över inloggningskontexten för att ansluta till databasen. Den inneslutna databasanvändaren har alltså företräde framför inloggningar som har samma namn.
  • I SQL Database kan namnet på den inneslutna databasanvändaren inte vara samma som namnet på serveradministratörskontot.
  • SQL Database-serveradministratörskontot kan aldrig vara en oberoende databasanvändare. Serveradministratören har tillräcklig behörighet för att skapa och hantera oberoende databasanvändare. Serveradministratören kan bevilja behörigheter till oberoende databasanvändare i användardatabaser.
  • Eftersom konfigurerade databasanvändare är huvudobjekt på databasnivå måste du skapa konfigurerade databasanvändare i varje databas där du använder dem. Identiteten är begränsad till databasen. Identiteten är oberoende (i alla aspekter) av en användare som har samma namn och samma lösenord i en annan databas på samma server.
  • Använd samma styrka för lösenord som du normalt använder för inloggningar.

Relaterat innehåll