Thema: SSL & Sicherheit.

Ein SSL-Zertifikat sorgt dafür, dass niemand mitlesen kann, was zwischen Browser und Server hin und her geht. Es macht die Website selbst aber nicht sicher, und genau da endet bei den meisten Anbietern die Erklärung. Bei JFconcept behandeln wir Verschlüsselung deshalb als Grundvoraussetzung, das Sicherheitskonzept beginnt erst danach.

Das Schloss im Browser ist kein Gütesiegel

Viele Betriebe fragen nach SSL, weil ein Browser einmal „nicht sicher“ angezeigt hat oder weil ein Wettbewerber damit wirbt. Die Sorge ist berechtigt, das Verständnis dahinter oft nicht. Das Schloss in der Adresszeile sagt nur: Die Übertragung ist verschlüsselt. Es sagt nichts darüber, wer die Seite betreibt, ob die Software aktuell ist und ob die Daten dahinter gut aufgehoben sind.

Daraus entstehen zwei typische Fehleinschätzungen. Die erste: Ein teureres Zertifikat sei sicherer. Die Stärke der Verschlüsselung hängt aber nicht am Preis des Zertifikats, sondern an der Konfiguration des Servers. Teurere Varianten unterscheiden sich vor allem darin, wie aufwendig die Identität des Betreibers geprüft wurde, und das sieht im Browser praktisch niemand mehr. Die zweite Fehleinschätzung ist die gefährlichere: Wer denkt, mit dem Zertifikat sei das Thema erledigt, kümmert sich um veraltete Erweiterungen, schwache Passwörter und offene Zugänge gar nicht erst.

Verschlüsselung ist der Anfang, Zugänge sind die Arbeit

Am Anfang steht die Verschlüsselung, und zwar vollständig. Ein Zertifikat allein reicht nicht, wenn die Seite weiterhin unverschlüsselt erreichbar bleibt oder einzelne Bilder und Skripte noch über die alte Adresse geladen werden. Wir leiten deshalb konsequent auf die verschlüsselte Variante um, räumen gemischte Inhalte auf und richten die Erneuerung automatisiert ein. Ein Zertifikat, das jemand von Hand verlängern muss, läuft irgendwann an einem Freitagabend ab.

Über die eigentliche Sicherheit entscheidet danach die Frage, wer überhaupt hineinkommt. Zugänge bekommen bei uns eigene Konten statt eines geteilten Admin-Passworts, und jedes Konto bekommt nur die Rechte, die zur jeweiligen Aufgabe gehören. Die Redaktion pflegt Inhalte, sie installiert keine Erweiterungen. Formulare laufen über serverseitige Prüfung und einen Honeypot gegen Spam-Bots, ohne reCAPTCHA und ohne dass Besucherdaten dafür an einen Drittanbieter wandern. Auf Wunsch geht das bis zur vollen Strenge: keine externen Requests zur Laufzeit, Schriften und Icons liegen auf dem eigenen Server. Dieser Zuschnitt gilt für Websites auf Standard-Basis genauso wie für individuell entwickelte Anwendungen, bei denen Login, Datenbank und Schnittstellen dazukommen und jede dieser Stellen eine eigene Angriffsfläche ist.

Vor dem Launch läuft jede Änderung über eine Staging-Umgebung und Git, damit niemand am Livesystem probiert. Wie die Absicherung danach im laufenden Betrieb gehalten wird, also Updates, Backups und Monitoring, ist eine eigene Entscheidung. Wir betreiben dafür eine eigene Serverumgebung, übernehmen die Wartung aber genauso auf fremder Infrastruktur. Wo gehostet wird, entscheidet der Kunde.

Sicherheit ist prüfbar, nicht nur behauptet

Wenn Sicherheit funktioniert, fällt sie nicht auf. Die ersten Anzeichen sind deshalb negativ: keine Browserwarnung, kein abgelaufenes Zertifikat, keine gekaperte Installation, keine Spam-Welle aus dem eigenen Kontaktformular.

Belegen lässt es sich trotzdem. Ein externer SSL-Test zeigt, ob die Konfiguration sauber ist und ob nur aktuelle Verschlüsselungsverfahren erlaubt sind. Die Entwicklerkonsole des Browsers meldet gemischte Inhalte sofort. Der Update-Stand von System und Erweiterungen ist ablesbar, ebenso die Frage, wie viele Personen Vollzugriff haben und wann ein Backup zuletzt wirklich zurückgespielt wurde. Genau diese Punkte geht das Team von JFconcept in Menden bei bestehenden Websites durch, bevor irgendjemand über neue Funktionen spricht. Eine Seite mit offenen Zugängen bekommt keine neuen Features, sondern zuerst saubere Konten.