Questo articolo fa parte di una serie basata sull'architettura di base end-to-end del servizio OpenaAI di Azure. È consigliabile acquisire familiarità con l'architettura di base in modo da comprendere le modifiche da apportare durante la distribuzione dell'architettura in una sottoscrizione della zona di destinazione dell'applicazione di Azure.
Questo articolo descrive l'architettura di un carico di lavoro di intelligenza artificiale generativa che distribuisce la stessa applicazione di chat di base, ma usa risorse esterne all'ambito del team del carico di lavoro. Queste risorse vengono condivise tra altri team del carico di lavoro e sono gestite centralmente dai team della piattaforma di un'organizzazione. Le risorse condivise includono risorse di rete per la connessione a o da posizioni locali, risorse di gestione degli accessi alle identità e criteri. Queste indicazioni sono destinate alle organizzazioni che usano le zone di destinazione di Azure per garantire una governance coerente e un'efficienza dei costi.
In qualità di proprietario del carico di lavoro, è possibile scaricare la gestione delle risorse condivise ai team della piattaforma in modo da poter concentrarsi sulle attività di sviluppo del carico di lavoro. Questo articolo presenta il punto di vista del team del carico di lavoro. Vengono specificate raccomandazioni per il team della piattaforma.
Importante
Che cosa sono le zone di destinazione di Azure?
Le zone di destinazione di Azure presentano due aree del footprint cloud di un'organizzazione. Una zona di destinazione dell'applicazione è una sottoscrizione di Azure in cui viene eseguito un carico di lavoro. Una zona di destinazione dell'applicazione è connessa alle risorse della piattaforma condivisa dell'organizzazione. Tramite tale connessione, la zona di destinazione ha accesso all'infrastruttura che supporta 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 che più team della piattaforma possono gestire. Ogni sottoscrizione ha una funzione specifica. Ad esempio, una sottoscrizione di connettività fornisce una risoluzione Domain Name System (DNS) centralizzata, connettività cross-premise e appliance virtuali di rete (NVA) disponibili per i team della piattaforma da usare.
È consigliabile comprendere le zone di destinazione di Azure, i relativi principi di progettazione e le aree di progettazione per implementare questa architettura.
Layout articolo
| Architettura | Decisioni relative alla progettazione | Approccio Azure Well-Architected Framework |
|---|---|---|
| ▪ Diagramma dell'architettura ▪ Risorse del carico di lavoro ▪ Risorse federate |
▪ Configurazione sottoscrizione ▪ Ambiente di calcolo ▪ Rete ▪ Accesso ai data scientist ▪ Monitorare le risorse ▪ Governance organizzativa ▪ Gestione delle modifiche |
▪ Affidabilità ▪ Sicurezza ▪ Ottimizzazione dei costi ▪ Eccellenza operativa ▪ Efficienza prestazionale |
Suggerimento
L'implementazione di riferimento di base della chat Azure OpenAI illustra le procedure consigliate descritte in questo articolo. Esaminare queste linee guida prima di prendere e implementare le decisioni di progettazione.
Modifica rispetto alla linea di base: questi criteri sono nuovi in questa architettura.
Architettura
Diagramma dell'architettura suddiviso in due sezioni principali. La sezione blu è etichettata come sottoscrizione della zona di destinazione dell'applicazione. La sezione inferiore è gialla ed è etichettata come sottoscrizione della zona di destinazione della piattaforma. La casella superiore contiene sia le risorse create dal carico di lavoro che le risorse di distribuzione automatica delle sottoscrizioni. Le risorse del carico di lavoro sono costituite da gateway applicazione e web application firewall, servizio app e la relativa subnet di integrazione, endpoint privati per soluzioni PaaS (Platform as a Service), ad esempio Archiviazione di Azure, Azure Key Vault, Azure AI Search, Servizio OpenAI di Azure e Registro Contenitori. Le risorse del carico di lavoro hanno anche l'area di lavoro di Machine Learning e le risorse di monitoraggio. Servizio app di Azure mostra tre istanze, ognuna in una zona di Azure diversa. La sottoscrizione della piattaforma contiene una rete virtuale hub, Firewall di Azure, Azure Bastion e un Gateway VPN disattivato e ExpressRoute. Esiste un peering di rete virtuale tra una rete virtuale nella zona di destinazione dell'applicazione e la rete virtuale hub.
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, definita democratizzazione delle sottoscrizioni. Gli architetti delle applicazioni, i data scientist e i team DevOps devono avere una conoscenza approfondita di questa responsabilità divisa per sapere cosa è sotto la loro influenza diretta o controllo e cosa non è.
Analogamente alla maggior parte delle implementazioni della zona di destinazione dell'applicazione, il team del carico di lavoro è principalmente responsabile della configurazione, della gestione e della distribuzione dei componenti del carico di lavoro, inclusi tutti i servizi di intelligenza artificiale usati in questa architettura.
Risorse di proprietà del team del carico di lavoro
Le risorse seguenti rimangono per lo più invariate rispetto all'architettura di base.
Azure OpenAI è un servizio completamente gestito che fornisce l'accesso all'API REST ai modelli linguistici di Azure OpenAI, tra cui GPT-4, GPT-3.5 Turbo e il set di modelli di incorporamento.
A seconda del modo in cui il Centro di eccellenza per l'intelligenza artificiale dell'organizzazione ha deciso di vincolare l'accesso alle distribuzioni dei modelli di intelligenza artificiale, il team del carico di lavoro potrebbe non possedere questa risorsa, ma il team deve usare risorse di intelligenza artificiale centralizzate. In tal caso, tutto il consumo di modelli scorre in genere attraverso un gateway fornito dal team della piattaforma di intelligenza artificiale. In questo articolo si presuppone che Azure OpenAI sia una risorsa di proprietà del carico di lavoro. In caso contrario, questa risorsa o un gateway per questa risorsa diventa una dipendenza del carico di lavoro. Il team della piattaforma garantisce una connettività di rete affidabile alle API.
Azure Machine Learning viene usato per sviluppare e distribuire la logica di prompt flow usata in questo carico di lavoro.
Gli endpoint online gestiti vengono usati come endpoint PaaS (Platform as a Service) per l'applicazione dell'interfaccia utente della chat, che richiama i prompt flow ospitati da Machine Learning.
Servizio app di Azure viene usato per ospitare l'applicazione Web di esempio per l'interfaccia utente della chat. In questa architettura è anche possibile usare questo servizio per ospitare il flusso del prompt in contenitori per un maggiore controllo sull'ambiente host che esegue il prompt flow. Servizio app di Azure ha tre istanze, ognuna in una zona di Azure diversa.
AI Search è un servizio comune usato nei flussi dietro le applicazioni di chat. AI Search può essere usato per recuperare i dati indicizzati rilevanti per le query utente.
Archiviazione di Azure viene usato per rendere persistenti i file di origine del prompt flow per lo sviluppo del prompt flow.
Registro contenitori di Azure viene usato per archiviare i flussi inseriti in un pacchetto come immagini del contenitore.
Gateway applicazione di Azure viene usato come proxy inverso per instradare le richieste utente all'interfaccia utente di chat ospitata in servizio app. Lo SKU selezionato viene usato anche per ospitare un web application firewall di Azure per proteggere l'applicazione front-end da traffico potenzialmente dannoso.
Key Vault viene usato per archiviare segreti e certificati dell'applicazione.
Monitoraggio di Azure, log di Monitoraggio di Azure 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 per gestire, proteggere e applicare controlli su larga scala.
Il team del carico di lavoro gestisce le risorse 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.
Risorse di proprietà del team della piattaforma
Il team della piattaforma possiede e gestisce queste risorse centralizzate. Questa architettura presuppone che queste risorse vengano sottoposte a pre-provisioning e che le considerino dipendenze.
Firewall di Azure nella rete hub viene usato per instradare, controllare e limitare il traffico in uscita. Il traffico in uscita del carico di lavoro passa a Internet, a destinazioni cross-premise o ad altre zone di destinazione dell'applicazione.
Modifica rispetto alla linea di base: questo componente è una novità di questa architettura. Firewall di Azure non è conveniente o pratico per ogni team del carico di lavoro per gestire la propria istanza.
Azure Bastion nella rete hub fornisce accesso operativo sicuro ai componenti del carico di lavoro e consente anche l'accesso ai componenti di Azure AI Studio.
Modifica dalla baseline: il team del carico di lavoro è proprietario di questo componente nell'architettura di base.
La rete virtuale spoke è la posizione in cui viene distribuito il carico di lavoro.
Modifica dalla baseline: il team del carico di lavoro è proprietario di questa rete nell'architettura di base.
Le route definite dall'utente vengono usate per forzare il tunneling nella rete hub.
Modifica rispetto alla linea di base: questo componente è una novità di questa architettura.
I vincoli di governance basati su Criteri di Azure e
DeployIfNotExistsi criteri DINE fanno parte della sottoscrizione del carico di lavoro. È possibile applicare questi criteri a livello di gruppo di gestione di proprietà del team della piattaforma o applicarli direttamente alla sottoscrizione del carico di lavoro.Modifica rispetto alla linea di base: questi criteri sono nuovi in questa architettura.
Le zone DNS privato di Azure ospitano i
Arecord per gli endpoint privati. Per maggiori informazioni, consultare la sezione Collegamento privato e integrazione DNS su larga scala.Modifica dalla linea di base: questo componente viene spostato nell'hub ed è gestito dalla piattaforma.
Servizio di risoluzione DNS per reti virtuali spoke e workstation cross-premise. Tale servizio assume in genere la forma di Firewall di Azure come proxy DNS o resolver privato DNS di Azure. In questa architettura, questo servizio risolve i record DNS dell'endpoint privato per tutte le richieste DNS che hanno origine nello spoke.
Protezione DDoS di Azure viene usato per proteggere gli indirizzi IP pubblici da attacchi distribuiti.
Passare dalla baseline: il team del carico di lavoro acquista protezione DDoS nell'architettura di base.
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à. La sottoscrizione include anche altre risorse, ad esempio Azure ExpressRoute, Gateway VPN di Azure e Resolver privato DNS. Queste risorse forniscono l'accesso cross-premise e la risoluzione dei nomi. La gestione di queste risorse non rientra nell'ambito di questo articolo.
Configurazione sottoscrizione
In un contesto di zona di destinazione, il team del carico di lavoro che implementa questa architettura deve informare il team della piattaforma dei requisiti specifici. Il team della piattaforma deve quindi comunicare i propri requisiti al team del carico di lavoro.
Ad esempio, 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.
Il team della piattaforma assegna un gruppo di gestione appropriato in base ai requisiti aziendali e tecnici del carico di lavoro. Un esempio è se un carico di lavoro viene esposto a Internet come in questa architettura. Il team della piattaforma stabilisce la governance configurando e implementando i gruppi di gestione. Il team del carico di lavoro deve progettare e gestire il carico di lavoro entro i vincoli della governance. Per maggiori informazioni sulle distinzioni tipiche dei gruppi di gestione, consultare la sezione Personalizzare l'architettura della zona di destinazione di Azure.
In definitiva, il team della piattaforma configura la sottoscrizione per questa architettura. Le sezioni seguenti forniscono indicazioni sulla configurazione iniziale della sottoscrizione in relazione a questa architettura.
Requisiti e adempimenti del carico di lavoro
Per questa architettura, il team del carico di lavoro e il team della piattaforma devono collaborare su alcuni argomenti: assegnazione del gruppo di gestione, tra cui la governance Criteri di Azure associata e la configurazione della rete. Preparare un elenco di controllo dei requisiti per avviare discussioni e negoziazione con il team della piattaforma. Questo elenco di controllo funge da esempio nel contesto di questa architettura.
| Argomento | Requisito del carico di lavoro per questa architettura | |
|---|---|---|
| ☐ | Numero di reti virtuali spoke e relative dimensioni. Il team della piattaforma deve conoscere il numero di spoke perché crea e configura la rete virtuale e lo rende uno spoke eseguendo il peering all'hub centrale. Devono anche assicurarsi che la rete sia abbastanza grande per supportare la crescita futura. | È necessaria una sola rete virtuale dedicata per uno spoke. Tutte le risorse vengono distribuite in tale rete. Richiedere /22 spazio indirizzi contiguo per operare su larga scala o gestire situazioni, ad esempio distribuzioni side-by-side. La maggior parte dei requisiti degli indirizzi IP è basata su: - Gateway applicazione requisiti per le dimensioni della subnet (dimensione fissa). - Endpoint privati con indirizzi IP singoli per i servizi PaaS (dimensione fissa). - Dimensioni della subnet per gli agenti di compilazione (dimensione fissa). - Distribuzioni blu/verde di calcolo del prompt flow (dimensione variabile). |
| ☐ | Area di distribuzione. Il team della piattaforma usa queste informazioni per assicurarsi di avere un hub distribuito nella stessa area delle risorse del carico di lavoro. | La disponibilità è limitata per Azure OpenAI in determinate aree. Comunicare l'area scelta. Comunicare anche l'area o le aree in cui vengono distribuite le risorse di calcolo sottostanti. Le aree selezionate devono supportare le zone di disponibilità. |
| ☐ | Tipo, volume e modello di traffico. Il team della piattaforma usa queste informazioni per determinare i requisiti di ingresso e uscita delle risorse condivise usate dal carico di lavoro. | Includere informazioni su: - Come gli utenti devono usare questo carico di lavoro. - Come questo carico di lavoro utilizza le risorse circostanti. - Protocollo di trasporto configurato. - Il modello di traffico e le ore di punta previste e non di punta. Quando si prevede un numero elevato di connessioni simultanee a Internet (chatty) e quando si prevede che il carico di lavoro generi traffico di rete minimo (rumore di fondo). |
| ☐ | Configurazione del firewall. Il team della piattaforma usa queste informazioni per impostare le regole per consentire il traffico in uscita legittimo. | Informare il team della piattaforma di informazioni specifiche correlate al traffico che lascia la rete spoke. - Creare agenti e jump box machine richiedono l'applicazione regolare di patch al sistema operativo. - Il calcolo invia i dati di telemetria del sistema operativo. - In un approccio alternativo, il codice del prompt flow ospitato da servizio app richiede l'accesso a Internet. |
| ☐ | Traffico in ingresso da ruoli specializzati. Il team della piattaforma usa queste informazioni per consentire ai ruoli specificati di accedere al carico di lavoro, implementando al tempo stesso la segmentazione corretta. | Collaborare con il team della piattaforma per determinare il modo migliore per consentire l'accesso autorizzato per: - Data scientist per accedere all'interfaccia utente Web di Machine Learning dalle workstation nelle connessioni di rete aziendali. - Operatori per accedere al livello di calcolo tramite il jump box gestito dal team del carico di lavoro. |
| ☐ | Accesso Internet pubblico al carico di lavoro. Il team della piattaforma usa queste informazioni per la valutazione dei rischi, che guida le decisioni su: - Posizionamento del carico di lavoro in un gruppo di gestione con protezioni appropriate. - Protezione da DDoS per l'indirizzo IP pubblico segnalato dal team del carico di lavoro. - Emissione e gestione dei certificati TLS (Transport Layer Security). |
Informare il team della piattaforma sul profilo del traffico in ingresso: - Il traffico con origine Internet è destinato all'indirizzo IP pubblico in gateway applicazione. - Nomi di dominio completi (FQDN) associati all'indirizzo IP pubblico per l'approvvigionamento dei certificati TLS. |
| ☐ | Utilizzo dell'endpoint privato. Il team della piattaforma usa queste informazioni per configurare le zone di DNS privato di Azure per tali endpoint e assicurarsi che il firewall nella rete hub possa eseguire la risoluzione DNS. | Informare il team della piattaforma su tutte le risorse che usano endpoint privati, ad esempio: - AI Search - Registro contenitori - Key Vault - Azure OpenAI - Account di archiviazione Avere una chiara comprensione del modo in cui la risoluzione DNS viene gestita nell'hub e le responsabilità del team del carico di lavoro per la gestione dei record di zona DNS privati. |
| ☐ | Risorse di intelligenza artificiale centralizzate. Il team della piattaforma deve essere a conoscenza del modello previsto e dell'uso della piattaforma di hosting perché il team della piattaforma usa queste informazioni per stabilire la rete per tutte le risorse di intelligenza artificiale centralizzate stabilite nell'organizzazione. Le organizzazioni creano piani univoci di adozione e governance dell'IA che i team del carico di lavoro saranno vincolati da . | Informare il team della piattaforma su tutte le risorse di intelligenza artificiale e Machine Learning che devono essere usate. In questa architettura, questi servizi sono: - Azure OpenAI - studio di Azure Machine Learning Avere una chiara comprensione dei servizi di intelligenza artificiale centralizzati che devono essere usati e quali sono le dipendenze da tali offerte per il carico di lavoro. |
Importante
È consigliabile un processo di 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 implementare le sottoscrizioni. Per maggiori informazioni, consultare la sezione Vendita di abbonamenti.
Calcolo
L'ambiente di calcolo che ospita il prompt flow e l'interfaccia utente della chat rimane identica all'architettura di base.
Un'organizzazione potrebbe imporre requisiti al team del carico di lavoro che impone l'uso di un runtime di Machine Learning specifico. Ad esempio, il requisito potrebbe essere quello di evitare runtime automatici o runtime dell'istanza di calcolo e favorisce invece un host contenitore del prompt flow che soddisfi i requisiti di conformità, sicurezza e osservabilità.
La governance dell'organizzazione potrebbe aggiungere altri requisiti per la manutenzione dell'immagine di base del contenitore e il rilevamento dei pacchetti di dipendenza rispetto ai requisiti del carico di lavoro indicati. I team del carico di lavoro devono assicurarsi che l'ambiente di runtime del carico di lavoro, il codice distribuito e le relative operazioni siano allineati a questi standard dell'organizzazione.
Approccio alternativo all'hosting del codice del prompt flow
Anziché ospitare il codice del prompt flow in un ambiente di runtime di Machine Learning, è possibile ospitarlo in servizio app. In questo approccio, il traffico in uscita viene controllato rispetto alla rete virtuale gestita di calcolo di Machine Learning. La logica stessa non cambia, ma le istanze di servizio app richiedono l'accesso a Internet.
Rete
Nell'architettura di base viene effettuato il provisioning del carico di lavoro in una singola rete virtuale.
Passaggio dalla baseline: il carico di lavoro viene suddiviso in modo efficace su due reti virtuali. Una rete è per i componenti del carico di lavoro e una per controllare la connettività Internet e ibrida. Il team della piattaforma determina il modo in cui la rete virtuale del carico di lavoro si integra con l'architettura di rete più grande dell'organizzazione, in genere con una topologia hub-spoke.
Questo diagramma dell'architettura ha una casella blu nella sottoscrizione della zona di destinazione dell'applicazione con etichetta superiore che contiene una rete virtuale spoke. Nella rete virtuale sono presenti cinque caselle. Le caselle sono etichettate snet-appGateway, snet-agents, snet-jumpbox, snet-appServicePlan e snet-privateEndpoints. Ogni subnet ha un logo del gruppo di sicurezza di rete e tutte le subnet snet-appGateway hanno una route definita dall'utente a livello di hub. Il traffico in ingresso proveniente da utenti locali e esterni punta al gateway applicazione. Un utente del data scientist è connesso al gateway VPN o a ExpressRoute nella parte inferiore del diagramma con etichetta di sottoscrizione della connettività. La sottoscrizione di connettività contiene zone DNS private per collegamento privato, resolver privato DNS e protezione DDoS. La rete virtuale hub contenuta nella sottoscrizione di connettività e la rete virtuale spoke sono connesse con un peering di rete virtuale con etichetta linea. Nella rete virtuale spoke è presente testo che legge il DNS fornito dall'hub.
Scaricare un file di Visio di questa architettura.
Rete virtuale hub: hub a livello di area che contiene servizi centralizzati e spesso condivisi che comunicano con le risorse del carico di lavoro nella stessa area. L'hub si trova nella sottoscrizione di connettività. Il team della piattaforma possiede le risorse in questa rete.
Rete virtuale spoke: in questa architettura, la singola rete virtuale dall'architettura di base diventa essenzialmente la rete spoke. La rete virtuale viene con peering alla rete hub dal team della piattaforma. Il team della piattaforma possiede e gestisce questa rete spoke, il peering e la configurazione DNS. Questa rete contiene molte delle risorse del carico di lavoro. Il team del carico di lavoro è proprietario delle risorse in questa rete, incluse le relative subnet.
A causa di questa suddivisione della gestione e della proprietà, assicurarsi di comunicare chiaramente i requisiti del carico di lavoro al team della piattaforma.
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. A meno che i team della zona di destinazione dell'applicazione non siano connessi con endpoint privati autogestiti, il team deve facilitare tutte le connessioni di rete virtuale transitive. Avere una buona conoscenza delle risorse usate da questo carico di lavoro gestite da team esterni all'ambito di questo team del carico di lavoro. Ad esempio, comprendere la connettività di rete tra il prompt flow e un database vettoriale gestito da un altro team.
Subnet della rete virtuale
Nella rete virtuale spoke il team del carico di lavoro crea e alloca le subnet allineate ai requisiti del carico di lavoro. L'inserimento di controlli per limitare il traffico all'interno e all'esterno delle subnet consente di fornire la segmentazione. Questa architettura non aggiunge subnet oltre a quelle subnet descritte nell'architettura di base. L'architettura di rete, tuttavia, non richiede più la AzureBastionSubnet subnet perché il team della piattaforma ospita questo servizio nelle sottoscrizioni.
È comunque necessario implementare controlli di rete locali quando si distribuisce il carico di lavoro in una zona di destinazione di Azure. Le organizzazioni potrebbero imporre ulteriori restrizioni di rete per proteggersi dall'esfiltrazione dei dati e garantire la visibilità per il centro operativo di sicurezza centrale (SOC) e il team della rete IT.
Traffico in ingresso
Il flusso del traffico in ingresso rimane uguale all'architettura di base.
Il team 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 inseriti nella rete spoke e non nella rete hub. Alcune organizzazioni potrebbero inserire risorse con traffico in ingresso in una sottoscrizione di connettività usando una rete perimetrale centralizzata (nota anche come rete perimetrale, zona demilitarizzata e subnet schermata). L'integrazione con tale topologia specifica non rientra nell'ambito di questo articolo.
Approccio alternativo per controllare il traffico in ingresso
Questa architettura non usa Firewall di Azure per controllare il traffico in ingresso. A volte la governance organizzativa richiede questo approccio. I team della piattaforma supportano l'implementazione per fornire ai team del carico di lavoro un ulteriore livello di rilevamento e prevenzione delle intrusioni per bloccare il traffico in ingresso indesiderato. Questa architettura richiede più configurazioni UDR per supportare questa topologia. Per maggiori informazioni su questo approccio, consultare la sezione Rete Zero Trust per le applicazioni Web con Firewall di Azure e Gateway applicazione.
Configurazione del DNS
Nell'architettura di base, DNS di Azure viene usato direttamente da tutti i componenti per la risoluzione DNS.
Passaggio dalla linea di base: DNS viene in genere delegato a uno o più server DNS nell'hub. Quando viene creata la rete virtuale per questa architettura, è previsto che le proprietà DNS nella rete virtuale siano già impostate di conseguenza. Il servizio DNS è considerato opaco per il team del carico di lavoro.
I componenti del carico di lavoro in questa architettura vengono configurati con DNS nei modi seguenti.
| Componente | Configurazione del DNS |
|---|---|
| Gateway applicazione | Ereditato dalla rete virtuale. |
| Servizio app (interfaccia utente della chat) | Il team del carico di lavoro configura l'app Web per l'uso dei server DNS hub tramite la dnsConfiguration proprietà. |
| Servizio app (prompt flow) | Il team del carico di lavoro imposta l'app Web per l'uso dei server DNS hub tramite la dnsConfigurationproprietà. |
| AI Search | Non è possibile eseguire l'override, usa DNS di Azure. |
| Cluster ambiente di calcolo di Machine Learning | ▪ Non è possibile eseguire l'override della rete virtuale gestita e usare DNS di Azure. Questa architettura usa questo approccio. ▪ Integrazione della rete virtuale, ereditata dalla rete virtuale. |
| Runtime automatico di Machine Learning | ▪ Non è possibile eseguire l'override della rete virtuale gestita, usa DNS di Azure. ▪ Integrazione della rete virtuale, ereditata dalla rete virtuale. Questa architettura non usa il runtime automatico. |
| Istanza ambiente di calcolo di Machine Learning | ▪ Non è possibile eseguire l'override della rete virtuale gestita, usa DNS di Azure. Questa architettura usa questo approccio. ▪ Integrazione della rete virtuale, ereditata dalla rete virtuale. |
| OpenAI di Azure | Non è possibile eseguire l'override, usa DNS di Azure. |
| Jump box | Ereditato dalla rete virtuale. |
| Agenti di compilazione | Ereditato dalla rete virtuale. |
Nessuna impostazione DNS è configurata per i componenti rimanenti nell'architettura perché non viene eseguita alcuna comunicazione in uscita da tali servizi. Non è necessaria alcuna risoluzione DNS per tali componenti.
Molti di questi componenti richiedono record DNS appropriati nei server DNS dell'hub per risolvere i numerosi endpoint privati di questo carico di lavoro. Per maggiori informazioni, consultare la sezione Zone DNS privato di Azure. Per i componenti in cui la risoluzione DNS basata su hub non può verificarsi, si riscontrano le limitazioni seguenti:
Il team della piattaforma non può registrare le richieste DNS, che potrebbe essere un requisito del team di sicurezza aziendale.
La risoluzione di collegamento privato di Azure servizi esposti nella zona di destinazione o in altre zone di destinazione dell'applicazione potrebbe essere impossibile. Alcuni servizi, ad esempio i calcoli di Machine Learning, ovviano a questa limitazione tramite funzionalità specifiche del servizio.
È consigliabile acquisire familiarità con il modo in cui il team della piattaforma gestisce IL DNS. Per maggiori informazioni, consultare la sezione Collegamento privato e integrazione DNS su larga scala. Quando si aggiungono funzionalità dei componenti che dipendono direttamente da DNS di Azure, è possibile introdurre complessità nella topologia DNS fornita dalla piattaforma. È possibile riprogettare componenti o negoziare eccezioni per ridurre al minimo la complessità.
Traffico in uscita
Nell'architettura di base, il controllo internet in uscita è disponibile solo tramite la configurazione di rete nelle aree di lavoro di Machine Learning e servizio app, in combinazione con l'uso di gruppi di sicurezza di rete nelle varie subnet.
Modifica dalla linea di base: i controlli in uscita sono ulteriormente aumentati. Tutto il traffico che lascia la rete virtuale spoke viene reindirizzato attraverso la rete hub con peering tramite un firewall in uscita. Il traffico originato all'interno della rete virtuale gestita per i calcoli di Machine Learning non è soggetto a questa route in uscita.
La sezione superiore di questo diagramma dell'architettura è denominata sottoscrizione della zona di destinazione dell'applicazione e contiene una casella di rete virtuale spoke e una casella di Machine Learning. La casella Machine Learning contiene endpoint privati per Archiviazione, Registro Contenitori, Ricerca intelligenza artificiale e Azure OpenAI. La casella della rete virtuale spoke contiene cinque subnet: snet-appGateway, snet-agents, snet-jumpbox, snet-appServicePlan e snet-privateEndpoints. Tutte le subnet, ad eccezione di snet-appGateway, hanno una linea tratteggiata che li porta a Firewall di Azure, che si trova nella casella inferiore. La casella inferiore è denominata "Sottoscrizione di connettività". Firewall di Azure ha la stessa linea di stile che punta a Internet rappresentata come cloud. La casella di Machine Learning ha lo stesso stile di linea tratteggiato che punta anche al cloud Internet. La casella superiore legge Dove possibile tutto il traffico associato a Internet ha origine dal carico di lavoro attraverso l'hub a causa della route definita dall'utente 0.0.0.0/0. La rete virtuale hub nella casella inferiore e la rete virtuale spoke nella casella superiore sono connesse con una riga che legge il peering di rete virtuale.
Scaricare un file di Visio di questa architettura.
La comunicazione client east-west con gli endpoint privati per Registro Contenitori, Key Vault, Azure OpenAI e altri rimane invariata dell'architettura di base. Tale percorso viene omesso dal diagramma precedente per brevità.
Traffico Internet routing al firewall
Una route è collegata a tutte le subnet possibili nella rete spoke che indirizza tutto il traffico diretto verso Internet (0.0.0.0/0) prima al Firewall di Azure dell'hub.
| Componente | Meccanismo per forzare il traffico Internet attraverso l'hub |
|---|---|
| Gateway applicazione | Nessuno. Il traffico associato a Internet proveniente da questo servizio non può essere forzato tramite un firewall del team della piattaforma. |
| Servizio app (interfaccia utente della chat) | L'integrazione rete virtuale regionale è abilitata. vnetRouteAllEnabled è abilitato. |
| Servizio app (prompt flow) | L'integrazione rete virtuale regionale è abilitata. vnetRouteAllEnabled è abilitato. |
| AI Search | Nessuno. Il traffico proveniente da questo servizio non può essere forzato attraverso un firewall. Questa architettura non usa competenze. |
| Cluster ambiente di calcolo di Machine Learning | ▪ Rete virtuale gestita: il traffico associato a Internet proveniente da questo servizio non può essere forzato tramite un firewall del team della piattaforma. Questa architettura usa questo approccio. ▪ Integrazione della rete virtuale: usa una route definita dall'utente applicata alla subnet che contiene il cluster di calcolo. |
| Runtime automatico di Machine Learning | ▪ Rete virtuale gestita: il traffico associato a Internet proveniente da questo servizio non può essere forzato tramite un firewall del team della piattaforma. ▪ Integrazione della rete virtuale: usa una route definita dall'utente applicata alla subnet che contiene il cluster di calcolo. Questa architettura non usa il runtime automatico. |
| Istanza ambiente di calcolo di Machine Learning | ▪ Rete virtuale gestita: il traffico associato a Internet proveniente da questo servizio non può essere forzato tramite un firewall del team della piattaforma. Questa architettura usa questo approccio. ▪ Integrazione della rete virtuale: usa una route definita dall'utente applicata alla subnet che contiene il cluster di calcolo. |
| OpenAI di Azure | Nessuno. Il traffico proveniente da questo servizio, ad esempio tramite la funzionalità dei dati, non può essere forzato tramite un firewall. Questa architettura non usa alcuna di queste funzionalità. |
| Jump box | Usa la route definita dall'utente applicata a snet-jumpbox. |
| Agenti di compilazione | Usa la route definita dall'utente applicata a snet-agents. |
Non sono configurate impostazioni del tunnel forzato per i componenti che rimangono nell'architettura perché non viene eseguita alcuna comunicazione in uscita da tali servizi.
Per i componenti o le funzionalità dei componenti in cui il controllo in uscita tramite il routing hub non è possibile, il team del carico di lavoro deve essere allineato ai requisiti dell'organizzazione in questo traffico. Usare controlli di compensazione, riprogettare il carico di lavoro per escludere queste funzionalità o cercare eccezioni formali. I carichi di lavoro sono in ultima analisi responsabili della mitigazione dell'esfiltrazione e dell'abuso dei dati.
Applicare la route Internet fornita dalla piattaforma a tutte le subnet, anche se la subnet non prevede il traffico in uscita. Questo approccio garantisce che eventuali distribuzioni impreviste in tale subnet siano soggette a filtri in uscita di routine. Assicurarsi che le subnet che contengono endpoint privati dispongano di criteri di rete abilitati per il routing completo e il controllo NSG.
Quando si applica questa configurazione di route all'architettura, tutte le connessioni in uscita da servizio app, un'area di lavoro di Machine Learning o qualsiasi altro servizio originato nella rete virtuale del carico di lavoro vengono esaminate e controllate.
Zone di DNS privato di Azure
Le architetture che usano endpoint privati per il traffico east-west all'interno del carico di lavoro richiedono record di zona DNS nel provider DNS configurato. Questa architettura richiede il corretto funzionamento di molti record di zona DNS: Key Vault, Azure OpenAI e altro ancora per supportare Collegamento privato.
Passaggio dalla baseline: il team del carico di lavoro è direttamente responsabile delle zone DNS private nell'architettura di base. Nell'architettura della zona di destinazione, il team della piattaforma gestisce in genere zone DNS privato. Potrebbero usare un'altra tecnologia, ma per questa architettura si tratta di record di zona DNS privato. Il team del carico di lavoro deve comprendere chiaramente i requisiti e le aspettative del team della piattaforma per la gestione di tali record di zona DNS privato.
In questa architettura, il team della piattaforma deve garantire l'hosting DNS affidabile e tempestivo per gli endpoint Collegamento privato seguenti:
- AI search
- OpenAI di Azure
- Registro Container
- Insieme di credenziali delle chiavi di
- Account di archiviazione
Accesso all'autorizzazione del prompt flow e al data scientist
Analogamente all'architettura di base, l'accesso in ingresso pubblico all'area di lavoro di Machine Learning e altre esperienze basate su browser sono disabilitate. L'architettura di base distribuisce un jump box per fornire a un browser un indirizzo IP di origine dalla rete virtuale usata da vari ruoli del carico di lavoro.
Quando il carico di lavoro è connesso a una zona di destinazione di Azure, sono disponibili altre opzioni per il team per questo accesso. Collaborare con il team della piattaforma per verificare se è possibile ottenere l'accesso privato ai vari studi di intelligenza artificiale basati su browser senza la necessità di gestire e gestire una macchina virtuale (VM). Questo accesso può essere ottenuto tramite l'accesso transitivo da una connessione ExpressRoute o Gateway VPN già stabilita. L'accesso nativo basato su workstation richiede il routing cross-premise e la risoluzione DNS, che il team della piattaforma può fornire. Rendere noto questo requisito nella richiesta di vendita di abbonamenti.
Fornire l'accesso nativo basato su workstation a questi portali è un miglioramento della produttività rispetto alla linea di base e può essere più semplice da gestire rispetto ai jumpbox delle macchine virtuali.
Ruolo del jump box
Avere una jump box in questa architettura è utile ma non a scopo di runtime o di intelligenza artificiale o di sviluppo di Machine Learning. La jumpbox può risolvere i problemi di routing dns e di rete perché fornisce l'accesso alla rete interna a componenti altrimenti inaccessibili esternamente.
Nell'architettura di base, Azure Bastion accede alla jump box, gestita dal team del carico di lavoro.
In questa architettura, Azure Bastion viene distribuito all'interno della sottoscrizione di connettività come risorsa a livello di area condivisa gestita dal team della piattaforma. Per dimostrare che il caso d'uso in questa architettura, Azure Bastion si trova nella sottoscrizione di connettività e non è più distribuito dal team del carico di lavoro.
La macchina virtuale usata come jump box deve essere conforme ai requisiti dell'organizzazione per le macchine virtuali. Questi requisiti possono includere elementi come le identità aziendali in Microsoft Entra ID, immagini di base specifiche e regimi di applicazione di patch.
Monitorare le risorse
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 gestione delle prestazioni delle applicazioni (APM) per il team del carico di lavoro. Questa funzionalità è configurata nell'interfaccia utente della chat e nel codice del prompt flow.
L'area di lavoro Log di Monitoraggio di Azure come sink unificato per tutti i log e le metriche raccolti dalle risorse di Azure di proprietà del carico di lavoro.
Analogamente alla baseline, tutte le risorse sono configurate per inviare i log Diagnostica di Azure all'area di lavoro Log di Monitoraggio di Azure 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 dei log di Monitoraggio di Azure centrale. Nelle zone di destinazione di Azure l'area di lavoro si trova in genere nella sottoscrizione di gestione.
Il team della piattaforma potrebbe anche avere processi che influiscono sulle risorse della zona di destinazione dell'applicazione. Ad esempio, potrebbero usare i criteri DINE per configurare la diagnostica e inviare i log alle sottoscrizioni di gestione centralizzate. In alternativa, è possibile usare gli avvisi di base di Monitoraggio applicati tramite i criteri. È importante assicurarsi che l'implementazione non limiti i flussi aggiuntivi di log e avvisi.
Criteri di Azure
L'architettura di base consiglia alcuni criteri generali per gestire il carico di lavoro. Quando si distribuisce questa architettura in una zona di destinazione dell'applicazione, non è necessario aggiungere o rimuovere altri criteri. Continuare ad applicare criteri alla sottoscrizione, ai gruppi di risorse o alle risorse che consentono di applicare la governance e migliorare la sicurezza di questo carico di lavoro.
Si prevede che la sottoscrizione della zona di destinazione dell'applicazione disponga di criteri già applicati, anche prima della distribuzione del carico di lavoro. Alcuni criteri consentono la governance dell'organizzazione controllando o bloccando configurazioni specifiche nelle distribuzioni. Di seguito alcuni criteri di esempio che potrebbero portare a complessità di distribuzione del carico di lavoro:
Criterio: "I segreti [in Key Vault] devono avere il periodo di validità massimo specificato."
Complicazione: Machine Learning gestisce i segreti nell'insieme di credenziali delle chiavi del carico di lavoro e tali segreti non hanno una data di scadenza impostata.
Criterio: "Le aree di lavoro di Azure Machine Learning devono essere crittografate con una chiave gestita dal cliente."
Complicazione: questa architettura non è progettata esclusivamente per gestire le chiavi gestite dal cliente. Tuttavia, può essere esteso per usarli.
I team della piattaforma possono applicare criteri DINE per gestire le distribuzioni automatizzate in una sottoscrizione della zona di destinazione dell'applicazione. Incorporare e testare in modo preliminare le restrizioni e 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.
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 delle zone di destinazione 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, ad esempio le modifiche del firewall, possono influire su più carichi di lavoro.
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 in anticipo in modo che non influiscano negativamente sui carichi di lavoro.
Modifiche della piattaforma che influiscono su questo 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 li implementi 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.
Esempio: un criterio non consente più la distribuzione di istanze OpenAI di Azure che supportano l'accesso alla chiave API.
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. Questi potenziali problemi si applicano sia al firewall in uscita che alle regole del gruppo di sicurezza di rete applicate da Azure Rete virtuale Manager.
Esempio: i server di aggiornamento del fornitore bloccati generano aggiornamenti del sistema operativo non riusciti nella jump box o negli agenti di compilazione.
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.
Esempio: impedisce al prompt flow di accedere a un archivio vettoriale gestito da un altro team o team di data science di accedere alle esperienze basate su browser nei portali di intelligenza artificiale dalle workstation.
Host Azure Bastion: modifiche alla disponibilità o alla configurazione dell'host Azure Bastion.
Esempio: impedisce l'accesso alle jumpbox e alle macchine virtuali dell'agente di compilazione.
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 del 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. Questa architettura è principalmente autonoma e probabilmente non riscontrerà un cambiamento significativo nei modelli di traffico in uscita.
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.
Esempio: in questa architettura, se si rimuove l'indirizzo IP pubblico da gateway applicazione e si rende questa applicazione solo interna, l'esposizione del carico di lavoro alle modifiche a Internet. Un altro esempio è se i portali di intelligenza artificiale basati su browser vengono modificati per essere esposti a Internet, che non è consigliato.
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.
Esempio: il carico di lavoro può passare da basso ad alto livello aziendale con un aumento dell'adozione e del successo del carico di lavoro.
Affidabilità
Questa architettura è allineata alle garanzie di affidabilità nell'architettura di base. Non esistono nuove considerazioni sull'affidabilità per i componenti principali del carico di lavoro.
Obiettivi di affidabilità
Il massimo obiettivo del livello di servizio composito (SLO) per questa architettura è inferiore rispetto all'obiettivo del livello di servizio composito (SLO) previsto a causa di nuovi 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.
Dipendenze critiche
Visualizzare tutte le funzionalità eseguite dal carico di lavoro nella piattaforma e nella zona 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 del carico di lavoro seguenti:
Firewall in uscita: il firewall in uscita centralizzato, condiviso da più carichi di lavoro, subisce modifiche non correlate al carico di lavoro.
Risoluzione DNS: questa architettura usa DNS fornito dal team della piattaforma anziché interfacciarsi direttamente con DNS di Azure. Ciò significa che gli aggiornamenti tempestivi ai record DNS per gli endpoint privati e la disponibilità dei servizi DNS sono nuove dipendenze.
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 quando vengono applicati. Ad esempio, un ritardo nella configurazione DNS per gli endpoint privati di questa architettura può causare ritardi nell'idoneità dell'interfaccia utente della chat per gestire il traffico o il prompt flow dal completamento delle query.
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 maggiori informazioni, consultare la sezione 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 le esigenze siano soddisfatte. Per maggiori informazioni, consultare la sezione Raccomandazioni per l'esecuzione dell'analisi della modalità di errore.
Sicurezza
Le raccomandazioni nelle sezioni seguenti si basano sull'elenco di controllo per la revisione della progettazione della sicurezza in Well-Architected Framework.
Controllo del traffico in ingresso
Isolare il carico di lavoro da altri spoke del carico di lavoro all'interno dell'organizzazione usando gruppi di sicurezza di rete nelle subnet e la natura non transitiva o i controlli nell'hub regionale. 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 non transitiva della rete hub per la sicurezza.
Il team della piattaforma implementa i criteri di Azure per la sicurezza. Ad esempio, un criterio potrebbe garantire che gateway applicazione abbia un Web application firewall impostato su modalità Nega, che limita il numero di indirizzi IP pubblici disponibili per la sottoscrizione. Oltre a questi criteri, il team del carico di lavoro deve distribuire criteri incentrati sul carico di lavoro che rafforzano il comportamento di sicurezza in ingresso.
La tabella seguente mostra esempi di controlli di ingresso in questa architettura.
| Origine | Scopo | Controllo del carico di lavoro | Controllo della piattaforma |
|---|---|---|---|
| Internet | Flussi di traffico applicazione | Indirizza tutte le richieste del carico di lavoro 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 per l'interfaccia utente della chat. | None |
| Internet | Accesso a Studio | Nega tutto tramite la configurazione a livello di servizio. | None |
| Internet | Accesso al piano dati a tutti i gateway applicazione | Nega tutto tramite NSG e la configurazione a livello di servizio. | None |
| Azure Bastion | Accesso all'agente di compilazione e jump box | Gruppo di sicurezza di rete nella subnet jump box che blocca tutto il traffico verso le porte di accesso remoto, a meno che non venga originato dalla subnet di Azure Bastion designata della piattaforma | None |
| Cross-premise | Accesso a Studio | Rifiuta tutto. A meno che non venga usata la jump box, consentire solo le workstation da subnet autorizzate per l'accesso al data scientist. | Routing non transitivo o Firewall di Azure se viene usato un hub protetto rete WAN virtuale di Azure |
| Altri spoke | None | Bloccato tramite regole del gruppo di sicurezza di rete. | Routing non transitivo o Firewall di Azure se viene usato un hub protetto rete WAN virtuale |
Controllo del 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.
Anche se si è proprietari delle subnet del carico di lavoro 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. Collaborare con il team di rete per garantire la continuità del controllo in uscita con accesso minimo.
La tabella seguente mostra esempi di traffico in uscita in questa architettura.
| Endpoint | Scopo | Controllo del carico di lavoro | Controllo della piattaforma |
|---|---|---|---|
| Origini Internet pubbliche | Il prompt flow potrebbe richiedere una ricerca Internet per integrare una richiesta OpenAI di Azure | Gruppo di sicurezza di rete nella subnet host del contenitore del prompt flow o nella configurazione della rete virtuale gestita da Machine Learning | Tolleranza della regola di rete del firewall per lo stesso controllo del carico di lavoro |
| Piano dati OpenAI di Azure | Il prompt flow di hosting di calcolo chiama questa API per la gestione delle richieste | TCP/443 alla subnet dell'endpoint privato dalla subnet che contiene il prompt flow | None |
| Insieme di credenziali delle chiavi di | Per accedere ai segreti dall'interfaccia utente della chat o dall'host del prompt flow | TCP/443 alla subnet dell'endpoint privato che contiene Key Vault | None |
Per il traffico che lascia la rete virtuale di questa architettura, i controlli vengono implementati al livello del carico di lavoro tramite gruppi di sicurezza di rete e a livello di piattaforma tramite un firewall di rete hub. I gruppi di sicurezza di rete forniscono regole di traffico di rete iniziali e estese ulteriormente limitate da regole firewall specifiche nella rete hub della piattaforma per una maggiore sicurezza. Non è previsto che il traffico est-ovest all'interno dei componenti del carico di lavoro, ad esempio tra Machine Learning Studio e l'account di archiviazione in questa architettura, venga instradato attraverso l'hub.
Protezione DDoS
Determinare chi deve applicare il piano di protezione DDoS che copre tutti gli indirizzi IP pubblici della soluzione. Il team della piattaforma potrebbe usare i piani di protezione degli indirizzi IP o 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 maggiori informazioni, consultare la sezione Raccomandazioni per la rete e la connettività.
Gestione delle identità e dell'accesso
Se non diversamente richiesto dall'automazione della governance del team della piattaforma, non ci sono aspettative di requisiti di autorizzazione aggiuntivi per questa architettura a causa del coinvolgimento del team della piattaforma. Il controllo degli accessi in base al ruolo (RBAC) di Azure deve continuare a soddisfare il principio dei privilegi minimi, che concede l'accesso limitato solo a coloro che ne hanno bisogno e solo quando necessario. Per maggiori informazioni, consultare la sezione Raccomandazioni per la gestione delle identità e degli accessi.
Certificati e crittografia
Il team del carico di lavoro in genere ottiene il certificato TLS per l'indirizzo IP pubblico in Gateway applicazione in questa architettura. Collaborare con il team della piattaforma per comprendere in che modo i processi di approvvigionamento e gestione dei certificati devono essere allineati alle aspettative dell'organizzazione.
Tutti i servizi di archiviazione dati in questa architettura supportano le chiavi di crittografia gestite da Microsoft o dai clienti. Usare chiavi di crittografia gestite dal cliente se la progettazione o l'organizzazione del carico di lavoro richiede un maggiore controllo. Le zone di destinazione di Azure non impongono l'uno o l'altro.
Ottimizzazione dei costi
Per le risorse del carico di lavoro, tutte 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. 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).
Eccellenza operativa
Il team del carico di lavoro è ancora responsabile di tutte le considerazioni sull'eccellenza operativa trattate nell'architettura di base, ad esempio monitoraggio, GenAIOps, controllo della qualità e procedure di distribuzione sicure.
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 di Monitoraggio di Azure del carico di lavoro. Tuttavia, i log e le metriche dei servizi centralizzati, ad esempio Firewall di Azure, il Resolver DNS privato e Azure Bastion, vengono spesso archiviati in un'area di lavoro dei log di Monitoraggio di Azure 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. Assicurarsi che il runbook di valutazione per questa architettura affronti questa situazione e includa i 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: quando possibile, concedere il controllo degli accessi in base al ruolo per eseguire query e leggere i 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. I team dell'applicazione possono usare queste informazioni per risolvere i problemi relativi alle attività. Per maggiori informazioni, consultare la sezione Raccomandazioni per il monitoraggio e il rilevamento delle minacce.
Agenti di compilazione
Molti servizi in questa architettura usano endpoint privati. Analogamente all'architettura di base, questa progettazione rende potenzialmente gli agenti di compilazione un requisito di questa architettura. La distribuzione sicura e affidabile degli agenti di compilazione è responsabilità del team del carico di lavoro, senza coinvolgere il team della piattaforma. Tuttavia, assicurarsi che la gestione degli agenti di compilazione sia conforme all'organizzazione. Ad esempio, usare immagini del sistema operativo approvate dalla piattaforma, applicazione di patch, report di conformità e metodi di autenticazione utente.
Efficienza prestazionale
Le considerazioni sull'efficienza delle prestazioni descritte nell'architettura di base si applicano anche a questa architettura. Il team del carico di lavoro mantiene il controllo sulle risorse usate nei flussi di domanda, non sul team della piattaforma. Ridimensionare l'host dell'interfaccia utente della chat, l'host del prompt flow, i modelli linguistici e altri in base ai vincoli di carico di lavoro e costi. A seconda dell'implementazione finale dell'architettura, prendere in considerazione i fattori seguenti quando si misurano le prestazioni rispetto agli obiettivi di prestazioni.
- Uscita e latenza cross-premise
- Limitazioni dello SKU derivate dalla governance del contenimento dei costi
Distribuire lo scenario
La distribuzione di una zona di distribuzione per questa architettura di riferimento è disponibile in GitHub.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Chad Kittel | Modelli & procedure di Azure - Microsoft
- Freddy Ayala | Microsoft Cloud Solution Architect
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggio successivo
Esaminare la collaborazione e i dettagli tecnici condivisi tra un team del carico di lavoro e i team della piattaforma.