Kорона корпоративной безопасности — как защитить данные на уровне баз данных

Пресса снова весь прошлый год шумела по поводу утечек баз данных.


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

Пункт № 1. Понимание настроек IT системы — проверьте конфигурацию


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

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

Также будет верным пользоватся публичной базой с зарегистрированными дырами в программном обеспечении (National Checklist Program Repository).

Пункт № 2. Криптуйте все ваши данные


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

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

Все основные поставщики баз данных предоставляют некоторую форму шифрования базы данных, обычно ссылаясь на эту функцию как что-то вроде прозрачного шифрования данных <Transparent Data Encryption (TDE).

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

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

Шифрование на уровне базы позволяет защитить базу или бэкап файл от Маски-шоу или от кражи методом прямого доступа. В начале 2000-х в налоговую провинции Онтарио (Канада) зашли неустановленные лица, дали по башке охранику — и унесли сервер с собой.

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

Пункт № 3. Используйте SQL брандмауэр базы данных


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

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

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

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

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

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

Пункт № 4. Контролируйте все — проверяйте свою базу данных


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

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

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

Помните, что сетевой монитор вроде может видеть только plain text команды, которые проходят через сеть и не закриптованы через SSL/TLS например.

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

Пункт № 5. Ограничьте зону видимости — установите правила доступа


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

Стремитесь ограничить своих пользователей и администраторов только теми привилегиями, которые необходимы для их бизнес-задач.

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

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

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

Как минимум, вы должны проверять доступ к данным привилегированных пользователей.
Некоторые базы (например MSSQL) не позволяют защитить базу от сисадмина.

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

Или более более дешевый способ — доступ к базе администратору только под присмотром в определенные временные рамки.

Если это ваш внутреннний продукт, то лучший способ сделать это — серверное приложение должно иметь Application Role в базе.

Стороннее приложение не должно иметь доступа к таблицам вообще!
Чтения данных только через View или Function.
Любое изменение данных через процедуру.
View и Function должны иметь только права на чтение таблиц.

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

Ограничения на обьем данных — если оператор обрабатывает 10-20 документов в день — то после 50 должна срабатывать блокировка доступа к базе — это позволяет не допустить сливa всех документов.

Пункт № 6. Маскируйте данные, что может уменьшить риск от последствий атаки


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

Во многих случаях для тестирования и разработки требуются наборы данных, эквивалентные по размеру и сложности производственным, в результате чего многие организации клонируют производственную базу данных для создания этих сред более низкого уровня.
Когда это происходит, риск безопасности, присущий производственной базе данных, внезапно увеличивается, поскольку теперь существует две (или, возможно, ПЯТЬ) копии данных.

Уменьшите риск, маскируя данные — заменив конфиденциальные данные искусственно сгенерированными или зашифрованными данными, которые не раскрывают истинные данные.
Промышленный термин для этого — статическая маскировка данных (static data masking).

Если вы продаете коробочный продукт — скорее всего будете запрашивать копию базы данных у клиентов.

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

Ни в одной государственной организации (названия нeкоторых я даже вслух никому не скажу) никогда не маскировали данные.

Некоторые коммерческие криптовали бэкап, пара (Walmart и какая-то японская секюрити компания прислали только нужную таблицу) и только одна компания прислала отдельные поля в текстовом файле.

То есть проблема на самом деле носит катaстрофический характер.

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

По мотивам статьи: Securing Enterprise Crown Jewels: How to Protect Data at DB Level
Поделиться публикацией

Комментарии 14

    0
    То есть проблема на самом деле носит катaстрофический характер.

    Как же мы жили до сих пор! И еще живем не маскируясь.

      0
      Потому что была моя добрая воля не распространять эти данные и горячее желание жить.:)

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

        А корпоративная безопасность этому мешает?

          0
          Есть же еще и моральные принципы.

          У меня не было желания становится очередным Сноуденом, да и компанию я любил.
      +1
      Неужели вы думаете
        +1
        Элаборируйте плиз.
          0
          Рука соскользнула и отправила незавершенную мысль.

          Все что Вы предлагаете интересно и замечательно, вот только если верить всевозможным блогам и постам про утечки баз данных (персональных данных), то я выделяю 2 крупных канала утечки:
          1. Копирование БД при конфигурировании которой была допущена ошибка (случайная или намеренная), в результате которой БД остается «торчать» наружу в свободном доступе (со стандартными паролями или вообще без них);
          2. Копирование БД самим администратором сервера или ДБА (не суть с какими целями он это делает, интересен канал утечки — через человека у которого есть полные и абсолютные права на сервер БД);

          И в этих 2 случаях мало что помогает, особенно во 2-ом. Можно вбухать миллионы долларов или рублей в средства защиты, но рано или поздно одна «паршивая овца» в стаде все равно сольет все данные или даст доступ чтобы другой человек слил эти данные.

          Самое смешное и оно же печальное — это наказание (штрафы, сроки) за распространение БД с персональными данными — они просто смешные, почитайте про это тут. Поэтому никто не боится «сливать» БД с персональными или иными данными, ведь прибыль превышает убытки от наказания в разы.
            0
            2. Копирование БД самим администратором сервера или ДБА (не суть с какими целями он это делает, интересен канал утечки — через человека у которого есть полные и абсолютные права на сервер БД);

            я слышал про такой вариант защиты от такого сценария в случае с SQL Server — база шифруется с помощью TDE. сертификат с помощью которого выполняется шифрование базы хранится на флешке в сейфе отдела безопасности. если нужно рестартануть сервер — приходит безопасник с флешкой, сервер рестартует, база расшифровывается, безопасник убирает флешку обратно в сейф. (технические подробности я сейчас сказать не смогу, видимо там была связка TDE и EKM)
            даное решение убережет файл и бекапы базы данных от кражи, но все равно оставит возможность экспорта данных пользователю с правами сисадмина в SQL Server. возможность экспорта уже нужно закрывать каким-то сторонним софтом анализирующим аномалии трафика
        0
        Какой то привет из начала двухтысячных, просто перечисление неких шагов… имхо ниочем
          0
          Мне показалось там вполне конкретные рекомендации, которых не было в начале 2000-х:
          прозрачное криптование в MSSQL появилось в 2008-м.

          А советов физически разделять данных на сервера в разных местах редко кто дает.
          +1
          Прямо бальзам на душу — каждой роли сервера по своему админу. Каждому серверу по группе своих админов. Этак никакой безработицы у админов не будет. :)
            0
            В качестве угроз добавлю вирусы сохраняющиеся в базах данных. Крайняя редкость, но бывало. Базы данных достаточно удобны для сохранения данных/кода злоумышленников, так как их часто исключают из проверки (и даже имеются штатные рекомендации, что исключить)
              0
              интересно как происходит запись вируса в файл базы данных и в каком виде просиходит сохранение тела вируса в базу? к примеру тот же SQL Server монопольно удерживает файлы баз данных с которыми он работает, что бы модифицировать файлы извне — нужно остановить службу, и после этого записать тело вируса в файл базы так, что бы в результате база не оказалась поврежденной.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое