Как расшифровать базу данных

Безопасность и СУБД: о чём надо помнить, подбирая средства защиты

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

Статья подготовлена по выступлению на @Databases Meetup, организованном Mail.ru Cloud Solutions. Если не хотите читать, можно посмотреть:

В статье будет три части:

Три составляющих безопасности СУБД: защита подключений, аудит действий и защита данных

Защита подключений

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

Перед тем как говорить о защите соединений, нужно ответить на важные вопросы, от которых зависит, как будут выстраиваться мероприятия безопасности:

Как это повлияет на производительность СУБД?

Посмотрим на примере PostgreSQL, как SSL влияет на нагрузку CPU, увеличение таймингов и уменьшение TPS, не уйдет ли слишком много ресурсов, если его включить.

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

Тест 1 без SSL и с использованием SSL — соединение устанавливается при каждой транзакции:

Тест 2 без SSL и с использованием SSL — все транзакции выполняются в одно соединение:

Остальные настройки:

Результаты тестирования:

При небольших нагрузках влияние SSL сопоставимо с погрешностью измерения. Если объем передаваемых данных очень большой, ситуация может быть другая. Если мы устанавливаем одно соединение на каждую транзакцию (это бывает редко, обычно соединение делят между пользователями), у вас большое количество подключений/отключений, влияние может быть чуть больше. То есть риски снижения производительности могут быть, однако, разница не настолько большая, чтобы не использовать защиту.

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

У нас был кейс, когда мы подключали Zabbix в режиме trust, то есть md5 не проверяли, в аутентификации не было необходимости. Потом заказчик попросил включить режим md5-аутентификации. Это дало большую нагрузку на CPU, производительность просела. Стали искать пути оптимизации. Одно из возможных решений проблемы — реализовать сетевое ограничение, сделать для СУБД отдельные VLAN, добавить настройки, чтобы было понятно, кто и откуда подключается и убрать аутентификацию.Также можно оптимизировать настройки аутентификации, чтобы снизить издержки при включении аутентификации, но в целом применение различных методов аутентификации влияет на производительность и требует учитывать эти факторы при проектировании вычислительных мощностей серверов (железа) для СУБД.

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

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

Аудит может быть не только СУБД. Аудит — это получение информации о том, что происходит на разных сегментах. Это может быть и database firewall, и операционная система, на которой строится СУБД.

В коммерческих СУБД уровня Enterprise с аудитом все хорошо, в open source — не всегда. Вот, что есть в PostgreSQL:

«Базовая регистрация операторов может быть обеспечена стандартным средством ведения журнала с log_statement = all.

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

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

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

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

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

Это может показаться простой задачей для базового аудита и grep, но что, если вам представится что-то вроде этого (намеренно запутанного) примера:

Стандартное ведение журнала даст вам это:

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

Это не идеально, так как было бы предпочтительнее просто искать по имени таблицы.

Вот где будет полезен pgAudit.

Для того же самого ввода он выдаст этот вывод в журнале:

Регистрируется не только блок DO, но и полный текст CREATE TABLE с типом оператора, типом объекта и полным именем, что облегчает поиск.

При ведении журнала операторов SELECT и DML pgAudit можно настроить для регистрации отдельной записи для каждого отношения, на которое есть ссылка в операторе.

Не требуется синтаксический анализ, чтобы найти все операторы, которые касаются конкретной таблицы(*)».

Как это повлияет на производительность СУБД?

Давайте проведем тесты с включением полного аудита и посмотрим, что будет с производительностью PostgreSQL. Включим максимальное логирование БД по всем параметрам.

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

На СУБД PostgreSQL с параметрами 1 CPU, 2,8 ГГц, 2 Гб ОЗУ, 40 Гб HDD проводим три нагрузочных теста, используя команды:

Результаты тестирования:

В итоге: полный аудит — это не очень хорошо. Данных от аудита получится по объему, как данных в самой базе данных, а то и больше. Такой объем журналирования, который генерится при работе с СУБД, — обычная проблема на продуктиве.

Смотрим другие параметры:

В корпорациях с аудитом еще сложнее:

Ограничение доступа к данным

Посмотрим на технологии, которые используют для защиты данных и доступа к ним в коммерческих СУБД и open source.

Что в целом можно использовать:

Как это влияет на производительность СУБД?

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

Проведем тест c pgcrypto. Создадим таблицу с зашифрованными данными и с обычными данными. Ниже команды для создания таблиц, в самой первой строке полезная команда — создание самого extension с регистрацией СУБД:

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

