Considerazioni sulla sicurezza per l'acceleratore di zona di destinazione di Azure Spring Apps

Articolo
10/10/2023

Questo articolo descrive le considerazioni sulla sicurezza e le raccomandazioni per un carico di lavoro ospitato in Azure Spring Apps. Queste indicazioni consentono di creare un carico di lavoro in grado di rilevare, prevenire e rispondere alle vulnerabilità di sicurezza.

Un'applicazione protetta non può garantire la sicurezza dell'intero carico di lavoro. Come proprietario del carico di lavoro, valutare gli errori umani e valutare la superficie di attacco, ad esempio l'applicazione e i servizi di infrastruttura con cui interagisce l'applicazione.

Azure offre controlli di sicurezza per la rete, l'identità e i dati per supportare la strategia di difesa avanzata. Molti dei controlli sono incorporati in Azure Spring Apps. Queste linee guida si basano sulla baseline di sicurezza di Azure per Azure Spring Apps, derivata da Azure Security Benchmark versione 2.0. Il benchmark fornisce raccomandazioni su come proteggere il carico di lavoro eseguito nel cloud di Azure Spring Apps.

I team centralizzati forniscono controlli di rete e identità come parte della piattaforma. Forniscono protezioni per mantenere il controllo su piattaforme, applicazioni e risorse in Azure. La sottoscrizione della zona di destinazione dell'applicazione fornita per il carico di lavoro viene pre-provisioning con i criteri, ereditati dal gruppo di gestione.

Durante la progettazione del carico di lavoro, assicurarsi che i controlli di sicurezza di cui si è proprietari siano allineati ai controlli centrali. La progettazione è soggetta a revisioni periodiche eseguite dal team di sicurezza centralizzato. Esaminare regolarmente i controlli di sicurezza e i criteri della piattaforma con i team centrali per assicurarsi che i requisiti del carico di lavoro siano soddisfatti.

Per informazioni sulla progettazione della piattaforma, vedere:

Considerazioni relative alla progettazione

Traffico interno. Limitare o consentire il traffico tra le risorse interne per seguire un principio di segmentazione aziendale allineato ai rischi aziendali. Se necessario, creare limiti di isolamento tramite reti virtuali e subnet. Implementare regole per limitare i flussi di traffico tra reti.
Traffico esterno. Usare le risorse native di Azure per proteggere le risorse del carico di lavoro da attacchi da reti esterne, tra cui:
- Attacchi DDoS (Distributed Denial of Service).
- Attacchi specifici dell'applicazione.
- Traffico Internet non richiesto e potenzialmente dannoso.
Gestione delle identità. Usare le funzionalità di Microsoft Entra, ad esempio identità gestite, Single Sign-On, autenticazioni complesse, identità gestite e accesso condizionale per fornire l'autenticazione e l'autorizzazione tramite Microsoft Entra ID.
Monitoraggio della protezione. Il sistema deve disporre di strumenti di monitoraggio per rilevare le minacce e misurare la conformità usando gli obiettivi dell'organizzazione e i controlli di Azure Security Benchmark. Questi strumenti devono essere integrati con sistemi SIEM (Central Security Information and Event Management) per ottenere una visione olistica del comportamento di sicurezza.
Dati in transito. I dati trasferiti tra componenti, posizioni o chiamate API devono essere crittografati.
Dati inattivi. Tutti i dati persistenti, inclusa la configurazione, devono essere crittografati.
Criteri di governance. È consigliabile rilevare le deviazioni dagli standard di conformità impostati dall'organizzazione. Criteri di Azure fornisce definizioni predefinite da applicare per rilevare le deviazioni. Quando si applicano criteri, non si garantisce la conformità completa a tutti i requisiti di un controllo. Potrebbero essere presenti standard conformi che non vengono risolti nelle definizioni predefinite.
Esposizione delle credenziali. È possibile distribuire ed eseguire codice, configurazioni e dati persistenti con identità o segreti. Assicurarsi che le credenziali vengano esaminate quando si accede agli asset.
Gestione dei certificati. I certificati devono essere caricati in base al principio Zero Trust di non considerare mai attendibili, verificare sempre e devono essere senza credenziali. Considerare attendibili solo i certificati condivisi verificando l'identità prima di concedere l'accesso ai certificati.
Distribuzioni coerenti. Usare infrastructure-as-code (IaC) per automatizzare il provisioning e la configurazione di tutte le risorse di Azure e rafforzare il comportamento di sicurezza.

