Najpierw obserwuj, potem egzekwuj: jak włączamy mechanizmy działające na zasadzie domyślnej odmowy

Dlaczego ten wpis powstał

To jest transparentny wpis ze strony operatora dotyczący elementu naszej dyscypliny inżynierskiej, a nie ogłoszenie nowej funkcji produktu. Kupujący B2B z Unii Europejskiej — inspektorzy ochrony danych, szefowie działów zgodności, dyrektorzy techniczni, radcowie prawni — coraz częściej zadają trafne pytanie procurementowe: „Kiedy włączacie mechanizm bezpieczeństwa, który może odrzucić mój ruch, skąd wiecie, że nie odrzuci czegoś niewłaściwego?"

Uczciwa odpowiedź to ogólna metoda, którą stosujemy wobec każdego mechanizmu tego rodzaju. Nigdy nie przełączamy odrzucającego mechanizmu wprost z „wyłączony" na „włączony". Najpierw uruchamiamy go w trybie wyłącznie obserwacyjnym, zbieramy dowody na rzeczywistym ruchu i włączamy egzekwowanie dopiero wtedy, gdy te dowody są czyste. Ten wpis wyjaśnia tę metodę zrozumiałym językiem. Został celowo napisany o samej dyscyplinie, a nie o jakimkolwiek konkretnym mechanizmie — to dyscyplina jest tym, co przenośne, i tym, co pozostaje prawdziwe nawet wtedy, gdy pojedynczy mechanizm zostanie później zmieniony lub wycofany.

Co oznacza „domyślna odmowa" — i dlaczego jej włączenie jest niebezpieczne

Mechanizm działający na zasadzie domyślnej odmowy to taki, który odrzuca żądanie, gdy kontrola się nie powiedzie, zamiast je przepuścić. „Fail closed" — awaryjnie zamknięty — to ta sama idea: jeśli mechanizm nie ma pewności, bezpieczną odpowiedzią jest nie.

Awaryjne zamykanie jest zwykle właściwą postawą w bezpieczeństwie. Drzwi, które blokują się po odcięciu zasilania, chronią to, co znajduje się za nimi. Ale dokładnie ta właściwość, która czyni mechanizm ochronnym, jest też tym, co czyni jego włączenie niebezpiecznym: jeśli kontrola jest subtelnie błędna, mechanizm awaryjnie zamknięty nie degraduje się cicho — on odrzuca. Mechanizm, który odrzuca zbyt wiele, nie jest poprawą bezpieczeństwa; jest samoczynnie wywołaną awarią. A ponieważ jego zadaniem jest odrzucanie, błędne odrzucenie nie wygląda z wewnątrz na żadną usterkę.

Ta asymetria wyznacza poprzeczkę. Włączenie mechanizmu, który może powiedzieć klientowi „nie", jest działaniem o wyższej stawce niż wdrożenie niemal dowolnej funkcji, zasługuje więc na wyższy standard dowodu niż „napisaliśmy to starannie i testy przechodzą".

Tryb obserwacji: wyłącznie rejestrowanie, zanim cokolwiek zostanie odrzucone

Naszym standardem jest to, że mechanizm domyślnej odmowy spędza czas w trybie obserwacji, zanim cokolwiek odrzuci.

W trybie obserwacji mechanizm działa na każdym pojedynczym żądaniu i dochodzi do werdyktu — to bym odrzucił albo to bym przepuścił — ale nie działa zgodnie z tym werdyktem. Zapisuje decyzję i przepuszcza żądanie. Funkcjonalnie mechanizm jest awaryjnie otwarty: nic nie jest blokowane, żaden klient nie jest dotknięty. To, co zyskujemy, to zapis dokładnie tego, jak mechanizm zachowałby się wobec rzeczywistego ruchu produkcyjnego, przy pełnym wolumenie, bez żadnego ryzyka faktycznego egzekwowania.

Dopiero gdy dowody z trybu obserwacji są czyste, rozważamy przełączenie tego samego mechanizmu na faktyczne odrzucanie. Ścieżka kodu, która decyduje „przepuść albo odrzuć", jest taka sama w obu trybach; jedyne, co się zmienia, to czy werdykt jest wykonywany. To ma znaczenie: oznacza, że rzecz, którą obserwowaliśmy, jest dokładnie tą rzeczą, którą później egzekwujemy, a nie jej bliskim krewnym.

Trzy rzeczy, które tryb obserwacji musi udowodnić

Tryb obserwacji to nie jest „zostawmy to włączone na chwilę i rzućmy okiem na logi". Wymagamy, aby ustalił trzy konkretne rzeczy, zanim mechanizm zasłuży na prawo do egzekwowania.

