Витік даних Singapore Land Authority: 70 000 записів з IBM Cloud

Кожен, хто успадковував застаре тестове середовище, знає цей запах: дамп-файл, старший за молодших інженерів у команді, позначений «анонімізований» кимось, хто пішов з компанії десять років тому. Сінгапур щойно дізнався, що трапляється, коли ніхто не перевіряє цю позначку. Singapore Land Authority розкрила, що особисті дані 70 000 людей опинились під загрозою після несанкціонованого доступу до набору даних у хмарному середовищі, яке керується IBM. Жива реєстраційна система залишилась недоторканою. Усю шкоду завдав 28-річний тестовий пісочниця.

Цифри

Почнімо з головного. 70 000 осіб мали розкриті імена, номери National Registration Identity Card, фінансові дані та адреси, як повідомляє AnewZ. У країні з приблизно шістьма мільйонами жителів це чималий відсоток дорослого населення, зосереджений в одному файлі, якого офіційно не повинно було існувати у такому вигляді.

Уражений набір даних було створено у 1998 році. Прочитайте цей рік ще раз. Він старший за хмарне середовище, в яке зрештою потрапив. Він старший за більшість сучасного законодавства про захист даних в Азії. Його було побудовано як макет, анонімізований набір даних для розробки та тестування постачальниками систем Singapore Titles Automated Registration System (STARS) та eLodgment. Обидві розміщені у хмарі IBM. Жодна з виробничих систем не зазнала втручання.

Власні слова SLA тут важливі: «Ця інформація мала бути анонімізована, але не була.» Це одне речення — увесь інцидент у мініатюрі. Хтось, у якийсь момент між 1998 і 2026 роками, або не зміг анонімізувати витяг, або відновив реальний знімок поверх макету, або довірився назві файлу, яка брехала. Ніхто не перевірив повторно. Дані пережили декілька міграцій платформ, переукладання контрактів і, мабуть, принаймні одне перенесення до хмарної інфраструктури IBM.

Перекладімо це в операційні терміни. 70 000 записів NRIC з фінансовими даними — це набір даних, який міг би фінансувати операцію з крадіжки особистих даних роками. NRIC у Сінгапурі функціонально еквівалентний національному посвідченню особи плюс частковому кредитному ключу. Порівняно з витоками платіжних карток, за якими більшість команд безпеки орієнтуються, це гірше на кожен запис. Вкрадену картку скасують за 48 годин. Номер національного посвідчення — ні.

Ланцюг реагування вражає: IBM розслідує, Агентство кібербезпеки Сінгапуру розслідує, Government Technology Agency розслідує, подано поліцейський звіт, і повідомлено Комісію з захисту персональних даних. Чотири регулятори або слідчих органи щодо одного інциденту свідчать про те, як Сінгапур ставиться до реєстраційних даних. Записи про власність є суверенною інфраструктурою.

Що насправді нового

Спокуса — класифікувати це як ще один хмарний витік і рухатися далі. Таке прочитання не помічає того, що насправді сталося. Це не була атака на контрольну площину IBM. Це не було хмарне сховище, налаштоване з відкритим доступом для всіх, принаймні не за тим, що SLA повідомила досі. Набір даних був призначений для розробки та тестування постачальниками. Хтось із законним доступом до нижнього середовища дістався даних, які були неправильно позначені у джерелі.

Це збій у ланцюжку постачання та простежуваності даних, а не збій хмарного провайдера. І це саме та історія, яку команди безпеки постійно недооцінюють. Бюджети на захист виробничих систем різко зросли за останні п'ять років. Тестові середовища, тестові дані, початкові дані для інтеграцій з постачальниками, CI-артефакти — все це перебуває на тому ж рівні занедбаності, що й у 2015 році. Команди, з якими я працював, зазвичай мають виробниче середовище, захищене чотирма факторами автентифікації та процесом екстреного доступу, тоді як їхня база даних для стейджингу — це щонічне відновлення продакшну з суфіксом "+test" у стовпці email.

Другий справді новий елемент — вік артефакту. Набір даних 1998 року, що зберігся через щонайменше три або чотири покоління інфраструктури в SLA. Кожна міграція — це можливість повторно класифікувати дані. Кожна міграція — це також можливість сліпо синхронізувати директорію, бо ніхто не хоче бути тим, хто зламав тестовий стенд постачальника за два тижні до запуску. Виробничі інциденти, які я бачив під час міграцій у європейських фінтех-компаніях, мають точно таку саму модель: ризиковані дані ніколи не є яскравою новою таблицею, це загадковий файл у /data/legacy/, який ніхто не наважується видалити.

Моя думка: справді новим розкриттям тут є не те, що хмара IBM зазнала витоку. Це те, що національний земельний реєстр визнає, що майже три десятиліття зберігав реальні персональні дані громадян у файлі, який усі вважали фіктивним. Це історія про управління даними, і вона змусить провести незручні аудити у кожного державного орендаря гіперскейлерної інфраструктури в регіоні.

