Chapter 6 Working with Encrypted InnoDB Tables — MySQL Enterprise Backup 4.1

Глава 6 Работа с зашифрованными таблицами InnoDB

MySQL Enterprise Backup поддерживает зашифрованные табличные пространства InnoDB. Подробную информацию о том, как MySQL-сервер шифрует и расшифровывает таблицы InnoDB, см. — там объясняются такие понятия, как главный ключ и ключи табличного пространства, что важно для понимания, как MySQL Enterprise Backup работает с зашифрованными табличными пространствами InnoDB.

Когда шифрование табличного пространства InnoDB использует централизованное решение управления ключами, эта функция называется “MySQL Enterprise Transparent Data Encryption (TDE)”.

Ниже приводится краткое описание того, как зашифрованные таблицы InnoDB обрабатываются MySQL Enterprise Backup при операциях резервного копирования, восстановления и применения журналов.

Создание резервной копии базы данных с зашифрованными таблицами InnoDB. Ниже приведен типичный командный запрос для создания резервной копии базы данных, содержащей зашифрованные таблицы InnoDB:

$ mysqlbackup --user=root --password --backup-image=/home/admin/backups/my.mbi --backup-dir=/home/admin/backup-tmp \
    --encrypt-password="password" backup-to-image

Во время операции резервного копирования mysqlbackup копирует файлы зашифрованного табличного пространства InnoDB в резервную копию и выполняет следующие действия:

Для MySQL Enterprise Backup 4.1.0, MySQL Enterprise Backup 4.1.1 и более поздних версий, работающих с MySQL Enterprise Server 5.7.20 и более ранними версиями, или MySQL Enterprise Backup 4.1.1 и более поздними версиями, работающих с MySQL Community Server 5.7:
- При онлайн-резервном копировании mysqlbackup связывается с MySQL-сервером, чтобы определить плагин keyring, используемый сервером, который в настоящее время является одним из keyring_file или keyring_okv (для оффлайн-резервных копий параметр --keyring должен быть использован для передачи той же информации в mysqlbackup). mysqlbackup также узнает у сервера, где получить доступ к keyring (для оффлайн-резервной копии параметр --keyring_file_data или --keyring_okv_conf_dir должен быть использован для предоставления той же информации). После получения доступа к keyring mysqlbackup получает главный ключ и использует его для расшифровки зашифрованных ключей табличного пространства, которые использовались для шифрования таблиц InnoDB на сервере.
- Используя пароль пользователя, предоставленный с параметром --encrypt-password, mysqlbackup заново шифрует ключи табличного пространства. Для каждой зашифрованной таблицы перешифрованный ключ табличного пространства вместе с другой информацией сохраняется в файле передачи (с расширением .bkt), который сохраняется в резервной копии.
Для MySQL Enterprise Backup 4.1.1 и более поздних версий, работающих с MySQL Enterprise Server 5.7.21 и более поздними версиями:
- MySQL Enterprise Backup всегда сохраняет главный ключ шифрования в зашифрованном файле внутри резервной копии, независимо от типа используемого плагина keyring.
- mysqlbackup связывается с MySQL-сервером, чтобы определить используемый плагин keyring, который в настоящее время является одним из keyring_encrypted_file, keyring_file, keyring_okv или keyring_aws.
- Если сервер использует плагин keyring_encrypted_file, пользователь должен использовать параметр --encrypt-password, чтобы предоставить mysqlbackup пароль шифрования файла keyring, который был установлен на сервере с этим параметром. Затем mysqlbackup копирует с сервера зашифрованный файл данных keyring, содержащий главный ключ, используемый для шифрования всех ключей табличного пространства, в папку meta в резервной копии. Зашифрованные файлы табличного пространства также копируются в резервную копию.
- Если сервер использует плагин keyring, отличный от keyring_encrypted_file, mysqlbackup получает доступ к keyring, чтобы получить главный ключ и использует его для расшифровки зашифрованных ключей табличного пространства, которые использовались для шифрования таблиц InnoDB на сервере. Затем главный ключ помещается в файл данных keyring, зашифрованный с паролем пользователя, предоставленным с параметром --encrypt-password, и сохраняется в папке meta в резервной копии с именем keyring_kef.

