Mysql шифрование данных: использование Master Key / Хабр

Содержание

использование Master Key / Хабр

В преддверии старта нового набора на курс «Базы данных» продолжаем публиковать серию статей про шифрование в MySQL.

В предыдущей статье этой серии (Шифрование в MySQL: хранилище ключей) мы говорили о хранилищах ключей. В этой статье мы рассмотрим, как используется главный ключ (master key), а также обсудим достоинства и недостатки шифрования методом конвертов (envelope encryption).

Идея шифрования конвертов заключается в том, что используемые для шифрования ключи (ключи табличных пространств) шифруются другим ключом (главным ключом, master key). Для шифрования данных фактически используются ключи табличных пространств. Графически это можно представить так:

Главный ключ (master key) находится в хранилище ключей (keyring), а ключи табличных пространств — в заголовках зашифрованных табличных пространств (на странице 0 табличного пространства).

На рисунке выше:

Таблица A зашифрована ключом 1 (Key 1). Ключ 1 шифруется с помощью главного ключа (master key) и хранится в зашифрованном виде в заголовке таблицы A.
Таблица B зашифрована ключом 2 (Key 2). Ключ 2 шифруется с помощью главного ключа (masker key) и хранится в зашифрованном виде в заголовке таблицы B.
И так далее.

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

InnoDB

В InnoDB фактическое шифрование и дешифрование выполняются на уровне ввода-вывода. То есть страница шифруется непосредственно перед тем, как она сбрасывается на диск и расшифровывается сразу после считывания с диска.

В InnoDB шифрование работает только на уровне табличных пространств. И по умолчанию все таблицы создаются в отдельных табличных пространствах (file-per-table tablespace). Говоря иными словами, создается табличное пространство, которое может содержать только одну таблицу. Хотя вы можете создавать таблицы также и в основном табличном пространстве (general tablespace). Но в любом случае таблица всегда находится в каком-то табличном пространстве. И поскольку шифрование осуществляется на уровне табличного пространства, то оно либо полностью зашифровано, либо нет. То есть нельзя в основном табличном пространстве зашифровать только часть таблиц.

Если по какой-либо причине у вас отключен file-per-table, то все таблицы создаются внутри системного табличного пространства (system tablespace). В Percona Server for MySQL можно зашифровать системное табличное пространство с помощью переменной innodbsystablespaceencrypt или используя потоки шифрования (encryption threads), но это все еще экспериментальная функция. В MySQL этого нет.

Прежде чем двигаться дальше, нам нужно рассмотреть структуру идентификатора главного ключа (master key ID). Он состоит из UUID, KEYID и префикса «INNODBKey». Выглядит это так: INNODBKey-UUID-KEYID.

UUID — это uuid сервера с зашифрованным табличным пространством. KEYID — это просто постоянно увеличивающееся значение. При первичном создании главного ключа KEYID равен 1. При ротации ключа, когда создается новый главный ключ, KEYID = 2 и так далее. Более подробно о ротации главных ключей мы поговорим в следующих статьях этой серии.

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

KEY ID — это KEYID из идентификатора главного ключа, который мы уже обсуждали. UUID — это uuid сервера, который также используется в идентификаторе главного ключа. TABLESPACE KEY — ключ табличного пространства, который состоит из 256 бит, случайно сгенерированных сервером. Вектор инициализации (IV, initialization vector) также состоит из 256 случайно сгенерированных битов (хотя должен быть 128 бит). IV используется для инициализации шифрования и дешифрования AES (из 256 бит используется только 128). В конце присутствует контрольная сумма CRC32 для TABLESPACE KEY и IV.

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

Зачем нужен CRC32?

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

Вы можете спросить: в какой момент осуществляется проверка ключей? Ответ — при запуске сервера. Сервер с зашифрованными таблицами / табличными пространствами при старте считывает UUID, KEYID из заголовка и генерирует идентификатор главного ключа. Затем он получает необходимый главный ключ из хранилища (keyring), расшифровывает ключ табличного пространства и проверяет контрольную сумму. Еще раз, если контрольная сумма совпадает, то все в порядке, нет — табличное пространство помечается как отсутствующее.

Если вы читали прошлую статью этой серии (Шифрование в MySQL: хранилище ключей), то, возможно, помните, что при использовании серверного хранилища ключей, сервер при запуске получает только список идентификаторов ключей, а точнее, key id и user id, так как эта пара однозначно идентифицирует ключ. А теперь я говорю, что сервер при запуске получает все ключи, необходимые ему для проверки возможности расшифровки ключей табличных пространств. Так почему же при инициализации, в случае серверного хранилища, загружаются только keyid и userid, а не все ключи? Потому что вам могут быть не нужны все ключи. В основном это связано с ротацией главного ключа. При ротации главного ключа в хранилище создается новый главный ключ, но старые ключи не удаляются. Таким образом, в серверном хранилище ключей у вас может находиться много ключей, которые не нужны серверу и, следовательно, не извлекаются при запуске сервера.

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

Однако шифрование с помощью главного ключа имеет один большой недостаток: после того как табличное пространство зашифровано с помощью tablespace_key, оно всегда остается зашифрованным одним и тем же ключом. Ротация главного ключа здесь не помогает. Почему это недостаток? Мы знаем, что в MySQL есть баги, которые могут привести к внезапному сбою и созданию core-файла. Так как core-файл содержит дамп памяти сервера, может случиться так, что в дампе будет расшифрованный ключ табличного пространства. Что еще хуже, дешифрованные ключи табличного пространства хранятся в памяти, которая может свопиться на диск. Вы можете сказать, что это не недостаток, так как вам нужны root-права для доступа к этим файлам и разделу подкачки. Да. Но root нужен только на некоторое время. Как только кто-то получит доступ к дешифрованному ключу табличного пространства, он / она сможет продолжить использовать его для расшифровки данных, даже без прав root. Кроме того, диск может быть украден, а раздел подкачки / core-файлы можно прочитать с помощью сторонних средств. Цель TDE состоит в том, сделать его нечитаемым, даже если диск будет украден. В Percona Server for MySQL есть возможность повторного шифрования табличного пространства с новыми сгенерированными ключами. Эта функция называется потоками шифрования (encryption threads) и на момент написания этой статьи все еще является экспериментальной.

Узнать подробнее о курсе

Читать ещё:

Шифрование в MySQL: хранилище ключей

Шифрование данных с помощью управляемого клиентом ключа — База данных Azure для MySQL

Статья
02/12/2023
Чтение занимает 9 мин

Область применения: база данных Azure для MySQL — отдельный сервер

Важно!

База данных Azure для MySQL — отдельный сервер находится на пути прекращения поддержки. Мы настоятельно рекомендуем выполнить обновление до База данных Azure для MySQL — гибкий сервер. Дополнительные сведения о миграции на База данных Azure для MySQL — гибкий сервер см. в статье Что происходит с База данных Azure для MySQL отдельным сервером?

Шифрование данных с помощью управляемых пользователем ключей для Базы данных Azure для MySQL позволяет создавать собственный ключ (BYOK) для защиты неактивных данных. Он также позволяет организациям реализовать разделение обязанностей в управлении ключами и данными. При шифровании, управляемом клиентом, вы полностью отвечаете за управление жизненным циклом ключа, разрешения на использование ключа и аудит операций с ключами.

Шифрование данных с помощью управляемых клиентом ключей для Базы данных Azure для MySQL задано на уровне сервера. На определенном сервере шифрование ключа шифрования данных (DEK), используемого службой, выполняется с помощью управляемого клиентом ключа, называемого ключом шифрования ключей (KEK). KEK — это асимметричный ключ, хранящийся в принадлежащем клиенту и управляемом им экземпляре Azure Key Vault.

Подробное описание ключа шифрования ключей (KEK) и ключа шифрования данных (DEK) приводится далее в этой статье.

Key Vault — это облачная внешняя система управления ключами. Она обладает высокой доступностью и является масштабируемым надежным хранилищем для криптографических ключей RSA, которое при необходимости поддерживается проверенными аппаратными модулями безопасности (HSM) FIPS 140-2 уровня 2. Эта система запрещает прямой доступ к хранимому ключу, но предоставляет авторизованным сущностям службы шифрования и расшифровки. Key Vault может создать ключ, импортировать его или передать с локального устройства HSM.

Примечание

Эта функция поддерживается только в хранилище общего назначения версии 2 (поддержка до 16 ТБ), доступном для ценовых категорий «Общее назначение» и «Оптимизированные для операций в памяти». Дополнительные сведения см. в статье Основные понятия службы хранилища. Другие ограничения описаны в этом разделе.

