Service-Typen: Core, Direct und Additional¶
Die Plattform bietet ihre Services in drei Typen an. Der Typ sagt dir, wer einen Service anfragen kann, wie er eingerichtet wird und ob zusätzliche Kosten oder eine separate Vereinbarung dazugehören. Welche Services es auf deiner Plattform gibt, hängt davon ab, was gekauft und aktiviert wurde. Frag dein Plattform-Team.
| Typ | Was es ist | Wer fragt ihn an | Zusätzliche Vereinbarung oder Gebühr |
|---|---|---|---|
| Core | Das Fundament, von dem jeder andere Service abhängt. Wird zentral betrieben und gepflegt. | Niemand: Er ist immer da | Nein |
| Direct | Services, die ein Workload-Team direkt anfragen kann. Für das Team konfiguriert und auf dessen Workload isoliert. | Workload-Team, über eine Standardänderung | Nein, Teil der Plattform |
| Additional | Services on top der Baseline, mit eigenem Umfang | Workload-Team, nach einem Intake | Meist ja: eine separate Gebühr, ein separates Service Level und, wo nötig, ein Implementation Statement of Work |
Im Managed-Modell (Betriebsmodelle) sind die Additional Services der Teil des Vertrags, der über die Plattform-Baseline hinausgeht. Im Eigenbetrieb sind es Services, die dein eigenes Plattform-Team anbieten kann.
Core Services¶
Core Services sind die Versorgungsleistungen der Plattform. Wenn sie zentral betrieben werden, bleiben sie zuverlässig, sicher und kosteneffizient.
| Core Service | Was er umfasst | Mehr |
|---|---|---|
| Connectivity | Virtual WAN und virtual hub pro Region, VPN- und ExpressRoute-Gateways zu Rechenzentren und Niederlassungen, der Private DNS Resolver, der zentrale IP-Plan und IP Groups | Architektur, DNS-Design |
| Firewalling | Die zentrale Azure-Firewall-Policy, Application Gateway mit Web Application Firewall (WAF), Baseline-NSGs, hostbasierte firewalls innerhalb von VMs | Organisation der Firewallregeln |
| Governance | Management groups, Azure Policy und Initiatives, Tags, RBAC-Modell, Kostenmanagement | Governance |
| Monitoring | Action Groups, Azure Monitor Baseline Alerts, Service-Health-Alerts, zentrales Log Analytics | Betriebsverantwortlichkeiten |
| Security-Plattformen | Microsoft Defender for Cloud und, falls aktiviert, Microsoft Sentinel | Identitäts- und Zugriffsmodell |
Firewalling im Detail¶
Firewalling ist in Schichten aufgebaut. Jede Schicht hat eine andere Aufgabe.
| Komponente | Schützt |
|---|---|
| Azure Firewall (hub) | Verkehr zwischen spokes, zu On-Premises-Netzwerken, zu anderen landing zones und ins Internet |
| Application Gateway mit WAF | Eingehenden Web-Verkehr aus dem Internet zu Workloads. Die WAF blockiert gängige Exploits (zum Beispiel SQL Injection und Cross-Site-Scripting). |
| Network Security Groups (NSG) | Verkehr in ein Subnet und aus einem Subnet. Jedes Subnet bekommt eine NSG, damit die Konnektivität so eng wie möglich bleibt. |
| Hostbasierte firewall | Verkehr auf der Maschine selbst. Gehört dem Workload-Team. |
| Eine bestehende On-Premises-firewall | Verkehr von der anderen Seite einer VPN- oder ExpressRoute-Verbindung, falls du eine hast. Regeln müssen meist auf beiden Seiten geändert werden. |
Eine Reihe von Prinzipien für Firewallregeln, die mehrere Managed-Plattformen nutzen:
| Prinzip | Grund |
|---|---|
| Nutze verschlüsselte Protokolle, es sei denn, der Workload kann es nicht | Verschlüsselung hält sensible Daten geheim |
| Regeln gehören einem Workload | Es muss immer klar sein, wem eine Regel gehört |
| Halte Produktions- und Nicht-Produktionsregeln getrennt und erlaube keinen Verkehr zwischen beiden | Produktionsdaten dürfen nicht in Nicht-Produktionsumgebungen verarbeitet werden |
| Halte interne und internetseitige Regeln getrennt | Externer Verkehr ist eine höhere Bedrohung |
| Eingehender Verkehr zu einem spoke wird abgelehnt, es sei denn, der Workload braucht ihn | Unnötige Kommunikation ist ein direktes Risiko |
| Definiere Regeln am Ziel, nur als eingehenden Verkehr | Die firewall wird gemeinsam genutzt. Könnte Workload B eine Regel hinzufügen, die Workload A öffnet, wäre Workload A ohne eigene Freigabe offen. |
Wie du die Regeldateien organisierst, steht in Organisation der Firewallregeln.
Application Gateway und WAF: typische Einstellungen¶
Der Einstiegspunkt Application Gateway wird als Code konfiguriert. Typische, anpassbare Einstellungen:
| Einstellung | Typischer Wert | Warum |
|---|---|---|
| Tier | WAF v2 | Aktiviert die WAF für jede Anfrage |
| Kapazität | Autoscale mit mindestens zwei Instanzen und einem festen Maximum | Redundanz, mit einer Obergrenze für die Kosten |
| HTTP/2 | Aktiviert | |
| TLS-Policy | Eine vordefinierte Policy mit mindestens TLS 1.2 | |
| WAF-Modus | Prevention, mit dem von Microsoft verwalteten Regelsatz und Prüfung des Request Body | Blockiert passende Anfragen aktiv |
| Log Scrubbing | Aktiviert | Maskiert sensible Werte in WAF-Logs |
| Zertifikate | In einem dedizierten Key Vault gespeichert; das Gateway liest sie mit einer Managed Identity | |
| Zugriff | Nur das Plattform-Team, über PIM | Die Ressourcen liegen in einer eigenen resource group |
Typischer Umgang mit False Positives: Das Workload-Team beantragt eine Ausnahme, das Plattform-Team holt die Freigabe der Security ein, und die Ausnahme wird dann als Exclusion für die konkrete Regel und das konkrete Request-Argument hinzugefügt. Eine Regel, die Microsoft selbst wegen False Positives zu deaktivieren empfiehlt, kann plattformweit deaktiviert werden. Führe eine Liste der Exclusions und deaktivierten Regeln mit ihrer Begründung.
Die obigen Werte sind Beispiele. Die tatsächlichen Einstellungen stehen in deiner Plattformkonfiguration (Application Gateway).
Direct Services¶
Direct Services werden vom Workload-Team angefragt und für dieses Team eingerichtet.
| Service | Was es ist |
|---|---|
| Workload und spoke | Eine subscription mit Netzwerk, Gruppen, PIM, Service Principal, Key Vault, Storage und Log Analytics, verbunden mit dem hub. Siehe Was du bekommst und Spoke-Varianten. |
| Bastion-Zugriff | Ein zentraler Azure-Bastion-Host, damit Teams keine eigenen deployen. Siehe Mit VMs verbinden und Design-Hinweise zu Bastion. |
| Build-Agents | Selbst gehostete pipeline-Agents im Netzwerk, um private Ressourcen zu erreichen. Siehe Zugriff für Build-Agents und den Container Agent Pool. |
| Entwicklerzugriff über VPN | Point-to-Site-VPN, damit Engineers private Ressourcen in ihren spokes erreichen. Siehe Entwicklerzugriff mit Point-to-Site-VPN. |
Design-Hinweise zu Bastion¶
Wenn die Plattform einen zentralen Bastion-Host anbietet, sind diese Einstellungen in einem Virtual-WAN-Design wichtig:
| Einstellung | Wert | Warum |
|---|---|---|
| Tier | Standard | Nötig für Verbindungen über IP-Adresse, die ein Virtual-WAN-Design verlangt |
| IP-basierte Verbindung | Aktiviert | Lässt Bastion eine Verbindung zu einer privaten IP-Adresse in einem anderen spoke aufbauen |
| Native-Client-Unterstützung | Aktiviert | Erlaubt die Azure CLI oder native RDP- und SSH-Clients, zum Beispiel von macOS |
| Kopieren und Einfügen | Aktiviert | Einfacher, Skripte und Befehle einzufügen |
| Anzahl der Instanzen | Zwei oder mehr | Redundanz |
Bastion liegt in einem eigenen virtuellen Netzwerk mit einem Subnet namens AzureBastionSubnet. Die firewall erlaubt nur SSH (22) und RDP
(3389) aus diesem Subnet zu den Adressbereichen der Workloads. Der Zugriff wird über eine Entra-ID-Gruppe gesteuert, die Reader
auf der Bastion-resource-group hat und mit Team-Gruppen (nicht mit einzelnen Benutzern) befüllt wird. Benutzer brauchen die IP-Adresse der
Zielmaschine und die Zugangsdaten dafür.
Additional Services¶
Additional Services brauchen einen Intake, weil ihr Umfang vom Workload abhängt. Eine typische Vereinbarung enthält:
- ein Service Level Addendum mit Umfang, Servicefenster und Verfügbarkeit des täglichen Supports,
- ein Implementation Statement of Work, wenn der Workload erst konform mit dem Service gemacht werden muss,
- eine Gebühr,
- Reporting an das Workload-Team.
Beispiele:
| Service | Was sich gegenüber einem normalen spoke ändert |
|---|---|
| Managed Spoke (Servicebeschreibung) | Das Plattform-Team baut, deployt, wartet und überwacht zusätzlich die Azure-Ressourcen des Workloads, als Infrastructure as Code on top des Standard-spokes |
| Managed Virtual Machines | Das Plattform-Team übernimmt die Erstkonfiguration und das Patching des Betriebssystems. Siehe Managed Virtual Machines. |
| Base Fabric Data Platform | Eine managed Microsoft-Fabric-Umgebung (capacity, workspaces, private Konnektivität, Connections) auf einem Spoke. Siehe Base Fabric Data Platform. |
| Integration Platform | Managed Integrations-Bausteine (Service Bus, Logic Apps, Function Apps, Container Apps, Data Factory) mit Shared API Management und Event Hubs. Siehe Integration Platform. |
| AI Platform | Ein gemeinsamer Azure-AI-Foundry-Account mit einem Projekt pro workload und Datenspeichern für Agents. Siehe AI Platform. |
| AKS Platform | Eine managed Kubernetes-Variante (AKS in Azure oder auf Azure Local) mit Baseline, Identität und Security Policy. Siehe AKS Platform. |
| Agentic Developer Portal | Ein optionales, Backstage-basiertes Portal mit einem Katalog der Workloads, Kosten-, Netzwerk-, Security- und Compliance-Ansichten, KI-Agents und einem MCP-Server. Siehe Agentic Developer Portal. |
| Andere Managed-Plattformen (zum Beispiel Virtual Desktops) | Eine Managed-Variante des Services, angeboten, wenn das Plattform-Team sie gebaut hat |
Spoke-Varianten¶
| Variante | Nutze sie, wenn | Was anders ist |
|---|---|---|
| Standard-Spoke | Normalfall | Der Standard: ein spoke pro Umgebung, einer für Produktionsdaten und die anderen für Nicht-Produktionsdaten |
| Sandbox | Experimente mit Azure | Eine subscription in der management group sandbox ohne Verbindung zum hub, zu anderen Workloads oder internen Netzwerken. Siehe Neue Sandbox-subscription. |
| Managed Spoke | Das Team lernt Azure noch, will nicht in die technischen Fähigkeiten investieren oder hat zu wenige Leute, um den Workload technisch zu betreuen | Dieselbe Baseline wie der Standard-spoke. Das Plattform-Team pflegt zusätzlich die Workload-Ressourcen, im Rahmen einer separaten Vereinbarung. |
Beim Managed Spoke läuft der Prozess üblicherweise so: ein Intake mit dem Plattform-Team, eine Bewertung der aktuellen oder neuen Lösung, ein Service Level Addendum, Aufbau und Deployment der Infrastructure as Code, Support im vereinbarten Fenster und Reporting an das Workload-Team. Das Workload-Team bleibt für den Workload verantwortlich: siehe Verantwortlichkeiten.
Anfragen für neue Services¶
Eine Anfrage für neue gemeinsame Funktionalität wird zuerst von Architektur, Betrieb und Security bewertet. Sie ist entweder eine Erweiterung eines bestehenden Services (zum Beispiel eine neue Option in einem feature flag) oder ein neuer Service. Ein Feature, das neues Terraform braucht, ist eine Entwicklungsänderung im Code-Repository, keine Standardänderung: siehe Plattform-Philosophie.