Настройване на многофакторно удостоверяване¶
Многофакторното удостоверяване (MFA) изисква от потребителя второ доказателство в допълнение към неговия идентификатор и парола. CyberElements предлага няколко начина за получаването му. Тази страница разглежда четири от тях, в реда, в който обикновено се обмислят, след което описва подробно онзи, който няма собствена страница за интеграция: еднократната парола, изпращана по имейл.
Четири фактора, но не цялата картина
Тези четири са онези, които разглежда тази страница — те не са единствените втори фактори, които платформата може да поиска. Налични са също, извън обхвата на тази страница:
- OTP, изпращан чрез SMS, чрез един от многото оператори, предлагани от модула OTP Token Generators;
- конектор Radius към MFA решение на трета страна, чрез типа OTP - Radius на същия модул;
- удостоверяване със сертификат x509, което не е маркер, а метод за удостоверяване на самия домейн — User certificate или User certificate and form, за да се запази и паролата;
- MFA, наложено от входящ доставчик на SAML, или от всяко друго делегирано удостоверяване. Тогава вторият фактор се изисква, преди платформата да се включи, и тя нито го конфигурира, нито го вижда.
MFA се задава за доставчика на самоличност, никога за потребител
Който и фактор да изберете, той се активира за доставчик на самоличност и се прилага за всеки потребител, който влиза чрез него. Няма настройка за отделен потребител: за да подложите на MFA само част от потребителите си, поставете ги зад отделен доставчик на самоличност.
Избор на фактор¶
| Фактор | Какво прави потребителят | Какво изисква | Процедура |
|---|---|---|---|
| Neomia Pulse | Нищо. Потребителят се разпознава по начина, по който пише на клавиатурата си. | Опцията Neomia Pulse, доставчик на самоличност от тип local или LDAP и втори фактор от тази таблица за същия доставчик. |
Интеграция с Neomia Pulse |
| FIDO2 | Представя своя удостоверител — като включи ключ за защита или потвърди на устройството или в сейфа, който съхранява ключа за достъп — след което въвежда ПИН, ако удостоверителят го изиска. | Удостоверител FIDO2 за всеки потребител, relying party, декларирана в конзолата, и личен акаунт — анонимен доставчик на самоличност е изключен. | Интеграция с Yubico |
| TOTP | Прочита шестцифрен код в приложение за удостоверяване. | Приложение на телефона или работната станция на потребителя (Google Authenticator, FreeOTP, Microsoft Authenticator и т.н.) и една регистрация за всеки потребител. | Интеграция с Google Authenticator |
| OTP по имейл | Копира код, получен по имейл. | SMTP сървър, достъпен за платформата, и имейл адрес, съхранен в атрибут на потребителя. | Настройване на OTP по имейл |
Neomia Pulse се конфигурира в допълнение към друг фактор
Активирането на Neomia Pulse изисква в същия домейн да е активирано друго MFA. След това неговите настройки определят за какво се използва другият фактор: той може да бъде пропуснат, когато Pulse потвърди потребителя, и изискван, когато Pulse не го потвърди. Следователно Neomia Pulse е начин да се спести вторият фактор, а не да се замени.
Къде се декларира и къде се активира всеки фактор¶
Конфигурацията има два възможни етапа — деклариране на фактора в собствения му модул, след това активирането му за доставчика на самоличност — но два от четирите пропускат един от тях:
| Фактор | Деклариран в | Активиран за доставчика на самоличност |
|---|---|---|
| Neomia Pulse | няма нищо за деклариране | ✅ опцията Enable neomia Pulse authentication |
| FIDO2 | Relying parties | ❌ няма нищо за активиране — вижте бележката по-долу |
| TOTP | OTP Token Generators | ✅ като маркер за удостоверяване |
| OTP по имейл | SMTP сървър, след това OTP Token Generators | ✅ като маркер за удостоверяване |
FIDO2 няма превключвател в доставчика на самоличност
Ключовете за защита не се активират домейн по домейн: платформата предлага фактора веднага щом е декларирана поне една relying party, за всеки доставчик на самоличност, който не е анонимен — ключът трябва да бъде свързан с личен акаунт. И именно потребителят регистрира своя удостоверител от портала, а не администраторът го присвоява.
Neomia Pulse не изисква предварително деклариране
Pulse не е маркер, който се създава в модул: опцията се активира директно за доставчика на самоличност, където се задава и нейното поведение.
Останалата част от тази страница разглежда OTP по имейл от началото до края. Другите три фактора са описани на техните страници за интеграция, към които водят връзките в таблицата по-горе.
Настройване на OTP по имейл¶
OTP по имейл изпраща на потребителя код за еднократна употреба по имейл, след като неговият идентификатор и парола бъдат приети. Потребителят въвежда този код в портала, за да завърши влизането.
Преди да започнете: какво всъщност защитава OTP по имейл¶
OTP по имейл не винаги добавя фактор
Прочетете това, преди да изберете този фактор пред другите три.
Ако потребителят влиза със своя акаунт в Active Directory и получава кода в пощенска кутия, свързана със същия акаунт, вторият фактор не добавя почти нищо: нападател, който е получил идентификационните данни, отваря пощенската кутия със същите тези данни и прочита кода.
OTP по имейл си струва да се внедри, когато пощенската кутия не е достъпна с проверяваните идентификационни данни, т.е. когато:
- потребителят влиза с локален акаунт или с акаунт, различен от неговата пощенска кутия;
- кодът се изпраща на адрес, различен от този на акаунта за влизане.
Стъпка 1 — Осигуряване на наличен SMTP сървър¶
Кодът се изпраща от платформата чрез SMTP сървър, деклариран в модула SMTP servers. Ако все още няма наличен такъв, декларирайте го, преди да продължите:
Настройване на изпращането на имейли
След това използвайте блока SMTP configuration test на този модул, за да потвърдите доставката: неуспех, диагностициран на този етап, е неуспех, който няма да търсите по-късно в процеса на влизане.
Тестовото съобщение не използва подателя, който ще конфигурирате
Тестът изпраща от noreply@cleanroom.com — адрес, вграден в продукта: той не може да се промени никъде и служи също като адрес за отговор. Вашият собствен подател е SMTP sender на маркера, зададен в стъпка 2 — именно той стои в истинските съобщения с OTP.
Последствието си струва да се знае, преди да направите извод: SMTP сървър, който ограничава адресите на подателите, може да отхвърли теста, докато пропуска истинските съобщения, и обратното.
Връзката се отваря от платформата
Потокът към SMTP сървъра излиза от платформата, а не от работната станция на потребителя. Ако вашият SMTP сървър се намира във вашата LAN мрежа, този поток трябва да бъде разрешен.
Стъпка 2 — Създаване на маркера OTP¶
Отворете модула OTP Token Generators и щракнете върху +. В прозореца Add OTP token изберете типа OTP - email, след което попълнете полетата.
| Поле | Какво да въведете |
|---|---|
| OTP Type | OTP - email. Този избор не може да бъде променен впоследствие — различен канал означава различен маркер. |
| Name | Името на маркера. То се показва на потребителя в портала, затова трябва да звучи като име на фактор, а не като вътрешно означение. |
| Description | Свободен текст, видим само за администраторите. |
| OTP usable characters | Азбуката, от която се генерира кодът. |
| OTP Length | Броят знаци в кода. |
| Validity period of a token (seconds) | Колко време има потребителят да въведе кода, преди той да бъде отхвърлен. |
| Message before the OTP | Изречението, което предхожда кода в текста на съобщението. |
| Mail subject | Темата на съобщението. |
| SMTP sender | Адресът на подателя на съобщението. |
| SMTP server | Сървърът, деклариран в стъпка 1. |
Пълният списък с полета, със стойностите им по подразбиране и ограниченията, е на справочната страница: Общ блок и Доставка по имейл.
Щракнете върху Validate, за да запишете маркера.
Стъпка 3 — Активиране на маркера за доставчик на самоличност¶
Отворете модула Identity Providers и редактирайте доставчика, който трябва да изисква OTP.
| Поле | Какво да въведете |
|---|---|
| Authentication token | Маркерът, създаден в стъпка 2. Могат да бъдат избрани няколко маркера. |
| User attribute used to send the OTP | Името на атрибута на потребителя, който съдържа адреса, на който се изпраща кодът. |
| Token expiration duration | Колко дълго потвърденият OTP остава приет, преди да бъде изискан отново. 0 деактивира изтичането, което означава, че OTP се изисква при всяко влизане. |
| Time unit | Hours или Days, прилагани към предходното поле. |
| Expiration starts | Дали обратното броене започва от последното потвърждаване на OTP, или от последното успешно влизане. |
Кой атрибут съдържа адреса
Атрибутът е този на директорията, към която сочи доставчикът на самоличност, а не име по наш избор: използвайте атрибута, в който вашите потребители действително имат адрес. За локална директория целта е адресът, въведен в свойствата на потребителя; за директория LDAP — собственият атрибут за поща на директорията.
Щракнете върху Validate. При следващото си влизане потребителите на този доставчик на самоличност ще бъдат помолени да въведат код.
Стъпка 4 — Първо проверете с тестов доставчик на самоличност¶
Активирането на MFA за доставчик на самоличност го прилага за всеки потребител зад него, включително за вас, ако влизате чрез него. Преди да активирате маркера за производствения си доставчик, създайте тестов доставчик на самоличност с един-единствен акаунт и изпълнете чрез него пълно влизане: идентификатор, парола, получаване на съобщението, въвеждане на кода.
Потребител без адрес никога не получава код
На потребител, чийто атрибут е празен, не може да бъде изпратено нищо и влизането му не може да завърши. Проверете дали атрибутът е попълнен за всеки акаунт зад доставчика на самоличност, преди да активирате маркера за него.