Предприятия: хватит раздавать API-ключи! (Как Postman покончил с бесконтрольным распространением учетных данных с помощью Passport)

6 октября 2026 г.

Поскольку Postman стремительно перешел к созданию агентов и хостингу агентичных воркфлоу, мы знали, что для снижения возросших рисков необходимо решить проблему расползания учетных данных. Мы задумали и создали Postman, чтобы помочь решить нашу собственную проблему... но мы знали, что это необходимо всей индустрии. В процессе работы Passport также разрешил вторую, связанную с ней проблему: у нас не было возможности указать, какие конкретные API (или даже какие эндпоинты внутри API) разрешено вызывать тому или иному человеку или агенту. Как только ключ появлялся, он обычно мог получить доступ к гораздо большим ресурсам, чем следовало. Это наш пошаговый путь к безопасному управлению учетными данными и одновременному ограничению доступа к API.

Большинство подходов к безопасности учетных данных API (включая хранилища секретов, статические сканеры, политики ротации и средства контроля на стороне клиента) работают на минимизацию ущерба уже после выпуска ключа. Владение — это проблема, которую динамические секреты и недолговечные токены решить не могут... они лишь сокращают окно атаки. Как только ключ попадает на машину инженера, он распространяется по инструментам, логам и окружениям. Даже GitGuardian’s State of Secrets Sprawl 2026 report обнаружила, что один живой секрет в среднем оказывается в восьми местах на одной и той же машине. Мы наблюдали ту же тенденцию и в Postman.

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

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

Точная инвентаризация

Начав с инвентаризации, мы хотели обеспечить полную видимость масштабов расползания секретов по всей нашей экосистеме. Все мы знаем, что секреты томится на эндпоинтах (ваши стандартные заметки в Apple Notes / файлы .env, которые переиспользовались в 50 проектах для удобства)... несмотря на то, что IT-отделы или отделы облачной инфраструктуры развертывают хранилища секретов, а команды по повышению осведомленности о безопасности предупреждают нас о правильных методах обращения с учетными данными. Мы проверили это на практике, взяв скрипт Osquery и просканировав нашу базу пользователей-инженеров (.env/.bash_history и т. д.). Проанализировав наше окружение, мы обнаружили, что риск сосредоточен всего у нескольких пользователей; фактически на один ноутбук приходилось 14% нашего общего риска!!! Исторически мы бы попросили этих пользователей сменить и перенести свои секреты в хранилище до того, как у нас произойдет инцидент или ИИ приведет к непредвиденному результату из-за обнаружения ключа. Это детективный контроль, а не превентивный, и он редко реализуется на практике в масштабе.

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

Osquery

Эффективная политика

Мы строили наш подход на основе сценариев использования для двух типов пользователей: людей и агентов.

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

Мы использовали систему управления мобильными устройствами (в нашем случае — JAMF), чтобы установить Passport на наши ноутбуки, и оставили ее работать в течение двух недель, прежде чем писать какие-либо правила. Затем мы вывели политику на основе пользователя, организации, отдела и роли... и того, к каким приложениям каждый из них обращался.

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

Во-вторых, мы определили наши разрешенные политики. Мы проанализировали наши самые критически важные и ценные данные, системы и активы (Zoom, Anthropic, OpenAI, Salesforce, и это лишь некоторые из них). В случае с агентами вы диктуете политику, чтобы обеспечить принцип наименьших привилегий. Поскольку список вызовов агента выводится из кода (потому что кто-то его написал), политику можно вывести довольно легко. Например, Yoda — наш go-to-market агент, и мы ограничили его область видимости перед первым запуском, прочитав импортируемые им модули инструментов: 16 учетных данных, 12 провайдеров, 42 эндпоинта, что составляет лишь подмножество того, к чему он мог бы получить доступ без политики и сырого API-ключа. В этом и заключается магия снижения рисков (меньше расползания учетных данных и управления доступом к API).

Ограничивая эндпоинты и сервисы, к которым могут обращаться ваши команды, Passport также укрепляет общую систему управления доступом к API. Доступ перестает быть принципом «все или ничего», привязанным к модели разрешений вендора, и становится тем, что ваша команда безопасности действительно определяет: эта идентичность может вызывать этот эндпоинт для этой цели и ни для чего больше. Инженеру, отлаживающему интеграцию платежей, не нужен постоянный доступ к каждому эндпоинту в этом API — только к тем, которых касается его задача. Агенту, созданному для чтения тикетов поддержки, не нужна возможность их удалять. Passport позволяет провести эту черту один раз, на уровне каталога, и сделать так, чтобы она действовала везде, где появляется эта идентичность, вместо того чтобы полагаться на API каждого вендора в вопросах предоставления собственных детализированных областей видимости (большинство из них этого не делают).

Ключевое наблюдение: множество пользователей все еще активно взаимодействуют с ИИ и имеют по одному ключу на пользователя, поэтому персональные пространства имен отлично для этого подходят. У Claude сотни эндпоинтов, и большинству пользователей нужен только эндпоинт /messages, но вам захочется сохранить по одному API-ключу на каждого разработчика в целях контроля затрат.

Принудительное исполнение

Момент, на котором буксует большинство внедрений систем безопасности: принудительное исполнение. Passport имеет интерфейс, поставляемый «из коробки» (которого будет достаточно для небольших организаций), но он также поддерживает API для интеграции вашей платформы управления IT-услугами (например, ServiceNow или Serval). Наша платформа называется Posty, и мы в основном осуществляем поддержку через Slack.

Интерфейс:

Интегрированный UX (Posty):

Обнаружение

Непрерывное обнаружение завершает цепочку, представляющую собой комбинацию методов обнаружения секретов (помните Osquery из раздела об инвентаризации?). Теперь, когда Passport в вашем виртуальном частном облаке видит каждый запрос, проходящий через прокси безопасного доступа (Secure Access Proxy), команды безопасности получают единый аудит-след в реальном времени для определения будущих политик. Каждый вызов логируется с указанием подтвержденной идентичности инициатора, а также статуса вызова и информации OTEL. Это позволило нам настроить оповещения об обнаруженных секретах / блокировках / ошибках, а также о вызывающих опасения условиях, связанных с объемом и скоростью запросов. Эти данные поступят в нашу отчетность о соответствии стандартам вроде SOC 2, ISO 27001, HIPAA и PCI DSS, а затем в конечном итоге вернутся на этапы инвентаризации и формирования политик, что со временем существенно повысит общую эффективность инструмента.

Трансформационные достижения

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