Ein angekreuztes Kästchen in einem Formular reicht nicht aus, um einen verlässlichen Einwilligungsprozess aufzubauen. Die Anwendung muss wissen, welche Einwilligung für welche Aktion, wann und mit welchem Geltungsbereich erteilt wurde. Außerdem muss sie ihre Tätigkeit einstellen können, wenn die Einwilligung widerrufen wird. Dieses Design ist besonders für optionale Funktionen relevant, etwa für Mitteilungen oder Verarbeitungen, die zur Erbringung der Hauptleistung nicht erforderlich sind.
Das Design einer widerrufbaren Einwilligung in PHP-Anwendungen erfordert, Entscheidungen voneinander zu trennen, die häufig in einem einzigen Flag zusammengefasst werden. Es entscheidet nicht allein darüber, ob eine Praxis den geltenden Vorschriften entspricht: Es überführt Produktentscheidungen und von Fachleuten geprüfte Anweisungen in überprüfbares technisches Verhalten.
Die Aktion abgrenzen und Konzepte voneinander trennen
Beschreiben Sie zunächst die konkrete Aktion, für die eine Einwilligung erforderlich ist. „Alles akzeptieren“ ist schwer auszulegen und zu widerrufen; „Werbemitteilungen per E-Mail erhalten“ grenzt Zweck und Kanal besser ab. Ändern sich Zweck oder Geltungsbereich wesentlich, sollten Sie nicht davon ausgehen, dass die frühere Einwilligung automatisch weiterhin gilt.
Unterscheiden Sie die Einwilligung von verwandten Konzepten:
- Nutzungsbedingungen: Sie legen Vertrags- oder Zugangsbedingungen fest; ihre Annahme bedeutet für sich genommen nicht, dass in eine optionale Verarbeitung eingewilligt wird.
- Einstellungen: Sie beschreiben Darstellungs- oder Konfigurationsentscheidungen. Sie können eine Einwilligung erfordern, stellen aber nicht immer selbst eine Einwilligung dar.
- Zugriffsberechtigungen: Sie steuern, was eine authentifizierte Identität im System tun kann. Der Widerruf einer optionalen Einwilligung sollte das Konto nicht automatisch deaktivieren.
- Einwilligung: Sie erfasst eine Entscheidung zu einem festgelegten Zweck und Geltungsbereich, entsprechend den zugrunde gelegten fachlichen und rechtlichen Kriterien.
Dokumentieren Sie jeden Zweck in einem stabilen Katalog, mit einer für die Benutzeroberfläche verständlichen Beschreibung und einer internen Referenz für den Code. Vermeiden Sie es, einen generischen Schlüssel wie accepted für verschiedene Zwecke wiederzuverwenden.
Den Zustand und seine Änderungen modellieren
Ein geeignetes Modell erfasst das Subjekt, den Zweck, den Geltungsbereich, den Zustand, die Herkunft der Entscheidung und Zeitstempel. Das Subjekt kann ein Konto oder eine verknüpfte Identität sein; welche Variante passt, hängt davon ab, wie die Einwilligung mit Personen, Konten und Kanälen zusammenhängt. Speichern Sie nur die Daten, die erforderlich sind, um die Entscheidung umzusetzen und zu erläutern.
Statt alles durch einen kontextlosen Boolean darzustellen, sollten Sie einen abfragbaren aktuellen Datensatz und, sofern die Audit-Anforderungen es rechtfertigen, unveränderliche oder nur ergänzbare Änderungsereignisse speichern. Ein Ereignis kann Folgendes enthalten:
- Die Kennung des Subjekts und den Zweckschlüssel.
- Die erfasste Aktion, zum Beispiel Erteilung oder Widerruf.
- Den geltenden Geltungsbereich, etwa Kanal oder Kategorie.
- Datum und Uhrzeit des Servers in einem einheitlichen Format.
- Die Herkunft, zum Beispiel ein authentifiziertes Formular oder ein Administrationsablauf, ohne übermäßige Datenerfassung.
- Eine Korrelationskennung oder die Version der Definition, sofern dies die Untersuchung von Änderungen erleichtert.
Ein Ereignisprotokoll schafft Nachvollziehbarkeit, beweist aber nicht automatisch, dass die Anfrage verständlich war, die Benutzeroberfläche angemessen gestaltet wurde oder die Entscheidung rechtlich gültig ist. Vermeiden Sie es, unnötige Formular-Kopien, IP-Adressen oder andere sensible Daten als Ersatz für ein korrektes Design zu speichern.
Bündeln Sie die Vorgänge in PHP in einem Domänendienst, zum Beispiel ConsentService, statt jedem Controller zu erlauben, den Zustand direkt zu schreiben. Die Aktualisierung des aktuellen Zustands und das Einfügen des Ereignisses sollten in einer Datenbanktransaktion erfolgen, wenn sie denselben Speicher verwenden.
Die Einwilligung am Ausführungspunkt prüfen
Die Benutzeroberfläche kann eine Option ausblenden, wenn keine Einwilligung vorliegt, doch das ist keine ausreichende Kontrolle. Die Prüfung muss an dem Punkt stattfinden, an dem die Aktion gestartet wird: bevor eine Nachricht in eine Warteschlange gestellt, eine optionale Verarbeitung ausgeführt oder eine externe Integration aufgerufen wird. Auch eine ausstehende Nachricht, die vor einem Widerruf erstellt wurde, muss vor dem Versand erneut geprüft werden.
Ein Domänenvorgang kann eine Schnittstelle wie ConsentRepository::isGranted($subjectId, $purpose, $scope) abfragen. Der Name dient nur der Veranschaulichung: Das Ergebnis muss den aktuellen Zustand, den genauen Zweck, den Geltungsbereich sowie alle vom Produkt festgelegten Ablauf- oder Versionsregeln berücksichtigen. Machen Sie eine Einwilligung für einen Kanal nicht zur Einwilligung für einen anderen.
Bei asynchroner Ausführung sollten Sie Kennungen weitergeben und den Zustand bei der Verarbeitung des Auftrags erneut abfragen, statt einer veralteten, vom Formular übermittelten Kopie zu vertrauen. Legen Sie das Verhalten bei einem Ausfall des Repositorys ausdrücklich fest: Bei einer sensiblen optionalen Aktion ist es in der Regel sicherer, sie nicht auszuführen, bis sich überprüfen lässt, ob die Einwilligung erteilt wurde. Protokollieren Sie den Betriebsfehler, ohne unnötige Daten offenzulegen.
Die Einwilligung widerrufen und die Änderung weitergeben
Der Widerruf ist ein expliziter Zustandsübergang, weder ein stilles Löschen des Verlaufs noch ein Widerruf der Sitzung. Der Benutzer kann weiterhin authentifiziert bleiben und Zugriff auf den Dienst behalten, während die optionale Aktion, in die eingewilligt wurde, eingestellt wird. Ebenso bedeutet der Widerruf einer Einwilligung nicht automatisch, dass alle Daten gelöscht werden: Aufbewahrung, Löschung oder weitere Verarbeitung können von anderen Anforderungen abhängen, die mit angemessener Beratung festgelegt werden müssen.
Aktualisieren Sie beim Erfassen des Widerrufs den von der Anwendung abgefragten Zustand und geben Sie ein Ereignis aus, mit dem sich nachgelagerte Aufgaben koordinieren lassen. Ermitteln Sie die Punkte, an die die Änderung weitergegeben werden muss: Warteschlangenaufträge, Scheduler, Kommunikationssysteme und Integrationen. Verwenden Sie zur Vermeidung inkonsistenter Auswirkungen Muster wie eine transaktionale Outbox-Tabelle und idempotente Consumer; legen Sie fest, was geschieht, wenn eine Integration nicht verfügbar ist.
Ein bereits eingetretener Effekt lässt sich nicht immer rückgängig machen, etwa eine zugestellte Nachricht. Unterscheiden Sie deshalb zwischen dem Verhindern künftiger Aktionen, dem Abbrechen noch ausstehender Aufgaben und der Korrektur bereits eingetretener Auswirkungen. Beschreiben Sie das Ergebnis präzise und halten Sie für Fehler bei der Weitergabe einen Wiederholungsmechanismus oder eine betriebliche Überprüfungsmöglichkeit vor.
Grenzfälle, Wiederholungen und Teilausfälle testen
Die Tests sollten den gesamten Ablauf abdecken, nicht nur prüfen, ob das Formular eine Auswahl speichert. Berücksichtigen Sie Erteilung, Ablehnung, Widerruf, Zweckänderungen und wiederholte Anfragen. Stellen Sie sicher, dass ein wiederholter Widerruf die Einwilligung nicht erneut aktiviert und doppelte Ereignisse weder doppelte Sendungen noch widersprüchliche Zustände verursachen.
- Prüfen Sie, dass eine Aktion nicht beginnt, wenn für den Zweck und Geltungsbereich keine aktuelle Einwilligung erteilt wurde.
- Widerrufen Sie die Einwilligung nach dem Erstellen eines Auftrags und bestätigen Sie, dass der Consumer sie vor der Ausführung erneut prüft.
- Simulieren Sie einen Fehler zwischen der Zustandsaktualisierung und der Benachrichtigung einer Integration; prüfen Sie, ob der Abgleich die Weitergabe abschließen kann.
- Testen Sie veraltete Zustände, fehlende Daten und Repository-Fehler mit dem festgelegten sicheren Verhalten.
- Stellen Sie sicher, dass der Widerruf eines Zwecks weder andere Zwecke noch Zugriffsberechtigungen oder die Sitzung verändert.
Erfassen Sie Betriebsmetriken und Verarbeitungsfehler, ohne technische Protokolle in ein paralleles Repository personenbezogener Informationen zu verwandeln. Überprüfen Sie regelmäßig ausstehende Aufgaben und Abweichungen zwischen dem zentralen Zustand und den Integrationen.
Verantwortlichkeiten vor dem Deployment abstimmen
Das Produktteam muss Zwecke, Geltungsbereich, Text und Ablauf des Widerrufs festlegen; die Technik muss diese Entscheidungen an jedem Ausführungspfad durchsetzen. Sicherheitsfachleute und Rechtsexperten können das Bedrohungsmodell, die Datenminimierung, Aufbewahrungsfristen und die maßgebliche Auslegung prüfen. Die Implementierung ersetzt diese Prüfung nicht.
Dokumentieren Sie vor dem Deployment, welche Aktionen von den jeweiligen Zwecken abhängen, wer ihre Definitionen ändern darf und wie Fehler korrigiert werden. So wird die Einwilligung von einem isolierten Kontrollkästchen zu einer überprüfbaren, nachvollziehbaren und innerhalb der PHP-Anwendung weitergebbaren Voraussetzung.
