Compliance in hybriden Betriebsumgebungen

Anja Kammer

Es ist kein Geheimnis, dass die drei größten Cloud-Anbieter allesamt ihren Sitz in den USA haben, was aufgrund des US-Cloud-Acts die Verarbeitung und Speicherung sensibler und personenbezogener Daten nahezu unmöglich erscheinen lässt [1]. Im Zuge einer Cloud-Migration verbleibt daher oft ein Teil des Systems im unternehmenseigenen On-Premises-Rechenzentrum, um bestimmte Compliance-Anforderungen für Datenschutz und Informationssicherheit zu erfüllen. Ein weiteres Kriterium dafür, dass Applikationen weiterhin mit eigener Infrastruktur betrieben werden, ist die Inkompatibilität mit dem Cloud-Native-Paradigma. Um einen hohen Migrationsaufwand oder sogar einen Rewrite zu vermeiden, bleiben Legacy-Systeme daher oft im eigenen On-Premises-Rechenzentrum. Weniger kritische und neu entwickelte Systeme finden ihren natürlichen Weg in die Public oder Private Cloud.

Doch je diversifizierter und verteilter das System ist, desto komplexer wird die Durchsetzung von Compliance über sämtliche Systeme und Plattformen hinweg. Auch mit dem Wachstum der IT-Organisation steigen die Herausforderungen, Compliance systemübergreifend effektiv sicherzustellen.

Typische Herausforderungen in hybriden Betriebsumgebungen

In einer historisch gewachsenen IT-Organisation mit hybriden Betriebsumgebungen begegnen uns häufig folgende Stolpersteine:

• Abstimmung von Compliance-Maßnahmen quer durch die IT-Organisation, die sich oft in verschiedene Teams und Produkte gliedert.
• Umsetzung und Überwachung von bereits geltenden und zukünftigen Compliance-Vorgaben, welche sich über verschiedene Betriebsplattformen und Software-Domänen erstreckt.
• Sicherstellung von Datenintegrität und -sicherheit bei Transfer zwischen unterschiedlichen Betriebsumgebungen.
• Fortlaufende Verwaltung von z.T. komplexen Zugriffsberechtigungen in einem sich stets erweiternden Netz an Nutzenden und Systemkomponenten.

In der Architekturberatung und bei Architekturreviews kristallisiert sich häufig heraus: Nicht die eingesetzte Technologie oder die Codequalität sind die drängendsten Probleme, sondern unpassende Prozesse und organisatorische Barrieren. Dies zeigt sich insbesondere in der Divergenz zwischen den Abteilungen.

Bei der natürlichen Entwicklung einer IT-Organisation auf dem Weg in die Cloud entstehen häufig zwei getrennte Organisationseinheiten, eine, die für die Legacy-Software und -Infrastruktur verantwortlich ist, und andererseits die Einheit, die für die moderneren Systeme in der Cloud zuständig sind. Der Austausch zwischen diesen Bereichen bleibt aufgrund der angenommenen tiefgreifenden Unterschiede meist unnötig eingeschränkt. Das Ergebnis ist eine fragmentierte IT-Landschaft, in der Synergien ungenutzt bleiben und wertvolles Erfahrungswissen nur selten geteilt wird.

Vorwiegend kleinere Unternehmen verfallen oft der trügerischen Annahme, dass Compliance-Verstöße ein Problem der „großen Fische“ seien. Der Glaube an das Prinzip „Es wird schon nichts schiefgehen“ ist nicht nur naiv, sondern auch klar fahrlässig. Auch kleinere Unternehmen fliegen nicht unter dem Radar, da allein die DSGVO viele Softwareprodukte für Endanwender:innen betrifft. Fahrlässiges Ignorieren von Datenschutzlücken kann nicht nur die Privatsphäre dieser Endanwender:innen gefährden, sondern neben den bekanntlich empfindlichen Geldstrafen auch das Ansehen des Unternehmens und deren Verantwortlichen gefährden. Dies gilt insbesondere dann, wenn es bereits wiederholt zu Verstößen gekommen ist oder vorangegangene Evaluationen wie Penetrationstests und Security Reviews deutlich auf Schwachstellen hingewiesen haben oder diese erst gar nicht durchgeführt wurden.

