Когда BI работает с критичными данными, цена ошибки возрастает. Разбираем типовые риски и способы решения для безопасного запуска и эксплуатации
К корпоративным системам, работающим с конфиденциальной информацией, предъявляются повышенные требования по информационной безопасности. Системы бизнес-аналитики (Business Intelligence, BI) занимают в этом ряду особое место. BI-инструменты аккумулируют данные из множества внутренних источников и могут содержать сведенную информацию, относящуюся к коммерческой тайне, инсайдерские сведения и другие критически важные данные. Их сохранность напрямую влияет на коммерческий успех и конкурентоспособность компании.
Из-за постоянного взаимодействия с такими данными вытекают две первоочередные задачи по приведению BI-системы в соответствие с требованиями информационной безопасности: обеспечение конфиденциальности передачи данных, а также контроль и учет доступа к ним.
1. Конфиденциальность передачи данных в BI системах
Данная задача в современных условиях успешно решается, при помощи прикладных протоколов шифрования обмена данными, таких как протокол защиты транспортного уровня (англ. Transport Layer Security или сокр. TLS), в более старых версиях также известного как SSL.
Можно выделить четыре основных направления обмена данными в BI-системе, где требуется обеспечить конфиденциальность передачи данных:
1. Между бизнес-пользователем и BI-системой
Большинство современных BI-систем содержат в своем составе веб-приложение в качестве основного интерфейса взаимодействия с пользователем. Коммуникация веб-браузера бизнес-пользователя с BI-системой чаще всего шифруется защищенной при помощи TLS версии протокола HTTP, известной как HTTPS. Большинство BI-систем предлагают готовые встроенные возможности для его настройки в веб-приложении.
По нашему опыту обслуживания существующих BI-систем, все еще встречаются устаревшие развертывания BI-приложений с HTTP без шифрования, чаще всего защищенные внешним шифрованием канала связи. В связи с повсеместным вытеснением незащищенной версии HTTP современными веб-браузерами, типовой задачей при обслуживании BI-систем является миграция с HTTP на HTTPS.
2. Между BI-системой и источниками данных
Для успешной защиты данной коммуникации требуется поддержка шифрования как со стороны системы управления базами данных (СУБД), так и со стороны компонента BI-системы, ответственного за подключение (коннектора или драйвера). Практически все современные СУБД и их клиентские библиотеки поддерживают настройку шифрования соединения при помощи TLS.
Из нашей практики обслуживания и развертывания BI-систем, для успешной реализации данной задачи требуется тесная коммуникация с командами систем хранения данных и инфраструктуры, особенно если TLS по каким-то причинам недоступен и требуется замещающее архитектурное решение.
3. Между BI-системой и связанными системами
При наличии интеграций с другими системами, зачастую может потребоваться доступ BI-системы к программным интерфейсам (API) этих систем. В подавляющем большинстве случаев такие интеграции осуществляются при помощи протоколов, приближенных к обычному протоколу просмотра веб-страниц HTTP, таких как REST, WebSocket и других. Шифрование для таких API реализуется идентичным HTTPS способом при помощи TLS.
Как и в предыдущем случае, может потребоваться взаимодействие с командами других систем.
4. Между компонентами самой BI-системы
Следуя тенденциям последнего десятилетия, современные BI-системы могут быть выполнены в микросервисной архитектуре. Некоторые BI-системы поддерживают кластеризацию — в сочетании с микросервисной архитектурой или без нее. В таких развертываниях компоненты BI-системы могут размещаться на нескольких отдельных физических или виртуальных серверах. Коммуникации между частями BI-системы зачастую требуют дополнительной защиты во избежание несанкционированного доступа к данным или нарушения работы всей системы в целом.
К сожалению, далеко не все поставщики BI-систем уделяют должное внимание данному аспекту. В одном из наших проектов потребовалось реализовать замещающее общее архитектурное решение на базе туннелирования для шифрования всей служебной коммуникации между компонентами BI-системы, что позволило привести систему в соответствие с требованиями отдела информационной безопасности.
В заключение следует отметить, что недавние достижения в области квантовых вычислений, уже в самом ближайшем будущем потребуют дополнительной инспекции, обновления или пересмотра используемых решений в части шифрования.
2. Контроль и учет доступа к данным в BI системах
Любая современная BI-система реализует внутри приложения локальную систему управления доступом на основе ролей (RBAC), в том или ином виде ограничивая доступ к контенту.
Однако ни одна BI-система не существует в изоляции — она встраивается в существующую инфраструктуру компании и обязана подчиняться принятой политике и требованиям информационной безопасности. Список требований к информационной системе, имеющей учетные записи пользователей, обычно типовой и обширный, и для его выполнения не всегда достаточно встроенного функционала. В него входит и аудит доступа, и управление паролями, выдача и отзыв доступа. Попытка выполнить весь список требований создает дополнительную нагрузку на команду поддержки BI-системы, а для пользователей — неудобства в виде еще одного отдельного пароля.
Чтобы удовлетворить требования информационной безопасности без дополнительных издержек и неудобств для пользователей, BI-системы интегрируют с другими информационными системами компании посредством технологии единого входа (Single Sign-On, SSO). Это критически важное звено в инфраструктуре компании, позволяющее пользователям использовать единую учетную запись, а команде BI-системы — передать весомую часть задач по аудиту и управлению учетными записями выделенной для этого команде (по независимым оценкам, до 50% обращений пользователей составляют только запросы на сброс пароля), концентрируясь только на функционале приложения.
Функционал SSO реализует отдельная информационная система-посредник в инфраструктуре компании, называемая провайдером идентификации (IdP). Ее использование открывает возможности предъявлять дополнительные требования ко входу пользователя в BI-систему средствами IdP — такие, как многофакторная идентификация (MFA), собственная поддержка которой в составе функционала BI-систем встречается редко.
Кроме этого, провайдеры идентификации постоянно совершенствуются и часто предоставляют поведенческий анализ и факторный анализ попыток обращения пользователей к приложению, поднимая безопасность на новый уровень, недоступный для штатного функционала BI-системы. IdP может отказать во входе в BI-систему пользователю на основе географических факторов, например, совершившему вход из необычно удаленного места, или предотвратить попытку входа злоумышленника после кражи учетных данных, рассчитав невозможное за короткий промежуток времени перемещение пользователя из одной географической локации в другую.
По опыту развертывания BI-систем, не везде реализация функционала SSO проходит без замечаний. Бывает, что остаются некоторые неожиданные мелкие недостатки для пользователей, обусловленные протоколами SSO, их реализацией или особенностями IdP. Например, в одном из недавних проектов при первом входе в систему по прямой ссылке на дашборд после успешного входа через SSO и перенаправления обратно в BI-систему не происходил переход на изначальный дашборд, по которому хотел перейти пользователь. Приходилось еще раз искать ссылку и переходить по ней второй раз, когда пользователь уже авторизовался в BI-системе. С нашей стороны было разработано дополнительное компенсирующее решение специально для размещения прямых ссылок на дашборды на других ресурсах внутри компании, позволяющее сгладить момент первого входа в систему и обеспечить удобство пользователей.
Заключение
Приведение BI-системы в соответствие требованиям информационной безопасности не всегда является лишь рутиной настройки. Часто встречаются и нестандартные требования, реализация которых требует разносторонних знаний. Например, в одном из проектов требовалось показывать специальное предупреждение и получать согласие пользователя перед началом работы с системой. Такой функционал отсутствовал в BI-системе, но без него система не допускалась в промышленную эксплуатацию. Не дожидаясь доработки от вендора, в короткие сроки проанализировали возможности и реализовали требуемый функционал поверх BI-приложения своими силами — это позволило ввести систему в эксплуатацию в необходимые сроки.
Таким образом, обеспечение информационной безопасности BI-систем — не формальная «галочка» на этапе запуска, а обязательное условие устойчивой работы с данными, сохранения коммерческой тайны и доверия пользователей внутри компании. Защищенная передача данных, корректно выстроенный контроль доступа, аудит и интеграция с корпоративной инфраструктурой должны закладываться в архитектуру и процессы внедрения с самого начала и регулярно пересматриваться по мере развития системы и появления новых угроз.
