Шифрование прикладных данных в .NET: ключи, ротация и поиск

Если приложение хранит почтовые адреса, токены, заметки или номера документов, одной галочки в облачной консоли мало. Бэкапы уходят на ноутбуки, снапшоты живут на файловых ресурсах, а база часто знает о данных больше, чем стоит.

Разработчику нужен не лозунг про «защищённое хранилище», а понятная схема: что именно шифровать, где держать ключи, как пережить их замену и что делать с поиском по полям. Именно на этом месте простая идея ломается об эксплуатацию.

Что произошло

Разбор в исходной статье — о прикладном шифровании данных в .NET на уровне отдельных свойств и колонок. Автор показывает, почему шифрование «до базы» решает только часть задачи, и почему в реальном продукте важнее не сам алгоритм, а вся цепочка вокруг него.

Речь идёт о типичной ситуации: данные нужно скрыть от кражи бэкапа или снапшота, но при этом приложению по-прежнему надо их читать, обновлять и искать. Для этого одного AES недостаточно — нужен нормальный механизм управления ключами, а не один секрет на все случаи жизни.

Как это работает на практике

В основе подхода — конвертное шифрование: сам payload шифрует быстрый симметричный алгоритм, а отдельный ключ для него защищает второй слой. В статье автор использует AES-256-GCM для данных и RSA-OAEP-SHA-256 для обёртки ключа — это типичная промышленная схема, где каждый инструмент делает свою работу.

Здесь важна не только конфиденциальность, но и целостность. GCM добавляет тег аутентификации, поэтому подмена шифротекста не проходит незаметно. Это заметно лучше старых режимов вроде CBC, где легко получить незакрытую дыру в проверке целостности.

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

Почему key chain важнее одного ключа

Одна из ключевых мыслей материала — ключ надо уметь менять без боли. Если один секрет отвечает за всё, любая ротация превращается в миграцию с риском потерять доступ к части записей.

Поэтому в реальных системах используют key chain: набор ключей с метаданными о том, какой из них шифровал конкретную запись. Тогда новые данные пишутся уже с актуальным ключом, а старые можно расшифровать во время переходного периода. Это снижает операционный риск и убирает жёсткую зависимость от одного артефакта.

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

Поиск по зашифрованным данным: удобство против безопасности

Самая неприятная часть — поиск. Если поле зашифровано честно, база не может просто так сравнить его со строкой запроса. Отсюда компромисс: либо искать по открытым данным до шифрования, либо хранить дополнительный индекс, либо строить отдельный безопасный механизм поиска.

Автор честно показывает, что универсального и дешёвого решения тут нет. Чем удобнее поиск, тем больше утечек структуры вы рискуете получить. Поэтому для email, токенов и идентификаторов обычно выбирают узкие, заранее продуманные сценарии, а не «поиск по всему подряд».

Для команд, которые работают с удалёнными базами и чужими сетями, полезно держать в голове и другой слой защиты — трафик и рабочую среду. В таких сценариях средство для защищённого подключения удалённой команды часто рассматривают как дополнительный барьер для доступа к рабочим сервисам и админкам через открытые точки подключения.

Кого это затрагивает и к чему ведёт

Материал в первую очередь полезен разработчикам .NET, архитекторам и тем, кто отвечает за хранение персональных данных. Но по сути проблема шире: любая команда, которая хранит чувствительные поля в базе, рано или поздно упирается в те же вопросы.

Если схема сделана плохо, потом всплывают одни и те же симптомы: неудобная ротация, ручная перекодировка старых записей, сломанный поиск, путаница с ключами и слабое разделение ролей. Если всё спроектировать заранее, система переживает замену ключей без паники и без простоя.

Отдельно стоит помнить: никакое шифрование колонки не спасает, если у атакующего есть полный контроль над сервером приложения. Поэтому криптография должна идти вместе с правами доступа, журналированием, защитой секретов и нормальной изоляцией инфраструктуры.

Что делать читателю прямо сейчас

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

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

Практический чек-лист

• Проверьте, какие поля в вашей базе действительно чувствительные.
• Убедитесь, что шифрование идёт до записи в БД, а не только на уровне диска.
• Уточните, где хранится ключ и кто может к нему обратиться.
• Опишите ротацию ключей заранее, а не «после инцидента».
• Отдельно решите, как вы будете искать по зашифрованным данным.
• Ограничьте доступ к процессу приложения и секретам на стороне инфраструктуры.
• Проверьте, не раскрывают ли бэкапы и снапшоты лишнее.
• Для удалённой работы и администрирования используйте дополнительный слой защиты канала.