Die Erkenntnis, dass Wegschauen keine Option darstellt, sollte dazu führen, dass es Architekt:innen und Entwickler:innen ermöglicht wird, sich kontinuierlich über moderne Technologien und bewährte Standardverfahren zu informieren – denn Vorgaben wie die der DSGVO fordern Datenschutz nach dem “Stand der Technik”. Es existieren zwar regelmäßig aktualisierte Hilfestellungen zur Definition dieses Begriffs [2] und konkrete Handlungsempfehlungen, doch es bleibt eine verbindliche Gewissheit aus. Dieses Problem setzt sich auch in der Zusammenarbeit mit Auditor:innen fort, die Unternehmen üblicherweise nicht bei der detaillierten Implementierung dieser technischen Maßnahmen unterstützen. Sie konzentrieren sich stattdessen vielmehr auf eine Überprüfung der dokumentierten Verfahren als auf die tatsächliche Realisierung. Häufig wird auch unterschätzt, dass die Berücksichtigung von Compliance-Anforderungen bereits beim Architekturdesign erfolgen muss. Die Illusion, Compliance sei ein Anhängsel, das man später nachrüsten kann, ist irreführend. Ein zielgerichtetes Design unter Berücksichtigung, z. B. von Datenschutz und Informationssicherheit, von Anbeginn ist entscheidend, um spätere kostspielige Redesigns zu vermeiden.

Gerade unter Unternehmen weniger-regulierte Branchen herrscht oft ein lückenhaftes Verständnis für die kritischen und schützenswerten Aspekte des eigenen Systems. Am Beispiel der DSGVO-Konformität stellt das Recht auf Löschung (Recht auf Vergessenwerden) von personenbezogenen Daten, allerdings hohe Anforderungen an die Nachverfolgbarkeit von Datenströmen.

Ein typisches Beispiel ist eine Stammdatenanwendung für Kund:innen, die sowohl in einer Cloud als auch On-Premises betrieben wird. Wenn diese Anwendung personenbezogene Daten speichert, dann muss sie in der Lage sein, auf Anfrage einer Kund:in alle betroffenen Daten zu identifizieren und irreversibel löschen zu können. Wenn personenbezogene Daten verteilt in verschiedenen Datenbanken, Caches, Backups und Messaging Brokern gespeichert werden, kann eine vollständige Löschung durch manuelles Eingreifen, nicht gewährleistet werden.

Ein weiteres Problem könnte in der Interoperabilität der verschiedenen Systemkomponenten liegen, wenn Daten durch mehrere Schichten und Dienste fließen und schließlich durch Services wie SaaS-Angebote persistiert werden, die schwer zu überwachen sind. Durch ein Architekturdesign, das von Anfang an die datenschutzrechtlichen Anforderungen berücksichtigt, können derartige Datenflüsse sinnvoll gelenkt und überwacht werden.

Darüber hinaus führt eine genaue Kenntnis, sowohl hinsichtlich der Kritikalität der verarbeiteten Daten als auch der davon abhängigen Dienste und Schnittstellen dazu, dass eine Entscheidungsgrundlage dafür geschaffen wird, welche Teile des Systems in eine Public Cloud, bspw. unter US-amerikanischer Kontrolle, ausgelagert werden können. Entscheidend ist aber auch eine Bewertung des Aufwands einer Cloud-Migration. Nicht ohne Grund werden viele Legacy-Systeme, trotz geringer Kritikalität, in On-Premises-Betriebsumgebungen belassen. Der Aufwand lohnt sich schlicht einfach nicht, trotz attraktiver Vorteile, die ein Cloud-Betrieb bringen würde.

