IT-Security in der Anwendungsbereitstellung

Von Jürgen Mang, Senior IT Security Consultant bei Axians IT Security

Die maximale Laufzeit von SSL/TLS-Zertifikaten wird in mehreren Schritten auf künftig nur noch 47 Tage reduziert. Jede Verlängerung greift damit regelmäßig in produktionsnahe Abläufe ein. Wer Zertifikate weiterhin manuell verwaltet, riskiert nicht nur wachsenden Aufwand, sondern im schlimmsten Fall den Ausfall kritischer Dienste.

Die Gültigkeitsdauer von SSL/TLS-Zertifikaten schrumpft in den kommenden Jahren drastisch zusammen. Wo früher noch knapp 13 Monate Standard waren, setzt das CA/Browser Forum – getragen von den führenden Browser-Herstellern – nun einen klaren Zeitplan: Seit März 2026 gilt eine Obergrenze von 200 Tagen.

Ab 2027 sinkt diese auf 100 Tage, und ab 2029 müssen Zertifikate spätestens nach 47 Tagen erneuert werden.

Für Organisationen, die dutzende oder gar hunderte Zertifikate noch von Hand verwalten, bedeutet das: ein Dauerfeuer an Erneuerungsvorgängen, das sich mit der Zeit schlicht nicht mehr bewältigen lässt. Ein einziger übersehener Ablauftermin kann bereits ausreichen, um Anwendungen unmittelbar aus dem Netz zu nehmen. Die eigentliche Frage dahinter ist damit eine organisatorische: Sind die Prozesse und Plattformen zur Anwendungsbereitstellung überhaupt so aufgestellt, dass sicherheitsrelevante Änderungen in dieser Frequenz zuverlässig und kontrolliert ausgerollt werden können?

Anwendungsbereitstellung: Manuelle Prozesse als strukturelles Risiko

Trotz wachsender Komplexität und steigender Sicherheitsanforderungen arbeiten viele Unternehmen bei der Verwaltung ihrer Anwendungsinfrastruktur noch erschreckend konventionell: Konfigurationen entstehen durch manuelle Eingriffe in Oberflächen, Einstellungen existieren nur im System selbst – eine systematische Dokumentation fehlt häufig. Die Folge: Es gibt keine nachvollziehbaren Versionsstände, keine belastbaren Änderungshistorien für Audits und kaum eine Möglichkeit, Umgebungen bei Bedarf reproduzierbar wiederherzustellen. Dieses Defizit bleibt oft so lange unsichtbar, bis ein Störfall oder eine externe Prüfung es ans Licht bringt.

Application Delivery Controller: Das unsichtbare Rückgrat und seine Tücken

Dabei stehen längst mehr als interne IT-Systeme auf dem Spiel. Ob Krankenkassen-App, digitales Rezept oder Versicherungsportal – zwischen Endnutzer und Anwendung liegt eine Schicht, die Traffic verteilt, Zugriffe kontrolliert, Authentifizierung regelt und Angriffe abwehrt. Application Delivery Controller (ADC) übernehmen diese Aufgabe. Anders als klassische Firewalls, die primär das Netzwerk absichern, operieren ADCs direkt auf der Anwendungsebene – dort, wo DDoS-Attacken, Injection-Versuche oder Schwachstellen in der Authentifizierung tatsächlich greifen.

Das Problem ist weniger fehlende Funktionalität als zu viel ungezügelte Flexibilität: ADCs bieten umfangreiche APIs und weitreichende Konfigurationsmöglichkeiten, liefern aber kein verbindliches Betriebsmodell mit. Das ist systemimmanent – schließlich sollen die Lösungen möglichst vielseitig einsetzbar sein. In der Praxis führt das jedoch dazu, dass jede Organisation – und nicht selten jeder einzelne Administrator – seine eigene Konfigurationslogik entwickelt. Nach Jahren entstehen so historisch gewachsene, kaum mehr erklärbare Setups, bei denen niemand mehr sicher sagen kann, wer wann welche Änderung aus welchem Grund vorgenommen hat.

