Федеральный закон от 27.07.2010 № 224-ФЗ, статья 11
Требования статьи 11 Федерального закона № 224-ФЗ и что из них поддерживает продукт
Статья 11 — единственная статья 224-ФЗ, которая адресована организации как таковой и требует от неё построенной процедуры. Ниже — карта «требование ↔ функция»: требования трёх нормативных актов и механизмы системы, которые работают на каждое из них.
За неисполнение или ненадлежащее исполнение обязанностей по принятию мер, направленных на предотвращение, выявление и пресечение злоупотреблений на финансовых и товарных рынках, установлена административная ответственность частью 4 статьи 15.35 КоАП РФ: на должностных лиц — от 20 000 до 30 000 рублей либо дисквалификация на срок до одного года, на юридических лиц — от 300 000 до 700 000 рублей. Это ровно та связка «обязанность — санкция», которую проверяет надзор, и ровно тот участок, где продукт оставляет доказательство исполнения.
- 19 требований, на каждое из которых в продукте есть работающий механизм Источник: карта соответствия «требование ↔ функция», разделы 1.1–1.3
- 3 нормативных акта разобраны построчно: 224-ФЗ, Указание № 5222-У, Методические рекомендации № 23-МР Источник: карта соответствия «требование ↔ функция»
- 2 требования Методических рекомендаций № 23-МР исполняются средствами самой программы — разграничение прав доступа и аутентификация Источник: пункты 2.2.4 и 2.2.5–2.2.6 карты соответствия
- 5 режимов аутентификации, переключаемых свойством конфигурации Источник: конфигурация подсистемы аутентификации
Что требует часть 1 статьи 11 224-ФЗ: порядок доступа и ответственное должностное лицо
Федеральный закон от 27.07.2010 № 224-ФЗ «О противодействии неправомерному использованию инсайдерской информации и манипулированию рынком и о внесении изменений в отдельные законодательные акты Российской Федерации», статья 11, часть 1. Источник: consultant.ru. Приведён пересказ, а не дословная цитата.Пересказ. Часть 1 статьи 11 обязывает организацию разработать и утвердить порядок доступа к инсайдерской информации и правила охраны её конфиденциальности либо включить эти положения в правила внутреннего контроля; создать структурное подразделение или назначить должностное лицо, подотчётное лицу, осуществляющему функции единоличного исполнительного органа, для контроля за соблюдением требований закона, и обеспечить условия для беспрепятственного и эффективного осуществления им своих функций.
В части 1 четыре самостоятельные обязанности, и проверяются они по-разному. Документ — «порядок доступа» и «правила охраны конфиденциальности» — организация утверждает своим решением. Три остальные обязанности проверяются по следам: назначено ли лицо, есть ли у него условия для работы, ведётся ли контроль за соблюдением порядка. Следы оставляет система, и именно на этом участке продукт помогает: разграничение доступа к материалам события настраивается до отдельной вкладки карточки и отдельного вложения, а всё движение фиксируется в протоколе с датой, временем и фамилией.
Разбор рабочего места назначенного лица вынесен в отдельный материал — рабочее место ответственного должностного лица, а техника разграничения доступа — в порядок доступа к инсайдерской информации и охрану конфиденциальности.
Что требует часть 2 статьи 11 224-ФЗ: правила внутреннего контроля, выполнение которых обеспечено
Федеральный закон от 27.07.2010 № 224-ФЗ, статья 11, часть 2. Источник: consultant.ru. Приведён пересказ, а не дословная цитата.Пересказ. Часть 2 статьи 11 обязывает организацию разработать, утвердить и обеспечивать выполнение правил внутреннего контроля по предотвращению, выявлению и пресечению неправомерного использования инсайдерской информации и (или) манипулирования рынком.
Ключевое слово здесь — «обеспечивать выполнение». Утверждённые правила сами по себе обязанность не исполняют: при проверке спрашивают не текст документа, а подтверждение того, что описанная в нём процедура действительно отрабатывала на конкретных сообщениях. Разница между этими двумя состояниями и есть предмет продукта: маршрут рассмотрения задан статусной моделью, единственный выход из предсобытия ведёт в первичную оценку, право на каждый переход выдаётся отдельным разрешением, а протокол смены статусов остаётся как доказательство. Подробный разбор — правила внутреннего контроля, которые исполняются системой.
Требования к содержанию самих правил задаёт Указание Банка России от 01.08.2019 № 5222-У. Полный текст пунктов Указания в открытом доступе не публикуется, поэтому в карте ниже состав обязательных положений приведён обобщённо, по вторичным источникам, и помечен как обобщение, а не как цитата.
Карта «требование ↔ функция» по 224-ФЗ
Строка карты читается так: норма — что она требует — что в продукте на это работает. Каждая строка называет конкретный механизм: реквизит карточки, право, статус маршрута, журнал или отчёт, — со ссылкой на пункт нормативного акта.
| Норма | Требование (пересказ) | Что в продукте на это работает |
|---|---|---|
| Ст. 6, ч. 1 | Запрет использовать инсайдерскую информацию для операций, передавать её другому лицу и давать на её основе рекомендации. | Система сужает круг лиц, видящих материалы события: вкладки карточки — самостоятельные объекты безопасности с раздельными правами на чтение и изменение, а вложения с признаком «Ограниченный доступ» открываются только по отдельному праву. |
| Ст. 11, ч. 1 | Разработать и утвердить порядок доступа к инсайдерской информации и правила охраны её конфиденциальности. | Инструментарий, которым такой порядок исполняется в отношении материалов события: реквизит «Гриф доступа» и уровень конфиденциальности из трёх значений — «Открытая информация», «Конфиденциальная информация», «Строго конфиденциальная информация». Гриф попадает в карточку события и в выгрузки. |
| Ст. 11, ч. 1 | Контролировать соблюдение порядка доступа и правил охраны конфиденциальности. | Журнал аудита безопасности фиксирует попытки входа с причиной отказа, состав ролей вошедшего, изменение пользователей, назначение и снятие ролей, добавление и удаление разрешений; журнал работы фиксирует вход в разделы. Оба журнала выгружаются в файл и предъявляются при проверке. |
| Ст. 11, ч. 1 | Создать структурное подразделение или назначить должностное лицо, подотчётное единоличному исполнительному органу. | В ролевой модели выделен контрольный контур: «Эксперт ПНИИИМР», «Сотрудник СПНП», «Менеджер риска ИБ», «Менеджер риска ИТ», «Сотрудник СВК», «Аудитор», «Руководитель». Подотчётность выражена конструкцией маршрута: финальное согласование замкнуто на эксперта. |
| Ст. 11, ч. 1 | Обеспечить условия для беспрепятственного и эффективного осуществления функций назначенным лицом. | Рабочее место: раздельные представления реестра событий и предсобытий, карточка из 12 разделов, запросы информации с установленной и фактической датой ответа, чат по событию, регламентные оповещения о сроках, отчётность. |
| Ст. 11, ч. 2 | Разработать, утвердить и обеспечивать выполнение правил внутреннего контроля. | Процедурная часть правил исполняется системой: статусная модель события из 24 статусов и 38 переходов, единственный выход из «Предсобытия» — первичная валидация, отдельное разрешение на каждый переход, непустой комментарий на 25 переходах из 38, протокол смены статусов с датой, временем, фамилией и комментарием. |
| Ст. 14 | Банк России вправе требовать документы и информацию, необходимые для проверки соблюдения закона. | Доказательная база выгружается: протокол смены статусов, журнал аудита и журнал работы с сохранением в файл, отчёт по событиям, фиксация нарушенного требования с точностью до абзаца нормативного акта и оснований для привлечения к ответственности. Состав выгрузки собирается под конкретный запрос. |
Требования Указания Банка России № 5222-У к содержанию правил внутреннего контроля
Указание Банка России от 01.08.2019 № 5222-У задаёт состав обязательных положений правил внутреннего контроля. Полный текст пунктов в открытом доступе не публикуется, поэтому формулировки требований ниже приведены обобщённо, по вторичным источникам, и не выдаются за цитаты.
| Норма | Требование (обобщённо) | Что в продукте на это работает |
|---|---|---|
| 5222-У, п. 1 — функции, права и обязанности ОДЛ | Правила определяют функции, права и обязанности ответственного должностного лица. | Права описываются моделью «субъект → роль → право»: 6 действий (чтение, изменение, добавление, удаление, выполнение, фильтр) на 7 типов защищаемых объектов. Набор ролей поставки построен под процесс регуляторного риска, и функции ответственного должностного лица собираются из этих прав. |
| 5222-У, п. 1 — подотчётность и отчётность | Правила определяют подотчётность ОДЛ единоличному исполнительному органу и порядок составления и представления отчётов. | Отчётный контур: отчёт по событиям, отчёт о своевременности в шести разрезах, отчёты по качеству из пяти частей, интерактивная отчётность. Каждый отчёт — самостоятельный объект безопасности с правом на чтение, что позволяет открыть отчётность отдельному адресату. |
| 5222-У, п. 1 — порядок контроля и мероприятия | Правила описывают контрольные мероприятия и порядок контроля за совершением действий. | Меры и рекомендации ведутся собственной статусной моделью из 6 статусов и 7 переходов: «Создано» → «На согласовании СПНП» → «Согласовано» → «В работе» → «Выполнено» либо «Отклонено». Фиксируются дата направления, периодичность, отчёт об исполнении, результат оценки надлежащего исполнения и степень влияния на уровень риска. |
| 5222-У, п. 1 — оценка действий работников | Правила содержат процедуры оценки действий органов управления и работников организации. | Конструктор анкет: шесть типов вопросов (число, список значений, флаг, справочник, множественный выбор, текст), страницы и результаты; анкета — отдельная вкладка карточки события, отчёт по анкетированию — защищаемый объект. Содержание анкет организация задаёт под свои процедуры. |
| 5222-У, п. 1 — независимость ОДЛ | Правила обеспечивают независимость ответственного должностного лица и исключают конфликт интересов. | Разделение обязанностей заложено конструктивно: после верификации маршрут расходится на три независимые ветви — СПНП, информационная безопасность, информационные технологии, — и только после согласования СПНП событие уходит эксперту. Роль администратора безопасности и ещё семь прикладных ролей защищены от редактирования и удаления. |
| 5222-У, п. 1 — непрерывность функций | Правила обеспечивают непрерывность выполнения функций ОДЛ и преемственность. | Права привязаны к роли, а не к человеку, поэтому замещение выполняется переназначением роли. Отдельный предохранитель: если следующий статус недоступен ни одному пользователю системы, рассылается предупреждение о том, что событие останется без рассмотрения. |
Требования Методических рекомендаций Банка России № 23-МР
Методические рекомендации Банка России от 14.09.2018 № 23-МР носят рекомендательный характер, но именно по ним удобнее всего проверять порядок доступа: они расписаны до конкретных мер. Два требования этих рекомендаций — разграничение прав доступа и аутентификация — программа исполняет собственными средствами.
| Норма | Требование (пересказ) | Что в продукте на это работает |
|---|---|---|
| 23-МР, п. 2.2.4 | Разграничение прав доступа к базам данных работников, осуществляющих ввод инсайдерской информации, и работников, осуществляющих её последующую обработку. | Ввод и обработка разделены технически: состав обязательных полей вкладки «Описание» зависит от роли (девять полей для ролей «Сотрудник» и «Руководитель», одно — для «Сотрудника СПНП»); при единственной роли координатора реестр предсобытий открывается в урезанном представлении; после выхода события из статуса «Предсобытие» карточка доступна на чтение остальным ролям; отдельным видом разрешения задаётся фильтр видимости строк. |
| 23-МР, пп. 2.2.5–2.2.6 | Применение средств идентификации и аутентификации, присвоение уникальных идентификаторов. | Пять режимов аутентификации, переключаемых свойством конфигурации: служба каталогов с Kerberos, служба каталогов, сквозная аутентификация, файл пользователей, база данных. Полномочия наполняются из службы каталогов; подключение к базе данных возможно под доменной учётной записью по Kerberos; в режиме базы данных пароли хранятся под BCrypt. Уникальный идентификатор — учётная запись с логином и доменом, связанная с сотрудником. При внедрении конфигурационные шаблоны заполняются рабочими учётными данными организации. |
| 23-МР, п. 1.1.22 | Порядок запроса инсайдерской информации: форма запроса, требования к содержанию, сроки рассмотрения, основания для отказа. | Механизм запросов с реквизитами «Сотрудник, направивший запрос», «Содержание», «Дата запроса», «Дата ответа установленная», «Дата ответа фактическая», «Ответ» и вложениями; отдельная вкладка карточки «Запросы» с собственными правами; в маршруте — статусы «Запрос информации у инициатора» и «Информация по запросу предоставлена». |
| 23-МР, п. 1.1.9 | Права и обязанности ответственного должностного лица. | Права настраиваются до уровня отдельной вкладки карточки и отдельного действия: 12 разделов карточки события регуляторного риска, 12 разделов карточки инцидента, четыре защищаемых действия. |
| 23-МР, гл. 2 (общая мера) | Исключение несанкционированного доступа к инсайдерской информации. | Узел меню не существует для пользователя без права: справочник требует права на чтение, действие — права на выполнение; импорт и настройка измерений закрыты отдельными действиями; вложения с признаком «Ограниченный доступ» скачиваются и удаляются только при наличии соответствующего права. |
| 23-МР, п. 1.1 (передача между подразделениями) | Передача инсайдерской информации между подразделениями — с согласия ответственного должностного лица. | Переход события между подразделениями формализован как согласование: три параллельные ветви и финальное согласование эксперта, отдельное право на каждый переход, обязательный комментарий на большинстве переходов, явные статусы возврата «Возврат руководителю» и «Возврат СПНП». |
Что это даёт ИТ-директору
Карта требований нужна не только комплаенсу. Для ИТ-директора она отвечает на другой вопрос: какой объём обязанностей закрывается одной системой и как она встаёт в уже работающий ИТ-ландшафт.
- Область поставки очерчена. Девятнадцать требований трёх актов разобраны построчно, у каждого назван механизм системы. Это готовая исходная рамка для технического задания.
- Модель доступа предсказуема. Шесть действий на семь типов объектов, раздельные права на 12 разделов карточки, отдельное разрешение на каждый переход по маршруту, фильтры видимости строк. Согласование матрицы доступа с владельцем риска — работа обозримого объёма.
- Аутентификация не требует отдельного проекта. Пять режимов переключаются свойством конфигурации, полномочия наполняются из службы каталогов, подключение к базе данных возможно под доменной учётной записью.
- Точки интеграции известны заранее. Источники данных — файлы, внешняя база данных, служба каталогов, почтовый ящик: регламентный импорт оргструктуры, приём сообщений из общего ящика, доменная аутентификация.
Развёртывание в закрытом контуре и требования к инфраструктуре обсуждаются отдельно — их состав подтверждает поставщик на этапе пилота.
Куда идти дальше
Карта отвечает на вопрос «что требуется». На вопрос «как это выглядит в работе» отвечают соседние разделы: маршрут события и статусная модель из 24 статусов показывает процедурную часть части 2 статьи 11; порядок доступа и охрана конфиденциальности — два требования 23-МР, которые программа исполняет собственными средствами; событие ПНИИИМР как событие регуляторного риска по 716-П объясняет, почему такие события учитываются в базе событий операционного риска. Цену вопроса задаёт статья 15.35 КоАП РФ с точными суммами по каждому составу, а место системы в контуре комплаенс-функции — разбор того, как она встраивается в работу банка.