jsonscraper

Zapomenuté API klíče: jak je odvolat, aniž byste zastavili službu

Nové Security Center OpenRouteru ukazuje, jak snadno lze nad klíči ztratit kontrolu. Seznam neaktivních přihlašovacích údajů je ale důvodem ke kontrole, nikoli tlačítkem „smazat vše“.

Interní kontrola OpenRouteru odhalila více než 1 000 aktivních API klíčů u 85 zaměstnanců; 168 klíčů se podle společnosti měsíce nepoužívalo. Jde o čísla z vlastního auditu OpenRouteru, nikoli o nezávislý oborový výzkum. I jako jednotlivý příklad ale ukazují známou technickou past: na klíč lze zapomenout, aplikaci, která je na něm závislá, však ne. Společnost datovala oznámení Security Center 28. září 2026.

Webové stránky Unsplash v režimu pro vývojáře
Bernd 📷 Dittrich · Licence Unsplash

Problém nespočívá jen v tom najít nejstarší přihlašovací údaj a smazat ho. Tým musí určit vlastníka, zjistit, kde se klíč používá, a promyslet jeho náhradu tak, aby nevyřadil občasnou úlohu nebo zapomenutou službu. Bez těchto informací se odvolání přístupu místo úklidu změní v riskantní experiment.

Co je v Security Center vidět — a co z toho nevyplývá

Podle popisu OpenRouteru Security Center sdružuje klíče v účtu a zobrazuje jejich vlastníka, poslední použití, limit výdajů a dobu platnosti; správci organizace vidí všechny klíče, zatímco členové vidí ty, které vytvořili. Při hromadných akcích lze vybrat až 500 klíčů a deaktivovat je, archivovat nebo jim nastavit limit výdajů. Deaktivaci lze vrátit, archivaci nikoli. Jde o vlastnosti nástroje popsané jeho dodavatelem, nikoli o nezávislé hodnocení jeho účinnosti.

Stav „lze odstranit“ je obzvlášť důležité chápat jako podnět ke kontrole, nikoli jako důkaz, že neexistují žádné závislosti. Metrika používání ukazuje předchozí požadavky, ale nemusí objasnit, ke které naplánované úloze, nouzovému scénáři nebo sezónnímu procesu klíč patří. OpenRouter sám doporučuje odstranění potvrdit u vlastníka; dokumentace k nastavení zabezpečení také varuje, že před deaktivací nebo archivací je třeba zkontrolovat závislosti.

Omezení sítě mají samostatnou výhradu: IP allowlist je k dispozici správcům tarifu Enterprise a vztahuje se na všechny klíče organizace. Požadavky z adres mimo seznam jsou odmítnuty s chybou 403 a změny se projeví okamžitě. Před zapnutím omezení je proto nutné zohlednit adresy produkčních serverů, kancelářské sítě a běhových prostředí CI; jinak může samotné ochranné opatření přerušit legitimní volání.

Postup při úklidu: nejdřív vlastník, potom odvolání

  1. Sestavte inventář. U každého klíče zaznamenejte vlastníka, účel, prostředí, systémy, které ho používají, limit výdajů a dobu platnosti. Pokud systém uvádí jako vlastníka pouze konkrétní osobu, určete také tým nebo službu, které převezmou odpovědnost, až tato osoba odejde.
  2. Ověřte používání a závislosti. Porovnejte čas posledního požadavku s plány úloh na pozadí, záložními scénáři, procesy vydávání verzí a externími integracemi. Nedávná neaktivita je důvodem zeptat se vlastníka, nikoli dostatečným důvodem k okamžitému odstranění.
  3. Před migrací snižte riziko. Pokud to nástroj umožňuje, nastavte přiměřený limit výdajů a dobu platnosti. Řiďte se principem nejnižších oprávnění a pravidly pro ukládání tajných údajů: příručka OWASP pro správu tajných údajů chápe evidenci, přístup a životní cyklus přihlašovacích údajů jako samostatné součásti procesu.
  4. Vytvořte náhradu a převeďte na ni uživatele. Aktualizujte tajný údaj v úložišti nebo konfiguraci nasazení a potom aplikace převádějte postupně. Nevkládejte hodnotu klíče do tiketů, protokolů ani zdrojového kódu.
  5. Před odvoláním ověřte produkční provoz. Ujistěte se, že nový klíč funguje ve všech známých systémech, které ho používají, včetně CI a občasných úloh. Poté nejprve starý klíč deaktivujte, pokud je tato operace vratná; archivujte nebo odstraňte ho až po potvrzení migrace a uplynutí dohodnuté doby sledování.
Webové stránky Unsplash v pozadí, v popředí technický pohled na zdrojový kód webu na obrazovce
Bernd 📷 Dittrich · Licence Unsplash

Postup „vytvořit nový klíč → převést aplikace → ověřit funkčnost → odstranit starý“ odpovídá návodu OpenRouteru k rotaci. Jde o doporučený postup, nikoli o záruku, že nedojde k výpadku: výsledek závisí na tom, zda jste našli všechny systémy, které přihlašovací údaj používají.

Servisní klíče nejsou všechny tajné údaje organizace

Panel konkrétního dodavatele pomáhá spravovat klíče pro jeho službu, ale sám o sobě nesjednocuje správu tajných údajů v cloudu, databázích, CI/CD a dalších rozhraních API. Obecná doporučení OWASP k životnímu cyklu tajných údajů zahrnují centralizované ukládání, řízení přístupu, audit, rotaci a odvolání. Doporučení Google Cloud navíc radí omezovat rozsah použití klíčů, odstraňovat nepotřebné přihlašovací údaje a sledovat jejich používání.

OpenRouter také tvrdí, že Security Center používá metadata klíčů, výdaje a dobu platnosti, nikoli obsah promptů a odpovědí. Jde o tvrzení samotného dodavatele; v posuzovaných zdrojích není k dispozici nezávislé technické ověření. A obecně platí, že existence panelu nedokazuje, že tým už snížil počet incidentů nebo výdaje: v prostudovaných materiálech nebyly nalezeny veřejné výsledky po spuštění.

Související články

Community Pulse · Průvodce

Claude Code nebo Codex: porovnávejte práci, ne značku

Názory vývojářů na Claude Code a Codex se různí a výzkum pull requestů neurčuje univerzálního vítěze. Praktický způsob, jak nástroje porovnat, je vyzkoušet je na úkolech a v prostředí, ve kterém skutečně pracujete.

Proměňte přečtené ve funkční integraci

Prozkoumejte API sociálních dat jsonscraper, testujte požadavky a sestavte další workflow.

Prozkoumat API