Baseline di governance e sicurezza per soluzione Azure VMware

Questo articolo illustra come stabilire baseline di governance e sicurezza, in modo che ogni soluzione Azure VMware carico di lavoro erediti controlli coerenti e riduca i rischi prima dell'onboarding.

Diagramma che mostra il processo di microsoft Cloud Adoption Framework per l'adozione di soluzione Azure VMware.

Questo articolo aiuta i responsabili decisionali a definire la base di riferimento per la governance e la sicurezza che viene ereditata per impostazione predefinita da ogni carico di lavoro di soluzione Azure VMware. Una baseline è il set minimo di controlli che ogni carico di lavoro di soluzione Azure VMware eredita prima che qualsiasi team di workload effettui l'onboarding. Queste linee di base vengono create e mantenute. Creare controlli aggiuntivi per soddisfare le esigenze dell'organizzazione, ad esempio la conformità alle normative o per gestire i rischi specifici del carico di lavoro.

Le linee guida di base qui presuppongono soluzione Azure VMware Generazione 2 (Gen 2), in cui il cloud privato viene distribuito all'interno di una rete virtuale Azure per impostazione predefinita, offrendo connettività nativa ai servizi di Azure e ai controlli nativi Azure. La generazione 1 (Gen 1) costituisce l'eccezione legacy ed è menzionata esplicitamente solo quando le sue capacità differiscono.

Applicare le stesse baseline di governance e sicurezza agli ambienti non di produzione applicati agli ambienti di produzione. La presenza di baseline coerenti comporta un minor rischio di debolezze nel patrimonio complessivo e semplifica la transizione dei carichi di lavoro da un ambiente a un altro.

Raccomandazione: Determinare la baseline di governance e sicurezza che ogni carico di lavoro soluzione Azure VMware deve ereditare sia nell'ambiente Azure che nel cloud privato VMware prima di eseguire l'onboarding di applicazioni o team operativi.

1. Ambito della baseline di governance

soluzione Azure VMware necessita di governance su due superfici e una linea di base che copre solo una di esse lascia lacune nel controllo e nel rischio.

  • Azure governance: la superficie di Azure è il set di risorse Azure che supportano il cloud privato, ad esempio la sottoscrizione, la rete virtuale, il monitoraggio e le assegnazioni di ruolo Azure. Lo governi con strumenti nativi di Azure.

  • Governance del cloud privato: La superficie VMware è il cloud privato stesso, ad esempio segmenti di rete, criteri firewall, ruoli vCenter e NSX e criteri di archiviazione. La maggior parte di essa viene governata con gli strumenti nativi di VMware all'interno del cloud privato.

Una baseline di governance che risolve solo l'ambiente Azure o solo l'ambiente VMware crea lacune nel controllo operativo e nella gestione dei rischi.

2. Applicazione dei criteri di governance

Applicare i requisiti di base tramite la zona di destinazione della piattaforma quando possibile. Usare processi operativi manuali per supportare l'imposizione quando i controlli tecnici non sono disponibili.

Applicare Criteri di Azure a livello di gruppo di gestione, sottoscrizione o gruppo di risorse per stabilire i requisiti obbligatori per ogni distribuzione soluzione Azure VMware. Usando Criteri di Azure, è possibile garantire la coerenza tra cloud privati soluzione Azure VMware, soprattutto quando si delega l'amministrazione VMware ai proprietari del carico di lavoro. Allineare questi requisiti agli standard già usati nell'ambito più ampio Azure estate. Alcuni criteri e meccanismi di imposizione standard includono:

3. Baseline di sicurezza

Ogni distribuzione di soluzione Azure VMware dovrebbe ereditare una baseline di sicurezza approvata prima dell'onboarding dei carichi di lavoro. Iniziare con la baseline di sicurezza Azure per soluzione Azure VMware, che esegue il mapping delle funzionalità di soluzione Azure VMware al benchmark di sicurezza Microsoft Cloud e fornisce indicazioni sulla sicurezza Microsoft consigliate. Microsoft Defender per il cloud può valutare continuamente l'ambiente in base alle raccomandazioni e ai controlli normativi applicabili. Le definizioni di Criteri di Azure associate ai controlli del benchmark sono visualizzate nell'esperienza Conformità alle normative in Microsoft Defender per il cloud. Vedere soluzione Azure VMware raccomandazioni sulla sicurezza.

4. Baseline di identità di soluzione Azure VMware