1. Kompletność — żadne żądanie nie prześliznęło się bez oceny. Nie wystarczy, że mechanizm zadziałał na żądaniach, na które akurat spojrzeliśmy. Potrzebujemy pewności, że ocenił każdą ścieżkę, którą żądanie może dotrzeć do nas. Zyskujemy ją z bezprzerwowego licznika: mechanizm numeruje swoje oceny, a my potwierdzamy, że sekwencja nie ma luk. Luka nie jest problemem kosmetycznym — oznacza, że pewne żądania dotarły do serwisu w ogóle bez oceny, a na tych ścieżkach egzekwujący mechanizm podejmowałby decyzje na ślepo. Mechanizm, któremu masz za chwilę powierzyć odrzucanie, musi najpierw zostać udowodniony jako kompletny.

2. Mechanizm naprawdę się uruchamia. Mechanizm, który milczał przez cały tryb obserwacji, jest niejednoznaczny: albo nic złego nie nadeszło, albo mechanizm jest po cichu zepsuty i nigdy niczego by nie wychwycił. „Cichy" to nie to samo, co „działający". Dlatego celowo wysyłamy znane złe żądanie — takie, które mechanizm ma odrzucić — i potwierdzamy, że w trybie obserwacji odrzuciłby dokładnie to jedno. To zamienia pełne nadziei założenie w pozytywny test na rzeczywistym, działającym systemie. Nie chcesz, by pierwszy raz, kiedy mechanizm zadziała naprawdę, był jednocześnie pierwszym razem, kiedy dowiadujesz się, czy w ogóle potrafi.

3. Zero fałszywych alarmów na rzeczywistym ruchu. Przez całe okno stabilizacyjne autentycznego ruchu klientów mechanizm nie może oznaczyć niczego legalnego. Nie „prawie niczego" — niczego. Pojedyncze legalne żądanie oznaczone do odrzucenia w trybie obserwacji jest gwarantowanym odrzuceniem klienta w chwili, gdy włączymy egzekwowanie, i to jest sygnał stopu. Gdy to się zdarza, nie egzekwujemy; idziemy zrozumieć, dlaczego mechanizm nie zgodził się z rzeczywistością, naprawiamy przyczynę i zaczynamy okno od nowa. Cały sens wcześniejszego obserwowania polega na przekształceniu „jesteśmy dość pewni, że to bezpieczne" w „patrzyliśmy, jak nie odrzuca ani jednego rzeczywistego klienta, przy wolumenie, przez całe okno".

Dopiero gdy wszystkie trzy są spełnione, idziemy dalej.

Pułapka: celowa odmowa jest niewidoczna dla systemu śledzenia błędów

Warto wskazać subtelny tryb awarii, ponieważ wprowadzał on w błąd staranne zespoły.

Większość monitoringu produkcyjnego jest zbudowana wokół wyjątków — kodu, który rzucił błędem, żądania, które się zawiesiło, zależności, która przekroczyła czas oczekiwania. Odrzucenie na zasadzie domyślnej odmowy nie jest żadną z tych rzeczy. Gdy mechanizm wykonuje swoje zadanie i zawraca żądanie, jest to działanie mechanizmu, a nie błąd. Nie wytwarza więc żadnego wyjątku, żadnego śladu stosu, niczego, co zwykły system śledzenia błędów mógłby wyłonić.

Konsekwencja jest sprzeczna z intuicją: po włączeniu egzekwowania twój system śledzenia błędów może być zupełnie cichy, podczas gdy mechanizm odrzuca rzeczywistych klientów. „System śledzenia błędów świeci na zielono" nie mówi ci nic o tym, czy mechanizm zawraca ruch, którego nie powinien. Cisza nie jest tutaj dowodem bezpieczeństwa — jest brakiem jednego sygnału, którego naprawdę potrzebujesz.

Dlatego mechanizm domyślnej odmowy potrzebuje własnego, wyraźnego sygnału, oddzielnego od monitoringu wyjątków: dedykowanego zapisu tego, co odrzucił i dlaczego, który operator może odczytać bezpośrednio. Bez tego lecisz na przyrządzie, który jest strukturalnie ślepy na dokładnie tę rzecz, o którą się martwisz.

Dopiero wtedy: przełączenie na egzekwowanie — z wyłącznikiem awaryjnym

Gdy trzy dowody są spełnione, a dedykowany sygnał jest na miejscu, egzekwowanie staje się małym, świadomym krokiem, a nie skokiem. Traktujemy przełączenie dokładnie jako to: świadomą decyzję, podjętą na sile dowodów z trybu obserwacji, nigdy automatyczny awans, który zdarza się tylko dlatego, że minął jakiś czas.

Utrzymujemy też odwracalność przełączenia. Mechanizm, którego egzekwowanie dopiero co rozpoczęliśmy, może zostać natychmiast przywrócony do trybu obserwacji, jeśli cokolwiek wygląda nie tak, bez ponownego wdrożenia i bez zmiany kodu. Ta odwracalność jest częścią dyscypliny, a nie czymś dodanym po fakcie: nie wdrażamy mechanizmu, którego bezpieczeństwo zależy od drzwi otwierających się tylko w jedną stronę. Możliwość natychmiastowego cofnięcia jest tym, co pozwala nam egzekwować z pewnością — i tym, co pozwala nowej postawie dojrzeć pod rzeczywistym ruchem, zanim potraktujemy ją jako trwałą.

Jak to wygląda dla regulatorów i kupujących

Zgodnie z art. 32 RODO — bezpieczeństwem przetwarzania — administrator musi wdrożyć odpowiednie środki techniczne i organizacyjne, aby chronić dane osobowe, zważone względem ryzyka dla osób, których dane dotyczą. Dostępność jest częścią tej równowagi: środek, który chroni dane, rutynowo czyniąc serwis niedostępnym dla legalnych użytkowników, nie jest sam w sobie środkiem odpowiednim.

„Najpierw obserwuj, potem egzekwuj" jest właśnie tym rodzajem środka organizacyjnego, który powstrzymuje ochronny mechanizm przed przechyleniem się w problem z dostępnością danych. Mówi w istocie: będziemy dodawać mechanizmy, które odrzucają podejrzany ruch, i udowodnimy na rzeczywistym ruchu, że nie odrzucają one ruchu legalnego, zanim pozwolimy im działać. Taki jest kształt praktyki bezpieczeństwa, na którą regulator lub audyt klienta korporacyjnego może spojrzeć i uznać ją za rozsądną — nie gwarancja, że nigdy nic się nie zdarzy, ale udokumentowana, powtarzalna metoda nieprzekształcania mechanizmu obronnego w awarię.

Czym to nie jest

• Nie magiczna siatka bezpieczeństwa. Tryb obserwacji dowodzi konkretnych niezmienników, które postanowiliśmy sprawdzić — kompletności, tego, że mechanizm się uruchamia, braku fałszywych alarmów na ruchu, który widzieliśmy. Nie może dowieść braku trybu awarii, o którym nikt nie pomyślał, by go poszukać. W miarę jak poznajemy nowe, dodajemy je do tego, co tryb obserwacji musi ustalić.
• Nie unikatowe dla HumanKey. Obserwowanie mechanizmu przed jego egzekwowaniem — uruchomienia w cieniu, tryb cienia, kanarki — to dobrze przetarta inżynieria. To, co publikujemy, to fakt, że naprawdę uzależniamy przełączenie od czystych dowodów i traktujemy „rozumowaliśmy, że będzie dobrze" jako niewystarczające. Ta dyscyplina jest częścią, którą zespoły procurementowe trudno zweryfikować z zewnątrz.
• Nie opis jakiegokolwiek konkretnego mechanizmu. Celowo utrzymaliśmy ten wpis na temat metody. Nie nazywamy konkretnego mechanizmu, który ostatnio przeprowadziliśmy przez nią, ani tego, jak ten mechanizm działa, ponieważ opublikowanie sposobu działania żywego mechanizmu bezpieczeństwa osłabiłoby go — a metoda jest i tak tym, co warte podzielenia się.

Odnośniki referencyjne

• Art. 32 RODO — Bezpieczeństwo przetwarzania (odpowiednie środki techniczne i organizacyjne, proporcjonalne do ryzyka, w tym dostępność)
• Nasza Polityka Prywatności oraz DPIA opisują kategorie danych, które przetwarzamy, i zabezpieczenia wokół nich

---

HumanKey to oparta na UE, natywnie zgodna z RODO platforma analityczna dla wydawców i serwisów e-commerce. Operatorskie wpisy transparentne obejmują wybory dotyczące zgodności i inżynierii, które kupujący B2B oceniają podczas procurement. Ten wpis odzwierciedla naszą praktykę operacyjną i nie stanowi porady prawnej.

Jeśli oceniasz HumanKey, nasza DPIA oraz pozostała dokumentacja prawna są publiczne. Aby rozpocząć bezpłatny okres próbny, instalacja fragmentu kodu zajmuje poniżej dwóch minut.