Condividi tramite


L'implementazione di Microsoft Foundry all'interno della mia organizzazione

Un piano di implementazione strutturato consente di evitare lacune di sicurezza, sovraccarichi dei costi e accesso quando si adotta Microsoft Foundry su larga scala. Questa guida illustra le decisioni chiave per l'implementazione di Foundry, tra cui la configurazione dell'ambiente, l'isolamento dei dati, l'integrazione con altri servizi Azure, la gestione della capacità e il monitoraggio. Usare questa guida come punto di partenza e adattarla alle proprie esigenze. Per informazioni dettagliate sull'implementazione, vedere gli articoli collegati.

Prerequisiti

Prima di iniziare la pianificazione dell'implementazione, verificare di avere:

  • Una strategia di sottoscrizione di Azure e dei gruppi di risorse per gli ambienti di sviluppo, test e produzione.
  • Microsoft Entra ID gruppi (o gruppi di identità equivalenti) definiti per amministratori, project manager e utenti del progetto.
  • Piano di area iniziale basato sul modello e sulla disponibilità delle funzionalità. Per informazioni dettagliate, vedere Disponibilità delle funzionalità tra aree cloud.
  • Accordo sui requisiti di sicurezza per la rete, la crittografia e l'isolamento dei dati nell'organizzazione.

Elenco di controllo per l'implementazione di base

Usa questa checklist prima del tuo primo rollout di produzione.

  1. Definire i limiti dell'ambiente tra sviluppo, test e produzione.
  2. Assegnare la responsabilità per ogni risorsa Foundry e per l'ambito del progetto.
  3. Determinare le funzionalità di Foundry che si prevede di usare. Non tutte le API di funzionalità sono disponibili nel contesto del progetto. Se si prevede di assegnare autorizzazioni all'ambito di progetto più basso per l'isolamento dei casi d'uso, questo potrebbe non essere supportato per le API di intelligenza artificiale classiche Azure, ad esempio Translator. Questi richiedono che ciascun utente disponga delle autorizzazioni sul livello padre della risorsa Foundry. Per questi casi, è consigliabile la segregazione della risorsa Foundry.
  4. Definire le assegnazioni di Controllo degli accessi in base al ruolo per amministratori, responsabili e utenti del progetto.
  5. Definire l'approccio di rete per ogni ambiente (access pubblico, endpoint privato o ibrido).
  6. Decidere se le chiavi gestite dal cliente sono richieste dai criteri.
  7. Definire la proprietà dei costi e del monitoraggio per ogni gruppo aziendale.
  8. Identificare le connessioni condivise necessarie e le connessioni con ambito di progetto.

Organizzazione di esempio

Contoso è un'azienda globale che esplora l'adozione di GenAI in cinque gruppi aziendali, ognuno con esigenze distinte e maturità tecnica.

Per accelerare l'adozione mantenendo la supervisione, Contoso Enterprise IT mira a abilitare un modello con risorse condivise comuni, tra cui rete e data management centralizzata, consentendo al tempo stesso access self-service a Foundry per ogni team all'interno di un ambiente regolamentato e sicuro per gestire i casi d'uso.

Considerazioni sull'implementazione

La risorsa Foundry definisce l'ambito per la configurazione, la protezione e il monitoraggio dell'ambiente del team. È disponibile nel portale foundry e tramite le API di Azure. I progetti sono come cartelle per organizzare il lavoro all'interno di questo contesto di risorse. I progetti controllano anche l'accesso e le autorizzazioni per le API e strumenti per sviluppatori di Foundry.

Importante

I progetti offrono un ambiente sandbox preconfigurato ottimizzato per la creazione dell'agente e le funzionalità native di Foundry. Tuttavia, poiché Foundry è basato su una serie di Servizi di Azure AI classiche, non tutte le API classiche sono disponibili nel contesto del progetto. Identificare le funzionalità che i team prevedono di usare e verificare se supportano l'accesso a livello di progetto. Per i servizi come Translator che richiedono autorizzazioni a livello di risorsa Foundry padre, è consigliabile usare risorse Foundry separate per l'isolamento dei costi e il controllo di accesso.

Screenshot di un diagramma che mostra la risorsa Foundry.

