Идентификация и аутентификация#
Общая модель идентификации и аутентификации#
В системе допускается использование следующих способов аутентификации:
Локальная аутентификация средствами платформы.
Аутентификация через внешний контур единого входа по протоколу OpenID Connect.
Аутентификация доменных пользователей с проверкой пароля внешней службой каталогов.
Аутентификация через внешний прокси-сервер авторизации.
Аутентификация технических подключений к REST- и SOAP-сервисам по схемам
BasicиBearer, включая постоянные токены и JWT.
При локальной аутентификации проверка учетных данных выполняется средствами Global ERP с применением встроенной политики паролей.
При использовании единого входа проверка учетных данных осуществляется внешним поставщиком идентификационных данных. Global ERP использует результат успешной аутентификации и применяет собственную модель авторизации.
При использовании внешнего прокси-сервера аутентификация пользователя осуществляется на стороне сервера авторизации. По результатам успешной аутентификации прокси-сервер формирует JWT-токен и передает его в Global ERP. Система валидирует токен и предоставляет доступ к функционалу в пределах назначенных прав доступа.
Для технических подключений к сервисам используются штатные HTTP-механизмы аутентификации. Для интеграционных сценариев поддерживаются логин и пароль, токены сервера приложений, долгоживущие пользовательские токены и JWT-токены, подписанные пользователем или прокси-пользователем.
Независимо от используемого механизма аутентификации, прикладная модель авторизации и проверка прав доступа реализуются в контуре Global ERP.
Идентификация пользователей#
Идентификация пользователя в Global ERP осуществляется по уникальному идентификатору учетной записи. Указанный идентификатор используется в качестве логина и связывает учетную запись пользователя, механизмы аутентификации, назначенные роли и регистрируемые действия.
При локальной аутентификации идентификатор используется во внутреннем контуре Global ERP.
При аутентификации через внешние службы каталогов или внешний контур единого входа должно обеспечиваться однозначное сопоставление учетной записи пользователя в Global ERP с соответствующей внешней учетной записью. Для технических подключений идентификация осуществляется с использованием учетной записи пользователя, служебной учетной записи либо токена, связанного с учетной записью. Во всех случаях идентификатор должен однозначно определять субъект доступа.
Локальная аутентификация#
При локальной аутентификации пользователь проходит встроенную процедуру аутентификации средствами платформы.
За включение централизованной настройки парольной политики отвечает флаг bPasswordSettingsInOT в классе Btk_Setting. При включенном флаге параметры задаются для типа объекта пользователя через Btk_UserPasswordSetting. При отключенном флаге применяются параметры из класса Btk_User.
Внутренняя реализация системы обеспечивает хранение паролей только в виде хэшей Argon2id. Исходное значение пароля не сохраняется и не может быть восстановлено по хэшу.
Для контроля повторного использования ранее применявшихся паролей используется сервис истории паролей. Значения предыдущих паролей сохраняются в журнале в хэшированном виде. Это позволяет проверять совпадение нового пароля с ранее использованными без раскрытия их исходных значений.
Проверка соответствия пароля установленным требованиям выполняется при его создании и смене. По истечении срока действия пароля система переводит пользователя в режим обязательной смены и при необходимости генерирует временный пароль.
Парольная политика#
В Global ERP реализована комплексная политика паролей, направленная на обеспечение информационной безопасности. Политика охватывает:
требования к минимальной длине и составу пароля;
историю паролей и запрет повторного использования;
проверку паролей по словарям и черным спискам;
сроки действия постоянного и временного пароля;
уведомления о необходимости смены пароля.
Для локальной аутентификации применяются следующие параметры политики паролей:
обязательное использование специальных символов;
обязательное сочетание букв и цифр;
обязательное использование букв в разных регистрах;
минимальная длина пароля;
запрет на повторное использование определенного числа предыдущих паролей;
минимальный срок действия пароля;
срок действия постоянного пароля;
срок действия временного пароля;
период предварительного уведомления о необходимости смены пароля.
Параметры парольной политики настраиваются в соответствии с руководством по политике паролей.
Рекомендуемая базовая конфигурация предусматривает:
минимальную длину пароля не менее 8 символов для обычных пользователей и не менее 12 символов для администраторов и привилегированных учетных записей;
использование не менее 3 категорий символов;
ограничение срока действия пароля;
обязательную смену временного пароля при первом входе;
ведение истории паролей.
Использование простых, предсказуемых и скомпрометированных паролей запрещено.
Автоматическая генерация паролей#
При создании локальных учетных записей в системе может использоваться автоматическая генерация временного пароля в соответствии с действующей парольной политикой.
Сгенерированный пароль:
соответствует установленным требованиям сложности;
формируется с использованием криптографически стойкого генератора случайных значений;
исключает использование предсказуемых последовательностей и словарных комбинаций;
отображается администратору однократно в момент создания учетной записи.
После завершения операции создания пользователя повторное отображение исходного значения пароля средствами системы не выполняется.
Для учетных записей, созданных с автоматически сгенерированным временным паролем, рекомендуется обязательная смена пароля при первом входе пользователя в систему.
Защита от подбора паролей#
Для предотвращения подбора паролей в локальном контуре аутентификации реализуется временная блокировка учетной записи пользователя при превышении допустимого количества последовательных неудачных попыток входа.
Параметр jTempBlockingForUnsuccessfulLogin определяет максимально допустимое количество неудачных попыток и продолжительность блокировки в минутах. При превышении установленного лимита система временно блокирует учетную запись.
В рекомендуемой конфигурации блокировка производится после 10 неудачных попыток входа сроком не менее 3 минут.
При использовании единого входа защита от подбора паролей дополнительно обеспечивается на стороне внешнего поставщика идентификационных данных. В сценариях OpenID Connect поддерживается настройка параметров механизма обнаружения перебора паролей: Max login failures, Wait increment и Quick login check.
Защита сеансов#
Система обеспечивает автоматический разрыв сеанса при отсутствии активности пользователя.
Политики управления сеансами, включая обязательность разрыва и значения таймаутов, настраиваются на уровне конфигурации системы.
Управление сеансами распространяется на пользовательские подключения и применяется как элемент общего контура идентификации, аутентификации и защиты доступа.
Завершение сеанса#
Сеанс работы пользователя может быть завершен по одному из следующих оснований:
По инициативе пользователя — через штатную функцию выхода из системы.
По таймауту бездействия — при отсутствии действий пользователя в течение интервала, заданного параметром
clientTimeoutв конфигурационном файле.По инициативе администратора — через функции администрирования активных сессий.
По иным условиям, предусмотренным конфигурацией системы.
Повторная идентификация и аутентификация#
После завершения сеанса доступ к функционалу системы возможен только после повторного прохождения идентификации и аутентификации штатными механизмами. При завершении сеанса интерфейс системы автоматически возвращается к окну аутентификации, предоставляя возможность начала нового сеанса.
Аутентификация через LDAP, Active Directory и ALDPro#
Global ERP поддерживает аутентификацию пользователей через внешние службы каталогов, включая LDAP-каталоги, Active Directory и ALDPro. Для этого в конфигурации сервера приложений настраивается подключение к каталогу, а для базы данных активируется режим authenticationType="ldap".
В указанном режиме проверка пароля пользователя не выполняется средствами платформы, а передается внешней службе каталогов для подтверждения подлинности.
Параметры парольной политики для доменных пользователей определяются корпоративной службой каталогов предприятия, включая групповые политики Active Directory или аналогичные политики LDAP/ALDPro. Смена пароля пользователя выполняется средствами операционной системы с пользовательского рабочего места, в том числе при очередном входе, если такая смена требуется политикой службы каталогов. Global ERP в этом сценарии не хранит доменный пароль и не управляет его сменой, а использует результат проверки учетных данных, выполненной службой каталогов.
Параметры подключения к службе каталогов задаются в конфигурации <ldap .../> и включают, в частности, адрес LDAP-сервера и домен. Данный режим применяется для аутентификации доменных пользователей при сохранении прикладной модели ролей внутри Global ERP.
Система поддерживает синхронизацию пользователей из внешних служб каталогов. Для этого используется сервис LDAP-синхронизации, настраиваемый в модуле Btk. Сервис обеспечивает загрузку пользователей из указанных доменов, фильтрацию по группам и выбор режимов синхронизации в соответствии с выбранным сценарием. При необходимости к системному имени пользователя может быть добавлен домен в формате User@Domain.
Синхронизация учетных записей и аутентификация по доменному паролю являются самостоятельными процессами и могут применяться совместно. Пользовательские учетные записи могут предварительно загружаться в систему через сервис синхронизации, после чего аутентификация выполняется через домен или внешний контур единого входа.
Настройка выполняется в соответствии с инструкцией по LDAP-синхронизации и описанием параметров LDAP в конфигурации базы.
Процесс аутентификации с помощью единого входа#
Поддержка единого входа реализована в компоненте Global Server через протокол OpenID Connect с использованием внешнего поставщика идентификационных данных. Настройка выполняется на стороне сервера приложений посредством блока <openId> в файле global3.config.xml.
Процесс аутентификации при использовании единого входа включает следующие этапы:
Пользователь инициирует вход в систему.
Аутентификация выполняется внешним провайдером идентификации.
На стороне внешнего провайдера могут использоваться федерация пользователей через LDAP, Active Directory или ALDPro, защита от подбора паролей и дополнительные факторы аутентификации.
После успешной аутентификации пользователю предоставляется доступ к функциям системы в рамках назначенных ролей и полномочий в Global ERP.
Во внешнем SSO-контуре могут использоваться корпоративные службы каталогов и механизмы многофакторной аутентификации, включая одноразовые пароли и приложения-аутентификаторы. Настройка второго фактора осуществляется на стороне поставщика идентификационных данных и может включать одноразовые коды, подтверждения по электронной почте, SMS, приложения-аутентификаторы и другие поддерживаемые провайдером методы.
Настройка выполняется в соответствии с руководством по настройке SSO. Настройка второго фактора описана в документации по настройке 2FA.
Аутентификация через внешний прокси-сервер авторизации#
Global ERP поддерживает работу с внешним сервером авторизации gs-authproxy и совместимыми внешними сервисами авторизации. Данный режим применяется в сценариях, когда требуется вынести первичную аутентификацию пользователей во внешний контур, например для предоставления доступа пользователям внешних организаций к выделенному функционалу.
В схеме работы данного режима входящий запрос пользователя направляется на балансирующий или проксирующий узел, после чего поступает на внешний сервер авторизации или непосредственно в Global ERP. Внешний сервер авторизации проверяет учетные данные пользователя и при успешной аутентификации генерирует JWT-токен. Пользователь передается в Global ERP с полученным токеном, где система выполняет проверку токена, сопоставляет пользователя с внутренней учетной записью и применяет ролевую модель доступа.
В этом режиме внешний прокси обеспечивает первичную аутентификацию и выдачу токена, а Global ERP — проверку токена, сопоставление учетной записи и применение полномочий.
Подробнее см. в разделе Развертывание сервера приложений GS с сервером авторизации.
Аутентификация технических подключений и сервисов#
Для технических подключений к REST- и SOAP-сервисам поддерживаются HTTP-схемы аутентификации Basic и Bearer.
При Basic-аутентификации клиент передает в запросе имя пользователя, пароль и имя базы. Имя пользователя и пароль кодируются в Base64 и передаются через заголовок Authorization в формате Basic {Base64Cred}, где {Base64Cred} — строка user:password. Имя базы может передаваться через сегмент URL, заголовок Database или HTTP-параметр Database. При отсутствии указания используется база по умолчанию, определяемая конфигурацией global3.config.xml.
При Bearer-аутентификации клиент передает токен аутентификации и имя базы. Для интеграционных сценариев могут использоваться токены сервера приложений, постоянные пользовательские токены и JWT-токены.
Поддерживаются следующие варианты JWT-аутентификации:
UserHash— долгоживущий токен пользователя;UserCrt— JWT, подписанный пользователем;ProxyCrt— JWT, подписанный прокси-пользователем для выполнения действий от имени другого пользователя.
Долгоживущий токен формируется администратором и привязывается к учетной записи пользователя. Подписанные JWT используют RSA-ключи, сопоставленные с учетной записью пользователя или прокси-пользователя. Проверка действительности токена выполняется системой с использованием открытого ключа, хранящегося в базе данных решения.
Подробнее см. в разделе Аутентификация в REST/SOAP-сервисах.
Аутентификация устройств#
Для устройств могут использоваться механизмы аутентификации с применением сертификатов и дополнительных атрибутов идентификации. В зависимости от архитектуры внедрения может использоваться интеграция с внешними системами управления устройствами класса MDM.
Использование таких механизмов допускается только в рамках штатного контура безопасности и не отменяет требований к сопоставлению устройства, учетной записи и назначенных прав доступа.
Источники учетных данных#
В зависимости от архитектуры конкретного внедрения источником учетных данных могут выступать:
локальная учетная запись Global ERP;
внешняя служба каталогов LDAP, Active Directory или ALDPro;
внешний провайдер идентификации в SSO-контуре;
внешний прокси-сервер авторизации, выдающий JWT;
учетные данные или токены, используемые для подключения к техническим сервисам.
Независимо от источника первичной аутентификации, учетные записи пользователей хранятся в базе данных Global ERP. Назначение ролей и проверка прав выполняются в контуре системы и описаны в разделе «Управление доступом».
Требования к расширениям и функциональному дизайну#
Расширения и прикладные доработки обязаны использовать штатный контур идентификации и аутентификации Global ERP. Реализация изолированных механизмов входа, параллельных хранилищ паролей или обходных сценариев аутентификации не допускается. Аутентификация расширений должна выполняться одним из штатных способов, предусмотренных платформой.