Microsoft Foundry-Einführung in meiner Organisation

Mit einem strukturierten Bereitstellungsplan können Sie Sicherheitslücken, Kostenüberläufe und Zugriffslücken vermeiden, wenn Sie Microsoft Foundry im Großen und Ganzen einführen. Verwenden Sie dieses Handbuch, um Arbeitsauslastungsgrenzen zu definieren, eine Ressourcentopologie auszuwählen und Governance für Selbstbedienungsteams einzurichten.

Voraussetzungen

Bevor Sie mit der Planung beginnen, vergewissern Sie sich, dass Sie folgendes haben:

  • Ein Verständnis der grundlegenden Organisation der Azure-Abonnements und Ressourcengruppen Ihrer Organisation.
  • Eingaben zu den Sicherheitsanforderungen Ihrer Organisation für Netzwerke, Verschlüsselung und Datenisolation.
  • Ein anfänglicher Regionsplan basierend auf Modell- und Funktionsverfügbarkeit. Ausführliche Informationen finden Sie unter Featureverfügbarkeit in Cloudregionen.
  • Vereinbarung über Sicherheitsanforderungen für Netzwerke, Verschlüsselung und Datenisolation in Ihrer Organisation.
  • Ein Inventar der Foundry-Features und APIs, die Ihre Teams verwenden möchten.

Definieren von Isolationsgrenzen

Beginnen Sie mit dem Entscheidungsleitfaden des Cloud Adoption Frameworks für die gemeinsame Nutzung von KI-Plattformen, und übertragen Sie diese Entscheidungen dann auf Foundry:

Obwohl jede Situation einzigartig ist, empfehlen wir für die gemeinsame Organisation die folgende Sequenz:

  1. Definieren Sie nichtverhandelbare Freigabegrenzen über Geschäftseinheiten, Datendomänen, Produktbesitz und Umgebungsebenen.
  2. Legen Sie eine prod-Richtlinie fest, die standardmäßig auf Isolation festgelegt wird, es sei denn, eine dokumentierte Ausnahme lässt Colocation zu.
  3. Legen Sie eine Explorationsrichtlinie fest, die standardmäßig Co-Location für eine schnellere Experimentierung vorsieht, es sei denn, Compliance- oder Validierungsanforderungen erfordern eine Isolierung.
  4. Weisen Sie für jede Abgrenzung die Verantwortung zu, einschließlich der Verantwortung für Sicherheit, Kosten und die Reaktion auf Sicherheitsvorfälle.

Identifizieren von Funktions- und Zugriffsanforderungen

Ermitteln Sie, welche Foundry-Features und APIs für jede Workload erforderlich sind, bevor Sie die Topologie abschließen.

Note

Nicht alle Foundry-APIs unterstützen die gesamte Vielfalt von Authentifizierungsmodi, Speicherverschlüsselungsstufen und Die Isolation auf Projektebene. Einige der Foundry Tools-APIs können Rollenzuweisungen im Bereich der übergeordneten Foundry-Ressource erfordern.

Verwenden Sie für gemeinsame Anwendungsfälle, die eine Foundry-Ressource gemeinsam nutzen, Foundry-Projekte als isolierte Arbeitsbereiche für jeden Anwendungsfall. Beispielsweise können Teams, die mit einer Idee experimentieren, ein Projekt erstellen, um kohärente Ressourcen zu organisieren, ohne die Infrastruktureinrichtung für Sicherheit, Modellbereitstellungen und Toolzugriff zu wiederholen.

Die meisten neueren, agentzentrierten Foundry-APIs unterstützen projektbezogene Berechtigungen. Einige herkömmliche Foundry Tools-APIs (frühere Azure AI Services), z. B. Sprach-zu-Text, erfordern weiterhin zugriff auf übergeordnete Ressourcenbereiche. Planen Sie Grenzen und RBAC, damit alle erforderlichen Funktionen in Ihrem vorgesehenen Zugriffsverwaltungsbereich zugänglich sind.

