3 варианта использования безопасности сторонних API

Безопасность API сторонних поставщиков требует индивидуального подхода для различных сценариев. Узнайте, как адаптировать стратегию безопасности к исходящим потокам данных, входящему трафику и взаимосвязям SaaS-SaaS.

Безопасность API сторонних поставщиков требует индивидуального подхода для различных сценариев. Узнайте, как адаптировать стратегию безопасности к исходящим потокам данных, входящему трафику и взаимосвязям SaaS-SaaS.

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

Согласно недавнему опросу Gartner , 71% руководителей ИТ сообщают об использовании сторонних интерфейсов прикладного программирования (API) в своих организациях. Многие руководители по безопасности и управлению рисками должны сосредоточиться на безопасности API при работе с потреблением и интеграцией со сторонними API, а не на раскрытии API первой стороны.

Кроме того, когда речь идёт о сторонних API, многие меры по исправлению, такие как исправление уязвимостей, не находятся под прямым контролем организации. Поэтому подход должен быть принципиально иным по сравнению с API первой стороны.

Руководителям служб безопасности следует обратить внимание на три варианта использования.

Вариант использования 1: обнаружение и управление исходящими потоками данных в сторонние API

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

Основной риск заключается в том, что конфиденциальные данные могут быть отправлены в API. Эта деятельность может противоречить корпоративным политикам или отраслевым нормам. Сторонние API также могут подвергать данные или данные клиентов опасности. Например, злоумышленник может украсть платежные данные клиентов, используя уязвимый платежный API. В зависимости от сценария, внедрение вредоносной нагрузки также может повредить базу данных делового партнёра.

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

Руководители служб безопасности также должны взаимодействовать с командой, которая управляет снабжением, закупками и управлением поставщиками (SPVM), а также сторонними киберрисками, чтобы гарантировать проверку приложений «программное обеспечение как услуга» (SaaS) и их соответствие политикам организации.

Лидеры безопасности также должны выявлять утечку конфиденциальных данных, отслеживая исходящий трафик в этих обменах API. Обычно это достигается путём внедрения возможностей предотвращения потери данных (DLP). Могут применяться разрозненные инструменты, например, инструменты безопасности (SSE), DLP и защиты API, все они имеют определенные возможности DLP.

• Дифференциаторами могут быть: возможность инструмента категоризировать данные во время передачи («на лету») или возможность выполнения действий по исправлению ситуации, таких как блокировка обмена, анонимизация или шифрование данных.

• Точка мониторинга также может иметь значение, поскольку некоторые инструменты могут быть уже установлены или иметь доступ к незашифрованному трафику.

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

• Внутренние соображения, такие как то, какая команда владеет каждым инструментом и управляет им, также будут играть роль при выборе инструмента.

Наконец, руководители по безопасности могут реализовать надлежащую аутентификацию и авторизацию клиента API (в этом сценарии — приложения) с помощью механизмов, предлагаемых поставщиком API. Как минимум, отдавайте предпочтение токенам, а не ключам API для авторизации. Оцените, насколько непрозрачные и подтверждающие владение токены (или, по крайней мере, часто меняющиеся учётные данные доступа) и закрепление сертификатов могут эффективно снизить риски утечки и перехвата токенов в конкретных случаях использования. Помните о технических трудностях, которые могут потребоваться для их настройки, и о проблемах с проверкой трафика.

Вариант использования 2: Защита от входящего трафика от сторонних API

В этом варианте использования организация использует сторонний API, и данные являются входящими. Типичным примером может быть корпоративное приложение, которое делает вызов API для получения данных от коммерческого поставщика SaaS или бизнес-партнёра.

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

Эксфильтрация данных все ещё является риском для этого варианта использования, и многие рекомендации из первого варианта использования все ещё применимы здесь. Если исходящий запрос API содержит конфиденциальные данные, эти данные могут быть перехвачены. Например, если вызов API запрашивает список ресторанов на основе координат GPS, указанные координаты GPS могут быть перехвачены, если соединение не защищено. Самое главное, сторонний API может извлекать определенные данные предприятия. (Подумайте, например, об API, извлекающем данные о клиентах из определенных экземпляров приложения CRM SaaS.)

Руководители служб безопасности должны выполнять проверку ввода. Попросите разработчиков добавить элементы управления проверкой ввода при приёме любых входных данных, включая входные данные от сторонних API. Это предотвратит широкий спектр атак со стороны вредоносного ввода, например, атаки с использованием SQL-инъекций. Инструменты тестирования безопасности приложений (AST) могут помочь автоматизировать эти проверки.

Используйте функциональность брандмауэра веб-приложений из встроенного инструмента защиты веб-приложений и API для добавления мер противодействия инъекционным атакам и другим типам вредоносного ввода.

Наконец, проверьте входные данные с помощью антивируса, «песочницы» или решения по обезвреживанию и реконструкции контента, интегрировав приложения, как правило, через протокол адаптации интернет-контента или API, с одним или несколькими из этих инструментов.

Вариант использования 3: обнаружение, проверка и управление данными для сторонних приложений, взаимодействующих через API

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

Эта ситуация становится особенно сложной, когда авторизованный пользователь приложения SaaS подключает его через API к неавторизованному приложению SaaS. Многие организации практически не будут иметь видимости существования соединения, не говоря уже о любых передачах данных через него. Во-вторых, видимость ограничена тем, что поставщики SaaS раскрывают через свои собственные API управления, поскольку нет чёткого места для вставки встроенного элемента управления. Основной риск в этом сценарии заключается в том, что приложение SaaS может раскрыть конфиденциальные корпоративные данные через API, и эти данные могут быть переданы в несанкционированное и даже неизвестное место, которое не было проверено службой безопасности.

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

Обнаружьте мошеннические токены доступа SaaS, запросив используемые приложения SaaS, где это поддерживается. Создайте и предложите пользователям политику подключения приложений SaaS через OAuth.

Для предыдущих вариантов использования свяжитесь с командой, которая управляет SPVM и сторонними киберрисками, чтобы убедиться, что приложения SaaS проверены и соответствуют организационным политикам, таким как политика безопасности данных и политикам стороннего обмена. Кроме того, инвентаризируйте взаимосвязи SaaS-SaaS; автоматизированные инструменты, такие как предложения SSPM, могут помочь обеспечить непрерывность этого процесса.

Адаптируя свои подходы к этим трем конкретным вариантам использования и их возможным вариациям, руководители служб безопасности могут устранить риски, которые сторонние API представляют для их организаций.

Мастер пера, обрабатывает новостную ленту.