Considerazioni sulla sicurezza per l'acceleratore di zona di destinazione di Azure Integration Services
Una buona sicurezza è l'elemento fondamentale di qualsiasi applicazione Azure. Azure Integration Services affronta una sfida particolare, poiché esistono molte risorse che costituiscono un'applicazione e ognuna di queste risorse ha le proprie considerazioni sulla sicurezza. Per assicurarsi di comprendere le considerazioni specifiche di ogni servizio, fare riferimento alle baseline di sicurezza seguenti:
Considerazioni relative alla progettazione
Quando si progetta il modello di sicurezza, esistono due aree di progettazione diverse: sicurezza in fase di progettazione e sicurezza in fase di esecuzione.
La sicurezza in fase di progettazione implica l'accesso alla gestione e alla creazione di risorse di Azure tramite il portale di Azure o un'API di gestione. In Azure si usano microsoft Entra ID e il controllo degli accessi in base al ruolo (RBAC) per ottenere questo risultato.
La sicurezza in fase di esecuzione implica l'accesso a endpoint e risorse durante il flusso di un'applicazione, ad esempio l'autenticazione e l'autorizzazione di un utente che chiama un'app per la logica o un'operazione API in Gestione API.
Decidere in anticipo se è necessario:
Cloud privato: tutte le risorse si trovano in una rete virtuale e usano solo indirizzi privati, senza accesso a o dalla rete Internet pubblica, potenzialmente disponibili per le risorse locali tramite VPN o ExpressRoute.
Cloud pubblico: tutte le risorse pubbliche hanno accesso a Internet pubblico, anche se bloccate per limitare l'accesso da Internet pubblico.
Ibrido : alcune risorse sono private e alcune sono pubbliche.
La scelta effettuata influirà sia sul costo delle risorse, sia sulla quantità di sicurezza che è possibile implementare per le applicazioni.
Le considerazioni generali sulla sicurezza includono:
Uso dei servizi di Azure per proteggere il traffico in ingresso e in uscita.
Uso di Microsoft Entra ID e OAuth 2.0 per gestire l'autenticazione.
Applicazione dei criteri di governance con Criteri di Azure.
Blocco dell'accesso alle risorse (controllo di accesso).
Crittografia dei dati sia in transito che inattivi.
Registrazione di tutti i tentativi di accesso alle risorse.
Controllo dell'accesso alle risorse.
Suggerimenti per la progettazione
Consigli per la progettazione della rete
Esaminare l'uso di un gateway applicazione (app Azure lication Gateway o Frontdoor di Azure) con un web application firewall (WAF) davanti agli endpoint accessibili. Ciò consentirà di monitorare e configurare più facilmente gli endpoint.
Frontdoor è una rete per la distribuzione di applicazioni che offre un servizio globale di bilanciamento del carico e accelerazione del sito per le applicazioni Web. Frontdoor offre funzionalità di livello 7, tra cui offload SSL, routing basato sul percorso, failover rapido, memorizzazione nella cache, che consentono di migliorare le prestazioni e la disponibilità delle applicazioni.
Gestione traffico è un servizio di bilanciamento del carico basato su DNS che consente di distribuire il traffico in modo ottimale ai servizi nelle aree globali di Azure, offrendo al tempo stesso disponibilità e velocità di risposta elevate. Dal momento che Gestione traffico è un servizio di bilanciamento del carico basato su DNS, bilancia il carico solo a livello di dominio. Per questo motivo, non può eseguire il failover altrettanto rapidamente di Frontdoor a causa di problemi comuni relativi alla memorizzazione nella cache DNS e ai sistemi che non rispettano il TTL DNS.
Il gateway applicazione offre un controller per la distribuzione di applicazioni gestite con diverse funzionalità di bilanciamento del carico di livello 7. È possibile usare il gateway applicazione per ottimizzare la produttività delle Web farm eseguendo l'offload al gateway della terminazione SSL con utilizzo elevato di CPU.
Azure Load Balancer è un servizio di bilanciamento del carico in ingresso e in uscita di livello 4 che offre prestazioni elevate e bassissima latenza per tutti i protocolli UDP e TCP. Load Balancer gestisce milioni di richieste al secondo. Load Balancer supporta la ridondanza della zona, garantendo disponibilità elevata tra zone di disponibilità.
Implementare l'isolamento di rete per le risorse dei servizi di integrazione usando l'integrazione della rete virtuale per inserirle in una subnet isolata combinata con l'uso del collegamento privato di Azure e degli endpoint privati. Vedere l'articolo Topologia di rete e connettività in questa serie per una revisione di queste linee guida per la progettazione.
Proteggere il traffico in uscita con Firewall di Azure
Usare il filtro IP per bloccare gli endpoint in modo che possano essere accessibili solo da indirizzi di rete noti (applicabile per le app per la logica non integrate nelle reti virtuali).
Se sono disponibili risorse pubblicamente, usare l'offuscamento DNS per scoraggiare eventuali utenti malintenzionati; offuscamento significa nomi di dominio personalizzati o nomi di risorse di Azure specifici che non rivelano lo scopo o il proprietario di una risorsa.
Raccomandazioni per la progettazione della crittografia
Quando si archiviano i dati (ad esempio, in Archiviazione di Azure o IN SQL Server di Azure), abilitare sempre Crittografia dei dati inattivi. Bloccare l'accesso ai dati, idealmente solo ai servizi e a un numero limitato di amministratori. Tenere presente che questo vale anche per i dati di log. Per altre informazioni, vedere Crittografia dei dati inattivi di Azure e Panoramica sulla crittografia di Azure.
Usare sempre la crittografia in transito (traffico TLS, ad esempio) quando si trasferiscono dati tra le risorse. Non inviare mai dati su un canale non crittografato.
Quando si usano protocolli TLS, usare sempre TLS 1.2 o versione successiva.
Mantenere i segreti in Azure Key Vault e quindi collegarli a Impostazioni app (funzioni, app per la logica), valori denominati (Gestione API) o voci di configurazione (Configurazione app).
Implementare criteri di rotazione delle chiavi per garantire che tutte le chiavi in uso nell'ambiente vengano ruotate regolarmente per evitare attacchi che usano chiavi compromesse
Per App per la logica, usare offuscamento per proteggere i dati nella cronologia di esecuzione.
Raccomandazioni per l'autenticazione e la progettazione dell'accesso
Seguire sempre il principio dei privilegi minimi quando si assegna l'accesso: assegnare a un'identità le autorizzazioni minime necessarie. A volte ciò comporta la creazione di un ruolo Microsoft Entra personalizzato. Se non esiste un ruolo predefinito con le autorizzazioni minime necessarie, è consigliabile creare un ruolo personalizzato con solo queste autorizzazioni.
Quando possibile, usare sempre identità gestite quando una risorsa deve accedere a un servizio. Ad esempio, se il flusso di lavoro dell'app per la logica deve accedere a Key Vault per recuperare un segreto, usare l'identità gestita dell'app per la logica per ottenere questo risultato; Le identità gestite offrono un meccanismo più sicuro e più semplice da gestire per accedere alle risorse, perché Azure gestisce l'identità per conto dell'utente.
Usare OAuth 2.0 come meccanismo di autenticazione tra gli endpoint delle risorse:
In App per la logica o funzioni abilitare Easy Auth, che richiede a tutti i chiamanti esterni di usare un'identità OAuth (in genere Microsoft Entra ID, ma potrebbe essere qualsiasi provider di identità).
In Gestione API usare l'elemento dei criteri jwt-validation per richiedere un flusso OAuth per le connessioni agli endpoint.
In Archiviazione di Azure e Key Vault configurare i criteri di accesso per limitare l'accesso a identità specifiche.
Raccomandazioni sulla progettazione della governance
Usare attivamente Criteri di Azure per cercare problemi di sicurezza o difetti. Ad esempio, gli endpoint senza filtro IP.
Se disponibile, usare Microsoft Defender per il cloud per analizzare le risorse e identificare potenziali punti deboli.
Esaminare regolarmente i log di controllo (idealmente usando uno strumento automatizzato) per identificare sia gli attacchi di sicurezza che qualsiasi accesso non autorizzato alle risorse.
Prendere in considerazione l'uso dei test di penetrazione per identificare eventuali punti deboli nella progettazione della sicurezza.
Usare i processi di distribuzione automatizzati per configurare la sicurezza. Se possibile, usare una pipeline CI/CD come Azure DevOps con Terraform per distribuire non solo le risorse, ma anche per configurare la sicurezza. In questo modo le risorse verranno protette automaticamente ogni volta che vengono distribuite.
Passaggio successivo
Esaminare le aree di progettazione critiche per prendere in considerazione e consigli completi per l'architettura.