Shopware-Staging: Testsystem ohne echte Kundendaten

Ein Testsystem soll das Produktivsystem so genau nachbilden, dass ein Fehler dort auffällt und nicht im laufenden Laden. Der bequemste Weg dahin ist ein Abzug der Produktivdatenbank - und genau an dieser Stelle entsteht das Problem: Mit dem Abzug wandern Namen, Anschriften, Mailadressen, Bestellhistorien und Zahlungsbezüge in eine Umgebung, die selten so abgesichert ist wie der Shopware-Shop selbst. Rechtlich bleibt es dieselbe Verarbeitung mit denselben Pflichten, technisch fehlen dem Testsystem in der Regel Zugangsschutz, Protokollierung und ein festgelegter Löschzeitpunkt. Dieser Beitrag zeigt, welche Anforderungen ein Staging erfüllen muss, wie eine Abzugskette aussieht, die Klartext gar nicht erst entstehen lässt, und welche drei Sperren jede Kopie braucht, bevor sich jemand daran anmeldet.

Warum eine Kopie der Produktivdatenbank kein Sonderfall ist

Personenbezogene Daten sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen (DSGVO Art. 4 Nummer 1). Das Kopieren, Speichern und Bereitstellen solcher Daten zählt ausdrücklich als Verarbeitung (DSGVO Art. 4 Nummer 2). Damit ist der Abzug der Produktivdatenbank keine technische Nebenhandlung, sondern eine eigenständige Verarbeitung mit Zweck, Rechtsgrundlage und Schutzmaßnahmen. Hinzu kommt der Grundsatz der Datenminimierung: Daten müssen dem Zweck angemessen und auf das notwendige Maß beschränkt sein (DSGVO Art. 5 Abs. 1 lit. c). Ein Entwicklungsteam braucht realistische Datenmengen, Feldlängen und Verteilungen - es braucht in der Regel keinen einzigen echten Nachnamen.

Die Folgen einer Panne im Testsystem unterscheiden sich nicht von denen im Produktivsystem. Wird ein Staging kompromittiert, gilt dieselbe Meldepflicht: unverzüglich und möglichst binnen 72 Stunden an die zuständige Aufsichtsbehörde, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen (DSGVO Art. 33 Abs. 1). Bei einem Abzug echter Bestell- und Kundendaten ist diese Ausnahme erfahrungsgemäß schwer zu begründen. Fehlende technische und organisatorische Maßnahmen fallen in den Rahmen von bis zu 10 000 000 Euro oder 2 Prozent des weltweiten Jahresumsatzes (DSGVO Art. 83 Abs. 4), Verstöße gegen die Verarbeitungsgrundsätze in den Rahmen von bis zu 20 000 000 Euro oder 4 Prozent (DSGVO Art. 83 Abs. 5). Maßgeblich ist jeweils der höhere Betrag. Für ein System, das offiziell „nur zum Testen“ läuft, ist das ein bemerkenswert hoher Einsatz.

Wenn neue Software mit Produktivdaten getestet wird, könnten eventuell nicht befugte Personen hierbei vertrauliche Informationen einsehen, wie besonders schützenswerte personenbezogene Daten.

BSI, IT-Grundschutz-Kompendium Edition 2023, Baustein CON.8 Software-Entwicklung, Abschnitt 2.8

In der Praxis ist das Testsystem der schwächere Zwilling. Es läuft häufig auf einem kleineren Hosting ohne die Schutzschichten der Produktion, trägt ein Passwort, das im Team herumgereicht wird, und wird nach dem Projektende weder gelöscht noch gepflegt. Suchmaschinen finden es über eine vergessene Subdomain, Auftragsbestätigungen gehen an echte Empfänger, und ein Zahlungsdienst bekommt Anfragen aus einer Umgebung, die niemand überwacht. Keiner dieser Punkte ist ein exotischer Sonderfall; sie entstehen aus derselben Ursache, nämlich aus der Annahme, ein Testsystem sei weniger wert als sein Original. Für einen Angreifer ist es dagegen dasselbe Datenmaterial bei geringerem Widerstand.

Was Recht und Grundschutz von einem Testsystem verlangen

