Datensicherheit auf der Firmenwebsite: Leitfaden für Verschlüsselung und sicheren Umgang mit Daten

Datensicherheit auf einer Firmenwebsite betrifft jede Information, die Ihre Seite berührt: die Anfrage im Kontaktformular genauso wie das Passwort für das Admin Panel. In diesem Leitfaden zeige ich HTTPS, Passwortspeicherung, Datenbankverschlüsselung, Backups und Zugriffsrechte in der Reihenfolge, in der ich sie in Projekten umsetze. Ich bleibe dabei auf der technischen Ebene. Die rechtliche Seite ist ein eigenes Thema.

Was bedeutet Datensicherheit auf einer Firmenwebsite?

Datensicherheit umfasst alle technischen Maßnahmen, die verhindern, dass Unbefugte die Daten einer Website lesen, verändern oder löschen. Auf einer Firmenwebsite ruht sie auf vier Säulen: Verschlüsselung bei der Übertragung, sichere Passwortspeicherung, geprüfte Backups und rollenbasierte Zugriffsrechte.

Sicherheitsteams fassen die Ziele meist in drei Begriffen zusammen: Vertraulichkeit, Integrität und Verfügbarkeit. Vertraulichkeit heißt, dass nur Berechtigte die Daten sehen. Integrität heißt, dass niemand sie unbemerkt verändert. Verfügbarkeit heißt, dass Website und Daten da sind, wenn Sie sie brauchen.

Ich lasse dieses Dreieck allerdings nicht als Theorie stehen. Zum Beispiel wird Vertraulichkeit bei mir zu TLS und Feldverschlüsselung. Integrität bedeutet Überwachung von Dateiänderungen. Verfügbarkeit bedeutet ein Backup, das ich tatsächlich zurückgespielt habe. So entsteht aus jedem Prinzip ein konkreter Prüfpunkt.

Warum greifen Angreifer auch kleine Firmen an?

Klein zu sein schützt nicht, denn die meisten Angriffe suchen sich gar keine bestimmte Firma aus. Stattdessen durchsuchen automatische Scanner das gesamte Internet und testen bekannte Schwachstellen an jeder Adresse. Schon ein veraltetes Plugin, ein Standardname für den Admin oder eine vergessene Sicherungsdatei reichen als Einladung.

Zudem sind die Daten einer Firmenwebsite mehr wert, als viele Inhaber glauben. Zum Beispiel sammeln Kontaktformulare Namen, Telefonnummern und E-Mail Adressen. Angebotsformulare enthalten Firmendaten und Budgets. Das Admin Panel ist der Schlüssel zu allem. Außerdem nutzen Angreifer gekaperte Seiten oft für Spam oder für Angriffe auf andere Seiten. Das schadet dem Vertrauen in Ihre Marke und Ihrer Sichtbarkeit in der Suche.

Das Muster, das ich am häufigsten sehe: Jemand hat die Seite vor Jahren gebaut, die Agentur ist weg, und niemand kümmert sich um Updates. Deshalb beginne ich immer mit einer Bestandsaufnahme. Welche Software, welche Version, wer hat Zugang?

Wie schützen HTTPS und TLS Ihre Daten?

HTTPS verschlüsselt den Verkehr zwischen Browser und Server mit dem TLS Protokoll. Somit kann niemand im selben WLAN mitlesen, was ein Besucher in ein Formular eingibt. Er kann außerdem keinen Code in die Seite einschleusen. Zudem bestätigt das Zertifikat, dass der Besucher wirklich Ihren Server erreicht.

Google hat HTTPS bereits 2014 als Rankingsignal bekannt gegeben. Auch die Dokumentation von Google Search Central empfiehlt, Websites mit HTTPS abzusichern. Sicherheit und SEO ziehen hier also an einem Strang. Chrome markiert unverschlüsselte Seiten außerdem in der Adressleiste als „Nicht sicher“.

