Эффект Coupang: почему шифрование не спасает без контроля доступа к ключам

[BOOX]

Утечка данных в Coupang наглядно продемонстрировала: можно использовать самые продвинутые алгоритмы, но оказаться беспомощным, если архитектура управления ключами имеет единую точку отказа.

В 2026 году, когда атаки на облачную инфраструктуру стали повседневностью, вопрос безопасности смещается с «как зашифровать» на «как изолировать доступ». Cyber Media разбирает, как именно работают ошибки в управлении ключами, почему стандартные методы шифрования не спасают от масштабных утечек и как выстроить архитектуру KMS до того, как система будет скомпрометирована.

Анатомия провала: как одна уязвимость открыла доступ к корневым секретам​

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

Проблема не в том, что шифрование «сломали». Злоумышленники просто нашли способ легитимно запросить расшифровку у системы, которая не умела отказывать. В кейсе Coupang техническая ретроспектива указывает на критическую ошибку централизации: из-за одной-единственной уязвимости в приложении хакеры смогли дотянуться до KMS. Сервис, не увидев подвоха, выдал полномочия на расшифровку практически всего массива данных. В этот момент шифрование превратилось в тыкву — оно стало лишь лишним шагом в коде, который никак не замедлил эксфильтрацию миллионов записей.

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

Ключевые факторы эскалации:

• Монолитный уровень доверия. KMS воспринимала запросы от разных сегментов сети как равнозначные. Раз запрос пришел от «своего» сервиса, значит, ему можно доверить ключи от любого объекта.
• Отсутствие изоляции контекста. Ключи для разных типов данных хранились в одной логической корзине. Скомпрометировав один токен доступа, хакеры получили возможность дешифровать и персональные данные, и платежную информацию.
• Иллюзия «Data at Rest». Команда ИБ, вероятно, считала задачу выполненной, зашифровав данные на дисках. Но они забыли, что защита самих ключей в процессе их передачи и использования — задача куда более сложная.

Кейс Coupang доказал: шифрование без жесткого разграничения прав на использование ключей — это просто способ занять процессорное время. Если ваш KMS доверяет любому внутреннему сервису по умолчанию, считайте, что данные лежат в открытом виде. Радиус поражения в такой системе всегда будет максимальным, превращая любую локальную «дыру» в катастрофу.

Архитектура доступа: предотвращение каскадной расшифровки БД​

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

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

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

Итак, уволенный сотрудник имеет админский доступ, значит его элементы криптографической аутентификации (сертификат открытого ключа, закрытый ключ или симметричный ключ аутентификации) не отозваны после его увольнения. Либо у него есть доступ к аналогичным средствам аутентификации его коллег, которые не уволены.

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

Иерархия ключей в современной KMS:

• DEK. Индивидуальные ключи, которыми шифруются сами данные. Их могут быть миллионы, и они никогда не хранятся в открытом виде рядом с информацией.
• KEK. Ключи, которые шифруют только DEK. Здесь проходит главная граница: разные группы данных (ПДн, финансы, технические логи) защищаются разными KEK, изолируя их друг от друга.
• Root Key. Вершина пирамиды, защищающая KEK. Он живет в аппаратном HSM или максимально изолированном KMS. Доступ к нему — исключительное и строго аудируемое событие.

Такая модель превращает базу данных из единого сейфа в систему автономных ячеек. Даже имея ключ от одной из них, злоумышленник не может «открыть» соседние. Это архитектурное решение превращает потенциальную катастрофу в локальный инцидент, с которым ИБ-команда может справиться в рабочем порядке.

Защита в рантайме: борьба с кражей из оперативной памяти​

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

Проблема «горячих» ключей сегодня решается через Confidential Computing. Основная цель — свести к нулю время нахождения ключа в незащищенном сегменте RAM. Технологии вроде Trusted Execution Environments, например Intel SGX или AMD SEV, создают изолированные анклавы прямо внутри процессора. Память такого анклава шифруется аппаратно: даже ядро ОС или гипервизор не могут заглянуть в процесс, где происходит работа с секретом.

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

