В последнее время я пытался разработать эффективную схему шифрования резервной копии базы данных.
У меня есть сервер Postgres 9.4, я думаю, что у меня есть большая часть схемы резервного копирования. Резервные копии будут храниться в стандартном файле .sql, заархивированы с помощью gzip, а затем запускаться через AES-CBC с OpenSSL.
Единственная часть, с которой у меня проблемы, - это ключи. Я не хочу использовать один главный ключ, мне нужна какая-то ротация или генерация ключей. Что-то, где все резервные копии (или, по крайней мере, большинство) имеют разные ключи, но также ключи, которые я могу легко найти / сгенерировать и использовать, если мне когда-нибудь понадобится. Я посмотрел в Google, но не нашел четкого решения.
Я тоже готов оценить совершенно разные решения для шифрования, я не привязан к AES-CBC / OpenSSL.
Мы будем благодарны за любое решение.
Спасибо.
Используйте gpg (GnuPG).
Вы сможете сгенерировать несколько ключей и зашифровать файл для расшифровки любым ключом из выбранного списка. Также ключи GPG не являются симметричными - вашему серверу нужны только открытые ключи для шифрования. Закрытые ключи, используемые для дешифрования, могут надежно храниться в другом месте.
Например, вы можете распечатать один закрытый ключ как QR-код для своего директора, а другой - для хранения в физическом сейфе.
Схема, которая реализована хотя бы в одной известной мне коммерческой СУБД, использует два ключа, назовем их мастер-ключ и ключ базы данных.
Главный ключ используется для шифрования ключа базы данных. Ключ базы данных, который может быть более высокого класса, используется для шифрования и дешифрования образов резервных копий.
Главный ключ можно безопасно повернуть, потому что для этого требуется только расшифровать и повторно зашифровать ключ базы данных.
Поскольку сам ключ базы данных остается неизменным, его всегда можно использовать для расшифровки и восстановления резервной копии независимо от возраста.
Если бы вместо этого вы меняли ключ базы данных, вам нужно было бы расшифровать и повторно зашифровать все хранящиеся резервные копии, что во многих случаях было бы непрактично.
Вы можете применить подход, предложенный @Tometzky, для шифрования ключа базы данных (хотя кажется, что это больше похоже на ключ дополнение чем ключ вращение).