«Private Endpoint aktiviert» ist keine vollständige Architektur
Enterprise-Teams behandeln private Vernetzung oft als Checkbox am Ende eines KI-Prototyps. Zu diesem Zeitpunkt hängt die Anwendung möglicherweise bereits von öffentlichen Modellendpunkten, externen Paketquellen, uneingeschränkten Web-Werkzeugen, öffentlicher DNS-Auflösung oder undokumentierten Telemetriepfaden ab.
Microsoft Foundry unterstützt Netzwerkisolation, einschliesslich Private Endpoints und Virtual-Network-Mustern. Der sichere Entwurf beginnt trotzdem mit einer Karte der Datenflüsse und Abhängigkeiten.
Drei Grenzen zeichnen
Microsoft trennt in der Netzwerkdokumentation drei Bereiche:
- Eingehender Zugriff auf Foundry-Ressource und Projekte.
- Ausgehender Zugriff von Foundry auf Azure-Dienste und andere Abhängigkeiten.
- Ausgehender Zugriff des Agent-Clients auf private Datenquellen, freigegebene Dienste oder Internetziele.
Behandeln Sie diese als unabhängige Fragen. Eingeschränkter Eingang begrenzt nicht automatisch jeden ausgehenden Pfad.
Dokumentieren Sie für jeden Datenfluss Quellidentität, Ziel, Protokoll, Datenklassen, Namensauflösung, Autorisierung, erzeugte Protokolle und Fehlerverhalten.
Mit der Workload beginnen, nicht mit dem Subnetz
Erfassen Sie, womit das KI-System tatsächlich interagiert:
- Prompts und hochgeladene Dateien;
- Retrieval-Speicher und Quelldokumente;
- Geschäfts-APIs und Werkzeugresultate;
- Konversations- oder Agentenzustand;
- Evaluationsdatensätze und -resultate;
- Traces, Logs, Metriken und Support-Exporte;
- Modell- und Paketdownloads;
- Administrator- und Entwicklerzugriff.
Sensible Informationen können in Telemetrie und Evaluationsartefakten auftauchen, obwohl die Primärdatenbank privat bleibt. Nehmen Sie Betriebsdaten in die Grenze auf.
Eingehender Zugriff und DNS
Der öffentliche Netzwerkzugriff kann deaktiviert oder eingeschränkt werden; Private Endpoints ermöglichen dann den Zugriff aus freigegebenen Netzwerken. DNS ist ein funktionaler Teil dieser Kontrolle. Aus dem vorgesehenen virtuellen Netzwerk muss der Foundry-Hostname auf die private Endpoint-Adresse auflösen. Eigenes oder lokales DNS benötigt passende Delegationen oder Einträge.
Validieren Sie die Auflösung über dieselben Netzwerkpfade wie Entwicklung, CI/CD, Anwendungen und Betrieb. Eine erfolgreiche Portalkonfiguration beweist nicht, dass jeder Client die private Route nutzt.
Testen Sie auch aus einem nicht freigegebenen Netzwerk. Das erwartete Scheitern ist Teil der Akzeptanzevidenz.
Ausgehende Abhängigkeiten und Agenten
Eine Anwendung ohne Zugriff auf Retrieval, Identitätsanbieter, Monitoring oder Werkzeug-APIs ist nicht produktionsbereit. Eine Anwendung mit Zugriff auf alles ist nicht isoliert.
Nutzen Sie eine aus der Missionsarchitektur abgeleitete Positivliste. Private Link und Private Endpoints können unterstützte Azure-PaaS-Abhängigkeiten schützen. Agentennetzwerke können mit einem delegierten Subnetz und Virtual-Network-Injection auf kundendefinierte Abhängigkeiten zugreifen.
Entscheiden Sie explizit, ob Webzugriff erforderlich ist. Falls ja, führen Sie ihn über einen kontrollierten und überwachten Pfad und behandeln Sie Internetinhalte als nicht vertrauenswürdige Eingabe. Falls nein, lassen Sie keinen breiten Ausgang «für später» offen.
Identität bleibt die primäre Autorisierungsgrenze
Netzwerke schränken Erreichbarkeit ein. Sie entscheiden nicht, ob ein Nutzer oder Agent einen Kundendatensatz lesen oder eine Geschäftsaktion ausführen darf.
Nutzen Sie Microsoft-Entra-Identitäten und minimale Rollenzuweisungen. Trennen Sie Bereitstellung, Betrieb, Evaluation und Datenzugriff. Bewahren Sie bei Werkzeugaufrufen die anfragende Identität, wenn der Workflow Nutzerautorisierung benötigt; andernfalls verwenden Sie eine dedizierte Workload-Identität mit engem Zweck.
Vermeiden Sie gemeinsame Schlüssel in der Anwendungskonfiguration, wenn Managed Identity verfügbar ist. Rotieren und überwachen Sie unvermeidbare Zugangsdaten.
Negative Pfade validieren
Eine private Bereitstellung benötigt Tests, die das Ablehnen unerwünschten Verhaltens belegen:
- öffentlicher Zugriff scheitert, wenn er deaktiviert ist;
- private DNS-Auflösung funktioniert in jeder freigegebenen Umgebung;
- eine nicht autorisierte Identität erreicht weder Projekt noch nachgelagerte Daten;
- nicht freigegebene Ziele sind ausgehend unerreichbar;
- Logs erfassen keine verbotenen Inhalte;
- ein Agent scheitert sicher bei Ausfall einer privaten Abhängigkeit;
- Betreiber behalten einen freigegebenen Vorfall- und Wiederherstellungspfad.
Wiederholen Sie diese Tests nach Änderungen an Netzwerk, DNS, Agent-Runtime oder Abhängigkeiten.
Privat ist eine Betriebseigenschaft
Netzwerkisolation erhöht Bereitstellungs- und Supportkomplexität. Halten Sie die Architektur als Code fest, überwachen Sie Private-Endpoint- und DNS-Zustand und weisen Sie Verantwortung für Richtlinienänderungen zu. Planen Sie Notfallzugriff ohne permanente Umgehung.
Die glaubwürdige Aussage lautet nicht «Wir verwenden Private Endpoints». Sie lautet: Wir kennen jeden relevanten Pfad, erzwingen die vorgesehenen Routen und Identitäten und testen kontinuierlich, dass unerlaubte Pfade scheitern.
Offizielle Referenz
Microsoft dokumentiert eingehende, ausgehende und Agent-Client-Verbindungen sowie Private Link und DNS in Netzwerkisolation für Microsoft Foundry konfigurieren.