API-ключи для serverless-функций: авторизация на шлюзе
Проверяйте API-ключ на уровне шлюза до запуска кода обработчика: никакого middleware в каждой функции, никаких случайно открытых эндпоинтов, а ротация ключа не требует редеплоя. Привязывайте разные ключи к разным маршрутам для мультитенантных и внутренних API.
Обновлено: 2026-06-28
Кратко
Суть ответа
API-ключи для serverless-функций: авторизация на шлюзе. Inquir проверяет API-ключ на уровне шлюза — код обработчика запускается только после успешной проверки. Маршруты с authType api-key ждут ключ в заголовке X-Api-Key; в обработчике нет boilerplate авторизации, а при включённой на маршруте авторизации не бывает случайно открытого эндпоинта.
Когда подходит
- Публичные API-эндпоинты, которые никогда не должны оказаться случайно открытыми
- Эндпоинты инструментов AI-агента, где модель использует отдельный ключ на группу инструментов
- Внутренние вызовы функция–функция, где нужна авторизация без boilerplate в обработчике
На что обратить внимание
- На каждой новой функции разработчик должен вспомнить про middleware авторизации. Часть случаев ловит код-ревью, остальное — инциденты в продакшене.
- Общие утилиты (функция validateApiKey()) помогают, но не убирают корень проблемы: проверку нужно включать, а не выключать.
Нагрузка и где ломается
Что бывает без авторизации на шлюзе
- Middleware авторизации в каждом обработчике: логика дублируется, на новых маршрутах её легко забыть
- Случайно открытые эндпоинты: задеплоили функцию без middleware — и она доступна всем
- Ротация ключа требует правок кода: если ключ проверяется внутри обработчика, ротация означает редеплой
- Нет привязки к маршрутам: один общий ключ на все функции — и ротация бьёт по всем вызывающим сразу
Проверка ключа прямо в обработчике serverless-функции — распространённый паттерн, который работает, пока функций мало. Когда их 20 и впереди security-ревью, обнаружить, что у трёх эндпоинтов нет middleware авторизации, потому что кто-то забыл скопировать паттерн, — это инцидент, который ждёт своего часа.
Компромиссы
Почему middleware авторизации в каждой функции хрупок
На каждой новой функции разработчик должен вспомнить про middleware авторизации. Часть случаев ловит код-ревью, остальное — инциденты в продакшене.
Общие утилиты (функция validateApiKey()) помогают, но не убирают корень проблемы: проверку нужно включать, а не выключать.
Как помогает Inquir
Авторизация на шлюзе: включена по умолчанию
Inquir проверяет API-ключ на уровне шлюза — код обработчика запускается только после успешной проверки. Маршруты с authType api-key ждут ключ в заголовке X-Api-Key; в обработчике нет boilerplate авторизации, а при включённой на маршруте авторизации не бывает случайно открытого эндпоинта.
API-ключи управляются на уровне воркспейса. Ротируйте ключ в конфигурации шлюза — он сразу вступит в силу для всех маршрутов с этим ключом, редеплой функции не нужен. Привязывайте разные ключи к разным группам маршрутов: внутренний API и доступ внешних партнёров.
Что вы получаете
Возможности авторизации на шлюзе
Проверка до обработчика
Проверка ключа происходит на шлюзе до запуска кода функции. Неверный ключ получает 401 без вызова функции — ни биллинга, ни выполнения обработчика.
Никакого boilerplate в обработчике
Не нужно добавлять middleware в каждую функцию. Обработчик считает вызывающего проверенным; логики авторизации в его коде нет.
Ротация ключа без редеплоя
Ротируйте API-ключи в конфигурации шлюза. Изменение сразу действует на всех маршрутах с этим ключом. Код функции менять не нужно.
Ключи в разрезе маршрутов
Разные API-ключи для разных групп маршрутов. Внутренние админские маршруты используют не тот ключ, что партнёрский API.
Что дальше
Как настроить авторизацию по API-ключу в Inquir
Включить API-ключ на маршруте шлюза
В конфигурации шлюза включите авторизацию по API-ключу для маршрута или группы маршрутов. Укажите, какие ключи для этого маршрута действительны.
Раздать ключ как секрет
Передайте значение X-Api-Key вызывающим через свой процесс работы с секретами; для функций, которые вызывают друг друга, храните его в секретах воркспейса.
Писать обработчик для проверенного вызывающего
Обработчику не нужно проверять API-ключ — шлюз уже это сделал. Сосредоточьте логику обработчика на бизнес-валидации.
Пример кода
Обработчик при авторизации на шлюзе: без boilerplate
Шлюз проверяет API-ключ до запуска этого кода. Обработчик может считать вызывающего проверенным и целиком заниматься бизнес-логикой.
export async function handler(event) { // No API key validation needed — gateway already checked X-Api-Key before invoke const customerId = event.pathParameters?.customerId; if (!customerId) return { statusCode: 400, body: JSON.stringify({ error: 'customerId required' }) }; const customer = await db.customers.findById(customerId); if (!customer) return { statusCode: 404, body: JSON.stringify({ error: 'not found' }) }; return { statusCode: 200, body: JSON.stringify({ customer }) }; }
export async function handler(event) { // This route uses a different API key than the public routes // The key is scoped to internal tool callers (AI agent orchestrator) const { query } = JSON.parse(event.body || '{}'); const results = await search.query(query); return { statusCode: 200, body: JSON.stringify({ results }) }; }
Когда подходит
Когда нужна авторизация по API-ключу на шлюзе
Когда это уместно
- Публичные API-эндпоинты, которые никогда не должны оказаться случайно открытыми
- Эндпоинты инструментов AI-агента, где модель использует отдельный ключ на группу инструментов
- Внутренние вызовы функция–функция, где нужна авторизация без boilerplate в обработчике
Когда лучше выбрать другое
- Эндпоинты, где нужно проверять пользователя (JWT или сессия), а не сервисный API-ключ, — для них сочетайте ключ на шлюзе с проверкой пользователя в обработчике
Частые вопросы
Частые вопросы
Можно ли сочетать API-ключ и JWT?
Да. Включите API-ключ на шлюзе для маршрутов «сервис–сервис», а на пользовательских маршрутах проверяйте JWT внутри обработчика. У разных маршрутов могут быть разные модели авторизации.
Что происходит с запросами с неверным API-ключом?
Шлюз возвращает 401 до запуска обработчика. Функция не вызывается, и вызов не тарифицируется.
Как ротировать скомпрометированный ключ?
Удалите скомпрометированный ключ из конфигурации шлюза и добавьте новый. Запросы со старым ключом сразу начнут получать отказ. Новый ключ раздайте легитимным вызывающим через свой процесс управления секретами.