Архив договоров успешно скопировали на резервную площадку. Файлы на месте, контрольные суммы совпадают. При восстановлении выяснилось, что ключ остался в недоступной учётной записи основного облака. Компания сохранила все данные и всё равно не может прочитать ни одного документа.
Управление ключами нужно не только для предотвращения утечек. Оно определяет, кто сможет пользоваться зашифрованными данными сегодня и кто сумеет восстановить их через несколько лет. Здесь разберём ключи шифрования хранимых данных. У ключей подписи и других криптографических задач свои требования; объединять их жизненные циклы одним расписанием замены нельзя.
Сначала определить, от чего защищаем документы
Шифрование диска может защищать от чтения снятого носителя. Оно не обязательно мешает приложению, которое законно запрашивает данные из работающей базы. Если злоумышленник получил полномочия этого приложения, механизм расшифрования способен добросовестно обслужить и его.
Поэтому место шифрования выбирают по угрозе, а права на чтение проектируют отдельно. Такой порядок предлагает руководство OWASP по криптографическому хранению. Требование «включить шифрование» неполно, пока неизвестно, какую копию могут похитить и кто сохраняет возможность её открыть.
Для договоров полезно перечислить рабочую базу, вложения, выгрузки, резервные копии и временные файлы. Защищённая база не компенсирует открытый экспорт, который каждый вечер отправляют в другой каталог. Не нужно шифровать всё одним способом, но пропущенные копии должны быть видны.
Зашифрованный ключ рядом с файлом — не обязательно ошибка
Распространённый подход — шифровать документ ключом данных, а сам ключ данных защищать другим ключом, управляемым KMS. Это называют envelope encryption. Зашифрованную, а не открытую копию ключа данных можно хранить рядом с документом. Для чтения потребуется разрешённая операция раскрытия этого ключа. Схема описана в документации AWS KMS.
Поэтому вопрос «лежит ли ключ рядом» слишком груб. Важно, в каком виде он находится и что требуется для его использования. Незашифрованный ключ данных в той же доступной папке и защищённая ключом KMS копия — разные ситуации.
Приложению нужны права на конкретную операцию и область данных, а не управление всей системой ключей. Например, сервис загрузки и сервис просмотра могут иметь разные обязанности. Право менять политику ключа тоже существенно: администратор, способный сам выдать себе расшифрование, не становится независимым контролёром только из-за названия роли.
Ротация не переписывает прошлое
Под заменой ключа могут понимать выпуск нового ключевого материала, переключение приложения на другой ключ или повторное шифрование данных. Это не взаимозаменяемые действия. Например, ротация в AWS KMS не перешифровывает существующие данные и не заменяет ранее выданные ключи данных. Прежний материал сохраняется для необходимого расшифрования.
Если атакующий уже получил документ и соответствующий незашифрованный ключ данных, последующая административная замена не отберёт эту возможность. Новый ключ может защищать будущие записи. Для существующих данных требуется отдельное решение, а похищенную копию невозможно заставить обновиться вместе с нашей системой.
В плане перехода нужно указать, какие данные остаются на старом ключе, что будет преобразовано и как проверить чтение обеих версий. Нельзя удалить прежний ключ сразу после удачной записи нового документа: старые договоры и резервные копии ещё могут от него зависеть.
Удаление — не более решительная версия отключения
Отключение ключа часто можно отменить. Уничтожение необходимого ключевого материала может сделать данные невосстановимыми. AWS отдельно предупреждает о необратимости удаления и предлагает сначала проверить, действительно ли ключ больше не нужен.
Нужен учёт зависимостей: какие наборы данных и какие поколения копий используют ключ. Отсутствие недавних обращений не доказывает ненужность: архивный договор могут впервые открыть после долгого перерыва. Политика хранения должна согласовывать срок жизни документов и возможность их прочитать.
Уничтожение ключа иногда используют как часть удаления данных. Но это работает лишь в пределах проверенной схемы: нет других доступных ключевых копий, открытых экспортов или иных способов чтения. Нельзя обещать исчезновение всех сведений о клиенте на основании удаления одной записи в KMS.
Почему один экземпляр работает без KMS, а другой — нет
Приложение могло уже получить ключ данных и сохранить его в памяти. Тогда часть чтений продолжится даже после потери связи с KMS, а новый экземпляр не сможет получить нужный материал. Это также влияет на эффект отзыва разрешений. Недоступность сервиса и немедленная невозможность любого расшифрования — разные события.
Кэширование криптографического материала требует ограничений по сроку и использованию. Оно может уменьшать число обращений, но расширяет время присутствия незашифрованных ключей в процессе. В AWS Encryption SDK это отдельный механизм с порогами безопасности, а не рекомендация хранить ключи без срока ради скорости.
Испытание должно включать новый запуск, чтение старого документа и запись нового при недоступности зависимости. Сервис обязан отличать временную невозможность расшифровать файл от отсутствия самого файла. Автоматически создавать пустую замену в такой ситуации особенно опасно.
Восстановление заканчивается чтением документа
У резервной площадки должны быть разрешённый путь к нужным ключам, совместимый способ расшифрования и доступ сотрудников, выполняющих восстановление. Они не обязаны иметь возможность скачать сам корневой ключ: конкретная услуга может её не предоставлять. Нужно заранее проверить поддерживаемый способ резервирования или переноса.
Для архива договоров возьмите несколько поколений документов и копий. Восстановите их в согласованной среде, прочитайте под разрешённой учётной записью и убедитесь в отказе лишней. Затем проверьте отключение тестового ключа и возврат доступа, не экспериментируя с необратимым удалением рабочих ключей.
После этого полезно зафиксировать владельца ключа, область применения, права изменения и условия завершения его использования. Для небольшой системы подходящая управляемая услуга может быть разумнее собственного криптографического хозяйства. Но вопрос о чтении старого договора всё равно останется у компании, а не у кнопки «шифрование включено».