Soluzione scenario 1 - Scalabilità globale dell'architetto e accesso sicuro
Nell'unità precedente è stato usato uno scenario che includeva la scalabilità globale per una rete per la distribuzione di contenuti. In questa unità: verranno esaminate una possibile soluzione e alcuni elementi da considerare.
Durante l'esame, è consigliabile confrontare la soluzione fornita con quella sviluppata nell'unità precedente. Spesso, le soluzioni appropriate per un problema sono più di una, ma esistono sempre dei compromessi. Quali elementi della soluzione sono diversi da quelli proposti? Esistono sono altri aspetti della soluzione che potrebbero essere rivisti? Nella soluzione fornita esistono elementi che si ritiene siano affrontati più accuratamente nella soluzione?
Opzione di distribuzione e configurazione
La prima decisione da considerare è la scelta dell'opzione di distribuzione di SQL di Azure. Sebbene SQL Server in una macchina virtuale di Azure possa funzionare, un'offerta di piattaforma distribuita come servizio (PaaS) può essere più adatta e comporta un sovraccarico di gestione minore.
Il cliente usa CLR (Common Language Runtime), ovvero una funzionalità con ambito di istanza. Istanza gestita di SQL di Azure è l'unica opzione di distribuzione PaaS che supporta funzionalità con ambito di istanza come CLR, Service Broker, Posta elettronica database e così via. Per questo motivo, Istanza gestita di SQL di Azure può consentire al cliente di passare a un'offerta PaaS senza dover riscrivere le applicazioni CLR in uso per trasformarle in una soluzione compatibile con il database SQL di Azure, come i processi di database elastici.
La decisione successiva da prendere coinvolge il livello di servizio. Dato che il cliente vuole isolare i carichi di lavoro di lettura e scrittura, l'uso del livello di servizio business critical sarà il modo più semplice per ottenere questo risultato. Il livello di servizio business critical dispone di un gruppo di disponibilità Always On in esecuzione dietro le quinte. Una di queste repliche secondarie può essere usata per i carichi di lavoro di sola lettura.
La scelta del livello business critical è solo metà della configurazione per separare i carichi di lavoro di lettura e scrittura. Lo scenario indica che il cliente deve essere in grado di estendere i servizi a più aree con più query eseguite contemporaneamente, isolando al tempo stesso i carichi di lavoro di lettura e scrittura.
Le due opzioni che possono potenzialmente soddisfare questa esigenza sono la replica geografica e i gruppi di failover automatico. Tuttavia, la replica geografica non è attualmente supportata nell'Istanza gestita di SQL di Azure. L'uso di un gruppo di failover automatico è quindi l'unica opzione che può essere utile a questo scenario per ottenere il ridimensionamento in lettura globale.
Dato che il cliente usa i gruppi di failover automatico, la necessità di usare o meno il livello di servizio business critical dipende dal numero di endpoint di sola lettura necessari per il carico di lavoro di analisi. Con un gruppo di failover automatico nel livello di servizio business critical, il cliente otterrebbe tre endpoint leggibili:
- Una replica secondaria dal gruppo di disponibilità dell'area primaria
- La replica secondaria del gruppo di failover, ovvero la replica primaria del database nell'area secondaria.
- La replica secondaria dal gruppo di disponibilità dell'area secondaria
Se il carico di lavoro di analisi non necessita di tutte queste repliche leggibili, l'uso del livello di servizio per utilizzo generico può essere una soluzione più economica.
Selezione dei metodi di autenticazione più appropriati
L'altro requisito di questo scenario prevede di determinare il modo migliore per ogni applicazione/persona di connettersi alla soluzione, data la necessità di creare e sfruttare le tecnologie più sicure possibili. Se si suddivide lo scenario, esistono quattro client distinti che dovranno accedere a Istanza gestita di SQL di Azure:
- Applicazione in esecuzione in una macchina virtuale di Azure
- Applicazione in esecuzione in un computer non Azure aggiunto a un dominio
- Analisti di database (DBA) o altri utenti degli strumenti di amministrazione di SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) da un computer non Azure non aggiunto a un dominio
- Applicazioni meno recenti in esecuzione in un computer non Azure in cui non è possibile modificare il driver o la stringa di connessione
Questi client verranno esaminati per comprendere come scegliere il metodo di autenticazione con alcune considerazioni e vincoli aggiuntivi.
Applicazione in esecuzione in una macchina virtuale di Azure
Le identità gestite per le risorse di Azure sono, in genere, la forma consigliata di autenticazione senza password per le applicazioni in esecuzione nelle macchine virtuali di Azure.
Applicazione in esecuzione in un computer non Azure aggiunto a un dominio
Per i computer non Azure, l'uso delle identità gestite non è un'opzione. L'autenticazione integrata tramite Microsoft Entra ID è il metodo di autenticazione consigliato per le app in esecuzione in computer aggiunti a un dominio all'esterno di Azure, presupponendo che il dominio sia federato con Microsoft Entra ID.
Se il computer non Azure non è aggiunto a un dominio, è possibile:
- Creare un'identità di applicazione per l'applicazione in Microsoft Entra ID.
- Associare un certificato all'identità dell'applicazione.
- Modificare l'applicazione per acquisire un token per il database SQL di Azure fornendo un ID client e un certificato.
Anche se il certificato deve contenere una chiave privata e deve essere distribuito nel computer in cui è ospitata l'applicazione, si evita almeno di impostare come hardcoded un segreto dell'applicazione nel codice o nella configurazione dell'applicazione. (Sarà necessario configurare l'app con l'identificazione personale del certificato.)
DBA o altri utenti degli strumenti di amministrazione di SQL da un computer non Azure non aggiunto a un dominio
Per gli utenti esterni ad Azure, se possibile, è consigliabile evitare l'uso di password. È possibile evitare l'uso delle password con gli strumenti SQL usando l'autenticazione integrata di Microsoft Entra. Gli strumenti devono tuttavia essere eseguiti in un computer aggiunto a un dominio e il dominio deve essere stato federato con Microsoft Entra ID. Non è il caso di questo scenario.
Poiché l'ambiente non soddisfa i prerequisiti per l'autenticazione integrata, è consigliabile usare l'autenticazione interattiva di Microsoft Entra con l'autenticazione a più fattori, supportata dalla maggior parte degli strumenti SQL.
Applicazioni meno recenti in esecuzione in un computer non Azure in cui non è possibile modificare il driver o la stringa di connessione
Negli scenari in cui il driver o la stringa di connessione non possono essere modificati, non esiste attualmente un modo per evitare le password. Queste applicazioni meno recenti devono continuare a usare l'autenticazione SQL. Si potrebbe prendere in considerazione la possibilità di esaminare in maggiore dettaglio le restrizioni e il modo in cui possono essere eliminate per applicare un approccio più sicuro e protetto per l'autenticazione delle applicazioni.