Allerdings reicht ein Zertifikat allein nicht aus. Akzeptiert der Server alte Protokolle oder lädt die Seite Dateien über HTTP, dann sinkt der Schutz. Kostenlose Zertifikate von Let's Encrypt verlängern sich automatisch. Daher gehört die eigentliche Arbeit in die Konfiguration.

Worauf achten Sie bei der TLS Konfiguration?

Zunächst gilt für die Datensicherheit: Alte Protokolle abschalten. TLS 1.0 und 1.1 gelten nicht mehr als sicher. Ihr Server sollte deshalb nur TLS 1.2 und TLS 1.3 annehmen. RFC 8446 beschreibt TLS 1.3, und diese Version verzichtet komplett auf schwache Cipher Suites.

Meine eigene Checkliste sieht so aus:

• TLS 1.0 und 1.1 aus, TLS 1.2 und 1.3 an.
• Jede HTTP Adresse leitet mit einem einzigen 301 auf HTTPS weiter.
• HSTS ist aktiv, also verbindet sich der Browser nie wieder unverschlüsselt.
• Kein gemischter Inhalt, also keine Bilder oder Skripte über HTTP.
• Automatische Zertifikatsverlängerung mit Warnung vor dem Ablauf.

Weiterleitungsketten prüfen Sie schnell mit dem Redirect Checker. Für die Servereinstellungen liefert der SSL Configuration Generator von Mozilla aktuelle Vorlagen für Apache und Nginx. Bei neuen Servern starte ich meist mit dem Profil „Intermediate“.

Wie speichern Sie Passwörter richtig in der Datenbank?

Speichern Sie Passwörter niemals im Klartext oder in umkehrbarer Form. Die richtige Methode schickt jedes Passwort durch einen langsamen Hash Algorithmus in nur eine Richtung. Sie speichern dann ausschließlich das Ergebnis. Beim Login hashen Sie die Eingabe erneut und vergleichen beide Werte.

Das Wort „langsam“ ist hier entscheidend, denn Tempo hilft dem Angreifer. Schnelle Hashes wie MD5 oder SHA1 erlauben Angreifern Milliarden Rateversuche pro Sekunde. Deshalb empfiehlt das OWASP Password Storage Cheat Sheet bewusst langsame Verfahren: Argon2id, scrypt, bcrypt und PBKDF2. Erste Wahl ist dort Argon2id, als Mindestwert mit 19 MiB Speicher, 2 Iterationen und Parallelität 1.

Zudem braucht jedes Passwort ein eigenes Salt. Moderne Bibliotheken erledigen das automatisch. Zum Beispiel erzeugt die PHP Funktion password_hash das Salt selbst und legt es im Hash ab. Eine eigene Spalte für das Salt brauchen Sie also nicht. Erfinden Sie nur niemals ein eigenes Hashverfahren.

Was unterscheidet Hashing von Verschlüsselung?

Viele verwechseln diese beiden Begriffe. Dabei verfolgen sie unterschiedliche Ziele. Hashing funktioniert nur in eine Richtung: Aus dem Ergebnis gewinnen Sie den ursprünglichen Wert nicht zurück. Verschlüsselung funktioniert dagegen in beide Richtungen. Wer den passenden Schlüssel hat, macht die Daten wieder lesbar.

Kurz gesagt: Für gute Datensicherheit hashen Sie, was Sie nie wieder lesen müssen, und verschlüsseln, was Sie später brauchen. Ein Passwort gehört in die erste Gruppe. Eine Telefonnummer gehört in die zweite.

Verwechseln Sie beides außerdem nicht mit Kodierung. Base64 schreibt Daten nur in ein anderes Format um. Dafür braucht es keinen Schlüssel, und jeder kann es rückgängig machen. Folglich ist eine in Base64 gespeicherte Telefonnummer genauso offen wie Klartext. Diesen Fehler finde ich bei Prüfungen immer noch.

Wie verschlüsseln Sie sensible Felder in der Datenbank?

