Безопасность данных в BI-системе

Как и любая информационная система, BI подвержена различным информационным угрозам. В этой статье рассмотрим, что такое безопасность данных, где в BI-системах уязвимые места и как защитить свои данные. Поехали!

Информационная безопасность (ИБ) — это комплекс мер и средств, направленных на защиту конфиденциальности, целостности и доступности информации.

Информационные угрозы могут быть следующими:

Это в полной мере относится как к данным в электронном виде, так и к хранящимся на физических носителях (например, бумажным документам). Особенно серьезными считаются угрозы, связанные с «преступлением как услугой» (англ. Crime-as-a-Service), т.е. заказными атаками, Интернетом вещей, цепями поставок и усложнением требований регуляторов.

Основная задача информационной безопасности — сбалансированная защита данных. Это достигается, в основном, через поэтапное управление рисками: выявление источников угроз и уязвимости, определение потенциальной степени воздействия и выработку защитных мер.

Свойства информации претерпевали изменения с развитием самой IT-инфраструктуры.

В 1975 году Джерри Зальцер (Массачусетский технологический институт) и Майкл Шрёдер предложили три ключевых принципа, которые еще называют триадой CIA (Confidentiality, Integrity, Availability):

В 1998 году Донн Паркер дополнил классическую триаду ещё тремя аспектами:

Система из 6 пунктов получила название «Паркеровская гексада».

В 2009 и 2011 появились новые модели, но классической по-прежнему остается CIA. Хотя, в профессиональной среде постоянно поднимается вопрос о ее современности.

Например, Международный стандарт ISO использует следующую схему:

Мы в статье будем опираться на триаду CIA.

Тем, что данных, собственно, очень много: BI работает с большими объемами информации. А значит, вопрос безопасности данных и разделения доступа к ним относится к первостепенной важности.

Кроме того, с точки зрения бизнеса определенные данные могут быть чувствительными.

Чувствительные данные – данные, раскрытие которых может нести риски для субъекта, к которому они относятся.

Нет единого стандарта, что относится к такого рода данным – каждая компания сама определяет, какую информацию считать конфиденциальной. Главное отличие – в степени последствий, которые наступят, если данные украдут или изменят. Это могут быть личные данные сотрудников и клиентов, номера счетов, данные по оплатам, клиентская база и т.п.

Но и к ним система должна предоставлять доступ по запросу авторизованного пользователя.

То есть, основные усилия должны быть направлены на соблюдение триады CIA – конфиденциальности, целостности и, в то же время, доступности. Это достигается за счет мер, которые развивают BI-системы.

Когда мы говорим о том, что система должна защищать данные от неавторизованных пользователей, то встает вопрос о проверке подлинности пользователя на этапе входа в систему.

Для этого используют различные протоколы аутентификации и авторизации.

У нас в Modus (кроме внешних) есть еще свой встроенный протокол, который не использует стороннее ПО - аутентификация и проверка доступа происходят внутри нашего приложения.

С помощью него можно настроить сложность и повторяемость пароля, используемые алфавиты и символы в паролях, срок действия учетной записи. Мы контролируем переборы, блокируем подозрительные учетные записи.

Также могут использоваться другие протоколы - SAML, OAuth, позволяющие использовать стороннее ПО (keycloak, adfs, Битрикс).

Для доступа к системе пользователь обязательно должен пройти процедуру аутентификации. Дальше, если все нормально, он получает токен, в котором записывается информация о том, когда он прошел эту процедуру, какие присвоены права, и что пользователь может делать в системе.

При выполнении процедуры аутентификации взаимодействие с сервером должно выполняться с использованием защищенного протокола - https. Желательно иметь возможность организовать это взаимодействие как с помощью BI-системы, так и с помощью стороннего ПО, например, nginx.

В Modus организовать взаимодействие по https можно двумя способами. При организации httpsбез стороннего ПО мы поддерживаем несколько версий протокола TLS: от устаревших 1.0,1.1 до более современных 1.2 и 1.3.

После прохождения аутентификации важная часть получения доступа к информации — это авторизация, которая определяет, что пользователь может делать в системе.

Управление доступом может быть:

- ролевое, когда права доступа группируются с учётом специфики их применения, образуя роли;

- избирательное, когда пользователь идентифицируется, как принадлежащий группе или процессу, которая имеет или не имеет доступ к определенной информации;

- мандатное – когда определенная информация помечается, как конфиденциальная, а пользователю, в свою очередь, присваивается или не присваивается право доступа к ней;

- гибридное (смешанное).

Мы в Modus используем гибридную схему на основе ролевого и избирательного управления доступом.

У нас есть три базовых роли (по степени уменьшения прав):