Fähigkeitsbereich Organisieren nach Projekt RBAC-Isolierung auf Projektebene Bringen Sie Ihren eigenen Speicher mit Netzwerk-/Verschlüsselungsunterstützung Auswirkung auf die Planung
Agent-Fähigkeiten (Agenten, Antworten, Evaluierungen, Datensätze, Indizes, Dateien und Playground-Ressourcen) Ja Ja Ja Beschränkt im grundlegenden Setup (verwalteter Speicher). Verwenden Sie für die vollständige Abdeckung "Standard". Gut geeignet für eine Segmentierung nach Projekt pro Anwendungsfall in gemeinsam genutzten Umgebungen.
Feinabstimmung des Trainings Nein (nur Standardprojekt) No Teilweise (nur Eingaben) Ja Wenn jedes Team unabhängige Feinabstimmungen benötigt, verwenden Sie separate Foundry-Ressourcen. Feinabgestimmte Bereitstellungen können projektübergreifend innerhalb einer Ressource gemeinsam genutzt und verwendet werden.
OpenAI-Bilder, Videos, Batchverarbeitung No No Teilweise (nur im Batch) Ja Verwenden Sie eine isolierte Workload-Einrichtung, und überprüfen Sie, wenn verwalteter Speicher erforderlich ist, frühzeitig RBAC-Einschränkungen.
Inhaltsverständnis Ja No Ja Ja Wenn eine strikte Zugriffsisolation pro Anwendungsfall erforderlich ist, bevorzugen Sie separate Foundry-Ressourcen.
Speech Ja (Feinabstimmung) No Ja Beschränkt im grundlegenden Setup (verwalteter Speicher). Verwenden Sie FÜR die vollständige CMK-Verschlüsselungsabdeckung BYO Storage.
Language Ja (Feinabstimmung) No Ja Beschränkt im grundlegenden Setup (verwalteter Speicher). Verwenden Sie FÜR die vollständige CMK-Verschlüsselungsabdeckung BYO Storage.
Translator No No No Ja Verwenden Sie eine separate Foundry-Ressource, wenn Isolation zwingend erforderlich ist.

Wichtig

Vergewissern Sie sich vor dem Rollout Ihrer exakten Funktionskombination. Wenn eine erforderliche API nur im Bereich der Foundry-Ressource funktioniert, weisen Sie Rollen in diesem Bereich zu, oder isolieren Sie Workloads in separate Foundry-Ressourcen.

Findry-Ressourcentopologie auswählen

Nachdem Sie Grenzen und Funktionsanforderungen definiert haben, wählen Sie die Topologie pro Umgebung aus.

Entscheidungspfad Empfohlene Einrichtung der Gießerei Beste Passform Wesentlicher Kompromiss
Ko-lokalisierte Workloads Eine Foundry-Ressource mit mehreren Projekten (in der Regel ein Projekt pro Anwendungsfall) Experimentierintensive Umgebungen, frühe Prototypen und Teams, die von gemeinsamen Bereitstellungen und gemeinsam genutzten verbundenen Daten oder Tools profitieren Gemeinsamer Auswirkungsbereich für Produktionsvorfälle, Kontingentausschöpfung und Fehlkonfigurationen
Vollständig isolierte Workloads Eine Gießereiressource pro Produktionsauslastungsgrenze (häufig mit einem primären Projekt pro Workload) Produktionsarbeitslasten, die strenge betriebliche Eindämmung, unabhängige Zugriffssteuerung und unabhängige Kontingent- oder Kostengrenzen erfordern Self-Service-Befähigung wird durch mehr zu verwaltende Ressourcen und einen höheren Einrichtungsaufwand schwieriger

Tip

Behandeln Sie für die Produktion die Isolation als Standard. Verwenden Sie Colocation nur dann als bewusste Ausnahme, wenn die Grenzen zwischen Workloads, die Datenanforderungen und die Akzeptanz von Risiken aufeinander abgestimmt sind.

Screenshot eines Diagramms, das die Foundry-Ressource zeigt.

Planen Ihrer Sicherheitsgrundwerte

Verwenden Sie diese Referenztabelle als Prüfliste für Sicherheitsentwurfsentscheidungen.