Zwei Vorschriften greifen unmittelbar. Der Verantwortliche muss geeignete technische und organisatorische Maßnahmen treffen - ausdrücklich einschließlich Pseudonymisierung - und zwar bereits bei der Festlegung der Mittel für die Verarbeitung (DSGVO Art. 25 Abs. 1). Als Beispiel angemessener Sicherheit nennt die Verordnung an erster Stelle die Pseudonymisierung und Verschlüsselung personenbezogener Daten (DSGVO Art. 32 Abs. 1 lit. a). Wer die Ersetzungsregeln erst schreibt, nachdem das erste Testsystem steht, erfüllt den Gedanken der Technikgestaltung nur noch nachträglich. Dient der Abzug einem anderen Zweck als die ursprüngliche Erhebung, ist außerdem zu prüfen, ob geeignete Garantien wie Verschlüsselung oder Pseudonymisierung vorliegen (DSGVO Art. 6 Abs. 4).

Der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik wird an dieser Stelle deutlicher als viele interne Richtlinien. Software muss in einer Test- und Entwicklungsumgebung getestet werden, die von der Produktionsumgebung getrennt ist (BSI IT-Grundschutz-Kompendium CON.8.A7). Getrennt heißt dabei mehr als eine andere Domain: eigene Datenbank, eigene Zugangsdaten, eigener Zwischenspeicher und ein eigenes Präfix für den Suchindex (Shopware-Dokumentation). Teilen sich beide Umgebungen eine dieser Schichten, kann ein Testlauf Produktivdaten überschreiben oder verdrängen, ohne dass jemand einen Bedienfehler gemacht hätte. Auch die Rückrichtung zählt: Ein Testsystem, das produktive Gegenstellen bedient, erzeugt dort echte Vorgänge.

Für die Daten selbst ist der Grundschutz ebenso eindeutig: Werden Produktivdaten für Software-Tests verwendet, die schützenswerte Informationen enthalten, müssen diese Testdaten angemessen geschützt werden; enthalten sie personenbezogene Informationen, müssen sie mindestens pseudonymisiert werden (BSI IT-Grundschutz-Kompendium OPS.1.1.6.A11). Funktionale Software-Tests sind zudem so durchzuführen, dass sie den Produktivbetrieb nicht beeinflussen (BSI IT-Grundschutz-Kompendium OPS.1.1.6.A2). Beides zusammen ergibt die Arbeitsregel für den Alltag: Der Testdatenbestand soll so echt wie nötig und so wenig personenbezogen wie möglich sein. Wie sich darauf eine belastbare Prüfstrecke aufsetzen lässt, beschreibt der Beitrag zur E2E-Testautomatisierung im Online-Shop - automatisierte Tests brauchen ohnehin planbare Daten statt zufälliger Echtbestellungen.

• Zweck vor Umfang: Vor dem ersten Abzug festhalten, wofür das Testsystem gebraucht wird. Ein Layouttest braucht andere Daten als eine Migrationsprobe, und der Umfang folgt aus dieser Antwort.
• Ersetzen statt Leeren: Ein geleertes Feld verändert Feldlängen und Verteilungen und macht den Test unbrauchbar. Ein ersetzter Wert derselben Form erhält die Aussagekraft.
• Referenzen erhalten: Fremdschlüssel müssen die Ersetzung überstehen, sonst zerfällt der Bestand in unverbundene Inseln und der Test prüft eine Struktur, die es so nicht gibt.
• Löschzeitpunkt mitplanen: Jedes Testsystem braucht ein Ablaufdatum. Wie das mit den gesetzlichen Fristen zusammenspielt, zeigt das Löschkonzept mit Aufbewahrungsfristen.
• Dokumentieren: Die Ersetzungsregeln gehören in die Verfahrensdokumentation, nicht in das Gedächtnis der Person, die den Abzug zieht.

Vier Stufen: Dump, Ersetzen, Kappen, Einspielen

Die Reihenfolge entscheidet über das Ergebnis. Wer den Abzug zuerst einspielt und danach bereinigt, hat für die Dauer dieses Zeitfensters eine vollständige Kopie der Kundendaten auf dem schwächer geschützten System liegen - und in Protokolldateien, Zwischenspeichern und Sicherungen dieses Systems bleiben Spuren davon zurück. Die belastbare Kette dreht das um: Der Abzug wird gezogen, die Ersetzungen laufen auf dem Abzug oder in einer abgeschotteten Zwischenstufe, überflüssige Tabellen werden gekappt, und erst die bereinigte Fassung erreicht das Testsystem. Damit entsteht auf dem Zielsystem zu keinem Zeitpunkt ein Klartextbestand, den man später mühsam wieder einfangen müsste.

