Konfigurace a Správa zabezpečení Azure SQL Database pro geografické obnovení nebo převzetí služeb při selháníConfigure and manage Azure SQL Database security for geo-restore or failover

Tento článek popisuje požadavky na ověřování ke konfiguraci a řízení aktivní geografické replikace a skupin s automatickým převzetím služeb při selhání.This article describes the authentication requirements to configure and control active geo-replication and auto-failover groups. Poskytuje taky kroky potřebné k nastavení přístupu uživatelů k sekundární databázi.It also provides the steps required to set up user access to the secondary database. Nakonec také popisuje, jak povolit přístup k obnovené databázi po použití geografického obnovení.Finally, it also describes how to enable access to the recovered database after using geo-restore. Další informace o možnostech obnovení najdete v tématu Přehled provozní kontinuity.For more information on recovery options, see Business Continuity Overview.

Zotavení po havárii s uživateli s omezenímDisaster recovery with contained users

Na rozdíl od tradičních uživatelů, které musí být namapovány na přihlašovací údaje v hlavní databázi, je obsažený uživatel zcela spravován samotným databází.Unlike traditional users, which must be mapped to logins in the master database, a contained user is managed completely by the database itself. To má dvě výhody.This has two benefits. Ve scénáři zotavení po havárii se uživatelé mohou nadále připojovat k nové primární databázi nebo databáze obnovena pomocí geografického obnovení bez jakékoli další konfigurace, protože databáze spravuje uživatele.In the disaster recovery scenario, the users can continue to connect to the new primary database or the database recovered using geo-restore without any additional configuration, because the database manages the users. Z perspektivy přihlášení se z této konfigurace taky mohou využít výhody a možnosti škálovatelnosti a výkonu.There are also potential scalability and performance benefits from this configuration from a login perspective. Další informace najdete v tématu Uživatelé databáze s omezením – zajištění přenositelnosti databáze.For more information, see Contained Database Users - Making Your Database Portable.

Hlavním obchodem je, že Správa procesu zotavení po havárii je ve velkém rozsahu náročná.The main trade-off is that managing the disaster recovery process at scale is more challenging. Pokud máte více databází, které používají stejné přihlašovací údaje, zajistěte, aby pověření s použitím obsažených uživatelů v několika databázích nemusely mít na starosti výhody obsažených uživatelů.When you have multiple databases that use the same login, maintaining the credentials using contained users in multiple databases may negate the benefits of contained users. Zásady rotace hesla například vyžadují, aby se změny v několika databázích udělaly konzistentně, a neměňte heslo pro přihlášení jednou v hlavní databázi.For example, the password rotation policy requires that changes be made consistently in multiple databases rather than changing the password for the login once in the master database. Z tohoto důvodu platí, že pokud máte více databází, které používají stejné uživatelské jméno a heslo, nedoporučuje se použít uživatele s omezením.For this reason, if you have multiple databases that use the same user name and password, using contained users is not recommended.

Jak nakonfigurovat přihlášení a uživateleHow to configure logins and users

Pokud používáte přihlašovací jména a uživatele (místo obsažených uživatelů), musíte provést další kroky, abyste zajistili, že v hlavní databázi existují stejná přihlášení.If you are using logins and users (rather than contained users), you must take extra steps to ensure that the same logins exist in the master database. V následujících částech najdete přehled kroků a další okolnosti.The following sections outline the steps involved and additional considerations.

Poznámka

Ke správě databází je taky možné použít přihlášení pomocí Azure Active Directory (AAD).It is also possible to use Azure Active Directory (AAD) logins to manage your databases. Další informace najdete v tématu přihlášení a uživatelé Azure SQL.For more information, see Azure SQL logins and users.

Nastavení přístupu uživatele k sekundární nebo obnovené databáziSet up user access to a secondary or recovered database

Aby byla sekundární databáze použitelná jako sekundární databáze jen pro čtení a zajistila řádný přístup k nové primární databázi nebo databázi obnovená pomocí geografického obnovení, musí mít hlavní databáze cílového serveru příslušné zabezpečení. konfigurace na místě před obnovením.In order for the secondary database to be usable as a read-only secondary database, and to ensure proper access to the new primary database or the database recovered using geo-restore, the master database of the target server must have the appropriate security configuration in place before the recovery.

Konkrétní oprávnění pro jednotlivé kroky jsou popsány dále v tomto tématu.The specific permissions for each step are described later in this topic.

Příprava přístupu uživatele k sekundární geografické replikaci by měla být provedena jako součást konfigurace geografické replikace.Preparing user access to a geo-replication secondary should be performed as part configuring geo-replication. Příprava přístupu uživatelů k geograficky obnoveným databázím by se měla provádět kdykoli, když je původní server online (například jako součást postupu zotavení po havárii).Preparing user access to the geo-restored databases should be performed at any time when the original server is online (e.g. as part of the DR drill).

Poznámka

Pokud převezmete služby při selhání nebo geografické obnovení na server, který nemá správně nakonfigurovaná přihlášení, bude přístup k tomuto účtu omezený na účet správce serveru.If you fail over or geo-restore to a server that does not have properly configured logins, access to it will be limited to the server admin account.

Nastavení přihlašovacích údajů na cílovém serveru zahrnuje tři kroky popsané níže:Setting up logins on the target server involves three steps outlined below:

1. určení přihlašovacích údajů s přístupem k primární databázi1. Determine logins with access to the primary database

Prvním krokem procesu je určení, která přihlášení musí být duplikována na cílovém serveru.The first step of the process is to determine which logins must be duplicated on the target server. K tomu je možné využít dvojici příkazů SELECT, jednu v logické hlavní databázi na zdrojovém serveru a jednu v samotné primární databázi.This is accomplished with a pair of SELECT statements, one in the logical master database on the source server and one in the primary database itself.

Přihlášení na zdrojovém serveru můžou určit jenom správce serveru nebo člen role serveru LoginManager , a to pomocí následujícího příkazu SELECT.Only the server admin or a member of the LoginManager server role can determine the logins on the source server with the following SELECT statement.

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

Pouze člen role databáze db_owner, uživatel dbo nebo správce serveru může určit všechny objekty zabezpečení databáze uživatele v primární databázi.Only a member of the db_owner database role, the dbo user, or server admin, can determine all of the database user principals in the primary database.

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

2. Vyhledejte SID pro přihlašovací údaje identifikované v kroku 1.2. Find the SID for the logins identified in step 1

Porovnáním výstupu dotazů z předchozí části a se shodnými identifikátory SID můžete mapovat přihlášení serveru na uživatele databáze.By comparing the output of the queries from the previous section and matching the SIDs, you can map the server login to database user. Přihlášení, která mají uživatele databáze se shodným identifikátorem SID, mají přístup uživatele k této databázi jako objekt zabezpečení databáze uživatele.Logins that have a database user with a matching SID have user access to that database as that database user principal.

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.The following query can be used to see all of the user principals and their SIDs in a database. Tento dotaz může spustit pouze člen databázové role db_owner nebo správce serveru.Only a member of the db_owner database role or server admin can run this query.

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

Poznámka

Uživatelé INFORMATION_SCHEMA a sys mají null identifikátory SID a identifikátor SID hosta je 0x00.The INFORMATION_SCHEMA and sys users have NULL SIDs, and the guest SID is 0x00. Identifikátor SID dbo může začínat na 0x01060000000001648000000000048454, pokud autor databáze byl správcem serveru, ne členem DbManager.The dbo SID may start with 0x01060000000001648000000000048454, if the database creator was the server admin instead of a member of DbManager.

3. vytvoření přihlašovacích údajů na cílovém serveru3. Create the logins on the target server

Posledním krokem je přejít na cílový server nebo na servery a vygenerovat přihlašovací údaje s příslušnými identifikátory zabezpečení (SID).The last step is to go to the target server, or servers, and generate the logins with the appropriate SIDs. Základní syntaxe je následující.The basic syntax is as follows.

CREATE LOGIN [<login name>]
WITH PASSWORD = <login password>,
SID = <desired login SID>

Poznámka

Pokud chcete uživateli udělit přístup k sekundárnímu, ale ne k primárnímu, můžete to udělat tak, že změníte přihlašovací údaje uživatele na primárním serveru pomocí následující syntaxe.If you want to grant user access to the secondary, but not to the primary, you can do that by altering the user login on the primary server by using the following syntax.

ALTER LOGIN <login name> DISABLE

Při zakázání se heslo nemění, takže v případě potřeby ho můžete kdykoli povolit.DISABLE doesn’t change the password, so you can always enable it if needed.

Další krokyNext steps