Considerazioni sulla sicurezza per carichi di lavoro cruciali in Azure

La sicurezza è uno dei principi fondamentali della progettazione e anche un'area di progettazione chiave che deve essere considerata un problema di prima classe all'interno del processo architettonico cruciale.

Dato che l'obiettivo principale di una progettazione cruciale è ottimizzare l'affidabilità in modo che l'applicazione rimanga efficiente e disponibile, le considerazioni sulla sicurezza e le raccomandazioni applicate all'interno di questa area di progettazione si concentrerà sulla mitigazione delle minacce con la capacità di influire sulla disponibilità e ostacolare l'affidabilità complessiva. Ad esempio, gli attacchi Denial-Of-Service (DDoS) riusciti hanno un impatto irreversibile sulla disponibilità e sulle prestazioni. Il modo in cui un'applicazione attenua tali vettori di attacco, ad esempio SlowLoris, influirà sull'affidabilità complessiva. Pertanto, l'applicazione deve essere completamente protetta dalle minacce destinate a compromettere direttamente o indirettamente l'affidabilità delle applicazioni per essere veramente cruciali in natura.

È anche importante notare che spesso esistono compromessi significativi associati a un comportamento di sicurezza avanzata, in particolare per quanto riguarda le prestazioni, l'agilità operativa e in alcuni casi l'affidabilità. Ad esempio, l'inclusione di appliance virtuali di rete inline per le funzionalità NGFW (Next-Generation Firewall), ad esempio l'ispezione approfondita dei pacchetti, comporterà una riduzione significativa delle prestazioni, una maggiore complessità operativa e un rischio di affidabilità se le operazioni di scalabilità e ripristino non sono strettamente allineate a quella dell'applicazione. È quindi essenziale che altri componenti e procedure di sicurezza destinati a mitigare i vettori di minaccia chiave siano progettati anche per supportare la destinazione di affidabilità di un'applicazione, che formerà un aspetto chiave delle raccomandazioni e delle considerazioni presentate in questa sezione.

Importante

Questo articolo fa parte della serie di carichi di lavoro cruciali di Azure Well-Architected. Se non si ha familiarità con questa serie, è consigliabile iniziare con un carico di lavoro cruciale?

Progetto open source mission-critical

Le implementazioni di riferimento fanno parte di un progetto open source disponibile in GitHub. Gli asset di codice adottano un modello Zero Trust per strutturare e guidare l'approccio di progettazione e implementazione della sicurezza.

Allineamento con il modello Zero Trust

Il modello Microsoft Zero Trust offre un approccio proattivo e integrato per applicare la sicurezza in tutti i livelli di un'applicazione. I principi guida di Zero Trust si sforzano di verificare in modo esplicito e continuo ogni transazione, affermare privilegi minimi, usare intelligenza e rilevamento avanzato per rispondere alle minacce quasi in tempo reale. In definitiva, è incentrato sull'eliminazione dell'attendibilità all'interno e all'esterno dei perimetri dell'applicazione, applicando la verifica per qualsiasi tentativo di connessione al sistema.

Considerazioni relative alla progettazione

Quando si valuta il comportamento di sicurezza dell'applicazione, iniziare con queste domande come base per ogni considerazione.

• Test di sicurezza continui per convalidare le mitigazioni per le vulnerabilità di sicurezza chiave.

  • I test di sicurezza vengono eseguiti come parte dei processi CI/CD automatizzati?
  • In caso contrario, con quale frequenza vengono eseguiti specifici test di sicurezza?
  • I risultati dei test vengono misurati in base al comportamento di sicurezza e al modello di minaccia desiderato?

• Livello di sicurezza in tutti gli ambienti inferiori.

  • Tutti gli ambienti all'interno del ciclo di vita di sviluppo hanno lo stesso comportamento di sicurezza dell'ambiente di produzione?

• Continuità di autenticazione e autorizzazione in caso di errore.

  • Se i servizi di autenticazione o autorizzazione non sono temporaneamente disponibili, l'applicazione potrà continuare a funzionare?

• Conformità e correzione della sicurezza automatizzate.

  • È possibile rilevare modifiche alle impostazioni di sicurezza chiave?
  • Le risposte per correggere le modifiche non conformi sono automatizzate?

