Configurarea autentificării multifactor¶
Autentificarea multifactor (MFA) îi cere utilizatorului o a doua dovadă, pe lângă identificatorul și parola sa. CyberElements Bastion oferă mai multe moduri de a o obține. Această pagină acoperă patru dintre ele, în ordinea în care sunt luate în considerare de obicei, apoi îl detaliază pe cel care nu are o pagină de integrare proprie: parola de unică folosință trimisă prin e-mail.
Patru factori, dar nu tabloul complet
Aceștia patru sunt cei pe care îi parcurge această pagină — nu sunt singurii factori secundari pe care platforma îi poate solicita. Mai sunt disponibili, în afara domeniului acestei pagini:
- un OTP trimis prin SMS, prin unul dintre numeroșii operatori oferiți de modulul OTP Token Generators;
- un conector Radius către o soluție MFA terță, prin tipul OTP - Radius al aceluiași modul;
- autentificarea prin certificat x509, care nu este un token, ci o metodă de autentificare a domeniului însuși — User certificate sau User certificate and form pentru a păstra și parola;
- un MFA impus în amonte de un furnizor SAML sau de orice altă autentificare delegată. Al doilea factor este atunci solicitat înainte ca platforma să fie implicată, iar aceasta nici nu îl configurează, nici nu îl vede.
MFA se stabilește pe domeniul de autentificare, niciodată pe un utilizator
Indiferent de factorul ales, acesta se activează pe un domeniu de autentificare și se aplică fiecărui utilizator care se conectează prin intermediul său. Nu există o setare pentru fiecare utilizator: pentru ca doar o parte din populația dumneavoastră să fie supusă MFA, plasați acei utilizatori în spatele unui domeniu de autentificare dedicat.
Alegerea unui factor¶
| Factor | Ce face utilizatorul | Ce necesită | Procedură |
|---|---|---|---|
| Neomia Pulse | Nimic. Utilizatorul este recunoscut după modul în care tastează la tastatură. | Opțiunea Neomia Pulse, parametrii de conexiune la serviciul dumneavoastră Pulse, un domeniu de autentificare de tip local sau LDAP, și un al doilea factor din acest tabel pe același domeniu. |
Integrarea Neomia Pulse |
| FIDO2 | Își prezintă autentificatorul — conectând o cheie de securitate sau aprobând pe dispozitivul ori în seiful care deține passkey-ul — apoi introduce un PIN dacă autentificatorul solicită unul. | Câte un autentificator FIDO2 pentru fiecare utilizator, o relying party declarată în consolă și un cont personal — un domeniu de autentificare anonim este exclus. | Integrarea Yubico |
| TOTP | Citește un cod din șase cifre într-o aplicație de autentificare. | O aplicație pe telefonul sau pe stația de lucru a utilizatorului (Google Authenticator, FreeOTP, Microsoft Authenticator și altele) și câte o înrolare pentru fiecare utilizator. | Integrarea Google Authenticator |
| OTP prin e-mail | Copiază un cod primit prin e-mail. | Un server SMTP accesibil platformei și o adresă de e-mail păstrată într-un atribut de utilizator. | Configurarea unui OTP prin e-mail |
Neomia Pulse se configurează peste un alt factor
Activarea Neomia Pulse necesită activarea unui alt MFA pe același domeniu. Setările sale decid apoi la ce servește acel alt factor: el poate fi ocolit atunci când Pulse validează utilizatorul și obligatoriu atunci când Pulse nu îl validează. Prin urmare, Neomia Pulse este o modalitate de a economisi al doilea factor, mai degrabă decât de a-l înlocui.
Unde se declară fiecare factor și unde se activează¶
Configurarea are două etape posibile — declararea factorului în modulul său propriu, apoi activarea lui pe domeniul de autentificare — dar doi dintre cei patru sar peste una dintre ele:
| Factor | Declarat în | Activat pe domeniul de autentificare |
|---|---|---|
| Neomia Pulse | nimic de declarat | ✅ opțiunea Enable neomia Pulse authentication, plus parametrii de conexiune la serviciul Pulse — consultați nota de mai jos |
| FIDO2 | Relying parties | ❌ nimic de activat — consultați nota de mai jos |
| TOTP | OTP Token Generators | ✅ ca token de autentificare |
| OTP prin e-mail | un server SMTP, apoi OTP Token Generators | ✅ ca token de autentificare |
FIDO2 nu are niciun comutator pe domeniul de autentificare
Cheile de securitate nu se activează furnizor cu furnizor: platforma oferă factorul de îndată ce este declarată cel puțin o relying party, pe fiecare domeniu de autentificare care nu este anonim — o cheie trebuie atașată unui cont personal. Iar utilizatorul este cel care își înrolează autentificatorul din portal, nu administratorul care i-l atribuie.
Neomia Pulse nu are nimic de declarat în prealabil
Pulse nu este un token care să fie creat într-un modul: opțiunea se activează direct pe domeniul de autentificare, tot acolo fiind stabilit și comportamentul său.
Pulse are nevoie de parametrii săi de conexiune
Bifarea opțiunii Enable neomia Pulse authentication dezvăluie trei câmpuri obligatorii care îndreaptă platforma către serviciul dumneavoastră Pulse:
| Câmp | Ce trebuie introdus |
|---|---|
| API URL | URL-ul API-ului Pulse. |
| Authentication API URL | URL-ul API-ului de autentificare Pulse. |
| API key | Cheia care autentifică platforma la acel serviciu. |
Domeniul de autentificare nu se salvează până când cele trei nu sunt completate.
Restul acestei pagini acoperă OTP-ul prin e-mail de la un capăt la altul. Ceilalți trei factori sunt tratați în pagina lor de integrare, legată în tabelul de mai sus.
Configurarea unui OTP prin e-mail¶
Un OTP prin e-mail îi trimite utilizatorului, prin e-mail, un cod de unică folosință, odată ce identificatorul și parola sa au fost acceptate. Utilizatorul introduce acel cod în portal pentru a finaliza conectarea.
Înainte de a începe: ce protejează de fapt un OTP prin e-mail¶
Un OTP prin e-mail nu adaugă întotdeauna un factor
Citiți acest lucru înainte de a alege acest factor în locul celorlalți trei.
Dacă utilizatorul se conectează cu contul său Active Directory și preia codul dintr-o cutie poștală atașată aceluiași cont, al doilea factor nu adaugă mai nimic: un atacator care a obținut credențialele deschide cutia poștală chiar cu acele credențiale și citește codul.
Un OTP prin e-mail merită implementat atunci când cutia poștală nu este accesibilă cu credențialele verificate, adică atunci când:
- utilizatorul se conectează cu un cont local sau cu un cont diferit de cel al cutiei sale poștale;
- codul este trimis la o altă adresă decât cea care aparține contului de conectare.
Pasul 1 — Dispuneți de un server SMTP¶
Codul este trimis de platformă printr-un server SMTP declarat în modulul SMTP servers. Dacă nu este încă disponibil niciunul, declarați unul înainte de a merge mai departe:
Configurarea trimiterii de e-mailuri
Utilizați apoi blocul SMTP configuration test al acelui modul pentru a confirma livrarea: un eșec diagnosticat în această etapă este un eșec pe care nu îl veți mai căuta ulterior în fluxul de conectare.
Mesajul de test nu utilizează expeditorul pe care îl veți configura
Testul trimite de la noreply@cleanroom.com, o adresă înscrisă în produs: ea nu poate fi modificată nicăieri și servește totodată ca adresă de răspuns. Propriul dumneavoastră expeditor este SMTP sender al tokenului, stabilit la pasul 2 — el este cel pe care îl poartă mesajele OTP reale.
Consecința merită cunoscută înainte de a trage concluzii: un server SMTP care restricționează adresele de expediere poate respinge testul, lăsând totuși să treacă mesajele reale, și invers.
Conexiunea este deschisă de platformă
Fluxul către serverul SMTP pleacă de la platformă, nu de la stația de lucru a utilizatorului. Dacă serverul dumneavoastră SMTP se află în rețeaua dumneavoastră LAN, acest flux trebuie autorizat.
Pasul 2 — Creați tokenul OTP¶
Deschideți modulul OTP Token Generators și faceți clic pe +. În fereastra Add OTP token, selectați tipul OTP - email, apoi completați câmpurile.
| Câmp | Ce trebuie introdus |
|---|---|
| OTP Type | OTP - email. Această alegere nu mai poate fi modificată ulterior — un canal diferit înseamnă un token diferit. |
| Name | Numele tokenului. Acesta este afișat utilizatorului în portal, așa că ar trebui să se citească precum numele unui factor, nu ca o referință internă. |
| Description | Text liber, vizibil doar administratorilor. |
| OTP usable characters | Alfabetul din care este extras codul. |
| OTP Length | Numărul de caractere ale codului. |
| Validity period of a token (seconds) | Cât timp are utilizatorul la dispoziție pentru a introduce codul înainte ca acesta să fie respins. |
| Message before the OTP | Propoziția care precedă codul în corpul mesajului. |
| Mail subject | Subiectul mesajului. |
| SMTP sender | Adresa expeditorului mesajului. |
| SMTP server | Serverul declarat la pasul 1. |
Lista completă a câmpurilor, cu valorile lor implicite și cu constrângerile lor, se află în pagina de referință: Blocul generic și Trimiterea prin e-mail.
Faceți clic pe Validate pentru a salva tokenul.
Pasul 3 — Activați tokenul pe un domeniu de autentificare¶
Deschideți modulul Authentication domain și modificați domeniul care trebuie să solicite OTP-ul.
| Câmp | Ce trebuie introdus |
|---|---|
| Authentication token | Tokenul creat la pasul 2. Pot fi selectate mai multe tokenuri. |
| User attribute used to send the OTP | Numele atributului de utilizator care conține adresa la care este trimis codul. |
| Token expiration duration | Cât timp rămâne acceptat un OTP validat înainte de a fi solicitat din nou. 0 dezactivează expirarea, ceea ce înseamnă că OTP-ul este solicitat la fiecare conectare. |
| Time unit | Hours sau Days, aplicate câmpului anterior. |
| Expiration starts | Dacă numărătoarea inversă începe de la ultima validare a OTP-ului sau de la ultima conectare reușită. |
Ce atribut conține adresa
Atributul este cel al directorului către care indică domeniul de autentificare, nu un nume ales de noi: utilizați atributul în care utilizatorii dumneavoastră poartă efectiv o adresă. Pentru un director local, adresa introdusă în proprietățile utilizatorului este cea de vizat; pentru un director LDAP, este atributul de e-mail propriu directorului.
Faceți clic pe Validate. Utilizatorilor acelui domeniu de autentificare li se solicită un cod la următoarea conectare.
Pasul 4 — Verificați mai întâi pe un domeniu de autentificare de test¶
Activarea MFA pe un domeniu de autentificare o aplică fiecărui utilizator din spatele său, inclusiv dumneavoastră, dacă vă conectați prin el. Înainte de a activa tokenul pe domeniul dumneavoastră de producție, creați un domeniu de autentificare de test care poartă un singur cont și efectuați o conectare completă prin el: identificator, parolă, primirea mesajului, introducerea codului.
Un utilizator fără adresă nu primește niciodată un cod
Unui utilizator al cărui atribut este gol nu i se poate trimite nimic, iar conectarea sa nu se poate finaliza. Verificați că atributul este completat pentru fiecare cont din spatele domeniului de autentificare înainte de a activa tokenul pe acesta.