Преимущества

Шифрование данных с помощью управляемых клиентом ключей для Базы данных Azure для MySQL обеспечивает следующие преимущества:

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

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

Терминология и описание

Ключ шифрования данных (DEK) : симметричный ключ AES256 для шифрования раздела или блока данных. Шифрование каждого блока данных другим ключом создает дополнительные сложности для выполнения атак в отношении зашифрованных данных. Доступ к DEK требуется поставщику ресурсов или экземпляру приложения, выполняющему шифрование или расшифровку определенного блока. Когда DEK заменяется новым ключом, повторного шифрования этим ключом требуют только данные в его связанном блоке.

Ключ шифрования ключей (KEK) : ключ шифрования, используемый для шифрования ключей DEK. Ключ KEK, который всегда остается в Key Vault, позволяет шифровать и контролировать сами ключи DEK. Сущность, у которой есть доступ к ключу KEK, может отличаться от сущности, требующей ключа DEK. Так как KEK требуется для расшифровки ключей DEK, его можно фактически рассматривать как единую точку, с помощью которой можно удалить ключи DEK (непосредственно удалив KEK).

Ключи DEK, зашифрованные с помощью ключей KEK, хранятся отдельно. Расшифровать ключи DEK может только сущность с доступом к ключу KEK. Дополнительные сведения см. в статье Шифрование неактивных данных.

Шифрование данных с помощью управляемого клиентом ключа

Чтобы сервер MySQL мог использовать управляемые клиентом и хранящиеся в Key Vault ключи для шифрования ключа DEK, администратор Key Vault предоставляет следующие права доступа.

get. Для получения общедоступной части и свойств ключа в хранилище ключей.
wrapKey . Для шифрования ключа DEK. Зашифрованный ключ DEK хранится в Базе данных Azure для MySQL.
unwrapKey. Для расшифровки ключа DEK. Службе «База данных Azure для MySQL» требуются расшифрованные ключи DEK для шифрования и расшифровки данных.

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

Если сервер настроен для использования управляемого клиентом ключа, хранящегося в хранилище ключей, он отправляет ключ DEK в хранилище ключей для шифрования. Key Vault возвращает зашифрованный ключ DEK, который сохраняется в базе данных пользователя. Аналогично при необходимости сервер отправляет защищенный ключ DEK в хранилище ключей для расшифровки. Если включено ведение журнала, аудиторы могут использовать Azure Monitor для просмотра журналов событий аудита Key Vault.

Требования к настройке шифрования данных для Базы данных Azure для MySQL

Ниже приведены требования к настройке Key Vault.

Key Vault и База данных Azure для MySQL должны принадлежать одному клиенту Azure Active Directory (Azure AD). Взаимодействие между Key Vault и сервером, размещенными в разных клиентах, не поддерживается. При последующем перемещении ресурса Key Vault требуется перенастроить шифрование данных.
В хранилище ключей следует включить функцию обратимого удаления с периодом хранения 90 дней, чтобы избежать потери данных в случае непреднамеренного удаления ключа (или Key Vault). Ресурсы с обратимым удалением по умолчанию хранятся в течение 90 дней, если срок хранения установлен меньше или равным 90 дней.

С действиями «Восстановить» и «Удалить» связаны отдельные разрешения в политике доступа хранилища ключей. Функция обратимого удаления отключена по умолчанию, но ее можно включить с помощью PowerShell или Azure CLI (обратите внимание, что ее нельзя включить на портале Azure).
Включите функцию защиты от очистки в хранилище ключей, задав период хранения в 90 дней. Защиту от очистки можно включить только после включения обратимого удаления. Ее можно включить с помощью Azure CLI или PowerShell. Если защита от очистки включена, хранилище или объект в удаленном состоянии нельзя удалить безвозвратно, пока не истечет период хранения. Безопасно удаленные хранилища и объекты по-прежнему можно восстановить с гарантированным соблюдением политики хранения.

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

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

