# Регламент идентификации и аутентификации в 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: - [Политика паролей](https://help.globalerp.ru/books/G3AppAdministrationGuide/SNAPSHOT/html/070_%D0%9F%D0%BE%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0_%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D0%B5%D0%B9.html) - [Настройка SSO](https://help.globalerp.ru/books/G3SysAdminDoc/SNAPSHOT/html/070_addition/005_openid.html) - [Развертывание сервера приложений GS с сервером авторизации](https://help.globalerp.ru/books/G3SysAdminDoc/SNAPSHOT/html/050_gs-authproxy.html) - [Аутентификация в REST/SOAP-сервисах](https://help.globalerp.ru/books/GlobalServerAppGuide/SNAPSHOT/html/080_addition/serv_serv/070_%D0%B0%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F.html) - [LDAP-синхронизация](https://help.globalerp.ru/books/GlobalUserGuideSystemWide/SNAPSHOT/html/service/0080_%D1%81%D0%B8%D0%BD%D1%85%D1%80%D0%BE%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F.html) - [Параметры LDAP в конфигурации базы](https://help.globalerp.ru/books/gs-docs-sphinx/master/reference/configuration/global3_config_xsd/configuration/databases/Database.html#Configuration.Databases.Database.ldap) ## Классификация пользователей и учетных записей Для целей управления доступом и разграничения полномочий учетные записи в системе Global ERP подразделяются на следующие категории: 1. **Внутренние пользователи** — сотрудники организации, имеющие постоянный доступ к системе для выполнения служебных обязанностей. 2. **Внешние пользователи** — клиенты, подрядчики и иные третьи лица, которым предоставляется ограниченный доступ к функционалу системы в рамках конкретных бизнес-процессов. 3. **Технические или сервисные учетные записи** — учетные записи, используемые для интеграций, автоматизированных процессов, сервисов и программных компонентов системы. 4. **Администраторы и привилегированные учетные записи** — пользователи с повышенными правами доступа к системным функциям, конфигурации, ролевым назначениям и критическим данным. Для каждой категории учетных записей устанавливаются отдельные правила аутентификации, ограничения по доступу, а также требования к хранению и защите учетных данных. ## Общая модель идентификации и аутентификации В системе допускается использование следующих способов аутентификации: 1. локальная аутентификация средствами платформы; 2. аутентификация через внешний контур единого входа по протоколу OpenID Connect; 3. аутентификация доменных пользователей с проверкой пароля внешней службой каталогов; 4. аутентификация через внешний прокси-сервер авторизации; 5. аутентификация технических подключений к 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](img/img_pass.png) После успешной аутентификации доступ к функциональности системы предоставляется в соответствии с назначенными ролями и полномочиями. ## Локальная аутентификация При локальной аутентификации пользователь проходит встроенную процедуру аутентификации средствами платформы. За включение централизованной настройки парольной политики отвечает флаг `bPasswordSettingsInOT` в классе `Btk_Setting`. При включенном флаге параметры задаются для типа объекта пользователя через `Btk_UserPasswordSetting`. При отключенном флаге применяются параметры из класса `Btk_User`. Внутренняя реализация системы обеспечивает хранение паролей исключительно в виде хэшей `Argon2id`. Исходное значение пароля не сохраняется и не может быть восстановлено по хэшу. Для контроля повторного использования ранее применявшихся паролей используется сервис истории паролей. Значения предыдущих паролей сохраняются в журнале в хешированном виде, что позволяет проверять совпадение нового пароля с ранее использованными без раскрытия их исходных значений. Проверка соответствия пароля установленным требованиям выполняется при его создании и смене. По истечении срока действия пароля система переводит пользователя в режим обязательной смены и при необходимости генерирует временный пароль. ## Парольная политика В Global ERP реализована комплексная политика паролей, направленная на обеспечение информационной безопасности. Политика охватывает: - требования к минимальной длине и составу пароля; - историю паролей и запрет повторного использования; - проверку паролей по словарям и черным спискам; - сроки действия постоянного и временного пароля; - уведомления о необходимости смены пароля. Для локальной аутентификации применяются следующие параметры политики паролей: - обязательное использование специальных символов; - обязательное сочетание букв и цифр; - обязательное использование букв в разных регистрах; - минимальная длина пароля; - запрет на повторное использование определенного числа предыдущих паролей; - минимальный срок действия пароля; - срок действия постоянного пароля; - срок действия временного пароля; - период предварительного уведомления о необходимости смены пароля. Рекомендуемая базовая конфигурация предусматривает: - минимальную длину пароля не менее 8 символов для обычных пользователей и не менее 12 символов для администраторов и привилегированных учетных записей; - использование не менее трех категорий символов; - ограничение срока действия пароля; - обязательную смену временного пароля при первом входе; - ведение истории паролей. Использование простых, предсказуемых и скомпрометированных паролей запрещено. ## Автоматическая генерация паролей При создании локальных учетных записей в системе может использоваться [автоматическая генерация временного пароля](https://help.globalerp.ru/books/G3AppAdministrationGuide/SNAPSHOT/html/030_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80.html#id4) в соответствии с действующей парольной политикой. Сгенерированный пароль: - соответствует установленным требованиям сложности; - формируется с использованием криптографически стойкого генератора случайных значений; - исключает использование предсказуемых последовательностей и словарных комбинаций; - отображается администратору однократно в момент создания учетной записи. После завершения операции создания пользователя повторное отображение исходного значения пароля средствами системы не выполняется. Для учетных записей, созданных с автоматически сгенерированным временным паролем, рекомендуется обязательная смена пароля при первом входе пользователя в систему. ## Защита от подбора паролей Для предотвращения подбора паролей в локальном контуре аутентификации реализуется временная блокировка учетной записи пользователя при превышении допустимого количества последовательных неудачных попыток входа. Параметр `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-сервера и домен. Данный режим применяется для аутентификации доменных пользователей при сохранении прикладной модели ролей внутри Global ERP. Система поддерживает синхронизацию пользователей из внешних служб каталогов. Для этого используется сервис LDAP-синхронизации, настраиваемый в модуле `Btk`. Сервис обеспечивает загрузку пользователей из указанных доменов, фильтрацию по группам и выбор режимов синхронизации в соответствии с выбранным сценарием. При необходимости к системному имени пользователя может быть добавлен домен в формате `User@Domain`. Синхронизация учетных записей и аутентификация по доменному паролю являются самостоятельными процессами и могут применяться совместно. Пользовательские учетные записи могут предварительно загружаться в систему через сервис синхронизации, после чего аутентификация выполняется через домен или внешний контур единого входа. Ролевая модель, права и доступ к функционалу системы управляются в Global ERP. Роли назначаются администратором вручную либо посредством внешней системы управления идентификацией и доступом, интегрированной с платформой. ## Процесс аутентификации с помощью единого входа Поддержка единого входа реализована в компоненте Global Server через протокол OpenID Connect с использованием внешнего поставщика идентификационных данных. Настройка выполняется на стороне сервера приложений посредством блока `` в файле `global3.config.xml`. Процесс аутентификации при использовании единого входа включает следующие этапы: 1. пользователь инициирует вход в систему; 2. аутентификация выполняется внешним провайдером идентификации; 3. на стороне внешнего провайдера могут использоваться федерация пользователей через LDAP, Active Directory или ALDPro, защита от брутфорса и дополнительные факторы аутентификации; 4. после успешной аутентификации пользователю предоставляется доступ к функциям системы в рамках назначенных ролей и полномочий в 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. Реализация изолированных механизмов входа, параллельных хранилищ паролей или обходных сценариев аутентификации не допускается. Аутентификация расширений должна выполняться исключительно одним из штатных способов, предусмотренных платформой.