8. Безопасность и сертификация

ИАФ.1: Идентификация и аутентификация пользователей

Формулировка в приказе:

Реализация в «IDENTYX»:

• (ИАФ.1 Б1, Б3) Обязательная аутентификация любого пользователя при доступе к защищенным ресурсам. Доступ к ресурсам исключается до идентификации и аутентификации.

  • При использовании прокси-режима на REST приложение доступ к ресурсам осуществляется только после успешной аутентификации и управляется IAM.

  • Для нативных приложений – за счет проверки разрешений в нужных местах.

• При использовании сервера OIDC проверка токенов выполняется на стороне приложения.

• (ИАФ.1 Б4) Поддержка различных способов и факторов аутентификации:

  • Первый фактор: Пароли, электронные ключи (WebAuthn), УКЭП (усиленная квалифицированная электронная подпись), интеграция с внешними IdP (ЕСИА, Сбер ID, VK ID и др.).

  • Второй фактор: TOTP (временные одноразовые коды).

• (ИАФ.1 Б5) Обеспечивается однозначное сопоставление идентификатора пользователя с процессами, запускаемыми от его имени (например, через передачу токена пользователя при записи события ИБ в рамках РСБ).

• (ИАФ.1 У1а, У2а, У3, У4) Реализована многофакторная аутентификация (например, с использованием токенов OTP), включая возможность настройки обязательности 2FA глобально для всех или для конкретных приложений.

ИАФ.3: Управление идентификаторами

Формулировка в приказе:

Реализация в «IDENTYX»:

• (ИАФ.3 Б1) Разделение административных ролей: для создания и управления пользователями требуются специальные права (например, роль Администратор или роль с ограниченными правами администрирования).

• (ИАФ.3 Б2) Уникальность идентификаторов пользователей обеспечивается на уровне БД (например, автоинкрементный первичный ключ в таблице пользователей acl_local_users).

• (ИАФ.3 Б3, У1б) Идентификаторы заблокированных/удаленных пользователей не используются повторно (полный запрет дублирования идентификаторов).

• (ИАФ.3 Б4, У2б) Реализовано блокирование идентификатора пользователя после установленного времени неиспользования (например, 45 дней).

ИАФ.4: Управление средствами аутентификации

Формулировка в приказе:

Реализация в «IDENTYX»:

• (ИАФ.4 Б1) Реализовано управление средствами аутентификации: имеется администратор IAM с соответствующими правами для управления, включая функции по выдаче разовых паролей, контролю установки пользователями 2FA, УКЭП и других методов, а также их централизованному отзыву.

• (ИАФ.4 Б2) Обеспечивается смена аутентификационной информации (паролей), заданной по умолчанию (например, для учетной записи администратора системы).

• (ИАФ.4 Б4, У1г) Настраиваемая парольная политика:

  • Требования к сложности пароля: минимальная длина (по умолчанию 8 символов), наличие символов разного регистра, цифр и специальных символов. Длина пароля не менее 8 символов, алфавит – не менее 70.

  • Обязательная смена пароля при первом входе.

  • Периодическая смена паролей (настраивается интервал, например, раз в 60 дней).

  • Запрет на повторное использование последних N паролей.

  • Реализована блокировка учетной записи после 3–4 неуспешных попыток (происходит постоянная блокировка до сброса администратором).

• (ИАФ.4 Б5) Реализовано блокирование и замена утерянных/скомпрометированных средств аутентификации, включая управление глобальным списком скомпрометированных паролей, механизм сброса секрета TOTP для пользователя и возможность централизованно блокировать скомпрометированные УКЭП.

• (ИАФ.4 Б6) Поддерживается периодическое обновление аутентификационной информации (пароли пользователей истекают согласно политике).

• (ИАФ.4 Б7) Аутентификационная информация (пароли) хранится в зашифрованном виде; передача токенов осуществляется по защищенному каналу (TLS).

ИАФ.5: Защита обратной связи при вводе аутентификационной информации