• Analisi dei segreti per rilevare i segreti prima che venga eseguito il commit del codice per evitare perdite di segreti tramite repository di codice sorgente.

  • L'autenticazione ai servizi è possibile senza avere credenziali come parte del codice?

• Proteggere la catena di approvvigionamento software.

  • È possibile tenere traccia delle vulnerabilità comuni e delle esposizioni (CVE) all'interno delle dipendenze dei pacchetti usati?
  • Esiste un processo automatizzato per l'aggiornamento delle dipendenze dei pacchetti?

• Cicli di vita delle chiavi di protezione dei dati.

  • Le chiavi gestite dal servizio possono essere usate per la protezione dell'integrità dei dati?
  • Se sono necessarie chiavi gestite dal cliente, qual è il ciclo di vita sicuro e affidabile delle chiavi?

• Gli strumenti CI/CD devono richiedere alle entità servizio Microsoft Entra con accesso a livello di sottoscrizione sufficiente per facilitare l'accesso del piano di controllo per le distribuzioni di risorse di Azure a tutte le sottoscrizioni di ambiente considerate.

  • Quando le risorse dell'applicazione sono bloccate all'interno di reti private, esiste un percorso di connettività del piano dati privato in modo che gli strumenti CI/CD possano eseguire distribuzioni e manutenzione a livello di applicazione.
    • Ciò introduce una complessità aggiuntiva e richiede una sequenza all'interno del processo di distribuzione tramite gli agenti di compilazione privati necessari.

Suggerimenti per la progettazione

• Usare Criteri di Azure per applicare configurazioni di sicurezza e affidabilità per tutti i servizi, assicurandosi che qualsiasi deviazione venga risolta o vietata dal piano di controllo in fase di configurazione, contribuendo a ridurre le minacce associate a scenari di "amministratore dannoso".

• Usare Microsoft Entra Privileged Identity Management (PIM) nelle sottoscrizioni di produzione per revocare l'accesso prolungato del piano di controllo agli ambienti di produzione. In questo modo si ridurrà significativamente il rischio rappresentato da scenari di "amministratore dannoso" tramite controlli e saldi aggiuntivi.

• Usare identità gestite di Azure per tutti i servizi che supportano la funzionalità, poiché facilita la rimozione delle credenziali dal codice dell'applicazione e rimuove il carico operativo della gestione delle identità per la comunicazione da servizio a servizio.

• Usare il controllo degli accessi in base al ruolo di Microsoft Entra per l'autorizzazione del piano dati con tutti i servizi che supportano la funzionalità.

• Usare librerie di autenticazione di Microsoft Identity Platform di prima parte all'interno del codice dell'applicazione per l'integrazione con Microsoft Entra ID.

• Prendere in considerazione la memorizzazione nella cache dei token sicura per consentire un'esperienza danneggiata ma disponibile se la piattaforma di gestione delle identità scelta non è disponibile o è disponibile solo parzialmente per l'autorizzazione dell'applicazione.

  • Se il provider non è in grado di emettere nuovi token di accesso, ma convalida quelli esistenti, l'applicazione e i servizi dipendenti possono funzionare senza problemi fino alla scadenza dei token.
  • La memorizzazione nella cache dei token viene in genere gestita automaticamente dalle librerie di autenticazione , ad esempio MSAL.

• Usare le pipeline IaC (Infrastructure-as-Code) e le pipeline CI/CD automatizzate per eseguire aggiornamenti a tutti i componenti dell'applicazione, incluse le circostanze di errore.

  • Assicurarsi che le connessioni al servizio strumenti CI/CD siano protette come informazioni sensibili critiche e non siano direttamente disponibili per i team del servizio.
  • Applicare il controllo degli accessi in base al ruolo granulare alle pipeline cd di produzione per ridurre i rischi di "amministratore dannoso".
  • Prendere in considerazione l'uso di controlli di approvazione manuali all'interno delle pipeline di distribuzione di produzione per attenuare ulteriormente i rischi di "amministratore dannoso" e fornire ulteriore garanzia tecnica per tutte le modifiche di produzione.
    • Controlli di sicurezza aggiuntivi possono venire a un compromesso in termini di agilità e devono essere valutati attentamente, tenendo conto di come l'agilità può essere mantenuta anche con cancelli manuali.

