ИТ Блог. Работа с базой данных (MySQL, CouchDB, MariaDB, MongoDB)
Внештатное резервное хранилище должно быть важной частью плана аварийного восстановления любой организации. Возможность хранения данных в отдельном физическом месте, где оно может пережить катастрофическое событие, которое уничтожает все данные в вашем основном центре обработки данных, гарантирует сохранение данных и непрерывность вашей организации. Служба облачного хранения – довольно хороший способ хранения резервных копий на удаленном сервере. Независимо от того, используете ли вы поставщика облачных вычислений или просто копируете данные во внешний центр обработки данных, в таких случаях необходимо использовать резервное шифрование. В одном из наших предыдущих блогов мы обсудили способы шифрования ваших резервных копий. Сегодня мы сосредоточимся на некоторых передовых методах резервного копирования.
Для шифрования и дешифрования данных вы должны использовать какой-то пароль или ключ. В зависимости от метода шифрования (симметричного или асимметричного) он может быть одним из секретов для шифрования и дешифрования или может быть открытым ключом для шифрования и закрытым ключом для дешифрования. Важно то, что вы должны держать их в безопасности. Если вы используете асимметричное шифрование, вам следует сосредоточиться на закрытом ключе, который вы будете использовать для дешифрования резервных копий.
Вы можете хранить ключи в системе управления ключами или в хранилище – на рынке есть множество опций, например, от KMS Amazon или Vault Hashicorp. Даже если вы решите не использовать эти решения, вы по-прежнему должны применять общие методы безопасности, например, чтобы гарантировать, что только правильные пользователи могут получить доступ к вашим ключам и паролям. Вы также должны рассмотреть возможность подготовки сценариев резервного копирования таким образом, чтобы вы не открывали ключи или пароли в списке запущенных процессов. В идеале, разместите их в файл, а не передавайте их в качестве аргумента для некоторых команд.
Основное различие между симметричным и асимметричным шифрованием заключается в том, что при использовании симметричного шифрования для шифрования и дешифрования используется один ключ или пароль. Для этого требуются более высокие стандарты безопасности на обоих концах процесса. Вы должны убедиться, что хост, на котором вы шифруете данные, очень безопасен, поскольку утечка симметричного ключа шифрования позволит получить доступ ко всем вашим зашифрованным резервным копиям.
С другой стороны, если вы используете асимметричное шифрование, у вас есть два ключа: открытый ключ для шифрования данных и закрытый ключ для дешифрования. Это делает вещи намного проще – вам не нужно заботиться о публичном ключе. Даже если он будет скомпрометирован, он все равно не позволит использовать какой-либо доступ к данным из резервных копий. Вы должны сосредоточиться только на безопасности секретного ключа. Это проще – вы, скорее всего, шифруете резервные копии на ежедневной основе (если не чаще), в то время как время от времени происходит восстановление, что делает возможным сохранение закрытого ключа в более безопасном месте (даже на выделенном физическом устройстве). Ниже приведен очень быстрый пример того, как вы можете использовать gpg для создания пары ключей и использовать ее для шифрования данных.
Во-первых, вам нужно сгенерировать ключи:
root@andreyex:~# gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"AndreyEx <info@AndreyEx.ru>"
Real name: AndreyEx
Email address: my@backups.cc
Comment: Backup key
You selected this USER-ID:
"AndreyEx (Backup key) <my@backups.cc>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.
Этот код создал как открытый, так и закрытый ключи. Затем вы хотите экспортировать свой открытый ключ для шифрования данных:
gpg --armor --export my@backups.cc> mybackupkey.asc
Затем вы можете использовать его для шифрования вашей резервной копии.
root @ andreyex: ~ # xtrabackup --backup --stream = xbstream | gzip | gpg -e -armor -r my@backups.cc -o /backup/pgp_encrypted.backup
Наконец, пример того, как вы можете использовать свой первичный ключ (в этом случае он хранится в локальном ключевом кольце) для дешифрования ваших резервных копий:
root@andreyex:/backup# gpg -d /backup/pgp_encrypted.backup | gunzip | xbstream -x
encryption: using gcrypt 1.6.5
You need a passphrase to unlock the secret key for
user: "AndreyEx (Backup key) <my@backups.cc>"
4096-bit RSA key, ID E047CD69, created 2018-12-01 (main key ID BC341551)
gpg: gpg-agent is not available in this session
gpg: encrypted with 4096-bit RSA key, ID E047CD69, created 2018-12-01
"AndreyEx (Backup key) <my@backups.cc>"Независимо от того, какое шифрование вы реализовали, симметричное или асимметричное, вам нужно подумать о ротации ключа. Прежде всего, очень важно иметь механизм для ротации ключей. Это может быть полезно в случае нарушения безопасности, и вам придется быстро менять ключи, которые вы используете для резервного копирования и дешифрования. Конечно, в случае нарушения безопасности вам необходимо подумать о том, что произойдет со старыми резервными копиями, которые были зашифрованы с использованием скомпрометированных ключей. Они были скомпрометированы, хотя они все еще могут быть полезны и требуются в соответствии с задачей точки восстановления. Существует несколько вариантов, включая повторное шифрование их или перенос их в непримиримую локализацию.
Если у вас есть возможность реализовать распараллеливание процесса шифрования, подумайте об этом. Производительность шифрования в основном зависит от мощности процессора, что позволяет увеличить количество ядер процессора параллельно шифрованию файла, что приведет к значительному сокращению времени шифрования. Некоторые из инструментов шифрования дают такую возможность. Одним из них является xtrabackup, который имеет возможность использовать встроенное шифрование и распараллелить процесс.
То, что вы ищете, это опция «–encrypt-key», либо «–encrypt-key-file», которые позволяют встроенное шифрование. При этом вы также можете определить «–encrypt-threads» и «–encrypt-chunk-size». Второй увеличивает рабочий буфер для шифрования, сначала определяет, сколько потоков должно использоваться для шифрования.
Конечно, это всего лишь одно из решений, которые вы можете реализовать. Вы можете добиться этого, используя инструменты оболочки. Пример ниже:
root@andreyex:~# files=2 ; mariabackup --user=root --backup --pass=pass --stream=xbstream |split -b 60M - backup ; ls backup* | parallel -j ${files} --workdir "$(pwd)" 'echo "encrypting {}" ; openssl enc -aes-256-cbc -salt -in "{}" -k mypass > "111{}"'Это отнюдь не идеальное решение, поскольку вам нужно заранее знать, насколько велика, более или менее, резервная копия будет разбивать ее на предопределенное количество файлов, соответствующих уровню параллелизации, которого вы хотите достичь (если вы хотите использовать 2 CPU ядра, у вас должно быть два файла, если вы хотите использовать 4 ядра, 4 файла и т. д.). Он также требует дискового пространства, которое в два раза превышает размер резервной копии, поскольку сначала он генерирует несколько файлов с использованием split, а затем шифрование создает другой набор зашифрованных файлов. С другой стороны, если ваш размер набора данных является приемлемым, и вы хотели бы улучшить производительность шифрования, это вариант, который вы можете рассмотреть. Чтобы расшифровать резервную копию, вам придется расшифровать каждый из отдельных файлов, а затем использовать «cat» для их объединения.
Независимо от того, как вы собираетесь внедрять резервное шифрование, вы должны его протестировать. Прежде всего, все резервные копии должны быть протестированы, зашифрованы или нет. Резервные копии могут быть неполными или могут пострадать от какого-либо типа коррупции. Вы не можете быть уверены, что резервная копия может быть восстановлена до фактического выполнения восстановления. Вот почему регулярная проверка резервного копирования является обязательной. Шифрование усложняет процесс резервного копирования. Проблемы могут появляться на время шифрования, опять же – ошибки или сбои могут испортить зашифрованные файлы. После зашифрования возникает вопрос, можно ли его расшифровать и восстановить?
У вас должен быть процесс тестирования восстановления. В идеале тест восстановления будет выполняться после каждой резервной копии. Как минимум, вы должны проверять свои резервные копии пару раз в год. Определенно вам нужно проверить его, как только было внесено изменение в процессе резервного копирования. Вы добавили сжатие в резервную копию? Вы изменили метод шифрования? Вы вращали ключ шифрования? Все эти действия могут повлиять на вашу способность фактически восстановить резервную копию. Поэтому вы должны убедиться, что вы проверите весь процесс после каждого изменения.
Тэги: , база данных Категории: Базы данных
