Secure Azure Computing Architecture (SACA)

I clienti del Dipartimento della Difesa degli Stati Uniti (DoD) che distribuiscono i carichi di lavoro in Azure hanno chiesto indicazioni per configurare reti virtuali sicure e configurare gli strumenti e i servizi di sicurezza stabiliti dagli standard e dalle procedure DoD.

Nel 2017, la Defense Information System Agency (DISA) ha pubblicato il Documento sui requisiti funzionali di SCCA (Secure Cloud Computing Architecture). SCCA descrive gli obiettivi funzionali per la protezione dei punti di connessione di Defense Information System Network (DISN) e del provider di servizi cloud commerciali. SCCA descrive anche come i proprietari della missione proteggono le applicazioni cloud ai limiti di connessione. Ogni entità DoD che si connette al cloud commerciale deve seguire le linee guida indicate in SCCA FRD.

SCCA ha quattro componenti:

  • Punto di Cloud Access perimetrale (BCAP)
  • Virtual Datacenter Security Stack (VDSS)
  • Virtual Datacenter Managed Services (VDMS)
  • Trusted Cloud Credential Manager (TCCM)

Microsoft ha sviluppato una soluzione che consente di soddisfare i requisiti SCCA per i carichi di lavoro DoD IL4 e DoD IL5 eseguiti in Azure. Questa soluzione specifica di Azure è denominata SECURE Azure Computing Architecture (SACA) e può essere utile per la conformità con SCCA FRD. Può consentire di spostare i carichi di lavoro in Azure dopo la connessione.

Le linee guida e le architetture SCCA sono specifiche per i clienti DoD, ma aiutano anche i clienti civili a rispettare le linee guida TIC (Trusted Internet Connections) e aiutano i clienti commerciali che vogliono implementare una rete perimetrale sicura per proteggere gli ambienti Azure.

Proteggere i componenti dell'architettura di cloud computing

Punto di Cloud Access perimetrale (BCAP)

Lo scopo di BCAP è quello di proteggere il diSN dagli attacchi originato nell'ambiente cloud. BCAP esegue il rilevamento e la prevenzione delle intrusioni. Filtra anche il traffico non autorizzato. Questo componente può essere colocato con altri componenti del SCCA. È consigliabile distribuire questo componente usando l'hardware fisico. I requisiti di sicurezza BCAP sono elencati nella tabella seguente.

Requisiti di sicurezza BCAP

Matrice dei requisiti BCAP.

Virtual Datacenter Security Stack (VDSS)

Lo scopo del VDSS è proteggere le applicazioni mission-owner DoD ospitate in Azure. VDSS esegue la maggior parte delle operazioni di sicurezza in SCCA. Esegue l'ispezione del traffico per proteggere le applicazioni eseguite in Azure. Questo componente può essere fornito all'interno dell'ambiente Azure.

Requisiti di sicurezza di VDSS

Matrice dei requisiti VDSS.

Virtual Datacenter Managed Services (VDMS)

Lo scopo di VDMS è fornire servizi di sicurezza host e data center condivisi. Le funzioni di VDMS possono essere eseguite nell'hub di SCCA o il proprietario della missione può distribuirne parti nella propria sottoscrizione di Azure. Questo componente può essere fornito all'interno dell'ambiente Azure.

Requisiti di sicurezza VDMS

Matrice dei requisiti VDMS.

Trusted Cloud Credential Manager (TCCM)

TCCM è un ruolo aziendale. Questo individuo è responsabile della gestione della SCCA. I loro compiti sono:

  • Stabilire piani e criteri per l'accesso dell'account all'ambiente cloud.
  • Assicurarsi che la gestione delle identità e degli accessi funzioni correttamente.
  • Gestire il piano di gestione delle credenziali cloud.

Questo individuo è nominato dal funzionario di autorizzazione. BCAP, VDSS e VDMS offrono le funzionalità necessarie a TCCM per svolgere il proprio lavoro.

Requisiti di sicurezza TCCM

Matrice dei requisiti di TCCM.

Considerazioni sulla pianificazione e i componenti SACA

L'architettura di riferimento SACA è progettata per distribuire i componenti VDSS e VDMS in Azure e per abilitare TCCM. Questa architettura è modulare. Tutte le componenti di VDSS e VDMS possono risiedere in un centro nevralgico centralizzato o in più reti virtuali. Alcuni controlli possono essere soddisfatti nello spazio del proprietario della missione o anche in loco. Il diagramma seguente illustra questa architettura:

Diagramma dell'architettura che mostra i componenti VDSS e VDMS raggruppati in una rete virtuale centrale.

Quando si pianifica la strategia di conformità SCCA e l'architettura tecnica, prendere in considerazione gli argomenti seguenti fin dall'inizio perché influiscono su ogni cliente. I problemi seguenti sono stati riscontrati con i clienti DoD e tendono a rallentare la pianificazione e l'esecuzione.

