Richtlinie zur Informationssicherheit

Unverbindliche Übersetzung. Maßgeblich ist die englische Fassung.

Diese Richtlinie beschreibt, wie LFW die Systeme schützt, die es betreibt, und die Kundensysteme, in denen es arbeitet. Sie richtet sich an Personen, die eine Sicherheitsprüfung durchführen, und beschreibt die Praxis, nicht die Absicht.

Version 1.0, 6. Oktober 2026. Teil der veröffentlichten Praktiken auf der Vertrauensseite, zusammen mit der Zugriffskontrollrichtlinie, dem Notfallplan für Sicherheitsvorfälle und der Nutzungsrichtlinie.

1. Geltungsbereich und Verantwortung

Die Richtlinie umfasst LFW.com, das Kundenportal unter my.lfw.com, die Verwaltungsseite für das Personal, den Server, auf dem sie laufen, die Arbeitsgeräte von LFW und den Zugriff von LFW auf Kundensysteme.

Leland Fiegel, der Gründer von LFW, ist für diese Richtlinie verantwortlich und mit Stand 27. September 2026 die einzige Person im Personal. Wo eine Kontrolle von einer zweiten Person abhängt, sagt diese Richtlinie das, statt anzudeuten, dass es sie gibt.

2. Wo die Systeme von LFW laufen

Die eigenen Anwendungen von LFW laufen auf einem Server bei Hetzner in Ashburn, Virginia, hinter Cloudflare. Die Firewall des Hosts nimmt Webverkehr nur aus den Adressbereichen von Cloudflare an, sodass der Server auf den Webports nicht direkt aus dem Internet erreichbar ist.

SSH ist nur mit Schlüssel möglich; Anmeldungen mit Passwort und leere Passwörter werden abgewiesen. Die Anwendung, ihre Datenbank und ihr Suchindex lauschen auf der Loopback-Adresse. fail2ban sperrt Adressen nach wiederholt fehlgeschlagenen Verbindungen.

Besucher erreichen die Website über TLS 1.3 mit einer HSTS-Richtlinie von einem Jahr; TLS 1.0 und 1.1 werden abgewiesen. Auch der Verkehr zwischen Cloudflare und dem Server ist verschlüsselt.

Die Verwaltungsseite für das Personal und das Kundenportal sind getrennte Origins (admin.lfw.com und my.lfw.com). Ein in eine öffentliche Seite eingeschleustes Skript kann nicht als angemeldetes Personal oder angemeldeter Kunde handeln, weil keines der beiden Sitzungscookies die öffentliche Website erreicht.

3. Die Anwendung

Jede Seite sendet eine Content Security Policy, die Skripte und Stile per Hash zulässt und keine Inline-Skripte erlaubt, dazu die üblichen Header: kein MIME-Sniffing, eine strenge Referrer-Richtlinie und eine Permissions Policy, die Kamera, Mikrofon und Standort verweigert.

Jeder Schreibzugriff auf die Anwendung wird auf seinen Ursprung geprüft, und öffentliche Endpunkte sind pro Adresse begrenzt. Der Typ hochgeladener Dateien wird anhand ihrer Bytes bestimmt, nie anhand der Angabe des Absenders; SVG wird abgewiesen; eine Anfrage darf drei Dateien mit je bis zu acht Megabyte enthalten.

Private Links (Berichte, Angebote, Einladungen) verwenden Zufallstoken mit mindestens 72 Bit. Geheimnisse liegen in einer Datei auf dem Server, beschränkt auf die Serveradministration und das Dienstkonto. Das Repository enthält keine Geheimnisse.

4. Bauen und Veröffentlichen

Jedes Release wird in einem Wegwerf-Container gebaut, der keine Schlüssel, keine privaten Dateien und keinen Serverzugang enthält. Installationsskripte von Abhängigkeiten sind abgeschaltet; nur zwei native Pakete werden neu gebaut, namentlich benannt.

Der Build schlägt fehl bei einem Lint-Fehler, einem Textwand- oder Schreibweisenfehler, einer doppelten Komponentenregel, einer bekannten Schwachstelle hohen Schweregrads in einem der beiden Produktions-Abhängigkeitsbäume oder einem fehlgeschlagenen Test.

Eine Version einer Abhängigkeit, die vor weniger als sieben Tagen veröffentlicht wurde, wird abgewiesen. Manipulierte Releases werden normalerweise innerhalb dieser Frist zurückgezogen; die Wartezeit ist die Kontrolle.

Ein Release wird als Ganzes aktiviert, nachdem das neue Release die Prüfungen seiner öffentlichen und geschützten Routen bestanden hat, und das vorherige Release wird für ein Zurücksetzen aufbewahrt.

5. Backups

Das Datenverzeichnis des Servers, die Datenbanken, die Geheimnisse und die Konfiguration werden mit restic gesichert: verschlüsselt und dedupliziert, einmal täglich und bei jedem Release. Nur die Serveradministration kann die Backups lesen.

