Condividi tramite

Implementazione di Microsoft Foundry nell'organizzazione

Questa guida illustra le decisioni chiave per l'implementazione di Microsoft 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 per altre indicazioni.

Prerequisiti

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

  • Una strategia per la sottoscrizione di Azure di destinazione e il gruppo di risorse per ambienti di sviluppo, test e produzione.
  • Microsoft Entra ID gruppi (o gruppi di identità equivalenti) definiti per amministratori, responsabili di progetto e utenti di 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. Definire le assegnazioni di Controllo degli accessi in base al ruolo per amministratori, responsabili e utenti del progetto.
  4. Definire l'approccio di rete per ogni ambiente (access pubblico, endpoint privato o ibrido).
  5. Decidere se le chiavi gestite dal cliente sono richieste dai criteri.
  6. Definire la proprietà dei costi e del monitoraggio per ogni gruppo aziendale.
  7. 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.

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.

  • Associare progetti ai casi d'uso. I progetti Foundry sono progettati per rappresentare casi d'uso specifici. Sono 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.

Protezione dell'ambiente Foundry

Foundry è basato sulla piattaforma Azure, quindi è possibile personalizzare i controlli di sicurezza per soddisfare le esigenze dell'organizzazione. Le aree di configurazione principali includono:

  • Identity: usare Microsoft Entra ID per gestire access 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.  Altre informazioni sulle identità gestite.

  • Networking: distribuire Foundry in un Virtual Network per isolare il traffico e controllare l'accesso usando i gruppi di sicurezza di rete (NSG).  Altre informazioni sulla 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

    L'isolamento della rete end-to-end non è completamente supportato nella nuova esperienza del portale Foundry. Per le distribuzioni isolate dalla rete, usare le linee guida per l'esperienza classica, l'SDK o l'interfaccia della riga di comando in Come configurare un private link per Foundry.

  • Chiave Gestita dal Cliente (CMK): Azure supporta la CMK per crittografare i dati a riposo. Foundry supporta facoltativamente cmk per i clienti con esigenze di conformità rigorose.  Altre informazioni su CMK.

  • Authentication and Authorization: Foundry supporta API key-based access per un'integrazione semplice e Azure RBAC per un controllo con granularità fine. Le chiavi API possono semplificare la configurazione, ma non forniscono la stessa granularità basata sui ruoli di Microsoft Entra ID con RBAC. Azure applica una netta separazione tra il piano di controllo (gestione delle risorse) e il piano dati (modello e accesso ai dati). Iniziare con i ruoli predefiniti e definire ruoli personalizzati in base alle esigenze. Altre informazioni su authentication.

  • Modelli: Usare i modelli ARM o Bicep per automatizzare le distribuzioni sicure. Esplora i modelli di esempio.

  • Risorsa 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 basato sui ruoli (RBAC) integrato per separare l'accesso:

  • Gli amministratori gestiscono distribuzioni, connessioni e risorse condivise
  • Project Manager sovrintendono 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 i ruoli di accesso e le responsabilità richiesti

    • Identificare i gruppi di utenti che richiedono access a vari aspetti dell'ambiente Foundry.
    • Assegnare ruoli predefiniti o personalizzati Azure RBAC in base alle responsabilità, come 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: contribuiscono 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 Azure AI Sottoscrizione o risorsa di Foundry
    Responsabili di progetto 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.

  • Determina l'ambito di accesso

    • Scegliere l'ambito appropriato per le assegnazioni di accesso.
      • Livello di sottoscrizione: access 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 access condivisi. Ad esempio, una funzione Azure che segue lo stesso ciclo di vita dell'applicazione dell'ambiente Foundry.
      • Livello di risorsa o progetto: ideale per il controllo con granularità fine, in particolare quando si gestiscono dati sensibili o si abilita il 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: adatta per servizi automatizzati e access condivisi tra gli utenti.
      • Identità utente: scelta consigliata quando è necessaria la responsabilità o il controllo a livello di utente.
    • Usare i gruppi di Microsoft Entra ID per semplificare la gestione degli accessi e garantire la coerenza tra gli ambienti.

    Per l'onboarding con privilegi minimi, iniziare con il ruolo Utente di Azure AI per sviluppatori e identità gestite dei progetti, e poi 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 le connessioni, ovvero configurazioni riutilizzabili che consentono l'accesso ai componenti dell'applicazione nei servizi di Azure e non. 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 Azure Storage 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 l'uso di token di accesso condivisi, come le identità gestite di Microsoft Entra ID o le chiavi API, per una gestione semplificata e l'onboarding, oppure i token utente tramite il pass-through di Entra ID, che offre un maggiore controllo per l'accesso a origini dati sensibili.

Screenshot di un diagramma che mostra la connettività e l'integrazione di Foundry project con altri servizi 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 usano carichi di lavoro di dati sensibili si connettono a origini dati con connessioni con ambito progetto e autenticazione pass-through Microsoft Entra ID.

Gestione

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

  • Model Access Control con Azure Policy Azure Policy 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 Microsoft Cost Management per monitorare l'uso effettivo continuativo e il rilevamento delle tendenze. Considerare i costi di Foundry come parte del costo totale della soluzione.
  • Usage Tracking with Azure Monitor Azure Monitor fornisce metriche e dashboard per tenere traccia dei modelli di utilizzo, delle prestazioni e dell'integrità delle risorse foundry.
  • Verbose Logging with Azure Log Analytics Azure Log Analytics 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 alla 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 costi Microsoft e il monitoraggio è connesso ad Application Insights per ogni project 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 di accedere a modelli già distribuiti, Foundry consente connessioni a 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

  • Last updated on