Ключи интеграций клиентов SaaS: как не перепутать владельца

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

Определите владельца раньше, чем ищете секрет

В приложении должны различаться пользователь, организация, подключение к поставщику и отдельная версия секрета. Их нельзя заменять одной строкой «API-ключ». Сотрудник может работать в нескольких организациях, а у компании могут быть разные подключения к одному поставщику. До обращения к хранилищу сервис должен понимать, в чьих интересах выполняется конкретная операция.

Не принимайте идентификатор организации, присланный браузером, за достаточное доказательство права. Мы советуем сверять его с разрешённой операцией и принадлежностью рабочих объектов. Выбранная в интерфейсе компания помогает пользователю, но сервер всё равно должен проверить контекст. Аналогичное правило понадобится не только веб-запросам, но и обработчикам событий.

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

Выбор хранилища не заканчивает проектирование

В руководстве Azure по Key Vault для мультитенантных решений рассмотрены отдельные и общие хранилища. Выбор зависит от требований к изоляции и эксплуатации. Там же подчёркнуто: соглашение об именах с префиксом клиента помогает найти секрет, но не обеспечивает управление доступом. Пример Azure не означает, что каждому SaaS обязательно нужен этот продукт.

В OWASP Secrets Management Cheat Sheet рекомендуется ограничивать доступ к секретам по необходимым полномочиям и уменьшать ненужное взаимодействие людей с их значениями. Для приложения это означает отдельное решение: какой процесс может получить какие секреты и для какой операции. Доступ разработчика ко всем клиентским ключам не должен появляться просто ради удобной диагностики.

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

Матрица маршрутов использования

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

Фоновые задачи особенно легко теряют контекст

Пользователь нажал кнопку в одной компании, а задача выполняется позже общим обработчиком. Если владелец остался только в текущей сессии браузера, у фонового процесса нет надёжной связи с первоначальной операцией. Мы советуем включать подтверждённый контекст в модель задания и проверять его при обработке. Нельзя искать «первое активное подключение к поставщику» без привязки к владельцу.

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

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

Кеш и служебный интерфейс тоже участвуют в изоляции

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

В панели поддержки показывайте состояние подключения, условное обозначение и результат последней операции в объёме нужных полномочий. Не делайте кнопку «показать полный ключ» обычным способом понять, какая организация подключена. Мы советуем устранять неоднозначность моделью данных и диагностикой без секрета, а не демонстрацией клиентских учётных сведений.

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

Как проверить на двух учебных организациях

1. Создайте согласованные учебные организации с различимыми тестовыми подключениями. Используйте безопасные обозначения в отчёте, не копируя настоящие клиентские ключи.
2. Выполните штатные операции каждой организации и подтвердите выбор её подключения. Проверяйте результат у тестового поставщика, если это предусмотрено стендом.
3. Проверьте запрет на использование чужого подключения через собственную модель прав. Разрешённая проверка должна иметь заранее согласованный объём и ожидаемый результат.
4. Повторите операции после заполнения кеша, в фоновой очереди и после контролируемой ошибки. Убедитесь, что повтор не изменил владельца.
5. Отключите учебное подключение по сценарию продукта и проверьте ожидаемую остановку зависимых задач. Отдельно проверьте, что другая организация продолжает работать.
6. Примите диагностические записи: по ним можно установить организацию и маршрут, но нельзя прочитать сам секрет. Зафиксируйте оставшиеся непроверенные пути.

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