Шифрование данных при хранении и передаче: практические схемы 2026

Что шифровать и чем: матрица выбора инструмента под задачу

Короткий ответ: под каждую задачу есть проверенный инструмент, и изобретать схему с нуля не нужно. Диск или раздел шифруйте через LUKS2 или ZFS native encryption, отдельные файлы через age, резервные копии через restic или borg, прикладной трафик через TLS 1.3, удаленный доступ через WireGuard или OpenVPN, пароли через Argon2id. Ключи держите отдельно от данных: в KMS, HashiCorp Vault или HSM.

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

Для кроссплатформенных задач, где нужен переносимый контейнер, подойдет VeraCrypt: он шифрует файл-контейнер или раздел и работает на Windows, macOS и Linux. В серверных сценариях VeraCrypt встречается реже: автоматизация и интеграция с systemd слабее, чем у LUKS2.

Актуальные алгоритмы 2026: что применять, что устарело

Базовый набор 2026 года: AES-256-GCM для симметричного шифрования с аутентификацией, ChaCha20-Poly1305 там, где нет аппаратного ускорения AES (мобильные устройства, часть ARM-серверов), XChaCha20 для больших nonce в потоковых сценариях, Argon2id для паролей, Ed25519 для подписей, X25519 для обмена ключами. Этого набора хватает для большинства задач, включая TLS 1.3.

Устаревшее и опасное: AES-CBC без отдельного HMAC (уязвим к padding oracle), RSA-2048 в новых системах, SHA-1 и MD5, TLS 1.0 и 1.1 (отозваны в RFC 8996), 3DES, RC4, PBKDF2 с числом итераций меньше 600 000 для SHA-256. RSA-2048 формально допустим до 2030 года по NIST, но новые ключи логичнее выпускать на 3072 бита и выше или сразу на Ed25519. Старый софт с этими алгоритмами выводите из эксплуатации, а не подкручивайте.

Пост-квантовые схемы перестали быть теорией. NIST стандартизировал ML-KEM (FIPS 203) в 2024 году, а OpenSSL 3.5 в 2025 году включил гибрид X25519MLKEM768 в стандартный TLS-стек. В 2026 году его поддерживают Chrome, Firefox и Cloudflare, поэтому новые TLS-развертывания получают защиту от будущих квантовых атак без пересборки. Для данных на дисках квантовая угроза слабее: AES-256 устойчив к алгоритму Гровера с запасом.

Проверить, что использует ваш сервер, можно командами openssl s_client и ssh -Q kex. Если в выводе есть aes128-cbc, 3des-cbc или ssh-rsa, конфигурацию пора обновлять.

Где хранить ключи: KMS, Vault, HSM или локально

Рабочая модель для большинства систем: envelope encryption. Данные шифрует ключ данных (DEK), DEK шифрует ключ шифрования ключей (KEK), KEK живет в KMS, HashiCorp Vault или HSM. В базе и в бэкапах хранится только зашифрованный DEK. Смена KEK не требует перешифрования данных: достаточно переобернуть DEK новым ключом.

Для LUKS2 ключом служит парольная фраза или ключевой файл, а мастер-ключ лежит в заголовке раздела. Копию заголовка делайте сразу после форматирования:

cryptsetup luksHeaderBackup /dev/nvme0n1p2 --header-backup-file /secure/luks-header.img

Файл храните на офлайн-носителе: без заголовка данные не восстановить даже с правильным паролем.

Для TLS приватные ключи выпускайте через cert-manager или Vault PKI, а храните в KMS или HSM уровня FIPS 140-3 Level 3, если этого требуют регуляторы. Антипаттерны, которые встречаются в аудитах чаще всего: ключ лежит рядом с данными (в том же облачном бакете или датасете ZFS), ключи закоммичены в git, один DEK используется для всех клиентов, копия заголовка LUKS отсутствует.

Клиентское, серверное и гибридное шифрование, а также управление ключами через HSM разобраны в отдельном руководстве: Шифрование данных при передаче и хранении: клиентское, серверное и гибридные модели.