Für die Datensicherheit in der Datenbank denken Sie also in zwei Ebenen. Die erste Ebene ist die Verschlüsselung auf Datenträgerebene. Dabei liegen Serverfestplatte oder Datenbankdateien verschlüsselt vor. Das hilft, wenn jemand die physische Platte stiehlt. Allerdings schützt es nicht vor einem Angreifer, der über die Anwendung zugreift, denn zur Laufzeit liegen die Daten bereits entschlüsselt vor.

Die zweite Ebene ist die Feldverschlüsselung in der Anwendung. Dabei verschlüsseln Sie besonders sensible Felder wie Ausweisnummern, Bankdaten oder private Dokumente, bevor Sie sie speichern. Somit zeigt selbst ein gestohlener Datenbankauszug an diesen Stellen nur unlesbare Werte.

Mein praktischer Rat: Listen Sie zunächst auf, welche Daten Sie wirklich speichern. Die meisten Firmenwebsites halten nur sehr wenig, das eine Feldverschlüsselung braucht. Vor allem schützt am besten, was Sie gar nicht erst sammeln. Ein unnötiges Formularfeld zu streichen ist sicherer, als es zu verschlüsseln.

Bleiben Sie außerdem bei bewährten Verfahren. AES mit 256 Bit im GCM Modus sichert Vertraulichkeit und Integrität zugleich. Nutzen Sie dafür die ausgereifte Kryptobibliothek Ihrer Sprache, zum Beispiel sodium in PHP oder das eingebaute crypto Modul in Node.js.

Wo bewahren Sie Schlüssel für die Verschlüsselung auf?

Verschlüsselung ist allerdings nur so stark wie ihr Schlüssel. Liegt der Schlüssel in einer Tabelle neben den Daten oder direkt im Quellcode, dann nimmt ein Angreifer beides auf einmal mit. Das ist der häufigste Fehler, den ich in der Praxis sehe.

Bessere Optionen sind:

1. Den Schlüssel außerhalb des Webroots speichern, in einer Umgebungsvariable oder Konfigurationsdatei, die nur der Anwendungsnutzer lesen kann.
2. Einen Key Management Service (KMS) des Cloudanbieters nutzen.
3. Schlüssel niemals in die Versionsverwaltung wie Git einchecken.
4. Schlüssel regelmäßig wechseln und alte Daten mit dem neuen Schlüssel neu verschlüsseln.

API Schlüssel und Datenbankpasswörter brauchen dieselbe Disziplin. Landet etwa der geheime Schlüssel eines Zahlungsanbieters in einem öffentlichen Repository, dann finden automatische Scanner ihn sehr schnell. Deshalb empfehle ich Werkzeuge, die jedes Repository nach Geheimnissen durchsuchen.

Wie erfassen und übertragen Sie Formulardaten sicher?

Formulare sammeln mehr Daten als jeder andere Teil einer Firmenwebsite. Folglich ziehen sie auch die meisten Angriffe an. Die erste Regel lautet: Prüfen Sie jede Eingabe auf dem Server. Die Prüfung im Browser dient der Nutzerfreundlichkeit, nicht der Sicherheit, denn Angreifer schicken Anfragen auch ganz ohne Browser.

Zweitens nutzen Sie Prepared Statements für jede Datenbankabfrage. So läuft Text aus einem Formular nie als Teil der Abfrage, und die Tür für SQL Injection bleibt zu. Die dritte Regel: Ergänzen Sie einen CSRF Schutz und ein sinnvolles Limit für Anfragen pro Zeit.

Vorsicht, denn auch das Weiterleiten per E-Mail birgt Risiken für die Datensicherheit. Statt sensible Inhalte in eine einfache E-Mail zu schreiben, senden Sie besser nur den Hinweis „neue Anfrage eingegangen“. Die Details zeigen Sie dann in einem geschützten Panel. Die Conversion Seite von Formularen behandle ich im Beitrag über Formulare für Termin, Angebot und Demo.

Was sagt die OWASP Top 10 über Ihre Firmenwebsite?

Die OWASP Top 10 listet die kritischsten Sicherheitsrisiken in Webanwendungen auf und dient weltweit als Referenz. Die aktuelle OWASP Top 10:2025 nennt fehlerhafte Zugriffskontrolle auf Platz eins und Sicherheitsfehlkonfiguration auf Platz zwei.

