Többtényezős hitelesítés beállítása

A többtényezős hitelesítés (MFA) az azonosítón és a jelszón kívül egy második bizonyítékot is kér a felhasználótól. A CyberElements több módot kínál ennek megszerzésére. Ez az oldal ezek közül négyet mutat be, abban a sorrendben, ahogyan általában mérlegelni szokták őket, majd részletesen ismerteti azt, amelyiknek nincs saját integrációs oldala: az e-mailben küldött egyszeri jelszót.

Négy tényező, de nem a teljes kép

Ez az oldal ezt a négyet mutatja be — de nem csak ezeket a második tényezőket kérheti a platform. Szintén elérhetők, de nem tartoznak ennek az oldalnak a hatókörébe:

• SMS-ben küldött OTP, az OTP Token Generators modul által kínált számos szolgáltató egyikén keresztül;
• Radius-összekötő egy külső MFA-megoldás felé, ugyanennek a modulnak az OTP - Radius típusán keresztül;
• x509-tanúsítványos hitelesítés, amely nem token, hanem magának a tartománynak egy hitelesítési módszere — User certificate, vagy User certificate and form, ha a jelszót is meg szeretné tartani;
• egy SAML-szolgáltató által előzetesen kikényszerített MFA, vagy bármely más delegált hitelesítés által kikényszerített MFA. A második tényezőt ilyenkor még a platform bevonása előtt kérik, így a platform azt sem nem konfigurálja, sem nem látja.

Az MFA-t az identitásszolgáltatón kell beállítani, soha nem a felhasználón

Bármelyik tényezőt választja, azt egy identitásszolgáltatón kell bekapcsolni, és minden olyan felhasználóra vonatkozik, aki azon keresztül jelentkezik be. Felhasználónkénti beállítás nincs: ha a felhasználóknak csak egy részére szeretné alkalmazni az MFA-t, helyezze ezeket a felhasználókat egy dedikált identitásszolgáltató mögé.

Tényező kiválasztása

Tényező	Mit tesz a felhasználó	Mire van szükség	Eljárás
Neomia Pulse	Semmit. A rendszer a billentyűzeten való gépelés módja alapján ismeri fel a felhasználót.	A Neomia Pulse beállítás, egy local vagy LDAP típusú identitásszolgáltató, valamint egy második tényező ebből a táblázatból ugyanazon a szolgáltatón.	Neomia Pulse-integráció
FIDO2	Felmutatja a hitelesítőjét — csatlakoztat egy biztonsági kulcsot, vagy jóváhagyja a kérést a hozzáférési kulcsot tároló eszközön vagy széfben —, majd megad egy PIN-kódot, ha a hitelesítő kéri.	Felhasználónként egy FIDO2-hitelesítő, egy a konzolban deklarált függő entitás és egy személyes fiók — névtelen identitásszolgáltató nem használható.	Yubico-integráció
TOTP	Leolvas egy hatjegyű kódot egy hitelesítő alkalmazásban.	Egy alkalmazás a felhasználó telefonján vagy munkaállomásán (Google Authenticator, FreeOTP, Microsoft Authenticator stb.) és felhasználónként egy regisztráció.	Google Authenticator-integráció
E-mailes OTP	Bemásol egy e-mailben kapott kódot.	A platform által elérhető SMTP-kiszolgáló és egy felhasználói attribútumban tárolt e-mail-cím.	E-mailes OTP beállítása

A Neomia Pulse egy másik tényezőre épülve konfigurálható

A Neomia Pulse bekapcsolásához ugyanazon a tartományon egy másik MFA-nak is bekapcsolva kell lennie. A Neomia Pulse beállításai ezután meghatározzák, mire használja a rendszer ezt a másik tényezőt: kihagyható, ha a Pulse elfogadja a felhasználót, és kötelező, ha nem. A Neomia Pulse tehát inkább a második tényező megtakarítására szolgál, mint annak kiváltására.

Hol kell deklarálni és hol kell bekapcsolni az egyes tényezőket

