Nastavitev večkratnega preverjanja pristnosti¶
Večkratno preverjanje pristnosti (MFA) od uporabnika poleg identifikatorja in gesla zahteva še drugi dokaz. CyberElements ponuja več načinov za njegovo pridobitev. Ta stran obravnava štiri med njimi, v vrstnem redu, v katerem se običajno obravnavajo, 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 ponudniku identitete, nikoli na uporabniku
Ne glede na to, kateri dejavnik izberete, se omogoči na ponudniku identitete in velja za vsakega uporabnika, ki se prijavi prek njega. Nastavitve za posameznega uporabnika ni: če želite MFA uvesti le za del uporabnikov, jih postavite za namenskega ponudnika identitete.
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, ponudnik identitete vrste local ali LDAP in drugi dejavnik iz te tabele na istem ponudniku. |
Integracija Neomia Pulse |
| FIDO2 | Predloži svoj preverjevalnik — priključi varnostni ključ ali odobri v napravi ali trezorju, ki hrani ključ za dostop — nato vnese PIN, če ga preverjevalnik zahteva. | En preverjevalnik FIDO2 na uporabnika, deklaracija relying party v konzoli in osebni račun — anonimni ponudnik identitete je izključen. | 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 in nato njegovo omogočanje na ponudniku identitete —, vendar dva od štirih eno od njiju preskočita:
| Dejavnik | Deklariran v | Omogočen na ponudniku identitete |
|---|---|---|
| Neomia Pulse | ničesar ni treba deklarirati | ✅ možnost Enable neomia Pulse authentication |
| 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 ponudniku identitete
Varnostni ključi se ne omogočajo po posameznih domenah: platforma ponudi ta dejavnik, takoj ko je deklariran vsaj en relying party, na vsakem ponudniku identitete, ki ni anonimen — ključ mora biti povezan z osebnim računom. Svoj preverjevalnik prek portala registrira uporabnik, ne dodeli ga skrbnik.
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 ponudniku identitete, kjer se nastavi tudi njeno delovanje.
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čanje tokena na ponudniku identitete¶
Odprite modul Identity Providers in uredite ponudnika, 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
Atribut je atribut imenika, na katerega kaže ponudnik identitete, in ne ime po naši izbiri: uporabite atribut, v katerem imajo vaši uporabniki dejansko naslov. Pri lokalnem imeniku je cilj naslov, vnesen v lastnostih uporabnika; pri imeniku LDAP je to lastni poštni atribut imenika.
Kliknite Validate. Uporabniki tega ponudnika identitete bodo ob naslednji prijavi pozvani k vnosu kode.
Korak 4 — Najprej preverite na preizkusnem ponudniku identitete¶
Omogočanje MFA na ponudniku identitete velja za vse uporabnike za njim, vključno z vami, če se prijavljate prek njega. Preden token omogočite na produkcijskem ponudniku, ustvarite preizkusnega ponudnika identitete z enim samim računom in prek njega 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 ničesar poslati in njegove prijave ni mogoče dokončati. Preverite, ali je atribut izpolnjen za vsak račun za ponudnikom identitete, preden na njem omogočite token.