• Definire un comportamento di sicurezza appropriato per tutti gli ambienti inferiori per garantire che le vulnerabilità principali vengano attenuate.

  • Non applicare la stessa postura di sicurezza dell'ambiente di produzione, in particolare per quanto riguarda l'esfiltrazione dei dati, a meno che i requisiti normativi non prevedano la necessità di farlo, poiché ciò comprometterà significativamente l'agilità degli sviluppatori.

• Abilitare Microsoft Defender per il cloud (in precedenza noto come Centro sicurezza di Azure) per tutte le sottoscrizioni che contengono le risorse per un carico di lavoro mission-critical.

  • Usare Criteri di Azure per applicare la conformità.
  • Abilitare Azure Defender per tutti i servizi che supportano la funzionalità.

• Adottare DevSecOps e implementare test di sicurezza nelle pipeline CI/CD.

  • I risultati dei test devono essere misurati in base a un comportamento di sicurezza conforme per informare le approvazioni del rilascio, perché siano automatizzati o manuali.
  • Applicare test di sicurezza come parte del processo di produzione cd per ogni versione.
    • Se ogni versione mette a repentaglio l'agilità operativa, assicurarsi che venga applicata una frequenza di test di sicurezza appropriata.

• Abilitare l'analisi dei segreti e l'analisi delle dipendenze all'interno del repository del codice sorgente.

Modellazione delle minacce

La modellazione delle minacce offre un approccio basato sui rischi alla progettazione della sicurezza, usando potenziali minacce identificate per sviluppare mitigazioni della sicurezza appropriate. Esistono molte possibili minacce con probabilità variabili di occorrenza e in molti casi le minacce possono concatenarsi in modi imprevisti, imprevedibili e persino caotici. Questa complessità e incertezza è il motivo per cui gli approcci di sicurezza basati sui requisiti tecnologici tradizionali sono in gran parte inadatti per le applicazioni cloud cruciali. Si prevede che il processo di modellazione delle minacce per un'applicazione mission-critical sia complesso e insoddisabile.

Per esplorare queste sfide, è necessario applicare un approccio di difesa a più livelli per definire e implementare mitigazioni di compensazione per le minacce modellate, considerando i livelli difensivi seguenti.

1. La piattaforma Azure con funzionalità e controlli di sicurezza di base.
2. Architettura dell'applicazione e progettazione della sicurezza.
3. Funzionalità di sicurezza predefinite, abilitate e distribuibili applicate alle risorse di Azure sicure.
4. Codice dell'applicazione e logica di sicurezza.
5. Processi operativi e DevSecOps.

Nota

Quando si esegue la distribuzione all'interno di una zona di destinazione di Azure, tenere presente che un ulteriore livello di mitigazione delle minacce tramite il provisioning delle funzionalità di sicurezza centralizzate viene fornito dall'implementazione della zona di destinazione.

Considerazioni relative alla progettazione

STRIDE offre un framework di rischio leggero per valutare le minacce alla sicurezza tra vettori di minacce chiave.

• Identità spoofed: rappresentazione di individui con autorità. Ad esempio, un utente malintenzionato che rappresenta un altro utente usando il relativo :
  • Identità
  • Autenticazione
• Input manomissione: modifica dell'input inviato all'applicazione o violazione dei limiti di attendibilità per modificare il codice dell'applicazione. Ad esempio, un utente malintenzionato che usa SQL Injection per eliminare i dati in una tabella di database.
  • Integrità dei dati
  • Convalida
  • Blocklisting/allowlisting
• Ripudio dell'azione: possibilità di rifare le azioni già eseguite e la capacità dell'applicazione di raccogliere prove e guidare la responsabilità. Ad esempio, l'eliminazione di dati critici senza la possibilità di tracciare un amministratore malintenzionato.
  • Controllo/registrazione
  • per la firma
• Divulgazione di informazioni: ottenere l'accesso alle informazioni limitate. Un esempio è un utente malintenzionato che ottiene l'accesso a un file con restrizioni.
  • Crittografia
  • Esfiltrazione di dati
  • Attacchi man-in-the-middle
• Denial of Service: interruzione dannosa dell'applicazione per ridurre l'esperienza utente. Ad esempio, un attacco botnet DDoS, ad esempio Slowloris.
  • DDoS
  • Botnet
  • Funzionalità di rete CDN e WAF
