Sicherheits- und Zuverlässigkeitsprüfung: 7 Schwachstellen im Bereitstellungsmodell, die du zuerst überprüfen solltest

Warum dein Bereitstellungsmodell eine Frage der Sicherheit und Zuverlässigkeit ist

Das Wichtigste auf einen Blick: Sicherheitsaudits, die sich nur auf den Anwendungscode konzentrieren, übersehen oft die Bereitstellungsschicht gänzlich. Genau dort liegen die häufigsten und am leichtesten vermeidbaren Fehler.

Die meisten Teams betrachten Sicherheit als eine Ebene, die einem funktionierenden System zusätzlich aufgesetzt wird. Das Problem ist, dass das Bereitstellungsmodell selbst Risiken mit sich bringt, noch bevor auch nur eine einzige Zeile Anwendungscode ausgeführt wird.

Wenn Bereitstellungen manuell erfolgen, Umgebungen inkonsistent sind oder sich Konfigurationen über verschiedene Phasen hinweg verschieben, verhält sich das System unvorhersehbar. Diese Unvorhersehbarkeit macht Vorfälle schwerer zu erkennen und lässt sie sich leichter verschlimmern.

Die 7 Schwachstellen, die du zuerst prüfen solltest

1. Inkonsistente Umgebungen

Wenn lokale, Staging- und Produktivumgebungen unterschiedlich konfiguriert sind, testest du nicht das, was du ausliefert. Fehler, die nur in der Produktivumgebung auftreten, sind oft Umgebungsfehler, keine Codefehler.

Was du prüfen solltest: Kannst du eine neue Umgebung mit denselben Daten und derselben Konfiguration einrichten, die auch in der Produktivumgebung laufen?

2. Manuelle Bereitstellungsschritte

Jeder Schritt, bei dem ein Mensch einen Befehl ausführen muss, ist ein Schritt, der übersprungen, in der falschen Reihenfolge ausgeführt oder unter Druck vergessen werden kann. Der Unterschied zwischen Teams, die automatisieren, und solchen, die dies nicht tun, ist messbar: Laut der DORA-Studie von 2024 erholen sich Spitzenperformer 2.293-mal schneller von fehlgeschlagenen Bereitstellungen als Teams mit schlechterer Performance und weisen eine 8-mal niedrigere Fehlerquote bei Änderungen auf.

Was du prüfen solltest: Wie viele Bereitstellungsschritte unterliegen keiner Versionskontrolle? Wenn heute jemand Neues eine Bereitstellung durchführen müsste, was würde ihm in der Dokumentation fehlen?

3. Unklare Zuständigkeiten

Wenn niemand eindeutig für eine Umgebung oder eine Konfigurationsentscheidung verantwortlich ist, stapeln sich die Probleme. Zugriffsrechte bleiben bestehen, auch wenn Mitarbeiter das Unternehmen verlassen. Schulden werden aufgeschoben, bis sie zu einem Vorfall führen.

Was du prüfen solltest: Kannst du für jede Umgebung in deiner Bereitstellungspipeline die Person nennen, die für deren aktuellen Zustand verantwortlich ist?

4. Schwache Rollback-Möglichkeiten

Ein schneller Rollback ist sowohl ein Zuverlässigkeits- als auch ein Sicherheitsmechanismus. Wenn das Rückgängigmachen einer fehlerhaften Bereitstellung Stunden dauert oder eine manuelle Wiederherstellung des Zustands erfordert, vergrößert sich der Schadensumfang bei jedem Vorfall.

Was du prüfen solltest: Wie lange dauert ein Rollback in deiner aktuellen Konfiguration tatsächlich? Wurde er kürzlich getestet oder ist das nur Theorie?

5. Konfigurationsabweichungen

Konfigurationsabweichungen treten auf, wenn Umgebungen, die eigentlich übereinstimmen sollten, durch Ad-hoc-Änderungen allmählich voneinander abweichen – oft in einem Kontrollpanel, das niemand überprüft. Dies ist eine der am schwersten zu erkennenden Fehlerarten.

