Zum Inhalt springen
Sicherheit

Zugänge im Shop entziehen: Offboarding und Rechteinventar

Zugänge entstehen mit Begründung und verschwinden ohne. Wie ein Rechteinventar über zehn Zugangswege entsteht, wie ein Offboarding abläuft und wie sich der.

17 Min. Lesezeit ZugriffsrechteOffboardingDienstleisterRechteinventarZugangsschutz

Kurz und einfach erklärt

Zugänge zu Ihrem Shop entstehen aus gutem Grund. Oft bleiben sie aber, wenn sie keiner mehr braucht. Solche alten Zugänge sind gefährlich.

Sie liegen nicht nur in der Verwaltung des Shops. Sie liegen auch beim Anbieter Ihrer Domain, beim Zahlungsdienst oder auf dem Server.

Der Beitrag zeigt, wie man eine Liste aller Zugänge führt. Er zeigt auch, wie man Zugänge entzieht, wenn jemand geht.

Wir führen diese Liste im Wartungsvertrag und prüfen sie zu festen Terminen.

Der offene Zugang, der einem Shop am gefährlichsten wird, gehört meistens niemandem mehr. Er wurde vor drei Jahren für eine Datenübernahme angelegt, hat seitdem keinen Eigentümer und steht in keiner Übergabeliste. Wer nach ihm sucht, findet ihn selten im Backend, sondern beim Registrar, im Zahlungskonto oder als Bereitstellungsschlüssel auf einem Server, den zwei Personen für abgeschaltet halten. Dieser Beitrag beschreibt, wie ein Rechteinventar entsteht, wie ein Offboarding abläuft, das nicht bei der Backend-Kennung endet, und woran sich erkennen lässt, dass der Entzug tatsächlich gewirkt hat.

Das Wichtigste in Kürze

  • Zugänge entstehen mit Begründung und verschwinden ohne. 48 Prozent aller ausgewerteten Datenabflüsse hatten eine Beteiligung Dritter, ein Zuwachs von 60 Prozent gegenüber dem Vorjahresbestand (Verizon DBIR 2026).
  • Im Handel ist der Anteil höher als im Durchschnitt: 68 Prozent der Datenabflüsse mit Beteiligung Dritter und 58 Prozent mit menschlichem Anteil, ausgewertet über 997 Vorfälle und 806 bestätigte Offenlegungen (Verizon DBIR 2026).
  • In Deutschland nennen 55 Prozent der geschädigten Unternehmen ein unzureichendes Identitäts- und Zugriffsmanagement als Grund dafür, dass ein Angriff überhaupt zum Schaden wurde (Bitkom).
  • Der Entzug ist eine Anforderung, keine Fleißaufgabe: Bei personellen Veränderungen müssen nicht mehr benötigte Kennungen und Berechtigungen entfernt werden (BSI IT-Grundschutz-Kompendium 2023, ORP.4.A2).
  • Schwache Passwörter und falsch gesetzte Berechtigungen bleiben besonders lange offen: Bis die Hälfte dieser Befunde behoben war, vergingen fast acht Monate (Verizon DBIR 2026).

Der Zugang, den niemand mehr sieht

Ein Shop wächst über Zugänge. Für die Datenübernahme kommt ein Datenbankbenutzer dazu, für den Preisfeed ein API-Schlüssel, für die Fehlersuche ein SSH-Konto, für die Kampagne ein Backend-Login der Agentur. Jeder dieser Schritte hat einen Anlass, und jeder wird in dem Moment gebraucht, in dem er entsteht. Was regelmäßig fehlt, ist der Gegenschritt: der Zeitpunkt, an dem derselbe Zugang wieder verschwindet. Diese Schieflage ist der eigentliche Befund. Zugänge entstehen unter Zeitdruck und mit klarer Begründung, sie verschwinden unter keinem von beidem.

Die Größenordnung lässt sich beziffern. Der Auswertungsbestand des Verizon-Berichts umfasst mehr als 31.000 Sicherheitsvorfälle und mehr als 22.000 bestätigte Datenabflüsse bei Organisationen in 145 Ländern (Verizon DBIR 2026). 48 Prozent dieser Datenabflüsse hatten eine Beteiligung Dritter, ein Zuwachs von 60 Prozent gegenüber dem Vorjahresbestand (Verizon DBIR 2026). Im Handel liegt der Wert noch höher: 68 Prozent der dort ausgewerteten Datenabflüsse hatten einen Anteil Dritter, 58 Prozent einen menschlichen Anteil; der Branchenabschnitt umfasst 997 Vorfälle, davon 806 mit bestätigter Offenlegung (Verizon DBIR 2026).

Die deutsche Sicht passt dazu. In einer Befragung von 1.003 Unternehmen ab zehn Beschäftigten nennen 55 Prozent der geschädigten Unternehmen ein unzureichendes Identitäts- und Zugriffsmanagement als Grund dafür, dass ein Angriff überhaupt zum Schaden führte (Bitkom). Bezogen auf die Unternehmen, die Opfer von Datendiebstahl, Industriespionage oder Sabotage wurden, tauchen aktuelle oder ehemalige Beschäftigte als Tätergruppe mit 23 Prozent unabsichtlich und 19 Prozent vorsätzlich auf, Kunden und Lieferanten mit je 8 Prozent (Bitkom). Der Zugang eines Menschen, der einmal dazugehörte, ist damit kein Randfall, sondern eine der Hauptspuren.

Entzogen ist nicht gleich entzogen

Ein deaktiviertes Backend-Konto beendet einen von zehn Wegen. Solange derselbe Partner einen Bereitstellungsschlüssel, ein Datenbankkonto oder einen Eintrag beim Registrar hält, bleibt der Weg in den Shop offen – nur an einer Stelle, die im Backend nicht sichtbar ist.

Dazu kommt die Zeit. Lediglich 23 Prozent der ausgewerteten Drittorganisationen hatten eine fehlende oder unsauber gesetzte Mehrfaktor-Anmeldung auf ihren Cloud-Konten vollständig behoben; die Hälfte aller Befunde war innerhalb eines Monats erledigt (Verizon DBIR 2026). Bei schwachen Passwörtern und falsch gesetzten Berechtigungen vergingen bis zur Behebung der Hälfte aller Befunde fast acht Monate (Verizon DBIR 2026). Ein Rechteproblem ist erfahrungsgemäß kein Ereignis mit Datum, sondern ein Zustand mit langer Halbwertszeit.

Das Rechteinventar: zehn Orte statt einem Backend

Ein Rechteinventar ist keine Benutzerliste. Eine Benutzerliste beantwortet die Frage, wer sich am Shop-Backend anmelden kann. Das Inventar beantwortet die Frage, wer den Shop verändern, auslesen oder abschalten kann – und über welchen Weg. Diese zweite Frage hat in einem gewachsenen Shop typischerweise mehr als zehn Antworten, von denen genau eine im Backend steht. Die folgende Aufstellung ist der Rahmen, den wir bei einer Bestandsaufnahme abarbeiten.

ZugangswegTypische InhaberWas der Entzug bedeutet
Shop-BackendRedaktion, Agentur, SupportKonto deaktivieren, offene Sitzungen beenden, Rolle prüfen
Server per SSHHosting, Entwicklung, BereitstellungÖffentlichen Schlüssel entfernen, Systemkonto sperren
DatenbankAnwendung, Auswertung, AltbestandBenutzer entfernen, Rechte auf die Anwendung begrenzen
DNS und RegistrarAgentur, IT-LeitungZugang trennen, Inhaberschaft auf das eigene Haus setzen
ZahlungskontoBuchhaltung, GeschäftsführungBenutzer entfernen, hinterlegtes Auszahlungskonto gegenprüfen
API-Zugänge des ShopsWarenwirtschaft, Feeds, MarktplätzeSchlüssel ungültig setzen, Herkunft der Aufrufe prüfen
MailversandMarketing, TransaktionsmailsZugangsdaten wechseln, Absenderfreigaben durchsehen
Code-AblageEntwicklung, DienstleisterMitgliedschaft entziehen, Bereitstellungsschlüssel tauschen
Monitoring und AlarmeBereitschaft, AgenturEmpfängerliste aktualisieren, stille Weiterleitungen suchen
SicherungenHosting, NotfallteamZugriff auf den Ablageort entziehen, Wiederherstellung prüfen

