Útok přes dodavatelský řetězec – uniklý přístupový klíč a data Evropské komise (2026)

Mnoho moderních útoků nezačíná tím, že by se někdo „vlámal“ do vaší firmy. Začínají u dodavatele: u nástroje, který používáte, u programu, který instalujete, nebo u služby, která má přístup k vašim údajům. V březnu 2026 to potvrdil případ Evropské komise: podle NÚKIB útočník získal přístupový klíč ke cloudové službě přes narušení dodavatelského řetězce a z něj se dostal k dalším účtům. Tento článek vysvětluje, co se stalo, co je dodavatelský řetězec a jak chránit klíče, tokeny a hesla i v malých projektech.

Údaje o případu vycházejí z publikace NÚKIB – Čtvrtletní přehled hrozeb Q1 2026 (označeno TLP:CLEAR; stav k 13. 11. 2026), která se odvolává na zprávu CERT-EU; obecné zásady ochrany tajných údajů vycházejí z dokumentace GitHub – prevence úniků dat (v angličtině). Případ je stále předmětem vyšetřování; uvádíme jen to, co zdroje uvádějí. Nejde o odborné poradenství.

Související články: Zero-day zranitelnosti a záplaty, GitHub – přihlášení a zabezpečení účtu a Správce hesel – jak funguje.

Aktualizováno: listopad 2026.

Co se stalo

Podle přehledu NÚKIB Evropská komise vyšetřovala bezpečnostní incident spojený s kompromitací cloudových služeb Amazonu (Amazon Web Services, AWS), které hostí některé její účty. Incident byl odhalen 24. března. K útoku se přihlásila kyberkriminální skupina ShinyHunters. Evropská komise přiznala odcizení svých dat, zároveň informovala, že její vnitřní systémy nebyly útokem dotčeny.

Podle dalších informací mělo být odcizeno více než 350 GB dat, včetně několika databází, a útočník již část dat zveřejnil na své stránce na dark webu. Podle zprávy CERT-EU byl počáteční přístup zajištěn v důsledku narušení dodavatelského řetězce společnosti Trivy, kdy byl získán přístupový klíč ke cloudové službě Amazonu. Tento klíč následně umožnil získat kontrolu nad dalšími účty AWS spojenými s Evropskou komisí.

Zjednodušený řetězec útoku přes dodavatele – vlastní infografika

Co je útok na dodavatelský řetězec

Při běžném útoku míří útočník přímo na cíl. Při útoku na dodavatelský řetězec (supply chain) zaútočí na někoho nebo něco, čemu cíl důvěřuje: softwarovou knihovnu, nástroj pro vývojáře, aktualizační server, poskytovatele služeb. Výhoda pro útočníka je, že jedna kompromitace může zasáhnout mnoho obětí a že napadení vypadá jako legitimní aktivita důvěryhodného nástroje. Pro uživatele z toho plyne: důvěra v dodavatele je riziko, které je třeba řídit, ne jen ignorovat.

Co je přístupový klíč a proč je citlivý

Přístupový klíč (API klíč, token, přístupový klíč k cloudu) je tajný údaj, kterým se program či služba prokazuje v cizí službě. Funguje jako heslo bez dvoufázového ověření: kdo klíč získá, může dělat vše, co mu klíč dovoluje, často bez dalšího ověřování. Podle případu Evropské komise stačil jediný klíč k tomu, aby útočník převzal další účty. Proto jsou klíče stejně cenné jako hesla, a proto je třeba:

• nikdy je nevkládat do kódu ani sdílených dokumentů,
• omezit jejich oprávnění na nezbytné minimum,
• pravidelně je měnit,
• okamžitě zneplatnit, pokud mohly uniknout.

Jak klíče chránit (zásady podle GitHubu)

Dokumentace GitHub shrnuje základní postupy, které se dají použít i v malých projektech:

• Nedávejte tajné údaje do commitů: ať už jde o hesla, tokeny nebo klíče, nesmí skončit v repozitáři.
• Zapněte ochranu při odesílání (push protection): GitHub zablokuje odeslání, pokud v něm detekuje tajný údaj. Doporučuje ji zapnout i v osobním nastavení účtu.
• Používejte skenování tajných údajů (secret scanning): prohledává celou historii všech větví, hlásí nalezené tajné údaje a lze přidat vlastní vzory.
• Uplatňujte nejnižší oprávnění: osobní přístupové tokeny omezte jen na potřebná oprávnění.
• Zabezpečte účty: vyžadujte dvoufázové ověření a podporujte silná hesla.
• Když tajný údaj unikne, zneplatněte ho (odvolání tokenu); odstranit ho jen z poslední verze nestačí, protože zůstává v historii. Dokumentace uvádí odstranění z historie nástrojem `git filter-repo`; `git revert` nepomůže, protože původní commit zůstane v historii.

Dokumentace se nezabývá otáčením klíčů ani ukládáním do proměnných prostředí; tyto postupy proto uvádíme jako obecné doporučení, nikoli jako citaci.

