Vairāku faktoru autentifikācijas iestatīšana¶
Vairāku faktoru autentifikācija (MFA) pieprasa lietotājam otru pierādījumu papildus identifikatoram un parolei. CyberElements piedāvā vairākus veidus, kā to iegūt. Šajā lapā aplūkoti četri no tiem tādā secībā, kādā tos parasti apsver, un pēc tam detalizēti aprakstīts tas, kuram nav savas integrācijas lapas: pa e-pastu nosūtītā vienreizējā parole.
Četri faktori, bet ne pilna aina
Šie četri ir tie, kurus aplūko šī lapa, — tie nav vienīgie otrie faktori, ko platforma var pieprasīt. Pieejami ir arī šādi faktori, kas neietilpst šīs lapas tvērumā:
- ar SMS nosūtīts OTP, izmantojot kādu no daudzajiem operatoriem, ko piedāvā modulis OTP Token Generators;
- Radius savienotājs ar trešās puses MFA risinājumu, izmantojot šī paša moduļa tipu OTP - Radius;
- autentifikācija ar x509 sertifikātu, kas nav marķieris, bet gan paša domēna autentifikācijas metode — User certificate vai User certificate and form, lai saglabātu arī paroli;
- MFA, ko pirms platformas piemēro SAML sniedzējs, vai jebkura cita deleģēta autentifikācija. Tad otrais faktors tiek pieprasīts, pirms tiek iesaistīta platforma, kas to ne konfigurē, ne redz.
MFA tiek iestatīta identitātes sniedzējā, nekad lietotājam
Neatkarīgi no tā, kuru faktoru izvēlaties, tas tiek iespējots identitātes sniedzējā un attiecas uz katru lietotāju, kurš pierakstās caur to. Nav iestatījuma katram lietotājam atsevišķi: lai MFA piemērotu tikai daļai lietotāju, novietojiet šos lietotājus aiz atsevišķa identitātes sniedzēja.
Faktora izvēle¶
| Faktors | Ko dara lietotājs | Kas nepieciešams | Procedūra |
|---|---|---|---|
| Neomia Pulse | Neko. Lietotājs tiek atpazīts pēc rakstīšanas manieres uz tastatūras. | Opcija Neomia Pulse, local vai LDAP tipa identitātes sniedzējs un otrs faktors no šīs tabulas tajā pašā sniedzējā. |
Neomia Pulse integrācija |
| FIDO2 | Uzrāda savu autentifikatoru — pievienojot drošības atslēgu vai apstiprinot ierīcē vai seifā, kurā glabājas piekļuves atslēga, — pēc tam ievada PIN, ja autentifikators to pieprasa. | Viens FIDO2 autentifikators katram lietotājam, konsolē deklarēta paļāvīgā puse un personīgais konts — anonīms identitātes sniedzējs ir izslēgts. | Yubico integrācija |
| TOTP | Nolasa sešciparu kodu autentifikatora lietojumprogrammā. | Lietojumprogramma lietotāja tālrunī vai darbstacijā (Google Authenticator, FreeOTP, Microsoft Authenticator utt.) un viena reģistrācija katram lietotājam. | Google Authenticator integrācija |
| OTP pa e-pastu | Nokopē pa e-pastu saņemtu kodu. | SMTP serveris, kas sasniedzams no platformas, un e-pasta adrese, kas glabājas lietotāja atribūtā. | OTP pa e-pastu iestatīšana |
Neomia Pulse tiek konfigurēts papildus citam faktoram
Lai iespējotu Neomia Pulse, tajā pašā domēnā jābūt iespējotai citai MFA. Pēc tam Pulse iestatījumi nosaka, kam tiek izmantots šis otrs faktors: to var izlaist, ja Pulse apstiprina lietotāju, un pieprasīt, ja Pulse to neapstiprina. Tādējādi Neomia Pulse ir veids, kā ietaupīt otro faktoru, nevis to aizstāt.
Kur katrs faktors tiek deklarēts un kur iespējots¶
Konfigurācijai ir divi iespējamie posmi — faktora deklarēšana tā modulī, pēc tam tā iespējošana identitātes sniedzējā —, bet divi no četriem vienu no tiem izlaiž:
| Faktors | Kur deklarēts | Iespējots identitātes sniedzējā |
|---|---|---|
| Neomia Pulse | nav ko deklarēt | ✅ opcija Enable neomia Pulse authentication |
| FIDO2 | Relying parties | ❌ nav ko iespējot — skatiet piezīmi tālāk |
| TOTP | OTP Token Generators | ✅ kā autentifikācijas marķieris |
| OTP pa e-pastu | SMTP server, pēc tam OTP Token Generators | ✅ kā autentifikācijas marķieris |
FIDO2 nav slēdža identitātes sniedzējā
Drošības atslēgas netiek iespējotas katram domēnam atsevišķi: platforma piedāvā šo faktoru, tiklīdz ir deklarēta vismaz viena paļāvīgā puse, katrā identitātes sniedzējā, kas nav anonīms, — atslēgai jābūt piesaistītai personīgajam kontam. Turklāt autentifikatoru portālā reģistrē pats lietotājs; administrators to nepiešķir.
Neomia Pulse gadījumā nekas iepriekš nav jādeklarē
Pulse nav marķieris, kas jāizveido modulī: opcija tiek iespējota tieši identitātes sniedzējā, kur tiek iestatīta arī Pulse darbība.
Pārējā šīs lapas daļā OTP pa e-pastu ir aprakstīts no sākuma līdz beigām. Pārējie trīs faktori ir aprakstīti to integrācijas lapās, uz kurām ir saites iepriekš redzamajā tabulā.
OTP pa e-pastu iestatīšana¶
OTP pa e-pastu nosūta lietotājam vienreizlietojamu kodu pa e-pastu, tiklīdz ir pieņemts lietotāja identifikators un parole. Lietotājs ievada šo kodu portālā, lai pabeigtu pierakstīšanos.
Pirms sākat: ko OTP pa e-pastu patiesībā aizsargā¶
OTP pa e-pastu ne vienmēr pievieno faktoru
Izlasiet šo, pirms izvēlaties šo faktoru, nevis kādu no trim pārējiem.
Ja lietotājs pierakstās ar savu Active Directory kontu un saņem kodu pastkastē, kas piesaistīta tam pašam kontam, otrais faktors gandrīz neko nepievieno: uzbrucējs, kurš ieguvis akreditācijas datus, atver pastkasti ar tiem pašiem akreditācijas datiem un izlasa kodu.
OTP pa e-pastu ir vērts izvietot, ja pastkaste nav sasniedzama ar pārbaudāmajiem akreditācijas datiem, t.i., ja:
- lietotājs pierakstās ar lokālu kontu vai ar kontu, kas ir nošķirts no lietotāja pastkastes;
- kods tiek nosūtīts uz citu adresi, nevis to, kas pieder pierakstīšanās kontam.
1. darbība — Nodrošiniet pieejamu SMTP serveri¶
Kodu platforma nosūta caur SMTP serveri, kas deklarēts modulī SMTP servers. Ja tāds vēl nav pieejams, deklarējiet to, pirms turpināt:
Pēc tam izmantojiet šī moduļa bloku SMTP configuration test, lai apstiprinātu piegādi: šajā posmā diagnosticēta kļūme ir kļūme, kas vēlāk nebūs jāmeklē pierakstīšanās plūsmā.
Testa ziņojums neizmanto sūtītāju, kuru konfigurēsiet
Pārbaude sūta no adreses noreply@cleanroom.com, kas ir iestrādāta produktā: to nevar mainīt nekur, un tā kalpo arī kā atbildes adrese. Jūsu sūtītājs ir marķiera SMTP sender, kas tiek iestatīts 2. darbībā, — tieši to ietver īstie OTP ziņojumi.
Šīs sekas ir vērts zināt, pirms izdarāt secinājumus: SMTP serveris, kas ierobežo sūtītāju adreses, var noraidīt pārbaudi, bet laist cauri īstos ziņojumus, un otrādi.
Savienojumu atver platforma
Plūsma uz SMTP serveri sākas platformā, nevis lietotāja darbstacijā. Ja jūsu SMTP serveris atrodas jūsu LAN, šai plūsmai jābūt atļautai.
2. darbība — Izveidojiet OTP marķieri¶
Atveriet moduli OTP Token Generators un noklikšķiniet uz +. Logā Add OTP token atlasiet tipu OTP - email, pēc tam aizpildiet laukus.
| Lauks | Kas jāievada |
|---|---|
| OTP Type | OTP - email. Šo izvēli vēlāk nevar mainīt — cits kanāls nozīmē citu marķieri. |
| Name | Marķiera nosaukums. Tas tiek parādīts lietotājam portālā, tāpēc tam jāizklausās pēc faktora nosaukuma, nevis pēc iekšējas atsauces. |
| Description | Brīvs teksts, kas redzams tikai administratoriem. |
| OTP usable characters | Alfabēts, no kura tiek veidots kods. |
| OTP Length | Rakstzīmju skaits kodā. |
| Validity period of a token (seconds) | Cik ilgi lietotājs var ievadīt kodu, pirms tas tiek noraidīts. |
| Message before the OTP | Teikums, kas ziņojuma pamattekstā ir pirms koda. |
| Mail subject | Ziņojuma tēma. |
| SMTP sender | Ziņojuma sūtītāja adrese. |
| SMTP server | Serveris, kas deklarēts 1. darbībā. |
Pilns lauku saraksts ar to noklusējuma vērtībām un ierobežojumiem ir atsauces lapā: Vispārīgais bloks un Piegāde pa e-pastu.
Noklikšķiniet uz Validate, lai saglabātu marķieri.
3. darbība — Iespējojiet marķieri identitātes sniedzējā¶
Atveriet moduli Identity Providers un rediģējiet sniedzēju, kuram jāpieprasa OTP.
| Lauks | Kas jāievada |
|---|---|
| Authentication token | Marķieris, kas izveidots 2. darbībā. Var atlasīt vairākus marķierus. |
| User attribute used to send the OTP | Tā lietotāja atribūta nosaukums, kurā glabājas adrese, uz kuru tiek nosūtīts kods. |
| Token expiration duration | Cik ilgi apstiprināts OTP paliek pieņemts, pirms tas tiek pieprasīts atkārtoti. 0 atspējo derīguma beigšanos — tad OTP tiek pieprasīts katrā pierakstīšanās reizē. |
| Time unit | Hours vai Days; attiecas uz iepriekšējo lauku. |
| Expiration starts | Vai atpakaļskaitīšana sākas no pēdējās OTP apstiprināšanas vai no pēdējās sekmīgās pierakstīšanās. |
Kurā atribūtā ir adrese
Tas ir tā direktorija atribūts, uz kuru norāda identitātes sniedzējs, nevis mūsu izvēlēts nosaukums: izmantojiet atribūtu, kurā jūsu lietotājiem patiešām ir norādīta adrese. Lokālā direktorijā jānorāda adrese, kas ievadīta lietotāja rekvizītos; LDAP direktorijā tas ir paša direktorija e-pasta atribūts.
Noklikšķiniet uz Validate. Nākamajā pierakstīšanās reizē šī identitātes sniedzēja lietotājiem tiks pieprasīts kods.
4. darbība — Vispirms pārbaudiet testa identitātes sniedzējā¶
Iespējojot MFA identitātes sniedzējā, tā tiek piemērota katram lietotājam aiz tā, arī jums pašiem, ja pierakstāties caur to. Pirms marķiera iespējošanas ražošanas sniedzējā izveidojiet testa identitātes sniedzēju ar vienu kontu un veiciet caur to pilnu pierakstīšanos: identifikators, parole, ziņojuma saņemšana, koda ievadīšana.
Lietotājs bez adreses nekad nesaņem kodu
Lietotājam, kura atribūts ir tukšs, neko nevar nosūtīt, un viņa pierakstīšanos nevar pabeigt. Pārbaudiet, vai atribūts ir aizpildīts katram kontam aiz identitātes sniedzēja, pirms iespējojat tajā marķieri.