Bezpieczeństwo
Tworzenie własnych reguł dostępu według IP, domeny i kraju oraz obserwowanie ich w trybie dry-run.
Strona „Reguły dostępu: zarządzanie IP, domenami i krajami“ omawia obszar funkcjonalny wskazany w URL. Istniejące treści są uzupełniane o rzeczywisty przebieg, wymagania wstępne i znane ograniczenia. Nowe reguły dotyczące IP, domen lub krajów zawsze startują w trybie Dry-Run. Reguła w bazie danych wymusza czas oczekiwania co najmniej 24 godzin przed aktywacją. Jeśli jednocześnie działają reguła Allow i reguła Block, pierwszeństwo ma Allow.
Reguły dostępu mogą dotyczyć adresów IP, domen lub krajów. Każda nowa reguła obowiązkowo startuje w trybie Dry-Run. Dopiero po upływie co najmniej 24 godzin można ją aktywować; ten czas oczekiwania jest zaimplementowany jako ograniczenie bazy danych, a nie tylko jako wskazówka w interfejsie.
Podczas Dry-Runu obserwuje się, których dostępów dotyczyłaby reguła. Pozwala to wykryć błędną konfigurację, zanim zostaną zablokowani prawdziwi użytkownicy. Reguły Allow mają pierwszeństwo przed regułami Block. Jeśli działa kilka reguł, należy sprawdzić całą ich kombinację, a nie tylko ostatnio dodany wpis.
Przed aktywacją administrator powinien zabezpieczyć własny dostęp oraz niezbędny dostęp usług. Zbyt szeroko zdefiniowana blokada krajów lub adresów IP może wykluczyć uprawnione osoby. Zmiany należy wprowadzać pojedynczo, a następnie kontrolować na podstawie protokołów.
Jeśli oczekiwana blokada nie działa, należy zweryfikować status, koniec 24-godzinnego okresu oraz ewentualne wyjątki Allow. W przypadku nieoczekiwanej blokady potrzebne są typ reguły, wartość, czas aktywacji i dotknięty dostęp. Nie wolno przy tym przekazywać sekretów ani pełnych danych osobowych z logów.
W odniesieniu do strony „Reguły dostępu: zarządzanie IP, domenami i krajami“ oznacza to: istniejący krótki tekst zostaje rozszerzony do rzetelnej instrukcji, bez obiecywania możliwości wykraczających poza potwierdzony stan produktu. Wiążące pozostają zweryfikowane źródła faktów oraz widoczny podział odpowiedzialności między tenantem a Zentor. W razie odstępstw należy zawsze podać dokładnie ten URL, dotkniętego klienta i obserwowany krok.
Przy pracy z „bezpieczeństwo“ każdy krok należy najpierw sprawdzić na kontrolowanym przypadku testowym. Kluczowe jest, aby widoczne ustawienie, rzeczywisty stan systemu i oczekiwany wynik były ze sobą zgodne. W razie odstępstw w analizie pomagają dokładna godzina, dotknięty klient, użyty kanał oraz niezmieniony komunikat o błędzie. Dane dostępowe, tokeny i dane osobowe nie mogą przy tym trafiać do zrzutów ekranu ani tekstów dla wsparcia.