Bereich Was zu entscheiden ist Mit
Identität und Zugriff Definieren Sie Administrator-, Projektmanager- und Projektbenutzerpersonas. Ordnen Sie jede Persona den Rollen mit den geringsten Berechtigungen und Microsoft Entra ID Gruppen zu. Rollenbasierte Zugriffssteuerung in Foundry
Netzwerken Wählen Sie das Netzwerkmodell pro Umgebung aus. Verwenden Sie verwaltetes virtuelles Netzwerk, um ein sichereres, einfacheres Setup zu gewährleisten. Verwenden Sie bring-your-own (BYO) virtuelles Netzwerk für erweiterte Netzwerksteuerung und benutzerdefinierte Routinganforderungen. Überprüfen Sie privates DNS und den Endpunkt-Freigabeprozess vor dem Produktivbetrieb. Konfigurieren des verwalteten virtuellen Netzwerks, Konfigurieren eines privaten Links für Foundry und netzwerkgeschütztes Setup (BYO virtual network)
Datenschutz und Schlüssel Entscheiden Sie, ob Microsoft verwalteten Schlüssel Richtlinienanforderungen erfüllen oder ob vom Kunden verwaltete Schlüssel erforderlich sind. Vom Kunden verwaltete Schlüssel in Foundry
Authentifizierungsmodell Bevorzugen Sie Microsoft Entra ID und RBAC für Personen und Dienste. Verwenden Sie API-Schlüssel nur, wenn die Rollen granularität nicht erforderlich ist. Rollenbasierte Zugriffssteuerung in Foundry

Planen des Modells, der Region und der Kapazitätsstrategie

Definieren Sie für jede Workload Folgendes:

  • Modellfamilien und Bereitstellungstypen, die für den Anwendungsfall erforderlich sind.
  • Datenverarbeitungsanforderungen (z. B. globale oder regionale Einschränkungen).
  • Durchsatz- und Latenzziele für interaktive und Batchszenarien.
  • Anforderungen an Kontingente und bereitgestellte Kapazität für Dauer- und Spitzenlasten.

Verwenden Sie die folgenden Verweise:

Planen der Konnektivität und Datenintegration

Identifizieren Sie für jede Workload externe Abhängigkeiten und Verbindungsmuster:

  • Datenquellen und Datenspeicher.
  • Interne APIs und Branchensysteme.
  • SaaS-Tools außerhalb von Azure, die von Agenten oder Orchestrierungsflüssen benötigt werden.
  • Netzwerkanforderungen, einschließlich privater Endpunkte, DNS-Auflösung, Ausgangssteuerelemente und ob verwaltetes Netzwerk oder BYO-virtuelles Netzwerk erforderlich ist.

Verwenden Sie Verbindungen in Foundry hinzufügen, um die Einrichtung von Verbindungen zu standardisieren.

Verbindungen können sowohl auf der Ebene der übergeordneten Foundry-Ressource als auch auf der Ebene untergeordneter Projekte erstellt werden, je nach gewünschtem Isolationsumfang. Auf übergeordneter Ebene konfigurierte Verbindungen sind für alle Projekte verfügbar.

Screenshot eines Diagramms, das die Konnektivität und Integration von Foundry-Projekten mit anderen Azure Services zeigt.

Planen von Automatisierung und Vorgängen

Definieren Sie, wie Teams Ressourcen konsistent in allen Umgebungen erstellen und verwalten.

  • Verwenden Sie Infrastructure as Code, um Kernressourcen und Standardrichtlinien bereitzustellen.
  • Standardisieren Sie Bereitstellungspipelinen für Projekte, Verbindungen, Modellbereitstellungen und Konfigurationsänderungen.
  • Definieren Sie Rollback- und Vorfallreaktionsverfahren für Modell- und Richtlinienänderungen.

Verwenden Sie für Automatisierungsmuster und Startimplementierungen Folgendes:

Die Beispielvorlagen umfassen End-to-End-Muster für allgemeine Sicherheitsszenarien, z. B. private Netzwerke, vom Kunden verwaltete Schlüssel und rollenbasierte Zugriffssteuerung.

Leitplanken zur Selbstbedienung definieren