• Elevazione dei privilegi: ottenere l'accesso alle applicazioni con privilegi tramite exploit di autorizzazione. Ad esempio, un utente malintenzionato modifica una stringa URL per ottenere l'accesso alle informazioni riservate.
  • Esecuzione di codice in modalità remota
  • Autorizzazione
  • Isolamento

Suggerimenti per la progettazione

• Allocare il budget di progettazione all'interno di ogni sprint per valutare potenziali nuove minacce e implementare le mitigazioni.

• L'impegno consapevole deve essere applicato per garantire che le mitigazioni della sicurezza vengano acquisite all'interno di criteri di progettazione comuni per favorire la coerenza tra tutti i team del servizio applicazioni.

• Iniziare con un servizio tramite la modellazione delle minacce a livello di servizio e unificare il modello consolidando il modello di thread a livello di applicazione.

Protezione dalle intrusioni di rete

Impedire l'accesso non autorizzato a un'applicazione cruciale e includere i dati è fondamentale per mantenere la disponibilità e salvaguardare l'integrità dei dati.

Considerazioni relative alla progettazione

• Zero Trust presuppone uno stato violato e verifica ogni richiesta come se provenga da una rete non controllata.

  • Un'implementazione avanzata della rete zero-trust usa micro-segmentazione e micro-perimetrali in ingresso/uscita distribuiti.

• I servizi PaaS di Azure sono in genere accessibili tramite endpoint pubblici. Azure offre funzionalità per proteggere gli endpoint pubblici o persino renderli completamente privati.

  • gli endpoint collegamento privato di Azure/privati forniscono accesso dedicato a una risorsa PaaS di Azure usando indirizzi IP privati e connettività di rete privata.
  • Rete virtuale gli endpoint di servizio forniscono l'accesso a livello di servizio dalle subnet selezionate ai servizi PaaS selezionati.
  • Rete virtuale injection fornisce distribuzioni private dedicate per i servizi supportati, ad esempio servizio app tramite un ambiente del servizio app.
    • Il traffico del piano di gestione continua a fluire attraverso indirizzi IP pubblici.

• Per i servizi supportati, collegamento privato di Azure l'uso di endpoint privati di Azure risolve i rischi di esfiltrazione dei dati associati agli endpoint di servizio, ad esempio un amministratore malintenzionato che scrive dati in una risorsa esterna.

• Quando si limita l'accesso di rete ai servizi PaaS di Azure usando endpoint privati o endpoint di servizio, per distribuire e gestire l'applicazione sarà necessario un canale di rete sicuro per consentire alle pipeline di distribuzione di accedere sia al piano di controllo di Azure che al piano dati delle risorse di Azure.

  • Gli agenti di compilazione self-hosted privati distribuiti in una rete privata perché la risorsa di Azure può essere usata come proxy per eseguire funzioni CI/CD tramite una connessione privata. Per gli agenti di compilazione deve essere usata una rete virtuale separata.
    • È necessaria la connettività agli agenti di compilazione privati dagli strumenti CI/CD.
  • Un approccio alternativo consiste nel modificare le regole del firewall per la risorsa in tempo reale all'interno della pipeline per consentire una connessione da un indirizzo IP pubblico dell'agente DevOps di Azure, con il firewall successivamente rimosso al termine dell'attività.
    • Tuttavia, questo approccio è applicabile solo per un subset di servizi di Azure. Ad esempio, questo non è fattibile per i cluster del servizio Azure Kubernetes privati.
  • Per eseguire attività amministrative e di sviluppo nei jumpbox del servizio applicazioni, è possibile usare.

• Il completamento delle attività di amministrazione e manutenzione è un ulteriore scenario che richiede la connettività al piano dati delle risorse di Azure.

• Le connessioni al servizio con un'entità servizio Microsoft Entra corrispondente possono essere usate all'interno di Azure DevOps per applicare il controllo degli accessi in base al ruolo tramite Microsoft Entra ID.

• I tag del servizio possono essere applicati ai gruppi di sicurezza di rete per facilitare la connettività con i servizi PaaS di Azure.

• I gruppi di sicurezza delle applicazioni non si estendono su più reti virtuali.

