Зачем разделять at-rest и in-transit

Это два разных момента жизни резервной копии, и защита одного не заменяет защиту другого. Encryption in-transit защищает бэкап только пока он передаётся по сети — от источника к хранилищу. Encryption at-rest защищает его после того, как передача завершилась и файл лежит на диске, ленте или в облачном бакете. Статья «Правило 3-2-1 для бэкапов на практике» упоминает контроль доступа к копиям («отдельные учётные данные хранилища копий») — это соседняя, но другая мера: контроль доступа ограничивает, кто может открыть бэкап, шифрование делает его нечитаемым даже для того, кто получил несанкционированный доступ к файлу.

Шифрование at-rest: диск, том, контейнер

По официальному источнику NIST, полнодисковое шифрование (Full Disk Encryption, FDE) шифрует «все данные на жёстком диске, используемом для загрузки компьютера, включая операционную систему», и требует аутентификации до загрузки ОС. Шифрование тома (volume encryption) защищает «весь логический том» после ввода аутентификации. Отдельно выделяется шифрование виртуального диска — «контейнер» (единый зашифрованный файл), который можно переносить между носителями; NIST прямо отмечает, что это делает защиту резервной копии «тривиальной»: «контейнер просто копируется на резервный сервер или носитель».

Практический источник даёт конкретные текущие рекомендации по алгоритмам: «шифрование at-rest должно использовать AES с ключом не менее 256 бит и, где возможно, аутентифицированный режим шифрования (AES-GCM)». Для облачного хранения — «SSE-KMS (например, AWS SSE-KMS) или ключи, управляемые заказчиком, чтобы ключи были отделены от хранилища». Для локального хранения — «FIPS-140 валидированное шифрование, самошифрующиеся диски (SED) или полнодисковое шифрование (LUKS с AES-XTS)». Для ленточных носителей — отдельное требование: «AES-256 шифрование ленты».

Шифрование in-transit: TLS и шифронаборы

Для канала передачи бэкапа тот же практический источник задаёт конкретную планку: «используйте только TLS 1.2 или TLS 1.3. Отключите TLS 1.0/1.1 и SSLv3» — устаревшие версии протокола содержат известные уязвимости и не должны оставаться доступными даже как fallback. Из конкретных шифронаборов источник называет предпочтительными «для TLS 1.3 — TLS_AES_256_GCM_SHA384; для TLS 1.2 — ECDHE-RSA-AES256-GCM-SHA384», с акцентом на forward secrecy и аутентифицированное шифрование.

Где хранить ключи: главное правило

Само по себе шифрование ничего не даёт, если ключ лежит рядом с зашифрованными данными — в этом случае шифрование становится формальностью. По источнику, правило звучит однозначно: «никогда не храните ключи в открытом виде рядом с бэкапами» — вместо этого нужен «централизованный KMS/HSM» (система управления ключами или аппаратный модуль безопасности).

Отдельно рекомендована ротация ключей — «как минимум ежегодная, или чаще для данных повышенного риска» — с документированной процедурой повторного шифрования, и разделение полномочий: «операторы, управляющие бэкапами, не должны иметь единоличный доступ к административным функциям KMS», что реализуется через отдельные роли IAM.

NIST дополняет это требованием планирования восстановления ключей: организациям следует «тщательно продумать, как практики управления ключами могут поддержать восстановление зашифрованных данных, если ключ был случайно уничтожен» — для резервных копий на съёмных носителях источник прямо рекомендует «сохранять предыдущие ключи на случай, если они понадобятся».

Практический минимум

Шифруйте бэкап и at-rest, и in-transit — это две независимые меры, не взаимозаменяемые. Используйте AES-256 с аутентифицированным режимом для данных на хранении и только TLS 1.2/1.3 для канала передачи. Никогда не держите ключ шифрования в том же хранилище, что и зашифрованный бэкап — используйте отдельный KMS/HSM, и заранее спланируйте процедуру восстановления на случай потери ключа, а не только процедуру шифрования.

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