Co to znamená pro běžné lidi

Nemusíte být správcem cloudu, abyste se tohoto týkali. Podobná logika platí pro:

• Přihlášení „přes Google/Facebook/Apple“ do aplikací: pokud se aplikace dostane k vašemu účtu, může toho zneužít; zkontrolujte propojené aplikace; viz Přihlášení přes Google, Apple či Facebook.
• Aplikace a rozšíření, kterým dáváte oprávnění k poště, fotografiím či cloudu.
• Malé weby a e-shopy: přístupové údaje k hostingu, doméně a platební bráně patří mezi nejcennější.
• Programátoři a tvůrci, kteří používají API klíče ve svých projektech.
• Rodinné weby a NAS: hesla a tokeny ke cloudovým záložním službám.

Základní zásada: dávejte aplikacím jen tolik přístupu, kolik skutečně potřebují, a pravidelně kontrolujte, kdo má přístup k vašim účtům.

Praktické kroky

1. Projděte propojené aplikace v účtech Google, Microsoft, Apple a sociálních sítích a odeberte nepoužívané.
2. Zapněte dvoufázové ověření u účtů, ke kterým mají přístup jiní lidé či aplikace.
3. Nesdílejte klíče e-mailem ani chatem; používejte správce hesel; viz Správce hesel.
4. U vývojářských projektů zapněte skenování tajných údajů a ochranu při odesílání; viz GitHub – přihlášení a zabezpečení účtu.
5. Při podezření na únik klíče jej okamžitě zneplatněte a vygenerujte nový.
6. Sledujte upozornění poskytovatelů na neobvyklou aktivitu.
7. Aktualizujte nástroje a knihovny, ale jen z oficiálních zdrojů.

Další informace o bezpečném chování najdete na E-Bezpečí, Stop online a u Policie ČR.

Co si odnést z případu Evropské komise

Případ ukazuje, že i vysoce chráněná organizace může přijít o data, pokud je kompromitován dodavatel a klíč má příliš široká oprávnění. Zároveň ukazuje, že zveřejnění dat na dark webu může přijít později: skupina ShinyHunters část dat zveřejnila. Pro jednotlivce z toho plyne praktická lekce: počítejte s tím, že se vaše údaje mohou objevit v úniku, a mějte připravené postupy (unikátní hesla, dvoufázové ověření, kontrola úniků); viz Have I Been Pwned.

Jak vypadá dobrý postup při úniku klíče

Pokud zjistíte, že klíč či token mohl uniknout, nezkoušejte nejprve zjistit, jestli se opravdu zneužil. Nejdříve ho zneplatněte (odvolejte) u poskytovatele, vytvořte nový s co nejmenšími oprávněními a nahraďte jím starý ve všech aplikacích. Poté prohlédněte záznamy aktivity: zda se klíč používal z neznámých míst či v neobvyklé době. Zkontrolujte, zda neexistují nové účty, oprávnění či klíče, které útočník mohl vytvořit. Až poté řešte příčinu: kde klíč unikl a jak tomu příště zabránit. Rychlost je důležitější než dokonalá analýza.

Hesla, klíče a sdílení v týmu

V malých týmech a rodinných projektech se tajné údaje často sdílejí poznámkami či chatem. To je rizikové, protože takový údaj zůstane v historii zpráv a může jej vidět každý s přístupem k zařízení. Raději používejte správce hesel s funkcí sdílení, oddělené účty pro každého člověka a pravidelně kontrolujte, kdo má k čemu přístup. Odejde-li člen týmu, odeberte mu přístupy a změňte sdílené údaje. Tyto jednoduché zvyky snižují riziko, že jediná chyba ohrozí všechno.

Praktický příklad (smyšlený)

Lukáš provozuje malý web a omylem uloží přístupový klíč k úložišti do veřejného repozitáře. Díky ochraně při odesílání ho GitHub zablokuje. Lukáš klíč zneplatní, vytvoří nový s omezenými oprávněními a zapne dvoufázové ověření u hostingu. Příklad je smyšlený.

Kontrolní seznam – vlastní infografika

Případ Evropské komise v kostce

Základní údaje – vlastní infografika

Výhody a nevýhody

Souhrn – vlastní infografika

Související články

V kategorii Malware a kybernetické útoky najdete také Škodlivá rozšíření prohlížeče a Malvertising.

Shrnutí

V březnu 2026 podle NÚKIB útočníci získali data Evropské komise (přes 350 GB) prostřednictvím narušení dodavatelského řetězce Trivy a odcizeného přístupového klíče k AWS. Klíč fungoval jako heslo bez druhého faktoru. Chraňte klíče a tokeny: nevkládejte je do kódu, omezte oprávnění, zapněte skenování tajných údajů a ochranu při odesílání, používejte dvoufázové ověření a při úniku klíč ihned zneplatněte.

Často kladené otázky k útoku přes dodavatelský řetězec