Средняя стоимость утечки данных в 2023-2024 годах превысила $4.45 млн, причем шифрование данных в покое сокращает потенциальный ущерб в среднем на 25-30%. В корпоративном секторе ошибка в выборе алгоритма или метода управления ключами превращает криптографию в дорогой «декор», который не останавливает квалифицированного атакующего.
Шифрование At Rest: от TDE до файлового уровня
Для баз данных стандартом де-факто остается Transparent Data Encryption (TDE). Он работает на уровне страниц данных, обеспечивая производительность с потерей всего 3-7% CPU на современных процессорах с поддержкой AES-NI. Однако TDE бесполезен, если злоумышленник получил доступ к запущенной СУБД под учетной записью администратора — данные будут расшифрованы автоматически.
Альтернативой является Application-Level Encryption (ALE), где данные шифруются в приложении перед записью в БД. Это дает максимальную защиту, но увеличивает нагрузку на приложение и делает невозможным поиск по зашифрованным полям без использования сложных гомоморфных схем. Кейс: при переходе с TDE на ALE в финансовом секторе время отклика API увеличилось с 120 мс до 180 мс, но риск компрометации БД через SQL-инъекцию был нивелирован.
Экспертный вывод: для общих требований комплаенса (ФЗ-152, GDPR) достаточно TDE, но для критических полей (пароли, ключи, ПДн) необходимо внедрять ALE с разделением ролей доступа.
Выбор алгоритмов: AES-256 против ГОСТ и ChaCha20
В корпоративном секторе доминирует AES-256 в режиме GCM (Galois/Counter Mode), так как он обеспечивает одновременно конфиденциальность и целостность. Использование режима CBC сегодня считается ошибкой из-за уязвимости к атакам типа padding oracle. Для систем с низкой вычислительной мощностью (IoT, старый парк серверов) оптимален ChaCha20-Poly1305, который работает быстрее AES на устройствах без аппаратного ускорения.
В РФ обязательным остается использование ГОСТ 34.12-2018 (Кузнечик/Магма). Важный нюанс: производительность программных реализаций ГОСТ может быть в 2-4 раза ниже, чем у AES с аппаратным ускорением. Это требует закладывать дополнительные мощности при масштабировании инфраструктуры.
Экспертный вывод: используйте AES-256-GCM для всех внутренних процессов и ГОСТ только там, где этого требует регулятор. Избегайте AES-128 и любых режимов ECB — это архитектурный провал.
Защита In Transit: TLS 1.3 и mTLS
Переход на TLS 1.3 сократил время установления соединения (handshake) с двух раундов до одного, что снижает задержку на 10-40 мс. Главная ошибка внедрения — поддержка устаревших TLS 1.0/1.1 для «совместимости со старым софтом», что открывает двери для атак типа POODLE и BEAST. Внутри периметра предприятия стандартным должен стать mTLS (Mutual TLS), где и клиент, и сервер предъявляют сертификаты.
При внедрении mTLS в микросервисной архитектуре нагрузка на управление сертификатами растет экспоненциально. Без автоматизации (например, через HashiCorp Vault или Istio) срок жизни сертификата в 90 дней превращается в администрируемый хаос с регулярными простоями сервисов из-за просроченных ключей.
Экспертный вывод: полностью отключайте TLS ниже 1.2. Для внутреннего трафика между сервисами внедряйте mTLS — это единственный способ реализовать архитектуру Zero Trust на сетевом уровне.
Криптографический менеджмент: проблема хранения ключей
Хранение ключей шифрования в конфигурационных файлах или в той же БД, что и данные — критическая уязвимость. Практика показывает, что 60% утечек данных происходят из-за компрометации ключей, а не взлома самого алгоритма. Решением является использование HSM (Hardware Security Module) или KMS (Key Management Service). Стоимость аппаратного HSM начинается от $5 000 до $25 000 за модуль, что оправдано для крупных предприятий.
Ключевой метрикой здесь является ротация ключей. Рекомендуемый цикл для мастер-ключей — 1 год, для сессионных — от нескольких часов до суток. Ошибка многих компаний — отсутствие плана регенерации ключей при увольнении системного администратора, что заставляет их либо менять все ключи вручную (с простоем в несколько часов), либо оставлять доступ бывшему сотруднику.
Экспертный вывод: переходите на внешние KMS с автоматической ротацией. Если бюджет ограничен, используйте программные хранилища с шифрованием токенов, но никогда не храните ключи в открытом виде в коде или конфигах.
Вывод
Для построения надежной защиты данных в 2024 году следует выбрать связку AES-256-GCM для хранения (TDE + ALE для критических полей) и TLS 1.3 с mTLS для передачи. Избегайте самописных алгоритмов шифрования и хранения ключей внутри инфраструктуры приложений. Начинать нужно с аудита текущих сертификатов и внедрения KMS — без управления ключами любое шифрование становится формальностью, которая не защищает от реального взлома.