Jetstack
Zpět na blog Blog

Správa citlivých údajů — přístupové údaje, které nikdy neskončí v kódu

Publikováno 1. prosince 2025

Technická ilustrace k článku Jetstacku

Za každou integrací stojí nějaký přístupový údaj. Klíč API k platební bráně. Token pro dopravce. Heslo do staršího systému. Přístupový klíč k cloudovému úložišti. Bez vyhrazeného místa, kam takové údaje ukládat, se rozlézají všude — vlepené do polí konfigurace automatizací, zapečené ve skriptech na straně serveru, vepsané do formulářových polí, přeposílané e-mailem mezi implementátory. Každé z těch míst je potenciální únik a každé zvlášť je starost navíc, když se údaj musí změnit. Platforma se správou citlivých údajů jako plnohodnotnou funkcí promění každý přístupový údaj v pojmenovaný odkaz — uložený jednou, řízený rolí, měněný na jednom místě a nikdy zapsaný přímo do něčeho, co se ukládá jinam. Takhle to má vypadat a přesně to tahle funkce dělá.

Pojmenované údaje se ukládají jednou a odkazuje se na ně odevšad. Implementátor vytvoří údaj — dá mu srozumitelný název jako Klíč API platební brány nebo Token dopravce — a vloží hodnotu. Od té chvíle na něj každá automatizace, skript nebo integrace, která ho potřebuje, odkazuje jménem. Hodnota se nikdy neobjeví v poli konfigurace, nikdy se nekopíruje do skriptů, nikdy neprojde odesláním formuláře. Cestuje odkaz; hodnota zůstává v úložišti citlivých údajů.

Rozsah je omezen na dané prostředí, s izolací tak přísnou jako u kterýchkoli jiných dat: údaje prostředí A jsou pro prostředí B neviditelné a nepřístupné, tečka. Uvnitř prostředí řídí přístup role. Role, které údaje potřebují používat, jejich hodnoty automaticky nevidí; role, které údaje spravují, je mohou vytvářet, měnit a obměňovat; role, které potřebují audit, si přečtou auditní stopu, aniž by se hodnoty odhalily. Právě tahle jemnost řízení dovolí prostředí dát automatizacím a skriptům přístup k údajům, které potřebují, aniž by se z každého vývojáře stal potenciální držitel přístupových údajů.

Odkaz v automatizacích je nejčastější použití. Akce automatizace, která odesílá webhook, volá externí API, ověřuje se u partnerského systému nebo nahrává do cloudového úložiště, si vybere údaj podle názvu z nabídky — žádná vlepená hodnota, žádné vystavení při kopírování. Za běhu automatizační engine odkaz přeloží na aktuální hodnotu a použije ji; hodnota se nikdy neuloží do samotné konfigurace automatizace. Když někdo později definici automatizace vyexportuje, export nese odkaz, ne hodnotu — konfiguraci tak lze sdílet, procházet a verzovat, aniž by unikly přístupové údaje.

Odkaz ve skriptech je týž mechanismus pro kód na straně serveru. Skript, který má poslat ověřený HTTP požadavek, si vyžádá údaj podle názvu přes drobné API platformy; hodnota se v kódu nikdy neobjeví. To je podstatné, protože skripty často končí ve verzovacím systému, v revizích kódu, ve sdílených knihovnách — všude, kde je natvrdo zapsaný přístupový údaj bezpečnostním incidentem čekajícím, až se stane. S odkazem podle názvu zůstává údaj v úložišti a skript se dá bez obav sdílet.

Skutečnou zkouškou každého systému na citlivé údaje je jejich obměna a právě tady se hodnota správy citlivých údajů ukáže nejzřetelněji. Když se údaj musí změnit — protože je naplánovaná pravidelná obměna, protože unikl, nebo protože ho zneplatnila třetí strana — implementátor hodnotu jednou přepíše. Každá automatizace, každý skript, každý odkaz, který údaj používá podle názvu, si při dalším spuštění sám vyzvedne novou hodnotu. Nemusíte procházet konfiguraci a měnit ji na dvanácti místech; není žádný seznam míst, kde by údaj mohl být zapečený a bylo ho třeba zkontrolovat. Z obměny se stává práce na pár minut, ne na celý den.

Odhalit versus použít je záměrný rozdíl. Role může dostat oprávnění údaj použít, aniž by dostala oprávnění jeho hodnotu odhalit. Ten rozdíl má význam ve větších týmech, kde spousta lidí potřebuje, aby integrace fungovaly (potřebují „použít“), ale jen pár lidí je s přístupovými údaji svěřeno (potřebují „odhalit“). Vývojář, který nastavuje automatizaci, si ze seznamu vybere správný údaj a ověří, že integrace funguje, aniž by kdy viděl jeho hodnotu. Administrátor, který údaje obměňuje, hodnotu vidí a mění přímo. Každá role má přesně takový přístup, jaký její práce vyžaduje.

Verzování krátce podrží předchozí hodnoty, aby se dala nepovedená obměna vzít zpět. Když se ukáže, že nově vydaný údaj není správný — překlep, upstream ho ještě neaktivoval, omylem míří do jiného prostředí — je předchozí verze po omezenou dobu stále k dispozici a obměnu lze vrátit. Pro ty nešťastné, ale reálné případy, kdy obměna nevyjde na první dobrou, dělá tohle verzování z možného výpadku jen drobnou nepříjemnost.

Hodnoty podle prostředí umožní, aby se týž název údaje přeložil v různých prostředích na různé hodnoty. Klíč API platební brány může v testovacím prostředí odkazovat na sandboxový údaj a v produkčním na produkční, i když automatizace a skripty, které na něj odkazují, jsou v obou totožné. Právě tahle znalost prostředí dovolí, aby si citlivé údaje čistě rozuměly s přenosem konfigurace z testu do produkce: mezi prostředími se stěhuje tatáž konfigurace a každé prostředí si názvy přeloží na údaje, které má skutečně používat.

Auditní stopa podchytí každou interakci s úložištěm citlivých údajů. Každé vytvoření, každá změna, každá obměna, každé odhalení, každé použití — vše zaznamenané v protokolu událostí s aktérem, časem a kontextem. Pro audity compliance, které mají doložit kontrolu nad přístupem k přístupovým údajům, je auditní stopa tím, co tvrzení podepře; pro bezpečnostní vyšetřování, které potřebuje zjistit, zda nebyl údaj zneužit, dává táž stopa odpověď. Článek o protokolu událostí popisuje širší mechanismus protokolu; události kolem citlivých údajů do něj přirozeně zapadají.

Přístupové údaje do polí konfigurace nepatří. To je zásada, na které funkce stojí. Pole konfigurace přijímá hodnoty, které smí vidět každý, kdo vidí konfiguraci — názvy vlastností, popisy, prahové hodnoty, popisky. Přístupové údaje mezi ně nepatří; jsou to právě ty hodnoty, které mají zůstat skryté i před lidmi, kteří zbytek systému oprávněně nastavují. Funkce citlivých údajů jim dává pořádný domov: pojmenované, odkazované, obměňované centrálně, auditované a neviditelné pro každého, kdo nemá výslovné oprávnění je vidět.

Pro implementátory, kteří se napojují na externí systémy — a to je většina z nich — je správa citlivých údajů jednou z těch základních schopností, které předem odstraní celou třídu chyb. Ze sousedních témat: článek o automatizacích popisuje místa, kde se na citlivé údaje odkazuje, článek o skriptování na straně serveru programový přístup, článek o protokolu událostí auditní stopu a článek o rolích a oprávněních řízení přístupu, které rozhoduje o viditelnosti údajů. Přístupové údaje, které nikdy neskončí v kódu, v polích konfigurace ani v exportovaných balíčcích — to je výsledek, který má tahle funkce přinést.