Авторизация логического доступа к ресурсам доступа, в том числе АС.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Мера устанавливает базовое техническое требование: любое обращение субъекта логического доступа к ресурсу доступа (в том числе к автоматизированной системе (АС)) должно сопровождаться процедурой авторизации — проверкой того, что данному субъекту действительно предоставлены права на запрашиваемое действие.
Главная цель меры — гарантировать, что успешного прохождения идентификации и аутентификации (мер РД.1—РД.7) недостаточно для получения доступа к конкретному ресурсу: должна выполняться отдельная проверка полномочий, без которой любой аутентифицированный субъект мог бы обращаться к любым ресурсам вне зависимости от предоставленных ему прав.
Мера реализуется на техническом уровне без организационной составляющей:
- Настройку операционных систем, СУБД, прикладного ПО и сетевого оборудования таким образом, чтобы каждое обращение к ресурсу доступа проверялось на соответствие фактически предоставленным правам, независимо от факта успешной аутентификации;
- Использование встроенных механизмов авторизации ресурсов доступа (списки контроля доступа — ACL, ролевые модели, политики доступа) в каждой информационной системе;
- Технический запрет на выполнение операций, не охваченных явно предоставленными правами субъекта («запрет по умолчанию» — default deny).
Класс используемых средств — встроенные механизмы авторизации операционных систем, СУБД и прикладного ПО, средства защиты от несанкционированного доступа (СЗИ от НСД).
Примеры таких средств:
- Иностранные: Microsoft Active Directory (списки контроля доступа), Oracle Database (Fine-Grained Access Control) и пр.
- Российские сертифицированные (ФСТЭК): Secret Net Studio, Dallas Lock 8.0-К и др.
- Открытый код: SELinux, PostgreSQL (Row-Level Security) и др.
- Итоги интервью с администраторами информационных систем;
- Скриншоты настроек авторизации (списков контроля доступа, ролевых моделей) в информационных системах;
- Результаты тестирования (попытка обращения аутентифицированного, но не авторизованного субъекта к ресурсу), подтверждающие срабатывание запрета;
- Журналы событий, подтверждающие регистрацию решений об авторизации (разрешении/отказе в доступе).
- Отдельные ресурсы доступа (в том числе АС) не проверяют права субъекта при обращении, полагаясь только на факт успешной аутентификации;
- Модель авторизации построена по принципу «разрешено по умолчанию», а не «запрещено по умолчанию», что создаёт риск избыточного доступа к неучтённым функциям;
- Настройки авторизации не покрывают все точки доступа к ресурсу (например, отсутствуют для программных интерфейсов — API);
- Тестирование фактического срабатывания механизма авторизации не проводится.
Не выявлены.
Не выявлены.
Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод) при разграничении логического доступа к ресурсам доступа.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Мера требует, чтобы в каждом ресурсе доступа применялся метод разграничения логического доступа, соответствующий характеру обрабатываемой информации и уровню защиты, — дискреционный (управление доступом на основе прав, назначаемых владельцем ресурса), мандатный (управление доступом на основе меток конфиденциальности) или ролевой (управление доступом на основе ролей субъектов), либо иной обоснованный метод.
Главная цель меры — обеспечить осознанный и соответствующий специфике ресурса выбор модели разграничения доступа, а не бессистемное предоставление прав, поскольку выбор неподходящего или отсутствие какого-либо формализованного метода делает управление доступом непрозрачным и труднопроверяемым.
Так как мера реализуется только техническими средствами, необходимо:
- Определение для каждого ресурса доступа (АС, СУБД, файлового ресурса и т. д.) применимого метода разграничения доступа исходя из специфики обрабатываемой информации и архитектуры ресурса;
- Настройку выбранного метода средствами самого ресурса доступа (дискреционные списки контроля доступа, мандатные метки конфиденциальности, ролевые модели);
- Технический контроль того, что разграничение доступа выполняется именно выбранным методом, а не в обход него (например, через прямой доступ к данным на уровне файловой системы или СУБД, минуя прикладную логику авторизации).
Класс используемых средств — встроенные механизмы разграничения доступа операционных систем и СУБД, средства защиты от несанкционированного доступа (СЗИ от НСД) с поддержкой мандатного управления доступом.
Примеры таких средств:
- Иностранные: Microsoft Active Directory (дискреционная модель), Oracle Label Security (мандатная модель) и пр.
- Российские сертифицированные (ФСТЭК): Secret Net Studio, Astra Linux Special Edition (мандатное управление доступом) и др.
- Открытый код: SELinux (мандатное управление доступом) и др.
- Итоги интервью с администраторами информационных систем;
- Проектная (эксплуатационная) документация ресурсов доступа, содержащая описание применяемого метода разграничения доступа;
- Скриншоты настроек, подтверждающие фактическую реализацию выбранного метода;
- Результаты тестирования, подтверждающие невозможность обхода выбранного метода разграничения доступа.
- Метод разграничения доступа не определён и не обоснован документально для части ресурсов доступа;
- Заявленный метод (например, мандатный) реализован не в полном объёме, фактически используется упрощённая дискреционная модель;
- Существуют технические пути обхода установленного метода разграничения доступа (прямой доступ к данным в обход прикладной логики);
- Настройки метода разграничения доступа не пересматриваются при изменении состава обрабатываемой информации.
Не выявлены.
Не выявлены.
Реализация ролевого метода (с определением для каждой роли прав доступа) при разграничении логического доступа в АС.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мера конкретизирует РД.31 применительно к автоматизированным системам (АС): в них должен применяться именно ролевой метод разграничения доступа (Role-Based Access Control, RBAC), при котором для каждой роли заранее определён чётко зафиксированный набор прав доступа, а субъектам права предоставляются через назначение соответствующей роли, а не по отдельности.
Главная цель меры — упростить и сделать прозрачным управление правами доступа в АС за счёт группировки прав в типовые роли, соответствующие производственным функциям субъектов, что снижает риск ошибок при назначении прав и облегчает последующий контроль (в том числе в рамках мер УЗП.8—УЗП.9).
Мера подразумевает исключительно технические меры защиты, а именно:
- Разработку и настройку в АС ролевой модели: определение перечня ролей, соответствующих производственным функциям субъектов, и фиксацию для каждой роли конкретного набора прав доступа к функциям и данным АС;
- Настройку АС таким образом, чтобы предоставление прав доступа субъекту выполнялось исключительно через назначение ему одной или нескольких ролей, без возможности точечного (вне ролевой модели) назначения отдельных прав;
- Технический контроль соответствия фактически предоставленных прав заявленному составу прав для назначенных субъекту ролей.
Класс используемых средств — встроенные механизмы ролевого управления доступом (RBAC) прикладного ПО и АС, системы управления учётными записями и правами доступа (IdM) с поддержкой ролевых моделей.
Примеры таких средств:
- Иностранные: SAP (ролевая модель авторизаций), Microsoft Dynamics (RBAC) и пр.
- Российские сертифицированные (ФСТЭК): Avanpost IDM, Solar inRights и др.
- Открытый код: Keycloak (Role-Based Access Control) и др.
- Итоги интервью с администраторами АС;
- Проектная документация АС, содержащая описание ролевой модели и состава прав каждой роли;
- Скриншоты настроек ролевой модели в АС;
- Результаты тестирования (сопоставление фактических прав субъекта с заявленным составом прав его роли (ролей)).
- Ролевая модель в АС не охватывает все функции и данные, часть прав предоставляется точечно, в обход ролей;
- Роли определены нечётко, их состав пересекается, что затрудняет контроль фактически предоставленных прав;
- Роли не пересматриваются при изменении функциональности АС, актуальность состава прав каждой роли не подтверждается;
- Одному субъекту назначено избыточное количество ролей без документированного обоснования служебной необходимости.
Не выявлены.
Не выявлены.
Реализация необходимых типов (чтение, запись, выполнение или иной тип) и правил разграничения логического доступа к ресурсам доступа, в том числе АС.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Мера требует, чтобы разграничение логического доступа выполнялось не только на уровне «есть доступ / нет доступа» к ресурсу в целом, но и по конкретным типам операций — чтению, записи, выполнению или иным применимым типам, — с определением правил, по которым тот или иной тип доступа предоставляется субъекту.
Главная цель меры — реализовать принцип минимально необходимых прав на уровне операций: субъект должен получать только те типы доступа к ресурсу, которые действительно необходимы ему для выполнения служебных обязанностей (например, право только на чтение данных без права их изменения), а не полный доступ ко всем операциям с ресурсом.
Ввиду того, что мера реализуется только технически, необходимо:
- Настройку ресурсов доступа (файловых систем, СУБД, прикладного ПО) таким образом, чтобы для субъекта можно было раздельно предоставлять права на чтение, запись, выполнение и иные применимые операции;
- Определение и документальное закрепление правил, по которым субъектам предоставляется тот или иной тип доступа (например, право на запись предоставляется только субъектам, ответственным за ввод и изменение данных, право на чтение — более широкому кругу субъектов);
- Технический контроль того, что субъекту не предоставлен более широкий тип доступа, чем это предусмотрено установленными правилами (например, исключение случаев, когда право на чтение фактически сопровождается и правом на запись).
Класс используемых средств — встроенные механизмы разграничения доступа операционных систем, файловых систем и СУБД (списки контроля доступа — ACL, права на уровне объектов).
Примеры таких средств:
- Иностранные: Microsoft NTFS (права на уровне файлов и папок), Oracle Database (системные и объектные привилегии) и пр.
- Российские сертифицированные (ФСТЭК): Secret Net Studio, Astra Linux Special Edition и др.
- Открытый код: файловые права POSIX (ACL), PostgreSQL (GRANT/REVOKE) и др.
- Итоги интервью с администраторами информационных систем;
- Внутренний документ, определяющий правила предоставления субъектам различных типов доступа (чтение, запись, выполнение);
- Скриншоты настроек, подтверждающие раздельное разграничение типов доступа к ресурсу;
- Результаты тестирования (проверка фактического типа доступа субъекта к ресурсу на соответствие установленным правилам).
- Правила предоставления различных типов доступа не формализованы документально;
- Субъектам систематически предоставляется более широкий тип доступа, чем необходимо (например, право на запись вместо права только на чтение);
- Отдельные ресурсы доступа не поддерживают раздельное разграничение по типам операций, что вынуждает предоставлять полный доступ;
- Соответствие фактически предоставленных типов доступа установленным правилам не проверяется на регулярной основе.
Не выявлены.
Не выявлены.
Запрет реализации пользователями бизнес-процессов и технологических процессов финансовой организации с использования учетных записей эксплуатационного персонала, в том числе в АС.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера запрещает пользователям выполнять бизнес-процессы и технологические процессы (то есть их обычную рабочую деятельность) под учётными записями эксплуатационного персонала — привилегированными административными учётными записями, предназначенными для эксплуатации и администрирования систем, а не для выполнения повседневных операций.
Главная цель меры — предотвратить смешение ролей пользователя и администратора: использование привилегированной учётной записи для рутинных операций резко увеличивает потенциальный ущерб от компрометации такой учётной записи или от ошибки пользователя, а также обесценивает разграничение прав, установленное мерами УЗП.19—УЗП.21.
Организационная составляющая сводится к следующим шагам:
- Закрепление во внутреннем нормативном документе прямого запрета на использование учётных записей эксплуатационного персонала для выполнения бизнес-процессов и технологических процессов, не относящихся к эксплуатации и администрированию систем;
- Информирование эксплуатационного персонала о данном запрете и о необходимости использования отдельной персональной пользовательской учётной записи для непроизводственных (не связанных с администрированием) операций;
- Периодический контроль (анализ журналов, выборочные проверки) фактического использования привилегированных учётных записей на предмет выполнения под ними операций бизнес- и технологических процессов.
Базовое разделение учётных записей и техническое ограничение состава ролей, доступных привилегированной учётной записи (пункты 1–2), реализуются штатными средствами разграничения доступа (ролевой моделью АС, группами Active Directory) без отдельного средства защиты информации. Для автоматизированного анализа и оповещения о фактах использования привилегированной учётной записи не по назначению (пункт 3) штатных средств недостаточно — нужны PAM и SIEM:
- Предоставление эксплуатационному персоналу двух раздельных учётных записей — привилегированной (административной) для задач эксплуатации и обычной пользовательской для выполнения непроизводственных операций (при их наличии у данного сотрудника);
- Технический запрет использования привилегированных учётных записей для входа в АС и выполнения в них функций, относящихся к бизнес-процессам и технологическим процессам (например, ограничение состава ролей, доступных привилегированной учётной записи, только административными функциями);
- Регистрацию и автоматизированный анализ фактов выполнения под привилегированными учётными записями операций, типичных для бизнес-процессов, с оповещением подразделения информационной безопасности при выявлении таких фактов.
Класс используемых средств — ролевая модель доступа АС и служба каталогов (штатное разграничение ролей); системы управления привилегированным доступом (PAM) и системы управления событиями информационной безопасности (SIEM) — для автоматизированного анализа и оповещения.
Примеры таких средств:
- Иностранные: CyberArk PAM, Splunk (для анализа журналов) и пр.
- Российские сертифицированные (ФСТЭК): Indeed Privileged Access Manager, MaxPatrol SIEM и др.
- Открытый код: Teleport, Wazuh и др.
- Внутренний нормативный документ, содержащий запрет на использование учётных записей эксплуатационного персонала для выполнения бизнес- и технологических процессов;
- Материалы информирования (инструктажа) эксплуатационного персонала о данном запрете;
- Акты (отчёты) периодического контроля фактического использования привилегированных учётных записей.
- Итоги интервью с администраторами информационных систем;
- Выгрузка перечня учётных записей эксплуатационного персонала, подтверждающая наличие раздельных привилегированной и пользовательской учётных записей;
- Скриншоты настроек, ограничивающих состав ролей, доступных привилегированной учётной записи, административными функциями;
- Журналы событий (отчёты SIEM), подтверждающие анализ фактов выполнения бизнес-операций под привилегированными учётными записями.
- Эксплуатационному персоналу не выделяется отдельная пользовательская учётная запись, вся деятельность (включая непроизводственную) выполняется под привилегированной учётной записью;
- Технический запрет на выполнение бизнес-операций под привилегированными учётными записями не реализован, ограничение носит только организационный (декларативный) характер;
- Анализ журналов на предмет выполнения бизнес-операций под привилегированными учётными записями не проводится;
- Запрет не доведён до сведения эксплуатационного персонала.
Не выявлены.
Не выявлены.
Запрет выполнения пользователями бизнес-процессов с использованием привилегированных прав логического доступа, в том числе работы пользователей с правами локального администратора АРМ.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Мера запрещает пользователям выполнять бизнес-процессы, обладая привилегированными правами логического доступа, — в частности, запрещает повседневную работу пользователя на автоматизированном рабочем месте (АРМ) под учётной записью с правами локального администратора.
Главная цель меры — минимизировать потенциальный ущерб от компрометации рабочей станции пользователя (например, в результате заражения вредоносным ПО или фишинговой атаки): если пользователь работает без привилегированных прав, вредоносный код, запущенный от его имени, также не получает административных полномочий на АРМ, что существенно ограничивает возможности злоумышленника закрепиться в системе или распространиться на другие ресурсы.
Так как данная мера — целиком техническая, для её выполнения необходимо:
- Настройку учётных записей пользователей таким образом, чтобы для повседневной работы (выполнения бизнес-процессов) использовалась учётная запись без прав локального администратора и без иных привилегированных прав логического доступа;
- Реализацию отдельного, контролируемого механизма временного повышения привилегий для случаев, когда пользователю действительно необходимо выполнить операцию, требующую административных прав (запрос повышения привилегий с санкционированием и регистрацией);
- Технический контроль (аудит состава локальных администраторов АРМ), выявляющий и устраняющий случаи, когда обычные пользователи фактически обладают правами локального администратора.
Класс используемых средств — средства управления привилегиями на конечных точках (Endpoint Privilege Management), системы управления конфигурациями.
Примеры таких средств:
- Иностранные: Microsoft Defender for Endpoint (совместно с политиками ограничения прав), CyberArk Endpoint Privilege Manager и пр.
- Российские сертифицированные (ФСТЭК): Secret Net Studio, Dallas Lock 8.0-К и др.
- Открытый код: групповые политики Linux/Windows без выделенных общепринятых открытых аналогов и др.
- Итоги интервью с администраторами АРМ;
- Выгрузка перечня локальных администраторов АРМ, подтверждающая отсутствие среди них рядовых пользователей;
- Скриншоты настроек механизма временного повышения привилегий (при его наличии);
- Результаты аудита (сканирования) АРМ на предмет фактического состава локальных администраторов.
- Часть пользователей продолжает работать с правами локального администратора АРМ по факту исторически сложившейся практики;
- Механизм временного контролируемого повышения привилегий отсутствует, что вынуждает администраторов постоянно предоставлять пользователям административные права «про запас»;
- Аудит фактического состава локальных администраторов АРМ не проводится на регулярной основе;
- Выявленные случаи наличия у пользователя прав локального администратора не устраняются в разумный срок.
Не выявлены.
Не выявлены.
Оповещение субъекта логического доступа после успешной авторизации о дате и времени его предыдущей авторизации в АС.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Суть меры заключается в том, что после успешной аутентификации (ввода логина и пароля) субъекту логического доступа отображается уведомление с указанием даты и времени его предыдущей успешной авторизации в данной автоматизированной системе (АС).
Главная цель меры — снижение риска несанкционированного доступа и своевременное выявление факта компрометации учётной записи. Если пользователь видит, что его предыдущий вход был совершён в то время, когда он точно не работал в системе, это является явным признаком того, что его учётные данные были использованы злоумышленником. Пользователь может оперативно среагировать: сменить пароль и сообщить о случившемся в службу информационной безопасности.
Реализация носит чисто технический характер и включает:
- Настройку АС таким образом, чтобы после успешной авторизации субъекту отображалось информационное сообщение с датой и временем его предыдущего успешного входа в данную АС;
- Хранение в системе сведений о дате и времени предыдущих успешных авторизаций каждого субъекта в объёме, достаточном для формирования такого уведомления;
- Обеспечение того, что данное уведомление не может быть отключено или скрыто самим пользователем.
Отдельного специализированного средства защиты для реализации меры, как правило, не требуется: функция реализуется на уровне логики самой АС и её встроенных механизмов идентификации и аутентификации.
- Итоги интервью с пользователями и разработчиками (администраторами) АС;
- Скриншоты интерфейса АС, подтверждающие отображение уведомления о дате и времени предыдущей авторизации;
- Результаты тестирования (последовательный вход под одной учётной записью), подтверждающие корректность отображаемых даты и времени.
- Функция реализована не во всех АС, к которым субъекты осуществляют логический доступ;
- Отображаемые дата и время предыдущей авторизации не соответствуют фактическим (ошибка логики учёта);
- Уведомление отображается слишком кратковременно или в неприметном месте интерфейса, из-за чего пользователи его не замечают;
- Пользователи не проинформированы о значении данного уведомления и о необходимых действиях в случае обнаружения несоответствия.
Не выявлены.
Не выявлены.
Контроль состава разрешенных действий в АС до выполнения идентификации и аутентификации.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мера требует, чтобы автоматизированная система (АС) ограничивала перечень действий пользователя до прохождения им идентификации и аутентификации, что исключает возможность получения злоумышленником какой-либо полезной информации (например, о структуре системы или версиях ПО) для дальнейшей атаки.
Главная цель меры — минимизировать риски несанкционированных действий и атак на этапе, когда личность пользователя ещё не подтверждена. Это предотвращает возможность получения доступа к защищённым ресурсам, выполнения операций или сбора информации о системе до прохождения аутентификации.
Мера выполняется силами технических средств защиты информации, а именно:
- Настройку АС таким образом, чтобы до прохождения идентификации и аутентификации субъекту были доступны исключительно минимально необходимые функции (например, отображение формы входа, общая информация об организации без раскрытия структуры системы);
- Технический запрет на получение до аутентификации какой-либо информации о внутренней архитектуре АС, версиях используемого ПО, структуре базы данных и иных технических деталях, которые могут быть использованы для подготовки атаки;
- Настройку обработки ошибок таким образом, чтобы сообщения об ошибках на этапе входа не раскрывали избыточные технические подробности (например, обобщённое сообщение «неверный логин или пароль» вместо детализации, какая именно часть учётных данных неверна).
- Итоги интервью с разработчиками и администраторами АС;
- Результаты тестирования (попытка получить доступ к функциям или информации АС до прохождения аутентификации), подтверждающие ограничение состава доступных действий;
- Скриншоты сообщений об ошибках на этапе входа, подтверждающие отсутствие избыточной технической детализации.
- До прохождения аутентификации пользователю доступны отдельные функции АС сверх необходимого минимума (например, часть справочной информации, раскрывающей структуру системы);
- Сообщения об ошибках на этапе входа раскрывают избыточные технические подробности (версии ПО, структуру базы данных, стек трассировки);
- Тестирование состава действий, доступных до аутентификации, не проводится на регулярной основе.
Не выявлены.
Не выявлены.
Размещение устройств вывода (отображения) информации, исключающее ее несанкционированный просмотр.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Мера требует такого физического размещения устройств вывода (отображения) информации — мониторов, экранов, панелей — при котором исключается возможность несанкционированного просмотра отображаемой на них защищаемой информации посторонними лицами (так называемый visual hacking, shoulder surfing).
Главная цель меры — исключить утечку защищаемой информации через простое визуальное наблюдение за экраном, поскольку такой канал утечки не требует от нарушителя никаких технических средств или специальных знаний — достаточно оказаться в поле зрения экрана.
Организационно это выражается в следующем:
- Определение требований к размещению устройств вывода информации, исключающих просмотр экрана с мест, доступных посторонним лицам (например, разворот мониторов от окон, дверных проёмов, зон обслуживания клиентов);
- Учёт данных требований при планировке рабочих мест, на которых обрабатывается защищаемая информация, а также при организации рабочих мест эксплуатационного персонала;
- Применение дополнительных организационных мер там, где оптимальное размещение технически невозможно (например, временное затемнение, использование перегородок);
- Периодический контроль соблюдения установленных требований к размещению устройств вывода информации.
- Внутренний документ, определяющий требования к размещению устройств вывода информации;
- Результаты выборочного визуального осмотра рабочих мест на предмет соблюдения установленных требований;
- Акты (отчёты) периодического контроля соблюдения требований к размещению устройств вывода информации.
- Требования к размещению устройств вывода информации не формализованы документально;
- Мониторы отдельных рабочих мест обращены в сторону зон, доступных клиентам или посторонним лицам (зоны обслуживания, коридоры, окна первого этажа);
- Периодический контроль соблюдения требований не проводится;
- Требования не учитываются при организации новых рабочих мест или при перепланировке помещений.
Не выявлены.
Не выявлены.