Konfigurowanie uwierzytelniania wieloczynnikowego¶
Uwierzytelnianie wieloczynnikowe (MFA) wymaga od użytkownika drugiego dowodu, obok identyfikatora i hasła. CyberElements oferuje kilka sposobów jego uzyskania. Ta strona omawia cztery z nich, w kolejności, w jakiej zwykle się je rozważa, a następnie opisuje szczegółowo ten, który nie ma własnej strony integracji: hasło jednorazowe wysyłane pocztą e-mail.
Cztery czynniki, to nie cały obraz
Te cztery omawia ta strona — nie są one jedynymi drugimi czynnikami, o które platforma może poprosić. Dostępne są również, poza zakresem tej strony:
- OTP wysyłany SMS-em, przez jednego z wielu operatorów oferowanych przez moduł OTP Token Generators;
- konektor Radius do rozwiązania MFA innej firmy, przez typ OTP - Radius tego samego modułu;
- uwierzytelnianie certyfikatem x509, które nie jest tokenem, lecz metodą uwierzytelniania samej domeny — User certificate albo User certificate and form, aby zachować również hasło;
- MFA wymuszone wcześniej przez dostawcę SAML albo przez dowolne inne uwierzytelnianie delegowane. Drugi czynnik jest wtedy wymagany, zanim platforma zostanie w to włączona, więc ani go nie konfiguruje, ani go nie widzi.
MFA ustawia się u dostawcy tożsamości, nigdy na użytkowniku
Niezależnie od wybranego czynnika włącza się go u dostawcy tożsamości i obowiązuje on każdego użytkownika, który loguje się przez tego dostawcę. Nie ma ustawienia na poziomie użytkownika: aby objąć MFA tylko część populacji, umieść tych użytkowników za dedykowanym dostawcą tożsamości.
Wybór czynnika¶
| Czynnik | Co robi użytkownik | Czego wymaga | Procedura |
|---|---|---|---|
| Neomia Pulse | Nic. Użytkownik jest rozpoznawany po sposobie pisania na klawiaturze. | Opcja Neomia Pulse, dostawca tożsamości typu local lub LDAP oraz drugi czynnik z tej tabeli u tego samego dostawcy. |
Integracja Neomia Pulse |
| FIDO2 | Przedstawia swój autentykator — podłącza klucz bezpieczeństwa albo zatwierdza na urządzeniu lub w magazynie przechowującym passkey — a następnie wprowadza PIN, jeśli autentykator o niego prosi. | Autentykator FIDO2 dla każdego użytkownika, relying party zadeklarowana w konsoli oraz konto imienne — anonimowy dostawca tożsamości jest wykluczony. | Integracja Yubico |
| TOTP | Odczytuje sześciocyfrowy kod w aplikacji uwierzytelniającej. | Aplikacja na telefonie lub stacji roboczej użytkownika (Google Authenticator, FreeOTP, Microsoft Authenticator i tym podobne) oraz jedna rejestracja na użytkownika. | Integracja Google Authenticator |
| OTP pocztą e-mail | Przepisuje kod otrzymany pocztą e-mail. | Serwer SMTP osiągalny dla platformy oraz adres e-mail przechowywany w atrybucie użytkownika. | Konfigurowanie OTP pocztą e-mail |
Neomia Pulse konfiguruje się jako uzupełnienie innego czynnika
Włączenie Neomia Pulse wymaga włączenia innego MFA na tej samej domenie. Jego ustawienia decydują następnie o tym, do czego służy ten drugi czynnik: może być pomijany, gdy Pulse potwierdzi użytkownika, i wymagany, gdy go nie potwierdzi. Neomia Pulse jest więc sposobem na oszczędzenie drugiego czynnika, a nie na jego zastąpienie.
Gdzie deklaruje się każdy czynnik i gdzie się go włącza¶
Konfiguracja ma dwa możliwe etapy — zadeklarowanie czynnika w jego module, a następnie włączenie go u dostawcy tożsamości — ale dwa z czterech pomijają jeden z nich:
| Czynnik | Deklarowany w | Włączany u dostawcy tożsamości |
|---|---|---|
| Neomia Pulse | nic do zadeklarowania | ✅ opcja Enable neomia Pulse authentication |
| FIDO2 | Relying parties | ❌ nic do włączenia — zobacz uwagę poniżej |
| TOTP | OTP Token Generators | ✅ jako token uwierzytelniania |
| OTP pocztą e-mail | serwer SMTP, a następnie OTP Token Generators | ✅ jako token uwierzytelniania |
FIDO2 nie ma przełącznika u dostawcy tożsamości
Kluczy bezpieczeństwa nie włącza się dostawca po dostawcy: platforma oferuje ten czynnik, gdy tylko zadeklarowana jest co najmniej jedna relying party, u każdego dostawcy tożsamości, który nie jest anonimowy — klucz musi być powiązany z kontem imiennym. I to użytkownik rejestruje swój autentykator z poziomu portalu, a nie administrator, który by go przypisywał.
W przypadku Neomia Pulse nie trzeba niczego wcześniej deklarować
Pulse nie jest tokenem, który tworzy się w module: opcję włącza się bezpośrednio u dostawcy tożsamości, tam też ustawia się jej zachowanie.
Pozostała część tej strony omawia OTP pocztą e-mail od początku do końca. Trzy pozostałe czynniki opisują ich strony integracji, do których odsyła powyższa tabela.
Konfigurowanie OTP pocztą e-mail¶
OTP pocztą e-mail wysyła użytkownikowi jednorazowy kod e-mailem, gdy jego identyfikator i hasło zostaną przyjęte. Użytkownik wprowadza ten kod na portalu, aby dokończyć logowanie.
Zanim zaczniesz: co naprawdę chroni OTP pocztą e-mail¶
OTP pocztą e-mail nie zawsze dodaje czynnik
Przeczytaj to, zanim wybierzesz ten czynnik zamiast trzech pozostałych.
Jeśli użytkownik loguje się swoim kontem Active Directory i odbiera kod ze skrzynki pocztowej powiązanej z tym samym kontem, drugi czynnik niemal nic nie wnosi: atakujący, który zdobył dane logowania, otwiera tymi samymi danymi skrzynkę i odczytuje kod.
OTP pocztą e-mail warto wdrożyć wtedy, gdy skrzynka nie jest osiągalna przy użyciu sprawdzanych danych logowania, czyli gdy:
- użytkownik loguje się kontem lokalnym albo kontem odrębnym od jego skrzynki;
- kod jest wysyłany na adres inny niż adres należący do konta logowania.
Krok 1 — Zapewnienie dostępnego serwera SMTP¶
Kod jest wysyłany przez platformę za pośrednictwem serwera SMTP zadeklarowanego w module SMTP servers. Jeśli żaden nie jest jeszcze dostępny, zadeklaruj go, zanim pójdziesz dalej:
Konfigurowanie wysyłki wiadomości e-mail
Następnie użyj bloku SMTP configuration test tego modułu, aby potwierdzić dostarczenie: niepowodzenie zdiagnozowane na tym etapie to niepowodzenie, którego nie będziesz szukać później w przebiegu logowania.
Wiadomość testowa nie używa nadawcy, którego skonfigurujesz
Test wysyła z adresu noreply@cleanroom.com, ustalonego przez produkt: nie można go nigdzie zmienić i służy on również jako adres odpowiedzi. Twój własny nadawca to pole SMTP sender tokena, ustawiane w kroku 2 — to on widnieje w prawdziwych wiadomościach z OTP.
Warto znać tego konsekwencję, zanim wyciągniesz wnioski: serwer SMTP ograniczający adresy nadawców może odrzucić test, przepuszczając jednocześnie prawdziwe wiadomości — i odwrotnie.
Połączenie otwiera platforma
Przepływ do serwera SMTP wychodzi z platformy, a nie ze stacji roboczej użytkownika. Jeśli twój serwer SMTP znajduje się w twojej sieci LAN, ten przepływ musi być dozwolony.
Krok 2 — Utworzenie tokena OTP¶
Otwórz moduł OTP Token Generators i kliknij +. W oknie Add OTP token wybierz typ OTP - email, a następnie wypełnij pola.
| Pole | Co wprowadzić |
|---|---|
| OTP Type | OTP - email. Tego wyboru nie da się później zmienić — inny kanał oznacza inny token. |
| Name | Nazwa tokena. Jest pokazywana użytkownikowi na portalu, powinna więc brzmieć jak nazwa czynnika, a nie jak wewnętrzne oznaczenie. |
| Description | Dowolny tekst, widoczny tylko dla administratorów. |
| OTP usable characters | Alfabet, z którego losowany jest kod. |
| OTP Length | Liczba znaków kodu. |
| Validity period of a token (seconds) | Ile czasu ma użytkownik na wpisanie kodu, zanim zostanie on odrzucony. |
| Message before the OTP | Zdanie poprzedzające kod w treści wiadomości. |
| Mail subject | Temat wiadomości. |
| SMTP sender | Adres nadawcy wiadomości. |
| SMTP server | Serwer zadeklarowany w kroku 1. |
Pełna lista pól, z ich wartościami domyślnymi i ograniczeniami, znajduje się na stronie referencyjnej: Blok generyczny i Dostarczanie pocztą e-mail.
Kliknij Validate, aby zapisać token.
Krok 3 — Włączenie tokena u dostawcy tożsamości¶
Otwórz moduł Identity Providers i edytuj dostawcę, który ma wymagać OTP.
| Pole | Co wprowadzić |
|---|---|
| Authentication token | Token utworzony w kroku 2. Można wybrać kilka tokenów. |
| User attribute used to send the OTP | Nazwa atrybutu użytkownika przechowującego adres, na który wysyłany jest kod. |
| Token expiration duration | Jak długo zweryfikowany OTP pozostaje przyjmowany, zanim zostanie zażądany ponownie. 0 wyłącza wygasanie, co oznacza, że OTP jest wymagany przy każdym logowaniu. |
| Time unit | Hours albo Days, stosowana do poprzedniego pola. |
| Expiration starts | Czy odliczanie zaczyna się od ostatniej weryfikacji OTP, czy od ostatniego udanego logowania. |
Który atrybut przechowuje adres
Chodzi o atrybut katalogu, na który wskazuje dostawca tożsamości, a nie o nazwę z naszego wyboru: użyj atrybutu, w którym twoi użytkownicy rzeczywiście mają adres. W katalogu lokalnym celem jest adres wpisany we właściwościach użytkownika; w katalogu LDAP — własny atrybut pocztowy katalogu.
Kliknij Validate. Użytkownicy tego dostawcy tożsamości zostaną poproszeni o kod przy następnym logowaniu.
Krok 4 — Najpierw sprawdź na testowym dostawcy tożsamości¶
Włączenie MFA u dostawcy tożsamości obejmuje każdego użytkownika, który za nim stoi, w tym ciebie, jeśli logujesz się przez niego. Zanim włączysz token u dostawcy produkcyjnego, utwórz testowego dostawcę tożsamości z jednym kontem i wykonaj przez niego pełne logowanie: identyfikator, hasło, odebranie wiadomości, wpisanie kodu.
Użytkownik bez adresu nigdy nie otrzyma kodu
Użytkownikowi, którego atrybut jest pusty, nie da się niczego wysłać, a jego logowanie nie może się zakończyć. Sprawdź, czy atrybut jest wypełniony dla każdego konta stojącego za dostawcą tożsamości, zanim włączysz na nim token.