Цифровая трансформация основана на API, который управляет новой операционной моделью, предоставляя прямой доступ к бизнес-логике, приложениям и данным. Хотя такой доступ очень удобен для сотрудников, партнеров и клиентов, он также делает API-интерфейсы мишенью для хакеров и вредоносных сетей. С появлением все большего числа атак и уязвимостей расширенная безопасность становится все более важной.
Существующие решения (например, контроль доступа, ограничение скорости и т. д.) обеспечивают базовую защиту, но их недостаточно для полного предотвращения вредоносных атак. Современным службам безопасности необходимо выявлять и реагировать на динамически меняющиеся атаки, которые используют уязвимость отдельных API, чтобы повысить вероятность успеха. Подумайте о том, какое захватывающее будущее, когда ИИ сможет обнаруживать API и другие аномальные действия, приводящие к утечке данных, автоматически блокировать атаки на всю инфраструктуру API и разрабатывать сложные решения. Такой подход обеспечивает глубокую видимость ИТ-инфраструктуры и позволяет специалистам по безопасности принимать незамедлительные меры при обнаружении вредоносного поведения.
нарушение API
В 2019 году крупнейшая австралийская компания по оценке недвижимости LandMark White столкнулась с уязвимостью API, которая привела к утечке данных об оценке недвижимости и информации о клиентах. В этом случае доступ к API, предназначенному для внутреннего использования, возможен из-за пределов корпоративного домена.
Нарушения привели к разным уровням корпоративных нарушений, включая захват учетных записей, кражу личной информации и фотографий, а также извлечение номеров кредитных карт. После взлома репутация компании была подорвана, и ее клиенты и банковские партнеры поспешили найти другие альтернативы.
Процесс от утечки до обнаружения уязвимости занял недели или месяцы, в то время как для полного устранения других подобных нарушений потребовался почти год. За исключением LandMark White, информация многих людей до сих пор не защищена, что очень опасно. Чтобы понять, как защититься от этих угроз, мы должны сначала понять потенциальные уязвимости, создаваемые API.
Уязвимость API
В настоящее время многие предприятия полагаются на неадекватные меры безопасности для защиты своих API. Хотя инструменты управления API предоставляют некоторые важные функции безопасности, включая аутентификацию и ограничение скорости, эти методы часто не могут предотвратить атаки, специально созданные для взлома API, данных и систем, к которым они предоставляют доступ.
1. Неполная проверка
Отсутствие проверки разрешений является повторяющимся шаблоном уязвимости в недавнем потоке взломов API. Эти недостающие проверки разрешений выявляют уязвимости в рабочих API. В некоторых случаях из-за полного отсутствия контроля доступа информация API оставалась открытой, что позволяло злоумышленникам с базовыми навыками проводить вредоносные атаки.
В случае с Facebook, USPS и Verizon/LocationSmart хакеры использовали определенные учетные записи для перепроектирования поведения API, чтобы выявить по крайней мере одну уязвимость, которая могла обеспечить доступ к данным из других учетных записей без надлежащей проверки учетных данных, и все они маскировались под обычных пользователей. Эта технология может обеспечить доступ к большому количеству счетов и успешно использовалась для нарушения работы некоторых банков и страховых компаний.
Если приложение вызывает API, указанная выше уязвимость может быть не обнаружена. Потому что можно получить злонамеренный доступ, пропуская клиентские приложения (например, веб-приложения) и напрямую вызывая API для наблюдения за данными и управления потоком. Клиентские приложения значительно ограничивают способы ограничения API через пользовательский интерфейс, а зависимость от приложения может немного улучшить безопасность, особенно если тестирование не выполняется вне приложения на уровне API.
Помимо управления доступом, безопасность API должна также включать проверку содержимого. Инцидент с сервером API для Kubernetes, обнаруженный (и исправленный) в начале 2019 года, показывает нам, что отсутствие контента безопасности может быть фатальным. Весь инцидент начался с того, что пользователи, авторизованные для отправки запросов на исправление к API-серверу Kubernetes, могли отправлять перерасходованные специальные исправления. Загрузка ресурсов во время этого процесса приводит к DoS-атаке на сервер API.
Эксплуатация таких уязвимостей может сильно нарушить работу сервисов, исправление сервера Kubernetes API включает возврат ошибки типа 413, если входящий патч JSON содержит более 10 000 операций. Этот тип проверки содержимого легко настроить в API Gateway, но его часто упускают из виду, поскольку для этого требуется выйти за рамки автоматически сгенерированных схем JSON, которые определяют только простые типы правил, которые требуют вмешательства человека для определения необходимости конкретной проверки. правильная настройка и тестирование.
2. Отсутствие видимости API
На данный момент распространение API только увеличит их уязвимость. API-интерфейсы развертываются быстрее, чем когда-либо, и в некоторых случаях постоянное стремление к инновациям, уменьшению трения и созданию новых потоков доходов от множества разных команд может привести к непреднамеренным последствиям недоступности API.
Поэтому неудивительно, что многие заинтересованные стороны сообщают об отсутствии информации обо всех API, развернутых в их организациях. Тот факт, что многие уязвимости, связанные с API, обнаруживались месяцами, если не годами, еще раз иллюстрирует отсутствие понимания общей структуры API.
Кроме того, некоторые API не являются общедоступными и могут рассматриваться только как детали реализации всего проекта. Это позволяет скрыть их с точки зрения безопасности, но, в свою очередь, приводит к отсутствию конкретных соображений безопасности. В других случаях API-интерфейсы, возникающие из разных частей организации, могут привести к несогласованности политик безопасности из-за разнородных платформ.
Несмотря на это, эти API-интерфейсы могут быть столь же уязвимы, как и общедоступные API-интерфейсы, поскольку хакерам так же легко их реконструировать. Чтобы восполнить эти пробелы, нам нужно четкое понимание того, что необходимо защищать, а глубокое понимание трафика API обеспечивает отправную точку для повышения безопасности сети.
3. Думая не только о проверке токенов
Проверка токена и проверка личности запрашивающего пользователя часто недостаточны для поддержки инфраструктуры API. Возможность применять детальный контроль доступа на уровне API не только логична, но и станет нормой, поскольку API становятся наиболее распространенным каналом доступа к данным разработчиков.
Более того, правила, определяющие, какие данные человеку разрешено запрашивать, определяются не только поставщиком API, но и пользователем. Эти решения позволяют пользователям ограничивать приложения, когда речь идет об имеющихся у них данных, поэтому стратегия управления пользовательскими API тесно связана с основными концепциями безопасности API.
В основе базовой безопасности API лежит определение процессов проверки и управления. Обновленные API необходимо проверять, начиная с определения ответов на вопросы, в том числе:
- Какие разрешения необходимы для доступа к API?
- Кто является предполагаемым запрашивающим?
- Какие базы данных и данные будет использовать служба для чтения и записи?
- С какими другими сервисами взаимодействует этот API?
- Как выглядят входные и выходные параметры и как они должны быть ограничены?
Ответы на эти вопросы подскажут нам, какие политики безопасности следует принять для новых API, которые скоро будут выпущены.
4. Расширение безопасности старого базового API
Даже при правильном фундаменте безопасность может сохраняться только в той мере, в какой она настроена. Когда конфигурация подвержена человеческим ошибкам, риск того, что уязвимость API заставит ее протестировать и запустить в работу, увеличивается с увеличением сложности уровня API. Даже если вы предпримете все меры для предотвращения этого, вы все равно рискуете выявить уязвимости в самом API.
Например, хакеры часто крадут токены с помощью фишинговых атак, которые позволяют им создавать законные приложения. Кроме того, клиентские приложения, которые вызывают API от имени пользователей, несовершенны и плохо хранят секреты. Это может быть так же просто, как обратный взлом ключа API путем просмотра кода JavaScript приложения или просмотра трафика API через прокси-сервер HTTPS.
Например, исследование, проведенное Университетом штата Северная Каролина, показало, что GitHub — это кладезь секретов приложений для вызова API, из более чем 100 000 репозиториев которого утекают токены API и ключи шифрования. GitHub сделал это открытие, внедрив новую функцию безопасности, которая сканирует токены из кода, отправленного на его платформу.
Злоумышленники также используют трояны удаленного доступа, такие как Mimikatz, для кражи учетных данных. Затем они используют украденные учетные данные, чтобы выдать себя за пользователя и получить токены. Еще одна распространенная уязвимость — вброс учетных данных на сервере авторизации, использующий набор учетных данных, извлеченных из предыдущих уязвимостей.
В каждом случае злоумышленник использует уязвимость в пользовательском клиентском приложении или сервере авторизации для получения токена, а не в самом API. Это вызывает много вопросов, потому что токены кажутся законными, а хакер выглядит как действительный пользователь. Это готовит почву для «утечки» пользовательских данных через API, и даже при наличии надлежащих политик контроля доступа и принудительного исполнения эти атаки, за исключением тех, которые связаны с уязвимостями в самом API, остаются незамеченными традиционными инструментами безопасности API, и часто в течение нескольких месяцев. или даже лет.
Команды безопасности могут приложить немало усилий, чтобы информировать пользователей и разработчиков API о безопасности клиентских приложений и инфраструктуре идентификации, но они по-прежнему могут подвергаться риску уязвимостей производственного API и скомпрометированных учетных данных. Поставщики API должны учитывать это в своих мерах безопасности, независимо от того, является ли API внутренним или внешним. Однако можно ускорить обнаружение атак и автоматически блокировать атаки, применяя искусственный интеллект (ИИ).
Применение ИИ к безопасности
Группы безопасности могут обучать механизмы машинного обучения на основе поведения API, которое обычно демонстрируют пользователи. Используя искусственный интеллект, команды могут определять хороший и плохой трафик, а также попытки и продолжающиеся атаки без вмешательства человека.
1. Обнаружение нетипичного поведения с помощью ИИ
При каждом вызове API данные токена доступа или файла cookie, а также время и последовательность определенных операций могут быть предоставлены модели ИИ. Во время выполнения этот механизм машинного обучения использует поведенческие модели для выявления признаков потенциальных угроз, таких как использование определенного токена или файла cookie вне легитимных приложений, утечка или изменение данных и многое другое.
Использование обнаружения аномального использования на основе ИИ может значительно ускорить обнаружение угроз, превращая обнаружение атак с месяцев в минуты или секунды. При обнаружении подозрительной активности API токен доступа или файл cookie, используемый для получения доступа к API, может быть занесен в черный список или отозван, что немедленно блокирует доступ любой стороны, использующей этот токен, на всех конечных точках API. Если за этими атаками стоят одни и те же идентификаторы пользователей, сами идентификаторы пользователей должны быть занесены в черный список и отмечены соответствующим образом. Этот тип мониторинга, обнаружения и блокировки атак достигается без вмешательства человека.
2. Используйте API-приманки
Использование ловушек API также может ускорить обнаружение хакерских атак API. Это включает в себя добавление поддельных ресурсов API, которые возвращают, казалось бы, действительные ответы запрашивающим сторонам. Ловушка использует склонность хакеров к поиску способами, недоступными для легитимных приложений, эффективно переворачивая стол, чтобы использовать знания, связанные с типичным взломом.
Когда хакеры попадают в эти ловушки, их мгновенно узнают. В то же время связанные с ними IP-адреса и токены доступа (если они были у них на тот момент) автоматически считались утечкой и заносились в черный список. Слушатели ловушек могут распознать, что эти запросы вряд ли будут поступать из реального приложения, потому что эти ресурсы API не существуют по закону. Эти меры безопасности не требуют специальных правил или расширенной конфигурации.
3. Заблокировать и исправить
Конечно, обнаружение — это только часть решения, не менее важна и обратная связь системы. Как только обнаруживается, что личная информация клиента (например, токены) была скомпрометирована, эта информация должна быть немедленно отозвана или занесена в черный список. Кроме того, эти события должны быть зарегистрированы для последующего просмотра, а система управления информацией и событиями безопасности (SIEM) должна быть уведомлена о подобных ситуациях в будущем.
Подробная информация о методах и ресурсах, вызываемых до обнаружения и блокировки скомпрометированных учетных данных, должна быть задокументирована, а информация, представленная в отчете, позволяет поставщику API, команде DevOps или команде безопасности предпринять необходимые действия для устранения или устранения ущерба, причиненного атака.
Технологии и инструменты для защиты API
Защитить свой API с помощью правильных технологий и инструментов — проще всего. Сейчас существует множество технологий и инструментов, способных в наибольшей степени защитить API от сетевых атак и хакеров, самый простой — использовать API-шлюз (API-шлюз) для предотвращения неизвестных атак и вторжений посредством фильтрации трафика и мониторинга узлов. Например, зарубежный Amazon API Gateway (под Amazon), отечественныйGOKU API Gateway(EOLINKERОн может легко реализовать требования системы шлюза. В области шлюза API также есть некоторые активные платформы с открытым исходным кодом, такие как Netflix Zuul, Kong на основе Nginx и т. Д. В настоящее время им уделяется меньше внимания, и они не будут представлены. При выборе шлюзовой системы, безопасности, удобства и локализации необходимо обратить особое внимание на несколько ключевых факторов.Все эти шлюзы имеют определенные гарантии безопасности API, чтобы можно было предотвратить утечку частной информации.
в заключении
Безопасность API — важная часть программы цифровой трансформации, которая может улучшить кибербезопасность по всем каналам. Во времена кризиса внедрение инфраструктуры безопасности API, ориентированной на идентификацию, лежит в основе современной стратегии цифровой трансформации. Обеспечение безопасности API также требует глубокого понимания активности API и обнаружения уязвимостей с помощью ИИ. В обоих случаях требуется наложение базовых элементов управления доступом к API, чтобы перехватывать атаки, исходящие из уязвимостей API, и устранять риск человеческой ошибки в конфигурации традиционных систем безопасности API.
Ссылка: Джинеш Таккар, Безопасные API с использованием искусственного интеллекта
Оригинальная ссылка:D zone.com/articles/цвет...
Источник изображения: Интернет