Uwierzytelnianie i bezpieczeństwo, w tym SSO

Fabrycznie każdy loguje się nazwą użytkownika i hasłem. Zamiast nazwy użytkownika działa adres e-mail. Jeśli wysyłka poczty jest ustawiona, pod formularzem pojawia się odnośnik „Do you need a password reset?”. Wysyłka poczty należy do Professional.

Po zalogowaniu przeglądarka dostaje przepustkę ważną przez ustalony czas. Karta „JWT token timer” decyduje, jak długo. Dopuszczalne są wartości od 1 do 24 godzin, zalecane jest 12. Potem trzeba zalogować się ponownie.

Karta „Password policy” dotyczy każdego hasła ustawianego w systemie. Obowiązuje przy zakładaniu konta, przy zmianie własnego hasła i przy resecie wykonanym przez administratora.

Ustawiasz minimalną długość, rodzaje znaków, które muszą wystąpić, po ilu dniach hasło wygasa i ile starych haseł pozostaje zablokowanych. Przy dniach i przy liście blokad 0 znaczy „wyłączone”.

Zasady o wielkich i małych literach nie wykluczają żadnego języka. Wiele systemów pisma nie zna takiego rozróżnienia, a znak z takiego systemu sam spełnia obie zasady.

Konta logujące się wyłącznie przez SSO albo katalog nie mają lokalnego hasła, więc wygasanie ich nie dotyczy. Ich zasady mieszkają u dostawcy. Jeśli istniejące konto połączono z SSO i nadal ma ono własne hasło, wygasanie i zasady haseł nadal dotyczą tego hasła.

Karta „2FA Settings” określa, kto musi używać logowania dwuskładnikowego. W „Two-factor requirement” wybierasz jeden z czterech poziomów: „Off”, „Administrators only”, „Administrators and agents” albo „Everyone”. „Everyone” obejmuje też klientów. Nowa instalacja zaczyna od „Administrators only”. Instalacja, która istniała już wcześniej, zachowuje po aktualizacji swoje dotychczasowe ustawienie.

Kto zaloguje się jako następny bez drugiego składnika, zakłada go. System pokazuje kod QR do aplikacji uwierzytelniającej i ten sam klucz do wpisania ręcznie. Po pierwszym kodzie składnik jest aktywny. Przyciskiem „Set up later” można odłożyć konfigurację, a logowanie przebiega dalej bez niej. Działa to najwyżej przez 7 dni, licząc od pierwszego odłożenia. Wiersz pod przyciskiem pokazuje pozostałe dni. Potem konfiguracja jest obowiązkowa.

Zaraz potem pojawia się dziesięć kodów zapasowych. Każdy z nich zastępuje jeden raz kod z aplikacji. Pokazują się dokładnie raz. Zapisujesz je przyciskiem „Copy” albo „Download”. „Download” działa zawsze. „Copy” zwykle też działa.

Jeśli ktoś zgubi urządzenie i kody, pomaga administrator. Na liście użytkowników przycisk z przekreśloną tarczą resetuje logowanie dwuskładnikowe tej osoby. Zakłada je ona ponownie przy następnym logowaniu.

Kody zależą od zegara serwera. Jeśli jest źle ustawiony, żaden kod nie zostanie przyjęty. Przycisk „Check now” na tej samej karcie porównuje czas serwera z publicznym źródłem czasu.

Jeśli ktoś loguje się przez zewnętrzną usługę logowania, system nie pyta o kod. Dostawca sprawdził już drugi składnik. Logowanie przez katalog jest inne: tam nadal obowiązuje zasada powyżej.

Każdy użytkownik może włączyć logowanie dwuskładnikowe dla własnego konta. Dotyczy to każdej roli, także wtedy, gdy karta „2FA Settings” go nie wymaga. Otwórz menu użytkownika na dole po lewej stronie paska bocznego i wybierz „Profile picture”. Ta sama strona zawiera obszar „Two-factor authentication”.

Obszar pokazuje, czy logowanie dwuskładnikowe jest włączone. Dopóki jest wyłączone, jest tam przycisk „Turn on”. Najpierw prosi on o Twoje hasło. Potem pojawia się kod QR do aplikacji uwierzytelniającej i ten sam klucz do wpisania ręcznie. Po pierwszym kodzie z aplikacji składnik jest aktywny.

Zaraz potem pojawia się dziesięć kodów zapasowych. Zapisz je przyciskiem „Copy” albo „Download”. „I have saved my codes” zamyka listę. Pokazuje się ona tylko ten jeden raz.

Dopóki logowanie dwuskładnikowe jest włączone, obszar pokazuje, ile kodów zapasowych zostało. „New recovery codes” tworzy dziesięć nowych. Stare kody przestają wtedy działać. „Turn off” znowu wyłącza logowanie dwuskładnikowe. Oba przyciski wymagają aktualnego kodu z aplikacji. Kod zapasowy nie jest tam przyjmowany.

Jeśli karta „2FA Settings” wymaga logowania dwuskładnikowego dla Twojej roli, brakuje „Turn off”. Mówi o tym wiersz w obszarze.

Błędne hasło albo błędny kod liczy się jak nieudane logowanie. Ochrona przed zgadywaniem haseł działa więc także tutaj. Włączenie i wyłączenie trafia do dziennika bezpieczeństwa. Jeśli administrator wyłączy własne logowanie dwuskładnikowe, dziennik zgłasza alarm.

Konta, które logują się tylko przez zewnętrzną usługę logowania, widzą zdanie zamiast przycisków. Drugim składnikiem zajmuje się ich dostawca. Konta z katalogu wpisują w pierwszym kroku swoje hasło z katalogu.

Ochrona działa bez żadnego ustawienia. Nie ma czego włączać. Informacja o niej stoi na karcie „2FA Settings”.

Działa w dwóch stopniach. Po pięciu nieudanych próbach dla tego samego konta adres, z którego przyszły, zostaje wstrzymany. Wstrzymanie kończy się najpóźniej 15 minut po pierwszej z tych prób. Z każdego innego adresu konto pozostaje od razu użyteczne.

To jest ważna część. Inaczej każdy, kto zna nazwę logowania, mógłby zamknąć koledze drogę pięcioma błędnymi hasłami. Nie potrzebowałby do tego żadnego hasła.

Drugi stopień to samo konto. Zostaje zablokowane na 15 minut po 20 nieudanych próbach. Ponieważ jeden adres może dorzucić najwyżej pięć z nich, potrzeba do tego kilku adresów.

Udane logowanie zeruje oba liczniki. Po ponownym uruchomieniu serwera wstrzymanie adresu znika, a blokada konta zostaje. Te same liczniki obowiązują przy logowaniu przez katalog. Nieosiągalny katalog nie liczy się jako nieudana próba. Jeśli dla danej nazwy nie ma jeszcze konta w systemie zgłoszeń, obowiązuje tylko wstrzymanie adresu.

Na liście użytkowników konto zablokowane w ten sposób nosi etykietę „temporarily locked”. Zostaje na liście. Po 15 minutach etykieta znika sama.

Nie musisz czekać. W tym samym wierszu jest przycisk z otwartą kłódką. Zdejmuje blokadę natychmiast i zeruje oba liczniki.

To nie jest to samo co „Archive”. Tamten przycisk wyłącza konto na dobre i tylko on zajmuje albo zwalnia stanowisko wewnętrzne.

Dziennik bezpieczeństwa rejestruje dwa rodzaje zdarzeń. Obszar „Sign-in” zawiera nieudane logowania, zablokowane konta, próby logowania w czasie blokady, odrzucone kody dwuskładnikowe i zmiany haseł. Dotyczy to logowania hasłem, przez katalog i przez SSO.

Obszar „Administration” pokazuje, kto co zmienił. Obejmuje to konta, role, uprawnienia, ustawienia bezpieczeństwa i archiwa. Każdy eksport dziennika też jest tam zapisywany.

Udane logowania są rejestrowane tylko w dwóch przypadkach. Pierwszy przypadek to administrator. Drugi przypadek to logowanie po nieudanych próbach na tym samym koncie. Zwykłe logowanie agenta lub klienta nie trafia do dziennika. Dziennik nie jest listą obecności.

Jeśli ktoś loguje się nazwą, która nie istnieje, we wpisie widnieje „unknown account”. System nie zapisuje wpisanej nazwy. Czasem jest to hasło, które trafiło do złego pola.

Zdarzenia logowania zapisują adres IP i przeglądarkę. Działania administracyjne zapisują, kto je wykonał, ale bez adresu IP. Hasła, kody i treść zgłoszeń lub e-maili nigdy nie trafiają do dziennika.

Strona pokazuje najpierw najnowsze wpisy, po 50 na stronę. Karta „Filters” zawęża listę. „Area” wybiera logowania lub administrację, „Event” jeden rodzaj zdarzenia. „Person” szuka w nazwisku osoby, która działała, i osoby, której to dotyczyło. „From” i „To” ograniczają dni. „Failures only” ukrywa wszystko, co się udało.

Filtry działają dopiero po kliknięciu „Apply”. „Reset” ponownie je usuwa.

„Export CSV” i „Export PDF” pobierają dokładnie to, co pokazują filtry. Każdy plik zawiera najwyżej 10 000 wpisów. Jeśli do filtrów pasuje więcej wpisów, informuje o tym uwaga przy przyciskach eksportu. PDF jest w twoim języku i podaje na górze filtry i okres. Data i godzina mają format ustawiony w „Settings → General Settings”.

Plik CSV jest zawsze po angielsku, a czasy są w UTC. Dzięki temu program może go odczytać niezależnie od języka. Każdy eksport sam trafia do dziennika jako „Security log exported”.

Sześć zdarzeń wywołuje alarm. Są to konto zablokowane po nieudanych próbach, rola zmieniona na „Admin”, konto założone od razu z rolą „Admin” i zresetowane logowanie dwuskładnikowe administratora. Do tego dochodzą zarchiwizowane zgłoszenia usunięte z bieżących danych oraz logowanie administratora po nieudanych próbach.

Po alarmie każdy, kto ma to uprawnienie, widzi żółty baner u góry każdej strony. Podaje on liczbę alarmów od ostatniej wizyty w dzienniku. Link „Open security log” prowadzi do niego. Po otwarciu dziennika baner znika. Przed pierwszą wizytą liczy alarmy z ostatnich siedmiu dni.

Dodatkowo każde aktywne konto z tym uprawnieniem i adresem e-mail dostaje e-mail z alarmem. System zbiera alarmy co 15 minut i wysyła jeden e-mail na osobę, a nie jeden na zdarzenie. E-mail podaje zdarzenie, osobę, której dotyczy, i czas. Nie zawiera adresu IP. E-mail z alarmem należy do wersji Professional.

Nocny przebieg usuwa stare wpisy. Terminy są w „Settings → Security”, w karcie „Data protection”, w bloku „Security log retention”. Zdarzenia logowania są domyślnie przechowywane 90 dni, dozwolone jest od 7 do 365 dni. Działania administracyjne są domyślnie przechowywane 12 miesięcy, dozwolone jest od 1 do 120 miesięcy.

Każdy termin ma własny przełącznik: „Delete old sign-in events” i „Delete old administrator actions”. Jeśli przełącznik jest wyłączony, te wpisy pozostają. Karta „Okresy przechowywania” wyjaśnia nocny przebieg.