Wirksame Maßnahmen

Neben der üblichen Praxis zur Sicherstellung von Compliance in Unternehmen zählen unserer Erfahrung nach besonders die Schaffung unterstützender Teamstrukturen und die Anpassung der Software-Delivery und Betriebsprozesse zu den wirksamsten Maßnahmen. Dazu zählen:

• Einrichtung einer föderalen Compliance-Gruppe
• Einsehbarkeit globaler Richtlinien sowie automatisierte Durchsetzung
• Standardisierte Software-Delivery-Pipelines und Vorlagen für alle Betriebsumgebungen
• Automatisierte Self-Service Schnittstellen für den hybriden Betrieb mit Pioneer-Teams

Im Folgenden wird auf diese Punkte näher eingegangen.

Föderale Compliance-Gruppe

Neben zentral gesteuerten Vorgaben werden auch von anderen Stakeholder:innen, wie Sicherheitsexpert:innen und Architekt:innen, speziellere Anforderungen an die Entwicklungsteams herangetragen. Diese sind teilweise nicht konkret formuliert oder es fehlt eine direkte Ansprechperson für Rückfragen. Stattdessen wird die Definition solcher Anforderungen in kleinen Kreisen diskutiert, während Entwicklungsteams nicht direkt involviert sind. Wären Entwicklungsteams hier stärker eingebunden, würde ihre wertvolle fachliche und technische Kompetenz in die Festlegung von Anforderungen einfließen, was letztlich zu praxisnahen und umsetzbaren Vorgaben führen würde.

Bleiben Anforderungen unklar und schwammig, werden sie unweigerlich von den Entwicklungsteams unterschiedlich interpretiert und umgesetzt werden. Dabei kommt erschwerend hinzu, dass in einem hybriden Setup üblicherweise getrennte Abteilungen für die Entwicklung On-Premises und für die Cloud existieren, was sich negativ auf die Koordination und Wissensverteilung auswirkt. Daher ist es wichtig, die Kommunikation und Zusammenarbeit zwischen der Fachabteilung, Rechtsabteilung, Entscheidungstragenden und den Entwicklungsteams zu verbessern.

Der Data Mesh Ansatz adressiert solche Herausforderungen. Dabei handelt es sich nicht um eine neue Technologie, sondern um einen dezentralen sozio-technischen Ansatz für Datenmanagement, bei dem Komplexitätsprobleme durch klare Teamverantwortlichkeiten und Schnittstellen gelöst werden. Dieses Prinzip lässt sich auch auf IT-Organisationen anwenden, die keinen besonderen Fokus auf Datenmanagement legen.

Beim Data Mesh Ansatz hat sich unter anderem die Bildung einer föderalen Governance-Gruppe in Form einer Community oder Gilde bewährt, die aus Vertretenden der Entwicklungsteams, der Fachabteilung und der Plattform-Teams besteht. Diese Gruppe koordiniert regelmäßige Treffen und richtet Kommunikationskanäle ein, in denen alle Beteiligten Fragen stellen und Bedenken äußern können. Bei der Einrichtung einer äquivalenten Gruppe für Compliance-Bedürfnisse würde diese dann von Compliance-Fachexpert:innen bzw. der Rechtsabteilung und anderen Stakeholder:innen unterstützt werden. Eine solche Community würde eine nötige Brücke zwischen Compliance, Architektur und Entwicklung schlagen, sodass diese sich auf konkrete Architekturentscheidungen, Good Practices und globale Richtlinien einigen können (Abbildung 1). Zur effektiveren Durchsetzbarkeit von globalen Richtlinien (Global Policies) wird beim Data Mesh ein automatisiertes Policy Management und Monitoring empfohlen [3].

Automatisiertes Policy-Management

Die besondere Herausforderung in hybriden Betriebsumgebungen besteht darin, dass Compliance-Anforderungen für jede Plattform und jeden Standort, mit möglicherweise unterschiedlicher Rechtslage, erfüllt werden müssen. Dies erhöht den Koordinationsaufwand und erschwert die Etablierung, Überwachung und Durchsetzung von Compliance-Richtlinien.

Häufig werden zur Kommunikation mit den Umsetzungsteams Beschreibungen der Compliance-Anforderungen in Wikis und Anforderungsdokumenten geteilt. In Readmes, Konfigurationsdateien und Code verbergen sich dann die eigentlichen Umsetzungen oder sogar weitere Vorgaben, die sonst nirgendwo dokumentiert sind oder eine Folge der Umsetzung nach dem “Stand der Technik” darstellen.

Nach dem Data Mesh-Ansatz wird empfohlen, zentral verwaltete, maschinenlesbare Richtlinienbeschreibungen (Policy as Code) bereitzustellen, die automatisiert zur Validierung und Durchsetzung (Automated Policy Enforcement) verwendet werden können.

Eine kaum zu vermeidende Herausforderung besteht darin, dass Policies as Code zwangsläufig bestehende Compliance-Beschreibungen nachbilden müssen, da von nicht-technischen Abteilungen realistischerweise nicht erwartet werden kann, dass sie ihre Anforderungen in maschinenlesbaren Formaten und Sprachen formulieren. Eine Vermittlung der Vorteile kann dennoch helfen, gegenseitiges Verständnis zu fördern. Dennoch ergeben sich Vorteile aus der Behandlung von Policies als Code, da bekannte Prinzipien der Softwareentwicklung genutzt werden. Policies sind so testbar und versionierbar mit den für Code üblichen Mitteln. Policies stellen im Wesentlichen Konfigurationen für eine Policy Engine dar, die die Auswertung von Regeln (Policy Evaluation) übernimmt.

Im Hinblick auf hybride Betriebsumgebungen sollte jedoch darauf geachtet werden, sich auf eine Technologie zur Beschreibung und Auswertung von Policies zu beschränken, die von allen Betriebsumgebungen unterstützt wird. Dies hat nicht nur den Vorteil, dass Redundanzen vermieden werden, sondern auch, dass eine spätere Migration von Systemkomponenten in eine andere Betriebsumgebung, wie eine Cloud, einfacher zu realisieren ist.

Ein etabliertes Tool ist die Open-Source-Software Open Policy Agent(OPA). Anders, als aktuelle Artikel und Vorträge zu diesem Tool vermuten lassen, kann es nicht nur in Cloud-Umgebungen wie Kubernetes eingesetzt werden. Zweifellos gibt es mächtigere Policy Engines, diese sind aber oft stark an eine bestimmte Betriebsumgebung gebunden und daher für einen einheitlichen Standard im hybriden Betrieb weniger geeignet. Der Open Policy Agent hingegen kann als zentraler Service, nebenläufiger Prozess oder Bibliothek in die Systemlandschaft integriert werden und stellt damit eine flexible Möglichkeit zur dezentralen Auswertung von Policies unabhängig von der eingesetzten Betriebsumgebung dar. Realistischerweise kann es aber auch notwendig sein, für spezielle Policies, z. B. für die Inter-Service-Kommunikation, weitere Werkzeuge einzusetzen.

Im operativen Einsatz lassen sich verschiedene Policies definieren, zum Beispiel:

• Netzwerk Policies: Vergleichbar mit verteilten Firewall-Regeln steuern sie den Verkehrsfluss zwischen Services auf Basis von Metadaten und Topologie.
• Limitierung erlaubter Container-Image Quellen: Diese Richtlinien bestimmen, welche Base-Images und Container Registries zugelassen sind, um nur geprüfte Images zur Verwendung freizugeben. (siehe Code Listing 1)
• Validierung von Metadaten: Vor dem Deployment werden verpflichtende Metadaten überprüft, wie die Systemkritikalität und Datenklassifizierung (Data Privacy Level). Auf dieser Grundlage kann entschieden werden, ob ein Deployment in eine bestimmte Betriebsumgebung zulässig ist, die ggf. spezifische Anforderungen wie Latenzen, Lizenzen oder Zertifizierungen erfordert.
• Verbot privilegierter Container-Rechte: Um das Risiko von Sicherheitslücken zu reduzieren, verhindern Richtlinien, dass Container mit zu weitreichenden Berechtigungen betrieben werden können.
• Ressourcen-Limitierung: Sie dienen der Limitierung des Zugriffs auf Ressourcen und vermeiden eine solche missbräuchliche Nutzung.

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  satisfied := [good | repo = input.parameters.repos[_] ; good = startswith(container.image, repo)]
  not any(satisfied)
  msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])
}

Code Listing 1: Open Policy Agent Gatekeeper - Constraint Template für erlaubte Container Registry. Quelle: Open Policy Agent Gatekeeper Library

Policy Engines können aber auch außerhalb des Betriebskontexts eingesetzt werden. Richtlinien zu Konfigurationen oder zur Struktur einer Systemdokumentation können so frühzeitig im Entwicklungsprozess validiert werden [4]. Es ist lediglich nötig, dass ein Prozess automatisierte Prüfungen ausführt. Das kann leicht in einer Pipeline realisiert werden, die globale Richtlinien aus einer zentralen OCI-Registry oder einem Object Store bezieht. Um die Vertrauenswürdigkeit der bezogenen Policies zu gewährleisten, wird Signing und Versioning eingesetzt.

Einheitliche Software-Delivery-Prozesse

Neben der Verwendung zentraler Policies für den Betrieb und der automatisierten Auswertung in Code und Dokumentations-Pipelines ist die Verwendung einer einheitlichen Software-Delivery-Pipeline für alle Betriebsumgebungen eines hybriden Setups eine bewährte Strategie. In Software-Delivery-Pipelines findet oft ein großer Teil der notwendigen Qualitäts-, Sicherheits- und Supply-Chain-Analyseprozesse statt. Eine Vereinheitlichung der Software-Delivery-Pipeline bedeutet aber auch, dass es unterstützende Teamstrukturen, wie ein Plattform-Team, braucht, das eine einheitliche Software-Delivery-Pipeline-Beschreibung pflegt und weiterentwickelt.

Die Entscheidung, die Software-Delivery-Pipeline nicht zentral zu entwickeln und auch nicht zwingend vorzuschreiben, ist sinnvoll, um den Entwicklungsteams mehr Freiheit bei der Implementierung zu geben. Es hat sich jedoch gezeigt, dass teameigene Pipelines zwar tendenziell besser an die Team-Prozesse angepasst sind, aber häufig veraltete Softwareversionen und Policies enthalten. Organisationen mit hohen Compliance-Anforderungen sind daher besser beraten, eine konsolidierte und zentral verwaltete Software-Delivery-Pipeline als Dienstleistung für Entwicklungsteams anzubieten. Diese Dienstleistung kann die Bereitstellung der erforderlichen Infrastruktur und die Verwaltung von Vorlagen für verschiedene Arten von Anwendungen umfassen. Mit den Entwicklungsteams als Kund:innen im Fokus steigt die Wahrscheinlichkeit der Akzeptanz und einer stetigen Weiterentwicklung der Pipeline an deren Bedürfnisse.

Plattform-Engineering als Dienstleistung

Ein häufiger Schmerzpunkt für Entwicklungsteams in regulierten Branchen scheint die Bereitstellungsfähigkeit zu sein. Nicht jede dieser Organisationen möchte sofort einen kontinuierlichen Deployment-Workflow einführen, bei dem für jede noch so kleine Code-Änderung ein Produktions-Deployment ausgelöst wird. Dennoch ist eine eigenständige Deploymentfähigkeit nach einer Freigabe für schnelle Feedbackzyklen essenziell. Sei es Feedback von Kund:innen für neue Features und Fixes oder schlicht das Feedback vom System, dass ein Deployment wegen falscher Konfiguration fehlgeschlagen ist. Je kleiner und häufiger Deployments sind, desto einfacher ist die Fehlersuche.

