Сотрудники компаний ежедневно переключаются между различными приложениями. Каждое из них требует надежного и уникального пароля, который необходимо регулярно менять, и что именно это означает, зависит от конкретного инструмента. Менеджеры паролей являются проверенным способом предотвратить постоянную утрату паролей вашими сотрудниками; однако они также требуют ввода пароля. Это приводит к ненужным обращениям в службу поддержки, снижению производительности и проблемам с безопасностью. Единый вход решает эту проблему, позволяя пользователям получать доступ к нескольким приложениям или системам через централизованную систему входа.

  • Единый вход (SSO) повышает IT-безопасность в вашей ITSM за счет централизованной аутентификации пользователей и упрощенного контроля доступа.
  • Использование процедуры единого входа повышает производительность за счет сокращения количества входов с помощью пароля.
  • Распространенные протоколы, такие как SAML, OAuth и LDAP, обеспечивают гибкую интеграцию в облачные и гибридные среды, такие как SeaTable.
  • Решения SSO, основанные в ЕС или локальные, соответствуют требованиям GDPR и предотвращают передачу данных в третьи страны.

Процедура SSO основана на токеновой коммуникации между веб-приложением и центральным поставщиком идентификационных данных (IdP).

Единый вход упрощает процесс регистрации пользователей.

  • Пользователи проходят однократную аутентификацию в IdP, например Okta или Authentik . Ответственный системный администратор предоставляет доступ ко всем авторизованным сервисам без необходимости повторного ввода паролей.
  • После успешной аутентификации SSO IdP генерирует токен SSO — своего рода сертификат безопасности, например, в виде SAML-утверждения (на основе XML) или JWT (JSON Web Token) — и сохраняет его либо в системе SSO, либо в веб-браузере. Токены SSO содержат информацию о соответствующем пользователе, например, имя пользователя и адрес электронной почты.
  • Если пользователь желает войти в веб-приложение, например SeaTable, с помощью процедуры SSO, приложение отправляет токен IdP, который сравнивается с существующим токеном SSO. Если пользователь может быть идентифицирован и имеет доступ к приложению, решение SSO проверяет токен аутентификации, и пользователь получает доступ к приложению.

Весь процесс входа занимает всего несколько секунд, при этом пользователь не замечает процесса аутентификации, происходящего в фоновом режиме. Если ваш сотрудник позже войдет в другое интегрированное приложение, оно сначала проверит, существует ли уже действительный токен от IdP. Если да, то пользователь автоматически авторизуется без необходимости повторного входа в систему. Это и есть «единственный» в Single Sign-On. Существует также Single Logout: когда пользователь выходит из веб-приложения, токен становится недействительным, и все другие связанные приложения также выходят из системы.

  • Централизованное управление вместо хранилищ паролей: вместо управления правами доступа в различных инструментах ваши ИТ-специалисты управляют ролями и разрешениями в одном централизованном месте. Это не только облегчает работу ваших ИТ-специалистов, но и снижает уязвимость и количество ручных ошибок.

  • Более широкое признание процессов цифровой трансформации: если переход на новые инструменты проходит гладко, без проблем с паролями, без сложностей с входом в систему и без опасений по поводу безопасности, ваши сотрудники быстрее примут изменения и, по оценкам, сэкономят около 30 минут рабочего времени в день, поскольку им не нужно будет вводить или сбрасывать пароли. Уже через две недели после внедрения SSO это составляет целый рабочий день, который можно посвятить продуктивным задачам. 

  • Повышенная ИТ-безопасность и соответствие нормативным требованиям: многие решения SSO требуют многофакторной аутентификации, а журналы аудита предоставляют полную информацию о том, кто и когда получал доступ к каким системам.

  • Предотвращение теневого ИТ: предоставляя сотрудникам простой и удобный доступ к утвержденным приложениям, ИТ-отдел снижает использование неавторизованных и потенциально небезопасных инструментов. Таким образом, SSO может помочь предотвратить появление теневых ИТ-структур .

Единый вход повышает уровень ИТ-безопасности.

Безопасность систем SSO основана на различных протоколах, которые регулируют обмен информацией между приложением и поставщиком идентификационных данных. Выбор наиболее подходящего для компании протокола в значительной степени зависит от ИТ-среды и требований. Для лучшего понимания мы представляем здесь основные протоколы.

SAML (Security Assertion Markup Language) на протяжении многих лет доминирует в корпоративных средах и является де-факто стандартом для SSO в масштабах предприятия, а также поддерживается управлением командой в SeaTable . В данном случае токен SSO представляет собой утверждение на основе XML — своего рода цифровое удостоверение — которое подписывается сертификатом. Преимущества единого входа с помощью SAML значительны:

  • SAML основан на браузере и беспрепятственно работает с классическими корпоративными приложениями.
  • SAML также поддерживает функцию единого выхода из системы — когда пользователь выходит из системы, IdP может одновременно завершить все сеансы.
  • Для регулируемых отраслей, таких как государственное управление, SAML является значительным преимуществом благодаря своим удобным для аудита журналам.

Однако SAML имеет и недостатки:

  • Формат XML сложен для отладки по сравнению с JSON.
  • SAML не является мобильно-дружественным.

OAuth 2.0 был специально разработан в качестве единого входа для облачных систем и подходит для сред с микрослужбами или API-соединениями. Известный под лозунгом «Войти с помощью Google» или «Войти с помощью Facebook», OAuth предоставляет делегированные права доступа без раскрытия фактического пароля. Он является мобильным: приложения на смартфонах и планшетах работают с OAuth без проблем. Подобно SAML, этот протокол также позволяет устанавливать гранулярные права доступа.

Недостаток: OAuth изначально был предназначен только для авторизации, а не для аутентификации. Чтобы исправить это, был разработан OpenID Connect (OIDC), который расширяет возможности OAuth и обеспечивает настоящую аутентификацию. Еще одним недостатком является несколько более сложная управление токенами обновления, чтобы пользователи не должны были повторно входить в систему при истечении срока действия токена.

Единый вход обеспечивает удобную регистрацию.

LDAP (Lightweight Directory Access Protocol) появился раньше SAML и OAuth и используется с 1990-х годов. LDAP хранит каталоги пользователей в виде древовидной структуры и традиционно используется Microsoft Active Directory (AD) в средах Windows. Таким образом, если вы используете исключительно среду Windows с локальными серверами, это решение является оптимальным.

Существенный недостаток: LDAP был разработан до появления облачных технологий и не оптимизирован для веб-SSO.

JSON Web Tokens (JWT) — это скорее технология, а не протокол SSO, но она становится все более важной для современных систем аутентификации. JWT представляет собой подписанный текстовый токен, содержащий информацию о пользователе, например, идентификатор пользователя, роли, срок действия. Поскольку каждый токен содержит всю информацию, а JSON Web Tokens оптимизированы для мобильных устройств, это решение хорошо подходит для масштабируемых децентрализованных систем и микросервисов, в том числе потому, что API могут очень легко проверять аутентификацию JWT.

Конечно, здесь также имеется недостаток: JSON Web Tokens не могут быть удалены и остаются действительными до истечения срока их действия. Например, после инцидента, связанного с безопасностью, или увольнения без уведомления, не всегда возможно немедленно лишить пользователя прав доступа.

Kerberos был ответом Microsoft на обеспечение безопасной сетевой аутентификации в доменах Windows. Он основан на системе билетов: клиент получает от сервера Kerberos билет, который позволяет ему получить доступ к определенной услуге без необходимости ввода пароля. В чистом домене Windows вы можете без проблем использовать Kerberos для входа с помощью SSO.

Однако строгая ориентация на локальную версию Windows также является существенным недостатком. Использование в качестве облачного SSO или в гибридных средах возможно только с дополнительными решениями. А современные мобильные приложения? Kerberos не предназначен для этого.

Если вы желаете использовать процедуру единого входа для вашей компании, вам потребуется инструмент управления идентификацией и доступом, или, сокращенно, поставщик идентификации. Там вы затем определяете для каждого аутентифицированного пользователя приложения, к которым будет предоставлен доступ. В настоящее время рынок соответствующих инструментов консолидировался и сократился до нескольких поставщиков, из которых мы представляем здесь наиболее значимых:

  • Okta: лидер рынка облачных решений с более чем 7000 предварительно настроенных интеграций приложений. Okta отличается обширными функциями (адаптивная многофакторная аутентификация, политики, основанные на рисках, аналитика) и надежной поддержкой, однако находится в США, поэтому ее использование с точки зрения законодательства о защите данных рекомендуется с осторожностью.  

  • Microsoft Entra ID (ранее Azure AD): Entra значительно расширилась и в настоящее время является главным конкурентом Okta. Система предоставляется бесплатно для пользователей Microsoft 365 и глубоко интегрирована в Microsoft. Однако, как и в случае с Okta, у этого американского решения существуют проблемы с защитой данных. Кроме того, интеграция приложений за пределами экосистемы Microsoft является сложной.

  • Authentik: это решение с открытым исходным кодом демонстрирует высокие показатели по всем параметрам (и используется нами в SeaTable в качестве IdP). Authentik может быть размещено на собственном хостинге, доступно бесплатно и поддерживает аутентификацию SAML, OAuth и LDAP. Недостаток: для настройки требуются технические знания, а поддержка предоставляется только сообществом.

Провайдеры идентификации обеспечивают единый вход.

  • OneLogin: OneLogin предлагает надежные функции и располагает глобальной инфраструктурой с серверами в Германии. Недостаток: OneLogin поддерживает примерно в два раза меньше приложений, чем Okta, и не предоставляет бесплатную поддержку.

  • Authelia: это наиболее легкое решение с открытым исходным кодом для процедур SSO. Authelia основано на прокси и идеально подходит, если вам требуется быстрое и простое решение для аутентификации SSO. Основной недостаток: строго говоря, Authelia не является полноценным IdP, а использует перенаправление аутентификации через обратные прокси вместо автономных протоколов.

Если система SSO подвергается взлому, злоумышленники могут получить доступ ко всей информации для входа в систему. Не создает ли это чрезмерно высокий риск для безопасности? Этот вопрос вполне обоснован, однако на него нельзя ответить однозначно «да» или «нет».

