Dezaktywacja organizacji na platformie SaaS nie powinna sprowadzać się do zmiany pola, takiego jak active = false. Taka modyfikacja może ukryć konto w interfejsie, podczas gdy jego użytkownicy nadal mają ważne sesje, integracja wciąż wysyła dane albo zadanie w kolejce nadal modyfikuje zasoby. Aby niezawodnie dezaktywować konto organizacji w SaaS opartym na PHP, trzeba określić znaczenie poszczególnych stanów i skoordynować skutki dla tożsamości, procesów i danych.
Celem jest uzyskanie weryfikowalnego rezultatu operacji oraz możliwość jej wznowienia po awarii w trakcie, bez powielania skutków i pozostawiania niespójnych uprawnień. Wymaga to zaprojektowania zarówno cyklu życia, jak i procedur wykonania oraz odzyskiwania.
Rozdzielić zawieszenie, zamknięcie i usunięcie
Terminy te opisują różne decyzje. Zawieszenie jest zwykle tymczasowe: blokuje określone operacje, ale zachowuje organizację, aby można ją było ewentualnie ponownie aktywować. Zamknięcie oznacza koniec relacji operacyjnej i może obejmować odebranie dostępu oraz anulowanie zadań. Usunięcie dotyczy danych i powinno odbywać się zgodnie z zasadami retencji, obowiązkami prawnymi i politykami produktu.
Nie należy używać jednego wskaźnika do reprezentowania wszystkich trzech sytuacji. Jawny model może uwzględniać stany takie jak active, suspending, suspended, closing, closed i deletion_pending. Konkretne nazwy zależą od produktu; ważne jest, aby każdy stan miał określone znaczenie, warunki wejścia oraz dozwolone operacje.
- Zawieszenie: blokowanie nowych działań biznesowych przy zachowaniu danych i dopuszczeniu niezbędnych operacji administracyjnych.
- Zamknięcie: zatrzymanie zwykłej działalności, unieważnienie dostępu i zakończenie zadań finalizujących.
- Usunięcie: usunięcie lub anonimizacja danych zgodnie z określoną polityką, a nie jako niejawny skutek zawieszenia.
Modelować przejścia i uprawnienia
Zdefiniuj maszynę stanów lub równoważne reguły przejść. Na przykład aktywna organizacja może przejść do stanu zawieszenia; wniosek o zamknięcie może rozpocząć stan closing; a dopiero po odpowiednich kontrolach organizacja przechodzi do stanu closed. Jeśli przejście jest niedozwolone, aplikacja powinna je odrzucić z podaniem zrozumiałej przyczyny, którą można zarejestrować.
Kontrole autoryzacji muszą uwzględniać stan organizacji po stronie serwera, a także role użytkownika. Ukrycie przycisków w interfejsie nie odbiera uprawnień. W aplikacji PHP scentralizuj tę decyzję w usługach domenowych, middleware lub współdzielonych politykach zamiast polegać na walidacjach rozproszonych po kontrolerach.
Określ, co może się wydarzyć na każdym etapie. Podczas closing można na przykład dopuścić eksporty i przeglądanie faktur, ale zablokować tworzenie użytkowników, rozpoczynanie procesów biznesowych oraz zmianę integracji. Taki kontrakt zapobiega temu, by różne komponenty odmiennie interpretowały pojęcie „dezaktywowana”.
Odebrać dostęp, unieważnić sesje i dane uwierzytelniające
Zamknięcie powinno obejmować wszystkie sposoby dostępu powiązane z organizacją: sesje internetowe, tokeny API, klucze serwisowe, oczekujące zaproszenia, dane uwierzytelniające OAuth i dostępy delegowane. Ustal, gdzie są wystawiane i jak można je unieważnić. Niezaakceptowane zaproszenie również może zapewnić przyszły dostęp, dlatego należy je anulować lub uniemożliwić jego wykorzystanie.
Unieważnianie sesji zależy od sposobu ich obsługi. Jeśli system korzysta z sesji przechowywanych na serwerze, można je unieważnić bezpośrednio; jeśli używa samodzielnych tokenów, może być konieczne sprawdzanie stanu organizacji przy każdym żądaniu, użycie listy unieważnionych tokenów albo zastosowanie strategii krótkiego czasu wygaśnięcia. Właściwa opcja zależy od poziomu ryzyka i wymagań wydajnościowych, ale stan zamknięcia musi mieć pierwszeństwo przed tokenem, który jeszcze nie wygasł.
Uwzględnij również użytkowników należących do wielu organizacji. Dezaktywacja jednej firmy nie powinna automatycznie blokować ich kont osobistych ani legalnego dostępu do innych klientów. Kontrola powinna dotyczyć kontekstu organizacji i uprawnień efektywnych dla każdego żądania.
Zatrzymać kolejki, webhooki i integracje
Zmiana stanu w bazie danych sama w sobie nie anuluje zadań już umieszczonych w kolejce. Sprawdź konsumentów kolejek, zaplanowane zadania, procesy importu i eksportu, synchronizacje oraz powiadomienia. Przed wykonaniem działania każdy worker powinien sprawdzić, czy organizacja nadal może je przeprowadzić. W razie potrzeby odrzuć lub anuluj oczekujące zadania i zarejestruj te, których nie udało się zatrzymać.
W przypadku wychodzących webhooków określ, czy już wygenerowane zdarzenia mają zostać dostarczone, anulowane czy zachowane na potrzeby audytu. W przypadku integracji przychodzących wyłącz dane uwierzytelniające i odrzucaj nowe żądania, nawet jeśli zewnętrzny dostawca nie otrzymał jeszcze powiadomienia o zamknięciu. Nie zakładaj, że podmiot zewnętrzny rozłączy się na czas.
W systemach rozproszonych nie zakładaj, że te działania i aktualizacja bazy danych tworzą transakcję atomową. Zastosuj kontrolowaną sekwencję, a w razie potrzeby wzorzec transakcyjnej skrzynki nadawczej do publikowania zdarzeń zmiany stanu. Zapewnij konsumentom odporność na powielone komunikaty dzięki operacjom idempotentnym.
Zapewnić możliwość wznowienia procesu dezaktywacji i jego audytowalność
Przedstaw dezaktywację jako operację z identyfikatorem, datą rozpoczęcia, wykonawcą, powodem, jeśli ma zastosowanie, wersją przepływu oraz wynikami poszczególnych etapów. Możliwe etapy to między innymi blokowanie operacji, unieważnianie danych uwierzytelniających, anulowanie zadań, powiadamianie integracji i przeprowadzanie kontroli końcowych. Zapisuj statusy takie jak oczekujący, zakończony lub nieudany wraz z informacjami przydatnymi w diagnostyce, unikając przechowywania sekretów lub zbędnych danych osobowych.
Jeśli etap zakończy się niepowodzeniem, system powinien umożliwiać ponowienie go bez powtarzania szkodliwych skutków. Na przykład ponowne unieważnienie już unieważnionych danych uwierzytelniających powinno być bezpieczne. Rozróżniaj błędy przejściowe, które można ponowić, od błędów wymagających interwencji. Nie oznaczaj zamknięcia jako zakończonego tylko dlatego, że uruchomiono zadanie asynchroniczne.
Określ również, co oznacza ponowna aktywacja. Zawieszenie można odwrócić, przywracając dozwolone operacje, ale ponowna aktywacja zamkniętej organizacji nie powinna automatycznie odtwarzać usuniętych danych uwierzytelniających ani przywracać anulowanych zadań. Polityka powinna określać, co zostaje przywrócone, co wymaga działania administracyjnego, a czego nie można już odwrócić.
Określić dalszy los danych
Przed usunięciem danych ustal, które rekordy zależą wyłącznie od organizacji, które należy zachować ze względów operacyjnych lub prawnych, a które należą do informacji współdzielonych. Określ sposób postępowania z dokumentami, dziennikami audytowymi, fakturami, kopiami zapasowymi i danymi przechowywanymi przez zewnętrznych dostawców. Usunięcie konta nie musi oznaczać natychmiastowego zniknięcia wszystkich kopii; wyjaśnij obowiązujące zasady, nie obiecując terminów, których system nie może zagwarantować.
Jeśli usunięcie odbywa się asynchronicznie, utrzymuj jawne stany, takie jak deletion_pending i deleted, oraz zapisuj wynik dla każdej kategorii danych. W przypadku anonimizacji sprawdź, czy procedura uniemożliwia rozsądną ponowną identyfikację i nie narusza referencji, które należy zachować. Decyzja powinna być zgodna z obowiązkami i politykami mającymi zastosowanie do produktu.
Zweryfikować i przetestować całą operację
Zakończenie dezaktywacji powinno dać się potwierdzić kontrolami, a nie tylko komunikatem o powodzeniu. Sprawdź, czy organizacja nie może wykonywać zablokowanych operacji, przewidziane dane uwierzytelniające przestały działać, zaproszenia zostały unieważnione i nie są uruchomione żadne niezgodne zadania. Zweryfikuj także stan integracji oraz wyjątki wymagające dalszych działań.
Uwzględnij automatyczne i operacyjne testy reprezentatywnych sytuacji:
- Powtórzone żądania zawieszenia lub zamknięcia, które nie powinny powodować powielania skutków.
- Awaria po odebraniu dostępu, ale przed zatrzymaniem integracji.
- Ponowienie po błędzie sieciowym lub nieudanej odpowiedzi dostawcy.
- Ponowna aktywacja zawieszonej organizacji oraz ograniczenia dotyczące zamkniętego konta.
- Aktywni użytkownicy należący do wielu organizacji i zadania w kolejce rozpoczęte przed zmianą.
Możliwa do obserwowania lista kontrolna, wraz z metrykami oczekujących i nieudanych operacji, pomaga wykrywać zablokowane procesy zamknięcia. Najważniejsze jest traktowanie dezaktywacji jako procesu biznesowego z określonymi stanami, uprawnieniami i skutkami. Dzięki temu dezaktywacja konta organizacji w SaaS opartym na PHP przestaje być odosobnioną zmianą, a staje się kontrolowanym, możliwym do wznowienia i spójnym przejściem dla wszystkich komponentów.