Häufig gibt es jedoch Deployment-Prozesse für die Produktionsumgebung, bei denen das Deployment und der Betrieb zwingend von einem separaten Betriebsteam durchgeführt werden müssen. Dem Entwicklungsteam ist es daher nicht gestattet, in der Produktionsumgebung zu deployen oder ihre eigenen Services zu betreiben. Die Schmerzen, die solche Übergaben erzeugen, sind bereits allgemein bekannt, werden allerdings hingenommen, mit der Begründung, es hätte Compliance-Gründe und würde nicht anders umgesetzt werden können. (Beispiel: Funktionstrennung zwischen unvereinbaren Aufgaben aus dem IT-Grundschutz-Baustein ORP.1.A4)

Dahinter steckt die Strategie, dass die strengere Kontrolle und Trennung von Verantwortlichkeiten zwischen Entwicklungs- und Betriebsteams die Risiken für die Produktionsumgebung minimiert. Diese strikte Trennung ist jedoch nur eine einfache Lösung für das Problem der Risikominimierung aus Angst, bei einem Auditing des Betriebskonzepts als nicht konform eingestuft zu werden. Der entscheidende Punkt ist jedoch nicht, eine möglichst restriktive Auslegung der bestehenden Vorschriften zu implementieren, um “auf der sicheren Seite zu sein”. Unternehmen tun sich einen großen Gefallen damit, eine risikoorientierte Vorgehensweise an dieser Stelle vorzuziehen. Maßnahmen sollten mit den unternehmerischen Zielen in Einklang gebracht werden. Auf diese Weise entstehen Maßnahmen, die für den jeweiligen Kontext angemessen sind und nicht durch ein maximales Sicherheitsbedürfnis getrieben werden.

Mögliche Unternehmensziele in diesem Kontext:

• Schnelle Time-to-Market durch effiziente Software-Delivery-Prozesse
• Vereinfachtes Hiring und flexiblere Einsetzbarkeit von Mitarbeitenden durch weniger erforderliches Spezialwissen
• Höhere Mitarbeitendenzufriedenheit durch geringe Wartezeiten und wenige Blockaden

Mit der Schaffung einer echten Self-Service-Betriebsplattform, werden Entwicklungsteams dazu befähigt, den Betrieb ihrer eigenen Services zu übernehmen, ohne jedoch umfassende Zugriffsrechte auf die Produktionsumgebung zu erhalten. Sogar die Unterscheidung der zugrundeliegenden Betriebsumgebung kann so weit abstrahiert werden, dass lediglich ein Tag in den Metadaten eines Deployment Manifests einen Indikator darstellt und die eigentliche Betriebsumgebung vor den Entwicklungsteams vollständig verborgen bleibt.

Beispiel Heroku als Self-Service Plattform

Heroku ist das Paradebeispiel einer hochabstrahierten Applikation-Plattform, auf deren zugrundeliegende Infrastruktur Nutzende nicht zugreifen können. Diese Plattform bietet Deployments von Anwendungen, die Nutzung verschiedener Persistenz-Produkte, umfassendes Monitoring und viele andere komplementäre Dienste an, die einfach zu nutzen sind. Klar ist, dass nicht jedes Unternehmen die Ressourcen hat einen Heroku-Clon aufzubauen. Die Investition in eine abstraktere Plattform kann sich dennoch lohnen, um sich von angstgetriebenen Fesseln zu befreien, die die Softwareentwicklung in stark regulierten Branchen so anstrengend machen. Dabei ist auch zu evaluieren, ob viele Funktionalitäten, z. B. für das Policy Enforcement, bereits durch vorhandenes Tooling abgedeckt werden können.

