Soluzione scenario 2 - Applicazione cruciale
Nell'unità precedente si è lavorato a uno scenario che prevede una disponibilità elevata per un sistema di gestione delle chiamate di pronto intervento. In questa unità verranno esaminati una soluzione possibile e altri 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 selezione per affrontare uno scenario è spesso identificare l'opzione di distribuzione di SQL di Azure potenzialmente ottimale. Se si considera solo il contratto di servizio (SLA), il requisito è per un contratto di servizio del 99,995%, che può essere garantito solo dal database SQL di Azure. Per ottenere questo contratto di servizio, è necessario distribuire il livello di servizio business critical e abilitare l'uso delle zone di disponibilità.
Un altro set di decisioni riguarda come abilitare la ridondanza geografica e garantire una disponibilità elevata in situazioni di emergenza. Anche se in questo caso è possibile usare sia la replica geografica che i gruppi di failover automatico, i gruppi di failover automatico consentiranno al cliente di eseguire il failover se necessario, senza modificare le stringhe di connessione. Questa configurazione può potenzialmente contribuire a ridurre il tempo di inattività per aggiornare le stringhe di connessione delle applicazioni, poiché non sarà necessario. È anche possibile configurare il monitoraggio delle query per verificare lo stato. In questo modo, se si verificano problemi, è anche possibile forzare un failover.
In questa configurazione è anche importante considerare il ruolo della coubicazione. Per mantenere una disponibilità elevata, è necessario che l'applicazione sia il più vicino possibile al database, certamente nella stessa area. È necessario assicurarsi che l'applicazione venga distribuita in entrambe le aree del gruppo di failover automatico, in modo che esista una copia ridondante dell'applicazione (ad esempio, un'app Web). Se si verifica un failover, è possibile usare Gestione traffico di Azure per reindirizzare il traffico all'applicazione nell'area secondaria.
DBA e dati sensibili
I coordinatori del sistema di intervento 113 hanno espresso preoccupazioni in merito a come proteggere i dati sensibili (ad esempio la cronologia dell'integrità e altre informazioni personali), consentendo contemporaneamente ai DBA di svolgere il proprio lavoro.
Per assicurarsi che i DBA non possano visualizzare i dati sensibili archiviati in colonne specifiche e che siano monitorati tutti gli accessi alle tabelle che contengono dati sensibili, è possibile usare alcune tecnologie SQL di Azure. L'uso di SQL Audit è una procedura consigliata per monitorare l'accesso, ma i DBA saranno comunque in grado di visualizzare i dati. La classificazione dei dati sensibili tramite Classificazione dati sarà utile, perché i dati sensibili verranno etichettati e sarà possibile tenerne traccia con SQL Audit. Con queste funzionalità implementate, tuttavia, i DBA saranno comunque in grado di visualizzare i dati sensibili. È possibile usare la funzionalità Dynamic Data Masking per mascherare i dati sensibili, ma non è possibile impedire a un db_owner di visualizzare i dati utente solo con le autorizzazioni.
Se in un database sono presenti dati estremamente sensibili, è possibile usare Always Encrypted per impedire anche ai db_owner di visualizzarli. È possibile gestire le chiavi Always Encrypted con la separazione dei ruoli, in modo che l'amministratore della sicurezza non acceda al database e il DBA non acceda alle chiavi fisiche in testo non crittografato. Usando questa strategia insieme al monitoraggio con SQL Audit, è possibile monitorare, mascherare e tenere traccia dell'accesso ai dati sensibili, anche da DBA con diritti db_owner.
I dati sensibili devono essere mascherati per i DBA, ma questi utenti devono comunque essere in grado di risolvere i problemi relativi alle prestazioni usando il portale di Azure e SQL Server Management Studio o Azure Data Studio. E devono essere in grado di creare nuovi utenti di database indipendenti che devono essere mappati per le entità di sicurezza di Microsoft Entra.
Una soluzione consiste nel creare un gruppo di Microsoft Entra denominato DBA SQL per i DBA in ogni istanza. Assegnare quindi il gruppo al ruolo Collaboratore SQL Server di controllo degli accessi in base al ruolo di Azure. Infine, è possibile impostare il gruppo in modo che sia l'amministratore di Azure AD nel server logico.