Я хочу зашифровать регулярно создаваемые и сжатые файлы резервных копий из контейнеров OpenVZ, прежде чем они покинут сервер и будут скопированы в пространство резервных копий провайдера через ftp.
Они различаются по размеру от 6 до 50 ГБ (после сжатия lzo). ОБНОВИТЬ ... и создаются автоматически средой виртуализации Proxmox.
Различные комментарии к mcrypt («качество кода / поддержка») или openssl («не для больших файлов») заставляют меня задуматься, подходят ли они. Что посоветуете?
Более того: я не могу разбить файл резервной копии во время сжатия на более мелкие части и не хочу делать это впоследствии по соображениям производительности. У меня был плохой опыт использования двуличия, и я хочу избежать этого, если вы захотите упомянуть об этом.
Серверная среда - Debian 7.
Другие предложили различные инструменты симметричного шифрования, которые подходят для конвейерной обработки, например aespipe. Я подозреваю, что они будут настолько эффективны, насколько это возможно, учитывая, что шифрование - это довольно дорогостоящая задача для процессора, и это неплохое предложение.
Но я бы предложил рассмотреть асимметричный инструмент, такой как gpg. Внутреннее массовое шифрование по-прежнему будет осуществляться через симметричный шифр с использованием одноразового ключа, но вся проблема управления ключами становится в значительной степени проще с доступным набором инструментов GPG.
В частности, использование простого симметричного шифра для шифрования резервных копий либо фатально подрывает безопасность (в том смысле, что для шифрования всех резервных копий используется один и тот же ключ, и сервер должен иметь к нему доступ на регулярной основе), либо существенно увеличивает вашу сложность (в том, что вы используете разные ключи для каждой резервной копии и теперь должны управлять ими вручную).
С помощью такого инструмента, как gpg, вы можете сгенерировать единую пару ключей для шифрования всех резервных копий, а серверу, который выполняет шифрование, нужна только общедоступная половина, на которой будут зашифрованы резервные копии. Вы можете хранить закрытый ключ отдельно либо в условиях нормальной безопасности, либо - если этого требуют бизнес-соображения - организовать разделение ключа между множеством лиц, некоторая подгруппа которых необходима для восстановления закрытого ключа, с использованием стандартных протоколов обмена ключами.