Управляемый клиентом ключ, используемый для шифрования ключа DEK, может быть только асимметричным 2048-битным ключом RSA.
Дата активации ключа (если задана) должна быть датой и временем в прошлом. Дата окончания срока действия не задана.
Ключ должен находиться в состоянии Включено.
Для ключа должно быть настроено обратимое удаление с периодом хранения в 90 дней. Это неявно задает для ключевого атрибута recoveryLevel необходимое значение «Recoverable». Если задан период хранения < 90 дней, для ключевого атрибута recoveryLevel устанавливается значение CustomizedRecoverable, которое не соответствует требованиям. Поэтому убедитесь в том, что задан период хранения 90 дней.
Для ключа должна быть включена защита от очистки.
Если вы импортируете существующий ключ в хранилище ключей, обязательно укажите его в поддерживаемом формате файла (.pfx, .byok, .backup).

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

Установите блокировку ресурсов в Key Vault, чтобы управлять правами на удаление этого критически важного ресурса и предотвратить случайное или несанкционированное удаление.

Включите функции аудита и отчетности для всех ключей шифрования. Key Vault предоставляет журналы, которые можно легко передать в любые средства управления информационной безопасностью и событиями безопасности. Например, они уже интегрированы в службу Azure Monitor Log Analytics.
Убедитесь, что Key Vault и База данных Azure для MySQL находятся в одном регионе, чтобы обеспечить быстрый доступ к операциям упаковки или распаковки ключа DEK.
Сделайте Azure KeyVault доступным только для частной конечной точки и ряда определенных сетей и используйте для защиты ресурсов только доверенные службы Майкрософт.

Ниже приведены рекомендации по настройке ключа, управляемого клиентом.

Храните копию управляемого клиентом ключа в надежном месте или передайте ее в службу депонирования.
Если ключ создается в Key Vault, создайте резервную копию ключа перед его первым использованием. Резервную копию можно восстановить только в Key Vault. Дополнительные сведения о команде резервного копирования см. в статье Backup-AzKeyVaultKey.

Условие отсутствия доступа к ключу, управляемому клиентом

Когда шифрование данных в Key Vault настраивается с помощью ключа, управляемого клиентом, то, чтобы сервер оставался в режиме «в сети», ему требуется постоянный доступ к этому ключу. Если сервер теряет доступ к управляемому клиентом ключу в Key Vault, он начинает отклонять все подключения в течение 10 минут. Сервер выдает соответствующее сообщение об ошибке, и его состояние изменяется на

Недоступен. Ниже приведены некоторые причины перехода сервера в это состояние.

Если для Базы данных Azure для MySQL с включенным шифрованием данных создается сервер восстановления на определенный момент времени, этот новый сервер будет находиться в состоянии Недоступен. Это можно исправить на портале Azure или с помощью интерфейса командной строки.
Если для Базы данных Azure для MySQL с включенным шифрованием данных создается реплика чтения, сервер реплики будет находиться в состоянии Недоступен. Это можно исправить на портале Azure или с помощью интерфейса командной строки.
При удалении KeyVault База данных Azure для MySQL не сможет получать доступ к ключу и перейдет в состояние Недоступен. Чтобы перевести сервер в состояние Доступен, следует восстановить Key Vault и повторно проверить шифрование данных.
При удалении ключа из KeyVault База данных Azure для MySQL не сможет получать доступ к ключу и перейдет в состояние Недоступен. Чтобы перевести сервер в состояние Доступен, следует восстановить ключ и повторно проверить шифрование данных.
Если срок действия ключа, хранящегося в Azure KeyVault, истечет, ключ станет недействительным, а База данных Azure для MySQL перейдет в состояние Недоступен. Чтобы перевести сервер в состояние Доступен, продлите срок действия ключа с помощью интерфейса командной строки, а затем повторно проверьте шифрование данных.

Непреднамеренный отзыв доступа к ключу из Key Vault

Может случиться так, что пользователь с достаточными правами доступа к Key Vault случайно отключает доступ сервера к ключу в результате выполнения следующих действий:

отзыв с сервера разрешений get, wrapKey и unwrapKey для хранилища ключей;
удаление ключа;
удаление хранилища ключей;
изменение правил брандмауэра хранилища ключей;
удаление управляемого удостоверения сервера в Azure AD.

Мониторинг управляемого клиентом ключа в Key Vault

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

Работоспособность ресурсов Azure. Недоступная база данных, которая потеряла доступ к ключу клиента, отображается как недоступная после отклонения первого подключения к базе данных.
Журнал действий. В случае сбоя доступа к ключу клиента в управляемом клиентом Key Vault в журнал действий добавляются записи. Если для таких событий создать правила генерации оповещений, можно восстанавливать доступ максимально быстро.
Группы действий. Определите эти группы для отправки уведомлений и оповещений в соответствии с вашими предпочтениями.

Восстановление и репликация с помощью управляемого клиентом ключа в Key Vault

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

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

Запустите процесс восстановления или создания реплики чтения в исходной Базе данных Azure для MySQL.
Оставьте созданный сервер (восстановленный сервер или сервер-реплику) в недоступном состоянии, так как его уникальному удостоверению еще не предоставлены разрешения для Key Vault.
На восстановленном сервере или сервере-реплике повторно проверьте ключ, управляемый клиентом, в параметрах шифрования данных, чтобы созданному серверу были предоставлены разрешения на упаковку и распаковку ключа, хранящегося в Key Vault.

Ограничения

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

Поддержка этой функции ограничена ценовыми категориями Общего назначения и Оптимизированная для операций в памяти.
Эта функция доступна только для регионов и серверов, поддерживающих хранилище общего назначения версии 2 (до 16 ТБ). Список регионов Azure, поддерживающих хранилище объемом до 16 ТБ, см. в документации в разделе о хранилищах.
Примечание
- Для всех новых серверов MySQL, созданных в регионах Azure, поддерживающих хранилище общего назначения версии 2, доступно шифрование данных с использованием ключей, управляемых клиентом. Сервер, восстановленный до точки во времени (PITR), или реплика чтения не считаются новыми, хотя теоретически они таковыми являются.
- Чтобы проверить, поддерживает ли подготовленный сервер хранилище общего назначения версии 2, перейдите в колонку ценовой категории на портале и посмотрите на максимальный размер хранилища, поддерживаемый подготовленным сервером. Если ползунок можно переместить максимум до 4 ТБ, сервер включен в хранилище общего назначения версии 1 и не будет поддерживать шифрование с использованием ключей, управляемых клиентом. Тем не менее данные все время шифруются с помощью управляемых службой ключей. Если у вас возникнут вопросы или вам понадобится помощь, напишите по адресу [email protected].
Шифрование поддерживается только с использованием криптографического ключа RSA 2048.

Дальнейшие действия

Узнайте, как настроить шифрование данных с помощью управляемого клиентом ключа для Базы данных Azure для MySQL с помощью портала Azure и Azure CLI.
Узнайте о поддержке типа хранилища для Базы данных Azure для MySQL с отдельным сервером.

шифрование MySQL | Как работает шифрование в MySQL на примерах?

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

Как правило, когда любой пользователь просматривает данные в базе данных, данные, основанные на типе столбца таблицы, будут доступны для чтения в текстовом виде. Некоторые из классически используемых категорий полей для столбцов в таблице базы данных, такие как VARCHAR, INT, TEXT и DATETIME, представлены в удобочитаемой форме, за исключением больших двоичных объектов и некоторых других категорий полей.

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

Синтаксис

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

Кроме того, MySQL Enterprise Encryption предоставляет администраторам баз данных, а также разработчикам технические инструменты, необходимые им для перечисленных ниже:

Асимметричное шифрование с открытым ключом
Расшифровка асимметричного открытого ключа
Генерация открытого/закрытого ключа
Предоставление симметричных ключей из пар открытого и закрытого ключей
Цифровая подпись данных
Проверка подписи данных
Проверка подлинности данных

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

MySQL Enterprise Encryption позволяет вашему предприятию выполнять следующие действия:

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

MySQL Enterprise TDE (Transparent Data Encryption) обеспечивает безопасность опасных данных пользователя, поддерживая шифрование данных в состоянии покоя в базе данных сервера. Он защищает конфиденциальность пользовательской информации, предотвращает утечку данных и помогает удовлетворить потребности контроля, включая:

Стандарт безопасности данных индустрии платежных карт (PCI) (DSS)
Закон о переносимости и подотчетности медицинского страхования (HIPAA)
Общее положение о защите данных
Закон штата Калифорния о защите прав потребителей и т. д.

Как работает шифрование в MySQL?

