Der Entwickler testet seine Änderung „kurz auf Prod” — und legt die Datenbank lahm. In der Testumgebung laufen echte Kundendaten, weil „synthetische Daten zu aufwendig” waren. Das Staging-System hat denselben Datenbankserver wie die Produktion. A.8.31 fordert eine strikte Trennung von Entwicklungs-, Test- und Produktionsumgebungen — um die Produktion und ihre Daten vor Kompromittierung durch Entwicklungs- und Testaktivitäten zu schützen.
Was verlangt die Norm?
- Umgebungen in separaten Domänen betreiben. Entwicklung, Test und Produktion sind logisch oder physisch getrennt.
- Regeln für Deployment definieren. Software wird nur über einen kontrollierten Prozess von einer Umgebung in die nächste übertragen.
- Produktionstest nur nach Genehmigung. Tests in der Produktionsumgebung nur in begründeten Ausnahmefällen und mit expliziter Genehmigung.
- Entwicklungstools von Produktion fernhalten. Compiler, Debugger und Entwicklungstools haben auf Produktionssystemen nichts verloren.
- Sensible Daten in Nicht-Produktionsumgebungen schützen. Keine echten Produktionsdaten in Test- oder Entwicklungsumgebungen ohne Maskierung.
In der Praxis
Drei-Umgebungen-Modell etablieren. Entwicklung (freies Experimentieren), Staging/Test (produktionsnahe Konfiguration, maskierte Daten), Produktion (streng kontrolliert). Jede Umgebung hat eigene Zugriffsrechte, eigene Netzwerke und eigene Daten.
Deployment-Pipeline als einzigen Weg in die Produktion. Code gelangt nur über die CI/CD-Pipeline in die Produktion — kein manuelles Deployment, kein direkter Zugriff. Die Pipeline erzwingt Tests, Reviews und Genehmigungen.
Zugriffskontrolle pro Umgebung. Entwickler haben Zugang zur Entwicklungs- und Testumgebung. Zugang zur Produktion ist auf Operations beschränkt. Diese Trennung verhindert versehentliche und böswillige Änderungen.
Konfigurationsdrift verhindern. Staging und Produktion müssen die gleiche Konfiguration haben (Infrastructure as Code). Abweichungen zwischen den Umgebungen führen dazu, dass Tests in Staging keine aussagekräftigen Ergebnisse liefern.
Typische Audit-Nachweise
- Umgebungstrennung — Nachweis getrennter Infrastruktur (Netzwerke, Accounts, Zugriffe) (→ Richtlinie sichere Softwareentwicklung im Starter Kit)
- Zugriffsrechte pro Umgebung — wer hat auf welche Umgebung Zugriff
- Deployment-Pipeline-Konfiguration — Nachweis, dass Deployments nur über die Pipeline laufen
- Genehmigungsprotokolle — dokumentierte Ausnahmegenehmigungen für Produktionszugriffe
- Testdaten-Nachweis — Bestätigung, dass Testumgebungen keine echten Produktionsdaten enthalten
KPI
Anteil der Projekte mit vollständig getrennten Entwicklungs-, Test- und Produktivumgebungen
Gemessen als Prozentsatz: Wie viele deiner Projekte haben eine vollständige Umgebungstrennung mit getrennten Zugriffsrechten und maskierten Testdaten? Ziel: 100%.
Ergänzende KPIs:
- Anzahl der direkten Produktionszugriffe durch Entwickler pro Monat (Ziel: 0)
- Anteil der Deployments über die automatisierte Pipeline (Ziel: 100%)
BSI IT-Grundschutz
- CON.8 (Software-Entwicklung) — Umgebungstrennung als Grundanforderung der sicheren Entwicklung.
- OPS.1.1.6 (Software-Tests und -Freigaben) — Testumgebungen getrennt von der Produktion, Freigabeprozess vor Produktivnahme.
Verwandte Kontrollen
- A.8.33 — Testinformationen: Schutz der in Testumgebungen verwendeten Daten.
- A.8.9 — Konfigurationsmanagement: Konsistente Konfiguration über alle Umgebungen.
- A.8.32 — Änderungsmanagement: Deployments als kontrollierte Änderungen.
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.8.31 — Trennung von Umgebungen
- ISO/IEC 27002:2022 Abschnitt 8.31 — Umsetzungshinweise
- BSI IT-Grundschutz, CON.8 — Software-Entwicklung