soluzione Azure VMware utilizza i servizi di gestione delle identità esistenti, quindi la baseline si riferisce al modo in cui ci si connette e alle risorse, ad esempio le macchine virtuali, anziché distribuire nuovi servizi di identità. Questa baseline si riferisce ai servizi di gestione delle identità usati da soluzione Azure VMware stessa e non influisce sui servizi di identità usati dai singoli carichi di lavoro dell'applicazione in esecuzione in VMware.

4.1 Provider di identità

Usare un'origine di identità esterna per l'accesso a vCenter anziché l'account CloudAdmin predefinito. soluzione Azure VMware supporta sia Microsoft Entra ID che Active Directory (LDAPS) come origini di identità esterne per il server vCenter.

  • Opzione 1. Microsoft Entra ID (scelta consigliata). Le organizzazioni che già standardizzano Microsoft Entra ID devono preferire Entra ID federazione perché centralizza la governance delle identità, l'accesso condizionale e l'autenticazione a più fattori tra Azure e amministrazione VMware.

  • Opzione 2. Active Directory Domain Services tramite LDAPS. Le organizzazioni con dipendenze operative dall'amministrazione VMware integrata Active Directory possono continuare a usare LDAPS. Offre continuità con i flussi di lavoro di amministrazione VMware integrati in ACTIVE Directory esistenti. I controller di dominio di Active Directory vengono eseguiti in Azure centralmente nella sottoscrizione di identità della piattaforma.

4.2 Autorizzazioni utente

Le decisioni di accesso degli utenti stabiliscono le basi per l'amministrazione sicura di soluzione Azure VMware. Prima di eseguire l'onboarding dei team operativi, definire il modo in cui gli amministratori ricevono l'accesso, quali ruoli possono usare e come viene esaminato l'accesso nel tempo.

  • Assegnazione basata su gruppo: Definire i gruppi di amministratori prima dell'onboarding dei team operativi. Assegnare utenti a gruppi e assegnare gruppi ai ruoli. Evitare assegnazioni dirette degli utenti, ad eccezione delle eccezioni temporanee.

  • Ruoli vCenter con privilegi minimi: Usare ruoli vCenter personalizzati quando il ruolo CloudAdmin concede più accesso rispetto alle esigenze di un team. soluzione Azure VMware supporta ruoli personalizzati in vCenter con privilegi uguali o inferiori al ruolo CloudAdmin. Non offre ruoli personalizzati nel portale di soluzione Azure VMware.

  • Parità di NSX Manager: Applicare lo stesso processo di governance dell'accesso a NSX Manager. Definire ruoli amministrativi approvati, applicare privilegi minimi ed eseguire verifiche di accesso periodiche. Non tutti i ruoli NSX predefiniti sono supportati, quindi definire un piccolo set di ruoli NSX approvati ed esaminarli regolarmente.

4.3 Ruolo CloudAdmin

Il ruolo CloudAdmin in soluzione Azure VMware funziona in modo diverso rispetto all'accesso amministrativo VMware on-premises, e considerarlo come un account amministrativo da usare quotidianamente è un errore comune. Considera CloudAdmin come una credenziale di emergenza (“break-glass”), ruotata, monitorata e limitata ai casi di emergenza. Concedere l'accesso giornaliero tramite gruppi di identità esterni mappati a ruoli con privilegi minimi.

  • Solo per emergenze: Non usare l'account CloudAdmin predefinito per l'amministrazione quotidiana o per l'integrazione con servizi. Riservarlo come account break-glass per l'accesso di emergenza. Conserva la credenziale tramite il tuo processo di accesso privilegiato, ruotala secondo una pianificazione definita e genera un avviso in caso di recupero o utilizzo.

  • Nessun accesso a livello host: gli amministratori di soluzione Azure VMware non dispongono dell'account administrator@vsphere.local di vCenter Server né dell'account root di ESXi. Gli amministratori possono tuttavia assegnare Active Directory utenti e gruppi al ruolo CloudAdmin nel server vCenter.

  • Dominio SSO gestito: Il dominio SSO vsphere.local è una risorsa gestita che supporta le operazioni della piattaforma. Non è possibile usarlo per creare o gestire utenti e gruppi locali oltre gli account predefiniti forniti con il cloud privato.

  • Aggiunta di un'origine di identità: Il ruolo CloudAdmin non può aggiungere direttamente un'origine di identità( ad esempio LDAP/LDAPS). Usare i comandi Esegui per aggiungere un'origine di identità esterna e assegnare il ruolo CloudAdmin a utenti e gruppi.

5. Baseline di rete di soluzione Azure VMware

Ogni cloud privato utilizza VMware NSX come livello di rete definito dal software, in sostituzione del modello basato su VLAN di VMware on-premises. I team creano segmenti NSX per i carichi di lavoro, instradano il traffico attraverso gateway NSX di livello 0 e di livello 1 e scrivono regole del firewall distribuite. Pianificare l'approccio alla sicurezza di rete in anticipo e impostare un limite chiaro:

  • Usare NSX per il traffico all'interno dell'ambiente soluzione Azure VMware (east-west).

  • Usare controlli nativi Azure o locali per il traffico che supera il limite soluzione Azure VMware (nord-sud).

5.1 Baseline del traffico est-ovest

I controlli east-west regolano il traffico tra i carichi di lavoro all'interno del cloud privato. Applicare la microsegmentazione con il firewall distribuito NSX per ogni carico di lavoro. Aggiungere vDefend solo quando è necessario un obiettivo di controllo specifico.

  • Opzione 1. Firewall NSX. Usare sempre il firewall distribuito NSX per applicare la microsegmentazione tra i carichi di lavoro. La microsegmentazione limita il movimento laterale se un attaccante riesce a compromettere un workload, ad esempio impedendo a un server web compromesso di raggiungere un database. I team tendono spesso a sottoutilizzare questa funzionalità subito dopo la migrazione, quindi includetela nella configurazione di base.

  • Opzione 2. NSX Firewall e VMware vDefend Firewall. Quando il firewall distribuito non soddisfa un requisito specifico, valutare il componente aggiuntivo facoltativo VMware vDefend Firewall per le funzionalità che NSX da solo non fornisce, ad esempio il rilevamento delle intrusioni e il filtro URL. Adottalo solo quando tali funzionalità corrispondono a un obiettivo di controllo che devi soddisfare.

Applicare lo stesso approccio con privilegi minimi a NSX limitando chi può modificare regole, segmenti e routing del firewall. Implementare il controllo delle modifiche e l'audit, poiché gli aggiornamenti di NSX possono influire sulla connettività condivisa e compromettere più carichi di lavoro.

5.2 Baseline del traffico nord-sud

I controlli nord-sud regolano il traffico che entra e lascia l'ambiente soluzione Azure VMware. Lo strumento corretto dipende dalla progettazione di rete Azure più ampia.

  • Opzione 1.Firewall di Azure o un'appliance virtuale di rete di terze parti. Molte organizzazioni controllano questo traffico con Firewall di Azure o un'appliance virtuale di rete di terze parti posizionata nella sottoscrizione centralizzata della piattaforma "Connettività".

  • Opzione 2.Firewall del gateway NSX nella rete perimetrale. Usare il firewall del gateway NSX nella rete perimetrale soluzione Azure VMware quando si preferisce esaminare i limiti del cloud privato.

  • Opzione 3.Firewall locale. Alcuni instradano internet in uscita attraverso un firewall locale esistente.

In Gen 2, aggiungi i gruppi di sicurezza di rete di Azure (NSG) a livello della rete virtuale di Azure per un ulteriore livello nativo di Azure che si affianca a NSX. Gen 1 non supporta gli NSG.

Se si applicano controlli a più livelli, pianificare come mantenerli coerenti. I controlli suddivisi tra livelli aggiungono complessità, rendono più difficile la risoluzione dei problemi e possono creare percorsi di traffico imprevisti. Se si usano strumenti di rete automatizzati, decidere in anticipo come mantenere sincronizzati i criteri tra VMware e Azure. Documentare i requisiti di connettività di rete del carico di lavoro e verificare che la stessa documentazione e lo stesso processo di notifica delle modifiche vengano usati dagli amministratori VMware e dai team di amministrazione della rete upstream.

6. Riferimento dei costi di soluzione Azure VMware

