Шифрование делят на два контура: данные в покое (at rest) – то, что лежит на дисках, в бэкапах и таблицах СУБД, и данные при передаче (in transit) – трафик между клиентом, приложением и сервером. Это не «продвинутая защита», а базовая гигиена. Если хоть один контур открыт, остальные меры по периметру теряют смысл: достаточно украденного бэкапа или перехваченной сессии в публичном Wi-Fi. Разбираем, что закрывать в первую очередь и где проходят границы ответственности.

Данные при передаче: TLS по умолчанию

Любой обмен, который покидает доверенный сегмент сети, идёт через TLS. Для веб-приложений это означает HTTPS на всех страницах, а не только на форме входа: сессионная cookie, перехваченная на «безобидной» странице по HTTP, открывает аккаунт целиком. Включайте принудительный редирект на HTTPS и заголовок Strict-Transport-Security, чтобы браузер не пытался ходить по открытому порту.

Практические требования на сегодня:

  • Отключите SSLv2 и SSLv3, используйте TLS 1.0 и выше; готовьте инфраструктуру к TLS 1.2.
  • Закрывайте слабые шифры (RC4, экспортные наборы), приоритет – AES.
  • Включайте forward secrecy (наборы с ECDHE/DHE): даже компрометация серверного ключа не вскроет ранее записанный трафик.
  • Следите за сроком и цепочкой сертификатов, не оставляйте самоподписанные на внешних сервисах.

Свежие новости о масштабах перехвата трафика – повод не откладывать. Шифрование канала не спасает от закладок на сервере, но снимает целый класс пассивных атак на линии связи.

Данные в покое: диски, СУБД и бэкапы

Здесь типичная ошибка – защитить «боевую» базу и забыть про копии. Утечка чаще уходит через бэкап на сменном носителе, дамп для разработчиков или украденный ноутбук администратора.

Минимальный набор:

  • Шифрование носителей на серверах и рабочих станциях с доступом к чувствительным данным.
  • Шифрование на уровне СУБД (прозрачное шифрование табличных пространств или отдельных полей с ПДн).
  • Шифрование архивов бэкапов и контроль того, где хранятся ключи к ним.
  • Для систем с персональными данными – сертифицированные средства криптозащиты, как того требует регулятор для соответствующего класса ИСПДн.

Отдельно – управление ключами. Ключ, лежащий в открытом виде рядом с зашифрованными данными, превращает всю схему в формальность. Ключи хранят отдельно, ротация и доступ к ним протоколируются.

Где это особенно критично

Системы, завязанные на государственную идентификацию, обрабатывают данные, утечка которых бьёт по гражданину напрямую. Интеграции через ЕСИА и сценарии входа по универсальной электронной карте гоняют идентификаторы и атрибуты пользователя и канал, и хранилище должны быть зашифрованы без исключений. Здесь шифрование не выбор архитектора, а требование к классу системы.

Вывод

Два контура – at rest и in transit – закрываются проверенными инструментами: TLS с актуальными шифрами на канале, шифрование носителей, СУБД и бэкапов на хранении, отдельное управление ключами. Это не разовый проект, а режим эксплуатации: сертификаты истекают, наборы шифров устаревают, носители уезжают за периметр. Оба контура проектируются под требования регулятора в рамках информационной безопасности всей системы – от модели угроз до выбора сертифицированных средств криптозащиты.