Шифрование дисков и разделов: LUKS2 и ZFS на практике

LUKS2 закрывает блочное устройство целиком: корень, данные, swap. ZFS native encryption работает на уровне датасета и дает отдельные ключи для разных категорий данных в одном пуле. Оба варианта проверены на практике, разница в точке приложения шифрования.

LUKS2: форматирование, TPM2/FIDO2 и автозагрузка

Форматирование раздела под LUKS2 с AES-256-XTS:

cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --hash sha256 /dev/nvme0n1p2

Открыть раздел и создать файловую систему:

cryptsetup luksOpen /dev/nvme0n1p2 cryptdata
mkfs.ext4 /dev/mapper/cryptdata

Автозагрузка без ручного ввода пароля на сервере с TPM2 (systemd 248 и новее):

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p2

Для рабочей станции добавьте FIDO2-ключ:

systemd-cryptenroll --fido2-device=auto /dev/nvme0n1p2

Запись в /etc/crypttab:

cryptdata UUID=ВАШ-UUID none luks,tpm2-device=auto

Проверка слотов и состояния:

cryptsetup luksDump /dev/nvme0n1p2

Что ломается на практике. TPM2 привязан к регистрам PCR, чаще всего к PCR 7 (состояние Secure Boot). Обновление прошивки, смена настроек BIOS или загрузчика меняет измерения, и раздел перестает открываться автоматически. Recovery-пароль и копия заголовка обязательны. Второй риск: swap в открытом виде. Секреты из памяти попадают на диск, поэтому на серверах используйте зашифрованный swap или zram. LUKS2 с 2020 года выводит ключ из парольной фразы через Argon2id, что защищает от перебора на GPU.

ZFS native encryption в TrueNAS: включение и ротация ключей

В TrueNAS шифрование датасета включается в интерфейсе: раздел Datasets, кнопка Edit у нужного датасета, вкладка Encryption, затем парольная фраза или ключевой файл. Через CLI то же действие выглядит так:

zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt tank/secure

Вариант с ключевым файлом:

zfs create -o encryption=on -o keyformat=hex -o keylocation=file:///etc/zfs/keys/tank-secure.key tank/secure

Ротация ключа датасета:

zfs change-key tank/secure

ZFS по умолчанию использует AES-256-GCM. Ключ не хранится внутри датасета: при потере ключа данные не восстановить, даже если пул цел. Отправка на другой сервер с флагом zfs send -w сохраняет шифротекст и не требует расшифровки на промежуточной машине. Границы защиты: ZFS шифрует данные, метаданные и свойства датасета; при этом имена датасетов и структура пула остаются видимыми.

Сравнение с LUKS2 простое. LUKS2 прячет все содержимое блочного устройства, включая файловую систему, но ключ у раздела один. ZFS дает отдельные ключи на датасеты и умеет наследовать их по иерархии, зато требует загрузки ключа перед монтированием. Для NAS с разными категориями данных (документы, бэкапы, медиатека) ZFS удобнее. Для системного диска сервера LUKS2 надежнее: он закрывает и корень, и swap.

Защиту хранилищ от шифровальщиков через снимки, WORM и AES-256 разбираем отдельно: Защита данных в хранилищах: AES-256, WORM и snapshots для отката атак.

Шифрование файлов и резервных копий: GPG, age, restic, borg

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

GPG vs age: что выбрать в 2026

GPG остается стандартом там, где есть готовая инфраструктура: подписи пакетов, переписка с контрагентами, смарт-карты. Обновленный стандарт OpenPGP (RFC 9580, 2024 год) добавил ключи v6, X25519, Ed25519 и AEAD-режимы, но число опций и сложность синтаксиса остались высокими. Типовые команды: gpg --encrypt --recipient admin@host file.tar.gz и gpg --decrypt file.tar.gz.gpg.

age создан как минималистичная замена: X25519 для обмена ключами, ChaCha20-Poly1305 для шифрования, три команды на все случаи. Генерация ключа, шифрование и расшифровка:

