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 catastrofico 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à dell'applicazione per essere veramente critica per 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.

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 sulla 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 i principali del servizio Microsoft Entra con accesso sufficiente a livello di sottoscrizione per facilitare l'accesso al piano di gestione 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.
    • Questo introduce una complessità aggiuntiva e richiede una procedura sequenziale nel processo di distribuzione mediante agenti di build privati indispensabili.

Consigli 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 agli scenari di "amministratore dannoso".

• Utilizzare Microsoft Entra Privileged Identity Management (PIM) nelle sottoscrizioni di produzione per revocare l'accesso continuo al piano di controllo degli 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 basato sui ruoli di Microsoft Entra per autorizzare il piano dati con tutti i servizi che supportano questa capacità.

• 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 sicura nella cache dei token per consentire un'esperienza degradata 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 Infrastructure-as-Code (IaC) e le pipeline CI/CD automatizzate per guidare gli aggiornamenti di tutti i componenti dell'applicazione, anche in condizioni di errore.

  • Assicurarsi che le connessioni di servizio degli strumenti CI/CD siano salvaguardate come informazioni sensibili e critiche e non siano direttamente disponibili a qualsiasi gruppo di servizi.
  • Applicare il controllo degli accessi in base al ruolo granulare alle pipeline CD di produzione per ridurre i rischi associati a un amministratore malevolo.
  • 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.
    • Cancelli di sicurezza aggiuntivi possono implicare 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 for 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 garantire 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 assetto di sicurezza conforme per informare le approvazioni del rilascio, siano esse automatizzate 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.

Considerazioni sulla progettazione

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

• Identità di spoofing: imitazione di persone con autorità. Ad esempio, un utente malintenzionato che si spaccia per un altro utente usando le sue credenziali.
  • Identità
  • Autenticazione
• Manomissione dell'input: modifica dell'input inviato all'applicazione o violazione delle barriere di fiducia 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
  • Validazione
  • Lista di blocco/lista di autorizzazione
• Confutazione dell'azione: abilità di confutare azioni già intraprese e capacità dell'applicazione di raccogliere prove e promuovere 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 remoto
  • Autorizzazione
  • Isolamento

Consigli 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 sulla 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 impiega micro-segmentazione e micro-perimetri distribuiti per l'ingresso e l'uscita.

• 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.

  • I collegamenti privati/endpoint privati di Azure forniscono accesso dedicato a una risorsa PaaS di Azure usando indirizzi IP privati e connettività di rete privata.
  • Gli endpoint servizio di rete virtuale forniscono l'accesso a livello di servizio dalle subnet selezionate ai servizi PaaS selezionati.
  • L'inserimento di reti virtuali offre distribuzioni private dedicate per i servizi supportati, ad esempio il servizio app tramite un ambiente del servizio app.
    • Il traffico del piano di gestione passa comunque attraverso indirizzi IP pubblici.

• Per i servizi supportati, il collegamento privato di Azure tramite 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 all'interno di una rete privata come risorse di Azure possono essere usati 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 AKS privati.
  • Per eseguire attività di sviluppo e amministrative sul servizio applicazioni, è possibile utilizzare i jump box.

• 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 principale del servizio Microsoft Entra corrispondente possono essere usate all'interno di Azure DevOps per applicare il Controllo degli Accessi Basato sui Ruoli 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.

Consigli 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 alle macchine virtuali di Azure e per eseguire attività amministrative in PaaS di Azure 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 delle applicazioni pubbliche in modo che accettino solo il traffico proveniente dall'istanza di Azure Front Door.

• Se sono necessari ulteriori requisiti di sicurezza della rete in linea, ad esempio l'ispezione approfondita dei pacchetti o l'ispezione TLS, impone l'uso di un'Appliance virtuale di rete o di Firewall Premium di Azure, assicurarsi che sia configurato per la massima alta disponibilità 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.
  • Prendere in considerazione l'uso dei Criteri di Azure per garantire che regole specifiche del gruppo di sicurezza di rete siano sempre associate alle subnet delle applicazioni.

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

• Usare Collegamento privato di Azure/Endpoint 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 gli endpoint servizio di rete virtuale per proteggere l'accesso ai servizi PaaS di Azure dall'interno di una rete virtuale.

  • Non abilitare gli endpoint del servizio di rete virtuale di default su tutte le subnet, perché verranno introdotti canali significativi di esfiltrazione dati.

• Per gli scenari di applicazioni ibride, accedere ai servizi PaaS di Azure dall'ambiente locale tramite ExpressRoute con 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 sulla 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 perimetro di sicurezza poiché le autorizzazioni di accesso per chiavi, segreti e certificati vengono applicate a livello di insieme di chiavi.

  • Le assegnazioni dei criteri di accesso di Key Vault concedono le autorizzazioni separatamente a 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 il failover, il Key Vault sarà in modalità di sola lettura, quindi non sarà possibile modificare le proprietà del Key Vault, come 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 un'istantanea a un punto nel tempo di un segreto, di una chiave o di un certificato, come blob crittografato che non può essere decrittografato al di fuori di Azure. Per ottenere dati utilizzabili dal BLOB, è necessario ripristinarli in un Key Vault all'interno della stessa sottoscrizione di Azure e nella stessa area geografica di Azure.

  • I segreti possono essere rinnovati durante un backup, causando un disallineamento.

• 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.

Consigli 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.

  • Effettua il provisioning di Azure Key Vault con i criteri di eliminazione temporanea e ripulitura abilitati per consentire la protezione dei dati 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 ciascun punto di distribuzione regionale, offrendo isolamento dei guasti e miglioramento delle prestazioni grazie alla localizzazione, oltre a gestire 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.

• Seguendo un modello di privilegi minimi, limitare l'autorizzazione per eliminare definitivamente segreti, chiavi e certificati a ruoli personalizzati di Microsoft Entra.

• 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 di Key Vault per gestire l'approvvigionamento e la firma dei certificati.

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

  • Automatizzare il processo di gestione e rinnovo dei certificati con le 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 guidata da politiche

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. Azure Policy offre un framework per applicare baseline di sicurezza e affidabilità, garantendo una conformità continua con criteri ingegneristici comuni per un'applicazione mission-critical. In particolare, Azure Policy costituisce una parte fondamentale del piano di controllo di Azure Resource Manager (ARM), integrando RBAC limitando le azioni che gli utenti autorizzati possono eseguire e può essere utilizzato per applicare convenzioni di sicurezza e affidabilità vitali nei servizi della piattaforma utilizzati.

Questa sezione esaminerà quindi le considerazioni chiave e le raccomandazioni relative all'uso della governance guidata da Criteri di Azure per un'applicazione cruciale, assicurando che vengano applicate continuamente convenzioni di sicurezza e affidabilità.

Considerazioni sulla progettazione

• Azure Policy offre un meccanismo per favorire la conformità con le normative imponendo convenzioni di sicurezza e affidabilità, ad esempio l'uso di endpoint privati o l'utilizzo delle zone di disponibilità.

• Azure Policy può essere utilizzato per guidare attività di gestione automatica, come il provisioning e la configurazione.

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

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

• Criteri di Azure hanno 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.

• I criteri di Azure forniscono un input critico per la creazione di report sulla conformità e il controllo della sicurezza.

Consigli per la progettazione

• Associare i requisiti normativi e di conformità alle definizioni dei 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 criteri di Azure per applicare l'uso delle 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 deviazione della configurazione del servizio, in relazione ai criteri di progettazione comuni, utilizzando Azure Policy.

Per scenari di importanza critica con più sottoscrizioni di produzione in un gruppo di gestione dedicato, dare 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.

• 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 a Microsoft Mission-Critical Support, assicurarsi che lo schema di assegnazione di tag applicato fornisca un contesto significativo per arricchire l'esperienza di supporto con una conoscenza 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 for Cloud (in precedenza noto come Centro sicurezza di Azure).

Considerazioni specifiche di IaaS quando si usano macchine virtuali

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

Considerazioni sulla 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 rinforzate di default.

Consigli per la progettazione

• Non consentire l'accesso diretto tramite la rete Internet pubblica alle 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 Network Security Groups, firewall di Azure o gateway di applicazione (livello 7 del modello OSI) per filtrare 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.

Passo successivo

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