От API-ключей к контролю доступа: переосмысление управления секретами

25 сентября 2026 г.

Столько, сколько существует программное обеспечение, обращающееся к API, мы решали одну и ту же задачу одним и тем же способом. Коду нужен секрет (ключ, токен, учетные данные), поэтому мы его предоставляем. Мы копируем его в файл конфигурации, переменную окружения, менеджер секретов или связку ключей ОС. Детали сильно менялись с годами. Но суть ответа оставалась неизменной: чтобы выполнить вызов, вызывающий объект должен владеть секретом.

Это допущение молчаливо служило опорой на протяжении двух десятилетий. Но скоро оно перестанет быть безопасным.

Чтобы понять почему, полезно проследить, как мы к этому пришли.

Мы продолжали совершенствовать хранение секретов

У управления секретами есть четкая линия прогресса, и каждый шаг на ней был реальным улучшением.

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

Внешняя конфигурация. Мы извлекли секреты из кода в переменные окружения и файлы .env. Это было действительно лучше: ключ перестал распространяться вместе с исходным кодом. Но он не перестал существовать в открытом виде; он просто переместился из репозитория в окружение, где каждый запускаемый вами процесс наследует его, независимо от того, нужен он ему или нет.

Централизованные менеджеры секретов. Затем появились HashiCorp Vault, AWS Secrets Manager, Azure Key Vault и их аналоги: единый источник истины с шифрованием в состоянии покоя, политиками ротации, политиками доступа и ведением журнала аудита в самом хранилище. Это текущий стандарт для большинства команд, и не без оснований. Он правильно решил задачу хранения.

Локальные хранилища и помощники по учетным данным. Параллельно связки ключей ОС, помощники учетных данных git и такие инструменты, как Postman Local Vault, хранили секреты вне общей инфраструктуры и в зашифрованном виде на машине разработчика.

Каждое поколение отвечало на вопрос «где мы храним ключ?» лучше, чем предыдущее.

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

Но самое главное, каждое из этих поколений делает одно и то же допущение относительно потребителя:

В момент вызова потребитель владеет настоящим секретом.

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

На протяжении большей части истории ПО это был достаточно безопасный компромисс. Агентная разработка превращает его в обязательство.

Агенты работают иначе

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

Этого достаточно, чтобы разрушить модель хранения. На вопрос «Где хранится ключ?» двадцать лет был удовлетворительный ответ, потому что вы клали его куда-то и знали, где он. Как только вызывающим объектом становится агент, честный ответ на вопрос «Куда попадает этот ключ?» звучит так: вы не можете знать это заранее — и реальный агентный трафик подтверждает это, распространяя один экспортированный ключ по хостам, процессам и форматам, которые никто не выбирал заранее.

Лучшее хранилище не может решить проблему, которая не связана с хранением.

Другой ответ: предоставляйте доступ, а не распространяйте секреты

Выход заключается в том, чтобы перестать улучшать место хранения секрета и изменить сам факт того, владеет ли им потребитель.

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

Это инвертирует модель. Управление секретами становится проблемой контроля доступа, а не хранения и распространения.

Инверсия: перестаньте выдавать каждому потребителю копию секрета и выдавайте им ссылку, которая разрешается только через прокси внутри вашей сети.

На практике эта модель обеспечивает:

• Ссылки на учетные данные вместо распределенных ключей, поэтому потребители владеют указателями, а не секретами.
• Разрешение внутри вашей сети, перед вашим существующим хранилищем секретов, поэтому открытый текст никогда не пересекает внешнюю границу и не попадает на уровень приложения, в логи или в облако поставщика.
• Криптографически подтвержденная идентичность вызывающего объекта, привязанная к владельцу, поэтому ссылка, скопированная с машины, бесполезна без соответствующей идентичности.
• Область действия на уровне операций, поэтому потребителю можно разрешить чтение и запретить удаление в рамках одного API.
• Доступ для каждого потребителя с возможностью отзыва в любое время, поэтому вы можете отключить одного вызывающего объекта, не затрагивая других.
• Атрибуция каждого вызова, поэтому запись аудита отвечает на вопрос, кто что сделал, а не просто фиксирует, что что-то произошло.
• Единая модель для людей, CI-конвейеров и AI-агентов, потому что «потребитель» никогда не был только человеком.