Konkret sieht die vollständige Liste so aus:

1. A01: Broken Access Control, also fehlerhafte Zugriffskontrolle.
2. A02: Security Misconfiguration, also Fehlkonfiguration.
3. A03: Software Supply Chain Failures, also Schwächen in der Lieferkette.
4. A04: Cryptographic Failures, also kryptografische Fehler.
5. A05: Injection.
6. A06: Insecure Design, also unsicheres Design.
7. A07: Authentication Failures, also Fehler bei der Anmeldung.
8. A08: Software or Data Integrity Failures.
9. A09: Security Logging and Alerting Failures.
10. A10: Mishandling of Exceptional Conditions.

Für Inhaber ist die Lehre zur Datensicherheit klar. Die meisten Risiken entstehen durch Fehler bei Rechten und Konfiguration, nicht durch exotische Angriffe. Anders gesagt: Gute Sicherheit beginnt mit Routine und Disziplin, nicht mit teuren Produkten.

Wie regeln Sie Zugriffsrechte für mehr Datensicherheit?

Das Grundprinzip der Datensicherheit heißt minimale Rechte. Jede Person und jedes System bekommt genau so viel Zugriff, wie die Aufgabe verlangt. Ein Blogautor braucht keine Plugins zu installieren. Die Buchhaltung braucht keine Themedateien. Der Datenbanknutzer der Anwendung braucht kein Recht, Tabellen zu löschen.

Diese Schritte setze ich um:

• Jede Person bekommt ein eigenes Konto, ein gemeinsames Admin Konto entfällt.
• Sie definieren Rollen und vergeben Rechte an Rollen, nicht an Personen.
• Scheidet jemand aus, schließen Sie das Konto am selben Tag.
• Alle drei Monate prüfen Sie sämtliche Konten.
• Für den Serverzugang nutzen Sie SSH Schlüssel statt Passwörter.

Verlassen Sie sich zudem nicht auf versteckte Menüpunkte. Ein entfernter Link heißt nicht, dass der Server beim direkten Aufruf die Rechte prüft. Genau solche Fehler bilden Platz eins der OWASP Liste.

Ist 2FA für das Admin Panel Pflicht?

Ja, heute halte ich die Anmeldung mit zweitem Faktor (2FA) für jedes Admin Panel für Pflicht. Passwörter tauchen in Datenlecks auf, werden auf anderen Seiten wiederverwendet oder fallen Phishing zum Opfer. Ein zweiter Faktor blockiert den Login dann trotzdem.

Konkret bevorzuge ich Authenticator Apps mit zeitbasierten Einmalcodes (TOTP). SMS Codes sind besser als nichts, allerdings angreifbar durch SIM Swapping. Hardwareschlüssel bieten den stärksten Schutz und eignen sich für besonders kritische Konten.

Zusätzlich empfehle ich einige Extras. Begrenzen Sie Loginversuche, sperren Sie das Konto nach mehreren Fehlversuchen kurzzeitig und halten Sie eine umbenannte Login Adresse nicht für echten Schutz. Eine neue Adresse reduziert Botverkehr nur ein wenig. Echter Schutz kommt also von 2FA und starken Passwörtern. Starke Zufallspasswörter erstellen Sie mit dem Passwort Generator.

Wie sieht eine verlässliche Backup Strategie aus?

Backups sind die letzte Verteidigungslinie der Datensicherheit. Sie retten Sie, wenn alle anderen Maßnahmen versagen. Ransomware, ein fehlerhaftes Update oder eine versehentlich gelöschte Tabelle haben dieselbe Lösung: ein sauberes, aktuelles Backup. Ich orientiere mich dabei an der verbreiteten 321 Regel.

Die Regel funktioniert so: mindestens drei Kopien der Daten, auf zwei verschiedenen Speichertypen, davon mindestens eine außerhalb des Servers. Somit nimmt selbst der Totalverlust des Servers die Daten nicht mit.