Die rechte Spalte ist die eigentliche Arbeit. Ein Konto zu deaktivieren dauert Sekunden; herauszufinden, welcher öffentliche Schlüssel in welcher Datei zu welchem Partner gehört, dauert länger. Wer die Härtung von Server und PHP einmal sauber dokumentiert hat, findet diese Stellen deutlich schneller wieder, und wer den Wechsel von API-Schlüsseln und Geheimnissen als Routine fährt, hat für den Ernstfall bereits die halbe Strecke hinter sich.

  • Zugangsweg – nicht der Name der Person, sondern System und Art des Zugriffs, also Benutzerkonto, Schlüssel oder Integration.
  • Verantwortliche Rolle – wer im eigenen Haus entscheidet, ob dieser Zugang bestehen bleibt. Ohne diese Angabe verwaist der Eintrag beim nächsten Personalwechsel.
  • Anlass – warum es ihn gibt. Ein Zugang ohne benennbaren Anlass ist der erste Kandidat für den Entzug.
  • Datum der letzten Prüfung – ohne dieses Feld ist das Inventar nach einem Jahr eine Vermutung mit Zeitstempel.

Das Prüfdatum macht aus der Liste einen Nachweis

Die Dokumentation der zugelassenen Kennungen, Gruppen und Rechteprofile muss regelmäßig daraufhin überprüft werden, ob sie den tatsächlichen Stand der Rechtevergabe widerspiegelt (BSI IT-Grundschutz-Kompendium 2023, ORP.4.A3). Dieselbe Anforderung verlangt außerdem, dass jede Kennung eindeutig einer Person zugeordnet werden kann und lange inaktive Kennungen deaktiviert werden sollten (BSI IT-Grundschutz-Kompendium 2023, ORP.4.A1).

Rollen statt Namen: Zuständigkeit macht den Entzug prüfbar

Wer Zugänge über Namen führt, bekommt bei jedem Wechsel eine Suchaufgabe. Wer sie über Rollen führt, bekommt eine Streichung. Der Unterschied zeigt sich erst im Ernstfall: Eine Rolle hat einen Zweck, einen Umfang und eine verantwortliche Person im eigenen Haus, ein Name hat nichts davon. Deshalb steht in einem brauchbaren Inventar die Rolle in der Zeile und der Mensch in der Spalte – und deshalb ist der zweite Faktor an einer Rolle mit weitreichenden Rechten kein Luxus. Wie sich das im Shop-Backend umsetzen lässt, steht in der Absicherung des Shop-Administratorzugangs.

Rolle statt Person

Redaktion, Agentur, Hosting, Buchhaltung: vier Rollen mit unterschiedlichem Umfang. Wer geht, verliert die Rolle, nicht nur ein Konto.

Ein Zugang, ein Zweck

Ein Schlüssel für die Bereitstellung, ein anderer für die Fehlersuche. Geteilte Zugänge lassen sich beim Ausscheiden nicht selektiv entziehen.

Zuordenbare Kennung

Sammelkonten wie redaktion@ oder agentur@ verhindern jede spätere Zuordnung. Jede Kennung gehört zu genau einer Person.

Benannte Verantwortung