Закрытый ключ хранится и обрабатывается вычислительными мощностями доверенной среды. Это может быть токен, это может быть специализированный сервер — HSM, или защищенная область памяти самого приложения, в котором используется ключ.

В рассматриваемом кейсе Coupang доступная информация не позволяет говорить о наличии такой уязвимости. Но, теоретически, уволенный админ мог знать об уязвимости ключевой информации и эксплуатировать ее. Если ключи аутентификации и ключи шифрования не покидают доверенную среду, система защищена от такого сценария.

Архитектурные подходы к защите In Use:

• Аппаратные анклавы. Выполнение криптографии в защищенных областях CPU, где ключи никогда не покидают аппаратный модуль доверия.
• Бесключевая среда. Генерация эфемерных ключей внутри изолированной среды под конкретную операцию с их мгновенным уничтожением.
• Гомоморфное шифрование. Вычисления над данными без их расшифровки, что полностью снимает вопрос хранения ключей в открытом виде в RAM.
• Динамическая обфускация. Постоянное перемешивание и дробление секретов в адресном пространстве, чтобы их невозможно было восстановить через дампы.

Без изоляции рантайма любая KMS остается уязвимой перед злоумышленником, который смог закрепиться на уровне ядра системы. Защита данных «в использовании» замыкает периметр безопасности, делая кражу ключей из памяти экономически нецелесообразной и технически почти невозможной.

Жизненный цикл без простоев: автоматизация ротации​

В ИБ-среде «залежавшийся» ключ — это накопленный риск. Чем дольше один и тот же секрет защищает данные, тем выше вероятность его компрометации и тем больше данных окажется под ударом. Однако компании часто годами не проводят ротацию, боясь «окирпичить» систему: риск потерять доступ к архивам или вызвать отказ сервиса из-за конфликта версий пугает инженеров сильнее, чем гипотетический взлом.

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

Страх ротации — это страх человеческой ошибки в процессе. Решение — полная автоматизация и тестирование:

• Политики жизненного цикла, а не ручные операции. В KMS задаются строгие политики: срок жизни ключа, период его активного использования, обязательная ротация. Все это прописывается как код.
• Автоматическая ротация с двойным шифрованием. В момент ротации данные не перешифровываются моментально. Старый ключ помечается как неактивный для шифрования, но активный для расшифровки. Новым ключом начинают шифроваться только новые данные. Старые данные постепенно перешифровываются фоном. Это гарантирует доступность.
• Обязательные тестирования в тестовой среде. Процедура ротации должна регулярно отрабатываться на полноценном стенде-клоне прода (тестовом стенде). Это включает откат на предыдущий ключ при «аварии». Такие учения должны быть частью регламента.
• Обязательное логирование. KMS должен вести полный, неизменяемый лог всех операций с ключами. Каждый ключ имеет метаданные с датой создания, активации, истечения срока действия.
• Резервное копирование и восстановление. Ключи должны быть надежно зарезервированы (в зашифрованном виде) в географически распределенном хранилище. Процедура восстановления также должна быть автоматизирована и отрепетирована.

Успех автоматизации зависит от абстракции через Envelope Encryption. Приложение не оперирует самим ключом, оно получает от KMS зашифрованный DEK вместе с метаданными. При попытке расшифровки KMS автоматически считывает версию из заголовка данных и подтягивает нужный KEK из хранилища. Ротация превращается в рутинный фоновый процесс, исключающий человеческий фактор и ошибки ручного управления конфигурациями.

Мониторинг KMS в 2026 году: детекция аномалий в реальном времени​

В 2026 году пассивный аудит логов — это расследование уже совершившегося преступления. Для предотвращения утечек масштаба Coupang мониторинг KMS должен работать как IPS-система, способная отличить рутинные вызовы API от попыток массовой эксфильтрации. Легитимный сервис обычно запрашивает ключи предсказуемыми порциями, соответствующими RPS бизнес-логики, в то время как атакующий стремится выкачать как можно больше за минимальное время.

