Oracle Corp. переносит корпоративную безопасность на уровень данных, делая ставку на то, что контроль, применяемый там, где информация действительно хранится, лучше выдержит атаки с использованием AI, чем традиционная защита периметра. В июне компания представила стратегию из трёх частей — secure at source, secure at speed и secure through resilience — и подробно расскажет о ней на виртуальном мероприятии «AI Cyberattacks Are Escalating: How to Secure Your Data Now» 22 сентября. Этот сдвиг важен потому, что AI-агенты сегодня добираются до конфиденциальных корпоративных данных по путям, для контроля которых средства на уровне приложений никогда не предназначались.
Что Oracle представила в июне
Стратегия опирается на набор инструментов для защиты баз данных, установки обновлений, тестирования и управления жизненным циклом. Среди них — Oracle Deep Data Security, которая применяет правила приватности для конкретного конечного пользователя внутри самой базы данных, и Oracle SQL Firewall, созданный для блокировки SQL-инъекций — уязвимости, позволяющей злоумышленникам выполнять вредоносные команды базы данных через поля ввода на сайте. В апреле Oracle объявила о широком наборе улучшений для Oracle AI Database, включая Deep Data Security для централизованных, декларативных и детализированных политик авторизации и видимости данных, привязанных к идентичности, ролям и контексту каждого конечного пользователя. Мероприятие 22 сентября соберёт руководителей продуктов Oracle, отраслевых экспертов и аналитиков theCUBE Research, чтобы обсудить ландшафт угроз и практические рекомендации по защите конфиденциальных данных, снижению перебоев и быстрому восстановлению после атаки.
Механика здесь важнее маркетинга. Встраивая применение политик Deep Data Security непосредственно в базу данных, Oracle добавляет защиту от несанкционированного доступа к данным, возникающего из-за вредоносных внедрённых запросов. Логика компании в том, что агенты перешли от простых ответов на вопросы к значимым действиям, а это ставит под сомнение эффективность защиты на уровне приложений. Если запрос попадает в базу данных с неверным намерением, сама база становится последней линией обороны. Это иной принцип проектирования, чем прикручивание безопасности к приложению, которое стоит перед данными.
Позиция Oracle вписывается в более широкий отраслевой сдвиг к объединению безопасности, управления и восстановления по всему стеку AI. Дэйв Велланте из theCUBE Research утверждает, что модель разделённой ответственности в облаке больше не достаточна в мире, где AI стоит на первом месте, поскольку агенты, действующие на машинных скоростях, требуют того, что он называет моделью совместной ответственности: защищать инфраструктуру, приложения и данные внутри них уже недостаточно, когда противники используют AI, а случайные действия AI выполняются на машинной скорости. Криста Кейс, также из theCUBE Research, добавляет, что следующая фаза внедрения корпоративного AI будет зависеть от управления не меньше, чем от возможностей модели: по мере того как агенты получают доступ к конфиденциальным данным и критическим процессам, организациям нужно знать, под чьей идентичностью они действуют, какие привилегии наследуют и где эти привилегии применяются. Джон Фуррье рассматривает внимание Oracle к уровню данных как часть более широкой ставки на то, что будущее AI определит не сам агент, а то, где и как он взаимодействует с данными.
Что это значит для бизнеса
Для компаний, разворачивающих AI-агентов, практическое следствие в том, что требования к безопасности смещаются с приложения на базу данных. Небольшая фирма с несколькими агентами может обнаружить, что встроенное применение политик снижает потребность в отдельных инструментах мониторинга, тогда как крупному предприятию с множеством хранилищ данных придётся сопоставить, какие идентичности наследуют агенты и где эти привилегии действительно применяются. Разница проявляется в повседневных ситуациях: агент, который запрашивает записи клиентов, запускает процесс или пишет в производственную таблицу, теперь несёт те же вопросы авторизации, что и сотрудник, и ответы должны быть проверяемыми, а не предполагаемыми.
Нерешённым остаётся вопрос, какую часть этого можно проверить до внедрения. В источнике не сказано, сколько клиентов используют Deep Data Security или SQL Firewall и что показали независимые тесты. Покупателям стоит спрашивать поставщиков, где физически находится применение политик, сохраняется ли оно при вредоносном внедрённом запросе и как работает восстановление, когда авторизованный агент изменяет критичные данные или нарушает процесс на машинной скорости. Инструменты отказоустойчивости Oracle — Zero Data Loss Recovery, защищающий базы данных вплоть до последней подтверждённой транзакции, и Globally Distributed AI Database с репликацией на основе Raft и автоматическим переключением — решают вопрос доступности, но сами по себе не отвечают на вопросы управления, которые поднимает Кейс. Новость не означает, что защита периметра устарела; она означает, что уровень данных теперь стал частью аргумента.
Маркер, за которым стоит следить, — само мероприятие 22 сентября и то, что Oracle раскроет там о применении политик, восстановлении и внедрении у клиентов. Если компания покажет конкретные развёртывания и независимую проверку, а не архитектурные схемы, подход на уровне данных станет убедительным критерием закупки для проектов с AI-агентами. Если обсуждение останется на уровне стратегии, бизнесу следует воспринимать эту стратегию из трёх частей как направление движения, а не как устоявшийся стандарт.