Формулировка в приказе:

Реализация в «IDENTYX»:

• (ИАФ.5 Базовое) Реализовано: при вводе пароля в форме IAM символы отображаются маскирующими знаками (например, «звёздочками»), количество вводимых символов не отображается.

ИАФ.6: Идентификация и аутентификация пользователей, не являющихся работниками оператора (внешних пользователей)

Формулировка в приказе:

Реализация в «IDENTYX»:

• (ИАФ.6 Базовое) Реализована интеграция с внешними провайдерами идентификации (например, ЕСИА) для аутентификации пользователей, не являющихся работниками оператора, включая автоматическое присвоение группы пользователей по умолчанию для внешних пользователей, прошедших саморегистрацию.

УПД.1: Управление учетными записями пользователей

Формулировка в приказе:

Реализация в «IDENTYX»:

• (УПД.1 Б4) Полный набор функций управления пользователями (создание, активация, блокирование, уничтожение) доступен уполномоченным администраторам.

• (УПД.1 Б1) Поддержка разных типов учетных записей реализуется через механизм групп пользователей, которым могут назначаться соответствующие политики и права.

• (УПД.1 Б2) Реализовано объединение учётных записей в группы.

• (УПД.1 Б3) Реализована верификация личности при заведении учетной записи с использованием внешних IdP (например, ЕСИА), а также имеются встроенные политики, требующие обязательного использования определенных методов верификации для конкретных групп пользователей.

• (УПД.1 Б7) Реализовано оповещение администратора об изменении сведений о пользователях, их ролях и полномочиях (например, через записи в журнале событий).

• (УПД.1 Б9) Предоставление пользователям прав доступа к объектам ИС основывается на выполняемых ими задачах через механизм ролей, реализуемый через группы пользователей.

• (УПД.1 У1) Имеются автоматизированные средства поддержки управления учетными записями, включая интеграцию с LDAP.

• (УПД.1 Б8, У2) Реализовано управление временными учетными записями, включая создание, указание срока действия, и автоматическую блокировку/уничтожение по истечении срока.

• (УПД.1 У3б) Реализовано автоматическое блокирование неактивных учётных записей пользователей (например, после 45 дней неиспользования). Система корректно различает статусы «заблокировано по неактивности» и «отключено».

УПД.2: Реализация модели управления доступом

Формулировка в приказе:

Реализация в «IDENTYX»:

• (УПД.2 Б1) Реализованы различные методы управления доступом:

  • Дискреционный (DAC) – через точечные права на объекты.

  • Ролевой (RBAC) – через назначение прав группам доступа.

  • Мандатный (MAC) – через управление доступом к "веткам" объектов или действиям.

• (УПД.2 Б2) Определяются и назначаются типы доступа (чтение, запись, исполнение и т.п.) через настраиваемый справочник «действий».

• (УПД.2 Б3) Устанавливаются правила разграничения доступа к объектам на основе справочника «объектов».

• (УПД.2 У1) Правила разграничения доступа управляют доступом субъектов при входе в систему.

• (УПД.2 У4) Правила разграничения доступа управляют доступом к объектам, создаваемым прикладным и специальным ПО (список прикладных объектов может направляться в IAM через специальный API).

• Ролевая модель поддерживает иерархию и наследование прав.

• Возможность применения ограничений к разрешениям.

УПД.4: Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы

Формулировка в приказе:

Реализация в «IDENTYX»:

• (УПД.4 Б1) Реализовано разделение полномочий: существуют администраторы IAM с полными правами, а также возможность создания администраторов с ограниченными правами доступа к определенным объектам или функциям.

• (УПД.4 У1) Система позволяет создавать различные административные роли. Технически возможно разделение выполнения ролей отдельными должностными лицами, и реализована настройка на уровне групп для управления членством и исключения конфликтующих ролей.

УПД.5: Назначение минимально необходимых прав и привилегий

Формулировка в приказе:

Реализация в «IDENTYX»:

• (УПД.5 Б1) Реализовано: возможность тонкой настройки разрешений на уровне действий и объектов доступа, что позволяет назначать минимально необходимые права через Действия и Группы доступа.

• (УПД.5 Б2) Реализовано документирование ролей, обязанностей и минимальных уровней привилегий (например, через поле "Описание" у групп).

• (УПД.5 У1) Реализовано: право доступа к функциям безопасности (параметрам настройки) средств защиты информации предоставляется выделенным администраторам IAM (администраторам безопасности), отдельные администраторы приложений могут иметь ограниченный доступ.

• Разделение административных функций (например, управление пользователями, управление правами, аудит, настройка системы).

УПД.6: Ограничение неуспешных попыток входа в информационную систему

Формулировка в приказе:

Реализация в «IDENTYX»:

• (УПД.6 Б1, У1) Реализовано: настраивается ограничение числа неуспешных попыток входа (например, 5 попыток), после превышения которого учетная запись блокируется. Разблокировка осуществляется администратором. (см. также ИАФ.4 У1г).

УПД.9: Ограничение числа параллельных сеансов доступа

Формулировка в приказе:

Реализация в «IDENTYX»:

• (УПД.9 Б1, Б2, У1а) Реализовано ограничение числа параллельных сеансов на уровне интегрированных приложений или через прокси-сервис, с возможностью настройки количества сессий.

• (УПД.9 У3) Реализовано: администратор может видеть список активных сессий, включая информацию для контроля и группировки параллельных сеансов пользователей.

УПД.10: Блокирование сеанса доступа после установленного времени неактивности

Формулировка в приказе:

Реализация в «IDENTYX»:

• (УПД.10 Б1, Б2, Б3, У1б, У2) Реализована блокировка сеанса по таймауту неактивности на уровне прокси-сервиса или интегрированного приложения, с возможностью настройки времени неактивности. Пользователи могут управлять своими сеансами через соответствующие интерфейсы. При блокировке сеанса обеспечивается приостановка действий, сокрытие информации предыдущего сеанса и требование повторной аутентификации для разблокировки.

• При использовании OIDC контроль срока действия токенов (access/refresh) помогает управлять продолжительностью сеансов.

УПД.11: Разрешение (запрет) действий пользователей, разрешенных до идентификации и аутентификации

Формулировка в приказе:

Реализация в «IDENTYX»:

• (УПД.11 Б1) Реализовано: система позволяет настроить доступ к ресурсам таким образом, чтобы определенные действия (например, доступ к публичным страницам) были разрешены без аутентификации, в то время как доступ к защищенным ресурсам требует обязательной идентификации и аутентификации (см. ИАФ.1 Б3).

• (УПД.11 Б2) Реализованы процедуры для аварийного восстановления работоспособности системы, включая скрипты для управления учетными записями администраторов (например, создание нового администратора или сброс пароля существующего).

РСБ.3: Сбор, запись и хранение информации о событиях безопасности

Формулировка в приказе:

Реализация в «IDENTYX»:

• Встроенная система журналирования событий безопасности.

• Регистрируются следующие ключевые события:

  • Успешные и неуспешные попытки аутентификации.

  • Изменение учетных данных пользователей.

  • Назначение и изменение прав доступа.

  • Блокировка/разблокировка учетных записей.

  • Административные действия.

• (РСБ.3 Б1) Реализовано хранение журналов событий безопасности. Время хранения логов настраивается в соответствии с политиками оператора.

• (РСБ.3 Б2) Реализована настройка категорий журналируемых событий на уровне приложений, что позволяет администратору определять события, подлежащие регистрации.

• (РСБ.3 Б4) Система позволяет хранить логи событий безопасности. Обеспечение достаточного объема памяти, управление квотами и оптимизация (например, через индексы в таблицах логов) производятся в рамках настройки и обслуживания системы.

Cценарии проверки для аудитора

В этом разделе приведены типовые сценарии, которые аудиторы часто используют для проверки соответствия требованиям ФСТЭК: