Как ротация ключей шифрования ограничивает ущерб при компрометации одного ключа?
Ротация ключей ограничивает ущерб по времени и объёму данных только тогда, когда старый ключ перестают использовать, ограничивают его доступ и при необходимости перешифровывают данные. Если скомпрометированный ключ продолжает расшифровывать старые данные, сама выдача нового ключа уже не защищает эти данные.
Ротация не устраняет компрометацию задним числом: атакующий может сохранить ранее полученный ключ и расшифровать все доступные ему шифротексты, защищённые этим ключом. Поэтому ротация должна быть частью управления жизненным циклом ключей, а не единственной мерой защиты.
В ранних системах один ключ нередко использовался длительное время для большого объёма данных. Компрометация такого ключа превращала весь накопленный шифротекст в потенциально раскрытые данные и усложняла отзыв доступа.
Ротация появилась как способ уменьшить криптографический и операционный радиус поражения. Она также помогает соблюдать требования к сроку жизни ключей, разделять области применения ключей и проводить контролируемую замену без остановки всей системы.
Предположим, ключ использовался годами для шифрования записей, резервных копий и экспортов. После его утечки злоумышленник получает возможность расшифровать не только будущие, но и все доступные старые данные, если они остаются защищёнными тем же ключом.
Неверная ротация создаёт ложное ощущение безопасности. Например, новый ключ можно выпустить, но оставить старый активным для расшифровки без ограничения срока или не перешифровать наиболее чувствительные данные. В этом случае новая запись может быть защищена лучше, а исторические данные останутся уязвимыми.
Сначала определяют область действия ключа: какие данные, резервные копии и операции им защищаются. Затем выпускают новый ключ, переводят новые операции на него, сохраняют старый ключ только для контролируемой расшифровки уже существующих данных и планируют их перешифрование.
Чтобы ротация действительно ограничивала последствия, нужны несколько мер:
Важно различать ключ шифрования данных и ключ управления ключами. При envelope encryption данные шифруются ключом данных, а тот оборачивается ключом управления. Ротация ключа управления обычно меняет только обёртку и не защищает данные, если скомпрометирован сам ключ данных. Для ограничения раскрытия нужно ротировать или заменить ключи данных и перешифровать соответствующие записи.
Ротация имеет компромиссы. Полное перешифрование больших хранилищ требует ресурсов, увеличивает нагрузку на систему и усложняет восстановление после сбоя. Поэтому часто используют поэтапную миграцию: новые данные шифруются новым ключом, старые обрабатываются партиями, а версия ключа хранится рядом с шифротекстом как служебный идентификатор, не раскрывающий сам ключ.
Ротация также не заменяет защиту хранилища ключей, разграничение доступа и безопасную обработку резервных копий. Если злоумышленник может получить новый ключ через тот же скомпрометированный путь, регулярная смена ключей лишь увеличивает операционные расходы.
Сервис хранит персональные данные в базе. Все записи за несколько лет зашифрованы одним ключом, а резервные копии автоматически создаются в отдельном хранилище. После компрометации учётной записи приложения команда просто выпускает новый ключ, но оставляет старый доступным для всех операций чтения.
Рассматривались два варианта. Первый — только заменить ключ: это быстро и почти не влияет на доступность, но не защищает уже сохранённые данные и не устраняет доступ к старому ключу. Второй — немедленно перешифровать всю базу: он лучше ограничивает раскрытие, но может создать длительную нагрузку, конфликтовать с резервным копированием и усложнить откат.
Выбрано поэтапное решение. Доступ к скомпрометированному ключу отозвали, новые записи стали шифроваться новым ключом, а существующие записи перешифровывались пакетами с контролем целостности и журналированием прогресса. После завершения миграции старый ключ удалили из активного контура, проверили резервные копии и ограничили их доступ отдельной ролью.
Такой подход не делает уже скопированные злоумышленником данные безопасными, но предотвращает дальнейшее раскрытие через старый ключ и сокращает объём данных, доступных при повторной компрометации одного ключа.
Нет, если скомпрометирован именно ключ данных. Замена ключа управления обычно означает повторное шифрование только ключа данных его новой обёрткой. Получив старый ключ данных, атакующий всё ещё сможет расшифровать сами данные, поэтому потребуется заменить ключ данных и перешифровать шифротексты либо применить другой механизм, делающий старый ключ непригодным.
Если скомпрометирован только ключ управления, его ротация и повторная обёртка ключей данных могут быть достаточны для защиты будущего доступа через систему управления ключами. Однако нужно отдельно проверить, не успел ли атакующий получить или экспортировать ключи данных.
Обычно нет. Пока существуют данные, резервные копии или журналы, зашифрованные старым ключом, немедленное удаление может сделать их невосстановимыми и нарушить работу системы.
Безопаснее перевести старый ключ в режим только расшифровки, ограничить его доступ, завершить миграцию и проверить восстановление из резервной копии. После этого ключ можно уничтожить или поместить в строго контролируемый архив согласно требованиям хранения и восстановления.
Каждый шифротекст должен иметь явную версию или идентификатор ключа. Сервис начинает шифровать новые данные текущим ключом, но временно умеет расшифровывать разрешённые старые версии. Фоновый процесс перешифровывает данные партиями, а результат проверяется до удаления старой версии.
Нужно предусмотреть идемпотентность, повтор после сбоя, контроль целостности и согласованность с резервными копиями. После достижения нулевого или согласованного остатка старых шифротекстов чтение старой версии отключают, а доступ к старому ключу отзывают. Такой процесс снижает простой, но требует более сложной логики миграции и тщательного мониторинга.