So stellst du eine Anfrage¶
Alle Anfragen laufen über den Intake deines Plattform-Teams (zum Beispiel ein Ticket oder Work Item). Das Plattform-Team ist XMMS im Rahmen eines Managed-Service-Vertrags oder das eigene Plattform-Team deiner Organisation: siehe Betriebsmodelle und Support. Jede Anfrage ist eine Standardänderung: ein bekanntes Verfahren mit festen Anfragefeldern. Fülle alle Felder aus; eine vollständige Anfrage wird am schnellsten bearbeitet.
Anfrage oder pull request?
Manche Plattformen lassen Workload-Teams eine Änderung selbst vorbereiten, meist eine Firewallregel, und zwar als pull request auf das Konfigurations-Repository. Das Plattform-Team prüft und deployt ihn. Frag dein Plattform-Team, ob das für dich möglich ist. Wenn ja, lies zuerst die Richtlinien für Firewallregeln und die Prüfung von pull requests. Die Schritte für die Dateien stehen in Firewallregeln und IP-Gruppen.
Jede Anfrage¶
| Feld | Pflicht | Beispiel |
|---|---|---|
| Begründung | ja | "Neues Rechnungsportal für Finance" |
| Umgebung | ja | dev, tst, acc, prd, shared |
| Kommentare | nein | Alles Weitere, was wir wissen müssen |
Ein neuer Spoke¶
| Feld | Pflicht | Beispiel / Hinweise |
|---|---|---|
| Name (Kurzname des Workloads) | ja | invprt. Maximal 6 Zeichen, später nicht änderbar. |
| Umgebung(en) | ja | dev und prd. Ein Spoke pro Umgebung. |
| Vorhandene subscription | ja | Die subscription-ID, falls deine Organisation subscriptions zuerst anlegt. Frag dein Plattform-Team, wie subscriptions erstellt werden. |
| Produktionsdaten ja/nein | ja | Bestimmt die management group und die Policies |
| Personenbezogene Daten (PII) ja/nein | ja | Setzt den Tag pii |
| Aus dem Internet erreichbar ja/nein | ja | Bestimmt corp oder online und ob du das App Gateway brauchst |
| Größe des IP-Bereichs | ja | Zum Beispiel ein /24. Das Plattform-Team weist den Bereich zu. |
| Subnets | ja | Name und Größe pro Subnet, Delegierungen (z. B. Microsoft.Web/serverFarms), Service Endpoints (z. B. Microsoft.Storage) |
| Team-Zugriff | ja | Anzeigename deiner bestehenden Entra-ID-Gruppe und pro Rolle, ob du direkten Zugriff, PIM mit Selbstgenehmigung oder PIM mit Genehmigung möchtest. Die Gruppe muss existieren, bevor der Spoke erstellt wird. |
| Tags | ja | owner, department, workload, costcentre |
| Region | nein | Standard ist die primäre Region der Plattform |
| Azure DevOps Repository + Service Connection | nein | Projektname und Repository-Name |
| Optionale Ressourcen | nein | Lass Key Vault, Storage oder Log Analytics weg, wenn du sie nicht möchtest. Sag Bescheid, wenn du den private endpoint des Key Vault oder Storage Accounts nicht nutzen wirst. |
| Genehmigungen | je nachdem | Die Genehmigungen, die deine Organisation verlangt, bevor ein Workload erstellt wird, zum Beispiel Product Owner, Architektur und Security. Siehe Onboarding. |
Weitere Anfragen¶
| Anfrage | Felder |
|---|---|
| Firewallregel (neu oder geändert) | Quelle (Spoke/Subnet), Ziel (FQDN, IP oder Service Tag), Port und Protokoll, Begründung. Für ausgehenden Internetverkehr bevorzuge FQDNs. |
| App über das Application Gateway veröffentlichen | Workload-Name, Backend-Adresse (IP/FQDN), Listener-URL, Port (HTTP/HTTPS), SSL-Zertifikat (für HTTPS), Redirects ja/nein, Health Probe (Pfad, Protokoll, Intervall). Optional: URLs eigener Fehlerseiten (zum Beispiel für 502 und 403). |
| App-Gateway-Konfiguration ändern | Dieselben Felder, nur was sich ändert |
| Zertifikat auf dem Application Gateway erneuern oder ersetzen | Listener-URL und Zertifikatsname. Wer das Zertifikat bestellt, hängt von deiner Plattform ab: siehe Zertifikate für veröffentlichte Apps. |
| Ausnahme für die Web Application Firewall | Die blockierte Anfrage (URI, Argumentname, Regel-ID aus dem WAF-Log), warum es ein False Positive ist, und die Security-Genehmigung. Siehe Application Gateway. |
| Eingehendes SFTP von einer externen Partei zu einem Storage Account | Siehe Eingehendes SFTP zu einem Storage Account |
| Managed VM (neu, ändern, entfernen) | Siehe Managed Virtual Machines |
| Policy-Ausnahme | Policy oder initiative, Scope (deine subscription oder resource group), Kategorie (Waiver oder Mitigated), Begründung, alternative Maßnahmen, Enddatum, Security-Genehmigung. Siehe Policy und Ausnahmen. |
| Änderung an deinem Spoke | Siehe So änderst du |
| Spoke löschen | Spoke-Name und Umgebung, Bestätigung, dass Daten gelöscht werden dürfen, Bestätigung, dass du der Workload-Eigentümer bist. Das Löschen ist endgültig: Die resource groups, der Key Vault und der Storage des Spokes werden zerstört. Die subscription wird nicht automatisch gekündigt. Entferne in derselben Anfrage die Firewallregeln und Application-Gateway-Einträge des Workloads. Siehe Einen Spoke löschen. |
| Gruppenzugriff (PIM-Modus, Team-Gruppe) | Siehe Zugriff, Gruppen und PIM |
| Budget, Reservierung | Siehe Kosten und Reservierungen |
| Shared Service (Registry, APIM, Gateway) | Siehe Shared Services |
| Eine neue Region | Region, Begründung. Das ist eine Plattformänderung und dauert länger. |
Firewallregeln¶
Ausgehender Verkehr und Spoke-zu-Spoke-Verkehr werden blockiert, sofern keine Regel ihn erlaubt. Beantrage die Regel, bevor du sie brauchst.
| Feld | Beschreibung |
|---|---|
| Quelle | Der Spoke oder das Subnet (CIDR), von dem der Verkehr ausgeht |
| Ziel | IP-Adresse, CIDR, FQDN oder Service Tag. Für Internetziele bevorzuge FQDNs. |
| Port(s) | Die Portnummern des Dienstes |
| Protokoll | TCP, UDP oder HTTP/HTTPS |
| Umgebung | Eine Anfrage pro Umgebung (dev, tst, acc, prd), da jede ihre eigenen Regeln hat |
| Begründung | Warum dieser Verkehr benötigt wird |
- Für Verkehr zwischen zwei Workloads in Azure stellt der Eigentümer des empfangenden (Ziel-)Workloads die Anfrage.
- Das Plattform-Team (oder dein Security Officer, der genehmigt) prüft die Anfrage anhand der Sicherheitsrichtlinie und setzt sie dann in der firewall-Konfiguration des hub um.
- Für Operatoren: siehe Firewallregeln.
- Workload-Teams, die den pull request selbst vorbereiten: Firewallregeln und IP-Gruppen.
Wer welche Regel beantragt¶
Ein gängiges Eigentumsmodell, das pro Regel einen klaren Eigentümer sicherstellt:
| Verkehr | Wer beantragt |
|---|---|
| Dein Workload zu einem Internetziel | Dein Team (die Quelle) |
| Dein Workload zu einem On-Premises-System | Dein Team (die Quelle) |
| Ein Azure-Workload zu einem anderen | Das Team des Ziel-Workloads |
| Ein externes oder On-Premises-System zu einem Azure-Workload | Das Team des Ziel-Workloads |
Der Grund, interne Regeln beim Ziel anzusiedeln, ist, dass die firewall gemeinsam genutzt wird. Könnten beide Seiten Regeln hinzufügen, könnte ein Workload Verkehr zu einem anderen Workload öffnen, der nie zugestimmt hat. Der Eigentümer des Ziels entscheidet, wer sich mit seinem Workload verbinden darf.
Regeltyp und Ziel wählen¶
- Verwende eine Application Rule für HTTP-, HTTPS- und SQL-Verkehr zu einem Internet-FQDN. Sie greift anhand des FQDN, und die firewall kann den Verkehr inspizieren.
- Verwende eine Network Rule für andere Protokolle und für internen Verkehr. Application Rules übersetzen die Quelladresse (SNAT), sodass das Ziel die firewall statt deines Workloads sieht und quellbasiertes Logging und Troubleshooting schwieriger werden. Deine Plattform kann es anders entscheiden, folge also dem, was dein Plattform-Team sagt.
- Benenne das Ziel so genau wie möglich: zuerst ein FQDN, dann eine einzelne IP-Adresse, dann ein IP-Bereich. Beantrage
kein
*, „any“ oder breite Bereiche. Nenne die genauen Ports. - Mehrere Regeln brauchen oft dieselben Adressen. Das Plattform-Team legt sie dann in einer IP-Gruppe ab (IP-Gruppen).
Was die Prüfung üblicherweise kontrolliert¶
Organisationen legen oft Regeln wie diese fest. Frag deine, welche gelten.
- Standardmäßig nur verschlüsselte Protokolle. Unverschlüsselte Protokolle brauchen eine zusätzliche Genehmigung der Security.
- Keine Regeln zwischen Produktions- und Nicht-Produktionsumgebungen, damit Produktionsdaten nicht in Nicht-Produktion fließen.
- Internet-Regeln und interne Regeln werden getrennt gehalten.
- Interne Regeln zwischen Workloads brauchen die Genehmigung des Eigentümers des Ziels. Regeln ins Internet oder zu einem Workload mit anderer Nutzungsart brauchen meist zusätzlich ein Security-Review.
Das folgende Beispiel zeigt, wie Genehmigungen aufgeteilt werden können. Es ist ein Beispiel, keine feste Regel der Plattform.
| Anfrage | Eigentümer des Ziels genehmigt | Security prüft die Begründung | Plattform-Team prüft technisch |
|---|---|---|---|
| Verkehr zwischen zwei Spokes desselben Workloads | ja | nein | ja |
| Verkehr von einem anderen Workload mit derselben Nutzungsart (prod oder non-prod) | ja | ja | ja |
| Ausgehender Verkehr ins Internet | ja | ja | ja |
| Verkehr von oder zu On-Premises | ja | ja | ja |
| Eine kleine Änderung an einer bestehenden Regel (nur Quelle oder Ziel innerhalb desselben Spokes ändert sich) | ja | nein | ja |
| Alles andere | ja | ja | ja |
Zertifikate für veröffentlichte Apps¶
Für einen HTTPS-Listener auf dem Application Gateway liegt das Zertifikat im Key Vault des Gateways, das das Plattform-Team verwaltet. Das Bestellen und Erneuern des Zertifikats liegt meist in der Verantwortung der Kundenseite (ein zentrales Team oder das Workload-Team), weil die Zertifizierungsstelle und ihr Konto zu deiner Organisation gehören. Kläre mit deinem Plattform-Team, wer was tut, wenn du die App veröffentlichst, und trage das Ablaufdatum in deinen Kalender oder dein Monitoring ein. Die Schritte zur Erneuerung stehen unter Ein Zertifikat auf dem Application Gateway ersetzen. Wenn das Backend dasselbe Zertifikat verwendet (zum Beispiel ein Reverse Proxy, der TLS terminiert), müssen beide Kopien gleichzeitig ersetzt werden.
Wie es weitergeht¶
- Das Plattform-Team prüft die Anfrage und stellt Rückfragen, wenn Felder fehlen.
- Es setzt die Änderung im Code um, lässt sie prüfen, testet sie bei Bedarf auf der canary-Plattform und wendet sie an.
- Du erhältst eine Bestätigung, was erstellt oder geändert wurde. Bei einem neuen Spoke: der subscription-Name, der VNet-Bereich, die Gruppen- namen und (wenn du PIM nutzt) wie du deine Rolle aktivierst.