От распространения секретов к управлению доступом

Каждое поколение инструментов для работы с секретами отвечало на вопрос о хранении лучше предыдущего. Следующее отвечает на совершенно другой вопрос.

Единица, которой нам нужно управлять, — это больше не секрет, который вы храните в безопасности. Это акт доступа: конкретный вызывающий объект, делающий конкретный вызов, с конкретной областью действия, в конкретный момент.

Старый вопрос звучал так:

Где хранится этот ключ и зашифрован ли он?

Новый вопрос звучит так:

Кто (человек, конвейер или агент) имеет право сделать этот вызов, с какими ограничениями, прямо сейчас, и могу ли я это доказать и отозвать?

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

Как Postman Passport воплощает модель доступа в жизнь

В Postman это тот сдвиг, для которого мы создаем Postman Passport.

Запрос через Passport: ссылка поступает, прокси разрешает настоящий секрет внутри вашей сети, и целевой API видит обычный аутентифицированный вызов, в то время как секрет никогда не покидает вашу сеть.

Passport — это безопасная система доступа к API для вашей команды. Вместо того чтобы распространять ключи каждому потребителю, которому они нужны, система предоставляет доступ с помощью ссылок на учетные данные, в то время как реальные секреты остаются внутри вашей сети. Прокси-сервер безопасного доступа работает в вашей сети перед хранилищем секретов, которое вы уже используете (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, 1Password), и разрешает ссылки во время запроса. Ваши политики ротации, журналы аудита и политики доступа внутри этого хранилища продолжают действовать. Passport добавляет уровень поверх них, который не позволяет потребителям когда-либо увидеть разрешенное значение.

Все, о чем говорилось в предыдущем разделе, является основой дизайна:

• Идентификация является криптографической и привязана к владельцу, поэтому украденная ссылка бесполезна.
• Область действия проверяется до обращения к хранилищу и может быть ограничена вплоть до конкретной операции.
• Секреты разрешаются внутри вашей сети и никогда не передаются через облако Postman, журналы или записи аудита.
• Доступ предоставляется для каждого API и отзывается одной записью в вашей частной сети API: не нужно ротировать ключи или отслеживать списки рассылки.
• А поскольку потребителем не всегда является человек, та же модель охватывает CI-конвейеры и AI-агентов. Вы предоставляете агенту ограниченный и отзываемый доступ вместо того, чтобы передавать ему ключ, который он может скомпрометировать в подсказке, журнале или стороннем инструменте.

Последний пункт связывает это с более широким сдвигом, который происходит в индустрии. В то время как команды создают инфраструктуру для управления действиями агентов (шлюзы и плоскости управления, появляющиеся вокруг агентных систем), Passport управляет тем, какие учетные данные агент может использовать, не предоставляя ему сами учетные данные. Управление намерениями и управление доступом — это две стороны одной проблемы, и ни одна из них не решается просто улучшением хранения.

Если вы сегодня распространяете статические ключи среди потребителей, начните с честного вопроса, заданного в отношении одного API: если бы этого потребителя пришлось отключить сегодня днем, смог бы я доказать, что его доступ был прекращен к вечеру? API, для которых ответ звучит как «мы бы ротировали то, что вспомнили», — это те, где модель доступа окупает себя в первую очередь.

Postman Passport уже доступен. Укажите один ценный ключ на ссылку и наблюдайте, как реальный вызов проходит успешно, при этом секрет не приближается к вызывающему объекту — в этом вся идея, и это самый быстрый способ убедиться в ее эффективности.

👉 Попробуйте Postman Passport → usepassport.ai

Ресурсы

• Начало работы с Postman Passport
• Как Postman Passport хранит секреты API внутри вашей сети
• Обзор Postman CLI