A konfiguráció két lehetséges lépésből áll — a tényező deklarálása a saját moduljában, majd bekapcsolása az identitásszolgáltatón —, de a négy közül kettő az egyiket kihagyja:

Tényező	Deklarálás helye	Bekapcsolás az identitásszolgáltatón
Neomia Pulse	nincs mit deklarálni	✅ az Enable neomia Pulse authentication beállítás
FIDO2	Relying parties	❌ nincs mit bekapcsolni — lásd az alábbi megjegyzést
TOTP	OTP Token Generators	✅ hitelesítési tokenként
E-mailes OTP	egy SMTP server, majd OTP Token Generators	✅ hitelesítési tokenként

A FIDO2 nem kapcsolható be az identitásszolgáltatón

A biztonsági kulcsok nem tartományonként kapcsolhatók be: a platform azonnal felkínálja a tényezőt, amint legalább egy függő entitás deklarálva van, minden olyan identitásszolgáltatón, amely nem névtelen — a kulcsot ugyanis személyes fiókhoz kell kötni. Ráadásul a hitelesítőt a felhasználó regisztrálja a portálon, nem a rendszergazda rendeli hozzá.

A Neomia Pulse esetében előzetesen nincs mit deklarálni

A Pulse nem egy modulban létrehozandó token: a beállítás közvetlenül az identitásszolgáltatón kapcsolható be, és a viselkedése is ott állítható be.

Az oldal további része az e-mailes OTP-t mutatja be az elejétől a végéig. A másik három tényezőt a saját integrációs oldaluk ismerteti, amelyekre a fenti táblázat hivatkozik.

E-mailes OTP beállítása

Az e-mailes OTP egyszer használatos kódot küld e-mailben a felhasználónak, miután a rendszer elfogadta az azonosítóját és a jelszavát. A felhasználó a bejelentkezés befejezéséhez a portálon adja meg ezt a kódot.

Mielőtt elkezdené: mit véd valójában az e-mailes OTP

Az e-mailes OTP nem mindig jelent további tényezőt

Olvassa el ezt, mielőtt ezt a tényezőt választaná a másik három helyett.

Ha a felhasználó az Active Directory-fiókjával jelentkezik be, és a kódot egy ugyanehhez a fiókhoz tartozó postafiókból kapja meg, a második tényező szinte semmit sem tesz hozzá: a hitelesítő adatokat megszerző támadó ugyanezekkel a hitelesítő adatokkal megnyitja a postafiókot, és elolvassa a kódot.

Az e-mailes OTP bevezetése akkor éri meg, ha a postafiók nem érhető el az ellenőrzött hitelesítő adatokkal, vagyis ha:

• a felhasználó helyi fiókkal, vagy a postafiókjától eltérő fiókkal jelentkezik be;
• a kódot a rendszer nem a bejelentkezési fiókhoz tartozó címre küldi.

1. lépés — SMTP-kiszolgáló biztosítása

A platform a kódot az SMTP servers modulban deklarált SMTP-kiszolgálón keresztül küldi el. Ha még nincs ilyen, deklaráljon egyet, mielőtt továbblépne:

E-mail-küldés beállítása

Ezután az adott modul SMTP configuration test blokkjával ellenőrizze a kézbesítést: az ebben a fázisban diagnosztizált hibát később már nem kell a bejelentkezési folyamatban keresnie.

A tesztüzenet nem az Ön által konfigurálandó feladót használja

A teszt a noreply@cleanroom.com címről küld, amely a termékbe beégetett cím: sehol sem módosítható, és egyben válaszcímként is szolgál. Az Ön saját feladója a token SMTP sender értéke, amelyet a 2. lépésben állít be — a valódi OTP-üzenetek ezt viselik.

Mielőtt következtetést vonna le, érdemes ismerni a következményt: egy olyan SMTP-kiszolgáló, amely korlátozza a feladócímeket, elutasíthatja a tesztet, miközben a tényleges üzeneteket átengedi, és fordítva.

A kapcsolatot a platform nyitja meg

