Configurare l'accesso isolato per le repliche denominate Hyperscale

  • Articolo

Si applica a:database SQL di Azure

Questo articolo descrive la procedura per concedere l'accesso a una replica denominata Hyperscale database SQL di Azure senza concedere l'accesso alla replica primaria o ad altre repliche denominate. Questo scenario consente l'isolamento delle risorse e della sicurezza di una replica denominata, perché la replica denominata verrà eseguita usando il proprio nodo di calcolo, ed è utile ogni volta che è necessario l'accesso in sola lettura isolato a un database Sql Hyperscale di Azure. Isolato, in questo contesto, significa che la CPU e la memoria non sono condivise tra la replica primaria e la replica denominata, le query in esecuzione nella replica denominata non usano risorse di calcolo della replica primaria o di altre repliche e le entità che accedono alla replica denominata non possono accedere ad altre repliche, incluso il database primario.

Nota

Microsoft Entra ID era precedentemente noto come Azure Active Directory (Azure AD).

Creare un account di accesso nel server primario

Nel database nel master server logico che ospita il database primario eseguire quanto segue per creare un nuovo account di accesso.

Usare la password complessa e univoca, sostituendo strong_password_here con la password complessa.

CREATE LOGIN [third-party-login] WITH PASSWORD = 'strong_password_here';

Recuperare il valore esadecimale SID per l'account di accesso creato dalla visualizzazione di sys.sql_logins sistema:

SELECT SID FROM sys.sql_logins WHERE name = 'third-party-login';

Disabilitare l'account di accesso. Ciò impedisce a questo account di accesso di accedere a qualsiasi database nel server che ospita la replica primaria.

ALTER LOGIN [third-party-login] DISABLE;

Creare un utente nel database primario di lettura/scrittura

Dopo aver creato l'account di accesso, connettersi alla replica primaria di lettura/scrittura del database, ad esempio WideWorldImporters (è possibile trovare uno script di esempio per ripristinarlo qui: Ripristinare il database in Azure SQL) e creare un utente del database per tale account di accesso:

CREATE USER [third-party-user] FROM LOGIN [third-party-login];

Come passaggio facoltativo, dopo aver creato l'utente del database, è possibile eliminare l'account di accesso del server creato nel passaggio precedente in caso di problemi relativi all'accesso riabilitato in qualsiasi modo. Connessione al master database nel server logico che ospita il database primario ed eseguire gli script di esempio seguenti:

DROP LOGIN [third-party-login];

Creare una replica denominata in un server logico diverso

Creare un nuovo server logico SQL di Azure da usare per isolare l'accesso alla replica denominata. Seguire le istruzioni disponibili in Creare e gestire server e database singoli in database SQL di Azure. Per creare una replica denominata, questo server deve trovarsi nella stessa area di Azure del server che ospita la replica primaria.

Nell'esempio seguente sostituire strong_password_here con la password complessa. Ad esempio, usando l'interfaccia della riga di comando di Azure:

az sql server create -g MyResourceGroup -n MyNamedReplicaServer -l MyLocation --admin-user MyAdminUser --admin-password strong_password_here

Creare quindi una replica denominata per il database primario in questo server. Ad esempio, usando l'interfaccia della riga di comando di Azure:

az sql db replica create -g MyResourceGroup -n WideWorldImporters -s MyPrimaryServer --secondary-type Named --partner-database WideWorldImporters_NR --partner-server MyNamedReplicaServer

Creare un account di accesso nel server di replica denominato

Connessione al master database nel server logico che ospita la replica denominata creata nel passaggio precedente. Sostituire strong_password_here con la password complessa. Aggiungere l'account di accesso usando il SID recuperato dalla replica primaria:

CREATE LOGIN [third-party-login] WITH PASSWORD = 'strong_password_here', sid = 0x0...1234;

A questo punto, gli utenti e le applicazioni che usano third-party-login o bob@contoso.com possono connettersi alla replica denominata, ma non alla replica primaria.

Concedere autorizzazioni a livello di oggetto all'interno del database

Dopo aver configurato l'autenticazione di accesso come descritto, è possibile usare le normali GRANTistruzioni e DENYREVOKE per gestire l'autorizzazione o le autorizzazioni a livello di oggetto all'interno del database. In queste istruzioni fare riferimento al nome dell'utente creato nel database o a un ruolo del database che include questo utente come membro. Ricordarsi di eseguire questi comandi nella replica primaria. Le modifiche vengono propagate a tutte le repliche secondarie, ma saranno valide solo nella replica denominata in cui è stato creato l'account di accesso a livello di server.

Tenere presente che per impostazione predefinita un utente appena creato dispone di un set minimo di autorizzazioni concesse, ad esempio non può accedere ad alcuna tabella utente. Se si desidera consentire third-party-user o bob@contoso.com leggere i dati in una tabella, è necessario concedere in modo esplicito l'autorizzazione SELECT :

GRANT SELECT ON [Application].[Cities] to [third-party-user];

In alternativa alla concessione delle autorizzazioni singolarmente in ogni tabella, è possibile aggiungere l'utente al ruolo del db_datareadersdatabase per consentire l'accesso in lettura a tutte le tabelle oppure usare schemi per consentire l'accesso a tutte le tabelle esistenti e nuove in uno schema.

Testare l'accesso

È possibile testare questa configurazione usando qualsiasi strumento client e tentare di connettersi al database primario e alla replica denominata. Ad esempio, usando sqlcmd, è possibile provare a connettersi alla replica primaria usando l'utente third-party-login . Sostituire strong_password_here con la password complessa.

sqlcmd -S MyPrimaryServer.database.windows.net -U third-party-login -P strong_password_here -d WideWorldImporters

Verrà generato un errore perché l'utente non è autorizzato a connettersi al server:

Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Login failed for user 'third-party-login'. Reason: The account is disabled.

Il tentativo di connessione alla replica denominata ha esito positivo. Sostituire strong_password_here con la password complessa.

sqlcmd -S MyNamedReplicaServer.database.windows.net -U third-party-login -P strong_password_here -d WideWorldImporters_NR

Non vengono restituiti errori e le query possono essere eseguite nella replica denominata, come consentito dalle autorizzazioni a livello di oggetto concesse.

Contenuto correlato