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


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

Пункт № 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