Suggerimenti per la progettazione

Rete come perimetro

Questi controlli di rete creano limiti di isolamento e limitano i flussi all'interno e all'esterno dell'applicazione.

Segmentazione di rete

Creare o usare una rete virtuale esistente quando si distribuiscono le risorse del servizio Azure Spring Cloud.

Creare l'isolamento all'interno della rete virtuale tramite la subnet. Limitare o consentire il traffico tra le risorse interne usando le regole del gruppo di sicurezza di rete. Usare la funzionalità protezione avanzata adattiva della rete di Microsoft Defender per il cloud per rafforzare ulteriormente le configurazioni del gruppo di sicurezza di rete che limitano le porte e gli INDIRIZZI IP di origine. Basare le configurazioni sulle regole del traffico di rete esterne.

Quando si creano regole di sicurezza, usare i tag del servizio di Azure per definire i controlli di accesso alla rete anziché indirizzi IP specifici. Quando si specifica il nome del tag di servizio nel campo di origine o destinazione della regola appropriata, consentire o negare il traffico per il servizio corrispondente. Microsoft gestisce i prefissi di indirizzo coperti dal tag del servizio. Aggiorna automaticamente il tag del servizio quando cambiano gli indirizzi.

Usare il tag del AzureSpringCloud servizio nei gruppi di sicurezza di rete o Firewall di Azure per consentire il traffico verso le applicazioni in Azure Spring Apps.

Per altre informazioni, vedere Responsabilità dei clienti per l'esecuzione di Azure Spring Cloud in una rete virtuale.

Connessione con reti private

In un ambiente condiviso usare Azure ExpressRoute o la rete privata virtuale di Azure (VPN) per creare connessioni private tra i data center di Azure e l'infrastruttura locale. Le connessioni ExpressRoute non passano su Internet pubblico con affidabilità, velocità più veloci e latenze inferiori.

Per vpn da punto a sito e VPN da sito a sito, connettere dispositivi o reti locali a una rete virtuale. Usare qualsiasi combinazione di queste opzioni VPN e Azure ExpressRoute.

Per connettere due o più reti virtuali in Azure, usare il peering di rete virtuale. Il traffico di rete tra reti virtuali di cui è stato eseguito il peering è privato. Questo tipo di traffico viene mantenuto nella rete backbone di Azure.

Attacchi da reti esterne

Posizionare i controlli sul traffico in ingresso e bloccare gli attacchi a livello di applicazione con app Azure lication Gateway con web application firewall integrato (WAF).

Usare Firewall di Azure per limitare il traffico in uscita dall'applicazione. È possibile usare Firewall di Azure per proteggere applicazioni e servizi da traffico potenzialmente dannoso da Internet e da altre posizioni esterne.

Firewall di Azure filtro basato sull'intelligence sulle minacce può inviare un avviso o bloccare il traffico da e verso indirizzi IP dannosi noti e domini. Gli indirizzi IP e i domini sono originati dal feed Intelligence sulle minacce Microsoft. Quando è necessaria l'ispezione del payload, distribuire un sistema di rilevamento/prevenzione intrusioni di terze parti (IDS/IPS) da Azure Marketplace con funzionalità di ispezione del payload. In alternativa, è possibile usare IDS/IPS/IPS basato su host o una soluzione di rilevamento e risposta degli endpoint (EDR) basata su host con o invece di IDS/IPS basato sulla rete.

Per proteggere le risorse del carico di lavoro dagli attacchi DDoS, abilitare la protezione standard DDoS nelle reti virtuali di Azure. Usare Microsoft Defender per il cloud per rilevare rischi di configurazione errata per le risorse correlate alla rete.

Proteggere il servizio dns (Domain Name Service)

Usare DNS di Azure per ospitare domini DNS. Proteggere le zone e i record DNS da attori non validi. A tale scopo, è consigliabile il controllo degli accessi in base al ruolo di Azure e i blocchi delle risorse. Per altre informazioni vedere Prevenire voci DNS inesatte ed evitare l'acquisizione di sotto-domini.

Identità come perimetro

Azure fornisce controlli di identità tramite Microsoft Entra ID. L'applicazione include molte funzionalità, ad esempio Single Sign-On, autenticazioni complesse, identità gestite e accesso condizionale. Per informazioni sulle scelte di progettazione per l'architettura, vedere Considerazioni sulle identità per l'acceleratore di zona di destinazione di Azure Spring Apps.

Nella sezione seguente vengono descritti gli aspetti di sicurezza di tali scelte.