Таблицы InnoDB в MySQL поддерживают шифрование данных в состоянии покоя для общих табличных пространств, журналов повторного выполнения табличных пространств файлов на таблицу, журналов отмены и системного табличного пространства mysql. В MySQL 8.0.16, чтобы настроить шифрование по умолчанию для схем СУБД и аналогичным образом, также поддерживаются общие табличные пространства, которые позволяют администраторам баз данных отслеживать, закодированы ли таблицы, созданные в этих схемах и связанных табличных пространствах.

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

Свойство шифрования данных в состоянии покоя зависит от подключаемого модуля набора ключей для управления главным ключом шифрования. Этот подключаемый модуль файла набора ключей предоставляется для всех выпусков MySQL, в которых данные набора ключей хранятся в файле, локальном для хоста сервера. MySQL Enterprise Edition предоставляет дополнительный подключаемый модуль набора ключей:

Keyring_encrypted_file хранит данные набора ключей в зашифрованном файле, локальном для узла сервера.
Keyring_okv содержит клиент KMIP, т. е. KMIP 1.1, который реализует KMIP-совместимый продукт для хранения ключей, который работает как серверная часть. Поддерживаемые продукты, совместимые с KMIP, состоят из решений для централизованной организации ключей, таких как Oracle key Vault, Thales Vormetric key management, Gemalto KeySecure, а также Fornetix key Orchestration.
Keyring_aws подключается к службе управления ключами (KMS) Amazon Web Services (AWS) для генерации ключей в качестве серверной части, а для хранения ключей применяет локальный файл.
Keyring_hashicorp соединяется с хранилищем HashiCorp для хранения серверной части.

Примеры

В MySQL 8.0.16 переменная с именем default_table_encryption регулирует шифрование немедленно сгенерированного табличного пространства, за исключением предложения ENCRYPTION, которое открыто указывается в операторе CREATE TABLESPACE. В предыдущей версии MySQL 8.0.16 пункт ENCRYPTION должен быть указан, чтобы разрешить шифрование, как написано ниже:

СОЗДАТЬ ТАБЛИЧНОЕ ПРОСТРАНСТВО ‘tbs1’ ДОБАВИТЬ ФАЙЛ ДАННЫХ ‘tbs.ibd’ ШИФРОВАНИЕ = ‘Y’ ENGINE=InnoDB;

Для изменения шифрования текущего общего табличного пространства необходимо указать предложение ENCRYPTION:

ALTER TABLESPACE tbs ENCRYPTION = ‘Y’;

Для шифрования системного табличного пространства mysql MySQL 8. 0.16 также поддерживает его. Это системное табличное пространство mysql содержит системную базу данных mysql вместе с таблицами словаря данных MySQL, и по умолчанию оно не зашифровано. Таким образом, для включения шифрования нам необходимо определить имя табличного пространства, а также параметр ENCRYPTION в операторе ALTER TABLESPACE, как показано ниже:0003

ALTER TABLESPACE mysql ENCRYPTION = ‘Y’;

Кроме того, для ограничения шифрования для этого системного табличного пространства mysql нам необходимо установить ENCRYPTION = ‘N’, применив оператор запроса ALTER TABLESPACE:

ALTER TABLESPACE mysql ENCRYPTION = ‘N’;

Помните, что для разрешения или ограничения шифрования для системы mysql табличному пространству необходимы привилегии CREATE TABLESPACE для всех таблиц в базе данных, показанных в экземпляре, то есть CREATE TABLESPACE для *.* в MySQL.

Всякий раз, когда опция ENCRYPTION указана в запросе CREATE TABLE или ALTER TABLE, она задокументирована в столбце таблицы CREATE_OPTIONS INFORMATION_SCHEMA. TABLES. Мы можем проверить столбец, чтобы проверить таблицы, которые остаются в зашифрованном табличном пространстве файлов на таблицу:

SELECT TABLESCHEMA, TABLENAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE CREATE _OPTIONS LIKE ‘%ENCRYPTION’;

Заключение

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

Шифрование данных MySQL в состоянии покоя

В этом сообщении блога обсуждаются проблемы и решения для шифрования данных в состоянии покоя MySQL. Также есть обновление от моей коллеги Кери Уильямс — вы можете ознакомиться с ним здесь.

Данные в состоянии покоя Шифрование — это не только полезная функция, но и требование HIPAA, PCI и других норм.

