Condividi tramite

Configurare l'accesso isolato per 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 isolato in sola lettura a un database Hyperscale SQL di Azure. Isolato, in questo contesto, significa che la CPU e la memoria non sono condivise tra la replica primaria e quella denominata, le query in esecuzione nella replica denominata non usano risorse di calcolo della replica primaria o di altre repliche, e le entità di sicurezza che accedono alla replica denominata non possono accedere ad altre repliche, inclusa quella primaria.

Nota

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

Creare un account di accesso nel server primario

Nel database master nel 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 sistema sys.sql_logins:

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 al server creato nel passaggio precedente se si teme che l'accesso venga riabilitato in qualche modo. Connettersi al database master sul server logico che ospita il database primario ed eseguire i seguenti script di esempio:

DROP LOGIN [third-party-login];

Creare una replica denominata in un server logico diverso

Creare un nuovo server logico SQL di Azure da utilizzare 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 una 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 su 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 sul server di replica denominato

Connettersi al database master sul 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 istruzioni GRANT DENY e REVOKE 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 a third-party-user o bob@contoso.com di leggere i dati in una tabella, è necessario concedere l'autorizzazione SELECT in modo esplicito:

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

In alternativa alla concessione delle autorizzazioni singolarmente su ogni tabella, è possibile aggiungere l'utente al db_datareaders ruolo del database 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.

Accesso al test

È 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 ammesso dalle autorizzazioni a livello di oggetto concesse.

Contenuto correlato