Seit mehr als 25 Jahren bin ich für den Internetauftritt der Evangelischen Kirche im Rheinland verantwortlich. In dieser Zeit hat sich technisch vieles verändert. Mit der Verbreitung künstlicher Intelligenz hat sich auch die Bedrohungslage verändert. Websites sind heute stärker gefährdet als noch vor kurzem, nicht zuletzt, weil KI die Suche nach Schwachstellen und die Automatisierung von Angriffen erleichtert hat.
Wie ernst die Situation inzwischen ist, zeigte sich im Oktober 2026. Am 21. Oktober wurden zwei kritische Sicherheitslücken in PHP öffentlich bekannt: PHP2Shell (CVE-2026-109618 und CVE-2026-109619). Bereits am Vortag waren Informationen über die Schwachstellen und ein funktionsfähiger Exploit vorzeitig bekannt geworden. Das PHP-Sicherheitsteam zog deshalb die Veröffentlichung entsprechender Sicherheitsupdates kurzfristig vor.
Die Sicherheitslücken führten zu einer weltweiten Welle vorsorglicher Abschaltungen von Websites. Betroffen waren unter anderem Behörden, Universitätskliniken und Webhosting-Anbieter.
Auch wir nahmen ekir.de vorsorglich vom Netz.
Für mich war das eine ungewöhnliche Situation. Bisher war es immer mein Bestreben gewesen, den Internetauftritt der Landeskirche möglichst schnell wieder online zu bringen, wenn er einmal nicht erreichbar war. Diesmal war es anders: Zum ersten Mal nahm ich die Website selbst vom vom Netz, und zwar vorsorglich, um sie vor möglichen Angriffen zu schützen.
Rund 200 Websites laufen unter ekir.de und entsprechenden Subdomains in unserem gemanagten WordPress-System. Über unseren Jenkins-Server konnte unser Dienstleister diese über eine Pipeline binnen weniger Sekunden offline nehmen und eine Wartungsmeldung auf Webserverebene einstellen – so waren die Websites vor der Sicherheitslücke in PHP geschützt.
Auf dem Server laufen noch rund 200 weitere Instanzen, diese werden aber nicht gemanagt, sondern werden individuell von den jeweiligen Kirchengemeinden und Kirchenkreisen betreut. Zwar konnten wir deren Webmaster per E-Mail benachrichtigen und auf die Sicherheitslücke hinweisen, aber soweit ich es mitbekam, konnte niemand schnell genug reagieren.
Diese Erfahrung wirft eine grundsätzliche Frage auf: Wie viel technische Eigenständigkeit können sich Kirchengemeinden und Kirchenkreise heute noch leisten, wenn sie gleichzeitig für die Sicherheit ihrer Internetauftritte verantwortlich sind?
Zum Glück rettete uns unser Hoster, der alle Hosting-Pakete offline nahm, bis er die Sicherheitsupdates einspielen konnte.
Von HTML-Dateien und FTP zu Content-Management-Systemen
Als die Evangelische Kirche im Rheinland 1997 mit ekir.de online ging, bestanden Internetseiten aus HTML-Dateien, die per FTP auf einen Webserver übertragen wurden. Wurde die Datei index.html versehentlich gelöscht, zeigte der Server unter Umständen nur noch eine Verzeichnisauflistung. Bei entsprechender Konfiguration erschien stattdessen eine Fehlermeldung und der Server war nicht erreichbar..
Ein Fortschritt waren die FrontPage Server Extensions: FrontPage synchronisierte lokale Dateien mit dem Webserver. Doch auch hier konnte eine fehlerhafte Synchronisierung die Website unerreichbar machen.
Seit etwa 2002 setzten wir ein Content-Management-System ein. Ursprünglich hieß es InfoOffice, später wurde es unter dem Namen RedDot vermarktet. Auf einem eigenen Redaktionsserver lag eine Spiegelung der Website. Über den Browser konnte man Inhalte bearbeiten; rote Punkte markierten die Stellen, an denen Änderungen möglich waren. Daher stammte der Name RedDot.
Auch dieses System war nicht gegen Fehler gefeit: Eine falsch benannte Startseite oder die Synchronisierung in das falsche Verzeichnis konnte die Verfügbarkeit der Website beeinträchtigen.
Später wurde aus RedDot OpenText. Trotz des Namens blieb die Software proprietär. Das ursprünglich aus Oldenburg stammende Unternehmen wurde von einem nordamerikanischen Unternehmen übernommen. Das technische Prinzip blieb gleich: Ein CMS-Server übertrug Inhalte auf den Live-Webserver.
Zeitweise hatten wir erhebliche Performanceprobleme. Veröffentlichungen über FTP dauerten manchmal mehrere Stunden. Der Webserver war zwar erreichbar, zeigte aber veraltete Inhalte.
ekir.de war von Anfang an ein gemeinsames Angebot
Seit dem 16. Februar 1997 ist die Evangelische Kirche im Rheinland unter ekir.de im Internet präsent. Von Anfang an konnten Kirchengemeinden, Kirchenkreise, Ämter, Werke und Einrichtungen eigene Verzeichnisse auf dem Webserver nutzen. Das war attraktiv, als Domains und Webspace noch vergleichsweise teuer waren.
Bereits der damalige Presseverband lud Gemeinden und Kirchenkreise ein, sich unter dem gemeinsamen Dach von ekir.de zu präsentieren. Das Angebot sollte nicht nur der Landeskirche oder dem Landeskirchenamt dienen, sondern der gesamten rheinischen Kirche.
Mit der wachsenden Zahl von Internetauftritten stiegen auch die Anforderungen an den Server. Die Kapazitäten mussten angepasst werden, um Performance-Probleme und Timeouts zu vermeiden. Seit zirka 15 Jahren haben wir ein Agenturpaket eines Hosters, über das wir das Webhosting anbieten.
Vom eigenen Webspace zum WordPress-Baukasten
Inzwischen befinden sich rund 400 Internetauftritte in der Hosting-Umgebung von ekir.de. Etwa 200 nutzen das zentral gemanagte WordPress-System, weitere rund 200 werden eigenständig betrieben. Diese können ein eigenes Design, ein eigenes CMS und eigene Plugins einsetzen.
Seit 2021 erfolgte nämlich die Umstellung auf WordPress als Open-Source-System. Der EKiR-WordPress-Baukasten steht der Landeskirche ebenso wie Kirchengemeinden, Kirchenkreisen, Ämtern, Werken und Einrichtungen zur Verfügung.
Ein wesentlicher Vorteil liegt in der zentralen technischen Betreuung. Ein Dienstleister spielt Sicherheitsupdates zeitnah ein, aktualisiert die Software und schließt bekannte Sicherheitslücken. Die Gemeinden können ihr eigenes Logo verwenden und ihre Inhalte selbst gestalten, aber selbst keine keine Plugins installieren. Dafür nutzen sie dieselbe Plattform wie die Landeskirche, nur über eine CSS-Datei und gewisse Parameter können sie ihr Layout steuern. Diese Internetauftritte werden zentral gemanagt und mithilfe eines Jenkins-Servers können Updates parallel aktualisiert werden.
Eigenständigkeit bedeutet auch Verantwortung
Genau hier liegt inzwischen das Problem. Wer eine eigenständige Website betreibt, gewinnt gestalterische Freiheit, übernimmt aber zugleich die Verantwortung für Wartung, Aktualisierung und Sicherheit.
Das ist heute keine triviale Aufgabe mehr. Die technische Sicherheit verlangt kontinuierliche, im Grunde tägliche Aufmerksamkeit. Wie soll eine Kirchengemeinde dies neben ihrer eigentlichen Arbeit zuverlässig gewährleisten, wenn sich niemand täglich mit Webhosting beschäftigt?
In der Praxis werden eigenständig betriebene Systeme häufig nicht ausreichend gepflegt. Software und Plugins sind veraltet, notwendige Updates fehlen, bekannte Sicherheitslücken bleiben offen. Dadurch steigt das Risiko von Angriffen. Auch ohne einen konkreten Angriff kann eine Abschaltung aus Sicherheitsgründen notwendig werden. Wird eine Website gehackt, muss sie möglicherweise ebenfalls vom Netz genommen werden.
Warum muss eine Gemeinde anders aussehen als die Landeskirche?
Warum wollen Kirchengemeinden und Kirchenkreise unbedingt technisch eigenständige Internetauftritte betreiben? Den Wunsch nach einem eigenen Erscheinungsbild kann ich verstehen. Vielleicht gefällt das vorgegebene Design nicht, vielleicht werden zusätzliche Funktionen gewünscht.
Aber ist diese Freiheit tatsächlich so viel wert, dass man dafür Sicherheitsrisiken in Kauf nimmt? Ist ein individuelles Design wichtiger als die zuverlässige Erreichbarkeit? Der Wunsch, anders auszusehen als die Landeskirche, darf nicht dazu führen, dass Sicherheitslücken in Kauf genommen werden.
Eine Website, die wegen eines Sicherheitsproblems nicht erreichbar ist, nützt niemandem. Auch das schönste Design hilft dann nicht weiter.
Gute Inhalte sind wichtiger als ein individuelles Design
Warum also nicht den zentral gemanagten WordPress-Baukasten nutzen? Dort kann man sich gestalterisch nicht nach Belieben austoben. Dafür kann sich eine Gemeinde auf das konzentrieren, worauf es bei ihrem Internetauftritt ankommt: aktuelle und gut gepflegte Inhalte.
Sie kann über Gottesdienste informieren, Veranstaltungen ankündigen, Ansprechpersonen vorstellen und aus dem Gemeindeleben berichten, ohne selbst sämtliche technischen Updates überwachen zu müssen.
Ein gemeinsamer technischer Baukasten bedeutet nicht, dass alle Gemeinden inhaltlich gleich sein müssen. Jede Gemeinde hat ihre eigene Geschichte, eigene Schwerpunkte und eigene Angebote. Diese Unterschiede lassen sich auch innerhalb eines gemeinsamen Systems darstellen.
Auch das Datenschutzrecht hat sich verändert
Früher gab es auch datenschutzrechtliche Gründe für ein eigenes kirchliches Webhosting-Angebot. Mit der Neufassung des kirchlichen Datenschutzrechts hat sich die Situation verändert: Da nun auch Verträge nach den Vorgaben der DSGVO zulässig sind, können Gemeinden selbst günstige Hosting-Anbieter auswählen. Damit entfällt ein wesentlicher früherer Grund für ein eigenes Hosting-Angebot der Landeskirche.
Günstiges Hosting macht den sicheren Betrieb einer eigenen Website allerdings nicht einfacher. Zum Preis der Eigenständigkeit gehören auch Zeit, Fachwissen und die laufende technische Betreuung.
Wie viel Eigenständigkeit ist sinnvoll?
Nach mehr als 25 Jahren Erfahrung mit kirchlichen Internetauftritten hat sich mein Blick verändert. Früher ging es häufig darum, technische Möglichkeiten überhaupt erst zu schaffen, dass Gemeinden eine Webpräsenz haben konnten. Heute geht es zunehmend darum, Websites zuverlässig und sicher zu betreiben.
Technische Eigenständigkeit ist für mich kein Selbstzweck. Eine Kirchengemeinde braucht eine Website, die erreichbar ist, aktuelle Informationen bietet und sicher betrieben werden kann. Sie braucht nicht unbedingt ein eigenes CMS, ein individuelle technische Features oder selbst installierte Plugins.
Wenn die Wahl zwischen einem eigenständigen, möglicherweise schlecht gewarteten System und einem zentral gemanagten, regelmäßig aktualisierten WordPress-Baukasten besteht, würde ich mich für den Baukasten entscheiden.
Denn der Preis dafür, anders auszusehen als die Landeskirche, darf nicht so hoch sein, dass man Sicherheitslücken in Kauf nimmt. Lieber eine sichere, gut gepflegte Website mit einem gemeinsamen Design als einen individuellen Internetauftritt, der wegen veralteter Software irgendwann nicht mehr erreichbar ist.
Weiterführende Quellen: 25 Jahre ekir.de – viel mehr als eine Website;
