Microsoft Foundry-implementatie in mijn organisatie

Een gestructureerd implementatieplan helpt u bij het voorkomen van beveiligingsproblemen, kostenoverschrijdingen en toegangsgroei bij het aannemen van Microsoft Foundry op schaal. Deze handleiding bevat een overzicht van belangrijke beslissingen voor het implementeren van Foundry, waaronder het instellen van omgevingen, gegevensisolatie, integratie met andere Azure-services, capaciteitsbeheer en bewaking. Gebruik deze handleiding als uitgangspunt en pas deze aan uw behoeften aan. Zie de gekoppelde artikelen voor meer informatie over de implementatie.

Voorwaarden

Voordat u begint met de implementatieplanning, controleert u of u het volgende hebt:

• Een doelstrategie Azure abonnement en resourcegroep voor ontwikkel-, test- en productieomgevingen.
• Microsoft Entra ID groepen (of gelijkwaardige identiteitsgroepen) die zijn gedefinieerd voor beheerders, projectmanagers en projectgebruikers.
• Een eerste regioplan op basis van de beschikbaarheid van modellen en functies. Zie Beschikbaarheid van functies in cloudregio's voor meer informatie.
• Overeenkomst over beveiligingsvereisten voor netwerken, versleuteling en gegevensisolatie in uw organisatie.

Controlelijst voor implementatie basislijn

Gebruik deze controlelijst vóór uw eerste productie-implementatie:

1. Definieer omgevingsgrenzen voor ontwikkeling, testen en productie.
2. Wijs eigendom toe voor elke Foundry-resource en elke projectomvang.
3. Bepaal de Foundry-functies die u van plan bent te gebruiken. Niet alle functie-API's zijn beschikbaar in de projectcontext. Als u van plan bent om machtigingen toe te wijzen aan het laagste projectbereik voor isolatie van use-case's, wordt dit mogelijk niet ondersteund voor klassieke Azure AI-API's zoals Translator. Deze vereisen dat elke gebruiker machtigingen heeft op het bovenliggende resourceniveau van Foundry. Voor deze gevallen wordt scheiding door Foundry-resource aanbevolen.
4. Definieer RBAC-toewijzingen voor beheerders, projectmanagers en projectgebruikers.
5. Definieer de netwerkbenadering voor elke omgeving (openbare toegang, privé-eindpunt of hybride).
6. Bepaal of door de klant beheerde sleutels vereist zijn voor beleid.
7. Definieer kosten en eigendom van monitoring voor elke bedrijfsgroep.
8. Identificeer vereiste gedeelde verbindingen en projectgerichte verbindingen.

Voorbeeldorganisatie

Contoso is een wereldwijde onderneming die genAI-acceptatie verkent in vijf bedrijfsgroepen, elk met verschillende behoeften en technische volwassenheid.

Om de acceptatie te versnellen zonder toezicht te houden, streeft Contoso Enterprise IT ernaar om een model mogelijk te maken met gemeenschappelijke gedeelde resources, waaronder netwerken en gecentraliseerd gegevensbeheer, terwijl selfservicetoegang tot Foundry mogelijk is voor elk team binnen een beheerde, veilige omgeving om hun gebruiksscenario's te beheren.

Overwegingen bij de implementatie

De Foundry-resource definieert het bereik voor het configureren, beveiligen en bewaken van de omgeving van uw team. Deze is beschikbaar in de Foundry-portal en via Azure API's. Projecten zijn vergelijkbaar met mappen om uw werk in deze resourcecontext te organiseren. Projecten beheren ook de toegang en machtigingen voor Foundry-ontwikkelaars-API's en hulpprogramma's.

Houd rekening met de volgende procedures voor het instellen van omgevingen bij het implementeren van Foundry om consistentie, schaalbaarheid en governance in teams te garanderen:

• Stel afzonderlijke omgevingen in voor ontwikkeling, testen en productie. Gebruik afzonderlijke resourcegroepen of abonnementen en Foundry-resources om werkstromen te isoleren, de toegang te beheren en ondersteuning te bieden voor experimenten met gecontroleerde releases.

• Maak een afzonderlijke Foundry-resource voor elke bedrijfsgroep. Lijn implementaties uit met logische grenzen, zoals gegevensdomeinen of bedrijfsfuncties om autonomie, governance en kosten bij te houden. Overweeg ook afzonderlijke Foundry-resources wanneer teams klassieke Azure AI-API's nodig hebben die geen ondersteuning bieden voor toegang binnen het projectbereik.