Выборка из таблицы без функции шифрования:

id | text1 | text2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
…
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 строк)

Выборка из таблицы с функцией шифрования:

id | decrypt | decrypt
——+—————+————
1 | \x31 | \x31
2 | \x32 | \x32
3 | \x33 | \x33
…
999 | \x393939 | \x393939
1000 | \x31303030 | \x31303030
(1000 строк)

Результаты тестирования:

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

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

Когда на всю колонку для всех пользователей один ключ (даже если не для всех, а для клиентов ограниченного набора), — это не всегда хорошо и правильно. Именно поэтому начали делать end-to-end шифрование, в СУБД стали рассматривать варианты шифрования данных со стороны клиента и сервера, появились те самые key-vault хранилища — отдельные продукты, которые обеспечивают управление ключами на стороне СУБД.

Средства безопасности в коммерческих и open source СУБД

Таблица далеко не полная, но ситуация такая: в коммерческих продуктах задачи безопасности решаются давно, в open source, как правило, для безопасности используют какие-то надстройки, многих функций не хватает, иногда приходится что-то дописывать. Например, парольные политики — в PostgreSQL много разных расширений (1, 2, 3, 4, 5), которые реализуют парольные политики, но все потребности отечественного корпоративного сегмента, на мой взгляд, ни одно не покрывает.

Что делать, если нигде нет того, что нужно? Например, хочется использовать определенную СУБД, в которой нет функций, которые требует заказчик.

Тогда можно использовать сторонние решения, которые работают с разными СУБД, например, «Крипто БД» или «Гарда БД». Если речь о решениях из отечественного сегмента, то там про ГОСТы знают лучше, чем в open source.

Второй вариант — самостоятельно написать, что нужно, реализовать на уровне процедур доступ к данным и шифрование в приложении. Правда, с ГОСТом будет сложнее. Но в целом — вы можете скрыть данные, как нужно, сложить в СУБД, потом достать и расшифровать как надо, прямо на уровне application. При этом сразу думайте, как вы будете эти алгоритмы на application защищать. На наш взгляд, это нужно делать на уровне СУБД, потому что так будет работать быстрее.

Источник

СОДЕРЖАНИЕ

Прозрачное / внешнее шифрование базы данных

Прозрачное шифрование данных (часто сокращенно TDE) используется для шифрования всей базы данных, что, следовательно, включает шифрование « данных в состоянии покоя ». Неактивные данные обычно можно определить как «неактивные» данные, которые в настоящее время не редактируются или не передаются по сети. Например, текстовый файл, хранящийся на компьютере, находится в состоянии покоя до тех пор, пока он не будет открыт и отредактирован. Неактивные данные хранятся на физических носителях, таких как ленты или жесткие диски. Хранение больших объемов конфиденциальных данных на физических носителях, естественно, вызывает опасения по поводу безопасности и кражи. TDE гарантирует, что данные на физических носителях не могут быть прочитаны злоумышленниками, которые могут иметь намерение украсть их. Данные, которые не могут быть прочитаны, бесполезны, что снижает стимул для кражи. Возможно, наиболее важным преимуществом TDE является его прозрачность. Учитывая, что TDE шифрует все данные, можно сказать, что никакие приложения не нужно изменять для правильной работы TDE. Важно отметить, что TDE шифрует всю базу данных, а также ее резервные копии. Прозрачный элемент TDE связан с тем фактом, что TDE шифрует «на уровне страницы», что по сути означает, что данные шифруются при хранении и дешифруются при вызове в системную память. Содержимое базы данных шифруется с использованием симметричного ключа, который часто называют «ключом шифрования базы данных».

Шифрование на уровне столбца

Шифрование на уровне поля

Шифрование на уровне файловой системы

Шифрованная файловая система (EFS)

Важно отметить, что традиционные методы шифрования базы данных обычно шифруют и дешифруют содержимое базы данных. Базы данных управляются «системами управления базами данных» (СУБД), которые работают поверх существующей операционной системы (ОС). Это создает потенциальную угрозу безопасности, поскольку зашифрованная база данных может работать в доступной и потенциально уязвимой операционной системе. EFS может шифровать данные, которые не являются частью системы базы данных, что означает, что объем шифрования для EFS намного шире по сравнению с такой системой, как TDE, которая способна только шифровать файлы базы данных. Хотя EFS расширяет объем шифрования, он также снижает производительность базы данных и может вызвать проблемы с администрированием, поскольку системным администраторам требуется доступ к операционной системе для использования EFS. Из-за проблем, связанных с производительностью, EFS обычно не используется в приложениях для создания базы данных, которые требуют частого ввода и вывода базы данных. Чтобы компенсировать проблемы с производительностью, часто рекомендуется использовать системы EFS в средах с небольшим количеством пользователей.