• L'acquisizione di pacchetti in Azure Network Watcher è limitata a un periodo massimo di cinque ore.

Suggerimenti per la progettazione

• Limitare l'accesso alla rete pubblica al minimo assoluto necessario per consentire all'applicazione di soddisfare lo scopo aziendale per ridurre la superficie di attacco esterna.

  • Usare collegamento privato di Azure per stabilire endpoint privati per le risorse di Azure che richiedono l'integrazione di rete sicura.
  • Usare agenti di compilazione privati ospitati per gli strumenti CI/CD per distribuire e configurare le risorse di Azure protette da collegamento privato di Azure.
    • Gli agenti ospitati da Microsoft non saranno in grado di connettersi direttamente alle risorse integrate di rete.

• Quando si gestiscono agenti di compilazione privati, non aprire mai una porta RDP o SSH direttamente su Internet.

  • Usare Azure Bastion per fornire l'accesso sicuro ad Azure Macchine virtuali e per eseguire attività amministrative in Azure PaaS tramite Internet.

• Usare un piano di protezione standard DDoS per proteggere tutti gli indirizzi IP pubblici all'interno dell'applicazione.

• Usare Frontdoor di Azure con criteri web application firewall per distribuire e proteggere le applicazioni HTTP/S globali che si estendono su più aree di Azure.

  • Usare la convalida dell'ID intestazione per bloccare gli endpoint dell'applicazione pubblica in modo che accettino solo il traffico proveniente dall'istanza di Frontdoor di Azure.

• Se requisiti aggiuntivi di sicurezza della rete in linea, ad esempio l'ispezione approfondita dei pacchetti o l'ispezione TLS, impongono l'uso di Firewall di Azure Premium o appliance virtuale di rete (NVA), assicurarsi che sia configurato per la massima disponibilità elevata e ridondanza.

• Se esistono requisiti di acquisizione pacchetti, usare i pacchetti Network Watcher per acquisire nonostante la finestra di acquisizione limitata.

• Usare i gruppi di sicurezza di rete e i gruppi di sicurezza delle applicazioni per micro segmentare il traffico delle applicazioni.

  • Evitare di usare un'appliance di sicurezza per filtrare i flussi di traffico all'interno dell'applicazione.
  • Si consideri l'uso di Criteri di Azure per applicare regole del gruppo di sicurezza di rete specifiche sono sempre associate alle subnet dell'applicazione.

• Abilitare i log dei flussi dei gruppi di sicurezza di rete e inserirli in Analisi del traffico per ottenere informazioni dettagliate sui flussi di traffico interni ed esterni dell'applicazione.

• Usare gli endpoint collegamento privato di Azure/privati, se disponibili, per proteggere l'accesso ai servizi PaaS di Azure all'interno della progettazione dell'applicazione. Per informazioni sui servizi di Azure che supportano collegamento privato, vedere collegamento privato di Azure disponibilità.

• Se l'endpoint privato non è disponibile e i rischi di esfiltrazione dei dati sono accettabili, usare Rete virtuale endpoint di servizio per proteggere l'accesso ai servizi PaaS di Azure dall'interno di una rete virtuale.

  • Non abilitare gli endpoint servizio di rete virtuale per impostazione predefinita in tutte le subnet, perché in questo modo verranno introdotti canali di esfiltrazione di dati significativi.

• Per gli scenari di applicazioni ibride, accedere ai servizi PaaS di Azure dall'ambiente locale tramite ExpressRoute con peering privato.

Nota

Quando si esegue la distribuzione all'interno di una zona di destinazione di Azure, tenere presente che la connettività di rete ai data center locali viene fornita dall'implementazione della zona di destinazione. Un approccio consiste nell'usare ExpressRoute configurato con il peering privato.

Protezione dell'integrità dei dati

La crittografia è un passaggio fondamentale per garantire l'integrità dei dati ed è in definitiva una delle funzionalità di sicurezza più importanti che possono essere applicate per attenuare un'ampia gamma di minacce. In questa sezione verranno quindi fornite considerazioni chiave e raccomandazioni relative alla crittografia e alla gestione delle chiavi per proteggere i dati senza compromettere l'affidabilità delle applicazioni.

Considerazioni relative alla progettazione

• Azure Key Vault prevede limiti di transazione per chiavi e segreti, con la limitazione applicata per ogni insieme di credenziali entro un determinato periodo.

• Azure Key Vault fornisce un limite di sicurezza perché le autorizzazioni di accesso per chiavi, segreti e certificati vengono applicati a livello di insieme di credenziali.

  • I criteri di accesso di Key Vault concedono autorizzazioni separate per chiavi, segreti o certificati.
    • Sono ora possibili autorizzazioni granulari a livello di oggetto per una chiave, un segreto o un certificato specifico.

• Dopo la modifica di un'assegnazione di ruolo, è presente una latenza fino a 10 minuti (600 secondi) per l'applicazione del ruolo.

  • È previsto un limite di 2.000 assegnazioni di ruolo di Azure per ogni sottoscrizione.

• I moduli di sicurezza hardware sottostanti di Azure Key Vault hanno la convalida FIPS 140.

  • Un modulo di protezione hardware gestito di Azure Key Vault dedicato è disponibile per scenari che richiedono la conformità FIPS 140-2 Livello 3.

• Azure Key Vault offre disponibilità elevata e ridondanza per mantenere la disponibilità e prevenire la perdita di dati.

• Durante un failover dell'area, il failover del servizio Key Vault potrebbe richiedere alcuni minuti.

  • Durante un insieme di credenziali delle chiavi di failover sarà in modalità di sola lettura, quindi non sarà possibile modificare le proprietà dell'insieme di credenziali delle chiavi, ad esempio le configurazioni e le impostazioni del firewall.

• Se si usa un collegamento privato per connettersi ad Azure Key Vault, potrebbero essere necessari fino a 20 minuti prima che la connessione venga ristabilita durante un failover a livello di area.

• Un backup crea uno snapshot temporizzato di un segreto, di una chiave o di un certificato, come BLOB crittografato che non può essere decrittografato all'esterno di Azure. Per ottenere dati utilizzabili dal BLOB, è necessario ripristinarli in un insieme di credenziali delle chiavi nella stessa sottoscrizione di Azure e nella stessa area geografica di Azure.

  • I segreti possono essere rinnovati durante un backup, causando una mancata corrispondenza.

• Con le chiavi gestite dal servizio, Azure eseguirà funzioni di gestione delle chiavi, ad esempio la rotazione, riducendo così l'ambito delle operazioni dell'applicazione.

• I controlli normativi possono prevedere l'uso di chiavi gestite dal cliente per la funzionalità di crittografia del servizio.

• Quando il traffico passa tra data center di Azure, la crittografia del livello di collegamento dati MACsec viene usata nell'hardware di rete sottostante per proteggere i dati in transito all'esterno dei limiti fisici non controllati da Microsoft o per conto di Microsoft.

Suggerimenti per la progettazione

• Usare chiavi gestite dal servizio per la protezione dei dati, se possibile, rimuovendo la necessità di gestire le chiavi di crittografia e gestire attività operative come la rotazione delle chiavi.

  • Usare chiavi gestite dal cliente solo quando è necessario un requisito normativo chiaro.

• Usare Azure Key Vault come repository sicuro per tutti i segreti, i certificati e le chiavi se sono necessari meccanismi di crittografia aggiuntivi o chiavi gestite dal cliente.

  • Effettuare il provisioning di Azure Key Vault con i criteri di eliminazione e ripulitura software abilitati per consentire la protezione della conservazione per gli oggetti eliminati.
  • Usare lo SKU di Azure Key Vault supportato da HSM per gli ambienti di produzione delle applicazioni.

• Distribuire un'istanza separata di Azure Key Vault all'interno di ogni stamp di distribuzione a livello di area, offrendo vantaggi per l'isolamento degli errori e le prestazioni tramite la localizzazione, oltre a esplorare i limiti di scalabilità imposti da una singola istanza di Key Vault.

  • Usare un'istanza dedicata di Azure Key Vault per le risorse globali dell'applicazione.

• Seguire un modello con privilegi minimi limitando l'autorizzazione per eliminare definitivamente segreti, chiavi e certificati ai ruoli personalizzati di Microsoft Entra personalizzati.

• Assicurarsi che venga eseguito il backup delle chiavi di crittografia e dei certificati archiviati in Key Vault, fornendo una copia offline nell'evento improbabile che Key Vault non sia disponibile.

