Настройване на многофакторно удостоверяване¶
Многофакторното удостоверяване (MFA) изисква от потребителя второ доказателство в допълнение към неговия идентификатор и парола. CyberElements Bastion предлага няколко начина за получаването му. Тази страница разглежда четири от тях в реда, в който обикновено се обмислят, след което описва подробно този, който няма собствена страница за интеграция: еднократната парола, изпратена по имейл.
Четири фактора, но не цялата картина
Тези четири са онези, които разглежда тази страница — те не са единствените втори фактори, които платформата може да поиска. Налични са също, извън обхвата на тази страница:
- OTP, изпращан чрез SMS, чрез един от многото оператори, предлагани от модула OTP Token Generators;
- конектор Radius към MFA решение на трета страна, чрез типа OTP - Radius на същия модул;
- удостоверяване със сертификат x509, което не е маркер, а метод за удостоверяване на самия домейн — User certificate или User certificate and form, за да се запази и паролата;
- MFA, наложено от входящ доставчик на SAML, или от всяко друго делегирано удостоверяване. Тогава вторият фактор се изисква, преди платформата да се включи, и тя нито го конфигурира, нито го вижда.
MFA се задава в домейна за удостоверяване, никога за потребител
Който и фактор да изберете, той се активира в домейн за удостоверяване и се прилага за всеки потребител, който влиза чрез него. Няма настройка за отделен потребител: за да подложите на MFA само част от потребителите си, поставете тези потребители зад специален домейн за удостоверяване.
Избор на фактор¶
| Фактор | Какво прави потребителят | Какво изисква | Процедура |
|---|---|---|---|
| Neomia Pulse | Нищо. Потребителят се разпознава по начина, по който пише на клавиатурата си. | Опцията Neomia Pulse, настройките за връзка с вашата услуга Pulse, домейн за удостоверяване от тип local или LDAP и втори фактор от тази таблица в същия домейн. |
Интеграция на Neomia Pulse |
| FIDO2 | Представя своя удостоверител — като включи ключ за защита или потвърди на устройството или в сейфа, който съхранява ключа за достъп (passkey) — след което въвежда ПИН, ако удостоверителят го изиска. | По един удостоверител 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, плюс настройките за връзка с услугата Pulse — вижте бележката по-долу |
| FIDO2 | Relying parties | ❌ няма нищо за активиране — вижте бележката по-долу |
| TOTP | OTP Token Generators | ✅ като маркер за удостоверяване |
| OTP по имейл | SMTP сървър, след това OTP Token Generators | ✅ като маркер за удостоверяване |
FIDO2 няма превключвател в домейна за удостоверяване
Ключовете за защита не се активират домейн по домейн: платформата предлага фактора веднага щом бъде декларирана поне една доверяваща се страна (relying party), във всеки домейн за удостоверяване, който не е анонимен — ключът трябва да бъде свързан с личен акаунт. И именно потребителят регистрира своя удостоверител от портала, а не администраторът го присвоява.
Neomia Pulse не изисква предварително деклариране
Pulse не е маркер, който се създава в модул: опцията се активира директно в домейна за удостоверяване, където се задава и поведението ѝ.
Pulse се нуждае от настройките си за връзка
Поставянето на отметка в Enable neomia Pulse authentication показва три задължителни полета, които насочват платформата към вашата услуга Pulse:
| Поле | Какво да въведете |
|---|---|
| API URL | URL адрес на API на Pulse. |
| Authentication API URL | URL адрес на API за удостоверяване на Pulse. |
| API key | Ключ, който удостоверява платформата пред тази услуга. |
Домейнът за удостоверяване не се записва, докато и трите не бъдат попълнени.
Останалата част от тази страница разглежда 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 — Активиране на маркера в домейн за удостоверяване¶
Отворете модула Authentication domain и редактирайте домейна, който трябва да изисква 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 в домейн за удостоверяване го прилага за всеки потребител зад него, включително за вас, ако влизате чрез него. Преди да активирате маркера в производствения си домейн, създайте тестов домейн за удостоверяване с един-единствен акаунт и изпълнете чрез него пълно влизане: идентификатор, парола, получаване на съобщението, въвеждане на кода.
Потребител без адрес никога не получава код
На потребител с празен атрибут не може да бъде изпратено нищо и влизането му не може да завърши. Проверете дали атрибутът е попълнен за всеки акаунт зад домейна за удостоверяване, преди да активирате маркера в него.