Полное шифрование диска

BitLocker не имеет тех проблем с производительностью, которые связаны с EFS.

Симметричное и асимметричное шифрование базы данных

Симметричное шифрование базы данных

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

Асимметричное шифрование базы данных

Ключевой менеджмент

В разделе «Симметричное и асимметричное шифрование базы данных» представлена ​​концепция открытых и закрытых ключей с базовыми примерами, в которых пользователи обмениваются ключами. Акт обмена ключами становится непрактичным с точки зрения логистики, когда множеству разных людей необходимо общаться друг с другом. При шифровании базы данных система обрабатывает хранение и обмен ключами. Этот процесс называется управлением ключами. Если ключи шифрования не управляются и не хранятся должным образом, может произойти утечка очень конфиденциальных данных. Кроме того, если система управления ключами удаляет или теряет ключ, информация, которая была зашифрована с помощью указанного ключа, по существу также оказывается «потерянной». Сложность логистики управления ключами также является темой, которую необходимо учитывать. По мере увеличения количества приложений, используемых фирмой, также увеличивается количество ключей, которые необходимо хранить и управлять ими. Таким образом, необходимо установить способ управления ключами от всех приложений через один канал, который также известен как корпоративное управление ключами. Решения для управления корпоративными ключами продаются множеством поставщиков в технологической отрасли. Эти системы по сути представляют собой централизованное решение для управления ключами, которое позволяет администраторам управлять всеми ключами в системе через один концентратор. Таким образом, можно сказать, что внедрение корпоративных решений для управления ключами может снизить риски, связанные с управлением ключами в контексте шифрования базы данных, а также уменьшить логистические проблемы, которые возникают, когда многие люди пытаются вручную поделиться ключами.

Хеширование

Хеширование используется в системах баз данных как метод защиты конфиденциальных данных, таких как пароли; однако он также используется для повышения эффективности обращения к базе данных. Введенные данные обрабатываются алгоритмом хеширования. Алгоритм хеширования преобразует введенные данные в строку фиксированной длины, которая затем может быть сохранена в базе данных. У систем хеширования есть две критически важные характеристики, которые будут описаны ниже. Во-первых, хэши «уникальны и повторяемы». Например, многократное выполнение слова «кошка» через один и тот же алгоритм хеширования всегда будет давать один и тот же хеш, однако очень сложно найти слово, которое вернет тот же хеш, что и «кошка». Во-вторых, алгоритмы хеширования необратимы. Чтобы связать это с приведенным выше примером, было бы почти невозможно преобразовать вывод алгоритма хеширования обратно в исходный ввод, которым был «кот». В контексте шифрования базы данных хеширование часто используется в системах паролей. Когда пользователь впервые создает свой пароль, он проходит через алгоритм хеширования и сохраняется в виде хеша. Когда пользователь снова входит на веб-сайт, введенный им пароль проходит через алгоритм хеширования и затем сравнивается с сохраненным хешем. Учитывая тот факт, что хеши уникальны, если оба хеша совпадают, считается, что пользователь ввел правильный пароль. Одним из примеров популярной хеш-функции является SHA (Secure Hash Algorithm) 256.

Соление

Перец

Шифрование на уровне приложений

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

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

Преимущества шифрования на уровне приложений

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

Недостатки шифрования на уровне приложений

Первым важным недостатком шифрования на уровне приложений является то, что приложения, используемые фирмой, необходимо будет модифицировать для шифрования самих данных. Это может потребовать значительного количества времени и других ресурсов. Учитывая характер альтернативных издержек, фирмы могут не поверить в то, что шифрование на уровне приложений стоит вложенных средств. Кроме того, шифрование на уровне приложения может ограничивать производительность базы данных. Если все данные в базе данных зашифрованы множеством различных приложений, становится невозможным индексирование или поиск данных в базе данных. Обосновать это на самом деле в виде базового примера: было бы невозможно построить глоссарий на одном языке для книги, написанной на 30 языках. Наконец, сложность управления ключами возрастает, поскольку несколько разных приложений должны иметь полномочия и доступ для шифрования данных и записи их в базу данных.

Риски шифрования базы данных

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

Источник