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

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

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

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

 

 

 

 

  1. Введение
  2. Разработка системы документов в области обеспечения информационной безопасности
  3. Установка DLP
  4. Разграничение доступа
  5. Ограничение прав суперпользователей при работе с базами данных
  6. Принцип работы Jatoba Data Vault
  7. Выводы

Введение

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

По данным исследования «СёрчИнформ», в первом полугодии 2020 года более чем в 90 % российских компаний «утекли» базы с данными клиентов, персональные сведения о сотрудниках или финансовые документы. Авторы исследования утверждают, что в 60 % случаев причиной стали намеренные действия сотрудников, а 40 % утечек произошли по причинам невнимательности и доверчивости.

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

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

Раскроем подробнее смысл каждой из описанных мер.

Разработка системы документов в области обеспечения информационной безопасности

Системный подход к обеспечению информационной безопасности в компании позволит существенно снизить риски в ИБ без затрат на покупку специализированных продуктов. Введите в компании режим защиты коммерческой тайны, подготовив специальную документационную базу, в которой будет чётко описано, какие сведения являются коммерческой тайной, кто и как обязан её защищать, передавать, использовать, какие санкции будут применяться к тем, кто нарушил правила работы с ней. Разработайте и подписывайте с каждым из сотрудников и с контрагентами договор о неразглашении коммерческой тайны (NDA).

Установка DLP

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

К недостаткам DLP-системы можно отнести высокую стоимость её интеграции и невозможность установки на личные устройства сотрудников, то есть, работая удалённо, сотрудник сможет бесконтрольно передавать информацию при наличии доступа к ней. Отсюда вытекает ещё одно необходимое условие — разграничение доступа.

Разграничение доступа

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

Ограничение прав суперпользователей при работе с базами данных

Решить вопрос с простыми пользователями обычно не представляется проблемой: ограничения требуют скорее управленческой воли, нежели сложных технических решений. Однако при работе с информационными системами, например базами данных (БД), всегда есть те, у кого больше прав, чем у всех остальных, так называемые суперпользователи. Им доступна информация скрытая от обычных сотрудников. Соответственно, и похитить данные им, как правило, проще.

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

Безусловно, наличие прав суперпользователя у администратора оправданно и необходимо для реализации целого блока операций:

  • выполнение бэкапов, выгрузка дампов;
  • работа со статистикой;
  • работа с объектами БД (рекомпиляция, перестройка, анализ ошибок).

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

Как же решить эту проблему? К сожалению, в продуктах Open Source часто отсутствует возможность как ограничения прав суперпользователей, так и в принципе разграничения ролей. Например, в СУБД PostgreSQL для пользователей с опцией SUPERUSER проверки прав и привилегий для конкретных объектов БД (таблицы, представления и пр.) не проводится совсем, что делает невозможным использование штатных механизмов ограничения через выдачу прав на объекты (GRANT\REVOKE). Таким образом, любой пользователь, обладающий ролью с опцией SUPERUSER, автоматически получает доступ ко всем таблицам всех баз данных. Складывается ситуация, когда не собственник бизнеса, а наёмный сотрудник может пользоваться базой данных компании практически без ограничений, а зачастую и без какого-либо контроля и отслеживания его действий. Не самое безопасное решение.

Важно отметить, что далеко не все проприетарные системы управления базами данных способны решить задачу ограничения суперпользователей в правах, но есть и исключения. Например, в отечественной СУБД Jatoba эта функциональность реализована при помощи модуля Jatoba Data Vault (JDV). Модуль обеспечивает внутренний контроль доступа всех пользователей со встроенной ролью SUPERUSER, которая присутствует в большинстве систем управления базами данных, построенных на ядре PostgreSQL. Подробнее о работе PostgreSQL с ролью «суперпользователь» можно узнать здесь.

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

CREATE ROLE name [ [ WITH ] option [ ... ] ]
where option can be:
SUPERUSER | NOSUPERUSER
………

Принцип работы Jatoba Data Vault

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

CREATE EXTENSION IF NOT EXISTS jdv;

Далее в БД будут созданы встроенные роли dv_owner, dv_secanalyst и dv_acctmgr, а также схема jdv со служебной таблицей (jdv_table) и вспомогательными функциями.

 

Рисунок 1. Схема работы Jatoba Data Vault

Схема работы Jatoba Data Vault

 

Роль dv_owner необходима для работы с функциями расширения и модуля JDV.

Роль dv_secanalyst предназначена для мониторинга доступов и предоставляет возможность просматривать jdv.jdv_table (select from jdv.jdv_table). Пользователь dv_owner по умолчанию включён в роль dv_secanalyst и может назначать её другим пользователям.

Роль dv_acctmgr эксклюзивно получает права на CREATE / ALTER / DROP / '\password [username]' для всех ROLE / USER, кроме dv_owner и включенных в неё ролей.

Все роли СУБД, которые имеют атрибут CREATEROLE до момента создания dv_acctmgr (включая SUPERUSER), теряют эту возможность.

При добавлении роли или объекта в политики JDV для них автоматически включается логирование (для схем по умолчанию логирование не задано). Модуль JDV позволяет гибко настраивать логирование. После включения опции JDV для роли dv_owner становятся доступны следующие функции управления списком защищаемых таблиц:

  • добавления в список защищаемых таблиц;
  • удаления из списка защищаемых таблиц;
  • установки разрешения на работу с таблицей;
  • сброса разрешения на работу с таблицей.

Все таблицы, добавленные в список защищаемых, будут дополнительно проверяться на наличие у пользователя прав доступа. Даже если пользователю выдали явные права на работу с таблицей (через grant) без дополнительного разрешения от владельца (db_owner), доступ не будет работать, будет возникать ошибка «ERROR: permission denied for table [tablename]». Такая же ошибка будет возникать для пользователей с ролью SUPERUSER.

Jatoba Data Vault учитывает нюансы архитектурных особенностей ядра СУБД, в частности: ограничение доступа к данным работает в том числе для секционированных (partitioning) таблиц, контролирует выдачу прав через наследование. Дополнительные правила и политики JDV ограничивают доступ к защищаемым данным даже для пользователей с самыми широкими полномочиями.

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

Использование подобных модулей, позволяющих разграничивать права доступа даже для привилегированных пользователей, не только даёт собственникам бизнеса возможность повысить уровень информационной безопасности компании и уменьшить вероятность несанкционированного использования служебной информации, но и обеспечивает соблюдение Приказ №21 от 18.02.2013 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных», мер УПД.5 «Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы» и УПД.4 «Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы».

Подробнее о продукте СУБД Jatoba и его функциональных возможностях можно узнать на сайте компании «Газинформсервис».

Выводы

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

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

Авторы:

Денис Рожков, руководитель разработки компания «Газинформсервис»

Георгий Тарасов, ведущий разработчик группы СУБД компании «Газинформсервис»

Полезные ссылки: 
Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru