Как использовать Zero Trust Framework для безопасности API
7 декабря 2022 г.Объяснение того, как расширить безопасность API с модели глубокоэшелонированной защиты на модель нулевого доверия
<цитата>"Пандемия заставила предприятия как можно быстрее реализовать все виды проектов цифровой трансформации, и это почти наверняка является движущей силой такого всплеска атак",
— Питер Климек, технический директор Имперва.
API-интерфейсы DYKT используются уже более 20 лет. С тех пор API претерпели радикальные изменения — от ограниченного набора компаний, использующих API для решения конкретных задач, до бесконечного множества вариантов использования в средах DevOps всех размеров. API-интерфейсы можно найти в разделе «Разработка приложений» — «гибкая разработка», подключение клиентов и партнеров к услугам и поддержка инициатив цифровой трансформации.
Но что касается кибербезопасности, согласно исследованию ProgrammableWeb, с 2019 года ежемесячно добавлялось в среднем 220 новых API. Тем не менее, благодаря более широкому распространению API сегодня раскрывают больше конфиденциальных данных, чем когда-либо, что делает их ценной мишенью для атак.
Этот пост представляет собой введение в то, как сопоставить требования безопасности API, от глубокоэшелонированной защиты до модели нулевого доверия.
Предыстория — состояние безопасности API
Прежде чем рассказать о том, как защитить API, давайте посмотрим на текущую картину угроз, связанных с безопасностью API. Согласно Отчет о состоянии безопасности API от Salt Security:
* Количество атак API увеличилось на 681% за последние 12 месяцев. * 95% респондентов столкнулись с инцидентом, связанным с безопасностью API, за последний год. * 34% респондентов не имеют стратегии безопасности API * 62 % респондентов признали, что развертывание нового приложения замедляется из-за проблем с безопасностью API
Короче говоря, мы можем сказать, что большинство предприятий не готовы к атаке на основе API. Кроме того, опора на существующие инструменты безопасности и управления API, например брандмауэры веб-приложений (WAF) и шлюзы API, могла бы эффективно предотвратить инциденты безопасности и создать ложное ощущение безопасности.
А как насчет Shift-Left?
В отчете подчеркивается, что тактика сдвига влево не помогает, по крайней мере, в отношении безопасности API. Более 50 % респондентов заявили, что разработчики, команды DevOps или DevSecOps несут ответственность за безопасность API. К компаниям, которые тратят больше средств на подготовку к развертыванию, относятся:
- рекомендации по безопасному кодированию,
- сканирование кода и
- проверка вручную
Однако 85% признали, что их инструменты безопасности неэффективны для предотвращения атак API - Доказывая, что эти методы безопасности DevOps, хотя и важны, недостаточны.
Итак, какую защиту должна создать или внедрить организация для защиты от API-атак? Чтобы ответить на этот вопрос, во-первых, нам нужно понять распространенные атаки на API.
Текущий ландшафт угроз
В недавнем отчете о безопасности API Google Cloud источники угроз безопасности API являются:
- Неправильно настроенные API (40%),
- Устаревшие API, данные и компоненты (35%)
- Спам, оскорбления, боты (34%).
:::подсказка «Неправильно настроенные API» или «неправильные настройки безопасности» как категория являются наиболее известным источником угроз.
:::
Согласно другому исследованию, проведенному Imperva Research Labs, самая серьезная атака связана с удаленным кодом Выполнение (RCE) или удаленное включение файлов (RFI), которые подскочили на 271%. Хакеры используют атаки RCE или RFI для кражи информации о компании, компрометации серверов и порчи веб-сайтов или даже получения контроля над веб-сайтами.
Другие уязвимости API, согласно топ-10 OWASP API Security:
- Разветвление API DDOS,
- API-атаки нулевого дня
- украденные учетные данные,
- нарушение периметра,
- боковое перемещение брешей,
- утечка данных на выходе или
- захват ресурсов
Кибербезопасность: API — новая конечная точка
Как упоминалось выше, первая причина повышенного риска для безопасности API является бурным внедрением - многих API в среде. Например, приложение Kubernetes имеет сотни модулей и микросервисов. Каждый из них управляет полдюжиной или более API. (Это типичный сценарий в среде DevOps).
Теперь добавьте, что эти рабочие нагрузки микросервисов (и, следовательно, вызовы API) являются временными, работают в облаках, написаны на нескольких языках и используют разные протоколы. Другими словами, API создают сложную среду, в которой команде безопасности сложно контролировать работу API.
Во-вторых, API никогда не предназначались для доступа к внешнему миру. Тем не менее, это то, с чем мы столкнулись с уязвимостями, обнаруженными внутри стеков сетевых протоколов. Эти разработчики никогда бы не подумали, что их работы будут приняты в наши дни. В результате API имеют встроенные уязвимости и риски.
В-третьих, атаки и взломы становятся все более изощренными, особенно те, которые выполняются на этапе пост-аутентификации и авторизации. Они также более глубоки в полезной нагрузке данных API.
Следовательно, помимо аутентификации и авторизации необходимо обратить внимание на безопасность, а также на уровень полезной нагрузки данных приложений и API. Один из способов сделать это — представить безопасность API как аналог нашей традиционной безопасности конечных точек.
DiD (глубокоэшелонированная защита), снова!
Проблемы с безопасностью возникают и в повседневной жизни вне компьютеров. С самого начала истории человечества разные страны исследовали и практиковали множество защитных механизмов и укреплений. Этот опыт и идеи также применимы к безопасности конечных точек, сети и API.
Допустим, Endpoint Software аналогичен замку:
- Аутентификация личности эквивалентна удостоверению личности командира, и
- Приманки (или приманки на войне) уводят злоумышленников от высокопоставленных целей.
- Среди этих военных стратегий одним из наиболее эффективных способов является глубокоэшелонированная оборона (ЭЗ).
Подход DiD можно разделить на две области:
- Пограничная защита (антивирусные сигнатуры)
- Обнаружение/предотвращение вторжений (IDS/IPS/EDR)
Я объясню безопасность API с этими областями глубокой защиты одну за другой.
1# Защита границы
Пограничная защита — это самый простой тип защиты. Почти все компании вкладывают средства в защиту границ. В системе безопасности конечных точек мы используем сигнатуры и списки запрещенных IP-адресов для защиты от известных методов атак
.Являясь передовой линией защиты, этот уровень призван остановить 90 % всех атак, нецелевых и инициированных неквалифицированными людьми, не обладающими серьезными техническими знаниями или хакерским мышлением. В этом сценарии защита границ может достаточно хорошо противостоять этим неизбирательным атакам.
Что касается безопасности API, WAF отлично справляется с этой задачей. Он предлагает стандартные функции для защиты границ:
· Списки разрешенных и запрещенных IP-адресов,
· Механизм правил WAF,
· Ограничение скорости и
· внедрение ошибок/фаззинг.
В сочетании он может блокировать почти все массовые атаки.
2# Обнаружение вторжений (++)
Наблюдение за безопасностью — важнейший элемент предотвращения атак. После того, как хакер взломал периметр, нам нужен правильный способ определить, какой файл/процесс/трафик, вероятно, связан со злонамеренной атакой. В Endpoint Software у нас есть система IDS/IPS на базе хоста для проверки всех запросов, проходящих через главный вход.
Некоторые другие методы обнаружения, такие как обнаружение APT и машинное обучение, могут быть более интуитивно понятными для оценки направленных атак.
Другими типичными способами реализации поведенческого анализа являются:
· Приманки,
· EDR (обнаружение и реагирование на конечные точки) и
· Анализ угроз (файл и процесс).
Среди всех этих методов приманки являются одними из самых старых (с начала войн). Заманивая некоторые важные цели в ловушки/приманки, они могут анализировать поведение врага и даже помогать определять его местонахождение. В настоящее время мы перенимаем эту тактику и превращаем ее в технологии обмана.
В современном мире решения для обеспечения безопасности API предоставляют комбинации упомянутых методов; например, артефакты, собранные в приманках, могут затем отправляться в канал анализа угроз для использования WAF или защиты веб-приложений и API (WAAP). На этом уровне у нас есть аналогичные методы для улучшения видимости и скорости, чтобы остановить атаку:
· Сетевые приманки
· Отчет о недоставке (сетевое обнаружение и реагирование) и
· Анализ угроз (полезная нагрузка и сеть).
Использование ботов для выполнения атак с «подстановкой учетных данных» — еще одна распространенная тактика атак. Он пытается украсть ценные активы. Стратегия состоит в том, чтобы найти способ получить данные для входа, такие как просочившиеся электронные письма/пароли, а затем попытаться получить доступ к сетевым расположениям в пакетном режиме (латеральное движение). Безусловно, наиболее эффективная защита от подтасовки учетных данных исходит от источника: идентифицируйте бота среди реальных пользователей, чтобы перехватывать все запросы, сделанные ботом.
Таким образом, некоторые инструменты AppSec также оснащены функциями защиты от ботов, определенным типом обнаружения поведения в рамках безопасности API.
Когда безопасность API соответствует нулевому доверию
Я не говорю, что DiD бесполезен. Решения API и безопасности приложений, такие как защита WAF для организаций от массовых атак. Однако, как уже упоминалось, API создает сложную среду, и неправильная настройка усугубляет проблему.
При неубранном периметре может потребоваться более глубокий подход. Zero Trust, по сути, везде создает препятствия для злоумышленников, лишая их возможности перемещаться в пределах среды.
n Нулевое доверие – это комплексная система и стратегия безопасности. Для этого требуются строгие и унифицированные шаги проверки для всех терминалов, BYOD (Bring Your Own Devices), серверов, API, микросервисов, хранилища данных и внутренних служб.
n Основная идея Zero Trust заключается в том, чтобы превратить централизованную точку контроля в несколько микроконтрольных точек на каждом пути ваших приложений, включая API. Будь то внешний запрос внутреннего доступа, мобильный телефон или ПК, вызов API или HTTP-запрос, обычный сотрудник или генеральный директор, никому нельзя доверять.
Чтобы эффективно достичь такой цели, не останавливая и не замедляя работу ваших приложений, оркестрация и автоматизация будут решающими шагами.
Почему оркестрация и автоматизация имеют решающее значение для обеспечения безопасности API с нулевым доверием?
ZTA, NIST SP800–207 | Изображение автора
Чтобы объяснить их необходимость, давайте подробнее рассмотрим один из столпов архитектуры с нулевым доверием — доверие доступа пользователя/устройства. Этот метод защиты аналогичен предъявлению паспорта на КПП в аэропорту и удостоверения личности для покупки алкоголя.
Без соответствующей идентичности и полномочий невозможно войти в соответствующую систему. Именно здесь шлюз API становится сильным, поскольку он предоставляет некоторые ключевые функции аутентификации:
- Автоматическая ротация ключей
- Интеграция с несколькими системами аутентификации, такими как OKTA и Auth 2.0.
- Поддержка шифрования трафика TLS и mTLS
Существует два основных компонента доверия пользователей и устройств:
- Управление идентификацией и доступом
- Шлюз API со встроенной защитой
Представьте себе установку оборудования для идентификации во всех транспортных узлах, таких как аэропорты и высокоскоростные железные дороги. Вы также должны знать все маршруты ко всем транспортным узлам и обратно и применять меры безопасности.
На большом предприятии будут сотни систем, десятки тысяч API и микросервисов и сотни тысяч клиентов. Если у нас нет неограниченных ресурсов и времени, команда DevOps, безопасности или приложений не может определить и вручную добавить сотни тысяч проверок микроидентификации в современные приложения.
Все остальные столпы нулевого доверия Архитектура, приложение, рабочая нагрузка и данные также требуют такой же логики для принятия. Необходимо решение, которое:
- Он использует современную архитектуру,
- Работает в гетерогенных средах,
- Снижает эти риски (не только товары) и
- Делает все это автоматически в мультиоблачных средах.
- (необязательно) с открытым исходным кодом, чтобы обеспечить технологическую гибкость и творческий подход.
Как выглядит безопасность API Idea Zero Trust?
Чтобы использовать сложные и разнородные среды в API, решение Zero Trust API Security должно иметь возможность развертывания в нескольких форматах и, таким образом, поддерживать разные настройки, например:
- Докер-контейнер,
- Автономный обратный прокси-сервер,
- Агент для веб-сервера/сервера приложений или
- Встроен в контроллер входа Kubernetes.
Благодаря поддержке облака и современной архитектуры приложений автоматизация и масштабируемость будут обеспечены.
Но для поддержания оркестровки «агент» (или точка микроприменения) должна иметь возможность развертываться поверх существующего приложения без изменения существующей архитектуры, обеспечивая при этом минимальную задержку и максимальный контроль.
После рассмотрения форм-факторов развертывания и архитектуры также важно, чтобы уровень безопасности не снижался. Для подлинного внедрения Zero Trust обработка данных безопасности должна выполняться локально без передачи данных в другие облака или механизмы, например в облачную песочницу для анализа.
Если внешние стороны не находятся под нашим контролем, проверить доверие к доступу к данным/сети будет сложно. Есть и другие преимущества локального выполнения таких действий, например:
- Конфиденциальные данные не покидают защищенную среду.
- Вам не нужно передавать сертификаты и закрытые ключи третьим лицам.
- Отсутствие зависимости от сторонних поставщиков для обработки трафика.
Последняя часть — рассмотрение оркестровки. В идеале нам нужно решение, которое может встраиваться в среду приложения, в то время как оркестратор может управлять этими агентами и выполнять следующие операции:
- регистрация/отмена регистрации агентов
- обновление правил
- обновление конфигурации
- обновление программного обеспечения
- регистрация и
- Синхронизация данных.
Короче говоря, Zero Trusted API Security должен быть в различных формах, чтобы внедряться в современные среды приложений. Между тем, лучшее решение должно обеспечивать оркестрацию и все функции безопасности, которые могут предоставлять традиционные решения.
Итак, как вы знаете, нулевое доверие не является безупречным. Решения с нулевым доверием не могут полностью защитить от атак нулевого дня или социальной инженерии, хотя они могут значительно уменьшить поверхность атаки и ее влияние.
:::информация Чтобы узнать об архитектуре Zero Trust: Введение в Zero Trust Архитектура безопасности — концепция, а не продукт.
:::
Заключительные слова
API стали центральной нервной системой современных приложений, перенося важную информацию и данные из одной части приложения в другую или из одного приложения в другое. В результате безопасность API должна быть приоритетом при защите приложений. Это особенно актуально для общедоступных API, когда пользователи со всего мира получают доступ к программным компонентам и конфиденциальным данным.
Внедрение Zero Trust Framework смещает акцент с одной защиты на разные компоненты (пользователи, устройства, сети, приложения и данные). Это может помочь вам гарантировать, что каждая часть доступа к API, будь то внутри или за пределами периметра, находится под подходом наименьших привилегий и постоянно контролируется.
Спасибо, что прочитали. Да пребудет с вами информационная безопасность🖖.
Оригинал