Schützen Sie Backups außerdem wie die Daten selbst. Ein unverschlüsselter Datenbankauszug in einem öffentlich erreichbaren Ordner macht alle anderen Mühen zunichte. Zum Beispiel gehört eine vergessene „backup.zip“ oder „.sql“ Datei im Webroot zu den ersten Dingen, nach denen Scanner suchen. Deshalb liegen Backups außerhalb des Webverzeichnisses, verschlüsselt und mit geplanter Löschung alter Kopien.

Wie prüfen Sie, ob ein Backup wirklich funktioniert?

Ein nie getestetes Backup ist für die Datensicherheit eine Hoffnung, kein Backup. Einer der bittersten Momente in meiner Arbeit: Im Ernstfall zeigt sich, dass die Sicherung defekt, unvollständig oder seit Monaten gestoppt ist. Deshalb stehen Wiederherstellungstests bei mir fest im Kalender.

In der Praxis ist die Methode einfach. Spielen Sie das Backup in eine separate Testumgebung zurück, öffnen Sie die Seite und testen Sie einige kritische Aktionen. Funktioniert das Formular, klappt der Login, sind die neuesten Inhalte da? Richten Sie zudem eine einfache Warnung ein, die Größe und Datum der Sicherung überwacht. Schrumpft die Größe plötzlich, dann stimmt etwas nicht.

Legen Sie außerdem zwei Werte vorab fest. Wie viel Datenverlust können Sie verkraften, und wie lange darf die Seite ausfallen? Bei täglichen Backups verlieren Sie im schlimmsten Fall einen Tag. Für eine Seite mit vielen Anfragen ist das eventuell zu viel. Dann sichern Sie die Datenbank häufiger.

Warum sind Updates und Plugins das schwächste Glied?

Die meisten Firmenwebsites laufen auf einem CMS, einem Theme und Dutzenden Plugins. Jedes dieser Teile stammt von einem anderen Team. Die neue OWASP Liste spiegelt das wider, denn Schwächen in der Software Lieferkette stehen jetzt auf Platz drei.

Meine Regeln für die Datensicherheit sind daher einfach. Deaktivieren Sie ungenutzte Plugins nicht nur, sondern löschen Sie sie. Suchen Sie Alternativen für Plugins ohne Updates seit langer Zeit. Spielen Sie Sicherheitsupdates sofort ein, testen Sie große Versionssprünge allerdings zuerst in einer Staging Umgebung. Behalten Sie zudem die Supportdauer von Laufzeitversionen wie PHP im Blick.

Die Suchseite von Aktualität behandle ich im Beitrag Content aktualisieren für SEO. Bei der Sicherheit ist das Thema schärfer. Eine bekannte, ungepatchte Lücke ist das direkte Ziel automatischer Angriffe.

Welche Sicherheitsheader und Servereinstellungen zählen?

HTTP Sicherheitsheader sind kurze Anweisungen, die dem Browser sagen, wie sich Ihre Seite verhalten soll. Somit blockieren sie viele Angriffe mit sehr wenig Aufwand. Dass Fehlkonfiguration in der OWASP Liste auf Platz zwei steigt, zeigt, wie oft Teams diesen Bereich vernachlässigen.

Diese Header haben bei mir Priorität:

• HSTS zwingt den Browser, ausschließlich HTTPS zu nutzen.
• Eine Content Security Policy (CSP) begrenzt die Quellen für Skripte und senkt das XSS Risiko.
• Der Header gegen MIME Sniffing verhindert, dass der Browser Dateitypen errät.
• Eine Referrer Policy begrenzt, welche Adressdaten an fremde Seiten gehen.
• Ein Frame Schutz verhindert, dass fremde Seiten Ihre Seite unsichtbar einbetten.

Auf dem Server schalten Sie das Verzeichnislisting ab, blenden Versionsnummern und Dateipfade in Fehlermeldungen aus und stoppen ungenutzte Dienste. Prüfen Sie außerdem Ihre DNS Einträge mit der DNS Abfrage und entfernen Sie vergessene Subdomains.

