Sdílet prostřednictvím

Konfigurace a správa zabezpečení služby Azure SQL Database pro geografické obnovení nebo převzetí služeb při selhání

  • Článek

Platí pro: Azure SQL Database

Tento článek popisuje požadavky na ověřování pro konfiguraci a řízení aktivní geografické replikace a skupin převzetí služeb při selhání. Poskytuje také kroky potřebné k nastavení přístupu uživatele k sekundární databázi. Nakonec popisuje, jak povolit přístup k obnovené databázi po použití geografického obnovení. Další informace o možnostech obnovení najdete v tématu Přehled kontinuity podnikových procesů.

Zotavení po havárii s uživateli s omezením

Na rozdíl od tradičních uživatelů, kteří musí být namapováni na přihlášení v master databázi, je obsažený uživatel spravován zcela samotnou databází. To má dvě výhody. Ve scénáři zotavení po havárii se uživatelé můžou i nadále připojovat k nové primární databázi nebo k obnovené databázi pomocí geografického obnovení bez jakékoli další konfigurace, protože databáze spravuje uživatele. Z této konfigurace z hlediska přihlášení existují také potenciální výhody škálovatelnosti a výkonu. Další informace najdete v tématu Uživatelé databáze s omezením – zajištění přenositelnosti databáze.

Hlavním kompromisem je, že správa procesu zotavení po havárii ve velkém měřítku je náročnější. Pokud máte více databází, které používají stejné přihlášení, může údržba přihlašovacích údajů pomocí uživatelů obsažených ve více databázích negovat výhody obsažených uživatelů. Zásady obměny hesel například vyžadují, aby se změny provedly konzistentně ve více databázích, a ne měnily heslo pro přihlášení jednou v master databázi. Z tohoto důvodu se nedoporučuje používat více databází, které používají stejné uživatelské jméno a heslo.

Konfigurace přihlášení a uživatelů

Pokud používáte přihlášení a uživatele (nikoli uživatele s omezením), musíte provést další kroky, abyste zajistili, že v master databázi existují stejná přihlášení. Následující části popisují kroky, které se týkají, a další aspekty.

Poznámka:

Ke správě databází je také možné použít přihlášení vytvořená z Microsoft Entra ID (dříve Azure Active Directory). Další informace najdete v tématu Přihlášení a uživatelé Azure SQL.

Nastavení přístupu uživatele k sekundární nebo obnovené databázi

Aby sekundární databáze mohla být použitelná jako sekundární databáze určená jen pro čtení, a aby se zajistil správný přístup k nové primární databázi nebo databázi obnovené pomocí geografického obnovení, master musí mít databáze cílového serveru před obnovením správnou konfiguraci zabezpečení.

Konkrétní oprávnění pro každý krok jsou popsána dále v tomto tématu.

Příprava přístupu uživatelů k sekundární geografické replikaci by se měla provádět jako součást konfigurace geografické replikace. Příprava přístupu uživatele k geograficky obnoveným databázím by se měla provádět kdykoli, když je původní server online (např. jako součást podrobného přehledu zotavení po havárii).

Poznámka:

Pokud převezmete služby při selhání nebo geografické obnovení serveru, který nemá správně nakonfigurovaná přihlášení, přístup k němu bude omezen na účet správce serveru.

Nastavení přihlášení na cílovém serveru zahrnuje tři kroky uvedené níže:

1. Určení přihlášení s přístupem k primární databázi

Prvním krokem procesu je určení, která přihlášení musí být duplikována na cílovém serveru. Toho se dosahuje pomocí dvojice příkazů SELECT, jednoho v logické master databázi na zdrojovém serveru a jednoho v samotné primární databázi.

Pomocí následujícího příkazu SELECT může určit přihlášení na zdrojovém serveru pouze správce serveru nebo člen role serveru LoginManager .

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

Všechny objekty zabezpečení databáze v primární databázi můžou určit pouze člen db_owner role databáze, uživatel dbo nebo správce serveru.

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

2. Vyhledejte identifikátor SID pro přihlášení identifikovaná v kroku 1.

Porovnáním výstupu dotazů z předchozí části a porovnáním identifikátorů SID můžete namapovat přihlášení serveru k uživateli databáze. Přihlášení, která mají uživatele databáze s odpovídajícím identifikátorem SID, mají k této databázi přístup jako objekt zabezpečení uživatele databáze.

Následující dotaz se dá použít k zobrazení všech objektů zabezpečení uživatele a jejich identifikátorů SID v databázi. Tento dotaz může spustit jenom člen db_owner role databáze nebo správce serveru.

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

Poznámka:

Uživatelé INFORMATION_SCHEMA a sys mají identifikátory SID s hodnotou NULL a identifikátor SID hosta je 0x00. Identifikátor dbo SID může začínat 0x01060000000001648000000000048454, pokud tvůrce databáze byl správcem serveru místo člena DbManager.

3. Vytvoření přihlášení na cílovém serveru

Posledním krokem je přejít na cílový server nebo servery a vygenerovat přihlášení s příslušnými identifikátory SID. Základní syntaxe je následující.

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

Na cílovém serveru nevytvořte nové přihlášení pomocí identifikátoru SID správce serveru ze zdroje. Místo toho se správce cílového serveru přihlásí k instančnímu objektu databáze v databázi, jako je db_owner nebo uživatel.

Poznámka:

Pokud chcete udělit přístup uživatele k sekundárnímu serveru, ale ne k primárnímu, můžete to udělat tak, že změníte přihlášení uživatele na primárním serveru pomocí následující syntaxe.

ALTER LOGIN [<login name>] DISABLE

DISABLE heslo nezmění, takže ho můžete kdykoliv povolit v případě potřeby.

Další kroky