Выгрузка для аналитики обычно появляется незаметно: несколько таблиц из продовой базы, ПДн, телефоны, почты, история операций, пара служебных полей. Её кладут в облачное хранилище, включают шифрование галочкой, дают доступ роли и забывают. Через месяц те же данные уже лежат в тестовом контуре, резервной копии, отчёте для подрядчика и старом бакете.
На вопрос “кто может расшифровать данные?” часто нет короткого ответа. У бакета шифрование включено, у базы тоже, TLS на входе есть. Но непонятно, где появляется открытый текст, кто управляет ключом, кто может вызвать расшифровку, как ротируются ключи и что останется в журналах после спорной операции.
С данными неприятно то, что их нельзя откатить. Сервер пересоздали, маршрут закрыли, роль урезали. Утекшая база обратно не собирается. Поэтому защита данных в облаке начинается раньше первой выгрузки: с классификации, выбора схемы шифрования, управления ключами и понимания, где исходные значения вообще не нужны и могут быть заменены токенами.
Стратегии защиты данных
Классификация по чувствительности
Защиту данных нельзя начинать с выбора KMS или алгоритма. Сначала нужно понять, какие данные вообще лежат в системе и где они проходят. Иначе всё заканчивается одинаково: шифруют целый диск, ставят галочку в хранилище, а настоящие ПДн спокойно уезжают в логи, отладочные дампы и выгрузки для аналитики.Минимальная классификация для облака обычно выглядит так:
- публичные данные - можно хранить без специальных мер, но всё равно с контролем целостности и доступа;
- внутренние данные - конфигурации, отчёты, служебные таблицы, которые не должны уходить наружу;
- чувствительные данные - ПДн, платёжные данные, коммерческая тайна, секреты, токены, ключи;
- регулируемые данные - всё, что попадает под 152-ФЗ, PCI DSS, GDPR или внутренние требования заказчика.
Когда в схеме появляются ПДн, платёжные поля и выгрузки для аналитики, классификация перестаёт быть формальностью, комплаенс быстро упирается в конкретные таблицы, роли, журналы, сроки хранения и возможность доказать, где именно обрабатывались чувствительные данные.
Выбор метода защиты по типу данных
Для внутренних и служебных данных часто хватает шифрования на стороне облачного сервиса, строгих прав доступа и журналов операций. Это нормальный базовый слой для дисков, бакетов, баз и резервных копий. Он снижает риск при потере носителя, ошибке инфраструктуры или неправильном доступе к физическому уровню.Для ПДн, платёжных данных и секретов одного шифрования хранилища мало. Тут нужно смотреть, кто управляет ключами и где появляется открытый текст. Если приложение отдаёт данные в облако уже зашифрованными, провайдер видит только ciphertext. Цена - сложность в приложении, поиске, аналитике и восстановлении. За контроль приходится платить инженерной работой.
Для данных, которые нужны только как идентификатор, лучше использовать токенизацию. Например, сервису не всегда нужен настоящий номер карты или паспорта. Ему может хватить токена, который сохраняет связь с клиентом, но не раскрывает исходное значение. Тогда зона, где живут настоящие данные, становится меньше: отдельное хранилище токенов, отдельные права, отдельный аудит.
Для секретов и ключей нельзя использовать обычные таблицы, переменные окружения и конфиги в репозитории. Их место - в KMS или secret manager, с ограничением доступа по ролям и журналированием операций. Любая схема, где ключ лежит рядом с зашифрованными данными, ломает смысл шифрования. Это как повесить замок и оставить ключ под ковриком, только коврик называется config-prod.yaml.
Практическая логика выбора простая:
Шифрование данных в хранении
Шифрование на стороне сервиса
Это базовый слой, с которого обычно начинают. Облачный сервис сам шифрует диск, бакет, базу или резервную копию перед записью. Для эксплуатации это удобно: приложение не меняется, производительность предсказуемая, интеграция с KMS обычно уже есть.Такой вариант закрывает понятный набор рисков: доступ к физическому носителю, ошибки на уровне инфраструктуры, часть сценариев с утечкой снимков и резервных копий. Но у него есть важное ограничение: открытый текст всё равно появляется внутри сервиса. Если у атакующего есть доступ к приложению, базе или операции расшифровки через роль, одно шифрование хранилища его не остановит.
Для большинства внутренних систем это нормальный старт. Диски виртуальных машин, объектное хранилище, управляемые базы, файловые тома, снапшоты и бэкапы почти всегда должны жить именно в таком режиме по умолчанию. Ошибка здесь обычно не в выборе подхода, а в деталях: ключ общий на пол-окружения, доступ к расшифровке шире, чем нужно, или резервные копии шифруются уже другой схемой, про которую забыли.
Шифрование на стороне клиента
Здесь данные шифруются до отправки в облако. Провайдер хранит уже ciphertext, а контроль над расшифровкой остаётся ближе к приложению или отдельному защищённому сервису. Такой подход нужен там, где модель риска жёстче: чувствительные ПДн, платёжные данные, отдельные категории медицинских или финансовых сведений, данные с повышенными требованиями заказчика.Цена у этого подхода заметная. Поиск, сортировка, аналитика, дедупликация, индексация и часть интеграций становятся сложнее. Любая операция, которой нужен исходный текст, должна проходить через доверенный контур. Ошибки тоже становятся дороже: потеряли ключ - потеряли доступ к данным. Неправильно спроектировали ротацию - получили сложную миграцию на живой системе.
Поэтому client-side encryption стоит применять точечно. Это хороший выбор, когда важнее контроль над исходным текстом, чем удобство эксплуатации. Делать так “на всякий случай” для всех данных подряд обычно выходит дорого и неудобно.
Блочное и объектное шифрование
Шифрование на уровне диска закрывает носитель целиком. Оно удобно для виртуальных машин, блочных томов и части СУБД. Плюс в простоте: приложение о нём обычно вообще не знает. Минус в том, что после монтирования тома данные для системы уже открыты. Если атакующий получил доступ к хосту или процессу с нужными правами, сам факт шифрования тома ему почти не мешает.Шифрование на уровне объекта работает ближе к самим данным: файл, объект в бакете, запись, поле, отдельный секрет. Такой подход лучше подходит для объектного хранения, архивов, документов и сценариев, где нужно избирательно управлять доступом и ключами. Он даёт больше гибкости, но и больше инженерной работы.
Практически выбор выглядит так:
- диски, тома, виртуальные машины, снапшоты - шифрование на уровне носителя;
- бакеты, файлы, архивы, резервные копии - шифрование на уровне объекта;
- самые чувствительные поля внутри записи - отдельное прикладное шифрование, если этого требует модель риска.
Что выбирать на практике
Если нужен рабочий базовый контур, почти всегда начинают так:- включают шифрование для дисков, баз, бакетов и резервных копий;
- выносят ключи в KMS;
- разделяют роли на использование ключа и управление ключом;
- отдельно проверяют, как шифруются экспорты, журналы и временные выгрузки.
Отдельно стоит проверить не только продовую базу, но и всё, что живёт вокруг неё: неочищенные снапшоты облаков часто хранят те же ПДн, секреты и служебные артефакты, только уже вне привычной модели доступа и без внимания со стороны команды.
Шифрование при передаче данных
Данные могут быть зашифрованы в базе и бакете, но ехать по сети в открытом виде между балансировщиком, приложением, очередью и внутренним API. Для аудита часто пишут “используется HTTPS”. В эксплуатации важнее другое: где TLS завершается, кто проверяет сертификат и что происходит с трафиком дальше внутри контура.TLS 1.3 для внешних и внутренних API
TLS 1.3 стоит держать базовым профилем для внешних API, административных интерфейсов и внутренних сервисов, которые передают ПДн, токены, платёжные или служебные данные. Он убирает часть старого наследия из TLS-конфигураций и сокращает поверхность ошибок в согласовании соединения.Сам включённый TLS еще ничего не гарантирует. Нужно проверить три вещи:
- TLS не заканчивается слишком рано на балансировщике;
- клиент проверяет сертификат и имя узла;
- старые протоколы и слабые наборы шифров не оставлены “для совместимости”.
NGINX:
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_tickets off;
ssl_certificate /etc/tls/tls.crt;
ssl_certificate_key /etc/tls/tls.key;Внутренний трафик
Чаще всего хорошо защищён вход снаружи, а внутри всё держится на доверии к сети. Запрос дошёл до балансировщика по TLS, дальше до приложения пошёл открытым HTTP, потом приложение передало данные в соседний сервис, тот записал часть полей в очередь. В схеме всё “внутри VPC”, но для чувствительных данных это слабый аргумент.Тут обращаем внимание не на кластер целиком, а на конкретные потоки:
Если по этим цепочкам проходят ПДн, токены или платёжные данные, канал должен быть защищён до того места, где данные реально обрабатываются, а не только до внешнего входа.
mTLS между сервисами
Обычный TLS подтверждает сервер. mTLS добавляет проверку клиента: обе стороны предъявляют сертификаты, и сервис понимает, кто к нему подключается. Для внутренних API это важно, потому что IP в облаке и Kubernetes слишком быстро теряет смысл как идентификатор.В service mesh это обычно выносят из приложения в инфраструктурный слой. Например, в Istio строгий mTLS для namespace можно задать так:
YAML:
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: payments
spec:
mtls:
mode: STRICTУправление ключами в KMS
KMS нужен там, где ключи уже нельзя держать в конфиге, переменной окружения или таблице рядом с данными. Его задача - хранить ключевой материал, выдавать доступ к операциям шифрования и расшифровки, вести журнал обращений и поддерживать ротацию. Если приложение читает ключ из config-prod.yaml, шифрование держится на дисциплине вокруг этого файла.Что должен закрывать KMS
В Yandex KMS, AWS KMS и похожих сервисах базовая модель одна: есть ключ, его версии, политики доступа и операции над данными или ключами данных. В эксплуатации важнее не интерфейс облака, а ответы на несколько вопросов.Кто может управлять ключом? Кто может только шифровать? Кто может расшифровывать? Где видны операции использования ключа? Что произойдёт, если ключ ротировали, отключили или удалили?
Плохой вариант - один сервисный аккаунт читает данные, вызывает расшифровку, меняет политику ключа и управляет версиями. При компрометации такого аккаунта атакующий получает не обход шифрования, а штатный путь к открытому тексту.
Конвертное шифрование
Большие объёмы данных обычно не шифруют напрямую мастер-ключом из KMS. Для этого используют конвертное шифрование.Данные шифруются отдельным ключом данных - DEK. Сам DEK шифруется ключом из KMS - KEK. В хранилище лежат зашифрованные данные и зашифрованный DEK. При чтении приложение передаёт зашифрованный DEK в KMS, получает открытый DEK в память процесса, расшифровывает данные и затем убирает ключ из памяти настолько аккуратно, насколько позволяет среда выполнения.
Плюс такого подхода в масштабе. Один ключ KMS может защищать много DEK, а DEK можно привязать к объекту, файлу, записи, tenant или набору данных. При ротации мастер-ключа часто достаточно переобернуть DEK новым KEK, без полной перезаписи всего массива данных.
Ротация ключей
Ротация должна быть процессом, а не галочкой. Новая версия ключа должна использоваться для новых операций, старые данные должны оставаться читаемыми, пока не пройдёт переоборачивание DEK или перешифрование нужного набора.Опасный сценарий - удалить старую версию до проверки архивов, снапшотов, резервных копий и старых выгрузок. В облаке данные редко живут в одном месте. База уже перешла на новую версию, а месячный бэкап или экспорт для аналитики всё ещё зависит от старого ключевого материала.
Рабочий порядок обычно такой: создать новую версию, перевести новые операции на неё, проверить чтение старых данных, переобернуть DEK при envelope encryption, оставить старые версии на ограниченный срок, посмотреть журналы decrypt после ротации. Если после ротации старый ключ всё ещё активно используется, значит где-то остался старый контур обработки.
Токенизация
Токенизация нужна, когда сервису не требуется исходное значение. Ему нужен стабильный идентификатор: связать операции с клиентом, найти запись, провести платёжный сценарий, но не хранить у себя номер карты, паспорт или телефон.Как работает
Сервис отправляет чувствительное значение в сервис токенизации. Тот сохраняет пару “исходное значение - токен” в защищённом хранилище и возвращает токен. Остальные системы работают уже с токеном.
Критичная операция - detokenize. Право на неё должно быть у минимального числа сервисов. Если детокенизацию может вызвать любой внутренний сервис, зона риска почти не уменьшилась.
Форматосохраняющая токенизация
Форматосохраняющий токен нужен для старых систем, которые ждут значение похожего вида: фиксированную длину, последние цифры, определённый формат поля. Это снижает объём переделок, но требует аккуратности: токен не должен раскрывать признаки исходного значения больше, чем нужно.Пример разделения:
Код:
PAN: 4111111111111111
Mask: 411111******1111
Token: tok_card_8f3a91c2PCI DSS scope reduction
Токенизация помогает сократить зону PCI DSS, если сервисы вне платёжного контура не могут получить исходные карточные данные. Для этого нужно проверить четыре вещи:- нет прав на detokenize;
- нет прямого доступа к token vault;
- исходные значения не попадают в логи и очереди;
- выгрузки и отчёты строятся уже по токенам или маскам.
Где ломается
Обычно ломается не токен, а маршрут данных. Исходное значение попадает в лог до токенизации. Очередь получает событие с настоящим документом. BI забирает поле из старой таблицы. Подрядчику отдают CSV “временно”.Поэтому токенизацию надо ставить как можно ближе к точке входа чувствительных данных. Чем раньше исходное значение заменено токеном, тем меньше систем приходится считать частью чувствительного контура.
Где заканчивается защита данных
Шифрование, KMS и токенизация работают только вместе с нормальной дисциплиной вокруг данных. Можно включить шифрование бакета, но оставить исходные ПДн в логах. Можно вынести ключи в KMS, но выдатьdecrypt половине сервисных аккаунтов. Можно внедрить токенизацию, но оставить detokenize как обычный внутренний API без строгого аудита.Хорошая схема начинается с простого вопроса: где в системе появляется открытый текст и кто может его увидеть. После этого уже выбираются инструменты: шифрование в хранении, TLS или mTLS в передаче, KMS для ключей, токенизация для сокращения чувствительного контура, отдельные правила для резервных копий, выгрузок и журналов.
Главный риск остаётся не в отсутствии одного конкретного механизма. Риск в том, что данные живут дольше и шире, чем предполагает архитектурная схема. Сегодня поле ушло в отчёт, завтра появилось в очереди, через месяц оказалось в тестовом дампе. Поэтому финальный вопрос для любой облачной системы звучит неприятно просто: если завтра понадобится доказать, где именно хранились и расшифровывались чувствительные данные, у вас уже есть ответ или начнётся раскопка по логам, бакетам и старым выгрузкам?
