Методические рекомендации Банка России от 14.09.2018 № 23-МР
Порядок доступа к инсайдерской информации и охрана её конфиденциальности
Часть 1 статьи 11 224-ФЗ обязывает разработать и утвердить порядок доступа к инсайдерской информации и правила охраны её конфиденциальности. Документ утверждает организация, а система исполняет его техническими средствами: разграничивает доступ до отдельной вкладки карточки, отдельного действия и отдельного вложения и оставляет след, по которому это проверяется.
Два требования Методических рекомендаций № 23-МР программа исполняет собственными средствами — пункт 2.2.4 о разграничении прав доступа к базам данных и пункты 2.2.5–2.2.6 о средствах идентификации и аутентификации. Как они устроены в поставке, разобрано ниже; остальные требования — в карте «требование ↔ функция».
- 6 × 7 действий на семь типов защищаемых объектов — 16 применимых сочетаний Источник: модель доступа модуля безопасности, перечень действий и типов объектов
- 12 + 12 разделов карточки события регуляторного риска и карточки инцидента — каждый со своим правом на чтение и изменение Источник: перечни разделов карточек, объекты безопасности
- 5 режимов аутентификации, переключаемых свойством конфигурации Источник: перечень режимов аутентификации приложения
- 3 уровня конфиденциальности в справочнике: гриф доступа попадает в карточку события и в выгрузки Источник: справочник уровней конфиденциальности карточки события
Что рекомендуют Методические рекомендации № 23-МР
Методические рекомендации Банка России от 14.09.2018 № 23-МР «По разработке и утверждению порядка доступа к инсайдерской информации и правил охраны её конфиденциальности», пункт 2.2.4, пункты 2.2.5–2.2.6. Источник: cbr.ru. Приведён пересказ, а не дословная цитата. Методические рекомендации носят рекомендательный характер.Пересказ. Пункт 2.2.4 рекомендует разграничивать права доступа к базам данных между работниками, осуществляющими ввод инсайдерской информации, и работниками, осуществляющими её последующую обработку. Пункты 2.2.5–2.2.6 рекомендуют применять средства идентификации и аутентификации и присваивать пользователям уникальные идентификаторы.
Обратите внимание на конструкцию пункта 2.2.4: он требует не «ограничить доступ», а именно развести тех, кто вводит сведения, и тех, кто их обрабатывает. Это требование к устройству системы, а не к дисциплине сотрудников, — и проверяется оно на настройках, а не на объяснениях.
Матрица прав: шесть действий на семь типов защищаемых объектов
Риск, который это снимает. Когда доступ выдаётся «на экран» или «на роль целиком», согласование матрицы доступа превращается в спор о том, что именно человек увидит. Здесь доступ выдаётся на типизированный объект, и у каждого типа свой набор применимых действий — обсуждать можно конкретную ячейку, а не общее ощущение.
Нажмите любую ячейку матрицы: под таблицей появится пояснение, что означает это сочетание. Матрица работает с клавиатуры — переход табуляцией, нажатие пробелом или вводом.
На узком экране таблица прокручивается по горизонтали.
| Тип объекта | Чтение | Изменение | Добавление | Удаление | Выполнение | Фильтр |
|---|---|---|---|---|---|---|
| Справочник | ||||||
| Действие | ||||||
| Отчёт | ||||||
| Статусная модель | ||||||
| Раздел карточки инцидента | ||||||
| Категория инцидента | ||||||
| Раздел карточки события РР |
Как читать матрицу. «Да» означает, что такое разрешение существует и его можно выдать роли; прочерк — что сочетание в модели не применяется. Нажмите любую ячейку, чтобы увидеть, что именно открывает или закрывает это право.
Из 42 сочетаний в модели применяются 16: для каждого типа объекта предусмотрен только тот набор действий, который для него имеет смысл. Выдать роли право, которого нет в перечне, невозможно — это ограничение самой модели доступа, а не настройки.
Права выдаются до отдельной вкладки карточки, а не на карточку целиком
Риск, который это снимает. Материалы события неоднородны: описание обстоятельств, заключение, переписка, вложения. Если доступ выдаётся на всю карточку, то сотрудник, которому нужно было увидеть один раздел, получает все — и круг лиц, имеющих доступ к чувствительным материалам, расширяется молча.
Как устроено. Каждый из 12 разделов карточки события регуляторного риска и каждый из 12 разделов карточки инцидента — самостоятельный объект безопасности с раздельными правами на чтение и изменение. Раздел, на который нет права чтения, в карточке не открывается.
| Карточка | Разделы | Что это даёт |
|---|---|---|
| Событие регуляторного риска | Описание · Классификация · Последствия · Причины · Мероприятия · Процедуры · Анкета · Инциденты · Заключение · Чат · Базовое описание · Похожие события | Ветвям согласования выдаётся ровно тот объём материалов, который нужен для их части работы. |
| Инцидент | Описание · Классификация · Источник · Нарушения · Последствия · Полное решение · Компенсации · Риск · Запросы · Чат · Журнал изменений · Похожие события | Раздел «Нарушения» с указанием нарушенного требования и раздел «Запросы» со сроками закрываются отдельно от остальной карточки. |
Отдельный вид разрешения — фильтр видимости строк с выражением-условием: он задаёт набор записей, которые попадают в реестр, и применяется так же, как обычное разрешение роли.
Вложения «Ограниченный доступ»: единственный механизм, где признак секретности реально управляет доступом
Риск, который это снимает. Самое чувствительное в разборе события — не поля карточки, а приложенные файлы: выгрузки, переписка, материалы проверки. Именно они утекают, и именно к ним обычно нет отдельного контроля.
Как устроено. У вложения есть признак «Ограниченный доступ». Скачать или удалить такое вложение может только сотрудник, которому выдано отдельное право на работу с файлами ограниченного доступа. Право входит в перечень защищаемых действий наравне с загрузкой данных и настройкой измерений, то есть выдаётся именно и только тем, кому оно нужно.
Почему это важно назвать отдельно
Это единственный механизм продукта, в котором признак секретности не описывает объект, а управляет доступом к нему. Всё остальное — уровень конфиденциальности события, гриф доступа — маркировка. Мы называем разницу прямо, потому что при выборе системы её путают чаще всего.
Признак бинарный: вложение либо ограниченного доступа, либо нет. С трёхуровневым справочником конфиденциальности события он не связан.
Разделение ввода и последующей обработки — то, чего требует пункт 2.2.4
Риск, который это снимает. Пока ввод и обработка сведений выполняются в одном интерфейсе с одинаковыми правами, работник, зафиксировавший событие, может его же и переквалифицировать. Пункт 2.2.4 методических рекомендаций требует развести эти две роли технически.
Как устроено. В продукте разделение выражено сразу четырьмя способами, и все четыре работают одновременно.
- Разный состав обязательных полей Для ролей «Сотрудник» и «Руководитель» на вкладке «Описание» обязательны девять полей: инициатор, подразделение, в котором произошло событие, подразделение, обнаружившее событие, дата создания, дата выявления, дата наступления, краткое описание, описание и состояние. Для роли «Сотрудник СПНП» обязательно одно поле — состояние. Тот, кто вводит, обязан заполнить обстоятельства; тот, кто обрабатывает, работает с уже введённым.
- Урезанное представление реестра Если у пользователя ровно одна роль — координатор, реестр предсобытий открывается в сокращённом виде. Полный реестр событий и реестр предсобытий — это одно представление с противоположными фильтрами по статусу, и координатор видит только свой участок.
- Разграничение по статусу После выхода события из статуса «Предсобытие» карточка становится доступной на чтение остальным ролям. Момент перехода из ввода в обработку определён статусом, а не договорённостью.
- Фильтры видимости строк Отдельный вид разрешения ограничивает набор записей выражением-условием: сотрудник видит не весь реестр, а свою часть.
Точная формулировка
Требование пункта 2.2.4 исполняется в базе данных продукта: система разграничивает доступ к материалам события — до отдельной вкладки карточки, отдельного действия и отдельного вложения. Соседние базы организации — кадровые, учётные, торговые — работают под собственными средствами разграничения, и вместе они образуют общий контур доступа.
Пять режимов аутентификации и уникальные идентификаторы
Риск, который это снимает. Общая учётная запись обесценивает весь журнал: протокол показывает, что статус сменил «оператор», а не человек. Пункты 2.2.5–2.2.6 методических рекомендаций требуют именно персональной идентификации.
Как устроено. Режим аутентификации выбирается одним свойством конфигурации, менять код для этого не нужно.
| Режим | Как работает | Когда выбирают |
|---|---|---|
| Служба каталогов с Kerberos | Проверка учётной записи в службе каталогов организации по протоколу Kerberos. | Домен уже есть, и учётные записи ведутся централизованно. |
| Служба каталогов | Проверка логина и пароля в службе каталогов; состав полномочий наполняется оттуда же. | Нужен единый источник учётных записей без сквозного входа. |
| Сквозная аутентификация | Пользователь входит под доменной учётной записью рабочей станции без повторного ввода пароля. | Рабочие места в домене, требуется вход без пароля. |
| Файл пользователей | Учётные записи описываются файлом настроек приложения. | Стенды, пилот, изолированный контур без домена. |
| База данных | Учётные записи хранятся в базе данных, пароли — под алгоритмом BCrypt. Только в этом режиме доступны самостоятельное восстановление доступа и персональные настройки пользователя. | Домена нет либо часть пользователей вне домена. |
Отдельно от аутентификации пользователя настраивается подключение к базе данных: оно возможно как под общей учётной записью, так и под доменной по Kerberos. Уникальный идентификатор — учётная запись с логином и доменом, связанная с конкретным сотрудником оргструктуры; именно эта связка позволяет протоколу смены статусов показывать фамилию, а не техническое имя.
Прямое обращение к внутренним адресам представлений запрещено на уровне правил доступа приложения, страницы входа и выхода открыты, всё остальное требует аутентификации.
Маркировка конфиденциальности материалов события
У карточки события есть реквизит «Гриф доступа» и уровень конфиденциальности — справочник из трёх значений: «Открытая информация», «Конфиденциальная информация», «Строго конфиденциальная информация». Это отвечает той части части 1 статьи 11 224-ФЗ, которая касается маркирования материалов в рамках правил охраны конфиденциальности.
Уровень конфиденциальности и гриф доступа описывают материалы события; на проверку прав они не влияют. Доступом в продукте управляют права на объекты и признак «Ограниченный доступ» у вложения.
Что это даёт ИТ-директору
- Глубина ролевой модели известна заранее. Шесть действий, семь типов объектов, 16 применимых сочетаний, раздельные права на 24 раздела двух карточек, отдельное право на каждый переход по маршруту и фильтры видимости строк. Матрица доступа проектируется до внедрения, а не выясняется в ходе него.
- Учётные записи не дублируются. Полномочия наполняются из службы каталогов, оргструктура и сотрудники загружаются регламентным импортом. Отдельного каталога пользователей продукт не требует.
- Консоль администрирования отделена от прикладной работы. В ней шесть разделов: роли, субъекты, пользователи, пользователи подсистемы отчётности, журнал работы, журнал аудита безопасности. Роль администратора безопасности и ещё семь прикладных ролей защищены от редактирования и удаления.
- Настройка, а не доработка. Режим аутентификации, способ подключения к базе данных и расписание загрузки данных задаются свойствами конфигурации.
- Первое действие при внедрении. Конфигурационные шаблоны из поставки содержат демонстрационные учётные данные и заменяются на боевые до запуска в эксплуатацию. Это стандартный пункт чек-листа внедрения, и мы называем его заранее.
Развёртывание в закрытом контуре организации или в частном облаке, поддерживаемые операционные системы и системы управления базами данных подтверждает поставщик на этапе пилота.
Куда идти дальше
На чём основана разработка
Продукт предоставляет инструменты, которыми организация исполняет процедуры своих правил внутреннего контроля и своего порядка доступа к инсайдерской информации, и оставляет доказательство их исполнения для ответственного должностного лица. Разработано с учётом требований статьи 11 Федерального закона № 224-ФЗ, Указания Банка России № 5222-У и Методических рекомендаций № 23-МР.
- Журнал аудита безопасности фиксирует попытки входа с причиной отказа, состав ролей вошедшего, изменение пользователей, назначение и снятие ролей, добавление и удаление разрешений; журнал работы фиксирует вход пользователя в разделы. Оба выгружаются в файл.
- Протокол смены статусов хранится вместе с событием и показывает движение материалов события: дату и время, старый и новый статус, фамилию сотрудника, комментарий.
Смежные разделы: маршрут события и статусная модель — то, ради чего выдаются права на переходы; рабочее место ответственного должностного лица — как этими правами пользуются в работе; карта «требование ↔ функция» — построчный разбор требований трёх актов; контур комплаенса — как система встраивается в работу банка.