• Usare i certificati Key Vault per gestire l'approvvigionamento e la firma dei certificati.

• Stabilire un processo automatizzato per la rotazione delle chiavi e dei certificati.

  • Automatizzare il processo di gestione e rinnovo dei certificati con autorità di certificazione pubbliche per semplificare l'amministrazione.
    • Impostare avvisi e notifiche per integrare i rinnovi automatici dei certificati.

• Monitorare l'utilizzo di chiavi, certificati e segreti.

  • Definire avvisi per l'utilizzo imprevisto in Monitoraggio di Azure.

Governance basata sui criteri

Le convenzioni di sicurezza sono in definitiva efficaci solo se applicate in modo coerente e olistico in tutti i servizi e i team delle applicazioni. Criteri di Azure fornisce un framework per applicare le baseline di sicurezza e affidabilità, garantendo la conformità continua con criteri di progettazione comuni per un'applicazione cruciale. In particolare, Criteri di Azure costituisce una parte fondamentale del piano di controllo di Azure Resource Manager (ARM), integrando il controllo degli accessi in base al ruolo limitando le azioni che gli utenti autorizzati possono eseguire e possono essere usate per applicare convenzioni di sicurezza e affidabilità vitali nei servizi della piattaforma usati.

In questa sezione verranno quindi esaminate le considerazioni chiave e le raccomandazioni relative all'uso di Criteri di Azure governance guidata per un'applicazione cruciale, assicurando che vengano applicate continuamente convenzioni di sicurezza e affidabilità.

Considerazioni relative alla progettazione

• Criteri di Azure fornisce un meccanismo per favorire la conformità applicando convenzioni di sicurezza e affidabilità, ad esempio l'uso di endpoint privati o l'uso di zone di disponibilità.

Nota

Quando si esegue la distribuzione all'interno di una zona di destinazione di Azure, tenere presente che l'applicazione delle assegnazioni di criteri di base centralizzate verrà probabilmente applicata nell'implementazione per i gruppi di gestione e le sottoscrizioni della zona di destinazione.

• Criteri di Azure può essere usato per gestire le attività di gestione automatizzate, ad esempio il provisioning e la configurazione.

  • Registrazione del provider di risorse.
  • Convalida e approvazione delle singole configurazioni delle risorse di Azure.

• Criteri di Azure ambito di assegnazione determina la copertura e la posizione delle definizioni di Criteri di Azure informa la riutilizzabilità dei criteri personalizzati.

• Criteri di Azure presenta diversi limiti, ad esempio il numero di definizioni in un ambito specifico.

• L'esecuzione dei criteri Deploy If Not Exist (DINE) può richiedere alcuni minuti.

• Criteri di Azure fornisce un input critico per la creazione di report di conformità e il controllo della sicurezza.

Suggerimenti per la progettazione

• Eseguire il mapping dei requisiti normativi e di conformità alle definizioni di Criteri di Azure.

  • Ad esempio, se sono presenti requisiti di residenza dei dati, è necessario applicare un criterio per limitare le aree di distribuzione disponibili.

• Definire criteri di progettazione comuni per acquisire definizioni di configurazione sicure e affidabili per tutti i servizi di Azure usati, assicurando che questi criteri vengano mappati alle assegnazioni di Criteri di Azure per applicare la conformità.

  • Ad esempio, applicare un Criteri di Azure per applicare l'uso di zone di disponibilità per tutti i servizi pertinenti, garantendo configurazioni di distribuzione affidabili all'interno dell'area.

L'implementazione di riferimento Mission Critical contiene un'ampia gamma di criteri incentrati sulla sicurezza e sull'affidabilità per definire e applicare criteri di progettazione comuni di esempio.

• Monitorare la deriva della configurazione del servizio, in relazione ai criteri di progettazione comuni, usando Criteri di Azure.

Per scenari cruciali con più sottoscrizioni di produzione in un gruppo di gestione dedicato, assegnare priorità alle assegnazioni nell'ambito del gruppo di gestione.

• Usare i criteri predefiniti, se possibile, per ridurre al minimo il sovraccarico operativo della gestione delle definizioni di criteri personalizzate.

