УЗП 5-21
Базовый состав мер по организации, контролю предоставления (отзыва) и блокированию логического доступа применительно к уровням защиты информации
УЗП.5 (Н-О-О)
Документарное определение правил предоставления (отзыва) и блокирования логического доступа.
Уровень защиты информации 3-Н, 2-О, 1-О.
Пояснение
Данная мера требует, чтобы в документах были закреплены и определены правила отзыва/блокирования логического доступа.
Реализация - О
Данная мера реализуется путем регламентирования в "Политике управления доступом" правил предоставления и блокирования логического доступа.
Проверочные процедуры (свидетельства)
Для подтверждения выполнения данного требования, необходимо ознакомиться с внутренней нормативной документацией и найти в ней определенные и зафиксированные правила предоставления и блокирования логического доступа.
Свидетельства:
Внутренний нормативный документ с указанием раздела в котором регламентирована мера УЗП.5.
Типичные недостатки
Не выявлено.
Компенсационные меры
Не выявлено.
Выявленные коллизии
Не выявлено.
УЗП.6 (О-О-О)
Назначение для всех ресурсов доступа распорядителя логического доступа (владельца ресурса доступа).
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Данная мера требует, чтобы для каждого ресурса доступа было определено лицо, отвечающее за то, в каком процессе и для каких целей используется ресурс доступа, надлежащими ли субъектами используется ресурс доступа, соблюден ли принцип минимизации прав и отсутствует ли возможность самосанкционирования.
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом", должен быть определен порядок назначения лиц, которые являются владельцами ресурса доступа, порядок актуализации перечня таких лиц, порядок ведения реестров таких лиц и порядок использования реестра при назначении прав.
Нужно обратить внимание, что владелец ресурса доступа — это не администратор системы, а лицо, которое определяет кто, с какими целями (в каких процессах) и как используется ресурс доступа.
Проверочные процедуры (свидетельства)
Реестр владельцев ресурсов доступа (АС, виртуальных машин, веб-серверов, севера электронной почты). Может быть в виде приложения к приказу на бумажном носителе, в электронной форме.
Допускается указывать владельца ресурса доступа в карточке описания ресурса доступа, паспорте на АС.
Типичные недостатки
Не выявлено.
Компенсационные меры
Не выявлено.
Выявленные коллизии
Не выявлено.
УЗП.7 (О-О-О)
Предоставление прав логического доступа по решению распорядителя логического доступа (владельца ресурса доступа).
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Данная мера требует, чтобы логический доступ к каждому ресурсу доступа был согласован с тем, кто отвечает за эксплуатацию системы в плане целей ее использования.
Решение владельца ресурса доступа должно быть получено до фактического назначения прав доступа.
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом", должен быть определен порядок уведомления владельца ресурса доступа о том, что субъект запрашивает доступ к ресурсу, порядок принятия решения владельцем ресурса доступа решения (доступ предоставить, отказать, скорректировать, отозвать), порядок фиксации решения владельца ресурса доступа в материалах, взаимосвязанных с материалами фактического предоставления доступа, где можно было бы определить, что администратор ресурса доступа выполнил решение владельца ресурса доступа.
Проверочные процедуры (свидетельства)
Заявка на предоставление прав доступа с визой (резолюцией) владельца ресурса доступа.
Резолюция владельца ресурса доступа в задаче по согласованию прав доступа в системе управления задачами или системе документооборота (если такие системы используются для фиксации процедур управления правами доступа).
Приказ, распоряжение владельца ресурса доступа в отношении субъекта.
Типичные недостатки
Не выявлено.
Компенсационные меры
Не выявлено.
Выявленные коллизии
Не выявлено.
УЗП.8 (О-Т-Т)
Хранение эталонной информации о предоставленных правах логического доступа и обеспечение целостности указанной информации.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Для пояснения.
Реализация - О
Хранение эталонов прав логического доступа можно обеспечить путем заполнения специальных форм, содержащих описание состава прав доступа и данные субъекта, кому предоставляется доступ.
Обеспечение целостности может реализовываться за счет электронной подписи формы, вычисление контрольного хэш-кода формы либо хранения форм с составом прав доступа в печатном виде.
При организации целостности информации о правах доступа необходимо обеспечить невозможность воздействия на фактор, обеспечивающий целостность, эксплуатационного персонала, имеющего высокие права доступа.
Реализация - Т
После каждого изменения предоставленных правах логического доступа должен осуществляется резервное копирование БД, где хранятся права доступа и производится контроль целостности.
Реализовать это возможно в ручном режиме:
Создать копию БД AD (ntds.dit).
Вычислить контрольную сумму (certutil -hashfile путь_к_файлу SHA512).
В автоматизированном режиме с помощью автоматически настроенных бэкапов и контроля целостности, осуществляемого специализированным продуктом по резервному копированию.
Проверочные процедуры (свидетельства) - Т
Скриншоты:
бэкапов БД AD и других БД, где хранятся права доступа (АБС, ДБО …);
периодичность таких бэкапов;
где и как хранятся хэши БД Свидетельства;
демонстрация того, как производится процедура резервного копирования и проверка целостности.
Проверочные процедуры (свидетельства) - О
Пример файла, содержащего описание прав доступа и данные субъекта, подписанного электронной подписью либо имеющего хэш-значение, либо демонстрация печатных форм.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.9 (О-Т-Т)
Контроль соответствия фактических прав логического доступа эталонной информации о предоставленных правах логического доступа.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера направлена на защиту неправомерного использования логического доступа лицами не имеющего права на него.
Реализация - О
Контроль соответствия фактических прав логического доступа эталонной информации о предоставленных правах логического доступа может выполняться путем визуального сравнения работником фактических прав с эталоном с последующим обязательным оформлением результатов такого сравнения в виде актов, отчетов и пр.
Реализация - Т
Данную меру можно реализовать:
1. Использованием систем класса IDM/IAM.
Использованием скриптов для сопоставления эталонной информации о предоставленных правах фактической информации.
Проверочные процедуры (свидетельства) - Т
1. Матрица ролей, в которой описаны все субъекты и ресурсы логического доступа в соответствии с их должностными инструкциями и политикой Организации.
Скриншоты настроек IDM\IAM-системы.
Проверочные процедуры (свидетельства) - О
Примеры актов, служебных записок, отметок в журналах о результатах контроля прав доступа.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.10 (Т-Т-Т)
Исключение возможного бесконтрольного самостоятельного расширения пользователями предоставленных им прав логического доступа.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Для пояснения.
Реализация - Т
Реализовано встроенным функционалом AD, АБС, ДБО и др. или IDM системами с учётом корректного назначения прав доступа в соответствии с разработанной матрицей доступа исключив избыточные привилегий.
Проверочные процедуры (свидетельства)
Один из способов проверить корректность реализации меры попробовать в системе совершить действия непредназначенные для данной УЗ (от прав пользователя создать УЗ).
Необходимо убедится в отсутствии УЗ АРМ наделённых неограниченных прав делегирования для этого в PS на AD:
Или в Панели управления AD раздел Компьютеры далее свойство на УЗ далее делегирование.
Свидетельства:
Скриншоты:
Отсутствия неограниченного делегирования.
Попытки осуществить изменение прав в AD GPO, АБС, ДБО.
Типичные недостатки
Наделение пользователей административными правами;
В сетях AD наделение УЗ АРМ неограниченным и ограниченное делегированием;
В сетях AD назначение пользователям прав на изменение GPO.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.11 (Т-Т-Т)
Исключение возможного бесконтрольного изменения пользователями параметров настроек средств и систем защиты информации, параметров настроек АС, связанных с защитой информации.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Для пояснения.
Реализация - Т
Реализуется встроенным функционалом СЗИ, и АС (перечислить какие) путём настройки СЗИ и АС таким образом, что бы вносить изменения в конфигурацию систем могли исключительно эксплуатационный персонал.
Проверочные процедуры (свидетельства)
Для процедур
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.12 (О-О-О)
Контроль необходимости отзыва прав субъектов логического доступа при изменении их должностных обязанностей.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Данная мера требует, чтобы состав полномочий доступа в любой момент времени строго соответствовал минимально необходимому субъекту набору прав доступа, в соответствии с фактическими должностными обязанностями и выполняемыми процессами.
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом", должен быть определен порядок отзыва или пересмотра прав субъектов логического доступа при изменении их должностных обязанностей, срок такого пересмотра, порядок фиксации процедуры пересмотра прав доступа.
Проверочные процедуры (свидетельства)
Заявка на пересмотр прав доступа субъекта при изменении его должностных обязанностей.
Задача по актуализации прав доступа субъекта при изменении его должностных обязанностей в системе управления задачами или системе документооборота (если такие системы используются для фиксации процедур управления правами доступа).
Приказ, распоряжение владельца ресурса доступа в отношении субъекта.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.13 (О-Т-Т)
Контроль прекращения предоставления логического доступа и блокирование учетных записей при истечении периода (срока) предоставления логического доступа.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Для пояснения.
Реализация - О
Для реализации меры во внутренних документах должна быть определена периодичность контроля и порядок проведения такого контроля, установлен образец фиксации результатов (в виде актов, служебных записок и пр.), а также состав лиц, кто информируется о результатах контроля. Периодичность контроля должна быть разумной (хотя бы раз в квартал) и охватывать все ресурсы доступа (ОС, СУБД, АС, среду виртуализации). Результаты контроля должны фиксироваться установленным в документе порядком и передаваться для устранения замечаний (блокирование выявленных действующих по истечении периода (срока) предоставления логического доступа учетных записей). Ответственный работник также должен проверить выполнение задачи по блокирования и поставить отметку контроля. К такому контролю относится, в том числе и контроль прекращения прав доступа работника при увольнении и подписании обходного листа.
Реализация - Т
Встроенным функционалом AD и других АС при настройке максимального срока жизни пароля в 90 дней и функционалом по созданию временных УЗ с определённым сроком жизни и последующей блокировкой;
Внедрить IDM систему и осуществить аналогичные настройки.
Проверочные процедуры (свидетельства) - О
Для реализации О Примеры актов контроля учетных записей и примеры выполненных задач по блокированию учетных записей с отметкой о проверке результатов выполнения.
Проверочные процедуры (свидетельства) - Т
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.14 (О-Т-Н)
Установление фактов неиспользования субъектами логического доступа предоставленных им прав на осуществление логического доступа на протяжении периода времени, превышающего 90 дней
Уровень защиты информации 3-О, 2-Т, 1-Н
Пояснение
Для пояснения
Реализация - О
Установление фактов неиспользования прав доступа свыше 90 дней может выполняться путем визуального контроля ответственным работников фактов отсутствия аутентификации для ресурса доступа субъектом свыше 90 дней (на основе записи о предыдущей аутентификации в журнале или путем выгрузки из систем, баз данных учетных записей, не использовавшихся свыше 90 дней). Результаты проверки должны оформляться по установленной форме (актами, служебными записками и пр). Для корректного выполнения такая проверка должна выполняться не реже раза в квартал.
Реализация - Т
Встроенным функционалом AD и других АС при настройке максимального срока жизни пароля в 90 дней (в AD Политика паролей -> Максимальный срок действия паролей – 90 дней)
Производить поиск и блокировку пользователей скриптом
Внедрить IDM систему и произвести соответствующие настройки
Проверочные процедуры (свидетельства) - Т
Проверочные процедуры (свидетельства) - О
Примеры актов, служебных записок, отметок в журналах о результатах контроля учетных записей ресурсов доступа, не использовавшихся субъектами свыше 90 дней
Типичные недостатки
Для недостатков
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
УЗП.15 (Н-Н-Т)
Установление фактов неиспользования субъектами логического доступа предоставленных им прав на осуществление логического доступа на протяжении периода времени, превышающего 45 дней.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Для пояснения
Реализация - Т
Установление фактов неиспользования прав доступа свыше 45 дней должно устанавливаться техническими средствами (специально настроенными скриптами проверки либо применением системы IdM)
При этом может быть настроен как уведомительный контроль (об итогах проверки информируются ответственные работники для принятия решения), либо автоматическое блокирование доступа при превышении срока неиспользования учетной записи.
Следует отметить, что для полного выполнения мера должна применяться ко всем ресурсам, не только к учетным записям операционной системы, но и учетным записям автоматизированных систем, СУБД, среды виртуализации, а также учитывать, что программный сервис относится к субъектам доступа
Проверочные процедуры (свидетельства)
Пример настроенного в расписании задач скрипта поиска неактивных свыше 45 дней учетных записей. Для всего набора ресурсов доступа (учетных записей ОС, АС, СУБД, среды виртуализации) либо скрин настройки ограничения неиспользования учетной записи 45 дней. Скриншоты выявления неактивных учетных записей
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.16 (О-О-О)
Реализация контроля со стороны распорядителя логического доступа целесообразности дальнейшего предоставления прав логического доступа, не использованных субъектами на протяжении периода времени, указанного в мерах УЗП.14, УЗП.15 настоящей таблицы.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Данная мера требует, чтобы в любой момент времени доступ к ресурсам имели только субъекты, фактически использующие систему. Мера защищает от ситуации отказа от действий. Если логический доступ будет получен несанкционированным лицом (в том числе в результате сговора), при этом субъект может доказать, что не мог выполнить действия в системе ввиду физического отсутствия (физической невозможности выполнять действия в системе).
Мера особенно актуальна в случае длительного отпуска, длительного больничного или иной причины длительного отсутствия субъекта.
Нужно обратить внимание, что корректная реализация требует, чтобы контроль полномочий и реакция владельца ресурса доступа были не реже указанных в мерах промежутков в 90 (45) дней
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом", должен быть определен порядок, по которому владелец ресурса доступа уведомляется о наличии неиспользуемых свыше 90 дней (45 дней) учетных записей, установлен порядок запуска и исполнения процедуры пересмотра прав доступа.
Проверочные процедуры (свидетельства)
Акт (протокол) контроля состояния УЗ для субъектов, кто не использовал права доступа свыше 90 (45) дней, свидетельство передачи акта владельцам ресурсов доступа и фиксации их решений.
Служебная записка в адрес владельца ресурса доступа, резолюция владельца ресурса доступа, фиксация результата исполнения резолюции.
Задача по актуализации прав доступа субъектов на основании акта контроля состояния учетных записей в системе управления задачами или системе документооборота (если такие системы используются для фиксации процедур управления правами доступа). В цепочке исполнителей задачи должно фиксироваться участие и решение владельца ресурса доступа.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.17 (О-Т-Т)
Реализация возможности определения состава предоставленных прав логического доступа для конкретного ресурса доступа.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера требует наличие механизма для определения в любой момент времени состава зафиксированных прав доступа субъектов для некоего конкретного ресурса доступа (при невозможности или экономической нецелесообразности использования технического решения).
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом", должен быть определен порядок, согласно которому обеспечивается фиксация и учет состава предоставленных прав для ресурса доступа, обеспечение защиты от несанкционированных изменений носителя, где зафиксирован состав прав логического доступа для конкретного ресурса доступа.
Реализация - Т
Реализацией требования также может быть ведение актуальной матрицы доступа в системах учета обращений, например – «Jira» или вики-системах, например – «Confluence».
Реализацией требования может стать внедрение IAM/IDM-систем, при помощи которых обеспечивается контроль за всеми правами логического доступа, выданными для конкретного ресурса доступа для всех пользователей этого ресурса.
Проверочные процедуры (свидетельства)
Реализация - О Реестр прав доступа для конкретного ресурса доступа в отношении каждого субъекта доступа. Допустимо выгрузить из ресурса доступа в форме отчета либо вести реестр вручную. Мера не определяет в случае организационной реализации способ фиксации. Таким образом формально оформленные на субъектов заявки в совокупности также позволяют определить состав предоставленных прав доступа. Механизм выполнения меры должен предусматривать корректный учет последующего изменения прав доступа и возможности построения последовательности наделения прав во времени.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.18 (О-Т-Т)
Реализация возможности определения состава предоставленных прав логического доступа для конкретного субъекта логического доступа.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера требует наличие механизма определения в любой момент времени, какой состав прав логического доступа разрешен конкретному субъекту для всех ресурсов доступа (при невозможности или экономической нецелесообразности использования технического решения).
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом", должен быть определен порядок, согласно которому обеспечивается фиксация и учет состава предоставленных субъекту прав для всего состава ресурсов доступа, обеспечение защиты от несанкционированных изменений носителя, где зафиксирован состав прав логического доступа для конкретного субъекта доступа.
Реализация - Т
1.Встроенным функционалом AD и других АС.
2.Внедрить IDM систему.
Проверочные процедуры (свидетельства)
Реализация - О Реестр прав доступа в отношении каждого субъекта доступа. Допустимо выгрузить из ресурса доступа в форме отчета либо вести реестр вручную. Может быть единым с реестром меры УЗП.17.
Мера не определяет в случае организационной реализации способ фиксации. Таким образом формально оформленные на субъектов заявки в совокупности также позволяют определить состав предоставленных прав доступа.
Механизм выполнения меры должен предусматривать корректный учет последующего изменения прав доступа и возможности построения последовательности наделения прав во времени.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
УЗП.19 (О-Т-Т)
Определение состава ролей, связанных с выполнением операции (транзакции) в АС, имеющих финансовые последствия для финансовой организации, клиентов и контрагентов, и ролей, связанных с контролем выполнения указанных операций (транзакций), запрет выполнения указанных ролей одним субъектом логического доступа.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера обеспечивает защиту от злоупотребления полномочиями и реализует принцип “четырех глаз”.
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом". Для ресурсов доступа, в которых выполняются операции (транзакции) с финансовыми последствиями, должна быть указана необходимость использования ролевой модели. При этом указано название ролей, используемых для регистрации операций и ролей, используемых для контроля выполнения операций. В документе должен быть указан запрет совмещения одним субъектом (одним работником) роли регистрации операции и роли контроля выполнения операции.
Реализация - Т
Данную меру можно реализовать:
1. Встроенными механизмами разграничения доступа в прикладном ПО АС в соответствии с принятой ролевой моделью;
2. Использованием IDM-системы.
Проверочные процедуры (свидетельства) - О
Скриншоты ролевой модели из АС, где выполняются операции (транзакции) имеющие финансовые последствия. В ролевой модели должны быть выделены различные роли для регистрации операций и роли, используемые для контроля выполнения операций. Проверяется включение в группы состава субъектов (работников), чтобы один субъект (работник) не был включен в обе группы одновременно.
Проверочные процедуры (свидетельства) - Т
1. Матрица ролей, в которой описаны все субъекты и ресурсы логического доступа в соответствии с их должностными инструкциями и политикой Организации;
2. Скриншоты настроек IDM-системы;
Скриншоты настроек прикладного ПО с разграничением доступа к выполнению операций и администрированием АС.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
В системах с массовым выполнением операций (транзакций), имеющих финансовые последствия и с высоким быстродействием автоматической обработки операций не выполняются работниками операции контроля. Регистрация операций выполняется сервисом автоматически из-под технической учетной записи.
Такими системами, например, являются системы процессинга.
В системах ДБО также зачастую не выполняется обработка работниками операций. Операции регистрируются сервисом и сразу перегружаются в другую систему основного учета, где и может выполняться контроль. В таких системах роли контроля также не выделяются.
УЗП.20 (О-Т-Т)
Реализация правил управления правами логического доступа, обеспечивающих запрет совмещения одним субъектом логического доступа ролей, предусмотренных мерой УЗП.19 настоящей таблицы.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера обеспечивает защиту от злоупотребления полномочиями и реализует принцип “четырех глаз”.
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом". Для ресурсов доступа, в которых выполняются операции (транзакции) с финансовыми последствиями, должна быть указана необходимость использования ролевой модели. При этом указано название ролей, используемых для регистрации операций и ролей, используемых для контроля выполнения операций. В документе должен быть указан способ обеспечения запрета совмещения одним субъектом (одним работником) роли регистрации операции и роли контроля выполнения операции. Такими способами могут быть:
- запрет согласования прав доступа в случае попытки включения субъекта в обе группы одновременно;
- систематический контроль состава групп и отсутствие одновременного включения в обе группы одного субъекта.
Реализация - Т
Данную меру можно реализовать:
1. Встроенными механизмами разграничения доступа в прикладном ПО АС в соответствии с принятой ролевой моделью;
2. Использованием IDM-системы.
Проверочные процедуры (свидетельства) - О
Скриншоты ролевой модели из АС, где выполняются операции (транзакции) имеющие финансовые последствия. В ролевой модели должны быть выделены различные роли для регистрации операций и роли, используемые для контроля выполнения операций. Проверяется включение в группы состава субъектов (работников), чтобы один субъект (работник) не был включен в обе группы одновременно.
Если документами определена обязательность контроля, также проверяются свидетельства выполнения такого контроля.
Если документами определен запрет согласования прав при попытке включения субъекта в обе группы, проверяется отметка на заявке факта проверки, что субъект не получает доступ одновременно в группу формирования операций и группу контроля операций.
Проверочные процедуры (свидетельства) - Т
1. Матрица ролей, в которой описаны все субъекты и ресурсы логического доступа в соответствии с их должностными инструкциями и политикой Организации;
2. Скриншоты настроек IDM-системы;
Скриншоты настроек прикладного ПО с разграничением доступа к выполнению операций и администрированием АС.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
В ряде организаций используется ротация персонала (при недостаточности ресурсов), когда один работник попеременно может выполнять роль по регистрации, либо роль по контролю, но в разные периоды времени (не пересекающиеся в цикле обработки операции). Если такая практика используется, она должна быть детально описана в документе. При этом указан способ недопущения ситуации, когда в ходе ротации работник получит доступ к операции и на этапе регистрации, и на этапе контроля (например, операция зарегистрирована одним днем, но обрабатывается следующим днем, при этом между днями проведена ротация персонала). Такие ситуации желательно обрабатывать программно (операция, зарегистрированная под учетной записью субъекта, не может быть проконтролирована под той же учетной записью вне зависимости от прошедшего времени или смены рабочего места).
УЗП.21 (Н-О-Т)
Реализация правил управления правами логического доступа, обеспечивающих запрет совмещения одним субъектом логического доступа следующих функций:
эксплуатация и (или) контроль эксплуатации ресурса доступа, в том числе АС, одновременно с использованием по назначению ресурса доступа в рамках реализации бизнес-процесса финансовой организации;
создание и (или) модернизация ресурса доступа, в том числе АС, одновременно с использованием по назначению ресурса доступа в рамках реализации бизнес-процесса финансовой организации;
эксплуатация средств и систем защиты информации одновременно с контролем эксплуатации средств и систем защиты информации;
управление учетными записями субъектов логического доступа одновременно с управлением правами субъектов логического доступа.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Требование находится в таблице «Базовый состав мер по организации, контролю предоставления (отзыва) и блокированию логического доступа», что говорит о необходимости реализации разграничения прав доступа работников финансовой организации в соответствии с назначенными ролями.
С учетом описания меры защиты информации можно сказать, что она направлена скорее на ресурсы доступа, которые имеют схожие с АС механизмы (например, системы централизованного управления виртуальными машинами, ДБО, автоматизированные банковские системы, внутренние сервисы финансовой организации, в рамках которых могут быть выделены роли «пользователь», «администратор», «администратор ИБ», а также те АС, которые обрабатывают защищаемую информацию в контексте рассматриваемых Положений Банка России).
Мера обеспечивает защиту от злоупотребления полномочиями, внесения несанкционированных изменений в АС и средств защиты в целях сокрытия неуполномоченных действий.
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом".
В документе должны быть определена необходимость выделения ролей, связанных с:
- эксплуатацией (поддержкой АС);
- использование АС в рамках бизнес-процесса;
- контролем функционирования АС;
- внедрением или доработкой АС;
- сопровождением средств защиты;
- контролем средств защиты;
- управлением учетными записями;
- управлением правами доступа.
При этом должен быть указан запрет совмещения одним лицом функций для следующих сочетаний:
- использование АС по назначению не разрешает одновременное обслуживание (сопровождение, настройку) и контроль функционирования АС;
- использование АС по назначению не разрешает одновременное внедрение, разработку и доработку АС;
- обслуживание (сопровождение, настройка) средств защиты не разрешает контроль средств защиты;
- регистрация учетных записей не разрешает выполнять наделение полномочиями
Реализация может быть в виде назначения работников организации приказами, либо определение функций в должностных инструкциях работников.
Реализация - Т
Данное требование описывает необходимость выделения следующих ролей:
1. Администратор/разработчик ресурса доступа;
2. Пользователь ресурса доступа;
3. Администратор СЗИ/ИБ.
4. Account Manager.
Реализацией требования могут стать как настройки матрицы доступа для каждого из ресурсов доступа, так и интеграция ресурсов доступа со внутренними SSO (или системами типа AAA), которые будут предоставлять необходимые права доступа в соответствии с выделенными ролями. При этом в матрице доступа должен быть реализован технический запрет совмещения ролей согласно формулировке меры (например, при назначении учетной записи роли пользователя запрещается эту же учетную запись регистрировать для роли администратора системы). Техническая реализация запрета возможна путем программной установки запрета одновременной регистрации учетной записи в конфликтных группах доступа.
Проверочные процедуры (свидетельства) - О
Заявки на предоставление доступа.
Приказы на назначение полномочий.
Должностные инструкции. В должностных инструкциях проверяются функции и обязанности, установленные работнику.
Рекомендуется дополнительно проверять группы в АС для выполнения бизнес-функций на включение в них учетных записей администраторов, а также групп администрирования на включение пользовательских учетных записей.
Проверочные процедуры (свидетельства) - Т
Матрица прав доступа, фактические настройки (скриншоты) IDM/IAM систем, при помощи которых обеспечивается разделение прав доступа к ресурсам доступа финансовой организации, протоколы интервью с работниками организации, включающие в себя описание ролей и разделение их ответственности за выполнение требований меры защиты информации.
При этом рекомендуется предоставлять свидетельства реализации требования с учетом ограничения конфликтных сочетаний (например, скриншот, что включение в группу бизнес-пользователей УЗ не дает ту же УЗ включить в группу админов).
Типичные недостатки
Не выявлено.
Компенсационные меры
Не выявлено.
Выявленные коллизии
В ряде организаций недостаточно кадровых ресурсов для разделения функций по разграничению регистрации учетных записей и наделению полномочиями в АС.
Для ряда АС технически невозможно разделение функций по регистрации учетных записей и наделению полномочиями, наделение ролью осуществляется в момент создания учетной записи.
Last updated