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

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

Підсумок IOSOR

Права користувачів відповідають на запитання «хто може надсилати повідомлення», тоді як ротація ключів — це суто інженерне завдання розробників. Поєднання цих двох процесів у єдиний доступ створює ризики витоку даних та хаосу під час ротації кадрів. Доступи до консолі та графіки оновлення секретів повинні існувати як два окремих артефакти.

Робіть чітке розмежування між рольовою матрицею (людина → дії) та інженерним реєстром ключів (секрет → власник → ротація). Не створюйте гібридні доступи, де текстові ролі містять робочі API-ключі, та не залучайте аналітиків чи KYC-контролерів до інженерних тасків оновлення секретів.

Чи був матеріал корисним?

Пов’язані гіди