Регламент идентификации и аутентификации в Global ERP#

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

В Global ERP реализован единый контур идентификации и аутентификации пользователей, внешних пользователей, устройств и технических подключений. Аутентификация в системе осуществляется с использованием следующих механизмов:

локальная аутентификация средствами платформы;
аутентификация с использованием внешнего SSO-контура по протоколу OpenID Connect;
аутентификация доменных пользователей через службы каталогов LDAP, Active Directory и ALDPro;
аутентификация через внешний прокси авторизации;
штатные механизмы аутентификации технических подключений к REST- и SOAP-сервисам.

Доступ к функциям, данным, журналам событий и системным API предоставляется исключительно в соответствии с назначенными ролями и полномочиями. Проверка прав доступа выполняется средствами Global ERP при каждом обращении к прикладным функциям, объектам данных и сервисным интерфейсам.

Расширения и прикладные доработки обязаны использовать штатные механизмы идентификации и аутентификации платформы. Реализация собственных изолированных механизмов аутентификации, хранения учетных данных или обхода штатных механизмов безопасности не допускается.

Область действия#

Настоящий регламент распространяется на:

пользователей системы Global ERP;
внешних пользователей;
администраторов системы;
интеграционные и технические подключения;
устройства, участвующие в доверенном контуре доступа;
все среды эксплуатации системы.

Нормативная база#

Документ разработан с учетом следующих нормативных и методических источников:

Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»;
внутренние нормативные документы ООО «Бизнес Технологии» в области информационной безопасности;
руководство по безопасной эксплуатации и сопровождению компонентов платформы Global ERP.

При подготовке и применении настоящего регламента следует также учитывать смежные разделы документации платформы Global ERP:

Классификация пользователей и учетных записей#

Для целей управления доступом и разграничения полномочий учетные записи в системе Global ERP подразделяются на следующие категории:

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

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

Общая модель идентификации и аутентификации#

В системе допускается использование следующих способов аутентификации:

локальная аутентификация средствами платформы;
аутентификация через внешний контур единого входа по протоколу OpenID Connect;
аутентификация доменных пользователей с проверкой пароля внешней службой каталогов;
аутентификация через внешний прокси-сервер авторизации;
аутентификация технических подключений к REST- и SOAP-сервисам по схемам Basic и Bearer, включая постоянные токены и JWT.

При локальной аутентификации проверка учетных данных выполняется средствами Global ERP с применением встроенной политики паролей.

При использовании единого входа проверка учетных данных осуществляется внешним поставщиком идентификационных данных, при этом Global ERP использует результат успешной аутентификации и применяет собственную модель авторизации.

При использовании внешнего прокси-сервера аутентификация пользователя осуществляется на стороне сервера авторизации. По результатам успешной аутентификации прокси-сервер формирует JWT-токен и передает его в Global ERP. Система валидирует токен и предоставляет доступ к функционалу исключительно в пределах назначенных прав доступа.

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

Независимо от используемого механизма аутентификации, прикладная модель авторизации и проверка прав доступа реализуются в контуре Global ERP.

Идентификация пользователей#

Идентификация пользователя в Global ERP осуществляется по уникальному идентификатору учетной записи. Указанный идентификатор используется в качестве логина и является основным атрибутом, связывающим учетную запись пользователя, механизмы аутентификации, назначенные роли и регистрируемые действия.

При локальной аутентификации идентификатор используется во внутреннем контуре Global ERP.

При аутентификации через внешние службы каталогов или внешний контур единого входа должно обеспечиваться однозначное сопоставление учетной записи пользователя в Global ERP с соответствующей внешней учетной записью.

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

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

Ролевая модель доступа#

В Global ERP применяется ролевая модель доступа с разграничением полномочий на уровне платформы и прикладных компонентов. Предоставление доступа к функциям, данным, журналам событий и API осуществляется строго на основании назначенных ролей.

Ролевая модель используется как основной механизм разграничения прав и поддерживает:

разделение полномочий между различными категориями пользователей;
ограничение доступа к критически важным операциям;
контроль привилегий при обращении к системным и сервисным API;
запрет совмещения конфликтующих ролей;
интеграцию с внешними IDM-системами.

Независимо от источника первичной аутентификации, прикладные роли и полномочия назначаются и проверяются в контуре Global ERP. Роли могут назначаться администратором системы вручную или через внешнюю систему управления идентификацией и доступом, интегрированную с Global ERP.

Контроль привилегий#

Контроль привилегий в Global ERP осуществляется на основе ролевой модели и реализуется средствами платформы на серверной стороне.

Проверка прав доступа выполняется при каждом обращении к:

прикладным операциям;
объектам данных;
системным и сервисным API;
REST- и SOAP-сервисам;
административным функциям и иным критичным интерфейсам.

Доступ к функциональности системы предоставляется исключительно при наличии соответствующих привилегий. При отсутствии необходимых прав выполнение операции запрещается.

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

Безопасность интерфейса доступа#

Для неавторизованных пользователей доступ ограничен минимальным набором функций, включая только страницы входа и восстановления пароля. Информация о внутренней структуре и компонентах системы не раскрывается.

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

imgpass

После успешной аутентификации доступ к функциональности системы предоставляется в соответствии с назначенными ролями и полномочиями.

Локальная аутентификация#

При локальной аутентификации пользователь проходит встроенную процедуру аутентификации средствами платформы.

За включение централизованной настройки парольной политики отвечает флаг bPasswordSettingsInOT в классе Btk_Setting. При включенном флаге параметры задаются для типа объекта пользователя через Btk_UserPasswordSetting. При отключенном флаге применяются параметры из класса Btk_User.

