Шифрование данных: в состоянии покоя и в передаче
По мере роста объема и критичности персональных данных в организациях становится необходимым не только хранить данные безопасно, но и передавать их по сетям таким образом, чтобы никто кроме уполномоченных получателей не получил доступ к содержимому, не исказил его и не мог доказать факт манипуляции. Эта глава посвящена шифрованию данных в состоянии покоя (at rest) и в передаче (in transit): теории, методологии, практические решения (open-source и российские), а также рискам и ограничениям внедрения в рамках Data Governance, аудита и соответствия требованиям закона.
- Что такое шифрование и зачем оно нужно в Data Governance?
- Основные термины: шифр, ключ, симметричное и асимметричное шифрование, алгоритмы, режимы работы, AEAD, интегритет и подлинность.
- Разделение задач: шифрование данных на диске и в базах данных (покой), шифрование каналов передачи и межсервисного взаимодействия (передача).
Ключевые понятия:
- Шифр (cipher) и ключ (key): защитная пара, на основе которой преобразуется открытая информация в недоступную.
- AES, ChaCha20-Poly1305 — наиболее применяемые симметричные алгоритмы для данных в покое и в транзите.
- TLS/SSL — протокол защищенной передачи данных в сети.
- KEK и DEK — ключ верхнего уровня (Key Encryption Key) и ключ данных (Data Encryption Key).
- KMS и HSM — системы управления ключами и аппаратные хранилища для ключей.
- Модель угроз, жизненный цикл ключа, принципы минимальных привилегий и криптоагильности.
Основные принципы шифрования
- Конфиденциальность: только уполномоченные стороны могут прочитать данные.
- Целостность и подлинность: гарантии того, что данные не изменены и что отправитель действительно тот, за кого себя выдает.
- Аутентичность и неотказуемость: возможность доказать, что сообщение было создано конкретным участником.
Симметричное vs асимметричное шифрование
- Симметричное (например, AES): один ключ для шифрования и расшифрования. Быстро, подходит для больших объемов данных. Ключи требуют безопасного распределения.
- Асимметричное (например, RSA, ECDSA, EdDSA): пара ключей — открытый и закрытый. Хорошо для обмена ключами и цифровой подписи, но медленнее для больших данных.
- AEAD (Authenticated Encryption with Associated Data): обеспечивает конфиденциальность и целостность одним механизмом. Примеры: AES-GCM, ChaCha20-Poly1305.
Режимы шифрования
- AES-GCM и ChaCha20-Poly1305 — стандартные AEAD-режимы с хорошей производительностью и защитой от некоторых реентропий.
- CBC, CFB — устаревшие режимы, требуют дополнительных мер по обеспечению целостности.
- Итог: для новых проектов предпочтение AES-GCM или ChaCha20-Poly1305.
Управление ключами (Key Management)
- Жизненный цикл ключа: генерация → хранение → использование → ротация/архивация → вывод из эксплуатации.
- KEK и DEK: данные обычно шифруются DEK, который сам шифруется KEK в KMS/HSM.
- Ключи не должны храниться в открытом виде и должны подвергаться регулярной ротации.
- Резервное копирование ключей и доступ к ним: строгие политики доступа, разделение обязанностей, аудит.
Шифрование данных в покое
- Дисковое шифрование (LUKS/dm-crypt в Linux, BitLocker в Windows, FileVault в macOS).
- Шифрование баз данных и файловых систем: TDE (Transparent Data Encryption) в базах данных, шифрование столбцов, шифрование на уровне файловой системы.
- Архивы и резервные копии: шифрование резервов и копий, управление ключами для резервного хранения.
Шифрование данных в передаче
- TLS 1.2/1.3: защита каналов между приложениями, веб-серверами и прокси.
- TLS-сертификаты и PKI: доверенные цепочки, сроки действия, обновления.
- М mutual TLS (mTLS): аутентификация обеих сторон, широко применяется в микросервисной архитектуре.
- Важность настройки: современные шифры, отключение устаревших протоколов, HSTS, OCSP stapling.
Соответствие регуляторным требованиям
- 152-ФЗ и локализация данных в РФ: требования к защите персональных данных, контроль доступа, аудит и возможность проведения мониторинга.
- GDPR и другие законодательства: требование защиты данных, управление ключами, уведомления об утечках.
- PCI DSS, HIPAA и другие отраслевые стандарты: требования к шифрованию как частью контроля доступа и мониторинга.
- Важность крипто-агильности и документирования процессов — возможность обновлять алгоритмы без прерывания сервисов.
Измерение и оценка рисков
- Оценка риска утечки ключей, неправильной конфигурации TLS, ошибок миграции ключей.
- Риски производительности: крипто-операции требуют ресурсов, и могут повлиять на латентности.
- Риски регуляторного non-compliance в случае отсутствия процедуры управления ключами.
- Возможность резервирования: резервное копирование ключей, хранение копий в разных зонах доступности и в разных средах (он-премис/облако).
Практические примеры
1) Примеры и сценарии шифрования в покое (data at rest)
Дисковое шифрование на Linux (LUKS/dm-crypt)
- Цель: защитить данные на физических устройствах при потере устройства или кражи.
-
Основные команды:
sudo cryptsetup luksFormat /dev/sdb1 sudo cryptsetup luksOpen /dev/sdb1 data-disk sudo mkfs.ext4 /dev/mapper/data-disk - Замечания: хранение ключей в отдельном хранилище; план ротации; забытые ключи — потеря данных.
Технические строки в базах данных (TDE)
- Пример: SQL Server TDE, Oracle TDE, MySQL InnoDB Encryption.
- Принцип: данные хранятся зашифрованными на диске; ключи управляются через KMS/HSM.
Шифрование резервных копий
- Алгоритмы: AES-256-GCM, шифрование на уровне архива.
- Ключи: отдельное ключевое хранилище, ограниченный доступ к резервным копиям.
2) Примеры и сценарии шифрования в передаче (data in transit)
TLS в веб-серверах (Nginx/Apache)
- Конфигурация TLS 1.3, сильные наборы cipher, включение HSTS и OCSP stapling.
-
Пример конфигурации Nginx (фрагмент):
ssl_protocols TLSv1.3 TLSv1.2; ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; ssl_prefer_server_ciphers off; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Мультируемклиентское TLS (mTLS) в микросервисной архитектуре
- Использование SPIFFE/SPIRE или Istio для автоматизации выдачи сертификатов между сервисами.
- Пример конфигурации Istio: включение мTLS в全-модульной сетке.
Пример с OpenSSL: создание самоподписанного сертификата (для тестирования)
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
3) Практические примеры (open-source и российские решения)
Open-source решения
- dm-crypt/LUKS: опыт на Linux-дисках, прозрачное шифрование файловой системы.
- OpenSSL/GnuTLS: создание сертификатов, тестирование TLS-соединений.
- HashiCorp Vault: управление секретами и шифрование полей в проектах через envelope encryption.
- OpenSSH: шифрованный туннель, SSH-ключи, доверие к серверам.
Российские решения (образцы)
- КриптоПро CSP/КриптоПро ЭС: реализация PKI и криптографических сервисов под требования регуляторов РФ, включая работу с ЭП, криптокалитками и сертификацией.
- Вендоры и решения для локальных сегментов: интеграция с 152-ФЗ, хранение ключей в аппаратных средствах (СКЗИ), поддержка отечественных криптоалгоритмов и сертифицированных реализаций.
- Практическая рекомендация: для критичных сервисов рассмотреть совместное использование отечественных криптоаппаратов и зарубежных стандартов, чтобы обеспечить совместимость и соответствие местным требованиям.
| Технология | Назначение | Преимущества | Ограничения |
|---|---|---|---|
| LUKS/dm-crypt | Шифрование дисков | Простота внедрения, прозрачность | Ключи на сервере, миграции требуют планирования |
| AES-GCM / ChaCha20-Poly1305 | AEAD шифрование | Конфиденциальность + целостность, высокая производительность | Требуется управление ключами |
| TLS 1.3 | Защита канала | Современный протокол, упрощенная конфигурация | Требуется сертификат, обновления сертификатов |
| KMS (облачные/локальные) | Управление ключами | Централизованное управление, аудит | Риски при потере доступа к KMS, зависимость от поставщика |
| КриптоПро CSP | РФ-совместимое ПКИ/Криптографические сервисы | Соответствие 152-ФЗ, поддержка отечественных криптоалгоритмов | Обновления и интеграции требуют специфических изменений в ПО |
4) Примеры кода и конфигураций
Пример Python-кода для симметричного шифрования файла (AES-256-GCM) и хранения шифрованного контента вместе с associated data:
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
key = os.urandom(32) # 256-bit ключ
aesgcm = AESGCM(key)
data = b"Очень чувствительная информация"
aad = b"контекст_данных"
nonce = os.urandom(12)
ciphertext = aesgcm.encrypt(nonce, data, aad)
# хранить (nonce, aad, ciphertext) безопасно
print(nonce, ciphertext)
Пример конфигурации TLS на Nginx (TLS 1.3, современные cipher suites):
server {
listen 443 ssl;
ssl_certificate /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/private/server.key;
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains" always;
}
Пример конфигурации Vault (envelope encryption сценарий)
# Включение секрета
vault secrets enable -version=2 transit
# Создание ключа
vault write transit/keys/my-data-key type=aes256-gcm96
# Шифрование данных
cipher_text=$(echo -n 'secret' | vault write -field=cipher_text transit/encrypt/my-data-key plaintext=@-)
Команды для LUKS на Linux
sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup luksOpen /dev/sdb1 cryptdata
sudo mkfs.ext4 /dev/mapper/cryptdata
Пример модуля Istio для mTLS (упрощенно)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICT
5) Российские решения и регуляторное соответствие
- Применение КриптоПро CSP и связанных продуктов для PKI, подписания документов и защиты данных в рамках 152-ФЗ.
- Внедрение защитного слоя на уровне файловых систем, баз данных и сетей с использованием отечественных криптокачественных компонентов.
- Важно: для проектов, работающих с персональными данными граждан РФ, необходимо учитывать требования локализации и аудита доступа к данным, а также возможность проведения криптоаудитов внутри организации и по запросу регуляторов.
Архитектура управления ключами
- Разделение обязанностей: хранение ключей в KMS/HSM отдельно от данных, доступ к которым ограничен.
- Механизмы ротации ключей: периодическая смена KEK и DEK без прерывания сервисов.
- Аутентификация и аудит: журналы доступа к ключам, мониторинг действий операторов.
- Резервное копирование ключей: хранение резервных копий в изолированных зонах, географическое разделение.
Архитектура шифрования в микросервисной среде
- Использование мTLS для преодоления доверительных границ между сервисами.
- Хранение секретов (ключей, сертификатов) в секрет-менеджерах (Vault, Kubernetes Secrets, AWS Secrets Manager, Yandex.Cloud KMS и т.д.).
- Применение envelope encryption: DEK шифруется KEK в KMS/HSM, данные шифруются DEK.
- Мониторинг и аудит: контроль за доступом к ключам, соответствие требованиям регуляторов.
Вопросы совместимости и миграций
- Обновление алгоритмов: крипто-агильность — возможность перехода на новые алгоритмы без утраты данных.
- Совместимость между средами: гибридная архитектура (часть сервисов в облаке, часть — on-premise) должна поддерживать единые ключи и политики.
- Резерв на случай потери KMS/HSM: план аварийного восстановления и резервного копирования ключей.
Риски и ограничения внедрения
- Производительность: крипто-операции требуют процессорного времени; необходимо планировать нагрузку и использовать аппаратное ускорение (AES-NI, HSM).
- Безопасность ключей: компрометация KEK/DEK приводит к утрате конфиденциальности данных.
- Конфигурационные ошибки: устаревшие или слабые протоколы TLS, неправильные режимы шифрования, неправильное управление сертификатами.
- Регуляторные ограничения: господствующие требования к локализации данных и аудиту, запреты на использование определенных стран-серверов/KMS без соблюдения локальных норм.
- Риск зависимости от поставщиков: в случае использования облачных KMS/CI/CD-инструментов — возможны задержки или смены политики.
- Сложности миграции: перенос ключей и секретов между окружениями требует хорошо продуманной стратегии.
Методы снижения рисков
- Применение AEAD-режимов, TLS 1.3, мTLS для сервисной сетки.
- Регулярная ротация ключей и автоматизированный аудит доступа к ключам.
- Разделение ролей, минимизация прав доступа к данным и ключам.
- Тестирование конфигураций шифрования в тестовой среде, затем постепенное внедрение в продакшн.
- Документация процессов и регулятивных требований.
Выводы
- Шифрование — один из базовых столпов безопасной архитектуры данных. Правильное применение шифрования в состоянии покоя и в передаче повышает уверенность в соблюдении требований Data Governance и регуляторных норм.
- Эффективная система шифрования требует не только выбора алгоритмов, но и грамотного управления ключами, прозрачной политики доступа, мониторинга и планирования миграций.
- Важно сочетать открытые (open-source) решения и отечественные (российские) решения в рамках единой архитектуры, чтобы обеспечить совместимость, прозрачность аудитов и соответствие требованиям регуляторов.
- Риски внедрения — неотъемлемая часть проекта. Успешная реализация достигается через крипто-агильность, контроль и документирование, а также через непрерывный процесс улучшения и соответствия.
FAQ (Вопросы и ответы)
1) В чем разница между данными в покое и данными в передаче?
- Данные в покое (data at rest) — это данные, сохраненные на носителях (диски, облако, базы данных). Шифрование предотвращает чтение данных без ключа.
- Данные в передаче (data in transit) — это данные, которые пересылаются по сетям. Шифрование защитывает содержимое и обеспечивает целостность в пути. TLS обеспечивает защиту канала, mTLS — защищает и аутентифицирует обе стороны.
2) Какие алгоритмы и режимы рекомендуется использовать по умолчанию?
- Рекомендуется использовать симметричное шифрование AES-256 в AEAD-режимах: AES-GCM или ChaCha20-Poly1305. Для передачи — TLS 1.3 с современными cipher suites. Для хранения ключей — централизованные KMS/HSM.
3) Что такое envelope encryption и зачем он нужен?
- Envelope encryption разделяет шифрование на два уровня: DEK (ключ данных) шифруется KEK в KMS/HSM. Это позволяет безопасно обрабатывать большие объемы данных и хорошо управлять ключами, не передавая их напрямую. Ключи данных могут вращаться отдельно от ключей хранения.
4) Какие существующие российские решения можно использовать для соответствия 152-ФЗ?
- КриптоПро CSP/КриптоПро ЭДО и сопутствующие сервисы, обеспечивающие PKI, криптографию и совместимость с отеческими криптоалгоритмами. Они поддерживают требования регуляторов РФ и обеспечивают безопасную подпись и шифрование в рамках 152-ФЗ. Важно сочетать с системами контроля доступа и аудитом.
5) Какие требования к аудиту и документации при внедрении шифрования?
- Необходимо фиксировать политики шифрования, жизненный цикл ключей, журналы доступа к ключам и шифрованным данным, политики обработки инцидентов, планы восстановления после сбоев, регламент обновления сертификатов и протоколов, а также периодические крипто-аудиты.
6) Какие риски связаны с миграцией ключей между средами?
- Риск потери доступа к ключам, несогласованность политик доступа, несовместимость версий ПО, прерывание сервисов, задержки в обновлениях. План миграции должен включать резервирование, тестирование и поэтапное внедрение.
7) Какие практики помогают снизить влияние шифрования на производительность?
- Аппаратное ускорение (AES-NI), использование AEAD-режимов, миграция на быстрые KMS/HSM, горизонтальное масштабирование служб, кэширование витрии ключей там, где это безопасно, и мониторинг производительности крипто-путей.
8) Как обеспечить защиту ключей в облаке?
- Использование облачных KMS/Secrets Manager, шифрование данных KEK, хранение ключей отдельно от данных, контроль доступа через IAM/AD, аудит и мониторинг доступа, регулярная ротация ключей.
9) Что важнее для государственных проектов с персональными данными: шифрование в покое или в передаче?
- Обе части критичны. Шифрование в покое защищает данные в хранилищах, а шифрование в передаче защищает при транспортировке между слоями архитектуры. В крупных проектах требуется комплексная стратегия: шифрование на всех уровнях, плюс управление ключами и аудит.
10) Какие шаги предпринять, чтобы начать внедрять шифрование в организации?
- Провести классификацию данных и определить требования к защите PII.
- Разработать политику управления ключами и доступами.
- Выбрать подходящие решения (open-source и/или российские).
- Разработать план миграции и тестирования.
- Реализовать TLS/мTLS для сервисов, LUKS/дисковое шифрование для критичных систем, TDE там, где требуется.
- Организовать аудит и мониторинг, обучить персонал, задокументировать процессы.