age-keygen -o key.txt
age -r AGE_PUBLIC_KEY -o backup.tar.gz.age backup.tar.gz
age -d -i key.txt -o backup.tar.gz backup.tar.gz.age

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

Шифрование бэкапов restic и borg: ключи и восстановление

restic шифрует репозиторий целиком: данные, метаданные и имена файлов. Криптография: AES-256-CTR для данных, Poly1305-AES для аутентификации, scrypt для вывода ключа из пароля. Типовой цикл:

restic -r s3:ENDPOINT/BUCKET init
restic -r s3:ENDPOINT/BUCKET backup /srv/data
restic -r s3:ENDPOINT/BUCKET snapshots
restic -r s3:ENDPOINT/BUCKET restore latest --target /restore

Пароль не хранится в скрипте: переменная RESTIC_PASSWORD_FILE указывает на файл с правами 600, а сам файл лучше держать в Vault или в systemd credentials.

borg устроен похоже: AES-256-CTR плюс HMAC, режим repokey-blake2 хранит ключ внутри репозитория, защищенный паролем. Инициализация и базовый цикл:

borg init --encryption=repokey-blake2 /mnt/backup/borg
borg create /mnt/backup/borg::daily-2026-09-11 /srv/data
borg extract /mnt/backup/borg::daily-2026-09-11

Ключевой риск обоих инструментов один: пароль от репозитория открывает все копии. Потеря пароля означает потерю бэкапов, восстановление невозможно. Правило 3-2-1 (три копии, два носителя, одна копия вне офиса, то есть offsite) работает только вместе с тестом восстановления: раз в квартал разворачивайте репозиторий на отдельной машине и проверяйте выборочные файлы. Подробная схема защиты бэкапов от удаления и шифровальщиков собрана в руководстве: Надежная защита резервных копий: шифрование, управление доступом и защита от удаления.

Шифрование данных при передаче: TLS, SSH, VPN

Три технологии решают три разные задачи. TLS защищает прикладной трафик (HTTPS, gRPC, API), SSH защищает администрирование, VPN защищает сетевой периметр и маршрутизацию. Путать уровни опасно: TLS-терминация на балансировщике не защищает трафик между балансировщиком и бэкендом, а VPN не заменяет mTLS между сервисами.

TLS 1.3 в Nginx и mTLS между сервисами

Минимальный набор директив для Nginx с TLS 1.3:

ssl_protocols TLSv1.3;
ssl_certificate /etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/YOUR_DOMAIN/privkey.pem;
ssl_session_tickets off;

TLS 1.3 сокращает рукопожатие до одного RTT и убирает устаревшие шифры. Режим 0-RTT ускоряет повторные подключения, но допускает повтор запросов, поэтому для платежей и других неидемпотентных операций его отключают на уровне приложения. Проверка конфигурации: openssl s_client -connect host:443 -tls1_3 и сканер testssl.sh.

Для трафика между сервисами включайте взаимную аутентификацию. В Nginx это две директивы:

ssl_client_certificate /etc/nginx/ca.crt;
ssl_verify_client on;

Сертификаты выпускает внутренний CA: Vault PKI или cert-manager с приватным issuer. Публичные сертификаты обновляйте автоматически: Let's Encrypt выдает 90-дневные сертификаты, certbot renew запускается по таймеру systemd, nginx -s reload применяет конфигурацию без разрыва соединений. Самоподписанные сертификаты в проде остаются антипаттерном: их нельзя централизованно отозвать, а клиенты требуют ручных исключений. Имя хоста в TLS передается через SNI и видно посредникам; шифрование Client Hello (ECH) постепенно появляется в браузерах и CDN, но пока не стало универсальным.

WireGuard vs OpenVPN: сравнение и выбор

WireGuard работает в ядре Linux с версии 5.6, занимает около 4000 строк кода и использует ChaCha20-Poly1305, X25519 и BLAKE2s. Конфигурация узла умещается в несколько строк, подъем туннеля: wg-quick up wg0. Скорость выше, задержки ниже, аудит проще.

