Предположим, что в организации используется информационная система (далее ИС), предоставляющая доступ к чувствительным данным организации. Например, ИС управления корпоративным контентом или ИС юридически значимого электронного документооборота с возможностью гибкого предоставления прав и логированием всех действий пользователей. Эта ИС активно используется несколькими тысячами или сотнями тысяч пользователей с разными правами в ИС. В этом случае, потребуется тонко настраивать и контролировать права пользователей. Простые решения для этого не подойдут.
Решение по трассировке прав в ИС
Коротко об элементах предлагаемого решения в виде пайплайна:
- Оперативные данные о фактах изменения и применения прав брать из логов ИС;
- Обогащать эти данные информацией о требованиях по изменению прав;
- Оперативно хранить эти обогащённые данные в отдельной таблице в БД ИС;
- Вести аудит изменений прав в ИС через БД;
- Передавать обогащённые данные и данные аудита БД в корпоративное хранилище данных (далее КХД или англ. DWH — Data Warerhouse) или в гибрид хранилища и озера данных (далее англ. Data Likehouse или DLH), реализованные на отдельной инфраструктуре, и хранить их там бессрочно с учётом их историчности, обеспечивая доступ к ним для их использования.
Формирование требований
Причины предлагаемого решения:
- Во-первых, для эффективного администрирования ИС требуется понимание какие права и кому предоставлены, а для обеспечения безопасности требуется возможность отслеживания на основании каких разрешений в ИС в разные моменты времени действовал пользователь. Всё это возможно при фиксации в истории факта изменения и применения разрешений в ИС.
- Во-вторых, для оптимизации модели предоставления разрешений в системе, особенно при активном росте количества пользователей, а также для проведения служебных расследований, требуется трассировка причинно-следственных связей между предоставлением разрешений и требованиями на их предоставление.
- В-третьих, (если это востребовано, в том числе в обозримой перспективе) для автоматизации разграничения предоставляемых прав в ИС требуются источники данных для разграничения этих прав и сам механизм разграничения.
Во всех выше перечисленных случаях требуется постоянно хранить данные о фактах предоставления разрешений в ИС, требований на предоставление этих разрешений, а также их использования. В итоге получаем одно из функциональных требований на возможность фиксации и постоянного хранения в ИС фактов изменения и применения разрешений.
Поиск решения
Ручное комментирование изменений
Одним из решений для выполнения требования о возможности фиксации и постоянного хранения в ИС фактов изменения и применения разрешений может быть фиксация требуемой информации в свободной форме в виде текстовых комментариев в местах изменения разрешений, если таковые предусмотрены.
Плюсы:
- Это решение не дорого и не сложно в реализации.
Минусы:
- Это решение сложно масштабируется. Например, при записи большого количества данных об изменениях в поля, предназначенные для небольших комментариев, они постепенно начнут существенно увеличивать размер БД и влиять на скорость её работы.
- Не применимо для фиксации фактов использования пользователями предоставленных им разрешений.
- Не везде в ИС может быть возможность добавления комментариев.
Аудит внесения изменений в БД ИС
Предоставить, изменить или удалить права пользователей ИС можно через БД, минуя интерфейс ИС. Для сохранения информации о подобных изменениях можно, например, использовать отдельную таблицу и фиксировать в неё вносимые изменения в БД с помощью триггеров.
Плюсы:
- Данное решение позволяет фиксировать любые изменения, вносимые в ИС.
- Не требуется изменить ИС, только БД.
Минусы:
- Решение будет замедлять операции (каждое изменение в БД будет добавлять 1 запись в аудите).
- Приведёт к удвоению объема данных.
- Сложно читать историюв подробном виде.
Создание и ручное заполнение таблицы изменений
Другим решением может быть создание таблицы трассировки внесения изменений в ролевую-атрибутивную модель предоставления разрешений в ИС. В этой таблице требуется предусмотреть возможность создания записи о дате и времени выполнения изменения, описание изменения с указанием изменяемого элемента объекта и произведённого изменения, источника требований для изменений и исполнителя.
Данную таблицу можно реализовать внутри ИС, например, через отдельный пользовательский интерфейс «Реестр предоставления прав». В интерфейсе, предусмотреть возможность вручную фиксировать предоставление любых прав в ИС. В случае подобной реализации можно фиксировать в этом реестре предоставление любых прав в системе, а также постоянно хранить их. Отдельным механизмом можно реализовать всплывающее окно при внесении изменений в местах предоставления прав для ввода причин производства изменений, с трансляцией полученного результата в «Реестр представления прав».
Плюсы:
- Данные из подобного решения могут быть использованы для исторического анализа существующих прав у пользователя на момент выполнения им действий в ИС.
- Также, эти данные могут быть использованы для разграничения предоставляемых разрешений на «до» и «после» внесения определённых изменений в его ролевую модель. Например, при изменении у пользователя места или характера выполняемых обязанностей.
Минусы:
- Требуется относительно дорогостоящая доработка ИС.
- Может привести к возрастанию таблицы из этого решения до такого размера, когда это сможет привести к замедлению работы ИС.
- Решение не позволяет интегрировать в себя данные из аудита БД. Т.к. это быстро значительно увеличит размер таблицы из этого решения и может заменить работу ИС.
Использование логов
Описанное выше решение можно улучшить и значительно удешевить его разработку, если использовать логи ИС в качестве основных данных об изменениях прав и их использовании.
Плюсы:
- В этом решении реализуются все функциональные требования, описанные здесь выше.
Минусы:
- В процессе эксплуатации ИС в этой таблице может накопиться такое количество данных, которое при их использовании будет способно значительно повлиять на быстродействие БД и всей ИС.
- Не оптимально хранить и использовать данные логов, имеющих, как правило, формат JSON, в реляционной таблице БД.
Создание DWH
Ещё одним улучшением выше описанного решения может быть создание DWH на отдельной инфраструктуре для хранения и использования данных о фактах всех изменений прав и их применения в ИС. В этом случае таблицу, описанную выше, можно использовать как транзитную для аккумулирования только «свежих» логов ИС, обогащения их данными об источниках требований изменения прав и передачи их в DWH. При этом, в слой «сырых» данных DWH (далее англ. Staging или STG) данные будут поступать «как есть» с помощью ELT-пайплайна (анл. Extract → Load → Transform или рус. Извлечь → Загрузить → Преобразовать).
Из STG слоя данные будут поступать в слой очищенных данных, где они будут обрабатываться и хранится методом STD Type 2 (добавление новой версии записи с новым ключом и пометками периода действия) с нормализацией до 3NF (все атрибуты с атомарным значениями, каждый коэффициент атрибут зависит от своего ключа, нет транзитивных зависимостей, т.е. не ключевые атрибуты не зависят от других не ключевых атрибутов) или лучше до Data Vault 2.0 (модели, состоящей из таблиц хабов с бизнес-ключами, таблиц связей между хабами и таблиц спутников с описательными атрибутами и историчностью) для сохранения полной историчности изменений и применения прав, а также высокой производительности хранилища и устойчивости его к изменениям. При подробной реализации данные слоя витрин могут быть денормализованы до звездообразной схемы (с центральной таблицей фактов и денормализованными таблицами измерений) для упрощения работы с ними конечным пользователям.
Плюсы:
- Это решение позволяет полностью реализовать выше описанное требование.
- DWH продаётся оптимизации.
- В предложенной реализации этого решения возможно развитие хранилища и перенос или дублирование всех исторических данных ИС в него.
- Это решение позволяет отдельным пайплайном добавлять данные об аудите БД в DWH, не нагружая ИС.
Минусы:
- Не самое дешёвое решение. Стоимость зависит, в том числе, от выбранных форм хранения данных на разных слоях хранилища.
- Трудозатратное решение на старте. Также, как и стоимость, зависит от выбранной формы хранения данных.
- Не оптимально хранить и использовать данные логов, имеющих, как правило, формат JSON, в реляционной таблице DWH.
Создание Data Likehouse
Для оптимизации хранения и использования логов в формате JSON вместо DWH можно рассмотреть Data Likehouse (гибрид хранилища и озера данных). Это решение может быть дешевле из-за возможности хранения неструктурированных данных.
Плюсы:
- Стоимость хранения данных ниже, чем в DWH.
- Оптимально для хранения логов в формате JSON.
- Это решение также, как и решение с DWH, позволяет отдельным пайплайном добавлять данные об аудите БД в Data Likehouse, не нагружая ИС.
Минусы:
- Сложность реализации требует высокой квалификации, а значит стоимости услуг привлечённых специалистов.