-- Ersetzung läuft auf dem Abzug, bevor er das Testsystem erreicht
UPDATE customer
   SET first_name = CONCAT('Vorname', id),
       last_name = CONCAT('Nachname', id),
       email = CONCAT('nutzer-', id, '@example.invalid'),
       company = CONCAT('Firma ', id),
       remote_address = NULL,
       custom_fields = NULL;

UPDATE customer_address
   SET street = CONCAT('Musterweg ', id),
       zipcode = '00000',
       city = 'Musterstadt',
       phone_number = NULL;

-- Die Bestellung führt eine eigene Abschrift von Kunde und Anschrift
UPDATE order_customer
   SET first_name = CONCAT('Vorname', customer_id),
       last_name = CONCAT('Nachname', customer_id),
       email = CONCAT('nutzer-', customer_id, '@example.invalid');

UPDATE order_address
   SET street = CONCAT('Musterweg ', id),
       zipcode = '00000',
       city = 'Musterstadt';

-- Kappen statt ersetzen: der Test braucht diese Zeilen nicht
TRUNCATE TABLE log_entry;
TRUNCATE TABLE newsletter_recipient;
TRUNCATE TABLE import_export_log;
TRUNCATE TABLE product_review;

Die Regeln bleiben bewusst berechenbar: Aus dem Primärschlüssel wird der Ersatzwert abgeleitet, damit derselbe Datensatz bei jedem Lauf denselben Platzhalter bekommt. Das erhält die Vergleichbarkeit zwischen zwei Abzügen und erlaubt es, einen Fehlerbericht aus dem Testsystem einem Vorgang zuzuordnen, ohne den echten Namen zu kennen. Mailadressen wandern auf eine reservierte Endung, die keinem Betrieb gehört; die Endung .invalid ist genau dafür vorgesehen. Wächst der Bestand, lohnt es sich, die Ersetzung als wiederholbaren Schritt in der Entwicklungsstrecke zu hinterlegen statt als Sammlung von Anweisungen in einer Chatnachricht.

• Protokolltabellen: Zugriffs-, Fehler- und Versandprotokolle enthalten Adressen und Inhalte und werden für einen Test in der Regel nicht gebraucht.
• Warenkörbe und Sitzungen: Offene Warenkörbe blähen den Abzug auf und tragen Kennungen, die sich einer Person zuordnen lassen.
• Anhänge und Belege: Rechnungs- und Lieferscheindateien liegen außerhalb der Datenbank und werden bei einem reinen Datenbankabzug häufig übersehen.
• Zugangsdaten für fremde Systeme: Schlüssel für Zahlung, Versand und Warenwirtschaft gehören ausgetauscht, sonst wirkt das Testsystem in echten Systemen.
• Newsletter-Verteiler: Ein vollständiger Verteiler im Testsystem ist der kürzeste Weg zu einem echten Massenversand.

Welche Tabellen im Shop personenbezogene Daten tragen

Die Suche nach personenbezogenen Feldern endet selten dort, wo sie beginnt. Der Kundenstamm ist offensichtlich, die Adresstabelle auch; in einem B2B-Shop kommen Firmendaten, Ansprechpartner und kundenspezifische Preise hinzu. Weniger offensichtlich sind die Kopien: Ein Shopsystem legt bei der Bestellung in der Regel eine eigene Abschrift von Kunde und Anschrift ab, damit ein späterer Adresswechsel den Beleg nicht verändert. Diese Abschriften tragen dieselben Daten ein zweites Mal und werden bei einer Ersetzung häufig vergessen. Dazu kommen Bewertungen mit Klarnamen, Kontaktanfragen mit Freitext, Rücksendungen, Gutscheinvergaben, Import- und Exportprotokolle sowie Benachrichtigungen.