Quale BCAP userà la tua organizzazione?

  • DISA BCAP:
    • DISA ha due BCAP di seconda generazione che attualmente operano e gestiscono, con tre nuovi BCAP gen 3 presto disponibili online.
    • I BCAP di DISA hanno tutti circuiti Azure ExpressRoute in Azure, che possono essere usati dai clienti di Enti pubblici e DoD per la connettività.
    • DISA ha una sessione di peering Microsoft di livello aziendale per i clienti che vogliono sottoscrivere strumenti SaaS (Software as a Service) Microsoft, ad esempio Microsoft 365. Usando il DISA BCAP, è possibile abilitare la connettività e il peering con l'istanza SACA.
    • È consigliabile usare DISA BCAP. Questa opzione è prontamente disponibile, ha ridondanza predefinita e ha clienti che operano su di esso oggi nell'ambiente di produzione.
  • Costruisci il tuo BCAP personalizzato:
    • Questa opzione richiede di affittare spazio in un data center colocalizzato e configurare un circuito ExpressRoute per Azure.
    • Questa opzione richiede l'approvazione aggiuntiva del CIO DoD.
    • A causa dell'approvazione aggiuntiva e della costruzione fisica, questa opzione richiede più tempo ed è complesso da ottenere.
  • Spazio IP instradabile DoD:
    • È necessario usare lo spazio di indirizzamento IP instradabile DoD al limite della rete. È disponibile l'opzione per usare NAT per connettere tali spazi allo spazio IP privato in Azure.
    • Per ottenere spazio IP, contattare il Centro informazioni di rete DoD. È necessario come parte del processo di approvazione del sistema/rete (SNAP) nella presentazione a DISA.
    • Se si prevede di usare NAT per connettere lo spazio degli indirizzi privati in Azure, è necessaria almeno una subnet /24 dello spazio indirizzi assegnato dalla NIC per ogni area in cui si prevede di distribuire SACA.
  • Ridondanza:
    • Distribuire un'istanza SACA in almeno due aree per le funzionalità di failover.
    • Connettersi ad almeno due BCAP tramite circuiti ExpressRoute separati. Entrambe le connessioni ExpressRoute possono quindi essere collegate all'istanza SACA di ogni area.
  • Requisiti specifici del componente DoD:
    • L'organizzazione ha requisiti specifici al di fuori dei requisiti SCCA? Alcune organizzazioni hanno requisiti IPS specifici.
  • SACA è un'architettura modulare:
    • Usare solo i componenti necessari per l'ambiente.
      • Distribuire gli appliance virtuali di rete a livello singolo o a livelli multipli.
      • Utilizzare IPS nativi del cloud o personalizzati (bring-your-own IPS).

Quale soluzione automatizzata verrà usata per distribuire VDSS?

Come accennato in precedenza, è possibile compilare il riferimento SACA usando un'ampia gamma di appliance e servizi di Azure. Microsoft ha automatizzato modelli di soluzione per distribuire SACA con servizi nativi o con soluzioni di partner come Palo Alto Networks, F5 e Citrix. Queste soluzioni sono descritte nella sezione seguente.

Quali servizi di Azure verranno usati?

  • Sono disponibili servizi di Azure che possono soddisfare i requisiti per l'analisi dei log, la protezione basata su host e la funzionalità IDS. È possibile che alcuni servizi non siano disponibili a livello generale nelle aree DoD di Microsoft Azure. In questo caso, potrebbe essere necessario usare strumenti di terze parti se questi servizi di Azure non possono soddisfare i requisiti. Esaminare gli strumenti con cui si ha familiarità e la fattibilità dell'uso degli strumenti nativi di Azure.

  • È consigliabile usare il maggior numero possibile di strumenti nativi di Azure. Sono compilati tenendo conto della sicurezza del cloud e si integrano perfettamente con il resto della piattaforma Azure. Usare gli strumenti nativi di Azure nell'elenco seguente per soddisfare vari requisiti di SCCA:

  • Dimensionamento

    • È necessario completare un esercizio di ridimensionamento. Esaminare il numero di connessioni simultanee che potrebbero essere presenti tramite l'istanza SACA e i requisiti di velocità effettiva di rete.
    • Questo passaggio è fondamentale. Consente di ridimensionare le macchine virtuali, i circuiti ExpressRoute e identificare le licenze richieste dai vari fornitori usati nella distribuzione SACA.
    • Una buona analisi dei costi non può essere eseguita senza l'esercizio di dimensionamento. Il dimensionamento corretto consente anche di ottenere prestazioni ottimali.

Scenario di distribuzione più comune

Diversi clienti Microsoft hanno eseguito la distribuzione completa o almeno le fasi di pianificazione degli ambienti SACA. Le esperienze hanno rivelato informazioni dettagliate sullo scenario di distribuzione più comune. Il diagramma seguente illustra l'architettura più comune:

Diagramma dell'architettura di riferimento SACA.

Come si può vedere dal diagramma, i clienti in genere sottoscrivono due dei BCAP DISA. Un peer privato di ExpressRoute è connesso ad Azure in ogni sede BCAP di DISA. Questi peer ExpressRoute vengono quindi collegati al gateway di rete virtuale in ogni area di Azure. Tutto il traffico in ingresso e in uscita passa attraverso SACA, tramite la connessione ExpressRoute al BCAP DISA.

I proprietari delle missioni scelgono quindi le aree di Azure in cui prevedono di distribuire le applicazioni. Usano il peering di rete virtuale per connettere la rete virtuale dell'applicazione alla rete virtuale SACA. Forzano quindi il tunneling di tutto il traffico attraverso l'istanza VDSS.

È consigliabile questa architettura perché soddisfa i requisiti SCCA. È a disponibilità elevata, ridimensiona facilmente e semplifica la distribuzione e la gestione.

Opzioni di distribuzione SACA automatizzate

Come accennato in precedenza, Microsoft ha collaborato con i fornitori per creare modelli di infrastruttura SACA automatizzati. Questi modelli distribuiscono i componenti di Azure seguenti:

  • Rete virtuale SACA
    • Subnet VDMS
      • Questa subnet è la posizione in cui vengono distribuite macchine virtuali e servizi usati per VDMS, incluse le macchine virtuali jumpbox.
    • Subnet non attendibili, affidabili, di gestione o AzureFirewallSubnet
      • Queste subnet sono la posizione in cui vengono distribuite appliance virtuali o Firewall di Azure.
  • Macchine virtuali di accesso per la gestione
    • Vengono usati per la gestione fuori banda dell'ambiente.
  • Appliance virtuali di rete
  • Azure Bastion
    • Bastion viene usato per connettersi in modo sicuro alle macchine virtuali tramite SSL
  • Indirizzi IP pubblici
    • Vengono usati per il front-end fino a quando ExpressRoute non viene portato online. Questi indirizzi IP si traducono nello spazio indirizzi privato del back-end di Azure.
  • Tabelle di instradamento
    • Applicate durante l'automazione, queste tabelle di pianificazione percorso forzano il tunneling di tutto il traffico attraverso l'appliance virtuale tramite il Load Balancer.
  • Servizi di bilanciamento del carico di Azure - SKU Standard
    • Vengono usati per bilanciare il carico del traffico tra le appliance di terze parti.
  • Gruppi di sicurezza di rete
    • Vengono usati per controllare quali tipi di traffico possono attraversare a determinati endpoint.

Distribuzione di Azure SACA

È possibile usare il modello di distribuzione Mission Landing Zone per eseguire la distribuzione in una o più sottoscrizioni, a seconda dei requisiti dell'ambiente. Usa servizi di Azure predefiniti che non hanno dipendenze dalle licenze di terze parti. Il modello usa Firewall di Azure e altri servizi di sicurezza per distribuire un'architettura conforme a SCCA.

Diagramma del modello SACA della zona di destinazione della missione.

Per la documentazione di Azure e gli script di distribuzione, vedere Zona di destinazione della missione.

Distribuzione di "Palo Alto Networks SACA"

Il modello di distribuzione Palo Alto Networks distribuisce da una a molte appliance della serie VM, nonché la messa in scena e il routing VDMS per abilitare un'architettura a un livello unico, conforme a VDSS. Questa architettura soddisfa i requisiti SCCA.

Il diagramma Palo Alto SACA.

Per la documentazione e lo script di distribuzione di Palo Alto Networks, vedere Implementazione di SACA per Palo Alto Networks in Azure.

Distribuzione di SACA di F5 Networks

Due modelli di distribuzione F5 separati coprono due architetture diverse. Il primo modello ha solo un livello di appliance F5 in una configurazione ad alta disponibilità attiva-attiva. Questa architettura soddisfa i requisiti SCCA. Il secondo modello aggiunge un secondo livello di F5 in configurazione attivo-attivo ad alta disponibilità. Questo secondo livello consente di aggiungere il proprio sistema IPS separato da F5 tra i livelli F5. Non tutti i componenti DoD hanno ipS specifici prescritti per l'uso. In tal caso, il singolo livello di appliance F5 funziona per la maggior parte perché tale architettura include IPS nei dispositivi F5.

Diagramma F5 SACA.

Per la documentazione di F5 e lo script di distribuzione, vedere F5 e Azure SACA.

Distribuzione di Citrix SACA

Un modello di distribuzione Citrix distribuisce due livelli di appliance Citrix ADC a disponibilità elevata. Questa architettura soddisfa i requisiti VDSS.

Diagramma di Citrix SACA.

Per la documentazione di Citrix e lo script di distribuzione, vedere Distribuzione basata su SACA.

Passaggi successivi

  • Last updated on