Nastavení vícefaktorového ověřování¶
Vícefaktorové ověřování (MFA) vyžaduje od uživatele kromě identifikátoru a hesla ještě druhý důkaz. CyberElements nabízí několik způsobů, jak jej získat. Tato stránka se zabývá čtyřmi z nich v pořadí, v jakém se obvykle zvažují, a poté podrobně popisuje ten, který nemá vlastní stránku integrace: jednorázové heslo zasílané e-mailem.
Čtyři faktory, ale ne celý obraz
Tato stránka prochází právě těmito čtyřmi — nejsou to ale jediné druhé faktory, které může platforma vyžadovat. K dispozici jsou také, mimo rozsah této stránky:
- OTP zasílané prostřednictvím SMS, přes jednoho z mnoha operátorů nabízených modulem OTP Token Generators;
- konektor Radius k řešení MFA třetí strany, prostřednictvím typu OTP - Radius téhož modulu;
- ověřování certifikátem x509, které není token, ale metoda ověřování samotné domény — User certificate, případně User certificate and form, chcete-li zachovat i heslo;
- MFA vynucené dříve v řetězci zprostředkovatelem SAML nebo jakýmkoli jiným delegovaným ověřováním. Druhý faktor je pak vyžadován dříve, než se do procesu zapojí platforma, která jej tedy ani nekonfiguruje, ani nevidí.
MFA se nastavuje u zprostředkovatele identity, nikdy u uživatele
Ať zvolíte kterýkoli faktor, povoluje se u zprostředkovatele identity a platí pro každého uživatele, který se přes něj přihlašuje. Neexistuje žádné nastavení pro jednotlivé uživatele: chcete-li MFA podrobit jen část svých uživatelů, umístěte tyto uživatele za vyhrazeného zprostředkovatele identity.
Výběr faktoru¶
| Faktor | Co dělá uživatel | Co vyžaduje | Postup |
|---|---|---|---|
| Neomia Pulse | Nic. Uživatel je rozpoznán podle způsobu, jakým píše na klávesnici. | Možnost Neomia Pulse, zprostředkovatel identity typu local nebo LDAP a druhý faktor z této tabulky u stejného zprostředkovatele. |
Integrace Neomia Pulse |
| FIDO2 | Předloží svůj autentizátor — připojí bezpečnostní klíč nebo potvrdí přihlášení na zařízení či ve správci hesel, který uchovává klíč pro přístup — a poté zadá PIN, pokud ho autentizátor vyžaduje. | Autentizátor FIDO2 pro každého uživatele, relying party deklarovaná v konzole a osobní účet — anonymní zprostředkovatel identity je vyloučen. | Integrace Yubico |
| TOTP | Přečte šestimístný kód v ověřovací aplikaci. | Aplikace v telefonu nebo na pracovní stanici uživatele (Google Authenticator, FreeOTP, Microsoft Authenticator atd.) a jedna registrace na uživatele. | Integrace Google Authenticator |
| OTP e-mailem | Opíše kód přijatý e-mailem. | Server SMTP dostupný z platformy a e-mailová adresa uložená v atributu uživatele. | Nastavení OTP e-mailem |
Neomia Pulse se konfiguruje nad jiným faktorem
Povolení Neomia Pulse vyžaduje, aby bylo na stejné doméně povoleno jiné MFA. Nastavení Neomia Pulse pak rozhoduje o tom, k čemu se tento druhý faktor použije: může být přeskočen, když Pulse uživatele ověří, a vyžadován, když ho neověří. Neomia Pulse je tedy způsob, jak druhý faktor ušetřit, nikoli jak ho nahradit.
Kde se jednotlivé faktory deklarují a kde se povolují¶
Konfigurace má dvě možné fáze — deklarování faktoru v jeho vlastním modulu a poté jeho povolení u zprostředkovatele identity — ale dva ze čtyř faktorů jednu z nich vynechávají:
| Faktor | Deklaruje se v | Povoluje se u zprostředkovatele identity |
|---|---|---|
| Neomia Pulse | není co deklarovat | ✅ možnost Enable neomia Pulse authentication |
| FIDO2 | Relying parties | ❌ není co povolit — viz poznámka níže |
| TOTP | OTP Token Generators | ✅ jako ověřovací token |
| OTP e-mailem | server SMTP, poté OTP Token Generators | ✅ jako ověřovací token |
FIDO2 nemá u zprostředkovatele identity žádný přepínač
Bezpečnostní klíče se nepovolují pro každou doménu zvlášť: platforma tento faktor nabízí, jakmile je definována alespoň jedna relying party, u každého zprostředkovatele identity, který není anonymní — klíč musí být vázán na osobní účet. A je to uživatel, kdo si svůj ověřovací prostředek zaregistruje z portálu, nikoli správce, kdo mu jej přiřadí.
U Neomia Pulse není třeba nic předem deklarovat
Pulse není token, který by se vytvářel v modulu: možnost se povoluje přímo u zprostředkovatele identity, kde se také nastavuje její chování.
Zbytek této stránky popisuje OTP e-mailem od začátku do konce. Tři další faktory popisují jejich stránky integrace, na které odkazuje tabulka výše.
Nastavení OTP e-mailem¶
OTP e-mailem zašle uživateli e-mailem jednorázový kód, jakmile jsou přijaty jeho identifikátor a heslo. Uživatel tento kód zadá na portálu, aby dokončil přihlášení.
Než začnete: co OTP e-mailem skutečně chrání¶
OTP e-mailem vždy nepřidává další faktor
Přečtěte si toto, než tento faktor zvolíte místo tří ostatních.
Pokud se uživatel přihlašuje svým účtem Active Directory a kód si vyzvedává z poštovní schránky propojené s tímtéž účtem, druhý faktor nepřidává téměř nic: útočník, který získal přihlašovací údaje, otevře schránku právě těmito údaji a kód si přečte.
Nasadit OTP e-mailem má smysl tehdy, když poštovní schránka není dostupná pomocí ověřovaných přihlašovacích údajů, tedy když:
- uživatel se přihlašuje místním účtem nebo účtem odlišným od své poštovní schránky;
- kód se odesílá na jinou adresu, než je adresa patřící k přihlašovacímu účtu.
Krok 1 — Zajištění dostupného serveru SMTP¶
Kód odesílá platforma prostřednictvím serveru SMTP deklarovaného v modulu SMTP servers. Pokud zatím žádný k dispozici není, deklarujte jej, než budete pokračovat:
Poté pomocí bloku SMTP configuration test tohoto modulu ověřte doručení: selhání diagnostikované v této fázi je selhání, které později nebudete hledat v průběhu přihlašování.
Testovací zpráva nepoužívá odesílatele, kterého nakonfigurujete
Test odesílá z adresy noreply@cleanroom.com, která je pevně zapsaná v produktu: nelze ji nikde změnit a slouží také jako adresa pro odpověď. Váš vlastní odesílatel je pole SMTP sender tokenu nastavené v kroku 2 — právě to nesou skutečné zprávy s OTP.
Tento důsledek je dobré znát dříve, než vyvodíte závěry: server SMTP, který omezuje adresy odesílatelů, může odmítnout test a přitom propustit skutečné zprávy — a naopak.
Připojení otevírá platforma
Tok k serveru SMTP vychází z platformy, nikoli z pracovní stanice uživatele. Pokud se váš server SMTP nachází ve vaší síti LAN, musí být tento tok povolen.
Krok 2 — Vytvoření tokenu OTP¶
Otevřete modul OTP Token Generators a klikněte na +. V okně Add OTP token vyberte typ OTP - email a poté vyplňte pole.
| Pole | Co zadat |
|---|---|
| OTP Type | OTP - email. Tuto volbu nelze později změnit — jiný kanál znamená jiný token. |
| Name | Název tokenu. Zobrazuje se uživateli na portálu, proto by měl znít jako název faktoru, nikoli jako interní označení. |
| Description | Volný text, viditelný pouze pro správce. |
| OTP usable characters | Abeceda, ze které se kód generuje. |
| OTP Length | Počet znaků kódu. |
| Validity period of a token (seconds) | Doba, kterou má uživatel na zadání kódu, než bude kód odmítnut. |
| Message before the OTP | Věta, která v těle zprávy předchází kódu. |
| Mail subject | Předmět zprávy. |
| SMTP sender | Adresa odesílatele zprávy. |
| SMTP server | Server deklarovaný v kroku 1. |
Úplný seznam polí s jejich výchozími hodnotami a omezeními najdete na referenční stránce: Obecný blok a Doručování e-mailem.
Token uložíte kliknutím na Validate.
Krok 3 — Povolení tokenu u zprostředkovatele identity¶
Otevřete modul Identity Providers a upravte zprostředkovatele, který má OTP vyžadovat.
| Pole | Co zadat |
|---|---|
| Authentication token | Token vytvořený v kroku 2. Lze vybrat několik tokenů. |
| User attribute used to send the OTP | Název atributu uživatele, který obsahuje adresu, na kterou se kód odesílá. |
| Token expiration duration | Jak dlouho zůstává ověřené OTP přijímáno, než je znovu vyžádáno. 0 vypíná vypršení platnosti, což znamená, že se OTP vyžaduje při každém přihlášení. |
| Time unit | Hours nebo Days, uplatňuje se na předchozí pole. |
| Expiration starts | Zda odpočet začíná od posledního ověření OTP, nebo od posledního úspěšného přihlášení. |
Který atribut obsahuje adresu
Jde o atribut adresáře, na který odkazuje zprostředkovatel identity, nikoli o název podle našeho výběru: použijte atribut, ve kterém vaši uživatelé adresu skutečně mají. U místního adresáře se cílí na adresu zadanou ve vlastnostech uživatele; u adresáře LDAP jde o vlastní poštovní atribut adresáře.
Klikněte na Validate. Uživatelé tohoto zprostředkovatele identity budou při příštím přihlášení vyzváni k zadání kódu.
Krok 4 — Nejprve ověřte na testovacím zprostředkovateli identity¶
Povolení MFA u zprostředkovatele identity se uplatní na každého uživatele, který za ním stojí, včetně vás, pokud se přes něj přihlašujete. Než token povolíte u produkčního zprostředkovatele, vytvořte testovacího zprostředkovatele identity s jediným účtem a proveďte přes něj úplné přihlášení: identifikátor, heslo, přijetí zprávy, zadání kódu.
Uživatel bez adresy kód nikdy nedostane
Uživateli, jehož atribut je prázdný, nelze nic odeslat a jeho přihlášení nemůže být dokončeno. Ověřte, že je atribut vyplněn u každého účtu za zprostředkovatelem identity, dříve než na něm povolíte token.