• Se sono necessarie definizioni di criteri personalizzate, assicurarsi che le definizioni vengano distribuite nell'ambito del gruppo di gestione appropriato per consentire il riutilizzo tra le sottoscrizioni di ambiente incluse per consentire il riutilizzo dei criteri tra ambienti di produzione e ambienti inferiori.

  • Quando si allinea la roadmap dell'applicazione alle roadmap di Azure, usare le risorse Microsoft disponibili per esplorare se le definizioni personalizzate critiche potrebbero essere incorporate come definizioni predefinite.

Nota

Quando si esegue la distribuzione all'interno di una zona di destinazione di Azure, è consigliabile distribuire definizioni di Criteri di Azure personalizzate nell'ambito del gruppo di gestione radice aziendale intermedio per abilitare il riutilizzo in tutte le applicazioni all'interno dell'ambiente Azure più ampio. In un ambiente di zona di destinazione, alcuni criteri di sicurezza centralizzati verranno applicati per impostazione predefinita all'interno di ambiti di gruppi di gestione più elevati per applicare la conformità alla sicurezza nell'intero ambiente di Azure. Ad esempio, i criteri di Azure devono essere applicati per distribuire automaticamente le configurazioni software tramite le estensioni della macchina virtuale e applicare una configurazione della macchina virtuale di base conforme.

• Usare Criteri di Azure per applicare uno schema di assegnazione di tag coerente nell'applicazione.
  • Identificare i tag di Azure necessari e usare la modalità dei criteri di accodamento per applicare l'utilizzo.

Se l'applicazione è sottoscritta al supporto microsoft mission-critical, assicurarsi che lo schema di assegnazione di tag applicato fornisca un contesto significativo per arricchire l'esperienza di supporto con una comprensione approfondita delle applicazioni.

• Esportare i log attività di Microsoft Entra nell'area di lavoro Log Analytics globale usata dall'applicazione.
  • Assicurarsi che i log attività di Azure siano archiviati nell'account di archiviazione globale insieme ai dati operativi per la conservazione a lungo termine.

In una zona di destinazione di Azure, i log attività di Microsoft Entra verranno inseriti anche nell'area di lavoro Log Analytics centralizzata della piattaforma. Deve essere valutato in questo caso se Microsoft Entra ID è ancora necessario nell'area di lavoro Log Analytics globale.

• Integrare le informazioni di sicurezza e la gestione degli eventi con Microsoft Defender per il cloud (in precedenza noto come Centro sicurezza di Azure).

Considerazioni specifiche di IaaS quando si usa Macchine virtuali

Negli scenari in cui è necessario l'uso di Macchine virtuali IaaS, è necessario prendere in considerazione alcune specifiche.

Considerazioni relative alla progettazione

• Le immagini non vengono aggiornate automaticamente dopo la distribuzione.
• Gli aggiornamenti non vengono installati automaticamente per l'esecuzione di macchine virtuali.
• Le immagini e le singole macchine virtuali in genere non sono predefinite.

Suggerimenti per la progettazione

• Non consentire l'accesso diretto tramite Internet pubblico per Macchine virtuali fornendo l'accesso a SSH, RDP o altri protocolli. Usare sempre Azure Bastion e jumpbox con accesso limitato a un piccolo gruppo di utenti.
• Limitare la connettività Internet diretta usando gruppi di sicurezza di rete, firewall di Azure o gateway applicazione (livello 7) per filtrare e limitare il traffico in uscita.
• Per le applicazioni multilivello è consigliabile usare subnet diverse e usare i gruppi di sicurezza di rete per limitare l'accesso tra di loro.
• Classificare in ordine di priorità l'uso dell'autenticazione a chiave pubblica, quando possibile. Archiviare i segreti in una posizione sicura, ad esempio Azure Key Vault.
• Proteggere le macchine virtuali usando l'autenticazione e il controllo di accesso.
• Applicare le stesse procedure di sicurezza descritte per gli scenari di applicazioni cruciali.

Seguire e applicare le procedure di sicurezza per scenari di applicazioni cruciali, come descritto in precedenza, se applicabile, nonché le procedure consigliate per la sicurezza per i carichi di lavoro IaaS in Azure.

Passaggio successivo

Esaminare le procedure consigliate per le procedure operative per scenari di applicazioni cruciali.

Procedure operative