Eine hochabstrahierte Self-Service-Plattform hat entscheidende Vorteile:

• Bereitstellung einer einheitlichen, dezentralen und automatisierten Durchsetzung und Überwachung von angewendeten Policies
• Compliance “by design” für querschnittliche Dienste wie Logging und Zugriffskontrolle als vorbeugendes und unterstützendes Kontrollsystem
• Self-Service Betrieb durch die Entwicklungsteams führt zu schneller Reaktionsfähigkeit bei Incidents und fördert nebenbei Ownership.

Der erste Schritt auf dem Weg zu einer Self-Service-Plattform ist die Einrichtung einer Organisationseinheit für Plattform-Engineering. Diese neue Abteilung unterscheidet sich von einer Betriebsabteilung, weil eine Self-Service-Plattform als Dienstleistung entwickelt wird. Es sollte als internes Produkt angesehen werden, dessen Anwender:innen zumindest die Entwicklungsteams sind [5]. Diese Plattform kann in den ersten Phasen der Einführung von den Entwicklungsteams auf freiwilliger Basis genutzt werden, könnte aber das Ziel haben, zum Regelverfahren für den Betrieb zu werden. Es wird nicht ausreichen, die Betriebsabteilung umzubenennen, denn der übliche Weg, weiterhin ein Ticket-basiertes Bestellprinzip zu pflegen, wird bestehen bleiben, mit der Perspektive, immer mehr Betriebsaktivitäten über die Self-Service-Plattform an die Entwicklungsteams zu delegieren.

Pioneer-Teams

Es hat sich als gute Strategie erwiesen, eine Self-Service-Plattform mit einem oder wenigen Pioneer-Teams zu starten, um eine benutzungszentrierte Entwicklung zu verfolgen. Es gelten also auch hier ähnliche Prinzipien wie für die übliche Produktentwicklung. Diese Pioneer-Teams sind Entwicklungsteams, die ihre Anwendungen, vor der generellen Verfügbarkeit der neuen Betriebsplattform, migrieren werden.

Die Zusammenarbeit zwischen dem Pioneer-Team und dem Plattform-Team ist auf eine enge Kooperation ausgerichtet. Im Vordergrund steht eine Produktentwicklung, die sich durch einen direkten und kontinuierlichen Austausch mit den Anwender:innen, also dem Pioneer-Team, auszeichnet. Dies führt zu einem praxisnahen Feedback und sichert die Ausrichtung der Plattformentwicklung an realen Anforderungen.

Ziel ist es nicht, eine möglichst vollständige Plattform am Beispiel von Heroku zu schaffen, sondern gezielt und bedarfsgerecht die Funktionen zu priorisieren, die den Entwicklungsteams den größten Nutzen bringen. Konkret bedeutet dies, dass die Entwicklung mit Kernfunktionen beginnt, die akute Probleme lösen – wie z. B. die selbstständige Konfiguration von Firewall-Regeln. Diese Funktionalität kann durch Mechanismen wie Pull-Requests und anschließende Code-Reviews durch das Plattform-Team implementiert werden oder durch anwendungsfreundliche Schnittstellen wie grafische Bedienoberflächen, die im Hintergrund automatisierte Validierungen auf Basis globaler Policies ermöglichen.

Ein besonderer Aspekt der Plattformentwicklung mit einem Pioneer-Team ist die Unterstützung des Pioneer-Teams während des Migrationsprozesses. Hier steht die Förderung der Selbstständigkeit im Umgang mit der neuen Plattform im Vordergrund – eine zentrale Voraussetzung für die spätere effektive Eigenverantwortung. Ein wichtiges Nebenprodukt sollte eine konzentrierte und leicht zugängliche Produktdokumentation sein, um ein eigenständiges Onboarding durch das Pioneer-Team und nachfolgende Entwicklungsteams zu ermöglichen. Detaillierte Beschreibungen der Plattformarchitektur sollten explizit nicht für die Nutzung erforderlich sein. Diese gehören in die Architekturdokumentation für das Plattform-Team.

