Дэвид Майтон, генеральный директор Arcjet – Интервью

Дэвид Майтон, основатель и генеральный директор Arcjet, возглавляет компанию, ориентированную на разработчиков, которая помогает командам внедрять надежные меры защиты, такие как обнаружение ботов, ограничение скорости, проверка электронной почты, смягчение атак и удаление данных,直接 в код приложения, заняв пост в июне 2023 года. Он также стал сооснователем Console, популярного информационного бюллетеня и подкаста для разработчиков, занимал должности советников, такие как эксперт в Seedcamp, и ранее руководил инженерными работами по продуктам в StackPath после того, как его компания по мониторингу облачных вычислений была приобретена, сохраняя при этом сильный интерес к устойчивым вычислениям и активно пишет на темы технологий.

Arcjet построен на основе философии “безопасность как код”, которая позволяет разработчикам защищать приложения с помощью простых интеграций SDK, размещая логику безопасности рядом с бизнес-логикой для принятия решений с низкой задержкой и контекстно-зависимых решений, исключая необходимость в отдельной инфраструктуре; платформа поддерживает такие защиты, как блокировка ботов, ограничения скорости и фильтрация чувствительных данных, и продолжает развиваться с функциями, такими как локальная модель безопасности на основе ИИ и расширенная поддержка фреймворков, отражая свою миссию по сделать безопасность в коде стандартом для современных приложений. (fly.io)

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

Большинство инструментов для разработчиков выигрывают демонстрацию и проигрывают производству. Получение установки чего-либо нового для разработчика сложно, поэтому “быстрый старт” должен быть без трения – но это только начало. Реальный режим сбоя – это то, что происходит после “это работает”: продукт становится ограниченным, и серьезные команды быстро разочаровываются и удаляют его.

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

Продукт не является пользовательским интерфейсом. Продукт – это поведение во время выполнения, краевые случаи, примеры и справочные документы, которым разработчики могут доверять.

Исходя из этого опыта, что привело вас к созданию Arcjet, и почему вы чувствовали, что следующий значительный сдвиг в безопасности приложений должен произойти внутри кода самого, а не на уровне сети или инфраструктуры?

Периметральная безопасность оптимизирует не то, что нужно. Разработчики строят и отправляют в код, а не в панели управления – и агенты ИИ не будут “кликать” по безопасности консоли, чтобы защитить приложение.

Если ваша защита не может быть выражена как код, просмотрена в запросе на слияние, протестирована в CI и развернута вместе с приложением, это не “безопасность, ориентированная на разработчика”.

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

Arcjet внедряет обнаружение угроз на основе ИИ直接 в обработчики запросов приложения. С технической точки зрения, какие преимущества предоставляет этот локальный, встроенный подход по сравнению с традиционными периметральными инструментами безопасности?

Внутри обработчика запроса у вас есть идентификатор, состояние сессии, история покупок, возраст учетной записи, флаги функций и базовая правда. Вы можете принять решение, такое как: “Это выглядит странно, но это лояльный клиент – увеличьте проверку вместо блокировки.” Сетевой прокси не может сделать это, потому что он не знает, что такое “клиент”.

Цель не состоит в том, чтобы максимизировать блокировку. Цель – минимизировать ложные положительные результаты с контекстно-зависимой безопасностью, потому что самая дорогая ошибка безопасности – блокировка законной оплаты или блокировка реального пользователя.

ИИ существенно изменил экономику злоупотреблений, от соскабливания ботов и спама при регистрации до автоматизированного эксплуатации API. Какие виды атак вы видите чаще всего в производстве сегодня, и как они эволюционируют, когда атакующие принимают более продвинутые системы ИИ?

Продуктивные выгоды от ИИ помогают атакующим! Большой сдвиг – это объем и скорость итерации: больше попыток подбора учетных данных, больше автоматизированного спама при регистрации, больше соскабливания ботов, больше сканирования API и более быстрая “военизация” свежих уязвимостей.

Мы также видим, как атакующие запускают более тесные обратные связи: они тестируют защиты, адаптируют подсказки и полезные нагрузки, ротируют инфраструктуру и продолжают, пока не получат доступ. Сейчас все это о скорости, а не о сложности.

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

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

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

Arcjet получил ранний успех с продуктами, ориентированными на ИИ, и платформами электронной коммерции. Что делает эти среды особенно уязвимыми для современных автоматизированных атак, и почему традиционные защиты часто не справляются?

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

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

Традиционные защиты в основном защищают пропускную способность и инфраструктуру. Современные атакующие нацеливаются на бизнес-логику: потоки регистрации, потоки оплаты, логика промо-акций, восстановление учетных данных и конечные точки API. Поэтому общие периметральные контроли и “решение с помощью CAPTCHA” все чаще не справляются.

Разработка программного обеспечения для безопасности имеет очень разные компромиссы, чем наблюдаемость или мониторинг. Что вас больше всего удивило в разработке продукта безопасности по сравнению с вашим предыдущим опытом с инструментами инфраструктуры?

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

Разработка продукта безопасности означает управление компанией безопасности. Мы используем такие рамки, как SOC 2, минимизируем наши зависимости от третьих сторон и относимся к ноутбукам разработчиков и доступу к инструментам как к активам производства. Это означает много мониторинга и быстрые реакции на потенциальные проблемы.

По мере того, как приложения все больше полагаются на агентов ИИ, действующих от имени пользователей, как разработчикам следует переосмыслить идеи идентичности, намерения и доверия на уровне приложения?

Когда агенты ИИ действуют от имени пользователей, идентичность перестает быть бинарным состоянием входа и становится проблемой делегирования: кто действует, от имени кого, с какими разрешениями, на сколько времени и с какими ограничениями.

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

Это означает создание шагов для повышения доверия (верификации, ограничения скорости, трения) вокруг действий с высоким риском, таких как сброс пароля, оплата и создание токенов – и сделать эти контроли живыми в коде, где приложение может отличить лояльного клиента от бота со украденным файлом cookie.

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

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

Если встроенная безопасность станет стандартной моделью для современных приложений, что это означает для того, как разработчики тестируют, развертывают и рассуждают о безопасности в производственных системах?

Если встроенная безопасность станет стандартом, команды будут тестировать злоупотребления так же, как они тестируют правильность: тесты безопасности, симуляции атак и проверки CI для рискованных конечных точек.

Большой сдвиг заключается в том, что агенты кодирования ИИ будут реализовывать безопасность как код, а не как конфигурацию панели управления. Агенты могут надежно предлагать, просматривать и проверять защиты только тогда, когда контроли живут в репозитории: политики, правила, тесты и инструментирование. Если “слой безопасности” является веб-интерфейсом, агент не может протестировать изменения, чтобы безопасно отправить их.

Это реальная причина, по которой “безопасность в коде” выигрывает – она соответствует тому, как современное программное обеспечение (и современное развитие с помощью ИИ) фактически строится.

Благодарим за отличное интервью, читатели, которые хотят узнать больше, могут посетить Arcjet.