Zu jedem Eintrag gehört eine Person im eigenen Haus, die über Bestand und Entzug entscheidet – unabhängig vom Dienstleister.

Geringste Berechtigung

Rechte werden nach tatsächlichem Bedarf vergeben. Ein Zugang, der weniger kann, hinterlässt beim Entzug weniger Reste.

Termin statt Erinnerung

Der Entzug hängt an einem Datum im Kalender, nicht am Gedächtnis der Person, die den Zugang eingerichtet hat.

Der Grundsatz steht nicht zur Diskussion: Benutzendenkennungen und Berechtigungen dürfen nur aufgrund des tatsächlichen Bedarfs vergeben werden, und bei personellen Veränderungen müssen die nicht mehr benötigten wieder entfernt werden (BSI IT-Grundschutz-Kompendium 2023, ORP.4.A2). Damit dieser Entzug im Nachhinein sichtbar ist, gehört jede Änderung an Rechten in dieselbe Auswertung wie Anmeldungen und Fehler; wie das praktisch aussieht, beschreibt der Beitrag zu Log-Monitoring und Alarmierung.

Der Offboarding-Ablauf in sieben Schritten

Ein Offboarding, das funktioniert, ist langweilig. Es besteht aus einer festen Reihenfolge, die unabhängig davon abläuft, ob jemand freundlich oder im Streit geht. Genau diese Unabhängigkeit ist der Punkt: Der Ablauf darf nicht davon abhängen, wie das Verhältnis am letzten Tag aussieht. Für den ungeplanten Fall gilt derselbe Ablauf mit verkürzten Fristen – die Vorbereitung dafür steht im Notfallplan für eine gehackte Website.

  1. Auslöser festhalten. Datum, Anlass und die Rolle, die endet. Ohne diesen Eintrag beginnt der Ablauf nicht nachvollziehbar.
  2. Inventar ziehen. Alle Einträge, die auf die endende Rolle zeigen – über alle zehn Zugangswege, nicht über das Backend allein.
  3. Übergabe vor Entzug. Wissen, Zuständigkeiten und laufende Vorgänge gehen an die Nachfolge, bevor der Zugang endet.
  4. Entziehen und dokumentieren. Je Eintrag: entzogen am, durch wen, mit welchem Ergebnis. Ein leeres Ergebnisfeld gilt als offen.
  5. Gemeinsame Geheimnisse wechseln. Alles, was die ausscheidende Rolle kennen konnte, wird getauscht, nicht nur das, was ihr zugeordnet war.
  6. Gegenprobe fahren. Zweiter Durchlauf durch das Inventar, ausgeführt von einer anderen Person als der, die entzogen hat.
  7. Abschluss festhalten. Was offenblieb, steht mit Grund und Termin im Protokoll. Schweigen ist kein Abschluss.

Die Reihenfolge ist der halbe Nutzen

Übergabe vor Entzug, Entzug vor Geheimniswechsel, Geheimniswechsel vor Gegenprobe. Wer zuerst entzieht und dann übergibt, produziert eine Rückfrage, die typischerweise mit einem neu eingerichteten Notzugang beantwortet wird – und der ist am Ende der Zugang, der bleibt.

Auch das Ausscheiden von Beschäftigten ist ein geregelter Vorgang und kein Zuruf: Von ausscheidenden Mitarbeitenden müssen alle im Rahmen ihrer Tätigkeit erhaltenen Unterlagen, Schlüssel und Geräte sowie Ausweise und Zutrittsberechtigungen eingezogen werden (BSI IT-Grundschutz-Kompendium 2023, ORP.2.A2). Für den Shop kommt eine zweite Frage dazu, die häufig übersehen wird: Wer informiert die Kundschaft, wenn beim Entzug etwas kippt? Der Beitrag zur Statusseite für Störungen beschreibt den Kanal, der dafür schon stehen sollte.

Dienstleisterwechsel: was Vertrag und Verordnung verlangen

Beim Wechsel eines Dienstleisters kommt zur technischen Seite eine rechtliche. Wer im Auftrag personenbezogene Daten verarbeitet, ist Auftragsverarbeiter, und der Vertrag dazu regelt ausdrücklich, was am Ende passiert. Die Verordnung formuliert das als Pflicht des Auftragsverarbeiters und gibt dem Verantwortlichen die Wahl zwischen Löschung und Rückgabe.

nach Abschluss der Erbringung der Verarbeitungsleistungen alle personenbezogenen Daten nach Wahl des Verantwortlichen entweder löscht oder zurückgibt, sofern nicht nach dem Unionsrecht oder dem Recht der Mitgliedstaaten eine Verpflichtung zur Speicherung der personenbezogenen Daten besteht

Verordnung (EU) 2016/679, Artikel 28 Absatz 3 Buchstabe g

Derselbe Artikel verlangt, dass der Auftragsverarbeiter dem Verantwortlichen alle erforderlichen Informationen zum Nachweis der Einhaltung zur Verfügung stellt und Überprüfungen ermöglicht (DSGVO, Artikel 28 Absatz 3 Buchstabe h). Und Artikel 32 verlangt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen (DSGVO, Artikel 32 Absatz 1 Buchstabe d). Ein Rechteinventar mit Prüfdatum ist genau dieses Verfahren in lesbarer Form – und die Aufbewahrung der Sicherungen gehört mit dazu, wie der Beitrag zur datenschutzkonformen Aufbewahrung von Sicherungen zeigt.

  • Rückgabe oder Löschung schriftlich entscheiden. Die Wahl liegt beim Verantwortlichen; ohne Entscheidung bleibt der Bestand beim alten Dienstleister liegen.
  • Zugänge des Dienstleisters getrennt führen. Personen des Dienstleisters, technische Konten des Dienstleisters und dessen Unterauftragnehmer sind drei verschiedene Zeilen.
  • Weisungsbindung mitdenken. Verantwortlicher und Auftragsverarbeiter unternehmen Schritte, damit ihnen unterstellte Personen mit Zugang die Daten nur auf Anweisung verarbeiten (DSGVO, Artikel 32 Absatz 4).
  • Nachweis einsammeln, solange der Draht warm ist. Nach dem letzten Rechnungslauf wird die Auskunftsbereitschaft erfahrungsgemäß geringer.
  • Fortlaufende Pflichten prüfen. Wo Aufbewahrungsfristen greifen, ersetzt eine dokumentierte Sperrung die Löschung; das gehört in dieselbe Zeile wie der Entzug. Welche Aktualisierungen daran hängen, zeigt die Übersicht zu den Datenschutz-Updates.

Auch der Baustein für Betrieb durch Dritte kennt den Punkt

Für geplante wie ungeplante Beendigungen eines Outsourcing-Verhältnisses sollte überprüft werden, ob die Zugangs-, Zutritts- und Zugriffsrechte für die Anbietenden mit der Beendigung aufgehoben wurden (BSI IT-Grundschutz-Kompendium 2023, OPS.2.3.A7). Wie eine geordnete Übernahme in der Praxis abläuft, beschreibt der Beitrag zur Wartungsübernahme beim Anbieterwechsel.

Was nach dem Entzug übrig bleibt

Der Entzug eines Kontos beendet die Anmeldung, nicht zwingend den Zugriff. Eine offene Sitzung läuft weiter, bis ihr Zeitfenster abläuft. Ein API-Schlüssel hängt an einer Integration, nicht am Benutzerkonto. Ein Webhook zeigt weiter auf ein fremdes Ziel, auch wenn die Person, die ihn angelegt hat, längst weg ist. Diese drei Reste sind der Grund, warum ein Offboarding ohne Gegenprobe nur die halbe Arbeit ist. Sie lassen sich vermeiden, wenn das Inventar sie von Anfang an als eigene Zeilen führt.

rechteinventar.yaml
# Auszug: ein System, drei Zugangswege, je eine Zeile
system: shop-backend
zweck: Pflege von Produktdaten und Bestellungen
zugriffe:
  - rolle: redaktion
    art: benutzerkonto
    verantwortlich: marketing
    letzte_pruefung: 2026-07-14
    zustand: aktiv
  - rolle: agentur
    art: benutzerkonto
    verantwortlich: it-leitung
    letzte_pruefung: 2026-07-14
    zustand: aktiv
  - rolle: integration-warenwirtschaft
    art: api-zugang
    verantwortlich: it-leitung
    letzte_pruefung: 2026-04-02
    zustand: prüfen
    hinweis: Schlüssel ohne benannten Anlass seit der Migration

Die Datei ist bewusst schlicht. Sie liegt neben der übrigen Betriebsdokumentation, wird bei jeder Änderung mit fortgeschrieben und ist damit im Zweifel der einzige Ort, an dem der Sollstand steht. Bei der Shopware-Wartung führen wir sie je Instanz, weil sich Integrationen und Bereitstellungswege zwischen zwei Shops selten decken.

  • Offene Sitzungen. Ein deaktiviertes Konto mit laufender Sitzung bleibt so lange handlungsfähig, bis die Sitzung endet oder aktiv beendet wird.
  • Integrationen und API-Zugänge. Sie hängen am System, nicht an der Person. Nach dem Entzug gehört jede Integration mit unklarer Herkunft auf die Prüfliste.
  • Webhook-Ziele. Ausgehende Meldungen an fremde Adressen überleben einen Personalwechsel in der Regel, weil sie in keiner Benutzerliste auftauchen.
  • Zweite Faktoren und Wiederherstellungscodes. Ein hinterlegtes Gerät oder ein ausgedruckter Code ist ein eigener Zugangsweg mit eigener Zeile.
  • Meldewege. Alarme, die an eine ausgeschiedene Adresse gehen, sind ein stiller Ausfall der Überwachung; welche Pflichten daran hängen, ordnet der Beitrag zu NIS2 und den Pflichten für Onlineshops ein.

Rezertifizierung: der Nachweis, dass es stimmt

Rezertifizierung heißt: Eine benannte Person bestätigt zu einem Stichtag, dass jeder Eintrag im Inventar noch gebraucht wird. Das ist kein Audit und dauert bei einem mittleren Shop selten länger als eine Stunde. Der Nutzen liegt darin, dass Zugänge damit ein Ablaufdatum bekommen, ohne dass jemand sie kündigen muss. Die Gegenprobe läuft verlässlicher über die Systeme selbst als über die Erinnerung der Beteiligten.

