Konfigurowanie uwierzytelniania wieloczynnikowego¶
Uwierzytelnianie wieloczynnikowe (MFA) wymaga od użytkownika drugiego dowodu, obok identyfikatora i hasła. CyberElements Bastion 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ę na domenie uwierzytelniania, nigdy na użytkowniku
Niezależnie od wybranego czynnika włącza się go na domenie uwierzytelniania i obowiązuje on każdego użytkownika, który loguje się przez tę domenę. Nie ma ustawienia na poziomie użytkownika: aby objąć MFA tylko część populacji, umieść tych użytkowników za dedykowaną domeną uwierzytelniania.
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, ustawienia połączenia z twoją usługą Pulse, domena uwierzytelniania typu local lub LDAP oraz drugi czynnik z tej tabeli na tej samej domenie. |
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 — anonimowa domena uwierzytelniania jest wykluczona. | 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 na domenie uwierzytelniania — ale dwa z czterech pomijają jeden z nich:
| Czynnik | Deklarowany w | Włączany na domenie uwierzytelniania |
|---|---|---|
| Neomia Pulse | nic do zadeklarowania | ✅ opcja Enable neomia Pulse authentication, a do tego ustawienia połączenia z usługą Pulse — zobacz uwagę poniżej |
| 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 na domenie uwierzytelniania
Kluczy bezpieczeństwa nie włącza się dostawca po dostawcy: platforma oferuje ten czynnik, gdy tylko zadeklarowana jest co najmniej jedna relying party, na każdej domenie uwierzytelniania, która nie jest anonimowa — 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 na domenie uwierzytelniania, tam też ustawia się jej zachowanie.
Pulse potrzebuje ustawień połączenia
Zaznaczenie Enable neomia Pulse authentication odsłania trzy obowiązkowe pola, które wskazują platformie twoją usługę Pulse:
| Pole | Co wprowadzić |
|---|---|
| API URL | URL API Pulse. |
| Authentication API URL | URL API uwierzytelniania Pulse. |
| API key | Klucz uwierzytelniający platformę wobec tej usługi. |
Domena uwierzytelniania nie zostanie zapisana, dopóki wszystkie trzy nie zostaną wypełnione.
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 na domenie uwierzytelniania¶
Otwórz moduł Authentication domain i edytuj domenę, która 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 domena uwierzytelniania, 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 tej domeny uwierzytelniania zostaną poproszeni o kod przy następnym logowaniu.
Krok 4 — Najpierw sprawdź na testowej domenie uwierzytelniania¶
Włączenie MFA na domenie uwierzytelniania obejmuje każdego użytkownika, który za nią stoi, w tym ciebie, jeśli logujesz się przez nią. Zanim włączysz token na domenie produkcyjnej, utwórz testową domenę uwierzytelniania z jednym kontem i wykonaj przez nią 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 domeną uwierzytelniania, zanim włączysz na niej token.