IT-Security in der Anwendungsbereitstellung Warum Unternehmen ihre Application Delivery neu denken müssen

398, 200, 100, 47 Tage: Die Gültigkeitsdauer von SSL-Zertifikaten sinkt stetig. Wer sie immer noch manuell verwaltet, riskiert spätestens ab 2029 Ausfälle. Jürgen Mang, Senior IT Security Consultant bei Axians IT Security, zeigt, wie Automatisierung hilft.

Was auf den ersten Blick wie ein reines PKI- oder Security-Detail wirkt, ist in Wahrheit ein Thema der Anwendungsbereitstellung: Denn Zertifikate hängen dort, wo Anwendungen Nutzern verfügbar gemacht werden. Wenn diese künftig alle paar Wochen erneuert werden müssen, wird aus einem Sicherheitsartefakt ein regelmäßiger Produktions-Change und damit ein Stresstest für genau die Plattformen und Prozesse, die Anwendungen bereitstellen.

Das CA/Browser Forum – das internationale Gremium, in dem Browser-Hersteller wie Google, Apple und Microsoft gemeinsam Standards für digitale Zertifikate festlegen – hat beschlossen, die maximale Gültigkeitsdauer von SSL/TLS-Zertifikaten schrittweise drastisch zu senken.

Konkret bedeutet das: Seit dem 15. März 2026 gilt eine maximale Laufzeit von 200 Tagen – zuvor waren es noch 398. Ab März 2027 sinkt die Grenze auf 100 Tage, ab März 2029 auf nur noch 47 Tage. Wer heute 200 oder 300 Zertifikate manuell verwaltet, tauscht diese ab 2029 alle sieben Wochen aus – von Hand, für jedes einzelne System. Das ist schlicht nicht mehr beherrschbar. Und ein Fehler hat unmittelbare Konsequenzen: Läuft ein Zertifikat ab oder wird fehlerhaft ausgetauscht, ist die betroffene Anwendung nicht mehr erreichbar. Für eine Bank, eine Versicherung oder einen Krankenversicherungsdienstleister bedeutet das: Dienste stehen still, Kunden können nicht zugreifen, Verträge können nicht abgeschlossen werden.

Die Zertifikatsfrage ist kein Nebenschauplatz, sondern ein Frühindikator: Sie zeigt, ob die Anwendungsbereitstellung bereits so standardisiert und automatisiert ist, dass häufige, sicherheitskritische Änderungen sauber getestet, ausgerollt und nachvollziehbar dokumentiert werden können.

Herausforderungen in der Anwendungsbereitstellung

Die meisten Unternehmen verwalten ihre Anwendungsinfrastruktur noch wie ein kleiner Handwerksbetrieb seine Rechnungen – in Handarbeit, ohne Nachvollziehbarkeit, ohne Sicherheitsnetz. Was in der Buchhaltung seit Jahren undenkbar wäre, ist im Betrieb kritischer Plattformen zur Anwendungsbereitstellung noch immer Alltag: Administratoren klicken sich durch grafische Oberflächen, Konfigurationen existieren nur im System selbst. Dadurch fehlen Versionierung, Nachvollziehbarkeit für Audits und eine zuverlässige Reproduzierbarkeit.

Dabei geht es hier nicht um Randthemen der IT. Wer heute seine Krankenkassen-App öffnet, ein Rezept digital einlöst oder über ein Versicherungsportal eine Police abschließt, ist auf diese Infrastruktur angewiesen. Zwischen dem Endanwender und der eigentlichen Anwendung steht eine Plattform, die Angriffe abwehrt, Last auf mehrere Server verteilt, Authentifizierung regelt und den Datenverkehr intelligent steuert. Diese Plattformen – Application Delivery Controller – sind das unsichtbare Rückgrat moderner digitaler Dienste. Sie schützen nicht das Netzwerk, wie es eine klassische Firewall tut. Sie schützen die Anwendung selbst – auf einer Ebene, auf der SQL-Injection-Angriffe, DDoS-Attacken und kompromittierte Authentifizierungsprotokolle wirksam werden.

Lego ohne Bauanleitung

Was diese Infrastruktur so komplex macht, ist nicht die Technologie allein. Application Delivery Controller sind mächtige Werkzeuge. Sie kommen jedoch ohne Meinung darüber, wie sie konfiguriert werden sollen. Sie bieten Schnittstellen, APIs und nahezu unbegrenzte Flexibilität. Was sie nicht liefern: einen standardisierten, automatisierbaren Betriebsprozess. Das ist kein Versäumnis der Hersteller, sondern ein bewusstes Designprinzip. Die Plattformen sind darauf ausgelegt, in jede Unternehmensarchitektur zu passen. Die Konsequenz: Jedes Unternehmen baut seinen Betrieb individuell auf. Jeder Administrator macht es ein bisschen anders. Und nach zehn Jahren gewachsener Infrastruktur weiß oft niemand mehr genau, wer wann was wie konfiguriert hat und warum.

Bei großen Unternehmen, die viele Cluster und tausende von Services über solche Plattformen betreiben, führt das zu einem strukturellen Problem. Die Umgebungen sind historisch gewachsen, inkonsistent und für Außenstehende kaum nachvollziehbar. Gleichzeitig sind vollständige Audit-Trails, klare Änderungshistorien und nachweisbare Compliance genau in diesen Umgebungen, die höchste Sicherheitsanforderungen erfüllen müssen essenziell.

Drei Welten, ein Problem

Erschwerend kommt hinzu, dass beim Betrieb moderner Anwendungsbereitstellungsplattformen mindestens drei Fachbereiche zusammenarbeiten müssen, die in der Praxis unterschiedliche Sprachen sprechen: die Security-Abteilung, die die Plattform betreibt; die Anwendungsentwicklung, die ihre Software schnell und sicher nach außen bringen will; und die DevOps-Teams, die moderne Automatisierungsmethoden beherrschen.

Das Ergebnis ist ein Engpass, den viele IT-Leiter kennen: Die Entwicklungsabteilung deployt ihre Anwendung wöchentlich mit neuen Features. Die Security-Abteilung braucht für die Freigabe nach außen mitunter einen Monat. Dazwischen: ein Ticket-System, das die Geschwindigkeit moderner Softwareentwicklung ausbremst wie ein Tempolimit. Entwickler, die längst mit CI/CD-Pipelines, Container-Plattformen und Cloud-Infrastrukturen arbeiten, stoßen auf Prozesse, die noch manuell und seriell funktionieren.

Das eigentliche Problem dabei: In den meisten Unternehmen sind diese drei Kompetenzbereiche organisatorisch getrennt. Der Security-Administrator kennt die Plattform, aber keine Deployment-Pipelines. Der DevOps-Ingenieur kennt die Pipelines, aber nicht die Feinheiten der Anwendungsabsicherung. Der Anwendungsbetreuer kennt seine Software, aber nicht die Cyber-Security-Anforderungen dazwischen. Selbst in großen Konzernen sind diese drei Profile selten gleichzeitig verfügbar und noch seltener haben sie gemeinsam die Zeit, etwas von Grund auf neu aufzubauen. Genau an dieser Stelle scheitern Automatisierungsprojekte in der Praxis.

Richtig automatisieren

Die Antwort auf all diese Herausforderungen lautet Automatisierung. Aber Automatisierung ist kein Produkt, das man kauft und einsteckt. Es ist ein Prozess – häufig auch ein Kulturwandel.

Der Weg führt von der manuellen Konfiguration über skriptbasierte Automatisierung hin zu einer Welt, in der Infrastruktur als Code beschrieben, in Versionsverwaltungssystemen gespeichert und über automatisierte Deployment-Pipelines ausgerollt wird. Konfigurationen, die in der Entwicklungsumgebung getestet wurden, kommen immer exakt so in der Produktion an. Änderungen sind nachvollziehbar, jeder Schritt dokumentiert, Rollbacks möglich. Und als Nebenprodukt entsteht genau der Audit-Trail, den Compliance-Anforderungen wie DORA, ISO 27001 oder Vorgaben für Cyberversicherungen heute verlangen.

Dabei ist es möglich, dieselben Methoden, die in der Entwicklung bereits Standard sind – automatisierte Pipelines, versionierter Code, strukturierte Testprozesse – auch für die Bereitstellung und Absicherung der Anwendungen zu nutzen. Sicherheit wird dann nicht mehr nachträglich aufgesetzt, sondern von Anfang an mitgedacht. Shift Left Security ist kein Buzzword, sondern eine operative Notwendigkeit in Umgebungen, in denen Anwendungen wöchentlich deployt werden.

Wo externe Expertise den Unterschied macht

Genau diese Brücke zu bauen, ist der Punkt, an dem externe Dienstleister mit tiefer Plattformkenntnis und vorgefertigten Frameworks wie dem Axians Automation Framework einen messbaren Mehrwert liefern. Wer alle drei Sprachen gleichzeitig spricht – die der Security-Plattform, der Anwendungslogik und der DevOps-Methodik – kann dort ansetzen, wo interne Teams an ihre Grenzen stoßen.

Die gezielte Befähigung entsteht durch Best-Practice-Templates, die aus realen Produktivumgebungen stammen sowie Standardisierungsprozesse, die zu den tatsächlichen Anwendungsstrukturen des Kunden passen und Deployment-Workflows, die auf denselben Methoden basieren, die Entwicklungsteams bereits kennen und nutzen.

Ein weiterer oft unterschätzter Aspekt: Unternehmen, die Automatisierung inhouse entwickeln, müssen diese auch warten. Ändert der Plattformhersteller seine APIs oder bringt neue Funktionalitäten, muss die selbstgebaute Automatisierung angepasst werden. Wer auf ein gepflegtes, kontinuierlich weiterentwickeltes Framework zurückgreift, trägt diesen Aufwand nicht allein.

Was jetzt zählt

Die Unternehmen, die heute anfangen, ihre Anwendungsbereitstellung zu standardisieren und zu automatisieren, werden in wenigen Jahren in Effizienz, Sicherheit und Compliance einen erheblichen Vorsprung haben. Der Rest wird spätestens 2027 unter verringerter Zertifikatsgültigkeit feststellen, dass sie das Rad unter Zeitdruck neu erfinden müssen. Und wer versucht, diesen Weg mit KI-Assistenten abzukürzen, riskiert im schlimmsten Fall fehlerhafte Konfigurationen an genau den Stellen, an denen kein Fehler toleriert werden kann.

Der erste Schritt muss dabei nicht die große Transformation sein. Er kann mit einem einzigen Bereich beginnen – etwa der automatisierten Zertifikatsverwaltung. Oder mit standardisierten Templates für die häufigsten Anwendungstypen. Oder mit einer Staging-Pipeline, die Konfigurationsänderungen erst testet, bevor sie in die Produktion gehen. Entscheidend ist nicht der perfekte Start. Entscheidend ist, dass man aufhört zu klicken.

Über den Autor

Jürgen Mang ist Senior IT Security Consultant bei Axians IT Security. Er ist seit über 20 Jahren in der Cyber Security tätig und beschäftigt sich seit mehr als 15 Jahren intensiv mit Application-Delivery-Infrastrukturen.

(ID:50876839)