Существует три основных способа шифрования данных в состоянии покоя:

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

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

Сергей Голубчик, главный архитектор MariaDB, обозначил плюсы и минусы шифрования на уровне базы данных во время своего выступления на Percona Live Amsterdam:

Плюсы шифрования на уровне базы данных

Доступна полная мощность СУБД
Доступна полная мощность СУБДПрост в реализации
Простота реализации — только база данных может видеть данные
Только базы данных могут видеть данные — шифрование для каждой таблицы, ключи для каждой таблицы, производительность
Шифрование для каждой таблицы, ключи для каждой таблицы, производительность 90 020

Минусы шифрования на уровне базы данных

Невозможно выполнить для каждого пользователя
Не защищает от злонамеренного пользователя root

Шифрование данных в состоянии покоя: параметры на уровне базы данных

В настоящее время существует два варианта шифрования данных в состоянии покоя на уровне базы данных:

Поддержка шифрования MariaDB 10. 1.3+ (с использованием исправления Google)
MySQL 5.7.11+ (и Percona Server 5.7.11) имеет шифрование на уровне табличного пространства InnoDB

Реализация MariaDB отличается от MySQL 5.7.11. MySQL 5.7.11 шифрует только табличные пространства InnoDB, в то время как у MariaDB есть возможность шифровать журналы отмены/повторения, двоичные журналы/журналы ретрансляции и т. д. Однако существуют некоторые ограничения (особенно вместе с Galera Cluster):

Нет ротация ключей в версии плагина с открытым исходным кодом (в MySQL 5.7.11 есть ротация ключей)
mysqlbinlog не работает с зашифрованными двоичными журналами (сообщается об ошибке)
Percona XtraBackup не работает, поэтому мы ограничены RSYNC в качестве метода SST для кластера Galera, который является методом блокировки (один узел не будет доступен для записи во время SST). Последняя версия Percona XtraBackup работает с шифрованием табличного пространства MySQL 5.7.119.0020
Следующие данные не зашифрованы (сообщается об ошибке)
- gcache Galera + данные репликации Galera
- Общий журнал / журнал медленных запросов

Шифрование на уровне базы данных также имеет свою слабость:

Пользователи root и MySQL могут прочитать файл набора ключей, что противоречит цели. Однако можно поместить ключ на смонтированный диск и размонтировать его при запуске MySQL (это можно сделать с помощью сценария). Недостатком этого является то, что в случае сбоя MySQL он не будет перезапущен автоматически без вмешательства человека.
И версия MariaDB, и версия MySQL шифруют данные только при записи на диск — данные не шифруются в ОЗУ, поэтому пользователь root потенциально может подключиться к MySQL с помощью gdb/strace или других инструментов и прочитать память сервера. Кроме того, с помощью gdb можно изменить структуру пароля пользователя root, а затем использовать mysqldump для копирования данных. Другой возможный метод — убить MySQL и запустить ее с помощью skip-grant-tables. Однако, если ключ размонтирован (т. е. находится на USB-накопителе), MySQL либо не запустится, либо не сможет прочитать зашифрованное табличное пространство.

Пример шифрования MariaDB

Чтобы включить шифрование полного уровня, мы можем добавить следующие параметры в my. cnf:

[mysqld] plugin-load-add=file_key_management.so file_key_management_filekey = ФАЙЛ:/mount/keys/mysql.key файл-ключ-управление-имя_файла = /mount/keys/mysql.enc innodb-шифровать-таблицы = ON innodb-шифрование-журнал = 1 innodb-шифрование-потоки = 1 зашифровать-tmp-disk-таблицы = 1 зашифровать-tmp-файлы = 1 шифровать-binlog = 1 file_key_management_encryption_algorithm = AES_CTR

CTRCTR

[mysqld]

plugin-load-add=file_key_management.so

file_key_management_filekey = FILE:/mount/keys/mysql.key

file-key-management-filename = /mount/keys/mysql.enc

2 innodb-encrypt-tables = ON

innodb-encrypt-log = 1

innodb-encryption-threads=1

encrypt-tmp-disk-tables=1

encrypt-tmp-files=1

encrypt-binlog=1

file_key_management_encryption_algorithm =

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

# openssl enc -aes-256-cbc -md sha1 -k -in keys.txt -out mysql.enc

шифрования находится в /mount/keys/mysql.key.

