API klíče pro AI: oprávnění, bezpečné uložení a rotace

API klíč umožňuje aplikaci používat službu jménem určitého účtu nebo projektu. Jeho únik může znamenat spotřebu rozpočtu, přístup k dostupným prostředkům nebo narušení provozu podle toho, jak je služba nastavena. Klíč proto není běžný konfigurační text, který lze poslat do chatu při ladění. Při sdílení důkazu o chybě jeho hodnotu odstraňte.

OWASP doporučuje řídit tajemství v celém životním cyklu, omezovat přístup a připravit rotaci. Jeho doporučení pro logování zároveň popisují údaje, které se do záznamů nemají bez rozmyslu ukládat. Následující inventář je provozní vzor CIAD. Nevyžaduje konkrétní produkt pro správu tajemství, ale vyžaduje ověřitelnou odpovědnost.

Vzor inventáře API přístupů

Do inventáře nepište celý klíč ani jeho soukromou zálohu. K identifikaci použijte označení v administraci nebo jiný bezpečný identifikátor. Jeden sdílený klíč pro všechny prototypy ztěžuje odpojení konkrétního systému i určení původu spotřeby. Oddělení aplikací má smysl i tam, kde poskytovatel neumožňuje jemné nastavení všech oprávnění.

Kontrolní seznam před nasazením aplikace

Projděte místa, kde se konfigurace skutečně objeví: zdrojové soubory, sestavení aplikace, výstup do prohlížeče, protokoly, chybové hlášky a exporty. Klíč uložený na serveru se může přesto dostat ven, pokud jej aplikace vloží do odpovědi. Ověření provádějte nad výstupem, ne jen nad úmyslem vývojáře.

Oddělte testovací a produkční identitu. Vývojář má být schopen testovat bez přístupu k provoznímu rozpočtu nebo datům. Každá aplikace potřebuje jen rozsah, který vyžaduje její úkol. Podporuje-li poskytovatel omezení oprávnění, nastavte je a ověřte zakázanou operaci. Podporuje-li rozpočtová upozornění, vyzkoušejte jejich doručení; upozornění nemusí být tvrdý stop-limit.

Stanovte postup při podezření na únik. Není vhodné čekat na pravidelnou plánovanou výměnu tajemství. Odpovědný správce musí znát dotčené aplikace, způsob zneplatnění a náhradní konfiguraci. Zvažte také automatizace, které běží méně často a během rychlého ručního testu se vůbec nespustí.

Postup rotace se dvěma ověřeními

1. Zmapujte všechny konzumenty klíče a ověřte dostupnou možnost přechodného souběhu. Ne každý poskytovatel umožňuje stejný postup.
2. Vytvořte náhradní klíč s potřebným rozsahem a uložte jej do schváleného úložiště. Přístup dejte jen procesům, které jej potřebují.
3. Přepněte aplikace řízeně a otestujte skutečný pracovní úkol. Zkontrolujte též plánované služby a chybová upozornění.
4. Zneplatněte starý klíč podle možností poskytovatele. Ověřte, že už autorizovaný test se starým klíčem neprojde.
5. Aktualizujte inventář a zapište omezení, která zůstávají. Tajnou hodnotu do protokolu neukládejte.

Příklad: jeden klíč ve třech skriptech

Modelový tým používá stejné tajemství pro shrnutí dokumentů, noční zpracování a osobní experiment. Před výměnou zjistí, že noční proces má vlastní uloženou konfiguraci a při běžném testu se neověří. Oddělí jej do samostatné identity, otestuje náhradní nastavení a experimentu produkční přístup odebere. Tím umožní pozdější odpojení bez výpadku obou pracovních služeb.

Spotřebu řeší řízení API limitů, provozní pravidla zabezpečení AI a následky kompromitace postup po úniku přístupu. Rotace je hotová teprve po ověření náhrady i skutečného ukončení starého oprávnění.