SSO, ключове за достъп и двуфакторен вход в Desk & Park

Представете си Кася, единственият IT специалист в компания със 180 души, която току-що е преминала към хибриден офис. Понеделник е, 8:40. Вече чакат три заявки: една колежка е забравила паролата си за инструмента за резервиране на бюра, друга не може да намери имейла с кода си за вход, а ръководител на екип пита дали изпълнителят, който напусна в петък, все още може да резервира паркомясто. Кася е прекарала две години в това да постави всяко приложение зад доставчика на идентичност на компанията. Инструментът за резервиране на бюра е единственият, който все още има собствени пароли.

Ето как работи влизането в Desk & Park, какво би настроила Кася и единственото място, където продуктът нарочно нарушава правилото „всичко през SSO“. Всичко това е достъпно във всеки план, включително безплатния план Start.

Стъпка 1: свържете доставчика на идентичност (SSO чрез OpenID Connect)

Desk & Park поддържа единен вход чрез OpenID Connect – стандарта, който говорят Microsoft Entra ID, Google Workspace, Okta и повечето други доставчици на идентичност. Потокът е authorization code с PKCE – вариантът, препоръчван за уеб приложения.

Кася отваря Настройки на организацията → Единен вход (SSO) и попълва четири полета:

1. Issuer URL: за Google https://accounts.google.com, за Entra https://login.microsoftonline.com/<tenant-id>/v2.0 или издателят на всеки друг OIDC доставчик.
2. Client ID и Client secret от регистрацията на приложение, която тя създава в конзолата на доставчика си. Тайната се съхранява криптирана и никога не се показва отново; за да я смени, Кася въвежда нова.
3. Разрешен имейл домейн (по избор). Ако е зададен, само адреси от този домейн могат да влизат чрез SSO, така че личен акаунт, който случайно съществува в доставчика, не може да влезе.
4. Картата показва Redirect URI, който трябва да се постави обратно в регистрацията на приложението.

Тя отмята Включване на SSO и запазва. Страницата за вход вече показва Вход чрез SSO, а колежката, която е забравила паролата си, използва същия акаунт в Microsoft или Google като за имейла. Една организация свързва един доставчик.

Какво SSO не прави само по себе си: не създава акаунти

Първото влизане чрез SSO не създава акаунт. Ако някой се удостовери успешно при доставчика, но няма акаунт в Desk & Park, той бива върнат на страницата за вход със съобщение да поиска покана от администратора си. Акаунтите се създават от администратор: с покани една по една, импортирани от списък или провизирани автоматично от Entra ID или Okta чрез SCIM, което описваме в SCIM провизиране и офбординг.

Това има значение за третата заявка на Кася: блокирането на някого при доставчика е само половината от офбординга. Другата половина е деактивирането на акаунта в Desk & Park и прекратяването на сесиите му, което SCIM прави, когато човекът бъде деактивиран в директорията.

Кой проверява втория фактор при влизане чрез SSO

Когато някой влиза чрез SSO, доставчикът на идентичност вече го е удостоверил, затова Desk & Park не добавя собствена стъпка с код отгоре. Вторият фактор е този, който изисква вашият доставчик. Ако политиката ви в Entra или Okta изисква MFA, това е MFA, през която минават вашите служители.

Стъпка 2: умишленото изключение – администраторите

Ето частта, която изненадва някои IT екипи: администраторските акаунти не могат да влизат чрез SSO. Това е нарочно.

Влизането чрез SSO разпознава човека по имейл адреса. Ако доставчикът на идентичност някога бъде конфигуриран погрешно или компрометиран, онзи, който го контролира, би могъл да представи имейл адреса на администратор и да влезе в административната конзола на системата за резервации. За да остане тази врата затворена, администраторите използват собствените фактори на платформата: парола, ключ за достъп или код по имейл, последвани от кода от приложението за удостоверяване, след като са включили двуфакторната защита.