Внутренняя реализация системы обеспечивает хранение паролей исключительно в виде хэшей Argon2id. Исходное значение пароля не сохраняется и не может быть восстановлено по хэшу.

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

Проверка соответствия пароля установленным требованиям выполняется при его создании и смене. По истечении срока действия пароля система переводит пользователя в режим обязательной смены и при необходимости генерирует временный пароль.

Парольная политика#

В Global ERP реализована комплексная политика паролей, направленная на обеспечение информационной безопасности. Политика охватывает:

требования к минимальной длине и составу пароля;
историю паролей и запрет повторного использования;
проверку паролей по словарям и черным спискам;
сроки действия постоянного и временного пароля;
уведомления о необходимости смены пароля.

Для локальной аутентификации применяются следующие параметры политики паролей:

обязательное использование специальных символов;
обязательное сочетание букв и цифр;
обязательное использование букв в разных регистрах;
минимальная длина пароля;
запрет на повторное использование определенного числа предыдущих паролей;
минимальный срок действия пароля;
срок действия постоянного пароля;
срок действия временного пароля;
период предварительного уведомления о необходимости смены пароля.

Рекомендуемая базовая конфигурация предусматривает:

минимальную длину пароля не менее 8 символов для обычных пользователей и не менее 12 символов для администраторов и привилегированных учетных записей;
использование не менее трех категорий символов;
ограничение срока действия пароля;
обязательную смену временного пароля при первом входе;
ведение истории паролей.

Использование простых, предсказуемых и скомпрометированных паролей запрещено.

Автоматическая генерация паролей#

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

Сгенерированный пароль:

соответствует установленным требованиям сложности;
формируется с использованием криптографически стойкого генератора случайных значений;
исключает использование предсказуемых последовательностей и словарных комбинаций;
отображается администратору однократно в момент создания учетной записи.

После завершения операции создания пользователя повторное отображение исходного значения пароля средствами системы не выполняется.

Для учетных записей, созданных с автоматически сгенерированным временным паролем, рекомендуется обязательная смена пароля при первом входе пользователя в систему.

Защита от подбора паролей#

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

Параметр 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.

Синхронизация учетных записей и аутентификация по доменному паролю являются самостоятельными процессами и могут применяться совместно. Пользовательские учетные записи могут предварительно загружаться в систему через сервис синхронизации, после чего аутентификация выполняется через домен или внешний контур единого входа.

Ролевая модель, права и доступ к функционалу системы управляются в Global ERP. Роли назначаются администратором вручную либо посредством внешней системы управления идентификацией и доступом, интегрированной с платформой.

Процесс аутентификации с помощью единого входа#

Поддержка единого входа реализована в компоненте Global Server через протокол OpenID Connect с использованием внешнего поставщика идентификационных данных. Настройка выполняется на стороне сервера приложений посредством блока <openId> в файле global3.config.xml.

Процесс аутентификации при использовании единого входа включает следующие этапы:

пользователь инициирует вход в систему;
аутентификация выполняется внешним провайдером идентификации;
на стороне внешнего провайдера могут использоваться федерация пользователей через LDAP, Active Directory или ALDPro, защита от брутфорса и дополнительные факторы аутентификации;
после успешной аутентификации пользователю предоставляется доступ к функциям системы в рамках назначенных ролей и полномочий в Global ERP.

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

Аутентификация через внешний прокси-сервер авторизации#

Global ERP поддерживает работу с внешним сервером авторизации gs-authproxy и совместимыми внешними сервисами авторизации. Данный режим применяется в сценариях, когда требуется вынести первичную аутентификацию пользователей во внешний контур, например для предоставления доступа пользователям внешних организаций к выделенному функционалу.

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

В этом режиме внешний прокси обеспечивает первичную аутентификацию и выдачу токена, а Global ERP — проверку токена, сопоставление учетной записи и применение полномочий.

Аутентификация технических подключений и сервисов#

Для технических подключений к 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-ключи, сопоставленные с учетной записью пользователя или прокси-пользователя. Проверка действительности токена выполняется системой с использованием открытого ключа, хранящегося в базе данных решения.

Аутентификация устройств#

Для устройств могут использоваться механизмы аутентификации с применением сертификатов и дополнительных атрибутов идентификации. В зависимости от архитектуры внедрения может использоваться интеграция с внешними системами управления устройствами класса MDM.

Использование таких механизмов допускается только в рамках штатного контура безопасности и не отменяет требований к сопоставлению устройства, учетной записи и назначенных прав доступа.

Источники учетных данных и ролевой контур#

В зависимости от архитектуры конкретного внедрения источником учетных данных могут выступать:

локальная учетная запись Global ERP;
внешняя служба каталогов LDAP, Active Directory или ALDPro;
внешний провайдер идентификации в SSO-контуре;
внешний прокси-сервер авторизации, выдающий JWT;
учетные данные или токены, используемые для подключения к техническим сервисам.

Независимо от источника первичной аутентификации, учетные записи пользователей хранятся в базе данных Global ERP. Роли и полномочия назначаются и проверяются в контуре системы. При необходимости интеграция с внешними системами управления идентификацией и доступом может использоваться для централизованного управления жизненным циклом учетных записей и назначения ролей.

Требования к расширениям и функциональному дизайну#

Расширения и прикладные доработки обязаны использовать штатный контур идентификации и аутентификации Global ERP. Реализация изолированных механизмов входа, параллельных хранилищ паролей или обходных сценариев аутентификации не допускается. Аутентификация расширений должна выполняться исключительно одним из штатных способов, предусмотренных платформой.

Регламент идентификации и аутентификации в Global ERP

Содержание