Детекция аномалий строится на анализе метаданных и поведенческих паттернов. Система мониторинга должна отслеживать не только сам факт обращения, но и отклонения в «профиле» сервиса.

В 2026 году акцент смещается с периметра на анализ поведения и контекста. Базовые признаки аномалии:

• Временные и географические аномалии. Запросы к KMS в нерабочее время или из несанкционированных регионов.
• Аномалии в объеме и частоте. Внезапный всплеск запросов на расшифровку DEK, особенно для данных, к которым долго не обращались. Попытки перебора или массового получения ключей.
• Аномалии в контексте. Запрос ключа сервисом, который обычно его не запрашивает, или с неправильными метаданными, например, запрос ключа от имени тестового окружения для продакшн-данных.

Настройка алертов и автоматического реагирования:

• Пороговые значения. Установка жестких лимитов на количество операций расшифровки в единицу времени для каждого сервисного аккаунта, блокирующая массовый перебор.
• Анализ энтропии запросов. Детекция автоматизированных скриптов по идентичным интервалам между вызовами или аномально высокой скорости перебора различных KeyID.
• Геофенсинг и контекст. Немедленная блокировка доступа при попытке обращения к KMS с узлов, не прошедших аттестацию, например, если сервис запущен вне доверенного K8s-кластера.
• Интеграция с SIEM/SOAR. Автоматический отзыв прав у скомпрометированного токена при обнаружении аномальной активности, не дожидаясь реакции дежурного офицера ИБ.

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

Облачные риски: собственное управление vs доверие провайдеру​

В 2026 году дискуссия вокруг управления ключами в облаке окончательно вышла за рамки простого «где хранить». Главный вопрос для ИБ-инженера — как сбалансировать контроль над данными и операционную надежность. На практике это выливается в выбор между нативными решениями провайдеров и моделью BYOK.

Нативные KMS-сервисы, например, AWS KMS, Google Cloud KMS, — это путь наименьшего сопротивления. Провайдер берет на себя все: от физической защиты HSM до обеспечения доступности «пяти девяток». Однако такой подход создает риск «замка на чужих дверях». Если ключи генерируются и хранятся внутри облака, провайдер технически имеет возможность дешифровать данные по запросу регуляторов или в случае внутренней компрометации.

Модель BYOK позволяет импортировать собственные ключи, сгенерированные во внешнем HSM, в облачную инфраструктуру. Это дает возможность мгновенно отозвать доступ, просто удалив ключ из облачного хранилища. Но важно понимать: в момент использования ключ все равно попадает в память инфраструктуры провайдера. BYOK — это не способ скрыть данные от облака, а инструмент управления жизненным циклом и соответствия комплаенс-требованиям, например, PCI DSS или GDPR.

Каждый подход хорош для своего применения и плох при применении не по назначению. Ключи на отчуждаемом съемном носителе — надежно при соблюдении правил хранения и использования ключевого носителя. Ключи в облаке — надежно, если поставщик сервиса надежен и протоколы доступа к ключам равно безопасны, не являются «слабым звеном». Эти два аспекта и являются системообразующими. Ваше доверие к поставщику облачного ключевого хранилища должно быть на чем-то основано (финансовые гарантии, лицензии, сертификаты, SLA).

Типичные ошибки конфигурации при внедрении BYOK:

• Нарушение энтропии. Использование слабых генераторов случайных чисел при создании ключа на стороне компании делает BYOK опаснее нативного решения.
• Ошибки в Key Policy. Слишком широкие права в политиках доступа, которые позволяют сервисам провайдера обходить ограничения владельца ключа.
• Отсутствие резервного копирования. Если ключ импортирован без возможности восстановления из исходного HSM, любая ошибка в синхронизации превращает облачные данные в цифровой мусор.
• Игнорирование региональности. Попытка использовать один и тот же импортированный ключ в разных регионах облака может привести к неконсистентности данных и нарушению требований по их суверенитету.

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

Заключение​

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

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


Источник