Eine Organisation auf einer SaaS-Plattform zu deaktivieren, sollte nicht darauf hinauslaufen, ein Feld wie active = false zu ändern. Diese Änderung kann das Konto in der Benutzeroberfläche ausblenden, während die Nutzer weiterhin gültige Sitzungen haben, eine Integration noch Daten sendet oder ein Auftrag in der Warteschlange weiterhin Ressourcen verändert. Um ein Organisationskonto in einer SaaS-Anwendung mit PHP zuverlässig zu deaktivieren, muss festgelegt werden, was jeder Status bedeutet, und die Auswirkungen auf Identität, Prozesse und Daten müssen koordiniert werden.
Ziel ist ein überprüfbares Ergebnis für den Vorgang. Schlägt er auf halbem Weg fehl, sollte er fortgesetzt werden können, ohne Auswirkungen zu duplizieren oder inkonsistente Berechtigungen zu hinterlassen. Dafür müssen sowohl der Lebenszyklus als auch die Ausführungs- und Wiederherstellungsverfahren gestaltet werden.
Sperrung, Schließung und Löschung voneinander abgrenzen
Diese Begriffe beschreiben unterschiedliche Entscheidungen. Eine Sperrung ist in der Regel vorübergehend: Sie blockiert bestimmte Vorgänge, während die Organisation für eine mögliche Reaktivierung erhalten bleibt. Eine Schließung markiert das Ende der operativen Geschäftsbeziehung und kann den Entzug von Zugängen sowie die Stornierung von Aufgaben umfassen. Eine Löschung betrifft die Daten und muss den Aufbewahrungsregeln, gesetzlichen Verpflichtungen und Produktvorgaben folgen.
Es empfiehlt sich nicht, alle drei Situationen mit einem einzigen Indikator abzubilden. Ein explizites Modell kann Status wie active, suspending, suspended, closing, closed und deletion_pending enthalten. Die konkreten Bezeichnungen hängen vom Produkt ab; entscheidend ist, dass jeder Status eine klare Bedeutung, Eintrittsbedingungen und zulässige Vorgänge hat.
- Sperrung: Neue Geschäftsaktionen verhindern, Daten aber erhalten und notwendige administrative Vorgänge ermöglichen.
- Schließung: Den regulären Betrieb einstellen, Zugänge ungültig machen und Abschlussaufgaben erledigen.
- Löschung: Daten gemäß einer festgelegten Richtlinie löschen oder anonymisieren – nicht als implizite Folge einer Sperrung.
Übergänge und Berechtigungen modellieren
Definieren Sie eine Zustandsmaschine oder gleichwertige Übergangsregeln. Eine aktive Organisation kann beispielsweise gesperrt werden; ein Schließungsantrag kann den Status closing einleiten; und erst nach den entsprechenden Prüfungen wechselt die Organisation zu closed. Ist ein Übergang nicht zulässig, muss die Anwendung ihn mit einer verständlichen und protokollierbaren Begründung ablehnen.
Bei Autorisierungsprüfungen muss der Status der Organisation serverseitig zusätzlich zu den Rollen des Nutzers ausgewertet werden. Schaltflächen in der Benutzeroberfläche auszublenden, entzieht keine Berechtigungen. Zentralisieren Sie diese Entscheidung in einer PHP-Anwendung in Domänendiensten, Middleware oder wiederverwendbaren Richtlinien, statt sich auf verstreute Prüfungen in Controllern zu verlassen.
Legen Sie fest, was in jeder Phase zulässig ist. Während closing können beispielsweise Exporte und das Abrufen von Rechnungen erlaubt sein, nicht aber das Anlegen von Nutzern, das Starten von Geschäftsprozessen oder das Ändern von Integrationen. Dieser Vertrag verhindert, dass verschiedene Komponenten „deaktiviert“ unterschiedlich interpretieren.
Zugänge, Sitzungen und Zugangsdaten entziehen
Die Schließung muss alle mit der Organisation verbundenen Zugangswege umfassen: Websitzungen, API-Tokens, Service-Schlüssel, ausstehende Einladungen, OAuth-Zugangsdaten und delegierte Zugänge. Ermitteln Sie, wo diese ausgegeben und wie sie ungültig gemacht werden. Auch eine nicht angenommene Einladung kann zukünftigen Zugang ermöglichen und muss deshalb storniert oder unbrauchbar gemacht werden.
Wie Sitzungen entzogen werden, hängt von ihrer Verwaltung ab. Speichert das System Sitzungen auf dem Server, können sie direkt ungültig gemacht werden. Bei zustandslosen Tokens muss dagegen möglicherweise der Organisationsstatus bei jeder Anfrage geprüft, eine Sperrliste verwendet oder eine Strategie mit kurzer Ablaufzeit angewendet werden. Welche Option geeignet ist, hängt vom Risikoniveau und den Leistungsanforderungen ab. Der Schließungsstatus muss jedoch Vorrang vor einem noch nicht abgelaufenen Token haben.
Berücksichtigen Sie auch Nutzer, die mehreren Organisationen angehören. Die Deaktivierung eines Unternehmens sollte nicht automatisch deren persönliches Konto oder den rechtmäßigen Zugang zu anderen Kunden sperren. Die Kontrolle muss auf den Organisationskontext und die effektiven Berechtigungen jeder Anfrage angewendet werden.
Warteschlangen, Webhooks und Integrationen stoppen
Eine Statusänderung in der Datenbank bricht bereits in die Warteschlange eingestellte Aufträge nicht von selbst ab. Prüfen Sie Warteschlangen-Worker, geplante Aufgaben, Import- und Exportprozesse, Synchronisierungen und Benachrichtigungen. Vor einer Aktion sollte jeder Worker prüfen, ob die Organisation für diesen Vorgang weiterhin aktiviert ist. Falls angebracht, sollten ausstehende Aufträge verworfen oder abgebrochen und diejenigen protokolliert werden, die sich nicht stoppen ließen.
Legen Sie für ausgehende Webhooks fest, ob bereits erzeugte Ereignisse zugestellt, abgebrochen oder zu Prüfzwecken aufbewahrt werden. Deaktivieren Sie bei eingehenden Integrationen die Zugangsdaten und weisen Sie neue Anfragen zurück, selbst wenn der externe Anbieter noch keine Benachrichtigung über die Schließung erhalten hat. Verlassen Sie sich nicht darauf, dass ein Dritter die Verbindung rechtzeitig trennt.
Gehen Sie in verteilten Systemen nicht davon aus, dass diese Aktionen zusammen mit einer Datenbankaktualisierung eine atomare Transaktion bilden. Verwenden Sie eine kontrollierte Abfolge und, falls angebracht, das Transactional-Outbox-Muster, um Ereignisse zu Statusänderungen zu veröffentlichen. Sorgen Sie dafür, dass Verbraucher wiederholte Nachrichten mithilfe idempotenter Vorgänge tolerieren.
Die Deaktivierung fortsetzbar und prüfbar gestalten
Modellieren Sie die Deaktivierung als Vorgang mit einer Kennung, einem Startdatum, dem ausführenden Akteur, gegebenenfalls einem Grund, einer Workflow-Version und Ergebnissen für jede Phase. Mögliche Phasen sind das Sperren von Vorgängen, der Entzug von Zugangsdaten, das Abbrechen von Aufgaben, die Benachrichtigung von Integrationen und der Abschluss von Prüfungen. Protokollieren Sie Status wie ausstehend, abgeschlossen oder fehlgeschlagen zusammen mit für die Diagnose nützlichen Informationen, ohne Geheimnisse oder unnötige personenbezogene Daten zu speichern.
Schlägt eine Phase fehl, muss das System einen erneuten Versuch ermöglichen, ohne schädliche Auswirkungen zu wiederholen. Der Entzug bereits entzogener Zugangsdaten sollte beispielsweise ein sicherer Vorgang sein. Unterscheiden Sie zwischen vorübergehenden Fehlern, bei denen ein erneuter Versuch möglich ist, und Fehlern, die ein Eingreifen erfordern. Markieren Sie die Schließung nicht als abgeschlossen, nur weil eine asynchrone Aufgabe gestartet wurde.
Legen Sie außerdem fest, was eine Reaktivierung bedeutet. Eine Sperrung lässt sich rückgängig machen, indem zulässige Vorgänge wieder freigegeben werden. Bei der Reaktivierung einer geschlossenen Organisation sollten jedoch nicht automatisch gelöschte Zugangsdaten neu erstellt oder stornierte Aufgaben wiederhergestellt werden. Die Richtlinie muss festlegen, was wiederhergestellt wird, wofür eine administrative Aktion erforderlich ist und was sich nicht mehr rückgängig machen lässt.
Den Verbleib der Daten festlegen
Bestimmen Sie vor dem Löschen von Daten, welche Datensätze ausschließlich von der Organisation abhängen, welche aus betrieblichen oder rechtlichen Gründen aufbewahrt werden müssen und welche Teil gemeinsam genutzter Informationen sind. Klären Sie den Umgang mit Dokumenten, Audit-Protokollen, Rechnungen, Backups und Daten, die bei externen Anbietern gespeichert sind. Das Löschen eines Kontos bedeutet nicht zwangsläufig, dass alle Kopien sofort verschwinden. Erläutern Sie die geltenden Regeln, ohne Fristen zu versprechen, die das System nicht garantieren kann.
Wenn die Löschung asynchron erfolgt, behalten Sie explizite Status wie deletion_pending und deleted bei und protokollieren Sie das Ergebnis für jede Datenkategorie. Prüfen Sie bei einer Anonymisierung, ob das Verfahren eine angemessene Reidentifizierung verhindert und keine Verweise zerstört, die erhalten bleiben müssen. Die Entscheidung muss mit den für das Produkt geltenden Verpflichtungen und Richtlinien übereinstimmen.
Den gesamten Vorgang prüfen und testen
Der Abschluss einer Deaktivierung muss sich durch Prüfungen belegen lassen, nicht nur durch eine Erfolgsmeldung. Vergewissern Sie sich, dass die Organisation keine gesperrten Vorgänge mehr zulässt, die vorgesehenen Zugangsdaten nicht mehr funktionieren, Einladungen ungültig sind und keine unvereinbaren Aufträge mehr ausgeführt werden. Prüfen Sie außerdem den Status der Integrationen sowie Ausnahmen, die weiterverfolgt werden müssen.
Nehmen Sie automatisierte und operative Tests für repräsentative Szenarien auf:
- Wiederholte Sperrungs- oder Schließungsanfragen, die keine Auswirkungen duplizieren dürfen.
- Ein Fehler nach dem Entzug von Zugängen, aber vor dem Stoppen einer Integration.
- Ein erneuter Versuch nach einem Netzwerkfehler oder einer fehlgeschlagenen Antwort eines Anbieters.
- Die Reaktivierung einer gesperrten Organisation und die Einschränkungen eines geschlossenen Kontos.
- Aktive Nutzer in mehreren Organisationen und Aufträge in der Warteschlange, die vor der Änderung gestartet wurden.
Eine nachvollziehbare Checkliste zusammen mit Kennzahlen zu ausstehenden und fehlgeschlagenen Vorgängen hilft, festgefahrene Schließungen zu erkennen. Entscheidend ist, die Deaktivierung als Geschäftsprozess mit festgelegten Status, Berechtigungen und Auswirkungen zu behandeln. So wird die Deaktivierung eines Organisationskontos in einer SaaS-Anwendung mit PHP von einer isolierten Änderung zu einem kontrollierten, wiederherstellbaren und für alle Komponenten konsistenten Übergang.
