Неделю назад мир узнал про Heartbleed – уязвимость в OpenSSL, которая позволяла читать память сервера блоками по 64 КБ. Многие администраторы обновили библиотеку и закрыли вопрос. Это ошибка. Патч останавливает утечку, но не отменяет того, что уже утекло. Приватные ключи, сессионные cookie, логины и пароли могли покинуть периметр задолго до того, как вы накатили исправление. После Heartbleed безопасность измеряется не версией OpenSSL, а тем, успели ли вы сменить все секреты, которые библиотека держала в памяти.

Почему патча недостаточно

Уязвимость существовала с декабря 2011 года. Эксплуатация не оставляет следов в логах – вы не докажете, что вас не читали. Значит, исходить нужно из худшего: приватный ключ TLS-сертификата скомпрометирован. А вместе с ним – всё, что им защищалось.

Ротация после Heartbleed – это не одна операция, а цепочка в строгом порядке:

  1. Обновить OpenSSL до 1.0.1g (или собрать без heartbeat-расширения).
  2. Сгенерировать новые ключевые пары – старые ключи переиспользовать нельзя.
  3. Перевыпустить сертификаты на новых ключах через удостоверяющий центр.
  4. Отозвать прежние сертификаты, внести их в CRL.
  5. Сменить пароли, токены API и сессионные секреты приложений.

Порядок важен. Если перевыпустить сертификат на старом ключе – вы получите новую бумагу со скомпрометированным секретом внутри. Если сменить пароли до патча – новые утекут так же, как старые.

Что это значит для госсектора и юридически значимых систем

Для систем, где сертификат подтверждает не «шифрование», а личность, цена компрометации ключа выше. В контурах юридически значимого документооборота приватный ключ – это подпись организации. Его утечка ставит под сомнение целостность всего, что подписано за период уязвимости.

Здесь чистая техническая ротация не закрывает вопрос. Нужно ответить на регуляторные:

  • Какие документы подписаны в окне компрометации и сохраняют ли они юридическую силу?
  • Требуется ли уведомление контрагентов и удостоверяющего центра?
  • Хранились ли ключи квалифицированных подписей в памяти уязвимого процесса или только в защищённом носителе (токен, HSM)?

Последний пункт – главный аргумент в пользу аппаратного хранения ключей. Ключ, который никогда не покидает токен, Heartbleed не достанет. Сервисы, где приватный ключ лежит в файле рядом с веб-сервером, пострадали полностью.

Как выстроить управление секретами на будущее

Heartbleed – повод не для разовой пожарной ротации, а для процесса. Минимальный набор практик:

  • Инвентаризация секретов. Вы не отзовёте то, о чём не знаете. Реестр ключей, сертификатов, сроков и владельцев – основа.
  • Плановая ротация. Срок жизни ключа задаётся заранее, а не инцидентом. Год для TLS, меньше – для сервисных токенов.
  • Разделение по контурам. Один скомпрометированный ключ не должен открывать доступ ко всему.
  • Аппаратная защита для критичных ключей. HSM и токены выводят приватный ключ из досягаемости уязвимостей приложения.
  • Готовый план отзыва. Заранее прописанная процедура превращает аврал в чек-лист.

Прошедший год показал, что инфраструктурные риски смещаются от периметра внутрь – мы писали об этом в итогах 2013-го. Heartbleed подтвердил тренд: уязвима оказалась не сеть, а сама криптобиблиотека, которой все доверяли по умолчанию.

Вывод

Обновить OpenSSL – это первый шаг, а не последний. Реальная защита после Heartbleed – это полная ротация секретов в правильном порядке и процесс, который делает следующую ротацию рутиной, а не катастрофой. Аудит ключевого хозяйства, перевыпуск сертификатов и выстраивание управления секретами – часть информационной безопасности, которую стоит закладывать в инфраструктуру заранее.