Jede Datenbank wird mit dem eigenen Online-Backup von SQLite kopiert, bevor sie gespeichert wird, sodass jeder Snapshot konsistent ist. Das Repository wird wöchentlich geprüft.

Aufbewahrung: die zehn neuesten Snapshots, 30 tägliche, 26 wöchentliche, 24 monatliche und 10 jährliche. Eine verschlüsselte Kopie des Repositorys liegt zusätzlich außerhalb des Hosting-Kontos, in einem privaten Cloudflare-R2-Bucket.

Die Backups einer Kundenwebsite sind die des Hosters. LFW prüft regelmäßig, dass sie laufen, und stellt bei Bedarf daraus wieder her, wie es der Anhang zur Website-Betreuung vorsieht.

6. Protokollierung und Überwachung

Der Webserver protokolliert jede Anfrage mit ihrer Quelladresse. Das Kundenportal führt einen nur erweiterbaren Verlauf der Änderungen an Anfragen und Dokumenten, protokolliert jede Ansicht eines Kundenkontos durch das Personal und vermerkt jedes Anmeldetoken bei seiner Verwendung, damit keines erneut verwendet werden kann.

LFW Monitor prüft LFW.com jeden Tag so, wie es Kundenwebsites prüft: Barrierefreiheit, defekte Links, Geschwindigkeit, TLS, E-Mail-Authentifizierungseinträge, die Content Security Policy und die übrigen Sicherheitsheader. Die Erreichbarkeit wird jede Minute geprüft, und die Fußzeile jeder Seite zeigt sie an.

Auf einer Kundenwebsite protokolliert LFW Activity Logger, wer in WordPress wann was geändert hat, sodass sich ein Vorfall zusammen mit den Zugriffsprotokollen des Hosters rekonstruieren lässt.

7. Kundenwebsites

LFW übernimmt eine Website nur, wenn drei Dinge vorhanden sind: ein Managed Hosting im Namen des Kunden, eine Firewall innerhalb von WordPress (Wordfence Premium), lizenziert für die Website, und Cloudflare vor dem Hoster mit aktivierter Web Application Firewall und DDoS-Abwehr.

WordPress-Kern, Themes und Plugins werden monatlich aus der Versionsverwaltung aktualisiert, mit automatischen Prüfungen nach jeder Veröffentlichung. Ein Sicherheitsrelease wird vor dem Monatszyklus eingespielt. Zwischen den Updates blockieren die Firewalls bekannte Angriffe, auch Angriffe auf eine Lücke, die öffentlich ist, bevor es eine Korrektur gibt.

8. Prüfung der eigenen Systeme von LFW

LFW hat LFW.com, seine Endpunkte, den Server, DNS und die E-Mail-Authentifizierung sowie das Repository am 16. September 2026 geprüft, durch Inspektion und nicht authentifizierte Tests des eigenen Bestands. Es wurde keine Schwachstelle gefunden, die ein nicht angemeldeter Besucher nutzen könnte.

Der einzige mittelschwere Befund, Dateiberechtigungen, die einem zweiten Dienstkonto auf dem Host das Lesen der Datenbanken von LFW erlaubten, wurde am selben Tag behoben und wird jetzt durch einen Test abgesichert. Die übrigen Befunde waren Härtungspunkte, so akzeptiert, wie sie sind, und werden intern festgehalten.

Ein unabhängiger Penetrationstest der Systeme von LFW wurde noch nicht beauftragt. Wenn der Vertrag eines Kunden einen solchen Test für die Website des Kunden vorsieht, organisiert LFW ihn und berichtet das Ergebnis.

9. Ein Problem melden

Sicherheitsmeldungen gehen an security@lfw.com, genannt in security.txt (auf Englisch). Die Richtlinie zur Offenlegung von Schwachstellen, mit Geltungsbereich, Regeln und Zusage, keine rechtlichen Schritte einzuleiten, ist unter lfw.com/security veröffentlicht.

Ein Mensch antwortet innerhalb von zwei Werktagen. Geschäftszeiten: Montag bis Freitag, 9 bis 17 Uhr US-Ostküstenzeit (6 bis 14 Uhr pazifische Zeit), außer an US-Bundesfeiertagen. Außerhalb dieser Zeiten bieten wir keine Betreuung und keine Rufbereitschaft an.

10. Was diese Richtlinie nicht behauptet

LFW verfügt über keinen SOC-2- oder ISO-27001-Bericht und erfüllt kein namentlich genanntes Rahmenwerk. Es behauptet keine Festplattenverschlüsselung für die Live-Datenbank auf seinem Server, keine FIPS-validierte Kryptografie und kein Netzwerk-Intrusion-Detection-System.

Diese Richtlinie ändert sich offen: Version und Datum oben ändern sich mit ihr, und der vorherige Text bleibt im Verlauf des Repositorys erhalten.