IOSOR Znalosti

Kdo může odesílat vs. hygiena rotace API klíčů

Uživatelské role určují, kdo může odesílat. Rotace API klíčů a přechod ze sandboxu patří pod Developers — neslučujte oprávnění účtů s životním cyklem tajných klíčů.

Uživatelská oprávnění a hygiena API klíčů sice v tiketech často splývají, ale řeší zcela odlišné bezpečnostní otázky. Zatímco matice rolí určuje, který konkrétní člověk smí odeslat kampaň či exportovat data, rotace klíčů chrání samotné systémové integrace. IOSOR tato dvě nastavení striktně odděluje, takže změna přístupu uživatele nikdy automaticky neobnoví tajný klíč webhooku a naopak.

Oddělte oprávnění účtů od životního cyklu tajných klíčů

Oprávnění účtů určují, kdo může kliknout na Odeslat, Schválit nebo Exportovat. Patří do revizí přístupových rolí s jmenovitě určenými vlastníky a maticí minimálních potřebných oprávnění.

Při vytváření požadavků na změnu udržujte práci oddělenou. Tiket pro role uvádí účty a povolené akce. Tiket pro Developers uvádí vlastníky tajných klíčů, okna pro rotaci a doklad o dokončeném přechodu.

Oprávnění k odesílání je otázkou rolí

Odesílání produkčních SMS čerpá předplacené blokace a zanechává auditní stopu v produkčním provozu. Účet, který má právo odesílat, musí být jednoznačně určen: operátoři kampaní, pohotovostní specialisté nebo automatizovaná identita s zdokumentovaným vlastníkem. Čtenáři z finančního oddělení, KYC revizoři a pracovníci exportu nesmí nikdy zdědit právo odesílat z běžné administrátorské role. Pokud někdo z firmy odchází, odeberte mu oprávnění k odesílání dříve, než začnete rotovat jeho počítač. Rotace klíčů nenahrazuje odebrání role — odcházející inženýr s stále platnou rolí může vygenerovat nový klíč, pokud to jeho účet umožňuje.

Rotace a přechod zůstávají na trase Developers

Rotace tajných klíčů webhooků bez výpadků, přechod ze sandboxových na produkční klíče a hygiena spuštění klíčů jsou úkoly pro Developers. Vyžadují souběžný provoz, ověření nového tajného klíče a kontrolní seznam pro přechod, který nezávisí na tom, kdo má práva k exportu. Pokud požadavek na změnu role obsahuje 'při té příležitosti otočte API klíč', nasměrujte rotaci na Developers. Požadavek na role se uzavře, když účty odpovídají akcím; Developers se uzavře, když je nový tajný klíč aktivní a starý je deaktivován. Udržujte partnerská rozhraní mimo proces rotace.

Odmítněte hybridní požadavky vkládající klíče do tiketu rolí

Tabulka s textem 'Admin — má produkční klíč' učí organizaci zacházet s účty jako s trezory na klíče. Publikujte raději dva samostatné dokumenty: matici rolí (osoba -> akce) a registr klíčů Developers (tajný klíč -> vlastník -> poslední rotace). Když partner požádá o přihlašovací údaje s právem odesílat a produkční klíč v jednom e-mailu, odpovězte dvěma odkazy: přístup k rolím pro účet a Developers pro přechod.

Související provozní trasy

Začněte s IOSOR

Zkontrolujte dnes oprávnění konzolových míst a oddělte práva uživatelů k odesílání od správy přihlašovacích údajů API. Lidské role přiřazujte striktně podle matice přístupů vašeho týmu a harmonogramy rotace klíčů integrujte do vývojářských pracovních toků. Ověřte, že v žádostech o přidělení míst ani v provozních záznamech nejsou uložena žádná surová pověření ani tajné klíče webhooků.

Shrnutí IOSOR

Přidělení lidských míst určuje, kdo může spouštět zprávy nebo zobrazovat přehledy, zatímco hygiena klíčů API řídí životní cyklus servisních údajů. Slučování zřizování uživatelských míst se správou tajemství vytváří závažná bezpečnostní rizika a snižuje provozní zodpovědnost.

Zachovávejte přísné oddělení mezi maticemi uživatelských přístupů a registry klíčů vývojářů s doloženými vlastníky a termíny přechodu. Nepovolujte hybridní oprávnění ani tabulky, které vkládají produkční tajemství vedle schválení lidských rolí.

Byl tento průvodce užitečný?

Související průvodci