OpenVPN работает в пространстве пользователя, опирается на TLS и проверен двумя десятилетиями эксплуатации. Настройка сложнее: нужна PKI с CA, серверными и клиентскими сертификатами. Зато OpenVPN умеет работать через TCP 443 и легче проходит через DPI и строгие корпоративные файрволы. Конфигурация выдается клиенту одним файлом .ovpn, клиенты есть для iOS, Android, Windows и macOS. Развертывание OpenVPN в Docker на VPS изолирует сервис и сокращает настройку до генерации PKI и NAT: поднять узел можно, к примеру, в облаке Timeweb Cloud, где доступны VPS с почасовой оплатой.

Правило выбора: WireGuard для производительности, простоты и трафика между своими узлами, OpenVPN для совместимости, обхода блокировок и сред, где нельзя загрузить kernel-модуль. Для site-to-site между офисами подойдет IPsec в режиме tunnel, особенно если оборудование уже умеет IKEv2.

Отдельная задача: доступ к внешним API. Если нужны модели GPT, Gemini или Claude, есть агрегаторы вроде AiTunnel с единым интерфейсом и оплатой в рублях без VPN. Правило для любых внешних API одно: ключи храните в Vault, передавайте только по TLS 1.3 и ротируйте при подозрении на утечку.

SSH: ключи Ed25519 и отключение парольной аутентификации

SSH остается главным каналом администрирования, и парольная аутентификация в нем остается слабым звеном. Генерация ключа Ed25519 с парольной фразой:

ssh-keygen -t ed25519 -a 100 -C admin@host

Директивы в /etc/ssh/sshd_config, которые закрывают базовые риски:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
MaxAuthTries 3
AllowGroups ssh-users

После правки проверьте файл командой sshd -t и перезапустите службу. Для второго фактора на критичных узлах используйте FIDO2-ключи (OpenSSH 8.2 и новее) или TOTP. Сравнение автономных open-source аутентификаторов, их шифрование и перенос seed-ключей есть в отдельной статье: Альтернативы Google Authenticator: выбираем автономный 2FA-аутентификатор с открытым исходным кодом.

Для больших парков машин удобнее SSH-сертификаты: CA подписывает пользовательские ключи на короткий срок, sshd проверяет подпись и принципалы. Дополнительный слой: port knocking или доступ к SSH только через VPN. Открытый в интернет порт 22 не нужен. Полный чек-лист по защите Linux-сервера с конфигами firewalld и nftables собран здесь: Безопасность Linux-сервера: практический hardening и аудит в 2026.

Защита персональных данных и паролей: требования и схема

Российские и международные требования сходятся в главном: персональные данные шифруют при хранении и передаче, доступ ограничивают, операции журналируют. С 30 мая 2025 года в России действуют повышенные штрафы за утечки персональных данных: до 15 млн рублей за повторное нарушение и уголовная ответственность для виновных лиц. Уведомить Роскомнадзор об инциденте нужно в течение 24 часов. В GDPR штрафы достигают 20 млн евро или 4% годового оборота компании.

Рабочая схема для приложений: PII хранятся в базе только в зашифрованном виде по модели envelope encryption, DEK уникален для клиента или таблицы, KEK лежит в KMS или HSM. Номера карт, паспортные данные и другие чувствительные поля дополнительно маскируются в логах и интерфейсах. Доступ к расшифровке получают сервисы с явной ролью, каждое обращение фиксируется в аудите.

Argon2id: параметры и типичные ошибки

Пароли хешируют только медленными функциями. Рекомендации OWASP для Argon2id: 64 MiB памяти, 3 итерации, 4 потока. Минимально допустимый профиль: 19 MiB, 2 итерации, 1 поток. Соль уникальна для каждого пользователя и не короче 16 байт, pepper (секрет приложения) хранится в KMS и не попадает в базу рядом с хешами. Для старых систем, где Argon2id недоступен, допустим bcrypt с cost 12 и выше.

