Ключи на один запуск вместо вечных: Vercel, Postman, Pulumi и Auth0 об одном и том же

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

Четыре текста об одном

Vercel 22 октября объявила войну долгоживущим ключам. Сравнение у них с HTTPS: с машинной аутентификацией мы сейчас там же, где HTTPS был в 2010-м, до того как его сделали нормой для всего. Vercel опросила больше 1000 SaaS-вендоров, и только 8,4 % из них поддерживают безопасные способы входа. Сама Vercel пишет, что потратила тысячи инженерных часов на болезненные ротации ключей и больше не хочет. Их ответ: OIDC-федерация, которая у них работает с 2024 года, набор форм OIDC UI для провайдеров API и Vercel Connect, где приложение получает токен под пользователя и нужные scopes в момент запроса, без ключа в переменных.

Postman 20 октября показала работу с секретами из командной строки. В Postman CLI от версии 1.69.0 секрет создаётся командой postman secret create, привязывается к переменной окружения по идентификатору, а в запросах пишется обычное {{PAYMENT_API_TOKEN}}. В коллекции и в файле окружения лежит ссылка на хранилище, значения там нет. Само значение вводится через одноразовую форму в браузере или скрытый ввод в терминале, так что помощник в терминале может начать процесс, а ключ вводит человек. Мне это близко: AI помогает мне с рутинной работой и отладкой, и я не хочу, чтобы в истории его команд лежали ключи.

Auth0 22 октября выпустила Terraform-модули, первый из них, b2b-saas-starter, уже в Terraform Registry. Один блок модуля создаёт приложение, API, настройки тенанта, защиту от атак и MFA, а внутри уже включены проверка прав на API, PKCE и ротация refresh-токенов с трёхсекундным окном для параллельных запросов. Главное для меня здесь то, что ротация включена по умолчанию.

Pulumi 15 октября добавила выпуск OIDC-токенов для любого сервиса в Pulumi ESC. Провайдер fn::open::oidc подписывает короткий токен с нужной аудиторией в момент открытия окружения, сервис проверяет подпись и выдаёт свой доступ. Срок жизни от минуты до часа, по умолчанию час, и ESC ничего не хранит. Формулировка про хранимый ключ у них точная: он работает для любого, кто его прочитал, с любой машины, пока существует.

Что это значит для проката

Возьмём компанию по аренде автомобилей. У неё сайт бронирования, внутреннее приложение, AmoCRM, платёжный сервис и почта для договоров. У каждой связки свой ключ. Один лежит в .env на сервере, второй в настройках CRM, третий на ноутбуке разработчика, который делал приложение и уже ушёл. Срока нет ни у одного. Если один утечёт, узнать об этом неоткуда, а поменять значит перебрать все места, где он лежит, и что-то в этот момент сломать.

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

Как это устроено у меня

В сервисе «Кофе вместе», который я сделал в сентябре и октябре 2026 года, самый ценный секрет это логин оптового кабинета Tasty Coffee. Он хранится в закрытых переменных сервера, а токен поставщика живёт только в памяти процесса. Все внешние запросы идут через Nginx и gateway на Node.js: он удаляет присланные клиентом заголовки идентичности и сам определяет пользователя по подписанной HttpOnly cookie. Сессия администратора живёт 8 часов, после пяти неудачных попыток входа с одного адреса вход блокируется на 15 минут. Запросы к поставщику и к Google Таблице идут через внутренние прокси, недоступные из публичной сети. Это тот же принцип, что у Vercel и Pulumi, только на общем сервере с 2 ГБ памяти и без платных сервисов.

В PDR-компании в США, с которой я работаю с 2021 года, к серверу ходят сайт, суперапп, телефония и парсеры документов, и внутренний API я довёл до третьей версии. Какие именно доступы у каждой связки, я не раскрываю. Скажу только, что вопросы безопасности в компании идут ко мне, а сервер, VPN и сетевое оборудование обслуживаю сам.

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

Что я бы сделал

Составить список всех ключей и токенов: к CRM, платёжному сервису, SMS, почте, картам, AI-сервисам. Где лежит, что умеет, когда менялся.

Убрать ключи из кода и из файлов, которые копируются с машины на машину. На сервере закрытые переменные, в CLI и тестах ссылки на хранилище, как у Postman.

Там, где сервис поддерживает OIDC или короткие токены, перейти на них. Остальным, а по опросу Vercel их больше 90 %, ограничивать ключ правами и менять по расписанию.

Решить, что видит AI-помощник в терминале и в коде. У себя я даю ему работать с кодом, а значения ключей ввожу сам.

Проверить, что всё это можно сделать без разработчика: доступы ваши, список у вас.

О сервере как общем центре, который проверяет права: статья Сервер: данные, доступ и выполнение процесса. По направлениям: API-интеграции с понятными правилами передачи данных и инфраструктура, которую можно выпускать и восстанавливать. Сервер «Кофе вместе» описан в кейсе о сервисе общих заказов кофе, а внутренний API PDR-компании на странице собственный API для нескольких приложений. Из близких обзоров: скомпрометированный удостоверяющий центр, AI-агент на боевом сервере и песочницы для агентов и новый Git; раньше я писал про секреты разработки как контракт и API-ключи и утечки. Если не знаете, сколько у вас ключей и где они лежат, начните с этого списка, а дальше можно обсудить вместе. Обсудить задачу.