Согласование, права и аудит
Никто не согласует сам себя, и никто не остаётся анонимным
Разделение полномочий — не бюрократия, а единственная защита от того, что один человек проведёт решение от начала до конца без свидетелей. В модуле это правило встроено в переходы статусов: тот, кто отправил объект на согласование, не может его же и утвердить. Остальное — права на пять действий, фильтры на уровне строк и журнал, который нельзя переписать задним числом.
Принцип четырёх глаз: правило, которое нельзя «договориться обойти»
В большинстве систем разделение полномочий держится на регламенте: написано, что согласовывать должен другой человек. На практике другой человек в отпуске, и объект проводит тот же, кто его подготовил. Здесь это невозможно технически.
Переход запрещён тому, кто инициировал предыдущее состояние
Условие проверяется на четырёх переходах бизнес-единицы: утверждение и возврат из согласования, а также утверждение и возврат из согласования архивации. Система сравнивает инициатора текущего действия с автором предыдущего требуемого состояния — и отказывает, если это один человек.
Кликните состояние, чтобы увидеть, куда из него можно уйти и что этому мешает. Слева — настоящие названия состояний из справочника модуля.
Черновик рабочий план на стадии наполнения
Бизнес-единица заполняется: наименование, подразделение оргструктуры, офицер ИБ и старший офицер ИБ. Без этих полей дальше не пройти.
На согласовании
Объект ждёт решения. Именно здесь работает разделение полномочий.
Активна
Рабочее состояние: по бизнес-единице ведутся приложения и контроли.
Редактирование
Изменения вносятся в отдельном состоянии, а не поверх действующей карточки: активная бизнес-единица не меняется незаметно для согласующего.
Согласование архивации
Вывод бизнес-единицы из ведения — такое же решение, как её создание, и проходит тот же контроль вторым человеком.
Архив
Конечное состояние. Данные остаются доступными для чтения и попадают в выгрузки: архивация — не удаление.
Переходов из этого состояния в модели нет.
Обязательные поля — тоже контроль
Бизнес-единица не сохраняется без наименования, подразделения, офицера ИБ и старшего офицера ИБ. Приложение — без наименования, типа и статуса, а для действующего дополнительно требуется привязка к бизнес-единице. Формально закрытая карточка без ответственного перестаёт быть возможной.
Оргструктура не покрывается дважды
На одно подразделение может существовать только одна неархивная бизнес-единица; при попытке завести вторую модуль показывает существующую. Если бизнес-единица уже есть на вышестоящем подразделении, выдаётся предупреждение о дублировании покрытия.
У каждого объекта своя статусная модель — и это не декорация
Состояние объекта определяет, что с ним можно делать: править, отправить, утвердить, вернуть. Ниже — настоящие названия состояний, те же, что видит пользователь в интерфейсе и в выгрузке.
| Объект | Состояния |
|---|---|
| Бизнес-единица | ЧерновикНа согласованииАктивнаРедактированиеСогласование архивацииАрхив |
| Приложение (информационная система) | ШаблонПланированиеАктивноЗакрыто |
| Классификатор ИТ-риска | ШаблонОтправлено на одобрениеВозвратОдобрено |
| Анкета контроля | ШаблонЗаполнениеНа согласованииЗавершеноОдобреноШаблон (с дополнением) |
| Анкета определения области влияния | ЧерновикНа заполненииНа согласованииОдобренаДоработка |
| Оценка риска | ШаблонЗавершеноАрхивТребуется переоценка |
| Проблема | ШаблонЗавершено |
| Несоответствие | НеобработанОтменёнДубликатСвязан с Issue |
Как заданы переходы
У бизнес-единицы, приложения и классификатора ИТ-риска таблица переходов задана декларативно: разрешённые переходы и условия описаны данными. У анкет порядок переходов определяется порядком работы по контролю.
Права: пять действий, четыре типа объектов и фильтр на уровне строк
Право выдаётся роли на пару «объект безопасности — тип объекта» и состоит из пяти независимых флагов. Разделение чтения, записи, добавления, удаления и действия — это то, что позволяет дать аудитору доступ, не давая возможности что-либо поменять.
Чтение
Видеть объект и его данные. Этим же правом управляется видимость разделов навигатора.
Запись
Изменять существующие записи.
Добавление
Создавать новые записи — отдельно от права изменять чужие.
Удаление
Удалять записи. Самое опасное право выдаётся отдельно от остальных.
Действие
Выполнять операции над объектом — например, переводить его по статусной модели.
| Тип | Что защищает |
|---|---|
| Разделы навигатора | Видимость узлов меню: без права на чтение узел не отображается вообще |
| Справочники | Библиотеки вопросов, типы, статусы и прочие справочные данные |
| Настройки приложения | Параметры модуля |
| Объекты | Бизнес-единицы, приложения, контроли, анкеты, проблемы, оценки риска |
Фильтр уровня строк
К праву можно добавить условие, ограничивающее видимые строки. Так подразделение видит только свои бизнес-единицы, а не весь реестр организации, — без создания отдельных копий данных.
Изоляция прав модуля
У модуля собственная схема базы данных для безопасности: роли, назначения ролей, права и журнал. Назначения связаны с общей таблицей субъектов платформы, но сами права модуля живут отдельно и не смешиваются с правами соседних систем.
Роли и подразделения: где ЛПР узнает свою оргструктуру
В модуле есть поля ответственных — офицер ИБ и старший офицер ИБ бизнес-единицы, ответственные по информационной системе, инициатор анкеты и привлекаемый специалист. Ниже — типичное соответствие подразделениям заказчика.
| Поле в модуле | Кто обычно за этим стоит | Что делает |
|---|---|---|
| Офицер ИБ бизнес-единицы | Специалист службы ИБ, закреплённый за подразделением | Ведёт бизнес-единицу, запускает контроли, разбирает несоответствия |
| Старший офицер ИБ | Руководитель направления в службе ИБ | Согласует переходы, для которых требуется вторая пара глаз |
| Ответственные по информационной системе | Владелец системы, ответственный за ИБ системы, ответственный за приватность данных | Отвечают на вопросы анкеты и подтверждают признаки классификатора |
| Инициатор анкеты | Менеджер информационной системы или проекта | Запускает проверку и следит за её сроками |
| Привлекаемый специалист | Эксперт смежного подразделения — ИТ, юристы, комплаенс | Заполняет часть анкеты по своей области |
Как устроены роли
Ответственные хранятся как ссылки на сотрудника в атрибутах объектов, поэтому закрепление людей меняется без правки ролевой модели. С модулем поставляется роль администратора безопасности, а функциональные роли настраиваются при внедрении под оргструктуру заказчика.
Журнал безопасности: кто, кому и что изменил
Отдельный журнал модуля фиксирует администрирование доступа: кто выполнил действие, над каким пользователем, какое именно и что изменилось — со значениями до и после.
Безопасность
- Роли
- Назначения ролей
- Права
- Журнал безопасности
| Дата | Администратор | Пользователь | Действие | Описание изменения |
|---|---|---|---|---|
| 02.09 09:14 | Администратор Б. | Специалист И. | Создание | Назначена роль администратора безопасности |
| 02.09 09:31 | Администратор Б. | Специалист И. | Изменение | Логин: было — прежнее значение, стало — новое значение |
| 03.09 12:02 | Администратор Б. | Специалист П. | Удаление or Remove | Отозвано право удаления в разделе справочников |
Записи журнала не редактируются из интерфейса модуля.
Таблица прокручивается вбок внутри рамки.
29 аудируемых действий: список, который отвечает за вас
Когда проверяющий спрашивает «а фиксируется ли у вас возврат анкеты на доработку», спорить не нужно — достаточно показать перечень. Найдите действие поиском.
- 01 Дефицит контроля добавлен
- 02 Дефицит контроля обновлён
- 03 Данные документа добавлены
- 04 Данные документа обновлены
- 05 Комментарий добавлен
- 06 Дефицит контроля удалён
- 07 Данные документа удалены
- 08 Проблема создана
- 09 Проблема удалена
- 10 Несоответствие отменено
- 11 Несоответствие восстановлено
- 12 Несоответствие отмечено как дубликат
- 13 Несоответствие связано с проблемой
- 14 Анкета запущена
- 15 Анкета отправлена
- 16 Анкета возвращена
- 17 Анкета завершена
- 18 Анкета одобрена
- 19 Вопрос анкеты добавлен
- 20 Вопрос анкеты обновлён
- 21 Вопрос анкеты удалён
- 22 Оценка риска создана
- 23 Оценка риска обновлена
- 24 Оценка риска завершена
- 25 Оценка риска удалена
- 26 Оценка риска отправлена
- 27 Оценка риска возвращена
- 28 Оценка риска одобрена
- 29 Проблема обновлена
Перечень хранится и как перечисление в модуле, и как справочник в базе данных с двуязычными наименованиями.
История согласований ведётся по каждому объекту отдельно
Общий журнал показывает, что произошло в системе. История согласований отвечает на другой вопрос — что произошло с этим конкретным объектом и в каком порядке. Таких историй пять, по одной на объект, проходящий согласование.
Контроль бизнес-единицы
Запуск, отправка, возврат, завершение проверки подразделения.
Контроль приложения
Тот же путь для проверки информационной системы, включая дочерние контроли.
Проблема
Создание, обновление, изменение вероятности и обоснования.
Оценка риска
Создание, завершение, отправка, возврат и одобрение оценки.
Классификатор ИТ-риска
Отправка на одобрение, возврат с комментарием, одобрение.
Что это даёт ИТ-директору
Управление доступом остаётся управляемым
- Права модуля изолированы. Собственная схема базы данных с ролями, назначениями, правами и журналом; назначения ссылаются на общий каталог субъектов платформы. Ревизия прав модуля не требует разбора прав всех соседних систем.
- Пять флагов вместо «полный доступ / нет доступа». Аудитору можно выдать чтение без записи, оператору — добавление без удаления, согласующему — действие без права править содержимое.
- Видимость меню — это тоже право. Раздел, на который нет права чтения, не отображается в навигаторе: пользователь не видит того, чего ему не положено, и не задаёт вопросов о недоступных кнопках.
- Журналы разделены по назначению. Администрирование доступа — в журнале безопасности, изменения бизнес-объектов — через логируемые сервисы данных, действия по контролю — в перечне из 29 позиций и в истории согласований.
- Роль администратора безопасности — в поставке. Полный набор действий на четырнадцать объектов доступен сразу, а функциональные роли настраиваются под оргструктуру заказчика.
Посмотреть, как это считается на ваших данных
Показываем расчёт на модельной информационной системе: анкета, несоответствия, присущий и остаточный риск, уровень критичности и маршрут согласования.
Запросить демонстрацию Как проходит пилот
ООО «Ланселот-ИТ» · +7 (499) 380-74-23 · info@lancelot-it.ru