Przy żądaniu dostępu do danych osoba dostaje każdy wpis, w którym działała lub którego dotyczyła. Adres IP i przeglądarka są dołączane tylko do wpisów, które sama wywołała, na przykład do własnego logowania. Jeśli osoba zostanie zanonimizowana, system usuwa jej zdarzenia logowania. Jej działania administracyjne pozostają. Jej nazwisko jest tam zastępowane symbolem zastępczym.

Uwaga dla ciebie jako operatora: udane logowania są w dzienniku tylko dla administratorów i po nieudanych próbach. Dziennik i tak pokazuje, kto co i kiedy zrobił. W firmie z radą pracowników jest to więc temat współdecydowania.

Na samej górze stoi przełącznik główny „Enable single sign-on”. Dopóki jest wyłączony, zostaje logowanie nazwą użytkownika i hasłem. Wszystko, co ustawisz pod nim, zostaje zapisane i zaczyna działać dopiero po jego włączeniu.

Karta „Active Directory / LDAP” podłącza katalog we własnej serwerowni. Podajesz serwer, bazę wyszukiwania, filtr znajdujący osobę oraz pola z adresem e-mail i nazwiskami.

Konto używane do wyszukiwania jest opcjonalne. Bez niego system pyta anonimowo. Hasło osoby służy tylko do połączenia z katalogiem i nigdy nie jest zapisywane.

Katalog nie przynosi własnego drugiego składnika. Jeśli strona bezpieczeństwa wymaga logowania dwuskładnikowego, te osoby też są o nie pytane.

Karta „Identity providers” zawiera zewnętrzne usługi logowania. Każda dostaje własny kafelek i własny przycisk na stronie logowania. „Add provider” tworzy nową.

Pod „Provider type” wybierasz rodzaj. „Generic OIDC Provider” pasuje do usług takich jak Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 albo Ping Identity. „SAML 2.0 Provider” pasuje do tych samych firm, gdy mają być podłączone przez SAML.

Obok nich jest sześć usług regionalnych: LINE, Kakao, Naver, WeChat, WeCom i DingTalk. Ich adresy są wypełnione z góry i widać je w polu jako szary tekst.

Nazwa z pola „Display name” pojawia się potem na przycisku. Przełącznik obok dotyczy tylko tego jednego dostawcy.

Przy adresie powrotnym pracuj w tej kolejności. Najpierw wpisz samą nazwę i kliknij „Save provider”. Dopiero wtedy system zna numer dostawcy i pokazuje gotowy adres pod „Redirect URI”. Powstaje on z publicznego adresu tej instalacji, tego zapisanego pod „Settings → Security”. To dokładnie ten adres, którego system używa, gdy ktoś się loguje.

Ten adres kopiujesz i rejestrujesz u dostawcy. Musi się tam zgadzać co do znaku. W zamian dostawca daje Ci identyfikator i sekret, a Ty wpisujesz je tutaj przez „Edit”.

Pole „Allowed e-mail domains” ogranicza, kto może wejść przez tego dostawcę. Puste dopuszcza każdą domenę.

Jeśli dostawcy czegoś jeszcze brakuje, jego kafelek nosi czerwoną etykietę „Incomplete”. Nie pojawia się wtedy na stronie logowania. Tekst obok mówi, jakich pól potrzebuje jego rodzaj.

W pełni skonfigurowani dostawcy i tak się nie pojawiają, dopóki przełącznik główny jest wyłączony. Kafelek mówi o tym w żółtym wierszu.

Jeśli Twoja licencja spadnie z powrotem do Basic, logowanie przez SSO i katalog działa dalej. Na tej stronie możesz wtedy tylko wyłączać dostawców i katalog. Dziennik prób logowania pozostaje czytelny.

Przełącznik „Automatically create accounts on first sign-in” stoi na tej samej karcie co przełącznik główny. Domyślnie jest włączony.

