Dela via

Konfigurera och hantera säkerheten för Azure SQL Database vid geografisk återställning eller felövertagande.

gäller för:Azure SQL Database

Den här artikeln beskriver autentiseringskraven för att konfigurera och kontrollera aktiva geo-replikerings- och redundansgrupper. Den innehåller också de steg som krävs för att konfigurera användaråtkomst till den sekundära databasen. Slutligen beskrivs också hur du aktiverar åtkomst till den återställda databasen när du har använt geo-återställning. Mer information om återställningsalternativ finns i Affärskontinuitet i Azure SQL Database.

Haveriberedskap med inneslutna användare

Till skillnad från traditionella användare, som måste mappas till inloggningar i databasen, hanteras en innesluten master användare helt av själva databasen. Detta har två fördelar. I haveriberedskapsscenariot kan användarna fortsätta att ansluta till den nya primära databasen eller databasen som återställs med geo-återställning utan någon ytterligare konfiguration, eftersom databasen hanterar användarna. Det finns också potentiella skalbarhets- och prestandafördelar med den här konfigurationen ur ett inloggningsperspektiv. Mer information finns i Oberoende databasanvändare – Gör databasen portabel.

Den största kompromissen är att det är svårare att hantera haveriberedskapsprocessen i stor skala. När du har flera databaser som använder samma inloggning kan det att underhålla autentiseringsuppgifterna med inneslutna användare i flera databaser motverka fördelarna med inneslutna användare. Till exempel kräver principen för lösenordsrotation att ändringar görs konsekvent i flera databaser i stället för att ändra lösenordet för inloggningen en gång i master databasen. Därför rekommenderas inte att använda oberoende användare om du har flera databaser som använder samma användarnamn och lösenord.

Så här konfigurerar du inloggningar och användare

Om du använder inloggningar och användare (i stället för inneslutna användare) måste du vidta extra åtgärder för att säkerställa att samma inloggningar finns i master databasen. I följande avsnitt beskrivs de steg som ingår och ytterligare överväganden.

Anmärkning

Du kan också använda inloggningar som skapats från Microsoft Entra-ID (tidigare Azure Active Directory) för att hantera dina databaser. Mer information finns i Auktorisera databasåtkomst.

Konfigurera användaråtkomst till en sekundär eller återställd databas

För att den sekundära databasen ska kunna användas som en skrivskyddad sekundär databas och för att säkerställa korrekt åtkomst till den nya primära databasen eller databasen som återställs med geo-återställning, master måste målserverns databas ha rätt säkerhetskonfiguration före återställningen.

Förberedelse av användaråtkomst till en sekundär geo-replikering bör utföras som en del av konfigurationen av geo-replikering. Förberedelse av användaråtkomst till geo-återställda databaser bör utföras när som helst när den ursprungliga servern är online (som en del av haveriberedskapstestet).

Anmärkning

Om du överför eller geo-återställer till en server som inte har inloggningar konfigurerade på rätt sätt, kommer åtkomsten att begränsas till serveradministratörskontot.

Att konfigurera inloggningar på målservern innebär tre steg:

1. Fastställa inloggningar med åtkomst till den primära databasen

Det första steget i processen är att avgöra vilka inloggningar som måste dupliceras på målservern. Detta görs med ett par SELECT-instruktioner, en i den logiska master databasen på källservern och en i själva den primära databasen.

Endast serveradministratören eller en medlem av LoginManager-serverrollen kan fastställa inloggningarna på källservern med följande SELECT instruktion.

SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'

Endast en medlem i rollen db_owner, dbo-användaren eller serveradministratören, kan fastställa alla databasanvändares principaler i den primära databasen.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

2. Hitta SID för de inloggningar som identifierades i steg 1

Genom att jämföra utdata från frågorna från föregående avsnitt och matcha SID:erna kan du mappa serverinloggningen till databasanvändaren. Inloggningar som har en databasanvändare med ett matchande SID får användaråtkomst till den databasen som den databasanvändarens huvudkonto.

Följande fråga kan användas för att se alla användarhuvudnamn och deras SID:er i en databas. Endast en medlem i db_owner-databasrollen eller serveradministratören kan köra den här frågan.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

Anmärkning

Användarna INFORMATION_SCHEMA och sys har NULL SID:er och guest SID är 0x00. dbo SID kan börja med 0x01060000000001648000000000048454 om databasskaparen var serveradministratör i stället för en medlem i DbManager.

3. Skapa inloggningarna på målservern

Det sista steget är att gå till målservern eller servrarna och generera inloggningarna med lämpliga säkerhetsidentifierare. Den grundläggande syntaxen är följande.

CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/

Skapa ingen ny inloggning med serveradministratörens SID från källan på målservern. Gör i stället serveradmin-inloggningen till en databasprincip i databasen, som db_owner eller db_user.

Anmärkning

Om du vill ge användaren åtkomst till den sekundära, men inte till den primära, kan du göra det genom att ändra användarens inloggning på den primära servern med hjälp av följande syntax.

ALTER LOGIN [<login name>] DISABLE

INAKTIVERA ändrar inte lösenordet, så du kan alltid aktivera det om det behövs.

Relaterat innehåll