Delen via

De beveiliging van Azure SQL Database configureren en beheren voor geo-herstel of een geo-failover

  • Artikel

Van toepassing op: Azure SQL Database

In dit artikel worden de verificatievereisten beschreven voor het configureren en beheren van actieve geo-replicatie en failovergroepen. Het biedt ook de stappen die nodig zijn om gebruikerstoegang tot de secundaire database in te stellen. Ten slotte wordt ook beschreven hoe u na het gebruik van geo-herstel toegang tot de herstelde database inschakelt. Zie Overzicht van bedrijfscontinuïteit voor meer informatie over herstelopties.

Herstel na noodgeval met ingesloten gebruikers

In tegenstelling tot traditionele gebruikers, die moeten worden toegewezen aan aanmeldingen in de master database, wordt een ingesloten gebruiker volledig beheerd door de database zelf. Dit heeft twee voordelen. In het scenario voor herstel na noodgevallen kunnen de gebruikers verbinding blijven maken met de nieuwe primaire database of de database die is hersteld met geo-herstel zonder extra configuratie, omdat de database de gebruikers beheert. Er zijn ook potentiële schaalbaarheids- en prestatievoordelen van deze configuratie vanuit het oogpunt van aanmelding. Zie Ingesloten databasegebruikers: een draagbare database maken voor meer informatie.

Het belangrijkste nadeel is dat het beheer van het proces voor herstel na noodgevallen op schaal lastiger is. Wanneer u meerdere databases hebt die gebruikmaken van dezelfde aanmelding, kunnen het onderhouden van de referenties die gebruikers in meerdere databases gebruiken, de voordelen van ingesloten gebruikers ontkennen. Het beleid voor wachtwoordrotatie vereist bijvoorbeeld dat wijzigingen consistent in meerdere databases worden aangebracht in plaats van het wachtwoord voor de aanmelding eenmaal in de master database te wijzigen. Als u daarom meerdere databases hebt die dezelfde gebruikersnaam en hetzelfde wachtwoord gebruiken, wordt het gebruik van ingesloten gebruikers niet aanbevolen.

Aanmeldingen en gebruikers configureren

Als u aanmeldingen en gebruikers gebruikt (in plaats van ingesloten gebruikers), moet u extra stappen uitvoeren om ervoor te zorgen dat dezelfde aanmeldingen in de master database aanwezig zijn. In de volgende secties worden de betrokken stappen en aanvullende overwegingen beschreven.

Notitie

Het is ook mogelijk om aanmeldingen te gebruiken die zijn gemaakt op basis van Microsoft Entra ID (voorheen Azure Active Directory) om uw databases te beheren. Zie Azure SQL-aanmeldingen en -gebruikers voor meer informatie.

Gebruikerstoegang tot een secundaire of herstelde database instellen

Om ervoor te zorgen dat de secundaire database kan worden gebruikt als een alleen-lezen secundaire database en ervoor wilt zorgen dat de nieuwe primaire database of de database die is hersteld met geo-herstel, master de database van de doelserver de juiste beveiligingsconfiguratie heeft vóór het herstel.

De specifieke machtigingen voor elke stap worden verderop in dit onderwerp beschreven.

Het voorbereiden van gebruikerstoegang tot een secundaire geo-replicatie moet worden uitgevoerd als onderdeel van het configureren van geo-replicatie. Het voorbereiden van gebruikerstoegang tot de geo-herstelde databases moet op elk gewenst moment worden uitgevoerd wanneer de oorspronkelijke server online is (bijvoorbeeld als onderdeel van de dr-analyse).

Notitie

Als u een failover-overschakeling uitvoert of geo-herstelt naar een server die geen goed geconfigureerde aanmeldingen heeft, wordt de toegang tot deze server beperkt tot het beheerdersaccount van de server.

Het instellen van aanmeldingen op de doelserver omvat drie stappen die hieronder worden beschreven:

1. Aanmeldingen bepalen met toegang tot de primaire database

De eerste stap van het proces is om te bepalen welke aanmeldingen moeten worden gedupliceerd op de doelserver. Dit wordt bereikt met een paar SELECT-instructies, één in de logische master database op de bronserver en één in de primaire database zelf.

Alleen de serverbeheerder of een lid van de LoginManager-serverrol kan de aanmeldingen op de bronserver bepalen met de volgende SELECT-instructie.

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

Alleen een lid van de db_owner-databaserol, de dbo-gebruiker of serverbeheerder, kan alle databasegebruikers-principals in de primaire database bepalen.

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

2. Zoek de SID voor de aanmeldingen die zijn geïdentificeerd in stap 1

Door de uitvoer van de query's uit de vorige sectie te vergelijken en de SID's te koppelen, kunt u de aanmelding van de server toewijzen aan de databasegebruiker. Aanmeldingen met een databasegebruiker met een overeenkomende SID hebben gebruikerstoegang tot die database als principal van die databasegebruiker.

De volgende query kan worden gebruikt om alle gebruikersprinciplen en hun SID's in een database weer te geven. Alleen een lid van de db_owner databaserol of serverbeheerder kan deze query uitvoeren.

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

Notitie

De INFORMATION_SCHEMA - en sysgebruikers hebben NULL-SID's en de gast-SID is 0x00. De dbo-SID kan beginnen met 0x01060000000001648000000000048454, als de maker van de database de serverbeheerder was in plaats van een lid van DbManager.

3. Maak de aanmeldingen op de doelserver

De laatste stap is om naar de doelserver of servers te gaan en de aanmeldingen te genereren met de juiste SID's. De basissyntaxis is als volgt.

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

Maak op de doelserver geen nieuwe aanmelding met de serverbeheerder-SID van de bron. In plaats daarvan moet de serverbeheerder van het doel zich aanmelden bij een database-principal in de database, zoals db_owner of gebruiker.

Notitie

Als u gebruikers toegang wilt verlenen tot de secundaire, maar niet aan de primaire, kunt u dit doen door de aanmelding van de gebruiker op de primaire server te wijzigen met behulp van de volgende syntaxis.

ALTER LOGIN [<login name>] DISABLE

Met DISABLE wordt het wachtwoord niet gewijzigd, dus u kunt het altijd inschakelen als dat nodig is.

Volgende stappen