Администратор может полностью управлять системой и настраивать ее: создавать учетные записи, описывать подключения к хранилищам данных, настраивать доступ. Такая учетная запись должна быть у одного проверенного человека. Можно создать несколько учетных записей с такой ролью, но их количество должно быть минимальным.

Аналитик работает с доступными для него источниками данных, настраивает наборы данных и дашборды для доступа конечных пользователей к бизнес-информации. Эту роль желательно выдавать тем сотрудникам, которые непосредственно работают с данными и настраивают отчеты.

Пользователь использует доступные ему дашборды, но ничего не настраивает и метаинформацию редактировать не может. Он может открывать отчеты, фильтровать данные, настраивать фильтры, возможно, экспортировать и выгружать данные. Это роль с наименьшим количеством прав.

Избирательное управление доступом мы настраиваем с помощью профилей и прямого назначения пользователям прав. Профиль – по сути, группа объектов, к которым мы хотим предоставить доступ учетным записям.

Например, у нас есть отчеты, которые используются одним подразделением. Мы объединяем их в один профиль и назначаем его определенным пользователям, которые будут пользоваться этими данными.

С помощью ролей и профилей доступа BI-система решает, кому и какую информацию можно предоставить. Это касается и метаданных портала c настройками, и данных бизнеса.

Так мы соблюдаем конфиденциальность и целостность системы. Т.е. пользователь не сможет получить доступ к блоку данных, изменить или удалить информацию, если ему явно не выдали на это права.

Аналитический портал работает напрямую с разными базами данных в режиме SQL-запросов. Т.к. в портале есть инструменты для написания этих запросов (базовые действия аналитика), то для сохранения целостности данных необходимо контролировать то, какие запросы пишет аналитик.

Мы, как правило, дополняем возможности соответствующих СУБД, у которые есть свои механизмы, связанные с безопасностью, ролевым доступом, назначением прав на определенные таблицы. Поэтому очень важно следить за тем, какие права и привилегии предоставляет администратор СУБД. Если большое количество сотрудников будет работать с базой данных под ролью супер-пользователей, то волшебства не произойдет, и возможно нарушение целостности и конфиденциальности информации.

С точки зрения "доступности" данных мы принудительно ограничиваем объемы, с которыми может работать приложение и пользователь. Это позволяет регулировать нагрузку без потери достоверности данных.

Выше уже говорили, что необходимо следить за тем, какие данные на уровне таблиц и кубов должны быть доступны пользователям. Однако, зачастую в BI системах (и не только в них) возникает необходимость разграничить доступ для различных пользователей внутри одной таблицы или куба.

К примеру, фактические продажи одного подразделения не должны быть доступны для сотрудников другого подразделения.

Однако, для руководителей и топ менеджмента данные должны быть доступны все. Для подобного разграничения используются механизмы RLS - доступ на уровне строк.

RLS мы настраиваем 2 способами:

1. Удобный графический интерфейс, где все настраивается без программирования. Самый простой в использовании – достаточно посмотреть документацию. Этот способ хорошо подойдет для небольших данных и не очень больших компаний.

+ просто настроить

- на больших данных возможно замедление при получении данных

2. С помощью серверных пользовательских переменных - SQL-запрос дополняется секциями, в которых аналитик настраивает фильтры.

+ высокая производительность за счет того, что выполняется «точечная» доработка запроса аналитиком, а не автоматически формируется универсальный запрос для всевозможных ситуаций

+ возможна интеграция с данными из внешних систем аутентификации/авторизации. Например, передача ИНН, имени подразделения, по которым должны быть отфильтрованы данные.

- сложность входа и первоначальной настройки. Но также есть документация и примеры настройки

Для обеспечения информационной безопасности могут применяться и другие методы. Например, мы в Modus активно используем статические анализаторы кода, которые ищут уязвимости, отчеты которых мы постоянно анализируем и отрабатываем.

Помимо анализаторов кода в целом следим за тем, чтобы не было возможности SQL-инъекции. SQL injection - это атака, во время которой вредоносный код вставляется в строки, которые будут переданы для анализа и выполнения.

Например, есть поле для ввода пароля. И злоумышленник может вместо пароля ввести некий SQL-запрос, который передается в СУБД и выполняется as is.

Также мы не храним такие данные, как пароли, в открытом виде – одни мы храним зашифрованными, другие в виде хэша.

И конечно, мы постоянно проводим аудит системы как собственными силами, так и с привлечением для этого партнеров.

Мы будем развивать RLS: построим серединное решение, чтобы RLS можно было настроить в интерфейсе, и это не сказывалось на скорости работы системы даже потенциально.

Также планируем совершенствовать механизмы логирования в части доступа к данным и их изменению.