Für die Suche selbst lohnt ein systematischer Blick in das Datenmodell statt eines Rateverfahrens. Spaltennamen mit Bestandteilen wie mail, name, street, phone, ip oder token sind ein guter Anfang, treffen aber weder Freitextfelder noch serialisierte Spalten, in denen ein Zahlungsdienst seine Antwort ablegt. Wer die Abfragen dafür gegen einen großen Bestand fährt, sollte die Laufzeiten im Blick behalten; welche Messwerte dabei helfen, beschreibt der Beitrag zu Slow-Query-Log und Datenbankindizes. Das Ergebnis ist eine Liste, die versioniert wird und bei jeder Erweiterung des Shops mitwächst.

Zwei Bereiche fallen erfahrungsgemäß durch das Raster. Der erste sind eigene Erweiterungen: Ein selbst gebautes Modul für Angebote, Reklamationen oder Kundenpreise legt eigene Tabellen an, die in keiner Standardliste stehen. Der zweite sind die angebundenen Systeme - eine Warenwirtschaft, ein Versanddienst oder eine Buchhaltung, die über Schnittstellen mit dem Shop sprechen. Zeigt das Testsystem auf die produktiven Gegenstellen, entstehen dort echte Vorgänge: Sendungen werden avisiert, Belege gebucht, Bestände verändert. Die Zugangsdaten dieser Verbindungen gehören deshalb genauso in die Ersetzungsliste wie die Kundendaten selbst.

Drei Sperren: Mailversand, Zahlung, Indexierung

Die erste Sperre betrifft den Mailversand. Sie ist die wichtigste, weil ein Fehler hier sofort nach außen sichtbar wird: Ein Testlauf über tausend Bestellungen erzeugt tausend Versandbestätigungen an echte Empfänger. Die offizielle Dokumentation weist ausdrücklich darauf hin, den Mailversand in der Staging-Umgebung abzuschalten, damit keine Testmails an echte Kunden gehen (Shopware-Dokumentation). Der eingebaute Staging-Modus deaktiviert den Versand von sich aus; wird er nicht genutzt, muss die Abschaltung von Hand gesetzt werden. Tragfähiger ist eine zweite Ebene: ein Versandweg, der auf dem Testsystem gar keinen Ausgang nach draußen hat.

Diese zweite Ebene lohnt sich, weil eine Einstellung in der Anwendung durch einen Konfigurationsfehler oder eine Erweiterung wieder aufgehen kann. Wird der Versandweg auf Systemebene auf einen Auffangpunkt gelegt, bleibt die Sperre auch dann bestehen, wenn die Anwendung anderes vorhat. Als Nebeneffekt lässt sich prüfen, welche Mails ein Vorgang überhaupt auslöst - eine Information, die im Produktivsystem schwer zu bekommen ist. Wie Absenderprüfung und Zustellbarkeit im Produktivsystem eingerichtet werden, behandelt der Beitrag zu SPF, DKIM und DMARC im Online-Shop; für die Staging-Domain sollten die dort beschriebenen Einträge bewusst anders aussehen.

Die zweite Sperre betrifft Zahlung und angebundene Dienste. Der Staging-Modus entfernt Anwendungen mit aktiven Verbindungen zu externen Diensten und setzt die Kennung der Instanz zurück, damit aus der Kopie keine Vorgänge in die Produktivumgebung zurücklaufen (Shopware-Dokumentation). Die dritte Sperre betrifft die Sichtbarkeit: Ein Testsystem gehört nicht in den Suchindex, weder über eine vergessene Subdomain noch über einen Verweis in einer Sitemap. Der Kopf mit noindex muss dabei erreichbar bleiben - eine Sperre in der robots.txt verhindert lediglich, dass er gelesen wird. Wie sich unerwünschter automatisierter Zugriff insgesamt aussteuern lässt, zeigt der Beitrag zu Bot-Traffic und Scraping im Online-Shop.

Die Prüfung gehört an das Ende jedes Aufsetzens, nicht in die Erinnerung. Drei Abfragen genügen als Minimum: Wie viele Datensätze tragen noch eine Mailadresse außerhalb der reservierten Endung, wie viele Protokollzeilen sind übrig, und antwortet die Startseite ohne Zugangsschutz? Läuft eine dieser Prüfungen ins Leere, weil eine Tabelle umbenannt wurde oder eine Erweiterung eine neue angelegt hat, ist das kein grünes Ergebnis, sondern ein fehlender Messwert. Ein leeres Prüfergebnis und ein bestandenes Prüfergebnis sehen in der Ausgabe gleich aus - der Unterschied entscheidet darüber, ob das Testsystem freigegeben werden kann.