Per garantire coerenza, scalabilità e governance tra i team, prendere in considerazione le procedure di configurazione dell'ambiente seguenti durante l'implementazione di Foundry:

  • Stabilire ambienti distinti per sviluppo, test e produzione. Usare gruppi di risorse o sottoscrizioni separati e risorse Foundry per isolare i flussi di lavoro, gestire access e supportare la sperimentazione con le versioni controllate.

  • Creare una risorsa Foundry separata per ogni gruppo aziendale. Allineare le distribuzioni con limiti logici, ad esempio domini dati o funzioni aziendali, per garantire autonomia, governance e rilevamento dei costi. Prendere in considerazione anche risorse Foundry separate quando i team necessitano di API di intelligenza artificiale classiche di Azure che non supportano l'accesso a livello di progetto.

  • Associare progetti ai casi d'uso. I progetti foundry rappresentano casi d'uso specifici e forniscono contenitori per organizzare componenti come agenti o file per un'applicazione. Anche se ereditano le impostazioni di sicurezza dalla risorsa padre, possono implementare controlli di access personalizzati, integrazione dei dati e altri controlli di governance. Prima di assegnare le autorizzazioni con ambito di progetto, verificare che le API che il vostro team intende utilizzare supportino l'accesso a livello di progetto.

Protezione dell'ambiente Foundry

Foundry è basato sulla piattaforma Azure, quindi è possibile personalizzare i controlli di sicurezza per soddisfare le esigenze dell'organizzazione.

Identità

Usare Microsoft Entra ID per gestire l'accesso utente e servizio. Foundry supporta le identità gestite per consentire l'autenticazione sicura senza password ad altri servizi di Azure. È possibile assegnare identità gestite a livello di risorsa Foundry e facoltativamente a livello di project per un controllo con granularità fine. Per informazioni dettagliate, vedere Controllo degli accessi basato sui ruoli in Foundry.

Rete

Distribuire Foundry in un Rete virtuale per isolare il traffico e controllare l'accesso usando i gruppi di sicurezza di rete. Per gli scenari di connettività privata, utilizza gli endpoint privati e verifica lo stato di approvazione degli endpoint e del DNS. Per informazioni dettagliate sull'implementazione e limitazioni, vedere Come configurare un private link per Foundry.

Importante

Alcune funzionalità, ad esempio agenti e valutazioni, richiedono una configurazione di rete aggiuntiva per l'isolamento end-to-end. Per informazioni dettagliate sull'implementazione e limitazioni correnti, vedere Come configurare l'isolamento di rete per Foundry.

Chiavi gestite dal cliente

Azure supporta chiavi gestite dal cliente (CMK) per crittografare i dati inattivi. Foundry supporta facoltativamente cmk per i clienti con esigenze di conformità rigorose. Per informazioni dettagliate, vedere Chiavi gestite dal cliente in Foundry.

Autenticazione e autorizzazione