Несомненно, с помощью решений Single Sign-On вы концентрируете риск, поэтому взлом IdP является очень серьезной проблемой. Однако процедуры SSO также предоставляют преимущества, которые компенсируют этот риск:

1. С помощью SSO количество паролей в обращении уменьшается. Каждый децентрализованно хранящийся пароль повышает риск взлома хакерами.

2. IdP может потребовать, чтобы каждый пользователь использовал второй фактор аутентификации. Многофакторная аутентификация (MFA) блокирует 99 % всех фишинговых атак.

3. Токены SSO имеют короткий срок действия. Например, украденный токен SAML или JWT действителен только в течение часа, а затем истекает. Украденный пароль может работать в течение нескольких месяцев.

Таким образом, использование единого входа не обеспечивает стопроцентную безопасность, особенно если не требуется MFA. Однако при правильной реализации SSO обеспечивает уровень защиты, который практически невозможно достичь с помощью децентрализованно управляемых паролей.

Для единого входа часто требуется многофакторная аутентификация.

Решения для единого входа (Single-Sign-On) могут также использоваться локально. Однако чаще всего аутентификация SSO используется в облачных средах. Поэтому ответственные ИТ-менеджеры при выборе соответствующего решения должны всегда учитывать вопросы защиты данных и соблюдения законодательства. Особое внимание следует уделить следующим аспектам:

1. Какие данные передаются? При использовании SSO в облаке информация о пользователях передается от IdP к приложению. Эти данные являются личными и, следовательно, подпадают под действие законодательства о защите данных. С точки зрения европейского GDPR, особенно критичной является ситуация, когда IdP находится в США и передает туда данные. Поэтому мы рекомендуем использовать европейского поставщика идентификационных услуг или локальное решение, такое как Authentik. 

2. Обратите внимание на согласие и экономию данных. GDPR требует, чтобы пользователи сознательно соглашались на передачу своих данных третьим лицам. Поэтому надежный IdP обеспечивает прозрачность в отношении того, какие данные передаются различным приложениям.

3. Работайте с аккуратно веденными журналами аудита. Статья 5 GDPR обязывает компании, собирающие персональные данные, отчитываться о законности и безопасности их обработки. В данном случае это означает, что ответственные лица должны отслеживать, кто, когда и где входил в систему. Хорошая новость: как правило, поставщики идентификационных данных автоматически регистрируют это в псевдонимизированном виде. 

4. Вы должны иметь возможность удалять пользователей. Статья 17 GDPR регулирует право на удаление. Независимо от этого, в интересах каждой компании предоставлять сотрудникам только тот доступ, который им действительно необходим, и блокировать доступ бывших сотрудников. Система SSO должна упростить процесс удаления пользователя, при необходимости — немедленно. 

SeaTable — это не просто хостинг в Германии, соответствующий требованиям GDPR, решение AI No-Code для гибких баз данных, автоматизации с поддержкой AI и создания приложений. Как инструмент для цифровой трансформации бизнес-процессов, он уже сейчас легко интегрируется в существующие IT-ландшафты благодаря SeaTable API.

Подписчики Enterprise SeaTable Cloud и пользователи локального предложения SeaTable Server могут настроить вход через Single-Sign On, что обеспечивает еще большую безопасность. Интеграция проста и занимает всего несколько минут. Пользователи облачной версии должны зарегистрироваться у поставщика идентификационных данных, поддерживающего SAML 2.0, который используется SeaTable в качестве протокола аутентификации. В нашей статье справки о едином входе описаны все шаги. Клиенты сервера также могут использовать LDAP или JWT. Подробную информацию можно найти в руководстве администратора .

Будьте в курсе событий
Подпишитесь на нашу новостную рассылку, чтобы оставаться в курсе последних новостей в области ИТ-безопасности и защиты данных.

Что необходимо для использования SSO?

Вам потребуется только рабочий домен электронной почты и поставщик идентификационных данных для единого входа, такой как Okta или Authentik.

Можно ли легко отозвать предоставленные права доступа для единого входа?

В принципе, вы можете аннулировать токены SSO и удалить пользователей, чтобы, например, бывшие сотрудники больше не имели доступа. Однако при аутентификации через JWT токен не может быть удален немедленно, а остается активным до установленного срока действия.

Можно ли использовать процедуру единого входа с несколькими поставщиками идентификации?

Нет, это невозможно. Все пользователи для настроенных вами доменов должны управляться в одном поставщике идентификации.

Что такое токен SSO?

Токен SSO — это набор данных или информации, который передается от одной системы к другой во время процедуры SSO. Токены подписываются поставщиками идентификационных данных цифровой подписью, чтобы получатель токена мог проверить, что он получен из надежного источника. Сертификат безопасности, необходимый для этой цифровой подписи, предоставляется при первоначальной настройке IdP.

Какие поставщики идентификации могут взаимодействовать с SeaTable Cloud?

Мы рекомендуем использовать Okta, Authentik или Microsoft Entra ID.

TAGS: ИТ-Безопасность И Конфиденциальность Данных Цифровая Трансформация