Kiedy ktoś loguje się przez dostawcę po raz pierwszy, system najpierw szuka konta, które już należy do tego dostawcy. Jeśli żadnego nie znajdzie, zakłada nowe.

Nowe konto dostaje rolę „Customer” i żadnego zespołu. Klient nie potrzebuje przynależności, żeby utworzyć zgłoszenie, więc może pracować od razu.

Klientów jest bez ograniczeń w obu edycjach, więc tak założone konto nie zajmuje stanowiska wewnętrznego. Kto ma zostać agentem, dostaje tę rolę potem w zarządzaniu użytkownikami.

Jeśli konto z tym samym adresem e-mail już istnieje, oba zostają połączone. Dzieje się to tylko wtedy, gdy dostawca zgłasza adres jako zweryfikowany. Jeśli tego nie robi, logowanie zostaje odrzucone.

Jeśli wyłączysz ten przełącznik, wchodzą tylko osoby, które mają już konto. Wszystkie inne są odprawiane.

Karta „Recent sign-in attempts” na samym dole pokazuje ostatnie 100 zdarzeń logowania przez SSO i katalog. Pochodzą z dziennika bezpieczeństwa. Nieudane próby są w niej zawsze. Udane logowanie jest w niej tylko dla administratorów i po nieudanych próbach na tym samym koncie. Dlatego nie każde logowanie jest na liście.

Każdy wiersz nazywa czas, dostawcę, wynik i adres źródłowy. Przy nieudanej próbie stoi obok powód. Kolumna „User” pokazuje nazwę konta. Jeśli nie ma konta, pokazuje adres podany przez dostawcę, a w przeciwnym razie „unknown account”. System nie zapisuje wpisanej nazwy.

Logowanie nazwą użytkownika i hasłem nie pojawia się w tej tabeli. To nie jest SSO. Znajdziesz je w dzienniku bezpieczeństwa.

W ustawieniu fabrycznym wpisy są usuwane po 90 dniach. Zdanie pod tytułem karty podaje ustawiony termin. Ustawienie wyjaśnia karta „Okresy przechowywania”.

Po instalacji Twój zespół korzysta z systemu w każdej przeglądarce internetowej. Instalator pyta, jak system ma być dostępny. W instalatorze dla Windows wybierasz to na stronie „Dostępność”. W Linuksie install.sh zadaje to samo pytanie i numeruje opcje od 1 do 5. Później zmieniasz to przez „Zmień sposób dostępu do SMITEY”. Twoje dane zostają tam, gdzie są.

Opcja „Tylko sieć lokalna, przez adres IP (HTTP) - najprostsza opcja” jest ustawieniem domyślnym. Twój zespół otwiera system pod http:// z adresem IP serwera i portem, na przykład http://192.168.1.20:8088. Port to 8088, chyba że wybierzesz inny. Port 80 też działa. Wtedy adres nie potrzebuje portu. Ta opcja nie potrzebuje nazwy ani certyfikatu.

Opcja „W sieci lokalnej pod własną nazwą (HTTP, HTTPS możliwy później) - masz wewnętrzny DNS” działa jak pierwsza, ale pod nazwą w rodzaju ticket.company.local. Nazwę tworzysz sam w swoim wewnętrznym DNS. Wskazuje ona na adres IP serwera. Wtedy Twój zespół dociera do systemu przez nazwę i nadal przez adres IP. Instalator pokazuje potem adres z tą nazwą.

W obu opcjach HTTP hasła i zgłoszenia idą przez Twoją sieć otwartym tekstem. Administratorzy widzą wtedy komunikat u góry strony.

