Sichere Bereitstellung
In diesem Thema wird beschrieben, wie Daten in einer kundenseitig gehosteten Codebeamer AI Bereitstellung gehandhabt, verarbeitet und geschützt werden.
Datenverarbeitung für die kundenseitig gehostete Bereitstellung
Bei der kundenseitig gehosteten Bereitstellung werden die Laufzeitkomponenten vollständig innerhalb des Azure-Mandanten bzw. -Abonnements des Kunden bereitgestellt und sind zustandslos konzipiert.
Zusammenfassung der Datenverarbeitung, ‑nutzung und ‑speicherung auf hoher Ebene
◦ Alle Inferenzanforderungen werden mit kundenverwaltetem AKS + kundeneigene, Azure OpenAI‑Dienst innerhalb der Kundenumgebung verarbeitet.
◦ PTC betreibt keine gehostete Laufzeit für kundenseitig gehostete Bereitstellungen und greift auch nicht darauf zu. Die Laufzeitkomponenten senden keine Eingabeaufforderungen, Antworten, Kundeninhalte oder Laufzeittelemetriedaten an PTC zurück.
◦ Laufzeitkomponenten sind zustandslos konzipiert.
▪ Anwendungsprotokolle, Traces und Spans werden an den OpenTelemetry Collector gesendet und nur an vom Kunden konfigurierte Observability‑Plattformen exportiert. Der Dienst ist so konzipiert, dass Prompts, personenbezogene Daten (PII), vollständige Antworten oder andere sensible Kundeninhalte nicht absichtlich protokolliert werden. In Ausnahme‑ oder Debug‑Szenarien können jedoch dennoch begrenzte sensible Daten angezeigt werden. Kunden müssen Observability‑Daten als sensible Daten behandeln und rollenbasierte Zugriffskontrollen (RBAC), Verschlüsselung sowie Aufbewahrungsrichtlinien für alle Überwachungs-Tools und Speicherlösungen durchsetzen.
▪ Kunden-Prompts oder -antworten werden vom Dienst während des normalen Betriebs nicht persistent gemacht.
Datenverarbeitung
Eine kundenseitig gehostete Bereitstellung verarbeitet die folgenden Datentypen im Arbeitsspeicher, um angeforderte Funktionen bereitzustellen:
◦ Vom Kunden bereitgestellte Eingaben, die das Codebeamer KI Plugin erhält
◦ Von PTC entwickelte Prompts bzw. Systemanweisungen, die verwendet werden, um die angeforderten KI‑Operation auszuführen
◦ Generierte LLM‑Antworten, die vom Azure‑OpenAI‑Endpunkt des Kunden zurückgegeben und anschließend an den aufrufenden Dienst zurückgegeben werden
Datennutzung
◦ Prompts, Eingaben und Antworten werden ausschließlich zur Verarbeitung der aktiven Anforderung und zur Rückgabe der Ergebnisse an das aufrufende Produkt oder Plugin verwendet.
◦ Betriebsprotokolle, Metriken und Traces werden innerhalb der Kundenumgebung für Überwachung, Problembehandlung, Audit‑Zwecke und Reaktion auf Vorfälle verwendet.
Datenspeicherung
◦ Der Codebeamer KI Dienst speichert im Normalbetrieb keine Kunden‑Prompts und ‑Antworten. Eine etwaige Persistenz wird ausschließlich durch kundenseitige betriebliche Tools und Konfigurationen gesteuert.
◦ Vom Kunden kontrollierte Überwachungslösungen können Protokolle gemäß den kundenspezifischen Konfigurations‑ und Aufbewahrungseinstellungen speichern.
◦ Das Verhalten der Azure OpenAI-Datenverarbeitung wird durch die von Microsoft veröffentlichten Richtlinien gesteuert.
Baseline für sichere Bereitstellung
Infrastruktur als Code (IaC)
Alle Azure‑Ressourcen werden mithilfe von Terraform (IaC) bereitgestellt. Dies gewährleistet konsistente, reproduzierbare und auditierbare Bereitstellungen. Terraform erzwingt zudem das Prinzip der geringsten Rechte (Least Privilege) und konfiguriert Sicherheitskontrollen gemeinsam mit den Ressourcen. Dadurch werden manuelle Änderungen reduziert und Konfigurationsdrift verhindert.
Über Terraform bereitgestellte Sicherheitskontrollen
Terraform erzwingt die folgenden Sicherheitskontrollen:
◦ Der Zugriff auf AKS erfolgt über Microsoft Entra ID‑basierte rollenbasierte Zugriffskontrolle (RBAC). Azure-Netzwerkrichtlinien steuern den Pod‑zu‑Pod‑Datenverkehr und erlauben ausschließlich genehmigte Verbindungen mit Default Deny. Die Liste der zugelassenen IP-Adressen für den AKS‑Server schränkt API‑Aufrufe auf genehmigte Quellen ein.
◦ Netzwerksicherheitsgruppen (NSGs) im AKS-VNet erlauben ausschließlich genehmigte IP‑Adressbereiche, reduzieren die Angriffsfläche und blockieren nicht angeforderten Netzwerkverkehr.
◦ Der Zugriff von Workloads in AKS‑Pods auf Azure‑Ressourcen erfolgt über verwaltete Identitäten, um die Verwendung von Geheimnissen zu vermeiden.
◦ Azure OpenAI ist nur über einen privaten Endpunkt innerhalb des VNet erreichbar. Die Namensauflösung erfolgt über Private DNS auf eine private IP‑Adresse, wodurch eine Exponierung über öffentliche DNS‑Dienste verhindert wird.
◦ Der öffentliche Netzwerkzugriff auf Azure OpenAI ist deaktiviert. Der gesamte Datenverkehr verbleibt innerhalb des Azure‑Backbones und nutzt private Konnektivität.
◦ Dienstaufrufe an OpenAI verwenden eine benutzerzugewiesene verwaltete Identität innerhalb der definierten Vertrauensgrenze. Dies ermöglicht feingranulare Zugriffskontrollen und eine authentifizierungsbasierte Nutzung ohne Schlüsselrotation.
◦ Die Netzwerkisolierung wird Ende‑zu‑Ende durchgesetzt, ohne öffentliche Exponierung der Azure‑OpenAI‑Endpunkte. Der ausgehende Datenverkehr ist auf private Links beschränkt.
◦ Wir empfehlen dringend, dass Kunden mithilfe von Terraform autorisierte IP‑Adressbereiche für den AKS‑API‑Server konfigurieren und ausgehende IP‑Adressen für das Codebeamer KI Plugin auf die Positivliste setzen.
Sicherheit von Container‑Images
Das Container‑Image ist so erstellt, dass es als Nicht‑Root‑Benutzer ausgeführt wird.
Sicherheitsüberprüfung für PTC Artefakte
Wir empfehlen Kunden die obligatorische Sicherheitsüberprüfung vor der Nutzung für alle bereitgestellten Artefakte, einschließlich IaC-Vorlagen, Container-Images und Helm-Charts. Die Nutzung muss blockiert werden, wenn nicht behobene kritische oder hochriskante Schwachstellen vorhanden sind. Für eine temporäre Risikoakzeptanz sind genehmigte Ausnahmen erforderlich.
Darüber hinaus wird empfohlen, die Laufzeit-Sicherheitsüberprüfung für die gesamte über IaC bereitgestellte Infrastruktur sowie innerhalb von Azure Kubernetes Service (AKS)‑Clustern zu aktivieren, um eine kontinuierliche Bedrohungserkennung und Compliance über Prüfungen zur Build-Zeit hinaus sicherzustellen.
Wir empfehlen außerdem, Scan-Nachweise, Software Bills of Materials (SBOMs) und Artefakt‑Signaturen für jede Version aufzubewahren, um Nachvollziehbarkeit, Compliance und einen sicheren Betrieb zu unterstützen.
Richtlinien für die operative Sicherheit
Die Lösung enthält Infrastruktur als Code sowie ein bereitgestelltes Container‑Image‑Archiv. Diese Ressourcen stellen eine sichere Basis für Bereitstellung und Laufzeitbetrieb bereit. Die Kunden sind dafür verantwortlich, ihre eigenen Kontrollen zur Dienstexponierung zu konfigurieren, um organisatorische und regulatorische Anforderungen zu erfüllen. Typische Muster für externe Exponierung beinhalten eine Ingress‑ oder Gateway‑Ebene mit TLS‑Terminierung und HTTP‑Sicherheitsfunktionen und können WAF‑ähnliche Schutzmechanismen umfassen, die an den OWASP‑Richtlinien ausgerichtet sind, einschließlich Authentifizierung, Ratenbegrenzung und Datenverkehrsfilterung. Wenn keine vollständige Web Application Firewall (WAF) eingesetzt wird, können Gateway‑basierte Kontrollen einen teilweisen Schutz bieten, stellen jedoch keinen vollständigen Ersatz dar.
Für einen sicheren Betrieb umfassen Bereitstellungen in der Regel Zugriffskontrollen nach dem Prinzip der geringsten Rechte, Netzwerksegmentierung, eingeschränkten eingehenden Datenverkehr (Ingress) sowie kontrollierten ausgehenden Datenverkehr (Egress), beispielsweise durch IP‑Positivlisten in Kombination mit identitätsbasierter Validierung. Diese Plattformmaßnahmen werden von den Kunden im Einklang mit ihren unternehmensinternen Sicherheitsrichtlinien implementiert.
Kunden müssen die bewährten Sicherheitsverfahren befolgen, wenn sie zusätzliche Tools wie Grafana, Prometheus, Aspire, Zipkin oder andere Tools konfigurieren, die als Exporttools in OTEL-Konfigurationen konfiguriert sind.
Weitere Informationen finden Sie unter den folgenden Links.