После запуска MySQL мы можем размонтировать раздел «/mount/key». В этом случае ключ будет недоступен и потенциальный хакер не сможет перезапустить MySQL с опцией «-skip-grant-tables» (без паролей). Однако это также предотвращает обычные перезапуски, особенно SST (полная синхронизация кластера).

Дополнительные примечания:

Шифрование повлияет на степень сжатия, особенно для физических резервных копий (логические резервные копии, т. е. mysqldump, не имеют значения, поскольку полученные данные не зашифрованы). Если ваш первоначальный размер сжатой резервной копии составлял всего 10% от размера базы данных, это не относится к зашифрованным таблицам.
Данные не шифруются при передаче и не будут шифроваться на ведомых устройствах репликации, если вы не включите те же параметры на ведомых устройствах. Шифрование также является локальным для сервера, поэтому, когда шифрование было только что включено на сервере, некоторые таблицы могут быть еще не зашифрованы (но в конечном итоге будут)
Чтобы проверить, какие таблицы зашифрованы, используйте таблицу информационной схемы INNODB_TABLESPACES_ENCRYPTION, которая содержит информацию о шифровании. Чтобы найти все зашифрованные таблицы, используйте этот запрос:
выберите * из information_schema.INNODB_TABLESPACES_ENCRYPTION, где ENCRYPTION_SCHEME=1
выберите * из information_schema.INNODB_TABLESPACES_ENCRYPTION, где ENCRYPTION_SCHEME=1

Пример шифрования MySQL 5.7

Чтобы включить шифрование, добавьте в my.cnf следующий параметр:

[mysqld] ранняя загрузка плагина = keyring_file. so keyring_file_data=/mount/mysql-keyring/keyring

[mysqld]

Early-plugin-load=keyring_file.so

keyring_file_data=/mount/mysql-keyring/keyring

Опять же, после запуска MySQL мы можем размонтировать раздел «/mount/mysql-keyring/».

Чтобы начать шифрование таблиц, нам нужно запустить alter table table_name Encryption=’Y’ , так как MySQL не будет шифровать таблицы по умолчанию.

Последняя версия Percona Xtrabackup также поддерживает шифрование и может создавать резервные копии зашифрованных таблиц.

Чтобы найти все зашифрованные табличные пространства в MySQL/Percona Server 5.7.11, мы можем использовать информационную_схему.INNODB_SYS_TABLESPACES и поле флага. Например, чтобы найти нормально зашифрованные таблицы, используйте следующий запрос:

mysql> выберите * из information_schema.INNODB_SYS_TABLESPACES, где флаг = 8225G *************************** 1-й ряд ********************** ******* ПРОСТРАНСТВО: 4688 НАЗВАНИЕ: тест/t1 ФЛАГ: 8225 FILE_FORMAT: Барракуда ROW_FORMAT: динамический PAGE_SIZE: 16384 ZIP_PAGE_SIZE: 0 SPACE_TYPE: Один FS_BLOCK_SIZE: 4096 FILE_SIZE: 98304 ALLOCATED_SIZE: 98304 *************************** 2-й ряд ********************** ******* ПРОСТРАНСТВО: 4697 НАЗВАНИЕ: sbtest/sbtest1_enc ФЛАГ: 8225 FILE_FORMAT: Барракуда ROW_FORMAT: динамический PAGE_SIZE: 16384 ZIP_PAGE_SIZE: 0 SPACE_TYPE: Один FS_BLOCK_SIZE: 4096 FILE_SIZE: 255852544 ALLOCATED_SIZE: 255856640 2 ряда в наборе (0,00 сек)

0 3 6

mysql> выберите * из information_schema. INNODB_SYS_TABLESPACES, где флаг = 8225G

**************************** 1-й ряд ******************* *********

Пространство: 4688

Имя: тест/T1

Флаг: 8225

File_format: Barracuda

ROW_FORMAT: Dynamic

PAGE_SIZE: 16384

ZIP_PAGE_SISIZE: 0

. Один

FS_BLOCK_SIZE: 4096

FILE_SIZE: 98304

ALLOCATED_SIZE: 98304

**************************** 2. строка ** *************************

SPACE: 4697

NAME: sbtest/sbtest1_enc

FLAG: 8225

FILE_FORMAT: Barracuda