Nastavitev večkratnega preverjanja pristnosti¶
Večfaktorsko preverjanje pristnosti (MFA) od uporabnika poleg identifikatorja in gesla zahteva še drugi dokaz. CyberElements Bastion ponuja več načinov za njegovo pridobitev. Ta stran obravnava štiri od njih v vrstnem redu, v katerem jih običajno preučimo, nato pa podrobno opiše tistega, ki nima lastne strani o integraciji: enkratno geslo, poslano po e-pošti.
Štirje dejavniki, ne celotna slika
Te štiri obravnava ta stran — niso edini drugi dejavniki, ki jih platforma lahko zahteva. Na voljo so tudi naslednji, ki presegajo obseg te strani:
- OTP, poslan po SMS-u, prek enega od številnih operaterjev, ki jih ponuja modul OTP Token Generators;
- povezovalnik Radius do rešitve MFA drugega ponudnika, prek vrste OTP - Radius istega modula;
- preverjanje pristnosti s potrdilom x509, ki ni token, temveč način preverjanja pristnosti same domene — User certificate ali User certificate and form, če želite ohraniti tudi geslo;
- MFA, ki ga na vhodni strani vsili ponudnik SAML, ali katero koli drugo delegirano preverjanje pristnosti. Drugi dejavnik se tedaj zahteva, preden je vključena platforma, ki ga ne konfigurira in ga ne vidi.
MFA se nastavi na domeni za preverjanje pristnosti, nikoli na uporabniku
Ne glede na izbrani dejavnik se ta omogoči na domeni za preverjanje pristnosti in velja za vsakega uporabnika, ki se prijavi prek nje. Nastavitve za posameznega uporabnika ni: če želite z MFA zajeti le del uporabnikov, jih postavite za namensko domeno za preverjanje pristnosti.
Izbira dejavnika¶
| Dejavnik | Kaj stori uporabnik | Kaj zahteva | Postopek |
|---|---|---|---|
| Neomia Pulse | Nič. Uporabnik je prepoznan po načinu tipkanja na tipkovnici. | Možnost Neomia Pulse, nastavitve povezave z vašo storitvijo Pulse, domena za preverjanje pristnosti vrste local ali LDAP in drugi dejavnik iz te tabele v isti domeni. |
Integracija Neomia Pulse |
| FIDO2 | Predloži svoj preverjevalnik — priključi varnostni ključ ali potrdi v napravi ali trezorju, ki hrani ključ za dostop — nato vnese PIN, če ga preverjevalnik zahteva. | Preverjevalnik FIDO2 za vsakega uporabnika, relying party, deklariran v konzoli, in osebni račun — anonimna domena za preverjanje pristnosti je izključena. | Integracija Yubico |
| TOTP | Prebere šestmestno kodo v aplikaciji za preverjanje pristnosti. | Aplikacija v telefonu ali na delovni postaji uporabnika (Google Authenticator, FreeOTP, Microsoft Authenticator itd.) in ena registracija na uporabnika. | Integracija Google Authenticator |
| OTP po e-pošti | Prepiše kodo, prejeto po e-pošti. | Strežnik SMTP, dosegljiv s platforme, in e-poštni naslov, shranjen v atributu uporabnika. | Nastavitev OTP po e-pošti |
Neomia Pulse se konfigurira kot dopolnitev drugega dejavnika
Za omogočanje Neomia Pulse mora biti v isti domeni omogočen še drug MFA. Nastavitve funkcije Neomia Pulse nato določajo, za kaj se ta drugi dejavnik uporablja: lahko se preskoči, ko Pulse potrdi uporabnika, in je obvezen, ko ga ne potrdi. Neomia Pulse je torej način, da se drugemu dejavniku izognete, ne pa da ga nadomestite.
Kje se posamezni dejavnik deklarira in kje se omogoči¶
Konfiguracija ima dve možni fazi — deklaracijo dejavnika v njegovem modulu, nato omogočanje na domeni za preverjanje pristnosti — vendar dva od štirih eno od njiju preskočita:
| Dejavnik | Deklariran v | Omogočen na domeni za preverjanje pristnosti |
|---|---|---|
| Neomia Pulse | ničesar ni treba deklarirati | ✅ možnost Enable neomia Pulse authentication, poleg tega pa nastavitve povezave s storitvijo Pulse — glejte opombo spodaj |
| FIDO2 | Relying parties | ❌ ničesar ni treba omogočiti — glejte spodnjo opombo |
| TOTP | OTP Token Generators | ✅ kot token za preverjanje pristnosti |
| OTP po e-pošti | strežnik SMTP, nato OTP Token Generators | ✅ kot token za preverjanje pristnosti |
FIDO2 nima stikala na domeni za preverjanje pristnosti
Varnostnih ključev ne omogočite domeno za domeno: platforma ponudi ta dejavnik, takoj ko je deklariran vsaj en relying party, v vsaki domeni za preverjanje pristnosti, ki ni anonimna — ključ mora biti povezan z osebnim računom. Svoj preverjevalnik pa v portalu registrira uporabnik, ne skrbnik, ki bi mu ga dodelil.
Za Neomia Pulse ni treba ničesar vnaprej deklarirati
Pulse ni token, ki bi ga ustvarili v modulu: možnost se omogoči neposredno na domeni za preverjanje pristnosti, kjer se nastavi tudi njeno delovanje.
Pulse potrebuje nastavitve povezave
Ko potrdite Enable neomia Pulse authentication, se prikažejo tri obvezna polja, s katerimi platformo usmerite na vašo storitev Pulse:
| Polje | Kaj vnesete |
|---|---|
| API URL | URL vmesnika API Pulse. |
| Authentication API URL | URL vmesnika API Pulse za preverjanje pristnosti. |
| API key | Ključ, s katerim platforma preveri svojo pristnost pri tej storitvi. |
Domene za preverjanje pristnosti ni mogoče shraniti, dokler niso izpolnjena vsa tri polja.
Preostanek te strani v celoti obravnava OTP po e-pošti. Preostale tri dejavnike obravnavajo njihove strani o integraciji, na katere so povezave v zgornji tabeli.
Nastavitev OTP po e-pošti¶
OTP po e-pošti uporabniku po e-pošti pošlje kodo za enkratno uporabo, ko sta njegov identifikator in geslo sprejeta. Uporabnik vnese to kodo na portalu, da dokonča prijavo.
Preden začnete: kaj OTP po e-pošti dejansko ščiti¶
OTP po e-pošti ne doda vedno dejavnika
To preberite, preden ta dejavnik izberete namesto drugih treh.
Če se uporabnik prijavi s svojim računom Active Directory in kodo prevzame iz poštnega predala, povezanega s tem istim računom, drugi dejavnik ne doda skoraj ničesar: napadalec, ki je pridobil poverilnice, s temi istimi poverilnicami odpre poštni predal in prebere kodo.
OTP po e-pošti se splača uvesti, kadar poštni predal ni dosegljiv s poverilnicami, ki se preverjajo, torej kadar:
- se uporabnik prijavi z lokalnim računom ali z računom, ločenim od njegovega poštnega predala;
- se koda pošlje na naslov, ki ni naslov računa za prijavo.
Korak 1 — Zagotovitev strežnika SMTP¶
Kodo pošlje platforma prek strežnika SMTP, deklariranega v modulu SMTP servers. Če še nobeden ni na voljo, ga deklarirajte, preden nadaljujete:
Nato z blokom SMTP configuration test tega modula potrdite dostavo: napaka, ugotovljena na tej stopnji, je napaka, ki je pozneje ne boste iskali v poteku prijave.
Preizkusno sporočilo ne uporablja pošiljatelja, ki ga boste konfigurirali
Preizkus pošilja z naslova noreply@cleanroom.com, ki je vpisan v izdelek: ni ga mogoče nikjer spremeniti, uporablja pa se tudi kot naslov za odgovor. Vaš lastni pošiljatelj je SMTP sender tokena, ki ga nastavite v koraku 2 — tega nosijo prava sporočila OTP.
Posledico je dobro poznati, preden sklepate: strežnik SMTP, ki omejuje naslove pošiljateljev, lahko zavrne preizkus, prava sporočila pa prepusti, in obratno.
Povezavo odpre platforma
Tok do strežnika SMTP izhaja iz platforme, ne iz delovne postaje uporabnika. Če je vaš strežnik SMTP v vašem omrežju LAN, mora biti ta tok dovoljen.
Korak 2 — Ustvarjanje tokena OTP¶
Odprite modul OTP Token Generators in kliknite +. V oknu Add OTP token izberite vrsto OTP - email, nato izpolnite polja.
| Polje | Kaj vnesete |
|---|---|
| OTP Type | OTP - email. Te izbire pozneje ni mogoče spremeniti — drug kanal pomeni drug token. |
| Name | Ime tokena. Uporabniku je prikazano na portalu, zato naj se bere kot ime dejavnika in ne kot interna oznaka. |
| Description | Prosto besedilo, vidno samo skrbnikom. |
| OTP usable characters | Abeceda, iz katere se tvori koda. |
| OTP Length | Število znakov v kodi. |
| Validity period of a token (seconds) | Koliko časa ima uporabnik za vnos kode, preden je zavrnjena. |
| Message before the OTP | Stavek pred kodo v telesu sporočila. |
| Mail subject | Zadeva sporočila. |
| SMTP sender | Naslov pošiljatelja sporočila. |
| SMTP server | Strežnik, deklariran v koraku 1. |
Celoten seznam polj z njihovimi privzetimi vrednostmi in omejitvami je na referenčni strani: Splošni blok in Dostava po e-pošti.
Kliknite Validate, da shranite token.
Korak 3 — Omogočite token na domeni za preverjanje pristnosti¶
Odprite modul Authentication domain in uredite domeno, ki naj zahteva OTP.
| Polje | Kaj vnesete |
|---|---|
| Authentication token | Token, ustvarjen v koraku 2. Izberete lahko več tokenov. |
| User attribute used to send the OTP | Ime atributa uporabnika, ki vsebuje naslov, na katerega se pošlje koda. |
| Token expiration duration | Koliko časa ostane preverjeni OTP sprejet, preden je znova zahtevan. 0 onemogoči potek veljavnosti, kar pomeni, da se OTP zahteva ob vsaki prijavi. |
| Time unit | Hours ali Days, uporabljeno za prejšnje polje. |
| Expiration starts | Ali se odštevanje začne ob zadnjem preverjanju OTP ali ob zadnji uspešni prijavi. |
Kateri atribut vsebuje naslov
Gre za atribut imenika, na katerega kaže domena za preverjanje pristnosti, in ne za ime po naši izbiri: uporabite atribut, v katerem imajo vaši uporabniki dejansko shranjen naslov. Pri lokalnem imeniku je ciljni naslov tisti, ki je vnesen v lastnostih uporabnika; pri imeniku LDAP je to lastni poštni atribut imenika.
Kliknite Validate. Uporabniki te domene za preverjanje pristnosti bodo ob naslednji prijavi pozvani k vnosu kode.
Korak 4 — Najprej preverite na preskusni domeni za preverjanje pristnosti¶
Če MFA omogočite na domeni za preverjanje pristnosti, velja za vsakega uporabnika za njo, tudi za vas, če se prijavljate prek nje. Preden token omogočite na produkcijski domeni, ustvarite preskusno domeno za preverjanje pristnosti z enim samim računom in prek nje izvedite celotno prijavo: identifikator, geslo, prejem sporočila, vnos kode.
Uporabnik brez naslova nikoli ne prejme kode
Uporabniku, katerega atribut je prazen, ni mogoče poslati ničesar, zato njegove prijave ni mogoče dokončati. Preverite, ali je atribut izpolnjen za vsak račun za domeno za preverjanje pristnosti, preden na njej omogočite token.