Aktivieren Sie Self-Serve nur innerhalb eindeutiger Einschränkungen:

  • Definieren Sie, welche Rollen Projekte erstellen, Modelle bereitstellen und externe Tools verbinden können.
  • Wenden Sie Richtliniensteuerelemente für das Modellbereitstellungs- und Laufzeitverhalten an, einschließlich der Modellanbieter und der zulässigen Toolverbindungen.
  • Richten Sie Kostenkontrollen und Budgetwarnungen für gemeinsam genutzte und isolierte Umgebungen ein.
  • Erzwingen Sie die Trace-Protokollierung für die zentrale Überwachung über Microsoft Foundry, Microsoft Copilot Studio und Microsoft 365 hinweg.

Verwenden Sie die folgenden Verweise:

Eigentümerschaft und Governance zuweisen

Behandeln Sie diesen Schritt als Übergang von der bereitgestellten Infrastruktur zur operativen Entwicklerverwendung.

Die meisten Organisationen verwalten den Zugriff bereits über vordefinierte Microsoft Entra ID-Gruppen. Ordnen Sie diese Gruppen den Foundry-Rollen im erforderlichen Bereich zu, und überprüfen Sie dann sowohl Verwaltungs- als auch Entwicklungszugriffspfade.

Foundry trennt den Zugriff nach:

  • RBAC-Aktionen der Steuerungsebene für die Ressourcenverwaltung.
  • RBAC-Aktionen der Datenebene für Entwicklungsworkloads.

Wichtig

Verwaltungsrollen wie Besitzer oder Mitwirkender reichen nicht für alle Entwicklungsszenarien aus. Beispielsweise kann ein Benutzer Ressourcen verwalten, aber dennoch Datenebenenrollen benötigen, um mit einem Agent in Foundry zu chatten.

Informationen zu Rollenzuordnungsanleitungen und erforderlichen Rollenkombinationen finden Sie unter Rollenbasierte Zugriffssteuerung in Foundry.

Ziehen Sie nach dem Onboarding Ihrer Benutzergruppen das Einrichten oder Erweitern von Governancedashboards in Betracht, um die Nutzung, Zuverlässigkeit, Herkunft und Compliance von Foundry nachzuverfolgen:

Beispiel einer Plattformbereitstellung

Die IT-Organisation bei Contoso muss mehrere Teams unterstützen und dabei zwei Prioritäten ausgleichen:

  • Schnelle Innovation, bei der Entwickler die neuesten KI-Technologien mit Nichtproduktionsdaten streng testen können.
  • Vollständig isolierte Entwicklungs-/Test- und Prod-Umgebungen für bewährte Anwendungsfälle, die Finanzierungen für die Operationalisierung erhalten.

Das Diagramm zeigt, wie Contoso eine gemeinsam genutzte Foundry-Untersuchungsinstanz für Innovation am gleichen Ort platziert, die mit eingeschränkter Kapazität sowie vorab angebundenen Daten und Tools allen Teams zur Verfügung steht. Der Beispiel-Backlog spiegelt allgemeine Unternehmensfunktionen wie Kundensupport, Mitarbeiter-Helpdesk, Finanzvorgänge, Beschaffung und Vertrieb wider. In der Vergangenheit gelangten nur wenige Anwendungsfälle bis zur erwiesenen Machbarkeit oder erhielten eine Finanzierung für eine Dev/Test-Einführung. Von diesen gelangt eine noch kleinere Teilmenge in die Produktion. Das Beispiel zeigt außerdem zwei verwandte vertriebsbezogene Anwendungsfälle, die während der Exploration und Entwicklung/Test zusammen angesiedelt bleiben, da sie dieselben CRM-Daten, Benutzerpersonas und verbundenen Systeme nutzen. Mit zunehmender Reife der Anwendungsfälle werden Teams Umgebungen mit zunehmend stärkerer Isolierung zugewiesen, die bei Bedarf in einer vollständigen Trennung auf Produktivniveau gipfeln.

Diagramm, das zeigt, wie Contoso-Anwendungsfälle aus einer gemeinsam genutzten Foundry-Umgebung für Untersuchungen in isolierte oder sich am gleichen Ort befindende Entwicklungs-/Testumgebungen und anschließend für eine kleinere Anzahl von Workloads in isolierte Produktionsumgebungen überführt werden.

Weitere Informationen

Nächster Schritt