Erkennen Sie einen Angriff ohne Logging und Monitoring?

Meist nicht, denn niemand schaut hin. Eine Seite ohne Protokolle bemerkt einen Angriff erst, wenn der Schaden sichtbar ist: Spamseiten in den Suchergebnissen, Beschwerden über verdächtige Nachrichten oder eine Sperrung durch den Hoster. Der Punkt zu Logging und Alarmierung in der OWASP Liste beschreibt genau diese Lücke.

Ein Mindestmaß an Monitoring protokolliert erfolgreiche und fehlgeschlagene Logins, Rechteänderungen und Dateiänderungen. Zudem schickt es bei kritischen Ereignissen eine Warnung an eine verantwortliche Person. Speichern Sie die Protokolle außerdem außerhalb des Servers, sonst löscht ein Eindringling einfach seine Spuren.

Auf der Suchseite meldet Ihnen der Bericht zu Sicherheitsproblemen in der Google Search Console, wenn Google schädliche Inhalte entdeckt. Ein vollständiges Monitoring ist das nicht. Trotzdem ist es eine kostenlose und wertvolle Frühwarnung.

Wie beeinflussen Hosting und E-Mail die Sicherheit?

Egal wie sauber Ihr Code ist: Ein schwacher Server hält das Risiko am Leben. Beim Shared Hosting kann eine Lücke in einer fremden Seite auf demselben Server je nach Einrichtung auch Sie treffen. Daher bevorzuge ich für Firmenprojekte Infrastruktur mit isolierten Konten und regelmäßigen Updates des Betriebssystems.

Bei der Auswahl eines Hosters stelle ich deshalb vier Fragen. Wer aktualisiert die Serversoftware und wie oft? Wo liegen die Backups? Wie trennt der Anbieter die Seiten voneinander? Wen erreichen Sie im Notfall?

E-Mail gehört ebenfalls zu dieser Kette. Gefälschte Nachrichten im Namen Ihrer Domain setzen Ihre Kunden Phishing aus. SPF, DKIM und DMARC senken dieses Risiko deutlich. Details dazu stehen in meinem Beitrag über E-Mail mit eigener Domain.

Wie sichern Sie Datensicherheit bei einer Migration?

Ein Relaunch oder Umzug gehört zu den riskantesten Phasen für die Sicherheit. Altes und neues System laufen eine Zeit lang parallel. Teams verschieben Datenbankauszüge zwischen Umgebungen und öffnen temporäre Konten. All das vergisst man leicht.

Meine Regeln für den Umzug sind klar. Datenbankauszüge übertrage ich über einen verschlüsselten Kanal und lösche sie nach getaner Arbeit. Danach schütze ich die Staging Seite mit einem Passwort und sperre sie für Suchmaschinen. Temporäre Konten schließe ich sofort nach dem Umzug. In Testumgebungen nutze ich zudem lieber anonymisierte Daten statt echter Kundendaten.

Für Weiterleitungen und Rankings finden Sie Details in meiner Checkliste zur Website Migration. Für die Sicherheit gilt die goldene Regel: Bereinigen Sie nach dem Umzug auch die Daten auf dem alten Server nach Plan.

Wie beeinflussen Skripte von Drittanbietern die Datensicherheit?

Jedes externe Skript auf einer Seite ist Code, der nicht auf Ihrem Server liegt, aber im Browser Ihrer Besucher läuft. Analytics Tags, Chat Widgets, eingebettete Karten und Werbepixel gehören dazu. Wird eines davon kompromittiert, dann liest es womöglich mit, was Besucher in Formulare tippen.

Deshalb behandle ich das Skriptinventar als eigene Aufgabe der Datensicherheit. Welches Skript läuft auf welcher Seite, wer hat es eingebaut, und brauchen Sie es noch? Ein ungenutztes Tag zu entfernen senkt Risiko und Ladezeit zugleich.

Mit einer Content Security Policy erlauben Sie Skripte nur von freigegebenen Domains. Für feste Versionen externer Dateien bestätigt Subresource Integrity (SRI), dass sich die Datei nicht verändert hat. Zudem macht eine minimale Zahl externer Skripte Formularseiten sicherer und schneller.