Pozostałe trzy opcje używają HTTPS: „Przez domenę publiczną z HTTPS (automatycznie, przy użyciu Let's Encrypt)”, „W sieci lokalnej z HTTPS i własnym certyfikatem” i „W sieci lokalnej z HTTPS, certyfikat tworzy SMITEY”. Potrzebują na serwerze portów 80 i 443. Opisuje je następna karta.

Na pierwszy test wystarczy pierwsza opcja. Jeśli Twoja sieć ma wewnętrzny DNS, wybierz drugą. Jeśli system ma być osiągalny z internetu, wybierz domenę publiczną. Jeśli Twoja firma ma własny urząd certyfikacji, wybierz własny certyfikat w sieci lokalnej. W przeciwnym razie pozwól SMITEY utworzyć certyfikat.

Bez HTTPS hasła i zgłoszenia idą przez Twoją sieć otwartym tekstem. Nowa instalacja zaczyna od zwykłego HTTP, żeby od razu działała w dowolnej przeglądarce internetowej. Dopóki administrator otwiera system przez zwykły HTTP, u góry strony pojawia się komunikat: „This connection is not encrypted.” Jeśli system jest otwarty na samym serwerze jako „localhost”, komunikat się nie pojawia. Agenci i klienci nigdy go nie widzą.

„How to switch on HTTPS” prowadzi do tej karty. „Hide for 30 days” ukrywa komunikat dla Ciebie. Ustawienie należy do Twojego konta, więc działa też w innej przeglądarce. Po 30 dniach komunikat wraca, dopóki połączenie nadal nie jest szyfrowane.

Instalator SMITEY konfiguruje HTTPS na trzy sposoby. W instalatorze dla Windows wybierasz go na stronie „Dostępność”, a w Linuksie install.sh zadaje to samo pytanie. W systemie, który już działa, otwórz „Zmień sposób dostępu do SMITEY” na pulpicie Windows albo w menu Start. W Linuksie to samo robi polecenie poniżej. Twoje dane zostają tam, gdzie są.

Opcja „W sieci lokalnej z HTTPS i własnym certyfikatem” używa Twojego własnego certyfikatu, na przykład z firmowego urzędu certyfikacji. Instalator pyta o nazwę systemu i plik certyfikatu z jego kluczem. Plik PFX z hasłem też się nada. Zanim cokolwiek zmieni, sprawdza certyfikat. Klucz musi pasować, certyfikat musi być ważny, a nazwa musi być w certyfikacie.

Opcja „W sieci lokalnej z HTTPS, certyfikat tworzy SMITEY” nie potrzebuje własnego certyfikatu. SMITEY tworzy go sam i sam go odnawia. Instalator zapisuje certyfikat główny jako SMITEY-root-ca.crt w folderze instalacji. Zainstaluj ten plik na każdym komputerze jako zaufany certyfikat główny, na przykład przez zasady grupy. Do tego czasu przeglądarki pokazują ostrzeżenie.

Opcja „Przez domenę publiczną z HTTPS (automatycznie, przy użyciu Let's Encrypt)” pobiera swój certyfikat z Let’s Encrypt. Potrzebuje publicznej domeny, która wskazuje na serwer. Serwer musi więc być osiągalny z internetu.

W obu opcjach dla sieci lokalnej nazwą może być nazwa w rodzaju ticket.company.local, jedno słowo jak helpdesk albo adres IPv4. Wszystkie trzy drogi potrzebują na serwerze portów 80 i 443. Jeśli używa ich inny program, instalator przerywa i niczego nie zmienia. System jest potem dostępny pod https:// i nazwą, bez portu.

Twój własny certyfikat kiedyś wygasa. Od 30 dni przed terminem administratorzy widzą u góry strony komunikat z datą. Od 7 dni przed jest on czerwony. W wersji Professional wszyscy administratorzy z adresem e-mail dostają dodatkowo wiadomość 30 i 7 dni wcześniej. Aby go odnowić, otwórz ponownie „Zmień sposób dostępu do SMITEY”, wybierz opcję z własnym certyfikatem i podaj nowe pliki.

Plik HTTPS-GUIDE.txt dołączony do instalacji opisuje każdy krok. Należy do tego rozdanie certyfikatu głównego i kroki wykonywane ręcznie.