Considerazioni sulla sicurezza per carichi di lavoro cruciali in Azure

  • Articolo

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

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

È anche importante notare che ci sono spesso compromessi significativi associati a una postura 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 (NVA) per le funzionalità NGFW (Next-Generation Firewall), ad esempio l'ispezione approfondita dei pacchetti, introduce una significativa penalità delle prestazioni, una complessità operativa aggiuntiva 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 minacce chiave siano progettati anche per supportare la destinazione di affidabilità di un'applicazione, che formerà un aspetto fondamentale delle raccomandazioni e delle considerazioni presentate all'interno di 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 mission-critical?

Logo GitHubMission-Critical open source progetto

Le implementazioni di riferimento fanno parte di un progetto di 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 al modello di 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 impegna a verificare in modo esplicito e continuo ogni transazione, affermare privilegi minimi, usare intelligenza e rilevamento avanzato per rispondere alle minacce in tempo quasi in tempo reale. È in definitiva incentrato sull'eliminazione dell'attendibilità all'interno e all'esterno dei perimetrali 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, quanto spesso viene eseguito un test di sicurezza specifico?
    • I risultati dei test vengono misurati con un comportamento di sicurezza desiderato e un modello di minaccia?

  • Livello di sicurezza in tutti gli ambienti inferiori.

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

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

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

  • Conformità e correzione automatica della sicurezza.

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

  • Analisi privata per rilevare i segreti prima del commit del codice per impedire eventuali perdite segrete tramite repository di codice sorgente.

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

  • Proteggere la catena di fornitura software.

    • È possibile tenere traccia delle vulnerabilità e delle esposizione comuni all'interno delle dipendenze del pacchetto usate?
    • Esiste un processo automatizzato per l'aggiornamento delle dipendenze del pacchetto?

  • Ciclo di vita delle chiavi di protezione dei dati.

    • È possibile usare chiavi gestite dal servizio per la protezione dell'integrità dei dati?
    • Se sono necessarie chiavi gestite dal cliente, come è sicuro e affidabile il ciclo di vita delle chiavi?

  • Gli strumenti CI/CD devono richiedere Microsoft Entra entità servizio con accesso a livello di sottoscrizione sufficiente per facilitare l'accesso al piano di controllo per le distribuzioni delle 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.
      • In questo modo viene introdotta 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 correzionata o vietata dal piano di controllo in fase di configurazione, consentendo di attenuare le minacce associate agli scenari di 'amministratore dannoso'.

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

  • 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 di gestione delle identità per la comunicazione da servizio a servizio.

  • Usare Microsoft Entra controllo degli accessi in base al ruolo 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 sicuri per consentire un'esperienza degradata ma disponibile se la piattaforma identity scelta non è disponibile o è disponibile solo parzialmente per l'autorizzazione dell'applicazione.

    • Se il provider non riesce a rilasciare 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 pipeline CI/CD automatizzate per l'infrastruttura come codice (IaC) per guidare gli 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 devono essere direttamente disponibili per qualsiasi team di servizio.
    • Applicare il controllo degli accessi in base al ruolo granulare alle pipeline CD di produzione per attenuare i rischi di "amministratore dannoso".
    • Prendere in considerazione l'uso di cancelli di approvazione manuali all'interno delle pipeline di distribuzione di produzione per ridurre ulteriormente i rischi di "amministratore dannoso" e fornire ulteriore garanzia tecnica per tutte le modifiche di produzione.
      • I cancelli di sicurezza aggiuntivi possono venire a un compromesso in termini di agilità e devono essere valutati attentamente, tenendo conto del modo in cui 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à chiave siano attenuate.

    • Non applicare lo stesso comportamento di sicurezza dell'ambiente di produzione, in particolare per quanto riguarda l'esfiltrazione dei dati, a meno che i requisiti normativi non richiedano tale comportamento, poiché ciò compromette significativamente l'agilità degli sviluppatori.

  • Abilitare Microsoft Defender per Cloud (in precedenza noto come Centro sicurezza di Azure) per tutte le sottoscrizioni che contengono le risorse per un carico di lavoro critico.

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

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

    • I risultati dei test devono essere misurati con un comportamento di sicurezza conforme per informare le approvazioni di rilascio, essere automatizzate o manuali.
    • Applicare test di sicurezza come parte del processo di produzione CD per ogni versione.
      • Se il test di sicurezza ogni versione compromette l'agilità operativa, assicurarsi che venga applicata una cadenza di test di sicurezza appropriata.

  • Abilitare l'analisi privata 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 per la progettazione della sicurezza, usando potenziali minacce identificate per sviluppare mitigazioni di sicurezza appropriate. Esistono molte possibili minacce con probabilità diverse di occorrenza e in molti casi le minacce possono concatenare 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 alle applicazioni cloud cruciali. Si prevede che il processo di modellazione delle minacce per un'applicazione critica sia complessa e senza problemi.

Per esplorare queste sfide, è consigliabile applicare un approccio approfondito alla difesa a 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 fondamentali.
  2. Architettura dell'applicazione e progettazione della sicurezza.
  3. Funzionalità di sicurezza predefinite, abilitate e distribuite applicate alle risorse di Azure sicure.
  4. Codice applicazione e logica di sicurezza.
  5. Processi operativi e DevSecOps.

Nota

Quando si distribuisce all'interno di una zona di destinazione di Azure, tenere presente che un livello di mitigazione delle minacce aggiuntivo 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 di 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à
    • Authentication
  • 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 dannoso.
    • Controllo/registrazione
    • per la firma
  • Divulgazione delle informazioni: 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 dell'applicazione dannosa per ridurre l'esperienza utente. Ad esempio, un attacco di botnet DDoS, ad esempio Slowloris.
    • DDoS
    • Botnet
    • Funzionalità della rete CDN e WAF
  • Elevazione dei privilegi: acquisizione dell'accesso con privilegi dell'applicazione tramite exploit di autorizzazione. Ad esempio, un utente malintenzionato modifica una stringa DI 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.

  • Lo sforzo consapevole deve essere applicato per garantire che le mitigazioni della sicurezza vengano acquisite all'interno di criteri di progettazione comuni per guidare la coerenza in tutti i team del servizio applicazioni.

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

Protezione delle intrusioni di rete

La prevenzione dell'accesso non autorizzato a un'applicazione critica e i dati inclusi sono fondamentali per mantenere la disponibilità e proteggere l'integrità dei dati.

Considerazioni relative alla progettazione

  • Zero Trust presuppone uno stato violato e verifica ogni richiesta come se proviene da una rete incontrollata.

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

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

    • collegamento privato di Azure/Endpoint privati forniscono accesso dedicato a una risorsa PaaS di Azure usando indirizzi IP privati e connettività di rete privata.
    • Rete virtuale Endpoint 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, è necessario un canale di rete sicuro per le pipeline di distribuzione per accedere sia al piano di controllo di Azure che al piano dati delle risorse di Azure per distribuire e gestire l'applicazione.

    • Gli agenti di compilazione self-hosted privati distribuiti in una rete privata come risorsa di Azure possono essere usati come proxy per eseguire funzioni CI/CD tramite una connessione privata. Deve essere usata una rete virtuale separata per gli agenti di compilazione.
      • È 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 all'interno della pipeline per consentire una connessione da un indirizzo IP pubblico dell'agente Azure DevOps, con il firewall successivamente rimosso dopo il completamento dell'attività.
      • Tuttavia, questo approccio è applicabile solo per un subset di servizi di Azure. Ad esempio, questo non è possibile per i cluster del servizio Azure Kubernetes privati.
    • Per eseguire attività di sviluppo e amministrazione nei jump box 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.

  • Il servizio Connections con un'entità servizio Microsoft Entra corrispondente può essere usata in Azure DevOps per applicare il controllo degli accessi in base al ruolo tramite Microsoft Entra ID.

  • I tag di 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 dei 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 l'applicazione per soddisfare lo scopo aziendale di ridurre la superficie di attacco esterna.

  • Quando si tratta di 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 sono necessari requisiti aggiuntivi per la sicurezza della rete in linea, ad esempio l'ispezione avanzata dei pacchetti o l'ispezione TLS, imporre l'uso di Firewall di Azure Appliance virtuale premium o rete virtuale (NVA), assicurarsi che sia configurato per la massima disponibilità elevata e ridondanza.

  • Se esistono requisiti di acquisizione pacchetti, usare 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 il traffico dell'applicazione micro-segmento.

    • Evitare di usare un'appliance di sicurezza per filtrare i flussi di traffico intra-applicazione.
    • Prendere in considerazione 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 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 disponibilità collegamento privato di Azure.

  • 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 del servizio di rete virtuale per impostazione predefinita in tutte le subnet, perché in questo modo verranno introdotti canali di esfiltrazione dei dati significativi.

  • Per scenari di applicazioni ibride, accedere ai servizi PaaS di Azure da locale tramite ExpressRoute con peering privato.

Nota

Quando si distribuisce all'interno di un'area 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 una vasta gamma di minacce. Questa sezione fornisce pertanto considerazioni chiave e raccomandazioni relative alla crittografia e alla gestione delle chiavi per proteggere i dati senza compromettere l'affidabilità dell'applicazione.

Considerazioni relative alla progettazione

  • Azure Key Vault ha 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 poiché le autorizzazioni di accesso per chiavi, segreti e certificati vengono applicate a livello di insieme di credenziali.

    • I criteri di accesso di Key Vault concedono autorizzazioni separate per chiavi, segreti o certificati.

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

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

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

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

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

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

  • Se il collegamento privato viene usato per connettersi ad Azure Key Vault, può richiedere fino a 20 minuti per ripristinare la connessione durante un failover a livello di area.

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

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

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

  • I controlli normativi possono stabilire l'uso delle chiavi gestite dal cliente per la funzionalità di crittografia dei servizi.

  • Quando il traffico si sposta tra i 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 le attività operative, ad esempio la rotazione delle chiavi.

    • Usare solo chiavi gestite dal cliente quando esiste un requisito normativo chiaro a tale scopo.

  • 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 HSM supportato da Azure Key Vault SKU 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, fornendo vantaggi per l'isolamento degli errori e le prestazioni attraverso la localizzazione, nonché l'esplorazione dei limiti di scalabilità imposti da una singola istanza di Key Vault.

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

  • Seguire un modello di privilegio minimo limitando l'autorizzazione per eliminare definitivamente segreti, chiavi e certificati per i ruoli personalizzati personalizzati Microsoft Entra.

  • Assicurarsi che le chiavi di crittografia e i certificati archiviati all'interno di Key Vault vengano sottoposti a backup, fornendo una copia offline nell'evento improbabile Key Vault diventa non 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 gli avvisi per l'utilizzo imprevisto all'interno di Monitoraggio di Azure.

Governance basata sui criteri

Le convenzioni di sicurezza sono in definitiva valide solo se vengono applicate in modo coerente e olistico in tutti i servizi e i team dell'applicazione. Criteri di Azure fornisce un framework per applicare le baseline di sicurezza e affidabilità, garantendo una conformità continua con criteri di progettazione comuni per un'applicazione critica. 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 autorizzate che gli utenti autorizzati possono eseguire e possono essere usati per applicare convenzioni di sicurezza e affidabilità vitali tra i servizi della piattaforma usati.

Questa sezione esaminerà pertanto le considerazioni principali e le raccomandazioni relative all'uso di Criteri di Azure governance guidata per un'applicazione critica, garantendo che vengano applicate continuamente convenzioni di sicurezza e affidabilità.

Considerazioni relative alla progettazione

  • Criteri di Azure fornisce un meccanismo per guidare 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 distribuisce all'interno di un'area di destinazione di Azure, tenere presente che l'imposizione delle assegnazioni di criteri di base centralizzate verrà probabilmente applicata nell'implementazione per i gruppi e le sottoscrizioni della zona di destinazione.

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

    • Registrazione del provider di risorse.
    • Convalida e approvazione di 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 qualsiasi ambito specifico.

  • L'esecuzione dei criteri Deploy If Not Exist (DINE) può richiedere diversi 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, un criterio deve essere applicato 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 tra aree affidabili.

L'implementazione di riferimento Mission Critical contiene una vasta gamma di criteri di sicurezza e affidabilità incentrati 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 dei 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 dell'ambiente incluse per consentire il riutilizzo dei criteri tra ambienti di produzione e inferiori.

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

Nota

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

  • Usare Criteri di Azure per applicare uno schema 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 di Microsoft Mission-Critical, assicurarsi che lo schema di tag applicato fornisca un contesto significativo per arricchire l'esperienza di supporto con informazioni approfondite sull'applicazione.

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

In un'area di destinazione di Azure, Microsoft Entra i log attività verranno inseriti anche nell'area di lavoro Log Analytics centralizzata della piattaforma. È necessario valutare in questo caso se Microsoft Entra ID sono ancora necessari nell'area di lavoro log analytics globale.

  • Integrare le informazioni di sicurezza e la gestione degli eventi con Microsoft Defender per Cloud (in precedenza nota 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, alcune specifiche devono essere prese in considerazione.

Considerazioni relative alla progettazione

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

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 (Azure) o gateway applicazione (livello 7) per filtrare e limitare il traffico in uscita.
  • Per le applicazioni a più livelli è consigliabile usare subnet diverse e usare gruppi di sicurezza di rete per limitare l'accesso tra.
  • Assegnare priorità all'uso dell'autenticazione a chiave pubblica, quando possibile. Archiviare i segreti in un luogo sicuro come Azure Key Vault.
  • Proteggere le macchine virtuali usando l'autenticazione e il controllo di accesso.
  • Applicare le stesse procedure di sicurezza descritte per 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