Как обеспечить защиту данных в корпоративном хранилище

Корпоративное хранилище данных (DWH) аккумулирует самую ценную информацию компании: выручку, клиентские базы, персональные данные, стратегические планы, детали сделок. Утечка или потеря таких данных может привести к штрафам, репутационным потерям и даже уголовной ответственности. При этом, по статистике, хранилища данных находятся под угрозой не меньше, чем операционные системы, но их защите часто уделяют меньше внимания – ошибочно полагая, что «раз это аналитика, то и хакерам неинтересно».

В этой статье разберём основные угрозы для DWH и дадим практические рекомендации, как выстроить многоуровневую защиту корпоративного хранилища данных.

Какие угрозы актуальны для хранилища данных

Угрозы можно разделить на три категории:

Внешние атаки. Хакеры могут проникнуть через уязвимости в сетевых сервисах, украсть учётные записи или использовать фишинг. Цель – выкрасть базу клиентов или коммерческую тайну для продажи или шантажа.

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

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

Защита DWH должна работать на всех трёх фронтах.

Уровень 1. Защита инфраструктуры

Шифрование данных

Все данные в хранилище должны быть зашифрованы. Два обязательных места:

• Шифрование на диске. Современные СУБД и файловые системы поддерживают прозрачное шифрование. Даже если злоумышленник физически украдёт жёсткий диск, он не прочитает информацию без ключа.
• Шифрование в каналах передачи. При передаче данных из источников в DWH и от DWH к BI-системам должен использоваться TLS (тот же протокол, что в HTTPS). Никакие запросы не должны ходить по открытым каналам.

Резервное копирование по схеме 3 2 1

Золотой стандарт для защиты от потери данных:

• 3 копии данных (оригинал плюс две резервных).
• 2 разных типа носителей (например, дисковая СХД и ленточная библиотека или облако).
• 1 копия должна храниться физически отдельно (в другом здании или регионе).

Регулярно проверяйте восстановление из резервных копий. Бесполезная копия – это копия, из которой нельзя восстановиться за приемлемое время.

Физическая безопасность серверов

Если DWH развёрнут локально: серверная должна быть с контролем доступа, камерами, резервным питанием и охлаждением. Если в облаке – выбирайте провайдера с сертификатами (например, ISO 27001) и дата-центрами уровня Tier III и выше.

Уровень 2. Управление доступом

Ролевая модель (RBAC)

Никто не должен иметь «админский» доступ без необходимости. Типовые роли для DWH:

• Администратор DWH – полный доступ к настройкам, ETL, структуре. Минимум людей (1–2).
• Аналитик данных – может читать агрегированные и обезличенные данные, но не видит персональные колонки (ФИО, паспорт, телефон).
• Руководитель отдела – видит данные только своего отдела или региона.
• BI-система – имеет отдельную сервисную учётную запись с правами только на чтение нужных витрин.

Принцип минимальных привилегий

Выдавайте пользователю ровно те права, которые ему необходимы для работы, и ни на одну операцию больше. Это касается и инженеров, настраивающих ETL. Например, разработчик ETL может писать данные в промежуточную зону, но не имеет права удалять исторические таблицы в ядре DWH.

Аудит всех действий

Любое обращение к данным должно логироваться: кто, когда, что за запрос сделал, сколько строк выгрузил, успешно или нет. Логи должны храниться в защищённом месте (лучше – в отдельной системе) не менее года. Это поможет расследовать инциденты и доказывать их отсутствие при проверках.

Уровень 3. Защита самих данных

Маскирование и анонимизация

Для аналитиков и тестировщиков не нужны настоящие персональные данные. Настройте маскирование: вместо реального ФИО показывать «Иванов А.А.», вместо точного адреса – только город. Для некоторых задач достаточно агрегированных данных (например, «средний чек в сегменте 30–40 лет» без привязки к конкретному человеку).

Контроль качества и происхождения данных

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

Ограничение на экспорт

Если аналитик может сделать SELECT * и сохранить результат в CSV, считайте, что данные утекли. Настройте ограничения:

• Максимальное количество строк в результате (например, не более 100 тысяч).
• Запрет на интерактивный экспорт больших объёмов – только через утверждённый процесс выгрузки.
• Логирование и оповещение при попытке выгрузить больше определённого порога.

Уровень 4. Организационные меры

Технологии бесполезны без правил и контроля.

Политика безопасности

Письменно зафиксируйте:

• Кто какие роли занимает.
• Как оформляется доступ (заявка, согласование с владельцем данных).
• Как часто пересматриваются права (например, раз в квартал).
• Что считается инцидентом и как его расследуют.

Обучение сотрудников

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

Договоры с подрядчиками

Если вы привлекаете внешнюю команду для внедрения или поддержки DWH, пропишите в договоре обязательства по неразглашению (NDA), ограничение доступа только на время работ и право на аудит.

Самые частые ошибки в защите DWH

Ошибка 1. Защищён только периметр, а внутри – «все доверенные».

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

Ошибка 2. Резервные копии не проверяются.

При пожаре или атаке выясняется, что бэкапы не восстанавливаются уже год. Проверяйте восстановление планово.

Ошибка 3. Администраторы имеют доступ к данным пользователей.

Это риск. Выдавайте администраторам доступ только к настройкам, но не к бизнес-данным. Используйте разделение полномочий.

Ошибка 4. Забывают про разработчиков ETL.

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

Компания Intez Group проектирует корпоративные хранилища данных с учётом практик безопасности: шифрование, ролевая модель, аудит, резервное копирование. Мы также проводим аудит безопасности уже работающих DWH. Оставьте заявку на консультацию – мы покажем, как защитить ваши данные на всех уровнях.