L'Framework di Microsoft Azure Well-Architected Framework è un set di principi guida che possono essere usati per valutare una soluzione attraverso i pilastri di qualità dell'eccellenza dell'architettura:
Questo articolo termina questa serie. Leggere l'introduzione.
Queste linee guida fornite in questa serie incorporano principi ben architettati in tutte le scelte di progettazione. Questo articolo riepiloga tali scelte. L'implementazione di GitHub: cluster baseline del servizio Azure Kubernetes (AKS) per i carichi di lavoro regolamentati illustra tali principi, a seconda delle esigenze.
I carichi di lavoro PCI DSS 3.2.1 richiedono il rigore di essere una soluzione ben progettata. Anche se l'allineamento dell'infrastruttura ai requisiti PCI è fondamentale, la conformità non si arresta nell'infrastruttura di hosting. Non affrontare i pilastri della qualità, in particolare la sicurezza, può compromettere la conformità. Le soluzioni ben architettate combinano sia l'infrastruttura che le prospettive del carico di lavoro per arrivare al rigore necessario per ottenere risultati conformi.
Affidabilità
L'affidabilità degli ambienti regolamentati deve essere prevedibile in modo che possano essere spiegate in modo coerente a scopo di controllo. Seguire le indicazioni fondamentali fornite nei principi di affidabilità. Le procedure consigliate per un ambiente regolamentato sono riepilogate in queste sezioni.
Destinazioni di ripristino e ripristino di emergenza
A causa della natura sensibile dei dati gestiti nei carichi di lavoro regolamentati, gli obiettivi di ripristino e gli obiettivi del punto di ripristino (RPO) sono fondamentali da definire. Qual è la perdita accettabile di CHD? Le attività di ripristino all'interno dell'ambiente CDE sono ancora soggette ai requisiti standard. Aspettarsi errori e disporre di un piano di ripristino chiaro per gli errori allineati a ruoli, responsabilità e accesso giustificato ai dati. I problemi relativi al sito live non sono giustificati per la deviazione da eventuali normative. Ciò è particolarmente importante in una situazione di ripristino di emergenza completa. Avere una documentazione chiara sul ripristino di emergenza conforme ai requisiti e ridurre al minimo l'accesso CDE o CHD imprevisto. Dopo il ripristino, esaminare sempre i passaggi del processo di ripristino per assicurarsi che non si sia verificato alcun accesso imprevisto. Documentare le motivazioni aziendali per tali istanze.
Ripristino
L'aggiunta di strategie di resilienza e ripristino all'architettura può impedire l'esigenza di accesso ad hoc all'ambiente CDE. Il sistema deve essere in grado di eseguire il ripristino automatico in corrispondenza dell'RPO definito senza la necessità di intervento diretto dell'uomo. In questo modo, è possibile eliminare l'esposizione non necessaria del CHD, anche a coloro che sono autorizzati ad avere accesso di emergenza. Il processo di ripristino deve essere controllabile.
Affrontare i rischi correlati alla sicurezza
Esaminare i rischi per la sicurezza perché possono essere una fonte di tempo di inattività del carico di lavoro e perdita di dati. Gli investimenti nella sicurezza hanno anche un impatto sull'affidabilità del carico di lavoro.
Processi operativi
L'affidabilità si estende a tutti i processi operativi in e adiacenti all'ambiente CDE. Processi ben definiti, automatizzati e testati per problemi come la creazione di immagini e il fattore di gestione jump box in una soluzione ben progettata.
Sicurezza
Seguire le indicazioni fondamentali fornite nei principi di progettazione della sicurezza. Le procedure consigliate per un ambiente regolamentato sono riepilogate in queste sezioni.
Governance
L'implementazione della governance è guidata dai requisiti di conformità in PCI-DSS 3.2.1. Ciò influisce sui controlli tecnici per mantenere la segmentazione, l'accesso alle risorse, il rilevamento delle vulnerabilità e la protezione più importante dei dati dei clienti.
Strategia di segmentazione aziendale
Per mantenere l'isolamento completo, è consigliabile distribuire l'infrastruttura regolamentata in una sottoscrizione autonoma. Se sono necessarie più sottoscrizioni per la conformità, è consigliabile raggrupparle in una gerarchia di gruppi di gestione che applica i criteri di Azure pertinenti in modo uniforme nelle sottoscrizioni nell'ambito. All'interno della sottoscrizione applicare i criteri di Azure correlati a livello di sottoscrizione per acquisire i criteri generali che devono essere applicati a tutti i cluster nell'ambiente dei dati dei titolari di schede. Applicare criteri di Azure correlati a livello di gruppo di risorse per acquisire i criteri applicabili a un'istanza del cluster specifica. Questi criteri definiscono le protezioni primarie di una zona di destinazione.
Isolare il carico di lavoro PCI (nell'ambito) da altri carichi di lavoro (fuori ambito) in termini di operazioni e connettività. È possibile creare l'isolamento distribuendo cluster separati. In alternativa, usare strategie di segmentazione per mantenere la separazione. Ad esempio, i cluster usano pool di nodi separati in modo che i carichi di lavoro non condividono mai una macchina virtuale (VM).
Applicazione dei criteri
Applicare i controlli di sicurezza abilitano i criteri di Azure. In questa architettura regolamentata, ad esempio, è possibile evitare errori di configurazione dell'ambiente dati dei titolari di schede. È possibile applicare criteri di Azure che non consentono allocazioni di indirizzi IP pubblici nei nodi della macchina virtuale. Tali allocazioni vengono rilevate e segnalate o bloccate.
Per informazioni sui criteri che è possibile abilitare per il servizio Azure Kubernetes, consultare la sezione Criteri di Azure definizioni predefinite per servizio Azure Kubernetes.
Azure offre diversi criteri predefiniti per la maggior parte dei servizi. Esaminare queste definizioni dei criteri di Azure predefinite e applicarle in base alle esigenze.
Monitoraggio della conformità
La conformità deve essere sistematicamente monitorata e mantenuta. Vengono eseguite attestazioni regolari della conformità. Sapere se le risorse cloud sono conformi consentirà di prepararsi per le attestazioni e il controllo.
Sfrutta i vantaggi della dashboard di conformità alle normative in Microsoft Defender per il cloud. Monitorando continuamente la dashboard, è possibile tenere traccia dello stato di conformità del carico di lavoro.
Sicurezza di rete
In una topologia hub-spoke, la presenza di reti virtuali separate per ogni entità fornisce la segmentazione di base nel footprint di rete. Ogni rete viene ulteriormente segmentata in subnet.
Il cluster AKS costituisce il nucleo dell'ambiente cde. Non deve essere accessibile dagli indirizzi IP pubblici e la connettività deve essere protetta. I flussi tipici all'ingresso e all'esterno dell'ambiente CDE possono essere classificati come:
- Traffico in ingresso verso il cluster.
- Traffico in uscita dal cluster.
- Traffico in-cluster tra i pod.
Per soddisfare i requisiti di un ambiente regolamentato, il cluster viene distribuito come cluster privato. In questa modalità, il traffico da e verso Internet pubblico è limitato. Anche la comunicazione con il server API Kubernetes gestito dal servizio Azure Kubernetes è privata. La sicurezza è ulteriormente migliorata con controlli di rete rigorosi e regole del firewall IP.
- Gruppi di sicurezza di rete (NSGs) per aiutare a proteggere la comunicazione tra le risorse all'interno di una rete.
- Firewall di Azure per filtrare il traffico in uscita tra le risorse cloud, Internet e in locale.
- Gateway applicazione di Azure integrato con Azure Web Application Framework per filtrare tutto il traffico in ingresso da Internet che Gateway applicazione di Azure intercetta.
- Kubernetes NetworkPolicy per consentire solo determinati percorsi tra i pod nel cluster.
- Collegamento privato di Azure per connettersi ad altri servizi PaaS (Platform as a Service) di Azure, ad esempio Azure Key Vault e Registro contenitori di Azure per le attività operative.
I processi di monitoraggio sono disponibili per assicurarsi che il traffico venga trasmesso come previsto e che eventuali anomalie vengano rilevate e segnalate.
Per informazioni dettagliate sulla sicurezza di rete, consultare la sezione Segmentazione di rete.
Sicurezza dei dati
PCI-DSS 3.2.1 richiede che tutti i dati dei titolari di schede (CHD) non siano mai chiari, sia in transito che in archiviazione.
Poiché questa architettura e l'implementazione sono incentrate sull'infrastruttura e non sul carico di lavoro, la gestione dei dati non viene illustrata. Di seguito alcune raccomandazioni ben architettate.
Dati inattivi
I dati devono essere crittografati tramite algoritmi di crittografia standard del settore.
- Non archiviare i dati nell'ambiente del titolare della scheda.
- Crittografare all'esterno del livello di archiviazione.
- Scrivere solo dati crittografati nel supporto di archiviazione.
- Non archiviare le chiavi nel livello di archiviazione.
Tutti i dati in Archiviazione di Azure vengono crittografati e decrittografati usando la crittografia avanzata. Le chiavi di crittografia autogestito sono preferite.
Se è necessario archiviare temporaneamente i dati, applicare le stesse considerazioni a tali dati. È consigliabile abilitare la funzionalità di crittografia host di AKS. È possibile applicare la crittografia dei dati temporanei con criteri di Azure predefiniti.
Quando si sceglie una tecnologia di archiviazione, esplorare le funzionalità di conservazione. Assicurarsi che tutti i dati vengano rimossi in modo sicuro alla scadenza del tempo configurato.
Lo standard richiede anche che i dati di autenticazione sensibili (SAD) non siano archiviati. Assicurarsi che i dati non siano esposti in log, nomi di file, cache e altri dati.
Dati in movimento
Tutte le comunicazioni con le entità che interagiscono con l'ambiente CDE devono essere su canali crittografati.
- È necessario consentire solo il flusso del traffico HTTPS nell'ambiente CDE. In questa architettura, Gateway applicazione di Azure nega tutto il traffico sulla porta 80.
- Preferibilmente, non crittografare e decrittografare i dati all'esterno dell'ambiente CDE. In tal caso, considerare che l'entità faccia parte dell'ambiente CDE.
- All'interno dell'ambiente CDE, fornire comunicazioni sicure tra pod con mTLS. A questo scopo, è possibile scegliere di implementare una mesh di servizi.
- Consentire solo crittografie sicure e TLS 1.2 o versione successiva.
Identità
Quando si progettano i criteri di accesso, seguire questi principi di sicurezza:
- Iniziare con i criteri Zero-Trust. Creare eccezioni in base alle esigenze.
- Concedere i privilegi minimi, sufficiente per completare un'attività.
- Ridurre al minimo l'accesso permanente.
Il controllo degli accessi in base al ruolo (RBAC) di Kubernetes gestisce le autorizzazioni per l'API Kubernetes. AKS supporta i ruoli Kubernetes. AKS è completamente integrato con Microsoft Entra ID. È possibile assegnare le identità di Microsoft Entra ai ruoli e sfruttare anche altre funzionalità.
Accesso zero-trust
RBAC di Kubernetes, RBAC di Azure e i servizi di Azure implementano la negazione di tutti per impostazione predefinita. Eseguire l'override di tale impostazione con cautela, consentendo l'accesso solo alle entità che ne hanno bisogno. Un'altra area per l'implementazione di Zero-Trust consiste nel disabilitare l'accesso SSH ai nodi del cluster.
Privilegi minimi
È possibile usare le identità gestite per le risorse e i pod di Azure e definire l'ambito per le attività previste. Ad esempio, Gateway applicazione di Azure deve avere le autorizzazioni per ottenere segreti (certificati TLS) da Azure Key Vault. Non deve disporre delle autorizzazioni per modificare i segreti.
Riduzione dell'accesso permanente
Ridurre al minimo l'accesso permanente usando l'appartenenza al gruppo just-in-time di Microsoft Entra. Rafforzare il controllo con i criteri di accesso condizionale in Microsoft Entra ID. Questa opzione supporta molti casi d'uso, ad esempio l'autenticazione a più fattori, la limitazione dell'autenticazione ai dispositivi gestiti dal tenant di Microsoft Entra o il blocco di tentativi di accesso atipici.
Gestione dei segreti
Archiviare segreti, certificati, chiavi e password all'esterno dell'ambiente CDE. È possibile usare oggetti segreti Kubernetes nativi o un archivio chiavi gestito, ad esempio Azure Key Vault. L'uso di un archivio gestito consentirà di gestire le attività di gestione dei segreti, ad esempio la rotazione delle chiavi e il rinnovo dei certificati.
Assicurarsi che l'accesso all'archivio chiavi abbia una combinazione di controlli di rete e di accesso. Quando si abilitano le identità gestite, il cluster deve eseguire l'autenticazione in Key Vault per ottenere l'accesso. Inoltre, la connettività all'archivio chiavi non deve essere tramite la rete Internet pubblica. Usare una rete privata, ad esempio collegamento privato.
Ottimizzazione dei costi
Seguire le indicazioni fondamentali fornite nei principi di ottimizzazione costi.
A causa dei requisiti di conformità e dei controlli di sicurezza rigorosi, un compromesso chiaro è il costo. È consigliabile stabilire stime iniziali usando il Calcolatore prezzi.
Di seguito una rappresentazione generale dell'impatto sui costi delle risorse principali usate da questa architettura.
I driver principali sono i set di scalabilità di macchine virtuali che costituiscono i pool di nodi e Firewall di Azure. Un altro collaboratore è Analisi dei log. Sono inoltre previsti costi incrementali associati a Microsoft Defender per il cloud, a seconda della scelta dei piani.
Avere una chiara comprensione di ciò che costituisce il prezzo di un servizio. Azure tiene traccia dell'utilizzo a consumo. Ecco un drill-down di Firewall di Azure per questa architettura.
Il costo associato ad alcune risorse, ad esempio Firewall di Azure, può essere distribuito tra più business unit o applicazioni. Un altro modo per ottimizzare i costi potrebbe essere ospitare un cluster multi-tenant all'interno di un'organizzazione, ottimizzando la densità con la diversità dei carichi di lavoro. Tuttavia, non è consigliabile questo approccio per i carichi di lavoro regolamentati. Assegnare sempre priorità alla conformità e alla segmentazione rispetto ai vantaggi dei costi.
Per mantenere i vincoli di budget, alcuni modi per controllare i costi sono modificando l'infrastruttura del Gateway applicazione di Azure, impostando il numero di istanze per la scalabilità automatica e riducendo l'output del log purché soddisfino ancora il audit trail richiesto da PCI-DSS 3.2.1. Valutare sempre queste scelte rispetto agli altri aspetti della progettazione che consentono di soddisfare il contratto di servizio. Ad esempio, è comunque possibile ridimensionare in modo appropriato per soddisfare i picchi di traffico?
Quando si creano gruppi di risorse di Azure, applicare tag in modo che possano essere monitorati per i costi. Usare strumenti di gestione dei costi come Azure Advisor e Gestione dei costi Microsoft per tenere traccia e analizzare i costi.
Valutare la possibilità di abilitare l'analisi dei costi di AKS per l'allocazione granulare dei costi dell'infrastruttura del cluster da costrutti specifici di Kubernetes.
Eccellenza operativa
Seguire le linee guida fondamentali fornite nei principi di eccellenza operativa. Le procedure consigliate per un ambiente regolamentato sono riepilogate in queste sezioni.
Separazione dei ruoli
L'applicazione di una chiara separazione dei compiti per gli ambienti regolamentati è fondamentale. Avere definizioni di ruoli e responsabilità in base alle esigenze del carico di lavoro e all'interazione con l'ambiente CDE. Ad esempio, potrebbe essere necessario un ruolo SRE (Infrastructure Reliability Engineer) per le operazioni correlate al cluster e ai servizi dipendenti. Il ruolo è responsabile della gestione della sicurezza, dell'isolamento, della distribuzione e dell'osservabilità. Formalizzare tali definizioni e decidere le autorizzazioni necessarie per tali ruoli. Ad esempio, le SRE hanno privilegi elevati per l'accesso al cluster, ma richiedono l'accesso in lettura agli spazi dei nomi dei carichi di lavoro.
Isolamento del carico di lavoro
PCI-DSS 3.2.1 richiede l'isolamento del carico di lavoro PCI da altri carichi di lavoro in termini di operazioni. In questa implementazione, i carichi di lavoro nell'ambito e out-of-scope vengono segmentati in due pool di nodi utente separati. Gli sviluppatori di applicazioni per gli sviluppatori e nell'ambito per carichi di lavoro out-of-scope possono avere set di autorizzazioni diversi. Inoltre, ci saranno controlli di qualità separati. Ad esempio, il codice nell'ambito è soggetto a rispettare la conformità e l'attestazione, mentre il codice non rientra nell'ambito. È anche necessario disporre di pipeline di compilazione e processi di gestione delle versioni separati.
Metadati operativi
Il requisito 12 dello standard PCI DSS 3.2.1 richiede di mantenere le informazioni sull'inventario dei carichi di lavoro e sulla documentazione sull'accesso al personale. È consigliabile usare i tag di Azure perché è possibile raccogliere informazioni sull'ambiente con risorse, gruppi di risorse e sottoscrizioni di Azure.
Gestire le informazioni sulle soluzioni approvate che fanno parte dell'infrastruttura e del carico di lavoro. Include un elenco di immagini delle VM, database e soluzioni di terze parti preferite dall'utente nell'ambiente CDE. È anche possibile automatizzare il processo creando un catalogo di servizi. Offre la distribuzione self-service usando le soluzioni approvate in una configurazione specifica, che è conforme alle operazioni continue della piattaforma.
Osservabilità
Per soddisfare il Requisito 10, l'osservabilità nell'ambiente CDE è fondamentale per la conformità. I log attività forniscono informazioni sulle operazioni correlate alla gestione di account e segreti, alla gestione delle impostazioni di diagnostica, alla gestione del server e ad altre operazioni di accesso alle risorse. Tutti i log vengono registrati con data, ora, identità e altre informazioni dettagliate. Conserva i log per un massimo di un anno configurando i criteri di conservazione e archiviazione dei dati nei log di Monitoraggio di Azure.
Assicurarsi che i log siano accessibili solo dai ruoli che ne hanno bisogno. Analisi dei log e Microsoft Sentinel supportano vari controlli di accesso in base al ruolo per gestire l'accesso audit trail.
Risposta e correzione
I servizi di monitoraggio di Azure, Monitoraggio di Azure e Microsoft Defender per il cloud, possono generare notifiche o avvisi quando rilevano attività anomale. Questi avvisi includono informazioni sul contesto, ad esempio gravità, stato e tempo di attività. Man mano che vengono generati avvisi, avere una strategia di correzione e rivedere lo stato di avanzamento. È consigliabile centralizzare i dati in una soluzione SIEM (Security Information and Event Management) perché l'integrazione dei dati può fornire un contesto di avviso avanzato.
Dalla vista Avvisi di sicurezza in Microsoft Defender per il cloud, è possibile accedere a tutti gli avvisi rilevati Microsoft Defender per il cloud sulle risorse. Per risolvere il problema, è necessario un processo di valutazione. Collaborare con il team di sicurezza per comprendere in che modo gli avvisi pertinenti verranno resi disponibili ai proprietari del carico di lavoro.
Efficienza delle prestazioni
Seguire le indicazioni fondamentali fornite nei principi di efficienza delle prestazioni. Le procedure consigliate per un ambiente regolamentato sono riepilogate in queste sezioni.
Scalabilità
Osservando come l'ambiente si adatta alle richieste mutevoli indicherà il comportamento di runtime previsto dell'ambiente sotto carico elevato. La scalabilità automatica delle risorse nel carico di lavoro ridurrà al minimo l'interazione umana nell'ambiente CDE. Un ulteriore vantaggio di sicurezza riduce sempre la superficie di attacco. È possibile ottimizzare il vantaggio sfruttando le risorse che supportano l'approccio scale-to-zero. Ad esempio, AKS supporta il ridimensionamento dei pool di nodi utente a 0. Per maggiori informazioni, consultare la sezione Ridimensionamento dei pool di nodi utente a 0.
Partizionamento
Il partizionamento è un fattore chiave per l'efficienza delle prestazioni nei carichi di lavoro regolamentati. La presenza di componenti discreti consente una definizione nitida della responsabilità e consente controlli precisi, ad esempio i criteri di rete. Analogamente a qualsiasi strategia di segmentazione, il partizionamento isola i componenti e controlla l'impatto del raggio di esplosione su errori imprevisti o compromissione del sistema.
Architetture di tipo shared-nothing
L'architettura shared-nothing è progettata per rimuovere conflitti tra carichi di lavoro condivisi. Si tratta inoltre di una strategia per rimuovere singoli punti di errore. In un ambiente regolamentato, i componenti devono essere isolati da limiti logici o fisici. In questo modo si allinea all'architettura shared-nothing, con conseguenti vantaggi di scalabilità. Consente inoltre di definire la destinazione dei controlli di sicurezza pertinenti e di funzionalità di controllo più rigorose dei vari componenti.
Carichi di lavoro leggeri
La complessità dei carichi di lavoro è difficile da documentare e controllare. Cercare di semplicità grazie ai vantaggi delle prestazioni e alla facilità di controllo dei requisiti normativi. Riconsiderare le scelte che hanno più ampiezza di quanto necessario, perché aumenta la superficie di attacco e il potenziale di uso improprio o errata configurazione.