Integrazione con il sistema di gestione delle identità centralizzato

Le zone di destinazione di Azure usano l'ID Microsoft Entra come servizio di gestione delle identità e degli accessi predefinito. Per gestire i servizi del carico di lavoro, è consigliabile usare l'ID Microsoft Entra centralizzato. L'ID Microsoft Entra centralizzato include l'accesso alle risorse di rete dell'organizzazione, Archiviazione di Azure, Key Vault e altri servizi da cui dipende l'applicazione.

Se si vuole concedere l'accesso al piano dati di Azure Spring Apps, usare il ruolo predefinito Azure Spring Cloud Data Reader . Questo ruolo concede le autorizzazioni di sola lettura.

Queste funzionalità di Microsoft Entra sono consigliate:

Identità dell'applicazione. L'applicazione potrebbe dover accedere ad altri servizi di Azure. Ad esempio, se vuole recuperare i segreti da Azure Key Vault.

Usare le identità gestite con Azure Spring Apps in modo che l'applicazione possa eseguire l'autenticazione ad altri servizi usando Microsoft Entra ID. Evitare di usare le entità servizio a questo scopo. Il processo di autenticazione delle identità gestite non usa credenziali hardcoded nel codice sorgente o nei file di configurazione.

Se è necessario usare le entità servizio con credenziali del certificato ed eseguire il fallback ai segreti client, è consigliabile usare l'ID Microsoft Entra per creare un'entità servizio con autorizzazioni limitate a livello di risorsa.

In entrambi i casi, Key Vault può essere usato con le identità gestite da Azure. Un componente di runtime, ad esempio una funzione di Azure, può essere usato per recuperare i segreti da Key Vault. Per altre informazioni, vedere Autenticazione in Azure Key Vault.
Microsoft Entra Single Sign-On (SSO). Microsoft Entra SSO è consigliato per autenticare l'accesso all'applicazione da altre applicazioni o dispositivi eseguiti nel cloud o in locale. L'accesso Single Sign-On fornisce la gestione delle identità a utenti interni ed esterni, ad esempio partner o fornitori.
Controlli di autenticazione avanzata. Microsoft Entra ID supporta controlli di autenticazione avanzata tramite l'autenticazione a più fattori (MFA) e metodi sicuri senza password. Per gli amministratori e gli utenti con privilegi, usare il livello più elevato del metodo di autenticazione avanzata per ridurre il raggio di esplosione in caso di violazione. Implementare quindi i criteri di autenticazione avanzata appropriati ad altri utenti. Per altre informazioni, vedere Abilitare mfa in Azure e opzioni di autenticazione senza password per Microsoft Entra ID.
Accesso condizionale alle risorse. Azure Spring Apps supporta l'accesso condizionale Microsoft Entra per un controllo di accesso più granulare basato su condizioni definite dall'utente. È possibile impostare condizioni per includere gli accessi utente da determinati intervalli IP che devono eseguire l'accesso tramite MFA. Questi criteri di accesso condizionale si applicano solo agli account utente che eseguono l'autenticazione a Microsoft Entra ID per accedere e gestire le applicazioni. Questi criteri non si applicano alle entità servizio, alle chiavi o ai token usati per connettersi alle risorse del carico di lavoro.
Accesso privilegiato. Implementare Microsoft Entra Privileged Identity Management per garantire l'accesso con privilegi minimi e la creazione di report approfonditi nell'intero ambiente Azure. I team dovranno avviare verifiche di accesso ricorrenti per assicurarsi che le persone e le entità servizio giuste abbiano i livelli di autorizzazione corretti e aggiornati.

Controlli dati

I controlli di rete e identità limitano l'accesso all'applicazione, ma i dati devono essere protetti. La crittografia garantisce l'integrità dei dati ed è una funzionalità di sicurezza chiave che deve essere applicata per attenuare le minacce.

Dati in transito

I dati trasferiti sono soggetti a attacchi fuori banda, ad esempio l'acquisizione del traffico. Usare la crittografia per assicurarsi che gli utenti malintenzionati non possano leggere o modificare facilmente tali dati. Azure fornisce la crittografia per i dati in transito tra data center di Azure.

Azure Spring Apps supporta la crittografia con Transport Layer Security (TLS) v1.2 o versione successiva. TLS fornisce comunicazioni sicure tramite identità e attendibilità e crittografa le comunicazioni di tutti i tipi. È possibile usare qualsiasi tipo di certificato TLS. Ad esempio, i certificati rilasciati da un'autorità di certificazione, i certificati di convalida estesi, i certificati con caratteri jolly con supporto per un numero qualsiasi di sottodomini o certificati autofirmato per gli ambienti di sviluppo e test.