In großen, verteilten Umgebungen mit vielen Clustern und tausenden Services wird dieses Durcheinander zum strukturellen Hemmnis. Gerade hier aber sind lückenlose Audit-Trails, klare Änderungsnachweise und nachweisbare Compliance regulatorische Pflicht.

Warum KI hier keine Abkürzung ist

In der Not greifen viele Administratoren zu einem naheliegenden Werkzeug: Sie fragen KI-Assistenten. Wie konfiguriere ich diese Authentifizierungslösung? Was soll ich mit dieser Konfiguration machen? Die Antworten klingen oft überzeugend, liegen jedoch häufig daneben.

Der Grund liegt in der Natur dieser Systeme. Die Logik, die auf einem Application Delivery Controller läuft, wird auf jeden einzelnen Datenverkehr angewandt – millionenfach pro Sekunde. 80 Prozent richtig reichen hier nicht. Der Code muss zu 100 Prozent stimmen. Denn wenn dies nicht der Fall ist, läuft die Banking-App nicht. Der Warenkorb funktioniert nicht. Der Arzt kann die elektronische Patientenakte nicht öffnen.

KI-Systeme sind nicht deterministisch. Sie halluzinieren Befehle, Einstellungen und Konfigurationsoptionen, die schlicht nicht existieren. In der Praxis bedeutet das: Ein Kunde fragt einen KI-Assistenten, wie er eine Authentifizierungslösung für seine Maklersoftware einrichten soll. Die Antwort klingt plausibel, referenziert verwandte Dokumentationen und beschreibt ein Vorgehen, das technisch nicht umsetzbar ist. Wer das nicht selbst beurteilen kann, hat keine Möglichkeit, den Fehler zu erkennen. Und genau das ist das Problem: Die Administratoren, die solche KI-Antworten erhalten, sind oft nicht in der Position, die Korrektheit eigenständig zu prüfen.

Richtig automatisieren

Automatisierung ist die Antwort auf diese Herausforderungen. Der Weg führt von manueller Konfiguration über skriptbasierte Ansätze hin zu einer Welt, in der Infrastruktur als Code beschrieben, in Versionsverwaltungssystemen gespeichert und über Deployment-Pipelines ausgerollt wird. Was in der Entwicklung getestet wurde, kommt exakt so in der Produktion an – Änderungen sind nachvollziehbar, Rollbacks möglich, und als Nebenprodukt entsteht genau der Audit-Trail, den Anforderungen wie DORA, ISO 27001 oder Cyberversicherungen verlangen.

Der entscheidende Vorteil: Methoden, die in der Softwareentwicklung längst Standard sind – versionierter Code, automatisierte Pipelines, strukturierte Tests – lassen sich ebenso auf die Bereitstellung und Absicherung von Anwendungen übertragen. Sicherheit wird so von Beginn an mitgedacht.

Fazit: Jetzt handeln, bevor der Druck wächst

Unternehmen, die ihre Anwendungsbereitstellung heute standardisieren und automatisieren , gewinnen auf drei Ebenen: Effizienz, Sicherheit und Compliance. Dafür braucht es zunächst ein gemeinsames Operating Model, das Security, Entwicklung und DevOps zusammenbringt und die Silos zwischen den Bereichen überwindet. Freigaben laufen dann nicht mehr über monatelange Ticketstrecken, sondern über wiederholbare Checks, automatisierte Tests und ein konsequentes Vier-Augen-Prinzip mit Rollback-Option.

Der Einstieg muss nicht groß sein: Zertifikatserneuerung automatisieren, Standard-Templates einführen, Konfigurationen in eine Versionsverwaltung überführen. Wer das heute angeht, ist auch für die 47-Tage-Grenze ab 2029 gewappnet und kann Zertifikatsrotationen im Wochentakt durchführen, ohne den Betrieb zu gefährden oder Compliance-Anforderungen wie DORA oder ISO 27001 zu riskieren.