Zugang, Protokoll und Löschzeitpunkt

Auch ein bereinigtes Testsystem ist kein öffentliches System. Die offizielle Dokumentation empfiehlt, die Staging-Umgebung mit Passwortschutz, IP-Beschränkung oder einer vorgelagerten Anmeldung gegen unbefugten Zugriff zu schützen (Shopware-Dokumentation). Der einfachste tragfähige Weg ist eine Zugangsabfrage auf Ebene des Webservers, die vor der Anwendung greift und damit auch Pfade schützt, die die Anwendung selbst freigeben würde. Wichtig ist die Ausnahme für Schnittstellenpfade, wenn automatisierte Tests dagegen laufen - sonst prüft die Testreihe nur noch die Anmeldemaske. Eine Beschränkung auf bekannte Adressbereiche ergänzt das, ersetzt es aber nicht.

Zum Zugang gehört die Frage, wer eigentlich Zugriff hat. Ein Testsystem sammelt über die Projektlaufzeit Konten von Entwicklung, Fachbereich, Agentur und gelegentlichen Prüfern; nach dem Projektende bleibt diese Liste in der Regel unverändert stehen. Eine kurze, datierte Übersicht der Zugänge und ein festes Ablaufdatum für das System selbst lösen das mit geringem Aufwand. Wir nehmen diese beiden Punkte in der Beratung zusammen mit der Tabellenliste auf, weil sie erfahrungsgemäß dieselbe Ursache haben: Das Testsystem hat viele Benutzer und keinen Verantwortlichen.

Wie oft ein Abzug erneuert wird

Ein Testsystem verliert seinen Wert, wenn sein Datenbestand altert: Neue Artikel, neue Kundengruppen und neue Zahlungsarten fehlen, und ein Fehler, der nur mit aktuellen Daten auftritt, bleibt unentdeckt. Ein Abzug, der zu häufig gezogen wird, kostet dagegen Laufzeit auf dem Produktivsystem und vervielfacht die Zahl der Kopien. In der Regel trägt ein monatlicher Rhythmus mit zusätzlichen Abzügen vor größeren Vorhaben - Versionswechsel, Migration, Umbau des Datenmodells. Entscheidend ist weniger der Abstand als die Wiederholbarkeit: Ein Abzug, der als Skript vorliegt, wird gezogen; ein Abzug aus zwölf Handgriffen wird verschoben.

• Ein Skript statt eines Ablaufplans im Kopf: Ziehen, Ersetzen, Kappen und Einspielen gehören in eine ausführbare Datei mit auswertbarem Rückgabewert.
• Ausgabe in eine Protokolldatei: Ein Lauf ohne Ausgabe liefert kein Signal, an dem ein Dauerfehler auffallen könnte.
• Zahlen gegenprüfen: Zeilenzahl je Tabelle vor und nach dem Lauf vergleichen; eine Abweichung ohne Erklärung bricht den Lauf ab.
• Ein Ablaufdatum je Kopie: Abzugsdateien und Sicherungen bekommen dieselbe Frist wie das System, das sie speisen.

Der Rhythmus hat eine zweite Seite: Je seltener ein Abzug gezogen wird, desto größer wird der Unterschied zwischen Test und Produktion - und desto häufiger endet ein Testlauf mit dem Satz, auf dem Testsystem habe es funktioniert. Wer die Kette automatisiert, kann den Abstand verkürzen, ohne den Aufwand zu erhöhen. Die Sicherungsstrecke folgt derselben Logik und lässt sich mit denselben Prüfungen belegen; der Beitrag zu Backup und Disaster Recovery im Online-Shop beschreibt, warum eine Sicherung erst mit der geprüften Wiederherstellung zur Sicherung wird.

Fehlerbilder, die typischerweise auftreten

