Нещодавно мені випала нагода поговорити з Френсісом де Соуза, операційним директором Google Cloud, за лаштунками одного заходу в Лос-Анджелесі. Серед навколишнього гамору де Соуза, який говорить спокійно й виважено, як університетський професор, поділився корисними порадами для компаній, що зараз проходять через етап «моменту безпеки ШІ». На його думку, «буде перехідний період, а потім, гадаю, ми вийдемо в кращу точку».
Говорив він тоді не стільки про Google, але очевидно, що навіть Google ще продовжує розбиратися в цих питаннях.
Основний меседж де Соуза — той самий, який фахівці з безпеки роками намагалися донести до керівників, але тепер на тлі ШІ він став особливо актуальним: безпека не може бути другорядною. «Починаючи свою подорож у ШІ, компанії мають обирати платформений підхід, — сказав він. — Безпека — це не те, що можна прикрутити потім, і не те, що можна віддати на відкуп окремим працівникам». Особливо він застеріг від явища «тіньового ШІ», коли співробітники користуються споживчими інструментами без контролю з боку організації. На його думку, компанії з самого початку мають вимагати від платформ безпеки, управління та можливості аудиту. «Не існує стратегії ШІ без стратегії даних і стратегії безпеки. Вони мають йти разом».
Варто зауважити: він не обмежувався «рекламою» Google Cloud. Коли я зазначила, що його поради звучать як рекламний меседж Google, він заперечив. За словами де Соуза, Google дотримується мультихмарного підходу, і він переконаний, що компанії, які вважають, що працюють лише з однією хмарою, майже напевно помиляються. «Навіть якщо вони обирають одну хмару, вони покладаються на SaaS-додатки, є бізнес-партнери, які можуть використовувати інші хмари, — сказав він. — Важливо, щоб компанії мали єдину позицію з безпеки в усіх хмарах, у всіх моделях».
Він також наголосив, що ландшафт загроз змінився настільки фундаментально, що старі моделі захисту стали надто повільними. За його словами, середній час між початковим зламом і переходом до наступного етапу атаки скоротився з восьми годин до 22 секунд, а поверхня атаки вийшла далеко за межі традиційного мережевого периметра. «Окрім вашої звичної інфраструктури, тепер у вас є моделі. Є конвеєри даних для їхнього навчання. Є агенти, є підказки (prompts). Усе це має бути захищеним».
Одну загрозу де Соуза виділив окремо: її недооцінюють. Мова про агентів, що рухаються внутрішніми системами компанії та можуть виявляти забуті сховища даних, про які ніхто роками не згадував. «У багатьох організацій є старі сервери SharePoint і налаштування доступу, які майже не оновлювалися, але це не мало значення, бо ніхто навіть не знав, де вони. Та агенти, що блукають вашим підприємством, знайдуть ці активи даних і розкриють інформацію на них».
Відповідь, на його думку, у тому, щоб протиставити машинній швидкості машинну ж швидкість. «Ми зараз бачимо появу «ШІ-нативного», повністю агентного захисту, коли організації запускають агентів, які керують обороною, — сказав він. — Замість людсько-орієнтованого захисту чи навіть підходу з людиною в контурі, тепер можна мати людей, які лише наглядають за повністю агентною обороною». Він додав, що це вже питання не лише технологій, а й лідерства: «Це питання рівня ради директорів і топменеджменту. Це не просто проблема команди безпеки».
Однак, навіть якщо ШІ бере на себе дедалі більше робіт із захисту, людей, які здатні цим керувати, бракує — а вразливості, які сам ШІ породжує, множаться швидше, ніж команди безпеки встигають їх усувати. «Нам потрібні люди, які впораються з “bug-pocalypse” — апокаліпсисом багів», — сказала CISO LinkedIn Лея Кісснер в інтерв’ю New York Times цього тижня, додавши, що не очікує, що індустрія зрозуміє безпеку ШІ в сталому, довгостроковому вимірі бодай у найближчі кілька років.
Це повертає нас до самих провайдерів платформ. Видання The Register за останні тижні опублікувало серію матеріалів про хвилю розробників Google Cloud, які отримали рахунки на п’ятизначні суми через несанкціоновані виклики API до моделей Gemini — сервісів, якими багато хто з них ніколи свідомо не користувався і навіть не вмикав. Схема була типовою: ключі API, спочатку створені для Google Maps і викладені у відкритий доступ відповідно до інструкцій самого Google, «тихо» отримали можливість доступу до Gemini після того, як компанія розширила їхні повноваження, не роз’яснивши це належним чином.
Род Данан, генеральний директор платформи для підготовки до співбесід Prentus, розповів, що його рахунок сягнув $10 138 приблизно за 30 хвилин після того, як зловмисники скористалися скомпрометованим ключем API. Ісуру Фонсека, розробник із Сіднея, який опинився в подібній ситуації, прокинувся й побачив нарахування приблизно на 17 000 австралійських доларів, хоча вважав, що встановив ліміт витрат у $250. Ніхто з них не знав, що автоматичні системи Google підвищили їхній тарифний план з огляду на історію акаунта, фактично збільшивши стелю витрат до $100 000 без явної згоди користувачів.
Після публікації першого матеріалу The Register Google повернув обом клієнтам кошти. Втім, компанія повідомила виданню, що не планує змінювати свою політику автоматичного підвищення тарифу, пояснюючи це тим, що пріоритезує запобігання збоям у сервісі, а не дотримання заявлених користувачами бюджетів.
Тим часом постає окреме питання: що відбувається, коли розробник намагається все негайно вимкнути. На цьому тижні The Register написало про дослідження компанії Aikido, яке показало, що навіть ті розробники, які помічають скомпрометований ключ і одразу його видаляють, можуть залишатися під загрозою. За даними Aikido, зловмисники можуть продовжувати використовувати цей ключ до 23 хвилин, оскільки відкликання ключа Google розповсюджується інфраструктурою поступово. Дослідник Aikido Джозеф Леон розповів The Register, що в цей проміжок імовірність проходження запитів непередбачувана — у деякі хвилини понад 90% запитів усе ще автентифікувалися — і зловмисники можуть використати цей час, щоб вивести файли та кешовані дані розмов із Gemini.
Леон також зазначив, що нові формати облікових даних Google, схоже, не мають такої проблеми: облікові дані сервісних акаунтів відкликаються приблизно за п’ять секунд, а новий формат ключів Gemini із префіксом AQ — приблизно за хвилину. «Обидва працюють у масштабі Google, — написав він у супровідній публікації Aikido. — Обидва свідчать, що технічно Google API-ключі теж можна зробити такими». Іншими словами, за словами Леона, 23-хвилинне «вікно» — це не технічне обмеження, а питання пріоритетів компанії.
Про це варто пам’ятати, читаючи поради де Соуза, які є цілком обґрунтованими й заслуговують серйозного ставлення. Він не помиляється, але наразі існує розрив між тим, що платформи декларують, і тим, з якою швидкістю вони самі адаптуються. І про це також важливо не забувати.