Terminal
$ sudo awk '{print FILENAME, $NF}' /home/*/.ssh/authorized_keys
/home/deploy/.ssh/authorized_keys agentur-2023 /home/deploy/.ssh/authorized_keys bereitstellung-ci /home/redaktion/.ssh/authorized_keys laptop-redaktion
$ mysql -N -e "SELECT user, host FROM mysql.user WHERE user <> 'root'"
shop localhost auswertung 10.0.0.% altbestand %
$ mysql -N shop -e "SELECT name, url FROM webhook"
bestellung-export https://export.altpartner.invalid/hook lager-abgleich https://pim.beispiel.invalid/hook

Drei Befehle, drei Befunde: ein Schlüssel aus dem Jahr 2023 ohne benannten Anlass, ein Datenbankbenutzer mit Zugriff von jeder Adresse und ein Webhook, der Bestelldaten an einen früheren Partner meldet. Keiner dieser drei Punkte taucht in der Benutzerliste des Backends auf. Der Termin dafür gehört in denselben Kalender wie die übrigen Wartungsfenster – und der ist zweimal im Jahr in Bewegung, wie der Beitrag zur Zeitumstellung mit Cronjobs und Zeitstempeln zeigt.

  • Vierteljährlich für Zugänge mit weitreichenden Rechten: Serverzugang, Datenbank, Registrar, Zahlungskonto.
  • Halbjährlich für Backend-Rollen, Integrationen und Meldewege.
  • Anlassbezogen bei jedem Wechsel einer Rolle, jedem Ende eines Projekts und jedem Vorfall.
  • Mit Ergebnis statt mit Häkchen: bestätigt, entzogen oder offen mit Grund und Termin. Die dauerhafte Überwachung dieser Kette gehört ins Monitoring.

Das Inventar in den Wartungsvertrag holen

Ein Rechteinventar, das nur bei der Einführung entsteht, ist nach zwölf Monaten Papier. Deshalb gehört es dorthin, wo ohnehin ein fester Rhythmus läuft. In einem SLA-Wartungsvertrag steht der Prüftermin neben dem Fenster für Sicherheitsupdates, und beide werden von derselben Bereitschaft getragen. Das spart keine Arbeit, aber es sorgt dafür, dass die Arbeit stattfindet.

Inventar je Instanz

Ein Bestand je Shop, gepflegt bei jeder Änderung an Rollen, Integrationen und Bereitstellungswegen.

Fester Prüftermin

Vierteljährlich für weitreichende Rechte, halbjährlich für den Rest – mit benannter Person und schriftlichem Ergebnis.

Offboarding auf Abruf

Ein vorbereiteter Ablauf für den geplanten Wechsel und derselbe Ablauf mit kurzen Fristen für den ungeplanten Fall.

Was davon zu welcher Leistung gehört, steht in der Übersicht der Wartungsleistungen. Wenn Sie nicht sicher sind, wie viele Zugangswege in Ihrem Shop offen sind, ist die Bestandsaufnahme der erste Schritt: Wir ziehen den Bestand über alle zehn Wege, markieren die Einträge ohne benennbaren Anlass und schlagen einen Prüfrhythmus vor. Der Weg dorthin führt über das Kontaktformular.

Die Frage, die den Zustand offenlegt

Nennen Sie ohne Nachsehen drei Personen oder Dienstleister, die heute per SSH auf Ihren Shopserver kommen. Fällt die Antwort schwer, ist das kein Sicherheitsproblem im engeren Sinn – es ist ein fehlendes Inventar, und das lässt sich in der Regel an einem Vormittag anlegen.

Quellen und Studien

Dieser Beitrag stützt sich auf Daten aus: Verizon 2026 Data Breach Investigations Report (Executive Summary), Bitkom-Presseinformation zum Wirtschaftsschutz 2026 vom 26.08.2026, BSI IT-Grundschutz-Kompendium Edition 2023 (Bausteine ORP.2, ORP.4 und OPS.2.3) sowie Verordnung (EU) 2016/679 (DSGVO), Artikel 28 und 32.

Verwandte Artikel

Recht & Compliance

Server-Logs im Shop: Wie lange IP-Adressen bleiben dürfen

Wie lange dürfen IP-Adressen in Server-Logs liegen? Was die DSGVO verlangt, was die fünf Wochen des BfDI bedeuten und wie Rotation, Kürzung und Backups wirken.

18 Min. Lesezeit
Wartung & Updates

WordPress-Sicherheitsupdates: Was alte Zweige noch bekommen

WordPress 7.1.2 schloss eine kritische Lücke, der Fix kam als Gefälligkeit bis 4.7 zurück. Was ältere Zweige erhalten, was nicht und wann der Sprung fällig ist.

20 Min. Lesezeit
Sicherheit

Rabattcodes in der Black Week: Missbrauch früh erkennen

Rabattcodes in der Black Week schützen: Codelänge, Rate-Limit am Gutscheinfeld, Alarm bei Fehlversuchen und ein Neukundenrabatt, der Mehrfachkonten standhält.

21 Min. Lesezeit