Das erste Fehlerbild ist die halbe Ersetzung. Der Kundenstamm ist bereinigt, die Abschriften in den Bestellungen sind es nicht - und weil das Kundenkonto den Kundenstamm anzeigt, fällt es beim Durchklicken nicht auf. Sichtbar wird es erst in einem Export, auf einer Rechnung oder in einer Suchabfrage über den Belegbestand. Die Gegenprobe ist einfach und gehört in jede Prüfliste: eine Zählung über alle Tabellen, die eine Mailadresse tragen können, nicht nur über die eine, die man im Kopf hatte. Findet die Zählung Spalten, die in der Liste fehlen, ist die Liste veraltet und nicht der Bestand sauber.

Das zweite Fehlerbild ist das Testsystem, das anders misst als die Produktion. Kleinere Maschine, kalter Zwischenspeicher, kein vorgelagerter Beschleuniger - Laufzeiten aus dem Staging taugen deshalb für den Vergleich zweier Stände, aber nicht als Aussage über das Erleben echter Besucher. Warum sich Laborwerte und Felddaten unterscheiden und welche Zahl in welcher Entscheidung zählt, ordnet der Beitrag zu Felddaten statt Laborwerten bei der Shop-Performance ein. Für die Testumgebung folgt daraus eine schlichte Regel: Funktion wird im Staging geprüft, Geschwindigkeit im Feld gemessen.

Das dritte Fehlerbild ist der stille Rückkanal. Ein Testsystem, dessen Konfiguration noch auf produktive Gegenstellen zeigt, erzeugt Vorgänge, die niemand erwartet: eine avisierte Sendung, eine gebuchte Rechnung, ein zurückgesetzter Bestand. Der Fehler fällt oft erst Tage später im anderen System auf, und die Ursache lässt sich dann schwer zuordnen. Wirksam dagegen ist eine Trennung auf zwei Ebenen: andere Zugangsdaten in der Konfiguration und, wo möglich, eine Sperre auf Netzebene, die Verbindungen aus dem Testsystem zu produktiven Gegenstellen abweist. Beides zusammen macht aus einem Konfigurationsfehler eine Fehlermeldung statt einer Buchung.

In welcher Reihenfolge nachrüsten

Wer eine bestehende Umgebung aufräumt, kommt schneller voran, wenn er nicht mit der Bereinigung beginnt, sondern mit den Sperren. Ein Testsystem, das keine Mails versendet, keine fremden Dienste anspricht und nicht im Index steht, richtet auch mit unbereinigten Daten deutlich weniger Schaden an als eines mit sauberen Daten und offenem Ausgang. Danach folgt der Zugangsschutz, dann die Tabellenliste, dann die Ersetzung, zuletzt die Automatisierung der Kette. Diese Reihenfolge ist keine Frage der Eleganz, sondern der Wirkung je Arbeitsstunde.

1. Sperren setzen: Mailversand abschalten, Verbindungen zu angebundenen Diensten trennen, noindex ausliefern und die Erreichbarkeit des Kopfes prüfen.
2. Zugang schließen: Zugangsabfrage vor der Anwendung, Ausnahme für die Testschnittstellen, Liste der Zugänge datieren.
3. Tabellen erfassen: Alle Tabellen und Spalten mit Personenbezug aufnehmen, eigene Erweiterungen ausdrücklich einschließen.
4. Ersetzung schreiben: Regeln je Spalte festlegen, Referenzen erhalten, Ergebnis je Tabelle zählen.
5. Kette drehen: Ersetzen in den Abzugsschritt verlagern, damit auf dem Zielsystem kein Klartext entsteht.
6. Automatisieren und protokollieren: Ablauf als Skript hinterlegen, Ausgabe in eine Datei schreiben, Ablaufdatum je Kopie setzen.

Am Ende steht ein Testsystem, das dem Produktivsystem im Verhalten entspricht und im Datenbestand nicht. Das ist die Trennung, auf die es ankommt: Struktur, Mengen und Feldlängen bleiben realistisch, der Personenbezug bleibt in der Produktion. Wer die Kette einmal sauber aufsetzt, gewinnt zusätzlich einen praktischen Nebeneffekt - Abzüge lassen sich weitergeben, ohne dass jede Übergabe eine eigene Abwägung braucht. Wenn Sie prüfen lassen möchten, was in Ihrer Umgebung heute im Testsystem liegt, ordnen wir das im E-Commerce-Projekt ein und benennen die Stellen, an denen der Klartext entsteht.