Stellen Sie dieselbe Frage bei Chat Widgets mit KI. Wohin geht der Text des Besuchers, und wie lange speichert der Anbieter ihn? Ohne Blick in die Dokumentation des Anbieters würde ich so ein Werkzeug nicht auf eine Kontaktseite setzen.

Wer trägt Budget und Verantwortung für die Sicherheit?

Die häufigste Lücke bei der Datensicherheit ist nicht technisch, sondern organisatorisch. Hat eine Agentur die Seite gebaut, fühlt sich nach deren Abschied niemand zuständig. Die IT sieht die Website wiederum als Sache des Marketings. Folglich warten Updates monatelang.

Mein Rat lautet also: Benennen Sie eine verantwortliche Person. Sie muss nicht alles selbst erledigen. Stattdessen sorgt sie dafür, dass Updates, Backups und Kontenprüfungen fest im Kalender stehen. So fällt die Arbeit nie in die Lücke „Ich dachte, das macht jemand anderes“.

Beim Budget trennen Sie einmalige Einrichtung und laufende Pflege. Zertifikate, Speicher für Backups und Monitoring verursachen wiederkehrende Kosten. Dennoch wirken diese Kosten meist klein neben der Bereinigung einer gehackten Seite und dem Wiederaufbau von Vertrauen. Dieser Vergleich beruht auf Praxiserfahrung und ist keine Garantie.

Wo endet die DSGVO und wo beginnt technische Sicherheit?

Die DSGVO regelt, zu welchem Zweck Sie personenbezogene Daten erheben, wen Sie informieren und wie lange Sie Daten speichern dürfen. Die Themen in diesem Leitfaden sind die technische Seite dieser Regeln: Verschlüsselung, Zugriffskontrolle, Backups und Protokolle.

Beide Seiten ergänzen sich, ersetzen sich aber nicht. Eine perfekte Datenschutzerklärung hilft nicht, wenn ein unverschlüsseltes Backup in einem öffentlichen Ordner liegt. Ebenso erfüllt eine technisch einwandfreie Infrastruktur Ihre rechtlichen Pflichten nicht von allein.

Daher empfehle ich, rechtliche Texte mit einer Anwältin oder einem Anwalt und technische Maßnahmen mit Ihrem Entwicklungsteam umzusetzen. Meine Verantwortung liegt auf der technischen Ebene. Rechtsberatung gebe ich nicht.

Mit welcher Checkliste für Datensicherheit starten Sie?

Allerdings müssen Sie nicht alles auf einmal erledigen. Die folgende Reihenfolge schließt zuerst die größten Risiken mit dem geringsten Aufwand. Sie beruht auf Praxiserfahrung und ist ein Startpunkt, keine Garantie für jede Seite.

1. Erfassen Sie alle Software, Plugins und Serverkomponenten und aktualisieren Sie sie.
2. Prüfen Sie die Admin Konten, entfernen Sie gemeinsame Logins und machen Sie 2FA verpflichtend.
3. Kontrollieren Sie HTTPS, HSTS und die TLS Versionen.
4. Richten Sie automatische, verschlüsselte, externe Backups ein und testen Sie eine Wiederherstellung.
5. Prüfen Sie Formulare auf serverseitige Validierung, Prepared Statements und Limits.
6. Kontrollieren Sie die Passwortspeicherung und den Ort der Schlüssel.
7. Ergänzen Sie Sicherheitsheader sowie Logging mit Warnungen.

Bauen Sie eine neue Seite, dann kosten diese Maßnahmen deutlich weniger, wenn Sie sie von Anfang an einplanen. In meinen Webdesign Projekten gehören Sicherheitsprüfungen zur Übergabeliste. Zu den Überschneidungen mit technischem SEO passt mein Beitrag mit 10 Tipps für technisches SEO. Für die Sichtbarkeit in der Suche insgesamt finden Sie alles auf meiner Seite zur SEO Beratung.