Considerazioni sulla sicurezza per l'acceleratore di zona di destinazione di Azure Integration Services

Una buona sicurezza è la pietra angolare 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:

• Baseline di sicurezza di Azure per Logic Apps

• Azure baseline di sicurezza per Gestione API

• Azure baseline di sicurezza per Data Factory

• Linee guida di sicurezza di Azure per bus di servizio

• Baseline di sicurezza di Azure per le Funzioni

• Base di sicurezza di Azure per l'archiviazione

• Azure baseline di sicurezza per Key Vault

Considerazioni sulla 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 del design-time implica l'accesso alla gestione e alla creazione di risorse di Azure tramite il portale di Azure o l'API Resource Manager. All'interno di Azure si usano Microsoft Entra ID e il controllo degli accessi in base al ruolo.

• Run-Time la sicurezza comporta 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:

• Private Cloud: tutte le risorse risiedono in una Rete virtuale (rete virtuale) e usano solo reti private, 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 e consentire solo indirizzi/intervalli IP specifici.

• Ibrido : alcune risorse sono private e alcune sono pubbliche.

La scelta effettuata influisce sia sul costo delle tue risorse, sia sul livello di sicurezza che è possibile implementare per le applicazioni.

Le considerazioni generali sulla sicurezza includono:

• Uso di Azure servizi di rete per proteggere il traffico in ingresso e in uscita.

• Uso di Microsoft Entra ID e OAuth 2.0 per gestire l'autenticazione e l'autorizzazione.

• Applicazione di criteri di governance con Criteri di Azure.

• Blocco dell'accesso alle risorse (controllo di accesso).

• Crittografia dei dati sia durante il transito che a riposo.

• Registrazione di tutti i tentativi di accesso alle risorse.

• Controllo dell'accesso alle risorse.

Consigli per la progettazione

Consigli per la progettazione della rete

• Esaminare l'uso di un Application Gateway (gateway applicazione di Azure o Frontdoor di Azure) con un Web application firewall (WAF) davanti agli endpoint accessibili; questo aiuterà con la crittografia automatica dei dati e ti permetterà di monitorare e configurare i tuoi endpoint più facilmente.

  • Frontdoor è una rete di distribuzione di applicazioni che fornisce il servizio globale di bilanciamento del carico e accelerazione del sito per le applicazioni Web. Frontdoor offre funzionalità di livello 7 come l'offload SSL, il routing basato sul percorso, il failover rapido e la memorizzazione nella cache per migliorare le prestazioni e la disponibilità delle applicazioni.

  • Traffic Manager è un servizio di bilanciamento del carico del traffico basato su DNS che consente di distribuire il traffico in modo ottimale ai servizi tra aree di Azure globali, garantendo al tempo stesso disponibilità elevata e velocità di risposta. Poiché 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 delle applicazioni fornisce un controller di distribuzione di applicazioni gestito che offre varie funzionalità di bilanciamento del carico a livello 7. È possibile usare Application Gateway per ottimizzare la produttività della web-farm eseguendo l'offloading della terminazione SSL ad alto utilizzo di CPU al gateway.

  • Azure Load Balancer è un servizio di bilanciamento del carico in ingresso e in uscita di livello 4 a prestazioni elevate e a bassa latenza per tutti i protocolli UDP e TCP. Load Balancer gestisce milioni di richieste al secondo. Load Balancer è ridondante tra zone, garantendo un'alta disponibilità tra le Zone di Disponibilità.

• Implementare l'isolamento di rete per le risorse dei servizi di integrazione usando l'integrazione della rete virtuale (VNet) per posizionare le risorse in una subnet isolata in combinazione con Azure PrivateLink e 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 siano accessibili solo da indirizzi di rete noti (applicabile per i servizi PaaS (Platform-as-a-Service), ad esempio App per la logica, App per le funzioni, bus di servizio, non integrati 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 specifici Azure che non rivelano lo scopo o il proprietario di una risorsa.

Raccomandazioni per la progettazione della crittografia

• Quando si archiviano dati (in Archiviazione di Azure o Azure SQL Server, ad esempio) nei servizi PaaS Azure, sono sempre crittografati a riposo usando chiavi gestite da Microsoft. 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 ulteriori informazioni, vedere Azure crittografia dei dati a riposo e Panoramica della crittografia di Azure. Valutare se l'uso di chiavi gestite Customer (CMK) è necessario o se le chiavi gestite da Microsoft sono sufficienti.

• Usare sempre crittografia in transito (traffico TLS, ad esempio) durante il trasferimento dei 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 Elementi 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 le app di logica, usare l'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. 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 delle app per la logica; Le identità gestite offrono un meccanismo più sicuro e più semplice da gestire per accedere alle risorse, in quanto Azure gestisce l'identità per conto dell'utente.

• Usare OAuth 2.0 come meccanismo di autenticazione tra gli endpoint delle risorse:

  • In Logic Apps o Functions 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 validate-jwtdei criteri 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. Dove possibile, usare una pipeline CI/CD come GitHub Actions o Azure DevOps Pipeline e Infrastruttura come strumenti di codice, ad esempio Bicep o Terraform non solo per distribuire le risorse, ma anche per configurare la sicurezza. In questo modo le risorse verranno protette automaticamente ogni volta che vengono distribuite.

Passo successivo

Esaminare le aree di progettazione critiche per formulare considerazioni e raccomandazioni complete per la vostra architettura.

Contenuti consigliati

• Che è Microsoft Defender per il cloud?

• Che sono le identità gestite per le risorse di Azure?

• Autenticare l'accesso alle risorse di Azure con identità gestite in App per la logica di Azure

• Considerazioni sulla sicurezza per lo spostamento dei dati in Azure Data Factory

• Attivare flussi di lavoro nelle app per la logica Standard con Easy Auth

• Proteggi un'API in Gestione API di Azure utilizzando l'autorizzazione OAuth 2.0 con Microsoft Entra ID

• sicurezza di Azure Key Vault

• Account di archiviazione e sicurezza