API-ключ: что это и как его хранить безопасно

API-ключ — это секретная строка, по которой сервис узнаёт, кто к нему обращается. Когда ваш сайт запрашивает данные у платёжной системы, а бот — у CRM, они предъявляют ключ. Сервис проверяет его и решает, разрешить ли запрос. По сути, ключ — это пароль для программы. Тот, у кого он есть, может работать с сервисом от имени вашей компании: читать данные клиентов, создавать заказы, иногда — списывать деньги.

Ключ, токен, логин и пароль

Термины часто смешивают. Логин и пароль подтверждают личность человека. API-ключ выдаётся приложению и обычно действует, пока его не отзовут. Токен доступа — временный ключ, который получают после авторизации, например по протоколу OAuth, и который истекает через заданное время. Для бизнеса разница важна: постоянный ключ опаснее при утечке, потому что работает бессрочно. Если сервис предлагает выбор, предпочитайте ключи со сроком действия или возможностью ограничить их права.

Как получают ключ

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

Как ключ передаётся

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

Где хранить

• В переменных окружения на сервере
• В специализированном хранилище секретов
• В менеджере паролей для доступа сотрудников

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

Ограничение прав

Хорошие сервисы позволяют создавать ключи с ограниченными правами: только чтение, только определённые разделы, только с определённых IP-адресов. Используйте это. Ключ для сайта, который показывает остатки, не должен уметь создавать платежи. Отдельные ключи для разных интеграций позволяют отозвать один, не ломая остальные. Называйте ключи понятно — «сайт, чтение остатков», «бот, создание заказов» — чтобы через год было ясно, какой ключ можно удалить.

Признаки утечки

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

Что делать при утечке

1. Отозвать скомпрометированный ключ в кабинете сервиса
2. Создать новый и установить его во всех местах, где он используется
3. Проверить журнал операций за период, когда ключ мог быть доступен посторонним
4. Найти источник утечки и устранить его
5. Если затронуты данные клиентов — оценить последствия и действовать по требованиям законодательства

Порядок в компании

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