Dela via

Konfigurera och hantera Azure SQL Database-säkerhetför geo-återställning eller redundansväxling

  • Artikel

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 Översikt över affärskontinuitet.

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 Användare av oberoende databas – göra 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 autentiseringsuppgifterna med hjälp av inneslutna användare i flera databaser ta bort 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.

Kommentar

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 Azure SQL-inloggningar och -användare.

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.

De specifika behörigheterna för varje steg beskrivs senare i det här avsnittet.

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 (t.ex. som en del av DR-detaljnivån).

Kommentar

Om du redundansväxlar eller geo-återställer till en server som inte har korrekt konfigurerade inloggningar begränsas åtkomsten till den till serveradministratörskontot.

När du konfigurerar inloggningar på målservern ingår tre steg som beskrivs nedan:

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 den db_owner databasrollen, dbo-användaren eller serveradministratören, kan fastställa alla databasanvändares huvudnamn 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 matchande SID har användaråtkomst till databasen som databasanvändarens huvudnamn.

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'

Kommentar

INFORMATION_SCHEMA- och sys-användare har NULL-SID:er och gäst-SID är 0x00. DBO SID kan börja med 0x01060000000001648000000000048454, om databasskaparen var serveradministratör i stället för 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 målets serveradministratörsinloggning till databashuvudnamn i databasen, till exempel db_owner eller användare.

Kommentar

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.

Nästa steg