Was du prüfen solltest: Wird die Konfiguration deiner Infrastruktur ebenso wie der Anwendungscode versioniert?

6. Mangelhafte Zugriffskontrollmuster

Um der Bequemlichkeit willen erteilte weitreichende Berechtigungen werden selten wieder zurückgenommen. Mit der Zeit haben mehr Personen Produktionszugriff, als ihn benötigen. Das ist nicht nur wegen des operativen Risikos von Bedeutung: Der „Verizon 2024 Data Breach Investigations Report“ ergab, dass gestohlene Zugangsdaten in 31 % aller Sicherheitsvorfälle der letzten zehn Jahre eine Rolle spielten, was übermäßigen Zugriff zu einer der am häufigsten ausgenutzten Schwachstellen macht

Was du prüfen solltest: Wer hat derzeit Zugriff auf die Produktionsumgebung? Wird diese Liste regelmäßig überprüft? Sind die Berechtigungen auf das beschränkt, was die jeweilige Rolle erfordert?

7. Geringe Vorhersehbarkeit bei der Bereitstellung

Wenn Entwickler nicht sicher sind, dass eine Bereitstellung reibungslos verläuft, verzögern sie die Veröffentlichung. Größere Änderungssätze sind schwieriger zu prüfen und schwerer rückgängig zu machen. Das Risiko steigt.

Was du prüfen solltest: Was war der Grund für den letzten ungeplanten Deployment-Stopp? Wurde die zugrunde liegende Ursache behoben?

Schau dir an, wie ein Bereitstellungsmodell ohne diese Lücken aussieht

So sieht es gut aus

Das Wichtigste zum Mitnehmen: Eine gute Delivery-Praxis reduziert die Anzahl der Entscheidungen, bei denen ein Mensch jedes Mal alles richtig machen muss.

Ein Bereitstellungsmodell, das diese Aspekte gut handhabt, weist einige gemeinsame Merkmale auf:

• Die Konfiguration wird in der Versionskontrolle verwaltet, wodurch Infrastrukturentscheidungen überprüfbar und rückgängig machbar sind.
• Umgebungen werden aus derselben Quelle erstellt, sodass sich die Staging-Umgebung wie die Produktivumgebung verhält.
• Deployments werden über Git ausgelöst. Der Commit-Verlauf dient als Deployment-Protokoll.
• Der Zugriff ist begrenzt und nachverfolgbar, mit einem klar definierten Verantwortlichen pro Umgebung.

Upsun basiert auf diesen Prinzipien: Die Konfiguration befindet sich in YAML-Dateien, die in dein Repository committet werden, jeder Branch kann eine vollständig isolierte Umgebung erzeugen, und der Zugriff wird auf Umgebungsebene verwaltet. 

Kurze Fragen zur Selbstüberprüfung

Das Wichtigste zum Mitnehmen: Wenn die Beantwortung einer dieser Fragen länger als ein paar Minuten dauert, ist das an sich schon ein Befund.

Geh diese vor deinem nächsten Audit durch:

1. Wenn ein Teammitglied heute das Unternehmen verlassen würde, könnte dann jemand anderes allein mit den im Repository vorhandenen Informationen sicher einen Deployment durchführen?
2. Wann hast du das letzte Mal einen Rollback durchgängig getestet?
3. Kannst du eine aktuelle Liste aller Personen mit Produktionszugang erstellen und jeden Eintrag begründen?
4. Ist die Staging-Umgebung derzeit mit der Produktionskonfiguration synchronisiert?
5. Wie viele Deployment-Schritte erfordern ein direktes Eingreifen einer bestimmten Person?

Wie man erkennt, welche Lücken zuerst behoben werden müssen

Das Wichtigste zum Mitnehmen: Lücken, die unbemerkt bleiben, sind diejenigen, die sich zu schwerwiegenden Vorfällen summieren. Transparenz ist der erste Schritt.