Затова практическото правило за Кася е: всеки администраторски акаунт трябва да включи двуфакторна автентикация в Настройки → Сигурност, като се започне от нейния собствен. Продуктът не го налага и точно затова то трябва да е в контролния ѝ списък.

Стъпка 3: ключове за достъп за хората, които мразят пароли

Ключът за достъп (passkey, WebAuthn) позволява на човек да влезе с пръстов отпечатък, разпознаване на лице или ПИН кода на устройството, без парола за запомняне или за фишинг. Всеки потребител добавя такъв за себе си в Настройки → Сигурност → Ключове за достъп („Добавяне на ключ за достъп“), като по избор му дава име („MacBook“, „iPhone“). Списъкът показва кога е добавен и кога е използван за последно всеки ключ и всеки от тях може да бъде премахнат.

Подробност, която има значение при прегледите на сигурността: ключ за достъп, използван с проверка на потребителя (пръстов отпечатък, лице или ПИН), се брои сам по себе си за два фактора и завършва влизането. Ключ за достъп, използван без проверка на потребителя, се третира само като притежание, така че акаунт с включена двуфакторна защита все пак минава през стъпката с код след това.

Стъпка 4: двуфакторна защита с приложение за удостоверяване

Двуфакторната защита в Desk & Park е TOTP: шестцифреният код от приложение за удостоверяване. Всеки потребител я включва в Настройки → Сигурност; оттам нататък всяко влизане с парола, код по имейл или ключ за достъп без проверка на потребителя изисква кода.

Потребителят получава и еднократни кодове за възстановяване: ако телефонът бъде загубен, един код го пуска да влезе и след това се изразходва. Кодовете могат да се генерират наново, а включването и изключването на двуфакторната защита се записват в дневника за сигурност.

Стъпка 5: сесии, които можете да видите и да прекратите

В Настройки → Сигурност → Активни сесии всеки потребител вижда къде е влязъл (браузър, операционна система, IP адрес, начален час) и може да прекрати всяка сесия или да избере Изход навсякъде.

Зад кулисите още два механизма вършат тиха работа:

• Ротация на токените за опресняване. Всеки път, когато сесията се подновява, старият токен се заменя. Ако вече използван токен бъде представен отново, което е знак, че е бил копиран, цялата сесия се прекратява.
• Заключване след повтарящи се неуспехи. След повтарящи се неуспешни опити следващите опити се блокират за известно време, а заключването се появява в дневника за сигурност.

Практични съвети за въвеждането

• Започнете с администраторите. Преди да обявите SSO, уверете се, че всеки администратор има включена двуфакторна защита и добавен ключ за достъп. Те няма да могат да използват SSO, така че собственото им влизане трябва да е силно.
• Задайте разрешения имейл домейн, ако вашият доставчик на идентичност съдържа и гостуващи или лични акаунти.
• Решете как ще се създават акаунтите. За малък офис поканите са достатъчни. За всичко по-голямо свържете SCIM, така че постъпващите и напускащите да идват от директорията.
• Нека съобщението е кратко. „Използвайте „Вход чрез SSO“ – същия акаунт като за имейла ви“ е достатъчно.
• Преглеждайте от време на време потока за сигурност. Влизанията, неуспехите, заключванията и промените в двуфакторната защита се появяват в одитния дневник на администратора; описваме го в одитния дневник и достъпа на поддръжката.

Обхват: какво не прави

За да са очакванията честни: единният вход е само OpenID Connect, така че няма SAML. Няма политика за цялата организация, която да налага двуфакторна защита на всеки потребител, няма настройваемо време за изтичане на сесията, няма списък с разрешени IP адреси и няма режим „само SSO“, който да изключва другите методи за влизане. Двуфакторната защита е личен избор на всеки потребител, затова и контролният списък по-горе започва с администраторите. Къде се съхраняват самите данни, е отделна тема, разгледана в защо данните за работното ви място се нуждаят от изолирана база данни.

Плановете и лимитите са на страницата с цените; настройката на цял офис е описана в ръководството за въвеждане.

Често задавани въпроси