Що вже враховано командами з безпеки

Більшість досвідчених інженерів, які читають це, вже знають, що тестові дані — це місце, де ховаються проблеми. Стаття 32 GDPR, сінгапурський PDPA та кожен серйозний режим захисту даних за останнє десятиліття говорять одне й те саме: псевдонімізація має бути верифікованою, а не передбачуваною. Тож сама концепція не нова. Прайсується поінформованість. Не прайсується виконання.

Ринок також врахував, що моделі спільної відповідальності залишають величезну сіру зону. IBM керує хмарним середовищем. SLA відповідає за класифікацію даних. Коли щось іде не так у цьому стику, обидві сторони розслідують, а клієнт несе репутаційні збитки. Це стандартна практика, і нікого в закупівлях не повинно дивувати.

Що не враховано: наскільки швидко азійські регулятори рухаються щодо інцидентів рівня реєстру. Чотири органи, задіяні в перший день, — це сигнал. Повідомлення Комісії з захисту персональних даних є процедурним. Участь CSA та GovTech — ні. Очікуйте офіційних рекомендацій, і очікуйте, що вони конкретно стосуватимуться засобів контролю тестових пісочниць постачальників. Команди, що продають продукти в державний сектор ASEAN, повинні припускати, що їхня наступна анкета з питань безпеки матиме новий розділ про походження тестових даних.

Незручний висновок: більшість корпоративних програм безпеки не можуть відповісти на запитання «звідки взялися початкові дані у вашому середовищі розробки, і хто підтвердив, що їх безпечно використовувати?» Якщо ви не можете відповісти на це сьогодні, ви перебуваєте за один запит FOIA або одного інсайдера від сінгапурського заголовку.

Альтернативний погляд

Консенсус зведеться до «хмара ризикована, IBM провалилася, Сінгапуру не пощастило». Це неправильне формулювання, і воно дозволяє занадто багатьом уникнути відповідальності.

Розгляньте альтернативне прочитання. Живі системи SLA не впали. Записи про право власності не зазнали втручання. Система eLodgment продовжувала працювати. З точки зору стримування, цей інцидент є перемогою: радіус ураження зупинився на тестовому наборі даних постачальника. Якби ті самі 70 000 записів були витягнуті з операційної бази даних STARS, ми б говорили про крах довіри до системи земельних титулів Сінгапуру, а не про розкриття та список постраждалих осіб.

Тож альтернативний аргумент полягає в тому, що сегментація спрацювала. Провалилася не безпека під час виконання, а гігієна маркування даних ETL-завдання епохи Клінтона. Це різні проблеми з різними рішеннями. Змішування їх змусить команди витрачати більше на інструменти виконання, які вони вже мають, і менше на нудну роботу з відстеженням і класифікацією, яка насправді могла б запобігти цьому. Нудне рішення рятує о 2 годині ночі. Нудне рішення — це також те, що ніхто не хоче фінансувати.

Ключові висновки

• Перевірте кожен набір даних, позначений «макет» або «анонімізований», що передує вашій поточній програмі захисту даних. Якщо його було створено до 2010 року, вважайте позначку неперевіреною, поки хтось не повторно виконає анонімізацію та не підпише це письмово.
• Невиробничі середовища потребують засобів контролю доступу виробничого рівня, якщо вони містять дані, похідні від виробничих. Сінгапурський інцидент показує, що зловмиснику не потрібно було торкатися STARS. Йому потрібен був лише тестовий пісочниця постачальника.
• Набори даних для розробки та тестування постачальників повинні бути у вашому інвентарі класифікації даних. Якщо ваш CMDB або каталог даних їх не містить, для вашої команди ризиків вони не існують, що означає: саме звідти походитиме наступний витік.
• Контрольні точки міграції — це правильний момент для повторної класифікації. Кожна хмарна міграція, кожна зміна провайдера, кожне перенесення платформи. Додайте обов'язковий огляд «що це за файл і чому ми його переносимо». Видаляйте агресивно.
• Очікуйте, що регулятори ASEAN посилять правила щодо тестових пісочниць постачальників. З участю CSA, GovTech, PDPC та поліції результат не обмежиться звітом. Очікуйте конкретних вказівок щодо походження тестових даних для хмарних орендарів державного сектору протягом дванадцяти місяців.

Причина, чому цей інцидент важливий поза межами Сінгапуру, полягає в тому, що кожне велике підприємство десь має еквівалентний файл 1998 року. Це може бути CSV на файловому сервері, таблиця у виведеному з експлуатації екземплярі Oracle, що все ще підключений до працюючого застосунку, або скрипт початкових даних, залитий у git-репозиторій ще до вашого нинішнього CISO. Земельний реєстр отримав аудит від зловмисника. Більшості організацій ще не так «пощастило».