• Projecten koppelen aan use cases. Foundry-projecten vertegenwoordigen specifieke use cases en bieden containers voor het organiseren van onderdelen, zoals agents of bestanden voor een toepassing. Hoewel ze beveiligingsinstellingen overnemen van hun bovenliggende resource, kunnen ze ook hun eigen besturingselementen voor toegang, gegevensintegratie en andere beheeropties implementeren. Voordat u machtigingen voor projectbereik toewijst, controleert u of de API's van uw team van plan zijn om ondersteuning te bieden voor toegang op projectniveau.

De Foundry-omgeving beveiligen

Foundry is gebouwd op het Azure platform, zodat u beveiligingscontroles kunt aanpassen aan de behoeften van uw organisatie.

Identiteit

Gebruik Microsoft Entra ID om gebruikers- en servicetoegang te beheren. Foundry ondersteunt beheerde identiteiten om veilige, wachtwoordloze verificatie toe te staan aan andere Azure-services. U kunt beheerde identiteiten toewijzen op het niveau van de Foundry-resource en eventueel op projectniveau voor fijnmazige controle. Zie Op rollen gebaseerd toegangsbeheer in Foundry voor meer informatie.

Netwerken

Implementeer Foundry in een Virtual Network om verkeer te isoleren en de toegang te beheren met behulp van netwerkbeveiligingsgroepen (NSG's). Voor privéconnectiviteitsscenario's gebruikt u privé-eindpunten en valideert u de goedkeuringsstatus van DNS en eindpunt. Zie Hoe u een privékoppeling voor Foundry configureert voor implementatiedetails en -beperkingen.

Door de klant beheerde sleutels

Azure ondersteunt klantbeheerde sleutels (CMK) voor het versleutelen van gegevens in rust. Foundry ondersteunt CMK optioneel voor klanten met strikte nalevingsbehoeften. Zie Door de klant beheerde sleutels in Foundry voor meer informatie.

Verificatie en autorisatie

Foundry biedt ondersteuning voor toegang op basis van API-sleutels voor eenvoudige integratie en Azure RBAC voor nauwkeurig beheer. API-sleutels kunnen de installatie vereenvoudigen, maar ze bieden niet dezelfde granulariteit op basis van rollen als Microsoft Entra ID met RBAC. Azure dwingt een duidelijke scheiding af tussen het beheervlak (resourcebeheerbewerkingen zoals het maken of configureren van resources) en het gegevensvlak (runtimebewerkingen zoals het aanroepen van modellen en het openen van gegevens). Begin met ingebouwde rollen en definieer indien nodig aangepaste rollen. Zie Op rollen gebaseerd toegangsbeheer in Foundry voor meer informatie.

Sjablonen

Gebruik ARM-sjablonen of Bicep om beveiligde implementaties te automatiseren. Verken de voorbeeldinfrastructuursjablonen.

Opslag

U kunt ervoor kiezen om ingebouwde opslagmogelijkheden in Foundry te gebruiken of uw eigen opslagbronnen te gebruiken. Voor de agentservice kunnen threads en berichten eventueel worden opgeslagen in resources die door u worden beheerd.

Voorbeeld: De beveiligingsbenadering van Contoso

Contoso beveiligt de Foundry-implementaties door gebruik te maken van privénetwerken, waarbij het Enterprise IT-team een centraal hubnetwerk beheert. Elke bedrijfsgroep maakt verbinding via een virtueel spoke-netwerk. Ze gebruiken ingebouwd op rollen gebaseerd toegangsbeheer (RBAC) om de toegang te scheiden:

• Beheerders beheren implementaties, verbindingen en gedeelde resources
• Project Managers toezicht houden op specifieke projecten
• Gebruikers communiceren met GenAI-hulpprogramma's

Voor de meeste gebruiksscenario's is Contoso standaard afhankelijk van door Microsoft beheerde versleuteling en maakt geen gebruik van Customer-Managed Sleutels.

Gebruikerstoegang plannen

Effectief toegangsbeheer is fundamenteel voor een veilige en schaalbare Foundry-installatie.

Toegangsrollen en verantwoordelijkheden definiëren

Bepaal welke gebruikersgroepen toegang nodig hebben tot verschillende aspecten van de Foundry-omgeving. Ingebouwde of aangepaste Azure RBAC-rollen toewijzen op basis van verantwoordelijkheden zoals:

• Accounteigenaar: beheer configuraties op het hoogste niveau, zoals beveiliging en gedeelde resourceverbindingen.
• Projectmanagers: Het maken en beheren van Foundry-projecten en hun bijdragers.
• Project gebruikers: bijdragen aan bestaande projecten.

Gebruik deze basisrol-naar-bereik toewijzing voor de planning van de implementatie:

Pas toewijzingen aan op basis van vereisten voor minimale bevoegdheden en ondernemingsbeleid.

Toegangsbereik bepalen

Kies het juiste bereik voor toegangstaken:

• Abonnementsniveau: Breedste toegang, meestal geschikt voor centrale IT- of platformteams of kleinere organisaties.
• Niveau van resourcegroep: handig voor het groeperen van gerelateerde resources met beleid voor gedeelde toegang. Bijvoorbeeld een Azure-functie die dezelfde toepassingslevenscyclus volgt als uw Foundry-omgeving.
• Resource- of projectniveau: ideaal voor fijnmazige controle, met name bij het omgaan met gevoelige gegevens of het inschakelen van selfservice.

Identiteitsstrategie afstemmen

Voor gegevensbronnen en hulpprogramma's die zijn geïntegreerd met Foundry, bepaalt u of gebruikers zich moeten verifiëren met behulp van:

• Beheerde identiteiten of API-sleutel: geschikt voor geautomatiseerde services en gedeelde toegang tussen gebruikers.
• Gebruikersidentiteiten: voorkeur wanneer verantwoording op gebruikersniveau of controlebaarheid vereist is.

Gebruik Microsoft Entra ID groepen om toegangsbeheer te vereenvoudigen en consistentie tussen omgevingen te garanderen.

Voor onboarding met minimale bevoegdheden begint u met de rol Azure AI-gebruiker voor ontwikkelaars en door project beheerde identiteiten. Voeg vervolgens alleen indien nodig verhoogde rollen toe. Zie Op rollen gebaseerd toegangsbeheer in Foundry voor meer informatie.

Connectiviteit met andere Azure-services tot stand brengen

Foundry ondersteunt connections. Dit zijn herbruikbare configuraties die toegang tot toepassingsonderdelen in Azure en niet-Azure-services mogelijk maken. Deze verbindingen fungeren ook als identiteitsbrokers, waardoor Foundry kan worden geverifieerd bij externe systemen met behulp van beheerde identiteiten of service-principals namens projectgebruikers.

Maak verbindingen op het resourceniveau Foundry voor gedeelde services, zoals Azure Storage of Key Vault. Bereikverbindingen met een specifiek project voor gevoelige of projectspecifieke integraties. Dankzij deze flexibiliteit kunnen teams hergebruik en isolatie verdelen op basis van hun behoeften. Meer informatie over verbindingen in Foundry.

Configureer verbindingsverificatie voor het gebruik van gedeelde toegangstokens, zoals Microsoft Entra ID beheerde identiteiten of API-sleutels, voor vereenvoudigd beheer en onboarding, of gebruikerstokens via Entra ID passthrough, die meer controle bieden bij het openen van gevoelige gegevensbronnen.

Voorbeeld: De connectiviteitsstrategie van Contoso

• Contoso maakt een Foundry-resource voor elke bedrijfsgroep, zodat projecten met vergelijkbare gegevens dezelfde verbonden resources delen.
• Verbonden resources maken standaard gebruik van gedeelde verificatietokens en worden gedeeld in alle projecten.
• Projecten die gebruikmaken van workloads voor gevoelige gegevens maken verbinding met gegevensbronnen met verbindingen binnen projectbereik en Microsoft Entra ID passthrough-verificatie.

Bestuur

Effectieve governance in Foundry zorgt voor veilige, compatibele en kostenefficiënte activiteiten binnen bedrijfsgroepen.

• Model Access Control met Azure Policy Azure Policy dwingt regels af voor Azure resources. Gebruik in Foundry beleidsregels om te beperken tot welke modellen of modelfamilies specifieke bedrijfsgroepen toegang hebben. Voorbeeld: de groep Financiën en risico's van Contoso is beperkt tot het gebruik van preview- of niet-compatibele modellen door een beleid toe te passen op abonnementsniveau van de bedrijfsgroep.
• Kostenbeheer per bedrijfsgroep Door Foundry per bedrijfsgroep te implementeren, kan Contoso onafhankelijk van elkaar kosten bijhouden en beheren. Gebruik de Azure prijscalculator voor schattingen van vooraf implementeren en Microsoft Cost Management voor doorlopend gebruik en trendtracking. Behandel Foundry-kosten als één onderdeel van de totale oplossingskosten.
• Gebruik bijhouden met Azure Monitor Azure Monitor biedt metrische gegevens en dashboards voor het bijhouden van gebruikspatronen, prestaties en status van Foundry-resources.
• Gedetailleerde logging met Azure Log Analytics Azure Log Analytics biedt diepgaande inspectie van logs voor operationele inzichten. Bijvoorbeeld gebruik van logboekaanvragen, tokengebruik en latentie ter ondersteuning van controle en optimalisatie.

Implementatiebeslissingen valideren

Nadat u uw implementatieplan hebt gedefinieerd, valideert u de volgende resultaten:

• Identiteit en toegang: roltoewijzingen komen overeen met goedgekeurde persona's en scopes.
• Netwerken: Connectiviteitspad en isolatiemodel worden gedocumenteerd voor elke omgeving.
• Netwerkverificatie: de verbindingsstatus van het privé-eindpunt is goedgekeurd en DNS zet Foundry-eindpunten om naar privé-IP-adressen vanuit het virtuele netwerk.
• Gegevensbeveiliging: versleutelingsbenadering (Microsoft-beheerde sleutels of door de klant beheerde sleutels) wordt gedocumenteerd en goedgekeurd.
• Operationele activiteiten: Kosten- en bewakingseigenaren worden aan elke bedrijfsgroep toegewezen.
• Verificatie van bewerkingen: kostenweergaven en dashboards worden gedefinieerd in Microsoft Cost Management en bewaking is verbonden met Application Insights voor elk productieproject.
• Modelbewerkingen: Implementatiestrategie (standaard of ingericht) wordt per use-case gedocumenteerd.
• Gereedheid voor regio's: vereiste modellen en services worden bevestigd in doelregio's vóór de implementatie.

Modelimplementaties configureren en optimaliseren

Bij het implementeren van modellen in Foundry kunnen teams kiezen tussen standaard- en ingerichte implementatietypen. Standaardimplementaties zijn ideaal voor ontwikkeling en experimenten, wat flexibiliteit en gebruiksgemak biedt. Ingerichte implementaties worden aanbevolen voor productiescenario's waarbij voorspelbare prestaties, kostenbeheer en het vastmaken van modelversies vereist zijn.

Foundry biedt ondersteuning voor scenario's voor meerdere regio's en biedt u toegang tot bestaande modelimplementaties, met verbindingen naar modelimplementaties die worden gehost in andere Foundry- of Azure OpenAI-exemplaren. Door verbindingen te gebruiken, kunnen teams implementaties centraliseren voor experimenten terwijl ze nog steeds toegang vanuit gedistribueerde projecten mogelijk maken. Voor productieworkloads kunt u use cases gebruiken om hun eigen implementaties te beheren om een strakkere controle over de levenscyclus van modellen, versiebeheer en terugdraaistrategieën te garanderen.

Als u overmatig gebruik wilt voorkomen en evenredige resourcetoewijzing wilt garanderen, kunt u TPM-limieten (Tokens per minuut) toepassen op implementatieniveau. TPM-limieten helpen het verbruik te beheren, te beschermen tegen onbedoelde pieken en het gebruik af te stemmen op projectbudgetten of quota. Overweeg om conservatieve limieten in te stellen voor gedeelde implementaties en hogere drempelwaarden voor kritieke productieservices.

Meer informatie

• De Foundry-omgeving beveiligen

  • Verificatie en RBAC: op rollen gebaseerd toegangsbeheer in Foundry
  • Netwerken: Een virtueel netwerk gebruiken met Foundry
  • Door de klant beheerde sleutels (CMK): Door de klant beheerde sleutels in Foundry
  • Voorbeeldinfrastructuur: opslagplaats met sjablonen met voorbeeldinfrastructuursjablonen
  • Herstellen of opschonen van verwijderde resources van Foundry

• Connectiviteit met andere Azure-services tot stand brengen

  • Overzicht van verbindingen: Een nieuwe verbinding toevoegen in Foundry

Volgende stap