L'architettura in questo articolo si espande sull'architettura di base della macchina virtuale (VM) per soddisfare le modifiche e le aspettative durante la distribuzione in una zona di destinazione di Azure.
Nell'esempio riportato in questo articolo un'organizzazione vuole che un carico di lavoro basato su vm usi risorse federate gestite centralmente da un team della piattaforma. Queste risorse includono le risorse di rete per la connettività cross-premise, la gestione degli accessi alle identità e i criteri. Questo esempio presuppone che l'organizzazione adotta le zone di destinazione di Azure per applicare una governance coerente e un'efficienza dei costi tra più carichi di lavoro.
In qualità di proprietario del carico di lavoro, è possibile eseguire l'offload della gestione delle risorse condivise ai team centrali, in modo da concentrarsi sulle attività di sviluppo del carico di lavoro. Questo articolo presenta il punto di vista del team del carico di lavoro. Consigli specificati per il team della piattaforma.
Importante
Che cosa sono le zone di destinazione di Azure? Le zone di destinazione di Azure presentano due prospettive del footprint cloud di un'organizzazione. Una zona di destinazione dell'applicazione è una sottoscrizione di Azure in cui viene eseguito un carico di lavoro. È connesso alle risorse condivise dell'organizzazione. Tramite tale connessione, ha accesso all'infrastruttura di base che esegue il carico di lavoro, ad esempio rete, gestione degli accessi alle identità, criteri e monitoraggio. Una zona di destinazione della piattaforma è una raccolta di varie sottoscrizioni, ognuna con una funzione specifica. Ad esempio, una sottoscrizione di connettività fornisce una risoluzione DNS (Domain Name System) centralizzata, connettività cross-premise e appliance virtuali di rete (APPLIANCE virtuali di rete) disponibili per l'uso da parte dei team delle applicazioni.
È consigliabile comprendere il concetto di zone di destinazione di Azure per prepararsi all'implementazione di questa architettura.
Layout articolo
| Architettura | Decisione di progettazione | Approccio di Azure Well-Architected Framework |
|---|---|---|
| ▪ Diagramma dell'architettura ▪ Risorse del carico di lavoro ▪ Risorse federate |
▪ Configurazione della sottoscrizione ▪ Requisiti di rete ▪ Modifiche alla progettazione della rete dalla linea di base ▪ Monitoraggio ▪ Conformità delle patch ▪ Governance organizzativa ▪ Gestione delle modifiche |
▪ Affidabilità ▪ Sicurezza ▪ Ottimizzazione costi |
Suggerimento
Questa implementazione di riferimento illustra le procedure consigliate descritte in questo articolo.
Gli artefatti del repository forniscono una base personalizzabile per l'ambiente in uso. L'implementazione configura una rete hub con risorse condivise come Firewall di Azure a scopo dimostrativo. È possibile applicare questa configurazione per separare le sottoscrizioni dell'area di destinazione dell'applicazione per funzioni distinte del carico di lavoro e della piattaforma.
Architettura
Scaricare un file di Visio di questa architettura.
Componenti
Tutte le architetture della zona di destinazione di Azure hanno una separazione della proprietà tra il team della piattaforma e il team del carico di lavoro. Gli architetti delle applicazioni e i team DevOps devono avere una conoscenza approfondita di questa divisione delle responsabilità per comprendere cosa è sotto la loro influenza diretta o controllo e cosa non è.
Risorse di proprietà del team del carico di lavoro
Le risorse seguenti rimangono per lo più invariate rispetto all'architettura di base.
Azure Macchine virtuali è la piattaforma dell'applicazione. Le risorse di calcolo vengono distribuite tra le zone di disponibilità.
Azure Load Balancer viene usato per bilanciare il carico privato del traffico dalle macchine virtuali front-end alle macchine virtuali back-end. Il servizio di bilanciamento del carico distribuisce il traffico alle macchine virtuali tra le zone.
app Azure lication Gateway viene usato come proxy inverso per instradare le richieste utente alle macchine virtuali front-end. Lo SKU selezionato viene usato anche per ospitare Web application firewall di Azure per proteggere le macchine virtuali front-end da traffico potenzialmente dannoso.
Azure Key Vault viene usato per archiviare i segreti e i certificati dell'applicazione.
Monitoraggio di Azure, Log Analytics e Application Insights vengono usati per raccogliere, archiviare e visualizzare i dati di osservabilità.
Criteri di Azure viene usato per applicare criteri specifici del carico di lavoro.
Il team del carico di lavoro gestisce e gestisce le risorse e le responsabilità seguenti.
Subnet di rete virtuale spoke e gruppi di sicurezza di rete (NSG) posizionati su tali subnet per mantenere la segmentazione e controllare il flusso del traffico.
Endpoint privati per proteggere la connettività alle soluzioni PaaS (Platform as a Service) e le zone DNS private necessarie per tali endpoint.
Azure Managed Disks archivia i file di log nei server back-end e i dati vengono conservati anche quando le macchine virtuali vengono riavviate. I server front-end dispongono di dischi collegati che è possibile usare per distribuire l'applicazione senza stato.
Risorse di proprietà del team della piattaforma
Il team della piattaforma possiede e gestisce queste risorse centralizzate. Questa architettura presuppone che queste risorse vengano preprovisionate e considerate dipendenze.
Firewall di Azure nella rete hub viene usato per controllare e limitare il traffico in uscita. Questo componente sostituisce il servizio di bilanciamento del carico standard nell'architettura di base, che non fornisce restrizioni sul traffico in uscita verso Internet.
Azure Bastion nella rete hub fornisce accesso operativo sicuro alle macchine virtuali del carico di lavoro. Nell'architettura di base il team del carico di lavoro è proprietario di questo componente.
La rete virtuale spoke è la posizione in cui viene distribuito il carico di lavoro.
Le route definite dall'utente vengono usate per forzare il tunneling nella rete hub.
i vincoli di governance basati su Criteri di Azure e
DeployIfNotExistsi criteri DINE fanno parte della sottoscrizione del carico di lavoro.
Importante
Le zone di destinazione di Azure forniscono alcune delle risorse precedenti come parte delle sottoscrizioni della zona di destinazione della piattaforma e la sottoscrizione del carico di lavoro fornisce altre risorse. Molte delle risorse fanno parte della sottoscrizione di connettività, che include risorse aggiuntive, ad esempio Azure ExpressRoute, Azure Gateway VPN e DNS di Azure. Queste risorse aggiuntive forniscono l'accesso cross-premise e la risoluzione dei nomi. La gestione di queste risorse non rientra nell'ambito di questo articolo.
Configurazione della sottoscrizione
In un contesto di zona di destinazione, il team del carico di lavoro deve informare il team della piattaforma dei requisiti specifici.
Il team del carico di lavoro deve includere informazioni dettagliate sullo spazio di rete necessario per il carico di lavoro, in modo che il team della piattaforma possa allocare le risorse necessarie. Il team determina i requisiti e il team della piattaforma determina gli indirizzi IP da assegnare all'interno della rete virtuale e il gruppo di gestione a cui è assegnata la sottoscrizione.
Il team della piattaforma assegna un gruppo di gestione appropriato in base ai requisiti tecnici e alla criticità aziendale del carico di lavoro, ad esempio se un carico di lavoro è esposto a Internet. L'organizzazione determina la configurazione di questi gruppi di gestione e il team della piattaforma li implementa.
Ad esempio, i gruppi di gestione negli scenari dell'applicazione per l'architettura di base sono considerati:
Applicazioni private, ad esempio applicazioni line-of-business interne o soluzioni commerciali off-the-shelf ,che si trovano spesso nel gruppo di gestione aziendale delle zone di destinazione di Azure.
Applicazioni pubbliche, come nelle applicazioni con connessione Internet, che sono spesso incluse nel gruppo di gestione Corp o Online.
Il team della piattaforma è anche responsabile della configurazione di una sottoscrizione o di un gruppo di sottoscrizioni per la distribuzione del carico di lavoro.
Le sezioni seguenti forniscono indicazioni sulla configurazione iniziale della sottoscrizione. Tuttavia, il team della piattaforma apporta in genere modifiche ai servizi centralizzati per soddisfare i requisiti mancanti o modificati. Le modifiche della piattaforma hanno un effetto più ampio su tutti i team del carico di lavoro.
Di conseguenza, il team della piattaforma deve assicurarsi che tutti i carichi di lavoro delle macchine virtuali siano preparati per le modifiche e che siano consapevoli del ciclo di vita della soluzione basata su vm e del ciclo di test. Per altre informazioni, vedere Gestione delle modifiche nel tempo.
Requisiti e adempimenti del carico di lavoro
Il team del carico di lavoro e i team della piattaforma condividono due responsabilità principali: assegnazione del gruppo di gestione e configurazione della rete. Per questa architettura, prendere in considerazione i requisiti di rete seguenti che è necessario comunicare con il team della piattaforma. Usare questi punti come esempi per comprendere la discussione e la negoziazione tra i due team quando si implementa un'architettura simile.
Numero di reti virtuali spoke: in questa architettura è necessario un solo spoke dedicato. Le risorse distribuite non devono estendersi su più reti e si trovano in una singola rete virtuale.
Dimensioni della rete spoke: prendere in considerazione i requisiti operativi e la crescita prevista del carico di lavoro. Ad esempio, se si prevede di implementare aggiornamenti blu/verde o canary, le dimensioni massime devono tenere conto dello spazio richiesto dalle distribuzioni side-by-side.
Le modifiche future potrebbero richiedere più spazio IP, che può non essere allineato con l'allocazione corrente. L'integrazione di questi spazi può introdurre una maggiore complessità. Essere proattivi e richiedere risorse di rete sufficienti per garantire che lo spazio allocato possa supportare l'espansione futura.
Area di distribuzione: è importante specificare le aree in cui verrà distribuito il carico di lavoro. Il team della piattaforma può usare queste informazioni per assicurarsi che venga effettuato il provisioning delle reti virtuali spoke-and-hub nella stessa area. Le reti in aree diverse possono causare problemi di latenza a causa del traffico che superano i limiti a livello di area e possono anche comportare costi di larghezza di banda aggiuntivi.
Caratteristiche e scelte di progettazione del carico di lavoro: comunicare le scelte di progettazione, i componenti e le caratteristiche al team della piattaforma. Ad esempio, se si prevede che il carico di lavoro generi un numero elevato di connessioni simultanee a Internet (chatty), il team della piattaforma deve assicurarsi che siano disponibili porte sufficienti per evitare l'esaurimento. Possono aggiungere indirizzi IP al firewall centralizzato per supportare il traffico o configurare un gateway NAT (Network Address Translation) per instradare il traffico attraverso un percorso alternativo.
Viceversa, se si prevede che il carico di lavoro generi traffico di rete minimo (rumore di fondo), il team della piattaforma deve usare le risorse in modo efficiente nell'intera organizzazione.
Il team della piattaforma deve comprendere chiaramente eventuali dipendenze. Ad esempio, il carico di lavoro potrebbe dover accedere a un database di cui è proprietario un altro team o che il carico di lavoro potrebbe avere traffico cross-premise. Il carico di lavoro ha dipendenze all'esterno di Azure? Queste informazioni sono importanti per il team della piattaforma.
Configurazione del firewall: il team della piattaforma deve essere a conoscenza del traffico che lascia la rete spoke e viene sottoposto a tunneling alla rete hub. Il firewall nell'hub non può bloccare il traffico.
Ad esempio, se il carico di lavoro deve accedere agli aggiornamenti di Windows per rimanere patch, un firewall non deve bloccare questi aggiornamenti. Analogamente, se sono presenti agenti di monitoraggio, che accedono a endpoint specifici, un firewall non deve bloccare il traffico perché può interrompere i dati di monitoraggio per il carico di lavoro. L'applicazione potrebbe richiedere l'accesso agli endpoint di terze parti. Indipendentemente dal fatto, usare un firewall centralizzato per distinguere tra il traffico previsto e quello non autorizzato.
Accesso operatore: se sono presenti gruppi di sicurezza microsoft Entra ID che gli operatori usano per accedere alle macchine virtuali tramite Azure Bastion, informare il team della piattaforma. Azure Bastion è in genere una risorsa centrale. È fondamentale assicurarsi che i gruppi di sicurezza e le macchine virtuali supportino il protocollo sicuro.
Inoltre, informare il team della piattaforma sugli intervalli IP che contengono le macchine virtuali. Queste informazioni sono necessarie per configurare i gruppi di sicurezza di rete in Azure Bastion nella rete hub.
Indirizzi IP pubblici: informare il team della piattaforma sul profilo del traffico in ingresso, inclusi gli eventuali indirizzi IP pubblici previsti. In questa architettura, solo il traffico con origine Internet è destinato all'indirizzo IP pubblico in gateway applicazione. Il team della piattaforma deve informare il team del carico di lavoro se questi indirizzi IP si trovano in un piano di protezione DDoS di Azure o se è responsabilità del team del carico di lavoro.
In questa architettura è disponibile un altro indirizzo IP pubblico per l'accesso operativo tramite Azure Bastion. Il team della piattaforma possiede questo indirizzo IP pubblico ed è registrato in un servizio, ad esempio Protezione DDoS, gestito anche dal team della piattaforma.
Importante
È consigliabile un flusso di lavoro vendita di abbonamenti per il team della piattaforma che include una serie di domande progettate per acquisire informazioni dal team del carico di lavoro. Queste domande possono variare da un'organizzazione a un'altra, ma lo scopo è raccogliere i requisiti per l'implementazione delle sottoscrizioni. Per altre informazioni, vedere Distribuzione automatica delle sottoscrizioni.
Scelte di progettazione delle macchine virtuali
Le selezioni dello SKU e del disco della macchina virtuale rimangono identiche all'architettura di base.
Un'organizzazione potrebbe imporre requisiti di conformità al team del carico di lavoro che impone l'uso di immagini di macchine virtuali specifiche. In base a questi requisiti, il team della piattaforma potrebbe gestire un set di immagini standardizzate, spesso definite immagini dorate, create per l'uso in tutta l'organizzazione.
Il team della piattaforma potrebbe usare un'offerta gestita, ad esempio Azure Compute Gallery o un repository privato, per archiviare immagini del sistema operativo approvate o artefatti del carico di lavoro. Quando si sceglie un'immagine del sistema operativo per le macchine virtuali, consultare il team della piattaforma sulle origini delle immagini, sulla frequenza di aggiornamento e sulle aspettative di utilizzo. Assicurarsi anche che le immagini possano soddisfare i requisiti aziendali necessari soddisfatti dal carico di lavoro.
Importante
Per il team della piattaforma: se si usa Raccolta di calcolo, il carico di lavoro richiede visibilità di rete per la raccolta privata. Collaborare con il team del carico di lavoro per stabilire una connettività sicura.
Rete
Nell'architettura di base viene effettuato il provisioning del carico di lavoro in una singola rete virtuale. Il team del carico di lavoro gestisce la rete virtuale.
In questa architettura il team della piattaforma determina la topologia di rete. In questa architettura si presuppone una topologia hub-spoke.
Scaricare un file di Visio di questa architettura.
Rete virtuale hub: un hub a livello di area contiene servizi centralizzati che comunicano con le risorse del carico di lavoro nella stessa area. Per altre informazioni, vedere Risorse di proprietà del team della piattaforma. È consigliabile inserire l'hub nella sottoscrizione di connettività.
Rete virtuale spoke: in questa architettura, la singola rete virtuale dell'architettura di base è la rete spoke. Viene eseguito il peering alla rete hub, che contiene i servizi centralizzati. Il team della piattaforma possiede e gestisce questa rete spoke. Questa rete contiene le risorse del carico di lavoro. Il team del carico di lavoro è proprietario delle risorse in questa rete, incluse le relative subnet.
Assicurarsi di comunicare periodicamente i requisiti del carico di lavoro al team della piattaforma e di esaminarli periodicamente.
Importante
Per il team della piattaforma: a meno che non sia richiesto specificamente dal carico di lavoro, non eseguire direttamente il peering della rete spoke a un'altra rete virtuale spoke. Questa procedura protegge gli obiettivi di segmentazione del carico di lavoro. Il team deve facilitare tutte le connessioni di rete virtuale transitive.
Subnet della rete virtuale
Nella rete virtuale spoke il team del carico di lavoro crea e alloca le subnet. L'inserimento di controlli per limitare il traffico all'interno e all'esterno delle subnet consente di fornire la segmentazione. Questa architettura usa la stessa topologia di subnet dell'architettura di base, con subnet dedicate per gateway applicazione, macchine virtuali front-end, servizio di bilanciamento del carico, macchine virtuali back-end ed endpoint privati.
Quando si distribuisce il carico di lavoro in una zona di destinazione di Azure, è comunque necessario implementare i controlli di rete. Le organizzazioni potrebbero imporre restrizioni per proteggersi dall'esfiltrazione dei dati e garantire la visibilità per il centro operativo di sicurezza centrale (SOC) e il team della rete IT.
Con questo approccio, il team della piattaforma può ottimizzare la spesa complessiva dell'organizzazione usando servizi centralizzati, invece di distribuire controlli di sicurezza ridondanti per ogni carico di lavoro in tutta l'organizzazione. In questa architettura, Firewall di Azure è un esempio di servizio centrale. Non è conveniente o pratico per ogni team del carico di lavoro gestire la propria istanza del firewall. È consigliabile un approccio centralizzato alla gestione del firewall.
Traffico in ingresso
Il flusso del traffico in ingresso rimane uguale all'architettura di base.
Il proprietario del carico di lavoro è responsabile di tutte le risorse correlate all'ingresso internet pubblico nel carico di lavoro. In questa architettura, ad esempio, gateway applicazione e il relativo indirizzo IP pubblico vengono posizionati nella rete spoke e non nella rete hub. Alcune organizzazioni potrebbero inserire risorse con traffico in ingresso in una sottoscrizione di connettività usando un'implementazione centralizzata della rete perimetrale.Some organizations might place resources with ingress traffic in a connectivity subscription by using a centraled demilitarized (DMZ) implementation. L'integrazione con tale topologia specifica non rientra nell'ambito di questo articolo.
Traffico in uscita
Nell'architettura di base i set di scalabilità di macchine virtuali del carico di lavoro accedono a Internet pubblico tramite Azure Load Balancer, ma tale traffico non è limitato.
Tale progettazione è diversa in questa architettura. Tutto il traffico che lascia la rete virtuale spoke viene instradato attraverso la rete hub con peering tramite un firewall in uscita. Una route è collegata a tutte le subnet possibili nella rete spoke che indirizza tutto il traffico per gli indirizzi IP non trovati nella rete virtuale locale (0.0.0.0/0) al Firewall di Azure dell'hub.
Scaricare un file di Visio di questa architettura.
La comunicazione del carico di lavoro all'endpoint privato per l'accesso a Key Vault rimane identica all'architettura di base. Tale percorso viene omesso dal diagramma precedente per brevità.
Il team del carico di lavoro deve identificare, documentare e comunicare tutti i flussi di traffico in uscita necessari per le operazioni dell'infrastruttura e del carico di lavoro. Il team della piattaforma consente il traffico richiesto e tutto il traffico in uscita non comunicato viene probabilmente negato.
Il controllo del traffico in uscita non è sufficiente assicurarsi che il traffico previsto sia consentito. Si tratta anche di assicurarsi che sia consentito solo il traffico previsto. Il traffico in uscita non comunicato viene probabilmente negato per impostazione predefinita, ma è nell'interesse migliore per la sicurezza del carico di lavoro per garantire che il traffico venga instradato correttamente.
Suggerimento
Incoraggiare il team della piattaforma a usare i gruppi IP in Firewall di Azure. Questa procedura garantisce che le esigenze di traffico in uscita del carico di lavoro siano rappresentate accuratamente con un ambito limitato solo per le subnet di origine. Ad esempio, una regola che consente alle macchine virtuali del carico di lavoro di raggiungere api.example.org non implica necessariamente che le risorse di supporto all'interno della stessa rete virtuale possano accedere allo stesso endpoint. Questo livello di controllo granulare può migliorare il comportamento di sicurezza della rete.
Comunicare i requisiti univoci del traffico in uscita al team della piattaforma. Ad esempio, se il carico di lavoro stabilisce numerose connessioni simultanee agli endpoint di rete esterni, informare il team della piattaforma. Il team della piattaforma può quindi effettuare il provisioning di un'implementazione appropriata del gateway NAT di Azure o aggiungere altri indirizzi IP pubblici nel firewall a livello di area per la mitigazione.
L'organizzazione potrebbe avere requisiti che scoraggiano l'uso di modelli di architettura, che usano indirizzi IP pubblici di proprietà del carico di lavoro per l'uscita. In tal caso, è possibile usare Criteri di Azure per negare gli indirizzi IP pubblici nelle schede di interfaccia di rete delle macchine virtuali e in qualsiasi altro IP pubblico, ad eccezione dei punti di ingresso noti.
Zone DNS private
Le architetture che usano endpoint privati necessitano di zone DNS private per lavorare con il provider DNS. Il team del carico di lavoro deve avere una chiara conoscenza dei requisiti e della gestione delle zone DNS private nella sottoscrizione fornita dal team della piattaforma. DNS privato zone vengono in genere gestite su larga scala con criteri DINE, che consentono Firewall di Azure di funzionare come proxy DNS affidabile e supportano regole di rete FQDN (Fully Qualified Domain Name).
In questa architettura, il team della piattaforma garantisce la risoluzione DNS privata affidabile per gli endpoint di collegamento privato. Collaborare con il team della piattaforma per comprendere le aspettative.
test di Connessione ivity
Per le architetture basate su vm, sono disponibili diversi strumenti di test che consentono di determinare i problemi di rete line-of-sight, routing e DNS. È possibile usare gli strumenti tradizionali per la risoluzione dei problemi, ad esempio netstat, nslookupo tcping. È anche possibile esaminare le impostazioni DHCP (Dynamic Host Configuration Protocol) e DNS della scheda di rete. Se sono presenti schede di interfaccia di rete, sono disponibili più funzionalità di risoluzione dei problemi che consentono di eseguire controlli di connettività usando Azure Network Watcher.
Accesso dell'operatore
Analogamente all'architettura di base, l'accesso operativo tramite Azure Bastion è supportato in questa architettura.
Tuttavia, l'architettura di base distribuisce Azure Bastion come parte del carico di lavoro. Per un'organizzazione tipica che adotta le zone di destinazione di Azure, distribuiscono Azure Bastion come risorse centrali per ogni area. Il team della piattaforma possiede e gestisce Azure Bastion e tutti i carichi di lavoro dell'organizzazione lo condividono. Per dimostrare che il caso d'uso in questa architettura, Azure Bastion si trova nella rete hub nella sottoscrizione di connettività.
Identità dell'operatore
Questa architettura usa la stessa estensione di autenticazione dell'architettura di base.
Nota
Quando gli operatori accedono a una macchina virtuale, devono usare le identità aziendali nel tenant microsoft Entra ID e non condividere le entità servizio tra le funzioni.
Iniziare sempre con il principio dei privilegi minimi e l'accesso granulare a un'attività anziché all'accesso di lunga durata. Nel contesto della zona di destinazione sfruttare il supporto JIT (Just-In-Time) gestito dal team della piattaforma.
Conformità delle patch e aggiornamenti del sistema operativo
L'architettura di base descrive un approccio autonomo all'applicazione di patch e agli aggiornamenti. Quando il carico di lavoro è integrato con le zone di destinazione, questo approccio potrebbe cambiare. Il team della piattaforma potrebbe determinare le operazioni di applicazione di patch in modo che tutti i carichi di lavoro siano conformi ai requisiti dell'organizzazione.
Assicurarsi che il processo di applicazione di patch includa tutti i componenti aggiunti all'architettura. Ad esempio, se si sceglie di aggiungere macchine virtuali dell'agente di compilazione per automatizzare la distribuzione, il ridimensionamento e la gestione delle applicazioni, tali macchine virtuali devono essere conformi ai requisiti della piattaforma.
Monitoraggio
La piattaforma della zona di destinazione di Azure fornisce risorse di osservabilità condivise come parte della sottoscrizione di gestione. È tuttavia consigliabile effettuare il provisioning delle proprie risorse di monitoraggio per facilitare le responsabilità di proprietà del carico di lavoro. Questo approccio è coerente con l'architettura di base.
Il team del carico di lavoro effettua il provisioning delle risorse di monitoraggio, tra cui:
Application Insights come servizio di monitoraggio delle prestazioni dell'applicazione (APM) per il team del carico di lavoro.
L'area di lavoro Log Analytics come sink unificato per tutti i log e le metriche raccolti dalle risorse di Azure di proprietà del carico di lavoro e dal codice dell'applicazione.
Scaricare un file di Visio di questa architettura.
Analogamente alla baseline, tutte le risorse sono configurate per inviare Diagnostica di Azure log all'area di lavoro Log Analytics di cui il team del carico di lavoro effettua il provisioning come parte della distribuzione dell'infrastruttura come codice delle risorse. Potrebbe anche essere necessario inviare log a un'area di lavoro Log Analytics centrale. Nelle zone di destinazione di Azure l'area di lavoro si trova nella sottoscrizione di gestione.
Il team della piattaforma potrebbe anche avere criteri DINE che possono usare per configurare diagnostica per inviare i log alle sottoscrizioni di gestione centralizzate. È importante assicurarsi che l'implementazione non limiti i flussi di log aggiuntivi.
Correlare i dati da più sink
I log e le metriche del carico di lavoro e i relativi componenti dell'infrastruttura vengono archiviati nell'area di lavoro Log Analytics del carico di lavoro. Tuttavia, i log e le metriche centralizzati, ad esempio Firewall di Azure, Microsoft Entra ID e Azure Bastion, vengono archiviati in un'area di lavoro Log Analytics centrale. La correlazione dei dati da più sink può essere un'attività complessa.
I dati correlati vengono spesso usati durante la risposta agli eventi imprevisti. Se si verifica un problema con la correlazione dei dati da più sink, assicurarsi che il runbook di valutazione per questa architettura lo indirizzi e includa punti di contatto dell'organizzazione se il problema si estende oltre le risorse del carico di lavoro. Gli amministratori del carico di lavoro potrebbero richiedere assistenza agli amministratori della piattaforma per correlare le voci di log dalle reti aziendali, dalla sicurezza o da altri servizi della piattaforma.
Importante
Per il team della piattaforma: se possibile, concedere il controllo degli accessi in base al ruolo (RBAC) per eseguire query e leggere sink di log per le risorse della piattaforma pertinenti. Abilitare i log del firewall per le valutazioni delle regole di rete e applicazione e il proxy DNS perché i team dell'applicazione possono usare queste informazioni durante le attività di risoluzione dei problemi.
Criteri di Azure
Il team della piattaforma applica probabilmente criteri che influiscono sulla distribuzione del carico di lavoro. Spesso applicano criteri DINE per gestire le distribuzioni automatizzate in una sottoscrizione dell'area di destinazione dell'applicazione. I criteri DINE possono modificare le risorse del carico di lavoro o aggiungere risorse alla distribuzione, con conseguente discrepanza tra le risorse distribuite in modo dichiarativo tramite il modello di carico di lavoro e le risorse effettivamente usate dalle richieste di elaborazione. Una soluzione tipica consiste nel correggere le modifiche con approcci imperativi, che non sono ideali.
Per evitare tale discrepanza, incorporare e testare preventivamente le modifiche avviate dalla piattaforma nei modelli IaC. Se il team della piattaforma usa criteri di Azure in conflitto con i requisiti dell'applicazione, è possibile negoziare una risoluzione con il team della piattaforma.
Importante
Le zone di destinazione di Azure usano vari criteri DINE, ad esempio criteri che gestiscono gli endpoint privati su larga scala. Questo criterio monitora le distribuzioni degli endpoint privati e aggiorna DNS di Azure nella rete hub, che fa parte di una sottoscrizione gestita dalla piattaforma. Il team del carico di lavoro non dispone dell'autorizzazione per modificare i criteri nell'hub e il team della piattaforma non monitora automaticamente le distribuzioni dei team del carico di lavoro per aggiornare automaticamente IL DNS. I criteri DINE vengono usati per fornire questa connessione.
Altri criteri potrebbero influire su questa architettura, inclusi i criteri che:
- Richiedere a una macchina virtuale Windows di aggiungere un dominio di Active Directory. Questo criterio garantisce che l'estensione macchina
JoinADDomainExtensionvirtuale sia installata e configurata. Per altre informazioni, vedere Applicare le macchine virtuali Windows per l'aggiunta a un dominio di Active Directory. - Non consentire l'inoltro IP nelle interfacce di rete.
Gestire le modifiche nel tempo
I servizi e le operazioni forniti dalla piattaforma sono considerati dipendenze esterne in questa architettura. Il team della piattaforma continua ad applicare modifiche, eseguire l'onboarding degli utenti e applicare i controlli dei costi. Il team della piattaforma, che gestisce l'organizzazione, potrebbe non classificare in ordine di priorità i singoli carichi di lavoro. Le modifiche apportate a tali dipendenze, indipendentemente dal fatto che siano modifiche alle immagini d'oro, modifiche del firewall, applicazione automatica di patch o modifiche alle regole, possono influire su più carichi di lavoro.
Pertanto, i team del carico di lavoro e della piattaforma devono comunicare in modo efficiente e tempestivo per gestire tutte le dipendenze esterne. È importante testare le modifiche, quindi non influiscono negativamente sui carichi di lavoro.
Modifiche della piattaforma che influiscono sul carico di lavoro
In questa architettura il team della piattaforma gestisce le risorse seguenti. Le modifiche apportate a queste risorse possono influire potenzialmente sull'affidabilità, la sicurezza, le operazioni e gli obiettivi di prestazioni del carico di lavoro. È importante valutare queste modifiche prima che il team della piattaforma le inserisca in vigore per determinare come influiscono sul carico di lavoro.
Criteri di Azure: le modifiche apportate ai criteri di Azure possono influire sulle risorse del carico di lavoro e sulle relative dipendenze. Ad esempio, potrebbero essere presenti modifiche dirette ai criteri o lo spostamento della zona di destinazione in una nuova gerarchia dei gruppi di gestione. Queste modifiche potrebbero non essere rilevate fino a quando non è presente una nuova distribuzione, quindi è importante testarle accuratamente.
Regole del firewall: le modifiche alle regole del firewall possono influire sulla rete virtuale o sulle regole del carico di lavoro che si applicano su larga scala in tutto il traffico. Queste modifiche possono causare traffico bloccato e persino errori di processo invisibile all'utente, ad esempio l'applicazione non riuscita delle patch del sistema operativo. Questi potenziali problemi si applicano sia al firewall di Azure in uscita che alle regole del gruppo di sicurezza di rete applicate da Azure Rete virtuale Manager.
Risorse condivise: le modifiche apportate allo SKU o alle funzionalità nelle risorse condivise possono influire sul carico di lavoro.
Routing nella rete hub: le modifiche apportate alla natura transitiva del routing nell'hub possono influire potenzialmente sulla funzionalità del carico di lavoro se un carico di lavoro dipende dal routing ad altre reti virtuali.
Host Azure Bastion: le modifiche alla disponibilità o alla configurazione dell'host Azure Bastion possono influire sulle operazioni del carico di lavoro. Assicurarsi che le modifiche al modello di accesso jump box abbiano un accesso di routine, ad hoc e di emergenza effettivo.
Modifiche alla proprietà: comunicare eventuali modifiche alla proprietà e ai punti di contatto con il team del carico di lavoro perché possono influire sulle richieste di gestione e supporto del carico di lavoro.
Modifiche del carico di lavoro che influiscono sulla piattaforma
Gli esempi seguenti sono le modifiche al carico di lavoro in questa architettura che è necessario comunicare con il team della piattaforma. È importante che il team della piattaforma convaliderà l'affidabilità, la sicurezza, le operazioni e gli obiettivi di prestazioni del servizio della piattaforma rispetto alle modifiche apportate al nuovo team del carico di lavoro prima che vengano applicate.
Uscita di rete: monitorare qualsiasi aumento significativo dell'uscita di rete per evitare che il carico di lavoro diventi un vicino rumoroso nei dispositivi di rete. Questo problema può potenzialmente influire sugli obiettivi di prestazioni o affidabilità di altri carichi di lavoro.
Accesso pubblico: le modifiche apportate all'accesso pubblico ai componenti del carico di lavoro potrebbero richiedere ulteriori test. Il team della piattaforma potrebbe spostare il carico di lavoro in un gruppo di gestione diverso.
Valutazione della criticità aziendale: se sono state apportate modifiche ai contratti di servizio del carico di lavoro, potrebbe essere necessario un nuovo approccio di collaborazione tra i team della piattaforma e del carico di lavoro.
Modifiche alla proprietà: comunicare le modifiche apportate alla proprietà e ai punti di contatto con il team della piattaforma.
Modifiche ai requisiti aziendali del carico di lavoro
Per mantenere gli obiettivi a livello di servizio del carico di lavoro, il team della piattaforma potrebbe dover essere coinvolto nelle modifiche dell'architettura del carico di lavoro. Queste modifiche potrebbero richiedere la gestione delle modifiche dal team della piattaforma o la convalida che la governance esistente supporti i requisiti modificati.
Ad esempio, comunicare le modifiche a qualsiasi flusso in uscita non consentito in precedenza in modo che il team della piattaforma possa aggiungere tale flusso nel firewall, Rete virtuale Manager o altri componenti per supportare il traffico richiesto. Viceversa, se non è più necessario un flusso in uscita consentito in precedenza, il team della piattaforma deve bloccare tale flusso per mantenere la sicurezza del carico di lavoro. Comunicare anche le modifiche nel routing ad altre reti virtuali o endpoint cross-premise o modifiche ai componenti dell'architettura. Ogni risorsa è soggetta a criteri e potenzialmente al controllo del firewall in uscita.
Affidabilità
Questa architettura è allineata alle garanzie di affidabilità nell'architettura di base.
Obiettivi di affidabilità
L'SLO composito massimo possibile è inferiore rispetto all'SLO composito di base a causa di componenti come il controllo di rete in uscita. Questi componenti, comuni negli ambienti della zona di destinazione, non sono univoci per questa architettura. Lo SLO viene ridotto in modo analogo se il team del carico di lavoro controlla direttamente questi servizi di Azure.
Nonostante un SLO più basso possibile, l'aspetto chiave dell'affidabilità è la divisione dei componenti del carico di lavoro tra i team funzionali. Con questo metodo, il team del carico di lavoro trae vantaggio da un team specializzato che si concentra sull'infrastruttura critica operativa usata da questo carico di lavoro e da altri carichi di lavoro.
Per altre informazioni, vedere Consigli per la definizione di destinazioni di affidabilità.
Dipendenze critiche
Visualizzare tutte le funzionalità eseguite dal carico di lavoro nella piattaforma e nell'area di destinazione dell'applicazione come dipendenze. I piani di risposta agli eventi imprevisti richiedono che il team del carico di lavoro sia a conoscenza del punto e del metodo delle informazioni di contatto per queste dipendenze. Includere anche queste dipendenze nell'analisi della modalità di errore (FMA) del carico di lavoro.
Per questa architettura, prendere in considerazione le dipendenze seguenti:
Firewall in uscita: il firewall in uscita centralizzato, condiviso da più carichi di lavoro, subisce modifiche non correlate al carico di lavoro.
Esaurimento delle porte di rete: i picchi di utilizzo di tutti i carichi di lavoro che condividono il dispositivo di rete possono causare la saturazione della rete o l'esaurimento delle porte nel firewall in uscita.
Criteri DINE: i criteri DINE per le zone DNS private di Azure (o qualsiasi altra dipendenza fornita dalla piattaforma) sono ottimali, senza contratto di servizio per l'esecuzione. Un ritardo nella configurazione DNS può causare ritardi nella preparazione di un'applicazione per gestire il traffico.
Criteri di gruppo di gestione: i criteri coerenti tra gli ambienti sono fondamentali per l'affidabilità. Assicurarsi che gli ambienti di preproduzione siano simili agli ambienti di produzione per fornire test accurati e per evitare deviazioni specifiche dell'ambiente che possono bloccare una distribuzione o una scalabilità. Per altre informazioni, vedere Gestire gli ambienti di sviluppo di applicazioni nelle zone di destinazione di Azure.
Molte di queste considerazioni potrebbero esistere senza zone di destinazione di Azure, ma i team del carico di lavoro e della piattaforma devono risolvere in modo collaborativo questi problemi per garantire che vengano soddisfatte le esigenze.
Per altre informazioni, vedere Consigli per l'esecuzione dell'analisi della modalità di errore.
Sicurezza
Le considerazioni sulla sicurezza per questa architettura vengono portate avanti dall'architettura di base. Le raccomandazioni nelle sezioni seguenti si basano sull'elenco di controllo per la revisione della progettazione della sicurezza in Well-Architected Framework.
Controlli di rete
Configurare correttamente i controlli di rete per assicurarsi che il carico di lavoro sia sicuro.
Traffico in ingresso
È possibile isolare il carico di lavoro da altri spoke del carico di lavoro all'interno dell'organizzazione tramite gruppi di sicurezza di rete nelle subnet o la natura nontransitiva o i controlli nell'hub a livello di area. Creare gruppi di sicurezza di rete completi che consentano solo i requisiti di rete in ingresso dell'applicazione e dell'infrastruttura. È consigliabile non basarsi esclusivamente sulla natura nontransitiva della rete hub per la sicurezza.
Il team della piattaforma implementa probabilmente criteri di Azure per assicurarsi che gateway applicazione abbia web application firewall impostato sulla modalità di negazione, per limitare il numero di indirizzi IP pubblici disponibili per la sottoscrizione e altri controlli. Oltre a questi criteri, il team del carico di lavoro deve avere la responsabilità di distribuire criteri incentrati sui carichi di lavoro che rafforzano il comportamento di sicurezza in ingresso.
La tabella seguente mostra esempi di controlli di ingresso in questa architettura.
| Source | Scopo | Controllo del carico di lavoro | Controllo della piattaforma |
|---|---|---|---|
| Internet | Flussi di traffico utente | Imbuto tutte le richieste tramite un gruppo di sicurezza di rete, un Web application firewall e regole di routing prima di consentire al traffico pubblico di passare al traffico privato che entra nelle macchine virtuali front-end | None |
| Azure Bastion | Accesso degli operatori alle macchine virtuali | Gruppo di sicurezza di rete nelle subnet di macchine virtuali che blocca tutto il traffico verso le porte di accesso remoto, a meno che non venga originato dalla subnet di Azure Bastion designata dalla piattaforma | None |
| Altri spoke | None | Bloccato tramite regole del gruppo di sicurezza di rete | Routing non transitivo o regole di Firewall di Azure nel caso di un hub protetto di Azure rete WAN virtuale |
Traffico in uscita
Applicare le regole del gruppo di sicurezza di rete che esprimono i requisiti di connettività in uscita richiesti della soluzione e negano tutto il resto. Non basarsi solo sui controlli di rete hub. In qualità di operatore del carico di lavoro, si ha la responsabilità di arrestare il traffico in uscita indesiderato come vicino all'origine come praticabile.
Tenere presente che, mentre si è proprietari della subnet all'interno della rete virtuale, il team della piattaforma ha probabilmente creato regole del firewall per rappresentare in modo specifico i requisiti acquisiti come parte del processo di vendita di abbonamenti. Assicurarsi che le modifiche apportate alle subnet e al posizionamento delle risorse nel corso della durata dell'architettura siano ancora compatibili con la richiesta originale. In alternativa, è possibile collaborare con il team di rete per garantire la continuità del controllo in uscita con accesso minimo.
La tabella seguente mostra esempi di uscita in questa architettura.
| Endpoint | Scopo | Controllo carico di lavoro (NSG) | Controllo della piattaforma (hub) |
|---|---|---|---|
| ntp.ubuntu.com | Protocollo NTP (Network Time Protocol) per le macchine virtuali Linux | UDP/123 a Internet nella subnet della macchina virtuale front-end (il firewall in uscita restringe questa ampia apertura) | Tolleranza della regola di rete del firewall per lo stesso controllo del carico di lavoro |
| Endpoint di Windows Update | Funzionalità di Windows Update dai server Microsoft | TCP/443 e TCP/80 su Internet nella subnet della macchina virtuale back-end (il firewall in uscita restringe questa ampia apertura) | Regola di indennità del firewall con tag FQDN di WindowsUpdate |
| Monitorare gli endpoint dell'agente | Traffico necessario per l'estensione Monitoraggio nelle macchine virtuali | TCP/443 a Internet in entrambe le subnet vm (il firewall in uscita restringe questa ampia apertura) | Autorizzazioni necessarie per le regole dell'applicazione firewall per tutti gli FQDN specifici su TCP/443 |
| nginx.org | Per installare Nginx (un componente dell'applicazione di esempio) direttamente dal fornitore | TCP/443 a Internet nella subnet della macchina virtuale front-end (il firewall in uscita restringe questa ampia apertura) | Necessaria tolleranza per le regole dell'applicazione firewall per nginx.org su TCP/443 |
| Insieme di credenziali delle chiavi di | Per importare certificati TLS (Transport Layer Security) in gateway applicazione e macchine virtuali | - DA TCP/443 a una subnet di endpoint privato da entrambe le subnet vm a una subnet dell'endpoint privato - TCP/443 a una subnet dell'endpoint privato da una subnet gateway applicazione - TCP/443 dalle macchine virtuali contrassegnate con una designazione del gruppo di sicurezza delle applicazioni (ASG) richiesta e gateway applicazione subnet |
None |
Protezione DDoS
Determinare chi è responsabile dell'applicazione del piano di protezione DDoS che copre tutti gli indirizzi IP pubblici della soluzione. Il team della piattaforma potrebbe usare piani di protezione IP o potrebbe anche usare Criteri di Azure per applicare i piani di protezione della rete virtuale. Questa architettura deve avere una copertura perché implica un indirizzo IP pubblico per l'ingresso da Internet.
Per altre informazioni, vedere Consigli per la rete e la connettività.
Gestione dei segreti
Per la gestione dei segreti, questa architettura segue l'architettura di base.
In qualità di team del carico di lavoro, continuare a mantenere i segreti nell'istanza di Key Vault. Distribuire più istanze in base alle esigenze per supportare le operazioni dell'applicazione e dell'infrastruttura.
Per altre informazioni, vedere Consigli per la protezione dei segreti dell'applicazione.
Ottimizzazione dei costi
Per le risorse del carico di lavoro, le strategie di ottimizzazione dei costi nell'architettura di base si applicano anche a questa architettura.
Questa architettura trae notevolmente vantaggio dalle risorse della piattaforma della zona di destinazione di Azure. Anche se si usano tali risorse tramite un modello di chargeback, la sicurezza e la connettività cross-premise aggiunte sono più convenienti rispetto all'auto-gestione di tali risorse.
Il team della piattaforma gestisce le risorse seguenti in questa architettura. Queste risorse sono spesso basate sul consumo (chargeback) o potenzialmente gratuite per il team del carico di lavoro.
- Firewall di Azure
- Soluzione SIEM (Security information and event management)
- host Azure Bastion
- Connettività cross-premise, ad esempio ExpressRoute
Sfruttare i vantaggi di altre offerte centralizzate del team della piattaforma per estendere tali vantaggi al carico di lavoro senza compromettere lo SLO, l'obiettivo del tempo di ripristino (RTO) o l'obiettivo del punto di ripristino (RPO).
Per altre informazioni, vedere Consigli per la raccolta e l'analisi dei dati sui costi.
Distribuire lo scenario
Una distribuzione di questa architettura di riferimento è disponibile in GitHub.
Passaggio successivo
Esaminare la collaborazione e i dettagli tecnici condivisi tra un team del carico di lavoro e i team della piattaforma.