Spätestens nach der erfolgreichen Migration der Services des Pioneer-Teams sollten die der Plattformentwicklung zugrunde liegenden Annahmen evaluiert werden. Dabei werden Aspekte wie die Verbesserung der Durchlaufzeiten von Features, die Vereinfachung von Debugging und Fehlerbehebung sowie die Effektivität der Policy-Durchsetzung gemessen. Eine regelmäßige Überprüfung dieser Kennzahlen zeigt den Fortschritt in Bezug auf die zugrundeliegenden Unternehmensziele. Diese Bewertung muss nicht vollständig automatisiert erfolgen. In der Praxis hat sich eine quartalsweise Evaluierung durch Value Stream Mapping Sessions, Befragungen und manuelle Übertragung von Kennzahlen aus Ticketsystemen und CI-Servern als ausreichend erwiesen.

Pioneer-Teams erfüllen auch eine entscheidende Rolle im Prozess der Etablierung neuer Plattformen, denn sie können zu mehr Glaubwürdigkeit, Transparenz und Vertrauensbildung beitragen. Ihre Erfahrungen und Meinungen haben besonderes Gewicht bei anderen Entwicklungsteams innerhalb der Organisation. Durch das Teilen ihrer Erfahrungen mit der Plattform, beispielsweise bei internen Konferenzen, werden sie indirekt zu Botschaftern für die Plattformnutzung, indem sie von deren Vorteilen als auch ihren Herausforderungen berichten. Eine Plattform-Engineering-Abteilung fungiert weiterhin als Kontrollinstanz für die Infrastruktur, wie es zuvor eine Betriebsabteilung war. Sie sorgt dafür, dass verbindliche Regeln automatisiert durchgesetzt und Vorgaben im Betrieb umgesetzt werden. Trotz des Strebens nach Autonomie der Entwicklungsteams bleibt die zugrundeliegende Infrastruktur ein wesentliches Rückgrat, indem sie die notwendige Infrastruktur wie Policy Engines bereitstellt (siehe: Governance through Infrastructure von Gregor Hohpe [6]). Die Vorteile der Verteilung von Verantwortlichkeiten auf Entwicklungsteams, die in ihrem eigenen Einflussbereich domänenspezifische Anforderungen erheben und entsprechende Policies in einer föderalen Compliance-Gruppe erarbeiten, bleiben davon unberührt.

Fazit

Compliance ist kein bürokratischer Selbstzweck. Rechtliche Vorgaben, wie die der DSGVO, dienen primär dem Schutz der Endanwender:innen. Schäden an der Unternehmensreputation, Geldbußen und die persönliche Haftung von Entscheidungsträger:innen sind unmittelbare Risiken, die betrachtet werden sollten. Um diesen Herausforderungen wirksam zu begegnen, wurden im Rahmen dieses Artikels verschiedene technische und organisatorische Maßnahmen und Konzepte vorgestellt, die dazu beitragen, Compliance-Anforderungen in hybriden Betriebsumgebungen gerecht zu werden:

• Die Gründung einer föderalen Compliance-Gruppe, die Expertise bündelt, gleichzeitig Wissen verteilt und bereichsübergreifende Kooperation fördert.
• Die Transparentmachung globaler Richtlinien, gepaart mit deren automatisierter Durchsetzung
• Die Entwicklung standardisierter Software-Delivery-Pipelines und Templates, als unterstützendes und überwachendes Mittel
• Die Bereitstellung von automatisierten Self-Service-Angeboten für den Betrieb und der zentralen Steuerung und Validierung von Richtlinien
• Einsetzen von Pioneer-Teams zur bedarfsgerechten Umsetzung von zentral gesteuerten Maßnahmen