Priorisiere anhand von zwei Faktoren:

• Wie oft wirkt sich diese Lücke auf dich aus? Schwache Rollback-Pfade sind wichtiger, wenn du häufig bereitstellst. Konfigurationsabweichungen spielen in langlebigen Umgebungen eine größere Rolle.
• Wie schwer ist es zu erkennen, wenn etwas schiefgeht? Schwachstellen, die unbemerkt zu Fehlern führen – wie unkontrollierte Zugriffsrechte oder Inkonsistenzen in der Umgebung – verdienen eine höhere Priorität als solche, die sofortige Fehler verursachen.

Beginne mit der Schwachstelle, die sowohl häufig auftritt als auch schwer zu erkennen ist.

Bist du bereit, dein Bereitstellungsmodell gemeinsam mit dem Upsun-Team zu überprüfen? Buche eine Zuverlässigkeitsprüfung

Mehr erfahren

• https://upsun.com/blog/dora-exit-strategy-for-financial-services/
• https://upsun.com/blog/git-driven-environments-infrastructure-as-code/
• https://upsun.com/blog/developer-guide-to-building-apps-without-infrastructure-burden/
• https://upsun.com/blog/unified-cloud-management-platform/

Häufig gestellte Fragen (FAQ)

Ist das relevant, wenn wir bereits ein Sicherheitsteam haben, das Audits durchführt? 

Ja, und es ist eher eine Ergänzung als eine Doppelung. Die meisten Sicherheitsaudits konzentrieren sich auf Anwendungscode, Netzwerkkonfiguration und Zugriffsrichtlinien. Die Bereitstellungsschicht (Konsistenz der Umgebung, Bereitstellungsprozess, Konfigurationsmanagement) fällt häufig nicht in den Umfang eines Standardaudits und ist der Bereich, in dem sich zwischen den Auditzyklen strukturelle Lücken ansammeln.

Wie priorisieren wir die Behebung dieser Probleme, wenn wir nur begrenzte Kapazitäten im Bereich Platform Engineering haben? 

Fang mit den Lücken an, die sowohl häufig vorkommen als auch unbemerkt bleiben. Konfigurationsabweichungen und unklare Zuständigkeiten verursachen die höchsten Folgekosten, da sie schwer zu erkennen sind, bis sie sich summieren. Beides lässt sich teilweise beheben, indem man die Infrastrukturdefinitionen in die Versionskontrolle überführt – dafür braucht man kein eigenes Plattformteam, sondern lediglich eine Änderung in der Art und Weise, wie die Konfiguration verwaltet wird.

In welchem Zusammenhang stehen diese Schwachstellen mit Compliance-Rahmenwerken wie SOC 2 oder ISO 27001? 

Mehrere der sieben Schwachstellen lassen sich direkt mit Kontrollen in beiden Rahmenwerken in Verbindung bringen: Zugriffskontrollmuster, Konfigurationsmanagement und Aufzeichnungen über Bereitstellungsänderungen sind in den meisten Compliance-Rahmenwerken ausdrückliche Anforderungen. Das Schließen dieser Lücken in der Bereitstellungsschicht reduziert nicht nur das operative Risiko; es liefert auch die Prüfungsnachweise, die diese Rahmenwerke erfordern – und zwar als Nebenprodukt des normalen Betriebs und nicht als manuelle Erfassungsmaßnahme.

Wie oft sollten wir diese Überprüfung durchführen? 

Mindestens vor einer größeren Veröffentlichung, vor einem Audit und nach jeder wesentlichen Veränderung im Team (Neueinstellungen, Abgänge oder Umstrukturierungen). In der Praxis integrieren Teams mit solider Lieferhygiene einige dieser Überprüfungen in ihren regulären Sprint-Zyklus, damit sich zwischen den Überprüfungen keine Lücken ansammeln.