Ошибки, которые встречаются в коде чаще всего: SHA-256 или MD5 вместо Argon2id, одинаковая соль для всех пользователей, отсутствие ограничения попыток входа, пароли в логах и в параметрах URL. Перед запуском прогоните бенчмарк hashcat на целевом железе: хеширование одного пароля должно занимать 100-500 мс, тогда перебор по словарю становится дорогим, а вход остается незаметным для пользователя.

Управление ключами и ротация без простоя

Шифрование без ротации ключей теряет смысл через год-два. План ротации определяет, что меняется: парольная фраза, ключ датасета, сертификат или ключ репозитория бэкапов. Для каждого типа есть своя процедура без остановки сервиса.

Ротация ключей LUKS и TLS: пошагово

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

cryptsetup luksHeaderBackup /dev/nvme0n1p2 --header-backup-file /secure/luks-header-2026-09.img
cryptsetup luksAddKey /dev/nvme0n1p2
cryptsetup luksRemoveKey /dev/nvme0n1p2

Простая замена пароля в одном слоте запускается командой cryptsetup luksChangeKey /dev/nvme0n1p2. Смена алгоритма или размера ключа в LUKS2 идет онлайн: cryptsetup reencrypt /dev/nvme0n1p2. Операция может идти часами, прогресс виден через cryptsetup luksDump. Для ZFS ротация ключа датасета мгновенная (zfs change-key): переобертывается только ключ данных, а не сами блоки.

TLS-сертификаты обновляются автоматически: certbot renew --dry-run проверяет цепочку, cert-manager перевыпускает сертификаты в Kubernetes, nginx -s reload применяет новые без разрыва соединений. В Vault ротация transit-ключей запускается командой vault write -f transit/keys/app/rotate: старые версии ключа остаются доступны для расшифровки, новые данные шифруются новой версией.

Репозитории restic и borg поддерживают несколько паролей: restic key add и restic key remove, borg key change-passphrase. Порядок тот же: добавить новый ключ, проверить доступ, удалить старый.

План на случай компрометации: отозвать скомпрометированные сертификаты и ключи API, сменить парольные фразы LUKS, ротировать ключи бэкап-репозиториев, переобернуть DEK новым KEK. Если утек сам DEK, потребуется полное перешифрование данных: окно и нагрузку планируйте заранее, а не в момент инцидента.

Типичные ошибки и чек-лист перед продом

Антипаттерны, которые чаще всего приводят к инцидентам: swap в открытом виде (plaintext swap), потерянный заголовок LUKS, ключи в git, самоподписанные сертификаты в проде, работающие TLS 1.0 и 1.1, слабый пароль от бэкап-репозитория, шифрование без теста восстановления и ротация раз в пятилетку. Каждый пункт проверяется за минуты: cryptsetup luksDump, openssl s_client, sshd -T, restic snapshots.

Чек-лист администратора: 12 пунктов перед продом

1. Все диски с данными зашифрованы: LUKS2 или ZFS native encryption.
2. Swap зашифрован или отключен, открытый swap недопустим.
3. Копия заголовка LUKS2 лежит на офлайн-носителе отдельно от сервера.
4. TLS 1.3 включен, сертификаты валидны, автопродление работает.
5. SSH принимает только ключи Ed25519, вход по паролю и root-логин по паролю отключены.
6. Удаленный доступ идет через WireGuard или OpenVPN, порт SSH закрыт от интернета.
7. Пароли пользователей хешируются Argon2id с параметрами не ниже 19 MiB и 2 итераций.
8. PII зашифрованы по схеме envelope encryption, DEK уникальны, KEK в KMS или Vault.
9. Ключи и секреты не лежат в git, в конфигах приложений и рядом с данными.
10. Бэкапы зашифрованы, пароль от репозитория в Vault, копия есть вне офиса.
11. Ротация ключей и сертификатов идет по расписанию, а не после инцидента.
12. Тест восстановления из бэкапа пройден на отдельной машине за последние 90 дней.

Начните с инвентаризации: что уже зашифровано, где лежат ключи, когда последний раз проверялось восстановление. Закрытие трех пунктов из чек-листа обычно дает больше эффекта, чем покупка нового HSM.