IOSOR

IOSOR База знаний

Кто может отправлять vs гигиена ротации API-ключей

Роли людей решают, кто может send. Ротация API-ключей и cutover sandbox остаются у Developers — не смешивайте выдачу мест с lifecycle секретов.

Права людей и гигиена API-ключей стоят рядом в launch-тикете, но отвечают на разные вопросы. Кто может send — карта ролей: какое место может сабмитить production SMS, approve кампанию или открыть export.

IOSOR держит разделение жёстко. Выдача console-роли не ротирует webhook secret. Ротация secret не выдаёт send.

Отделите выдачу мест от lifecycle секретов

Выдача мест отвечает, кто может нажать Send, Approve или Export — обзоры roles-access с именными владельцами и матрицей least privilege. Lifecycle секретов отвечает, как ключи создают, ротируют, держат dual-hold на cutover и выводят из строя — runbook Developers: ротация без потери delivery reports, cutover sandbox vs production и partner surface gates без утечки upstream-бренда.

Не открывайте один тикет «access + keys». Тикет ролей перечисляет места и глаголы.

Кто может send — вопрос роли

Production SMS тратит prepaid hold и оставляет audit trail на live-пути. Место send должно быть явным: campaign ops, on-call messaging или automation identity с документированным владельцем. Read-only finance, KYC-ревьюеры и export-clerks не должны наследовать send от общей admin-роли.

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

Ротация и cutover остаются на пути Developers

Ротация webhook secret без downtime, cutover sandbox vs production keys и launch-гигиена ключей — работа Developers. Нужны окна dual-run, smoke на новом secret и cutover-чеклист, который не зависит от Export-места. Если запрос на смену роли включает «ещё и ротировать API-ключ», ротацию ведите в Developers. Roles-access закрывается, когда места совпадают с глаголами; Developers — когда новый secret live, а старый retired. Держите партнёрские поверхности вне пути ротации.

Отказывайтесь от hybrid-выдач с ключами в тикетах ролей

Таблица «Admin — имеет production-ключ» учит организацию считать места vault’ом ключей. Публикуйте два артефакта: матрицу ролей (человек → глаголы) и реестр ключей Developers (secret → владелец → последняя ротация). Когда партнёр просит login с send и live-ключ в одном письме, отвечайте двумя ссылками: roles-access для места, Developers для cutover.

Связанные пути

Начните с IOSOR

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

Итог IOSOR

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

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

Был ли материал полезен?

Связанные гайды