La crittografia è fondamentale per il traffico su reti esterne e pubbliche. Per impostazione predefinita, tutti gli endpoint pubblici devono usare HTTPS per il traffico in ingresso. Le chiamate di gestione per configurare il servizio Azure Spring Apps tramite le chiamate API di Azure Resource Manager devono essere tramite HTTPS.

Per il traffico HTTP, assicurarsi che i client che si connettono alle risorse di Azure possano negoziare TLS v1.2 o versione successiva. Non usare versioni o protocolli obsoleti. Disabilitare le crittografie deboli.

Per la gestione remota, invece di usare un protocollo non crittografato, usare Secure Shell (SSH) per Linux o Remote Desktop Protocol (RDP) e TLS per Windows.

Dati inattivi

Il carico di lavoro richiede uno stato di archiviazione per l'origine e gli artefatti, le impostazioni del server di configurazione, le impostazioni dell'app e l'archiviazione. I dati inattivi lato server sono protetti dalla crittografia Archiviazione di Azure. Archiviazione crittografa automaticamente il contenuto con chiavi gestite da Microsoft.

La cache del server di configurazione, i file binari di runtime creati da origini caricate e i log applicazioni durante la durata dell'applicazione vengono salvati in un disco gestito di Azure. Questi dati vengono crittografati automaticamente. Le immagini del contenitore create dall'origine caricata dall'utente vengono crittografate e salvate in Registro Azure Container.

Per gli scenari di supporto, quando Microsoft deve accedere ai dati dei clienti pertinenti, usare Customer Lockbox per Microsoft Azure perché il team o l'organizzazione deve approvare l'accesso.

Monitorare le anomalie degli account e generare avvisi

Microsoft Defender per il cloud è consigliabile ricevere avvisi sulle attività sospette, ad esempio un numero eccessivo di tentativi di autenticazione non riusciti o account deprecati nella sottoscrizione.

Azure Spring Apps è integrato con Microsoft Entra ID, che consente di tenere traccia delle attività di accesso, inclusi gli accessi a rischio. È possibile usare i log di controllo per rilevare le modifiche apportate a qualsiasi risorsa all'interno di Microsoft Entra ID. I dati sono integrati con Monitoraggio di Azure e possono essere esportati in Microsoft Sentinel.

Per altre informazioni, vedi:

Criteri di governance

La definizione predefinita di Azure denominata Azure Spring Cloud deve usare l'inserimento di rete consente di applicare i controlli di rete.

Rilevare l'implementazione dei limiti di isolamento per l'applicazione da Internet.
Abilitare Azure Spring Apps per comunicare con reti private nei data center locali o con il servizio di Azure in altre reti virtuali.
Controllare le comunicazioni di rete in ingresso e in uscita per la rete virtuale di Azure Spring Apps.

Gestione dei certificati

Un'app potrebbe richiedere certificati TLS pubblici durante la comunicazione con i servizi back-end o i sistemi locali. È possibile caricare i certificati in Key Vault.

Per caricare in modo sicuro i certificati da Key Vault, le app Spring Boot usano identità gestite e il controllo degli accessi in base al ruolo di Azure. Azure Spring Apps usa un'entità servizio provider e il controllo degli accessi in base al ruolo di Azure. Questo caricamento sicuro è basato sul provider JCA (Java Cryptography Architecture) di Azure Key Vault. Per altre informazioni, vedere Libreria client JCA di Azure Key Vault per Java.

Se il codice Spring, il codice Java o le librerie open source, ad esempio OpenSSL, si basano sulla catena JCA predefinita di JVM per caricare in modo implicito i certificati nell'archivio attendibilità di JVM, è possibile importare i certificati TLS da Key Vault in Azure Spring Apps. Usare questi certificati all'interno dell'app. Per altre informazioni, vedere Usare certificati TLS/SSL nell'applicazione in Azure Spring Apps.

Analisi delle credenziali

Implementare Credential Scanner per identificare le credenziali che accedono a codice, configurazioni e dati persistenti. Credential Scanner incoraggia lo spostamento delle credenziali individuate in posizioni più sicure, ad esempio Key Vault.

Per GitHub, è possibile usare la funzionalità di analisi dei segreti nativa per identificare le credenziali o altre forme di segreti all'interno del codice.