Az SMTP-kiszolgáló felé irányuló adatfolyam a platformról indul, nem a felhasználó munkaállomásáról. Ha az SMTP-kiszolgáló az Ön LAN-hálózatán található, ezt az adatfolyamot meg kell engedni.

2. lépés — Az OTP-token létrehozása

Nyissa meg az OTP Token Generators modult, és kattintson a + gombra. Az Add OTP token ablakban válassza ki az OTP - email típust, majd töltse ki a mezőket.

Mező	Mit kell megadni
OTP Type	OTP - email. Ez a választás később nem módosítható — más csatorna más tokent jelent.
Name	A token neve. A portálon megjelenik a felhasználónak, ezért tényezőnévként, ne belső hivatkozásként hangozzon.
Description	Szabad szöveg, csak a rendszergazdák látják.
OTP usable characters	Az a karakterkészlet, amelyből a kód összeáll.
OTP Length	A kód karaktereinek száma.
Validity period of a token (seconds)	Mennyi ideje van a felhasználónak a kód megadására, mielőtt a rendszer elutasítja.
Message before the OTP	Az üzenet törzsében a kódot megelőző mondat.
Mail subject	Az üzenet tárgya.
SMTP sender	Az üzenet feladójának címe.
SMTP server	Az 1. lépésben deklarált kiszolgáló.

A mezők teljes listája az alapértelmezett értékeikkel és korlátozásaikkal együtt a referenciaoldalon található: Általános blokk és Kézbesítés e-mailben.

A token mentéséhez kattintson a Validate gombra.

3. lépés — A token bekapcsolása egy identitásszolgáltatón

Nyissa meg az Identity Providers modult, és szerkessze azt a szolgáltatót, amelynek az OTP-t kérnie kell.

Mező	Mit kell megadni
Authentication token	A 2. lépésben létrehozott token. Több token is kiválasztható.
User attribute used to send the OTP	Annak a felhasználói attribútumnak a neve, amely azt a címet tartalmazza, ahová a rendszer a kódot elküldi.
Token expiration duration	Mennyi ideig fogadja el a rendszer a jóváhagyott OTP-t, mielőtt újra kérné. A 0 érték kikapcsolja a lejáratot, vagyis a rendszer minden bejelentkezéskor kéri az OTP-t.
Time unit	Hours vagy Days, az előző mezőre alkalmazva.
Expiration starts	Az, hogy a visszaszámlálás az utolsó OTP-jóváhagyástól vagy az utolsó sikeres bejelentkezéstől indul.

Melyik attribútum tartalmazza a címet

Az attribútum annak a címtárnak az attribútuma, amelyre az identitásszolgáltató mutat, nem általunk választott név: azt az attribútumot használja, amelyben a felhasználói címe ténylegesen szerepel. Helyi címtár esetén a felhasználó tulajdonságaiban megadott címet kell megcélozni; LDAP-címtár esetén magának a címtárnak a levelezési attribútumát.

Kattintson a Validate gombra. Az adott identitásszolgáltató felhasználóitól a rendszer a következő bejelentkezésükkor kódot kér.

4. lépés — Ellenőrzés először egy tesztelési célú identitásszolgáltatón

Ha az MFA-t bekapcsolja egy identitásszolgáltatón, az a mögötte álló összes felhasználóra vonatkozik, Önt is beleértve, ha azon keresztül jelentkezik be. Mielőtt az éles szolgáltatón bekapcsolná a tokent, hozzon létre egy tesztelési célú identitásszolgáltatót egyetlen fiókkal, és hajtson végre rajta keresztül egy teljes bejelentkezést: azonosító, jelszó, az üzenet fogadása, a kód megadása.

Cím nélküli felhasználó soha nem kap kódot

Annak a felhasználónak, akinek az attribútuma üres, semmit sem lehet küldeni, és a bejelentkezése nem fejeződhet be. Ellenőrizze, hogy az attribútum az identitásszolgáltató mögötti minden fióknál ki van-e töltve, mielőtt bekapcsolná rajta a tokent.