Designprinzipien und Guardrails¶
Plattform-Philosophie erklärt, wie das Produkt gebaut ist. Diese Seite behandelt die Regeln für die Nutzung der Plattform: die Guardrails, denen Workload-Teams und das Plattform-Team folgen. Sie sind ein empfohlener Satz. Deine Organisation entscheidet, welche gelten und wer sie durchsetzt.
Policy, Standard, Best Practice¶
Lege für jede Regel fest, wie verbindlich sie ist.
| Stufe | Bedeutung | Beispiel |
|---|---|---|
| Policy | Muss befolgt werden. Möglichst durch Technik erzwungen. | Storage Accounts sind nicht aus dem öffentlichen Internet erreichbar |
| Standard | Muss befolgt werden, außer eine Abweichung ist begründet | Eine Standardsprache oder ein Standardtool, es sei denn, eine benötigte Bibliothek ist nicht verfügbar |
| Best Practice | Empfohlen, nicht verpflichtend | Tests gegen gemeinsame Datenmodelle ausführen |
Guardrails für Workload-Teams¶
| # | Guardrail | Warum |
|---|---|---|
| 1 | Keine manuellen Änderungen in der Produktion. Nutze eine Deployment-pipeline. | Manuelle Änderungen haben keine Historie (was, wer, warum geändert wurde) und sind fehleranfällig |
| 2 | Automatisiere so viel wie möglich: Infrastructure as Code, pipelines, Skripte | Manuelle Aufgaben sind nicht reproduzierbar und verursachen Fehler |
| 3 | Vier-Augen-Prinzip für jede Änderung in der Produktion, zum Beispiel ein geprüfter pull request | Eine unabhängige Kontrolle fängt Fehler ab |
| 4 | Wiederverwenden vor Kaufen vor Bauen | Wiederverwenden und Kaufen sind langfristig meist günstiger |
| 5 | Cloud-nativ vor Drittanbieter, und SaaS vor PaaS vor IaaS | Lässt sich leichter in die übrige Landschaft integrieren |
| 6 | You build it, you run it, you own it | Entwirf für den Betrieb, denn du wirst ihn betreiben |
| 7 | Observability darf keinen Zugriff auf die Daten erfordern | Operatoren können die Gesundheit prüfen, ohne sensible Inhalte zu sehen |
| 8 | Isoliere die Entwicklung: Die Arbeit eines Teams darf die eines anderen nicht kaputt machen | Deploye oft in die Produktion statt Big-Bang-Releases |
| 9 | Teste die entscheidenden Teile | Keine 100 % Abdeckung, sondern Tests, die Refactoring und Continuous Deployment absichern |
| 10 | Melde dich mit Entra ID mit MFA an. Vergib Zugriff an Gruppen, nie an Einzelpersonen. | Eine Identität, ein Kontrollpunkt |
Dazu passende Best Practices: In der pipeline linten und Security-Tests ausführen, lieber kleine Best-of-Breed-Tools als ein Tool, das alles kann, die Zahl der Verbindungen zwischen Ressourcen gering halten, APIs standardisieren und die Best Practices der verwendeten Dienste befolgen.
Guardrails für die Infrastruktur¶
| # | Guardrail | Warum |
|---|---|---|
| 1 | Öffentlicher Zugriff auf einen Workload läuft über die zentralen Einstiegspunkte: HTTP(S) über das Application Gateway, andere Protokolle über die Azure Firewall | Ein Ort, um eingehenden Verkehr zu prüfen und zu kontrollieren |
| 2 | Keine öffentlichen IP-Adressen an Workload-Ressourcen | Folgt aus dem vorherigen Guardrail |
| 3 | Nutze private Konnektivität. Öffentlicher Zugriff auf Ressourcen ist standardmäßig blockiert; private endpoints sind der bevorzugte Weg. Ist das nicht möglich, erlaube nur bestimmte Subnets oder IP-Adressen. | Hält den Datenverkehr aus dem Internet heraus |
| 4 | Verwende die neueste TLS-Version, die ein Dienst anbietet | Security |
| 5 | Umgebungen sind vollständig isoliert: Jede hat eigene Ressourcen, Konfiguration und Abhängigkeiten | Verhindert, dass Probleme in einer Stufe auf eine andere übergreifen, und unterstützt parallele Entwicklung und Tests |
In der Plattform werden diese durch die zentrale firewall, das Private DNS und Policies umgesetzt, die öffentliche Endpunkte blockieren. Eine Möglichkeit, einer externen Partei eingehenden Zugriff auf eine Ressource zu geben, ist Eingehendes SFTP auf einen Storage Account. Siehe Einschränkungen und Policy und Ausnahmen.
Guardrails für pipelines und Repositories¶
Die Plattform läuft auf pipelines, daher gehört die pipeline-Plattform zum Security-Modell. Eine Baseline in Kürze:
- Organisation. Ein nicht-persönliches Konto besitzt die Organisation. Zugriff nur mit Entra-ID-Identitäten, über Gruppen. Privilegierte Rollen nur über PIM. Alternative Authentifizierungsdaten und OAuth-Zugriff von Drittanbietern sind deaktiviert.
- Die Historie ist Beweismaterial. Niemand löscht Builds, Releases, Repositories oder Team-Projekte.
- Produktions-Deployments brauchen eine Genehmigung auf der Produktionsstufe und laufen nur von bestimmten Produktions-Branches.
- Pipelines sind YAML, klassische pipelines sind deaktiviert, und Variablen, die zur Queue-Zeit gesetzt werden können, sind eingeschränkt.
- Secrets liegen in einem Vault, nicht in pipeline-Variablen. Sie werden nie geloggt, sondern auditiert und rotiert. Bevorzuge Service Connections mit minimalem Scope und Service Principals statt Personal Access Tokens.
- Branches haben Policies ohne Bypass: mindestens zwei Reviewer, die Person, die zuletzt gepusht hat, kann nicht genehmigen, Kommentare sind aufgelöst, ein Build ist erfolgreich und ein Work Item ist verknüpft. Forking ist deaktiviert.
- Produktions-Secrets liegen in einem separaten Vault, mit Zugriff nach dem Need-to-know-Prinzip. Test- und Produktions-Zugangsdaten werden nicht vermischt.
- Agents. Nur wenige Konten haben Berechtigungen, die firewall ist so restriktiv, wie die Agents es zulassen, Pools werden regelmäßig aktualisiert, und Produktions-Artefakte verwenden einen separaten Pool (Zugriff der Build-Agents).
Die vollständige Liste für Azure DevOps mit den Einstellungen steht unter Azure DevOps: Einrichtung und Leitprinzipien.
Wie sich das zu den MCP-pipelines verhält
Das MCP-Konfigurations-Repository hat eigene Schutzmaßnahmen: Genehmigungsmodi für prod-Läufe und Branch Protection auf dem Konfigurations-Repository. Siehe Pipelines und Workflows. Die Guardrails auf dieser Seite gelten für die pipelines, die deine Workload-Teams bauen.
Freiheit innerhalb eines Rahmens¶
Guardrails bedeuten nicht, dass alles zentral kontrolliert wird. Eine gute Plattform gibt Teams Autonomie, wo es sicher ist: Das Team besitzt seine pipelines, seine Ressourcen innerhalb seines Spokes und in manchen Designs seine eigenen DNS-Zonen (DNS-Subdomain-Delegation). Die Plattform setzt den Rahmen mit Policy, Namensgebung und Netzwerk und prüft ihn automatisch.