Около 5 тыс. участников государственной стартап-платформы в Южной Корее лишились защиты персональных данных из-за ошибки, которую в 2026 году уже неловко объяснять на пальцах: ключ шифрования оказался в API вместе с данными. Для русскоязычной IT-аудитории это не экзотическая история из чужой юрисдикции, а очень земной кейс о том, почему «у нас все зашифровано» ничего не значит, если архитектура хранит секреты там же, где и полезную нагрузку.
Речь идет о платформе Modu-ui Changup, связанной с программой поддержки стартапов под эгидой южнокорейского Министерства малого и среднего бизнеса и стартапов, как пишет BleepingComputer. Сервис хранил персональные данные участников, включая имена, email-адреса и краткие описания стартап-идей. Ключевая деталь инцидента в том, что сама база не была открыта в чистом виде: информация уже находилась в зашифрованном виде. Проблема в другом: ключ, который должен был оставаться отдельно от данных, попал в API. После этого вопрос «были ли данные зашифрованы» превращается в бюрократическую формальность.
Южнокорейские власти 31 июля назвали именно утечку ключа решающей причиной компрометации. По данным расследования, сторонняя сторона собирала данные из API в том числе через web crawling. В результате утекли email-адреса, комментарии оценщиков и краткие описания идей примерно 5 тыс. заявителей, прошедших отбор. Отдельно неприятно выглядит история с адресами электронной почты: на публичном интерфейсе они были скрыты как приватные, но следователи пришли к выводу, что их можно было извлечь через AI-ориентированный краулинг. Это важный нюанс для команд, которые до сих пор мыслят категориями «раз на экране не видно, значит, наружу не торчит». Если поле приходит в ответе API, оно уже потенциально снаружи.
Еще за месяц до официального подтверждения утечки вокруг платформы уже звучали претензии к тому, как через API можно структурированно получать персональные данные заявителей. Государство тогда заявило, что меры приняты оперативно, но вопрос о переработке самой архитектуры безопасности остался открытым. И здесь, пожалуй, главный урок всей истории: инциденты редко возникают внезапно. Чаще они сначала приходят в виде «неприятного сигнала», потом в виде «частного замечания», а уже затем превращаются в полноценную утечку с участием спецслужб и полиции. В расследовании участвовали Национальная разведслужба, Центр кибербезопасности и Национальное полицейское агентство Южной Кореи. Также власти сообщили о 39 IP-адресах, замеченных при доступе к утекшей информации; все они находились внутри страны.
С технической точки зрения кейс довольно прямолинейный и оттого показательный. Если ключ шифрования захардкожен в коде, конфиге, базе или любом окружении, которое приложение раздает наружу хотя бы частично, шифрование превращается в декоративный слой. Да, формально данные зашифрованы. Практически же злоумышленник получает и сейф, и ключ от него в одном пакете. В продакшене это случается чаще, чем принято признавать: секреты оказываются в переменных окружения без нормального контроля доступа, в CI-логах, в репозиториях, в мобильных клиентах, в debug-эндпоинтах и, как видно, в API-ответах. Дальше уже неважно, какой именно алгоритм использовался. Уровень криптографии не спасает, если ключ живет по правилам convenience-driven development.
В материале Penta Security, который разбирает инцидент, много маркетинга, но базовый тезис спорить не заставляет: ключ шифрования должен храниться отдельно от данных и приложений, которые эти данные обслуживают. Нормальная схема для таких задач давно известна: выделенная система управления ключами, запрос ключа только в момент операции расшифровки, контроль жизненного цикла ключей, журналы доступа и регулярная ротация. Причем одной ротацией после инцидента дело не заканчивается. Если ключ уже утек, организация должна не только выпустить новый, но и заново зашифровать все данные, которые были защищены старым. Параллельно нужно разбирать логи доступа к ключам, проверять права на уровне API, серверов и внутренних хранилищ, уведомлять затронутых пользователей и включать постоянный мониторинг. То есть платить не только за ошибку, но и за ее длинный хвост.
Для разработчиков это история про базовую инженерную дисциплину. Для продактов и IT-руководителей — про цену компромиссов, которые обычно оформляются словами «сделаем сейчас попроще, потом вынесем в отдельный сервис». Для стартапов — особенно ироничный урок: платформа, созданная для поддержки новых компаний, сама показала, как легко похоронить доверие к продукту одной архитектурной уступкой. Для HR и compliance-команд вывод еще проще: наличие шифрования в презентации и в чек-листе не означает реальной защиты персональных данных. Регуляторы смотрят не на лозунг «данные encrypted», а на то, можно ли их фактически прочитать после компрометации одного компонента. И если можно, спор о соответствии требованиям быстро заканчивается.
На фоне роста AI-краулинга этот кейс становится еще неприятнее. Раньше многие команды оценивали риски API прежде всего через призму «человек зайдет в интерфейс и что-то увидит». Теперь данные могут собираться быстрее, глубже и системнее, чем предполагалось изначально, а скрытые в UI поля остаются вполне доступными для автоматизированного извлечения. Поэтому следующий виток зрелости в security для цифровых платформ будет крутиться не вокруг громких заявлений о шифровании, а вокруг скучной, но решающей вещи: умеет ли компания держать ключ шифрования отдельно от данных и доказывать это не на словах, а в архитектуре.