Эдера спонсировала этот пост.
В вычислениях время выполнения — это среда, в которой код активно выполняется. Он включает в себя все между приложением и аппаратным обеспечением: операционная система, время выполнения языка, интерфейсы ядра и контекст выполнения. Исторически, эта среда строго контролировалась, часто запуская одну рабочую нагрузку на выделенном сервере. Безопасность была обеспечена операционной системой, брандмауэрами и сегментацией сети.
Сегодня эта модель рухнула. Современные приложения создаются как распределенные микросервисы, развернутые в динамической инфраструктуре и часто работают автономными агентами ИИ. Средство выполнения больше не является четко определенной системой. Это обширный, эфемерный уровень выполнения, разделяемый несколькими арендаторами, контейнерами и рабочими нагрузками.
Безопасность на основе обнаружения стала беговой дорожкой в отрасли: бесконечная настройка, преследование ложных срабатываний и правила модернизации после компромисса. Несмотря на массовые инвестиции, нарушения сохраняются. Настало время для нового фундамента: безопасность, встроенная в саму время выполнения, где выполнение может быть ограничено, а не просто наблюдается.
Почему предупреждение о погоне за собой не удается
Традиционные инструменты времени выполнения полагаются на журналы, метрики и обнаружение на основе правил для мониторинга поведения рабочей нагрузки, наблюдения за аномальными Syscalls или отклонениями от ожидаемых моделей. Тем не менее, эти оповещения часто неточны, задерживаются или не имеют значения.
Результатом является бесконечная петля сортировки, которая очень напоминает неэффективность управления уязвимостью. Аналитики и разработчики Центра безопасности (SOC) (SOC) тратят ценное время, преследуя ложные позитивы, в то время как значимые угрозы продолжаются без контроля.
Что еще более важно, уязвимости времени выполнения — это не то же самое, что ошибки приложений. Недостаток приложения может раскрыть данные или нарушить функциональность, но слабость времени выполнения может обеспечить неограниченный доступ к хосту и любой другой рабочей нагрузке на систему.
Это представляет собой фундаментальный разрыв в изоляции и дает злоумышленникам полный контроль. Без упрочнения во время выполнения защитники вынуждены реагировать на симптомы вместо того, чтобы устранять коренные причины компромисса.
Эта реактивная модель проистекает из устаревшего предположения: что угрозы могут быть описаны заранее. На практике злоумышленники обходят обнаружение, цепляя тонкое поведение, злоупотребляя достоверными учетными данными или исследуя агенты ИИ посредством вредоносных подсказок. Поддержание правил становится работой на полный рабочий день.
Есть также проблема тестирования правил. Часто предполагается, что правила обнаруживают поведение злоумышленника, но редко (если когда -либо) тестируются и подтверждаются. Целые классы атак, такие как боковое движение или эскалация привилегий, продолжают преуспеть из -за среды выполнения, не имеющих изоляции или упрочнения, и вместо этого предназначенные для общего вычисления между доверенными арендаторами.
Утвержденное время выполнения заменяет предупреждение о погоне за правильными границами изоляции. Это предотвращает эти категории атак, не допуская условий, которые позволяют им. Если рабочие нагрузки изолированы и отрицают доступ по умолчанию, атаки не могут распространяться или расти.
Коллапс традиционной изоляции
Исторически, операционная система обеспечила соблюдение границ времени выполнения с использованием моделей процессов, разрешений пользователей и защиты памяти. Но по мере того, как приложения превращались из монолитов к клиентскому серверу, а затем к облачным нативным микросервисам, эти границы растворились. Контейнеры делятся ядрами. Пространства имен предлагают разделение ресурсов, а не безопасность. Сетевые политики контролируют трафик, но не поведение.
В Kubernetes и облачных средах рабочие нагрузки запускаются и разрушаются постоянно. Команды развертывают услуги, написанные на нескольких языках, каждый из которых имеет разные библиотеки и зависимости. Больше нет единой модели безопасности на основе операционной системы, на которую можно полагаться. Изоляция времени выполнения теперь должна соблюдаться на более низком уровне в самой среде выполнения.
«Предположим нарушение» в настоящее время единственная жизнеспособная позиция безопасности. Общественные эксплуатации приложений остаются ведущим вектором начального доступа, что составляет почти половину всех инцидентов. После того, как злоумышленники закрепляются, уязвимости времени выполнения предлагают прямые пути для эскалации привилегий, инфраструктуры злоупотреблений и компромисса соседних рабочих нагрузок.
Традиционные инструменты периметра и проверки времени настройки не могут содержать эту угрозу. Граница должна перейти к времени выполнения, где закаленная изоляция и безопасность по дизайну становятся последней линией защиты. Когда среда выполнения структурирована, чтобы по умолчанию отрицание ненужного доступа, обнаружение становится менее критическим, поскольку условия эксплуатации никогда не возникают.
Что на самом деле означает закаленное время выполнения
Утвержденное время выполнения обеспечивает три основополагающих элемента управления:
Каждая рабочая нагрузка работает в зоне песочницы без неявного доступа к сетям, API или контейнерам. Эта изоляция применяется не только через пространства имен Linux, а глубоко ограничивая среду процесса. Общая память, доступ к открытым устройствам и сетевые вызовы не затоплены по умолчанию.
Время выполнения уменьшает то, что код может сделать по умолчанию. Это предотвращает обслуживание общего ядра не затопленным Syscalls, гарантируя, что они не могут прервать или избежать ограниченной среды выполнения. Это устраняет ненужные привилегии и устраняет видимость уровня хоста. Это обеспечивает только то, что должна функционировать рабочая нагрузка. Это делает привилегии эскалацию и злоупотребление ресурсами структурно невозможным.
Когда инструменты наблюдения во время выполнения или мониторы уровня ядра обнаруживают аномалии, время выполнения отвечает немедленно. Он может отключить доступ к сети, приостановить выполнение или поместить рабочую нагрузку в карантин. В отличие от традиционных инструментов, которые сообщают только о проблемах, закаленное время выполнения действует в режиме реального времени.
Это поведение совпадает с Центром интернет -безопасности (CIS) и руководством по технической реализации безопасности (STIG). Что еще более важно, они постоянно соблюдаются самой средой выполнения, не полагаясь на статическую политику или динамическую оценку правил. Рабочие нагрузки изолированы и ограничены по дизайну, а не слоистой логикой политики.
Почему ИИ и графические процессоры увеличивают срочность
Рабочие нагрузки ИИ представляют новые шаблоны выполнения и новые риски. Агенты не просто анализируют данные. Они ведут себя автономно, генерируют динамический код и выполняют произвольные действия на основе входов в реальном времени. Они имеют учетные данные, запускают рабочие процессы и взаимодействуют с внутренними системами. Когда они скомпрометированы, они становятся надежными нападавшими.
Риск увеличивается на аппаратном слое. GPU часто делятся между контейнерами и пользователями. Их драйверы и интерфейсы памяти подвергаются воздействию процессов совместного резидента. Утечка по боковым каналам, придумывание памяти и несанкционированные пути выполнения не только теоретические, но их уже эксплуатируются. Например, WIZ недавно раскрыл уязвимости NVIDIA GPU, которые обнаружили критические слабости в общих аппаратных средах.
Утвержденное время выполнения содержит эти риски, тесно ограничивая каждую рабочую нагрузку. Агенты ИИ и рабочие места, управляемые графическими процессорами, ограничены тем, что они могут видеть и прикоснуться. Области памяти, интерфейсы устройств и межпроцессные связи явно уполномочены. Ничего не предполагается, чтобы быть в безопасности без проверки.
Утвержденное время выполнения — новый периметр
Периметр наследия больше не существует. Средство выполнения теперь является той, когда доверие должно быть оценено и применяется. Наблюдаемость и ведение журнала помогают построить ограниченный контекст, но без контроля они пассивны. Утвержденное время выполнения привносит как видимость, так и действие в уровень выполнения.
Команды безопасности и платформы уже растянуты, пытаясь управлять трубопроводами обнаружения, сортировкой и расстройством политики. Утвержденное время выполнения уменьшает это бремя, устраняя возможность целых классов атак. Это делает сдерживание поведением по умолчанию, а не запоздалой мыслью.
Edera Reimagines Container Container, обеспечивая оптимизацию ресурсов для рабочих нагрузок без нарушения рабочих процессов разработчика. Мы перепроектировали основную архитектуру: решение с аппаратного обеспечения, а не программное обеспечение. Наш подход соединяет разрыв между тем, как контейнеры отправляются и как они должны работать. Узнайте больше последних из Edera Trending Stories youtube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Алекс Зенла стал соучредителем Edera в апреле 2024 года, чтобы изменить способ запуска и защиты программного обеспечения и моделей искусственного интеллекта. Всего 25 лет она начала изучать гипервизоры и технологии аппаратного обеспечения в 7, участвовала в системах низкого уровня и начала … Подробнее от Alex Zenla