Примечание

Пользователи, которые не хотят предоставлять пароль в командной строке или в файле параметров, могут использовать параметр --encrypt-password без указания значения; mysqlbackup запросит у пользователя ввести пароль перед началом операции. Это относится ко всем командам, использующим параметр --encrypt-password.

Команда extract или image-to-backup-dir для резервной копии изображения, содержащей зашифрованные таблицы InnoDB, не требует параметра --encrypt-password.

Восстановление резервной копии с зашифрованными таблицами InnoDB. Ниже приведен типичный командный запрос для восстановления резервной копии одного файла, содержащей зашифрованные таблицы InnoDB:

$ mysqlbackup  --defaults-file=/usr/local/mysql/my.cnf  --backup-image=/home/admin/backups/my.mbi \
    --backup-dir=/home/admin/restore-tmp --encrypt-password="password" copy-back-and-apply-log

Для MySQL Enterprise Backup 4.1.0 или MySQL Enterprise Backup 4.1.1 и более поздних версий, работающих с MySQL 5.7.20 и более ранними версиями: Во время операции восстановления mysqlbackup копирует файлы зашифрованного табличного пространства InnoDB на сервер. mysqlbackup также выполняет следующие действия:

Используя пароль пользователя, предоставленный с параметром --encrypt-password, который должен совпадать с паролем, использованным при создании резервной копии базы данных, mysqlbackup расшифровывает ключи табличного пространства, которые были зашифрованы с использованием этого пароля при создании резервной копии.
Если используется параметр --generate-new-master-key, mysqlbackup генерирует новый главный ключ и использует его для перешифрования ключей табличного пространства. Для использования параметра --generate-new-master-key необходимо указать параметр --keyring, а также параметр --keyring_file_data (когда --keyring=keyring_file) или параметр --keyring_okv_conf_dir (когда --keyring=keyring_okv), чтобы mysqlbackup мог получить доступ к keyring и добавить новый главный ключ в него.
```
$ mysqlbackup  --defaults-file=/usr/local/mysql/my.cnf  --backup-image=/home/admin/backups/my.mbi \
  --backup-dir=/home/admin/restore-tmp --encrypt-password="password" \
  --generate-new-master-key --keyring=keyring_file --keyring-file-data=path-to-keyring-file \
    copy-back-and-apply-log
```
Параметры keyring должны быть предоставлены восстановленному серверу.

Если параметр --generate-new-master-key не используется, mysqlbackup предполагает, что тот же keyring, который использовался на сервере во время создания резервной копии, остается действительным и доступен восстановленному серверу.

Для MySQL Enterprise Backup 4.1.1 и более поздних версий, работающих с MySQL 5.7.21 и более поздними версиями: Для операции восстановления необходимо предоставить тот же пароль, который использовался при создании резервной копии, с параметром --encrypt-password. Во время восстановления mysqlbackup копирует зашифрованные файлы табличного пространства InnoDB и зашифрованный файл, содержащий главные ключи (keyring_kef), на сервер. Он также выполняет следующие действия:

Для MySQL Enterprise Server: mysqlbackup восстанавливает зашифрованный файл данных keyring в его правильное местоположение на сервере. Восстановленный сервер должен быть запущен с плагином keyring_encrypted_file и с параметрами и (которые должны предоставить серверу тот же пароль, который использовался с параметром --encrypt-password во время восстановления).
Для MySQL Community Server: Плагин keyring_file является единственным поддерживаемым плагином keyring для MySQL Community Server; поэтому mysqlbackup использует пароль, предоставленный с параметром --encrypt-password, для расшифровки файла данных keyring и затем восстанавливает его в правильное местоположение на сервере для использования плагином keyring_file.

Для инкрементных резервных копий. Для серии инкрементных резервных копий, если на сервере используется плагин ключей, отличный от keyring_encrypted_file, пользователи могут указать другое значение для --encrypt-password для любой из полных или инкрементных резервных копий в последовательности резервного копирования. Однако пароль, используемый для создания конкретной полной или инкрементной резервной копии, должен быть предоставлен для восстановления этой резервной копии. При запуске сервера после восстановления серии инкрементных резервных копий пароль, используемый для восстановления последней инкрементной резервной копии, должен быть предоставлен серверу (за исключением MySQL Community Server, который будет запущен с плагином keyring_file и не требует указания этого параметра для запуска).

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

$ mysqlbackup --user=root --password --backup-dir=/home/admin/backup \
    --encrypt-password="password" backup

Следующая команда типична для подготовки резервной копии с помощью команды apply-log:

$ mysqlbackup --backup-dir=/home/admin/backup  --encrypt-password="password" apply-log

Обратите внимание, что пароль пользователя должен быть предоставлен с помощью параметра --encrypt-password, так как ключи пространства таблиц должны быть расшифрованы перед применением журнала. Это же требование применяется, когда вы пытаетесь обновить резервную копию с использованием инкрементной резервной копии с помощью команды apply-incremental-backup:

$ mysqlbackup  --backup-dir=/home/admin/backup --incremental-backup-dir=/home/admin/backup-in \
    --encrypt-password="password" apply-incremental-backup

Если вы использовали разные значения для --encrypt-password для полных или инкрементных резервных копий в последовательности резервного копирования, убедитесь, что вы предоставите тот же пароль, который вы использовали для создания каждой отдельной резервной копии, когда выполняете операцию apply-log или apply-incremental-backup с ним.

Далее, команда copy-back восстанавливает подготовленную резервную копию на сервер:

$ mysqlbackup  --defaults-file=/usr/local/mysql/my.cnf  --backup-dir=/home/admin/backup copy-back

Обратите внимание, что параметр --encrypt-password для этого шага не требуется.

Вы можете объединить два этапа apply-log и copy-back в один, запустив команду copy-back-and-apply-log, для которой необходим параметр --encrypt-password:

$ mysqlbackup  --defaults-file=/usr/local/mysql/my.cnf  --backup-dir=/home/admin/backup \
  --encrypt-password="password" copy-back-and-apply-log

Для MySQL Enterprise Backup 4.1.0 или MySQL Enterprise Backup 4.1.1 и более поздних версий, работающих с MySQL 5.7.20 и более ранними версиями: Вы также можете использовать параметр --generate-new-master-key, как и при восстановлении резервной копии в одном файле:

$ mysqlbackup  --defaults-file=/usr/local/mysql/my.cnf  --backup-dir=/home/admin/backup \
  --generate-new-master-key --keyring=keyring_file --keyring-file-data=path-to-keyring-file \
  --encrypt-password="password" copy-back-and-apply-log

Ограничения. При работе MySQL Enterprise Backup с зашифрованными таблицами InnoDB действуют определенные ограничения:

Для MySQL 5.7.11 и более ранних версий резервное копирование для пространств таблиц InnoDB, зашифрованных с помощью “MySQL Enterprise Transparent Data Encryption (TDE)”, не поддерживается mysqlbackup. Чтобы выполнить резервное копирование этих таблиц, обновите сервер до последней версии MySQL 5.7, обращая внимание на любые требования к обновлению, описанные в, особенно на требования к параметру, и поверните главный ключ на обновлённом сервере, используя оператор. Затем выполните процесс резервного копирования.
Во время операции validate, если mysqlbackup обнаруживает какие-либо зашифрованные таблицы InnoDB, она выдает предупреждение и пропускает их.
При частичном резервном копировании с использованием переносимых пространств таблиц (то есть, когда используется параметр --use-tts), зашифрованные таблицы InnoDB никогда не включаются в резервную копию. В файле журнала выводится предупреждение всякий раз, когда зашифрованная таблица InnoDB, соответствующая критериям выбора таблиц, была пропущена.
Параметр --skip-unused-pages не оказывает никакого влияния на зашифрованные таблицы InnoDB во время резервного копирования (то есть, пустые страницы для этих таблиц не пропускаются).
Офлайн-резервное копирование зашифрованных таблиц InnoDB не поддерживается MySQL Enterprise Backup 4.1.1 и более поздними версиями при работе с MySQL Enterprise Server 5.7.21 и более поздними версиями.