Foundry supporta sia l'accesso basato su chiave API per un'integrazione semplice che Azure RBAC per un controllo granulare. Le chiavi API possono semplificare la configurazione, ma non forniscono la stessa granularità basata sui ruoli di Microsoft Entra ID con RBAC (Controllo degli Accessi in Base ai Ruoli). Azure applica una netta separazione tra il piano control (operazioni di gestione delle risorse come la creazione o la configurazione di risorse) e il piano data (operazioni di runtime come la chiamata di modelli e l'accesso ai dati). Iniziare con i ruoli predefiniti e definire ruoli personalizzati in base alle esigenze. Per informazioni dettagliate, vedere Controllo degli accessi basato sui ruoli in Foundry.

Modelli

Usa modelli ARM o Bicep per automatizzare le distribuzioni sicure. Esplorare i modelli di infrastruttura di esempio.

Spazio di archiviazione

È possibile scegliere di usare le funzionalità di archiviazione predefinite in Foundry o di usare le proprie risorse di archiviazione. Per il servizio Agent, i thread e i messaggi possono essere archiviati facoltativamente in risorse gestite dall'utente.

Esempio: Approccio alla sicurezza di Contoso

Contoso protegge le distribuzioni di Foundry usando la rete privata e un hub centrale gestito dall'IT aziendale. Ogni gruppo aziendale si connette tramite un virtual network spoke. Usano il controllo degli accessi in base al ruolo predefinito per separare l'accesso:

  • Gli amministratori gestiscono distribuzioni, connessioni e risorse condivise
  • Responsabili di progetto sovrintendono a progetti specifici
  • Gli utenti interagiscono con gli strumenti GenAI

Per la maggior parte dei casi d'uso, Contoso si basa sulla crittografia gestita da Microsoft per impostazione predefinita e non usa chiavi Customer-Managed.

Pianifica l'accesso utente

Una gestione efficace degli accessi è fondamentale per una configurazione sicura e scalabile di Foundry.

Definire ruoli e responsabilità di accesso

Identificare i gruppi di utenti che richiedono access a vari aspetti dell'ambiente Foundry. Assegnare ruoli Azure RBAC predefiniti o personalizzati in base alle responsabilità, ad esempio:

  • Proprietario dell'account: gestire configurazioni di primo livello, ad esempio connessioni di sicurezza e risorse condivise.
  • Project manager: creare e gestire progetti Foundry e i relativi collaboratori.
  • Utenti del progetto: Contribuite ai progetti esistenti.

Usa questa mappatura iniziale da ruolo a ambito per la pianificazione del rollout.

Persona Ruolo di avvio Ambito consigliato
Amministratori Proprietario o proprietario dell'account di intelligenza artificiale Azure Sottoscrizione o risorsa di Foundry
Project Manager Azure AI Project Manager Risorsa della fonderia
utenti di Project Utente di Azure AI Progetto Fonderia

Modificare le assegnazioni in base ai requisiti con privilegi minimi e ai criteri aziendali.

Determinare l'ambito di accesso

Scegliere l'ambito appropriato per le assegnazioni di accesso:

  • Livello di sottoscrizione: accesso più ampio, in genere adatto per team IT o piattaforme centrali o organizzazioni più piccole.
  • Livello gruppo di risorse: utile per raggruppare le risorse correlate con criteri di accesso condiviso. Ad esempio, una funzione Azure che segue lo stesso ciclo di vita dell'applicazione dell'ambiente Foundry.
  • Livello di risorsa o progetto: ideale per un controllo con granularità fine, soprattutto quando si gestiscono dati sensibili o si abilitano self-service.

Allineare la strategia di gestione delle identità

Per le origini dati e gli strumenti integrati con Foundry, determinare se gli utenti devono eseguire l'autenticazione tramite:

  • Identità gestite o chiave API: adatto per i servizi automatizzati e l'accesso condiviso tra gli utenti.
  • Identità utente: scelta consigliata quando è necessaria la responsabilità o il controllo a livello di utente.

Usare Microsoft Entra ID gruppi per semplificare la gestione degli accessi e garantire la coerenza tra gli ambienti.

Per l'onboarding con privilegi minimi, iniziare con il ruolo Azure utente di intelligenza artificiale per sviluppatori e identità gestite del progetto, quindi aggiungere ruoli elevati solo se necessario. Per informazioni dettagliate, vedere Controllo degli accessi basato sui ruoli in Foundry.

Stabilire la connettività con altri servizi di Azure

Foundry supporta connections, che sono configurazioni riutilizzabili che consentono l'accesso ai componenti dell'applicazione su servizi Azure e servizi non Azure. Queste connessioni fungono anche da broker di identità , consentendo a Foundry di eseguire l'autenticazione a sistemi esterni usando identità gestite o entità servizio per conto degli utenti del progetto.

Creare connessioni a livello di risorsa Foundry per servizi condivisi come Archiviazione di Azure o Key Vault. Definire l'ambito delle connessioni a un progetto specifico per integrazioni sensibili o specifiche di progetto. Questa flessibilità consente ai team di bilanciare il riutilizzo e l'isolamento in base alle proprie esigenze. Altre informazioni sulle connessioni in Foundry.

Configurare l'autenticazione della connessione per utilizzare token di accesso condiviso, come le identità gestite di Microsoft Entra ID o le chiavi API, per semplificare la gestione e l'onboarding. In alternativa, utilizzare i token utente tramite passaggio diretto Entra ID, che offrono un maggiore controllo per accedere a fonti di dati sensibili.

Screenshot di un diagramma che mostra la connettività e l'integrazione del progetto Foundry con altri servizi di Azure.

Esempio: Strategia di connettività di Contoso

  • Contoso crea una risorsa Foundry per ogni gruppo aziendale, assicurando che i progetti con esigenze di dati simili condividano le stesse risorse connesse.
  • Per impostazione predefinita, le risorse connesse usano token di autenticazione condivisa e vengono condivise in tutti i progetti.
  • I progetti che utilizzano carichi di lavoro di dati sensibili si connettono alle origini dati con connessioni con ambito di progetto e Microsoft Entra ID con autenticazione pass-through.

Gestione

Una governance efficace in Foundry garantisce operazioni sicure, conformi e convenienti tra gruppi aziendali.

  • Model Controllo di accesso con Criteri di Azure Criteri di Azure applica regole tra le risorse Azure. In Foundry, usa le policy per limitare a quali modelli o famiglie di modelli possano accedere determinati gruppi aziendali. Example: Il gruppo Finance & Rischio di Contoso è limitato nell'uso di modelli di anteprima o non conformi attraverso l'applicazione di una politica al livello di sottoscrizione del gruppo aziendale.
  • Gestione costi per gruppo aziendale Distribuendo Foundry per gruppo aziendale, Contoso può tenere traccia e gestire i costi in modo indipendente. Usare il calcolatore prezzi Azure per le stime di pre-distribuzione e Gestione dei costi Microsoft per il monitoraggio del reale utilizzo continuativo e delle tendenze. Considerare i costi di Foundry come parte del costo totale della soluzione.
  • Usage Tracking with Monitoraggio di Azure Monitoraggio di Azure fornisce metriche e dashboard per tenere traccia dei modelli di utilizzo, delle prestazioni e dell'integrità delle risorse foundry.
  • Verbose Logging with Log Analytics di Azure Log Analytics di Azure consente un'ispezione approfondita dei log per informazioni operative. Ad esempio, l'utilizzo delle richieste di log, l'utilizzo dei token e la latenza per supportare il controllo e l'ottimizzazione.

Convalidare le decisioni di implementazione

Dopo aver definito il piano di implementazione, convalidare i risultati seguenti:

  • Identità e accesso: le assegnazioni di ruolo sono mappate a utenti tipo e ambiti approvati.
  • Rete: il percorso di connettività e il modello di isolamento sono documentati per ogni ambiente.
  • Verifica della rete: lo stato della connessione dell'endpoint privato è Approvato e il DNS risolve gli endpoint Foundry in indirizzi IP privati dall'interno della rete virtuale.
  • Protezione dei dati: l'approccio di crittografia (chiavi gestite da Microsoft o chiavi gestite dal cliente) è documentato e approvato.
  • Operazioni: i proprietari di costi e di monitoraggio sono assegnati per gruppo aziendale.
  • Verifica delle operazioni: le visualizzazioni dei costi e i dashboard sono definiti in Gestione dei costi Microsoft e il monitoraggio è connesso ad Application Insights per ogni progetto di produzione.
  • Operazioni del modello: la strategia di distribuzione (standard o provisionata) è documentata per ciascun caso d'uso.
  • Idoneità per l'area: i modelli e i servizi necessari vengono confermati nelle aree di destinazione prima dell'implementazione.

Configurare e ottimizzare le distribuzioni di modelli

Quando distribuiscono modelli in Fonderia, i team possono scegliere tra i tipi di distribuzione standard e con provisioning. Le distribuzioni standard sono ideali per lo sviluppo e la sperimentazione, offrendo flessibilità e facilità di configurazione. Le distribuzioni con provisioning sono consigliate per scenari di produzione in cui sono necessari prestazioni prevedibili, controllo dei costi e associazione della versione del modello.

Per supportare scenari tra aree e consentire l'accesso alle distribuzioni di modelli esistenti, Foundry consente connections per modellare le distribuzioni ospitate in altre istanze di Foundry o Azure OpenAI. Utilizzando le connessioni, i team possono centralizzare le implementazioni per la sperimentazione, pur consentendo l'accesso dai progetti distribuiti. Per i carichi di lavoro di produzione, si può scegliere di affidare ai casi d'uso la gestione delle proprie distribuzioni per garantire un maggiore controllo sul ciclo di vita del modello, sul controllo delle versioni e sulle strategie di rollback.

Per evitare l'uso eccessivo e garantire un'allocazione equa delle risorse, è possibile applicare i limiti dei token al minuto (TPM) a livello di distribuzione. I limiti di TPM consentono di controllare l'utilizzo, proteggersi da picchi accidentali e allineare l'utilizzo ai budget o alle quote project. Valutare la possibilità di impostare limiti conservativi per le distribuzioni condivise e soglie più elevate per i servizi di produzione critici.

Ulteriori informazioni

Passo successivo