La governance dei costi definisce i paletti finanziari ereditati da ogni implementazione di soluzione Azure VMware. Come minimo, è necessario disporre di un budget con avvisi, di uno standard obbligatorio per l'assegnazione dei tag e di un approvatore designato per le modifiche di capacità in ogni sottoscrizione di soluzione Azure VMware.

  • Budget e avvisi: Usa Gestione dei costi Microsoft per impostare limiti di budget e avvisi di spesa eccessiva, in modo da individuare tempestivamente eventuali sforamenti di spesa. Richiedere ai team del carico di lavoro di configurare gli avvisi per le soglie di utilizzo di CPU, memoria e vSAN e indirizzare tali avvisi a un proprietario delle operazioni denominato in modo che la risposta non sia ambigua. Impostare centralmente i valori di soglia, ad esempio l'invio di avvisi al 75% dell'utilizzo della CPU per i cluster di produzione, in modo che le decisioni sulla capacità siano basate sugli stessi dati in ogni team. Vedere Configurare gli avvisi per soluzione Azure VMware.

  • Assegnazione di tag: Richiedi tag per le risorse di soluzione Azure VMware in modo che i costi siano attribuiti ai proprietari e ai carichi di lavoro e sia possibile generare report su di essi. Vedere Definizioni dei criteri per l'assegnazione di tag alle risorse.

  • Capacità: Considerare l'aggiunta di host come azione deliberatamente approvata. Decidi chi può approvare capacità aggiuntiva. Definire standard per le dimensioni minime e massime del cluster e per le regioni di distribuzione approvate, e richiedere un margine di capacità di riserva affinché un datastore non si riempia mai eccessivamente. Richiedi la quota host prima che sia necessaria. Le richieste di quota non aggiungono alcun costo, ma un'aggiunta di capacità può richiedere diversi giorni per soddisfare. Assicurarsi che il processo includa l'acquisizione delle licenze VCF necessarie per gli host soluzione Azure VMware appena aggiunti.

7. Baseline per la VM guest di soluzione Azure VMware

Microsoft gestisce l'infrastruttura soluzione Azure VMware, inclusi gli host ESXi, il server vCenter e NSX. Si rimane responsabili dei sistemi operativi guest, delle applicazioni e dei controlli di sicurezza eseguiti all'interno di ogni macchina virtuale.

Estendere la governance ai sistemi operativi guest integrando le macchine virtuali in VMware vSphere abilitato per Azure Arc. Vedi VMware vSphere abilitato per Azure Arc.

Una volta che una macchina virtuale è abilitata per Azure Arc, le organizzazioni possono applicare Configurazione computer di Criteri di Azure, i servizi di Microsoft Defender, Update Manager e altre funzionalità di gestione di Azure, utilizzando gli stessi processi di governance adottati per le macchine virtuali di Azure. Vedere Definizioni di criteri predefiniti per i server abilitati per Azure Arc e Come creare definizioni di criteri di configurazione del computer personalizzati.

7.1 Baseline di configurazione guest

Richiedere Azure Arc onboarding come parte del processo di provisioning delle macchine virtuali. L'onboarding anticipato garantisce che i controlli di governance vengano applicati dal primo giorno anziché essere aggiunti in un secondo momento tramite il lavoro manuale. Azure Arc abilita funzionalità come Inventory, Change Tracking e Machine Configuration.

Questi servizi funzionano in soluzione Azure VMware allo stesso modo in cui funzionano per le macchine virtuali di Azure, una volta che il sistema operativo guest è abilitato per Arc. Le organizzazioni possono quindi applicare gli stessi standard di configurazione in ambienti Azure, VMware locale e soluzione Azure VMware.

7.2 Protezione degli endpoint

Gli standard di Endpoint Protection devono rimanere coerenti indipendentemente dalla posizione in cui viene eseguita la macchina virtuale. Per le macchine virtuali di soluzione Azure VMware, VMware vSphere abilitato per Azure Arc fornisce il percorso d'integrazione necessario per distribuire Microsoft Defender per endpoint e altri servizi di sicurezza di Azure. Questo approccio consente ai team di sicurezza di mantenere una visualizzazione unificata del comportamento di sicurezza degli endpoint nell'ambiente ibrido. Vedere Integrare Microsoft Defender per il cloud con soluzione Azure VMware.

7.3 Baseline di applicazione di patch

Microsoft è responsabile dell'applicazione di patch all'infrastruttura soluzione Azure VMware. Nell'organizzazione, in genere il team operativo IT o i team di amministrazione del carico di lavoro sono responsabili dell'applicazione di patch ai sistemi operativi guest e alle applicazioni. Se l'organizzazione dipende dalle soluzioni di applicazione di patch aziendali stabilite, continuare a usare gli strumenti in cui esistono requisiti avanzati di pianificazione o orchestrazione. Questi requisiti possono includere Gestore aggiornamenti di Azure nelle macchine virtuali soluzione Azure VMware abilitate per Arc.

7.4 Baseline dell'estensione della VM

Le estensioni macchina virtuale offrono funzionalità come il monitoraggio della sicurezza, la raccolta di dati di telemetria e la gestione operativa. Senza governance, la distribuzione delle estensioni può diventare frammentata e difficile da controllare.

Definire un catalogo di estensioni approvato e richiedere ai team del carico di lavoro di usare solo le estensioni autorizzate. Associare la governance delle estensioni con Criteri di Azure per applicare la conformità e rilevare configurazioni non autorizzate.

Passo successivo

Standard operativi

  • Last updated on