Lokální provoz AI řeší, kam tečou data – ne kdo se k modelu dostane. Lokální API Ollamy nemá žádné přihlášení; SentinelLABS a Censys napočítaly zhruba 175 000 veřejně dostupných instancí ve 130 zemích (leden 2026) a kritická chyba z jara 2026 měla záplatu víc než dva měsíce předtím, než o ní kdo věděl. Bezpečnost je vlastnost provozu: síť, aktualizace, dohled.
Proč lokální AI není automaticky bezpečná?
Přenesením modelu na vlastní server vyřešíte jednu otázku: data neopouštějí firmu. Seznam tím ale nekončí. Bezpečnost není vlastnost modelu, ale provozu kolem něj – stejně jako u firemního cloudu na vlastním serveru. V článku o lokálních LLM jsem tématu věnoval dvě věty ve FAQ; tady je celé.
Prakticky jde o tři vrstvy:
- Kam tečou data. Lokální nasazení řeší – dotazy i dokumenty zůstávají u vás.
- Kdo se dostane k API. Lokální nasazení neřeší. Runtime jako Ollama nemá u lokálního API autentizaci: kdo dosáhne na port, může se ptát, stahovat i nahrávat modely.
- Co model smí dělat. Jakmile má nástroje – soubory, e-mail, databázi – přibývá otázka, jak ho lze zmanipulovat obsahem. Samostatné téma; tento text se drží infrastruktury.
Kolik AI serverů je otevřených do internetu – a proč?
Společný výzkum SentinelLABS a Censys (leden 2026) zaznamenal za 293 dní pozorování zhruba 175 000 unikátních instancí Ollamy dostupných z veřejného internetu, ve 130 zemích. Přibližně polovina měla zapnuté volání nástrojů – nejsou to „jen chatboty“, ale servery, které umějí spouštět kód a sahat na okolní systémy.
Příčina není exotická. Runtime je navržený pro localhost: po instalaci naslouchá jen na 127.0.0.1. Jakmile ho chcete volat z jiného stroje – z webového rozhraní, z automatizace, z kontejneru – dokumentace nabídne změnu jedné proměnné prostředí. Bez varování, bez zmínky o autentizaci (stav FAQ k 3. 9. 2026). Kdo ji nastaví na stroji s veřejnou adresou nebo za děravým firewallem, přidá do té statistiky další řádek.
Není to chyba softwaru. Je to provozní rozhodnutí, které tisíce správců udělaly stejně – proto jev, ne incident.
Bleeding Llama: proč o záplatě víc než dva měsíce nikdo nevěděl?
Na jaře 2026 zveřejnil Cyera Research kritickou chybu v Ollamě, CVE-2026-7482 („Bleeding Llama“). Speciálně upravený soubor modelu, nahraný přes API pro správu modelů, donutil server vydat obsah vlastní paměti – systémové prompty, konverzace uživatelů, proměnné prostředí s klíči. Bez přihlášení, bez chybového záznamu v logu. Časová osa je výmluvnější než chyba sama.
| Datum | Událost |
|---|---|
| 2. 2. 2026 | Nahlášeno vývojářům Ollamy |
| 25. 2. 2026 | Oprava ve verzi 0.17.1, bez označení jako bezpečnostní záplata |
| 2. 3. 2026 | Žádost o CVE u MITRE bez odezvy |
| 28. 4. 2026 | CVE-2026-7482 přiděleno přes Echo CNA |
| 5. 5. 2026 | Zveřejnění s technickými detaily |
Kdo se řídil jen bezpečnostními feedy, o opravě víc než dva měsíce nevěděl – záplata bez CVE je pro skenery neviditelná. Útok, který nenechá stopu v aplikačním logu, zachytí jen dohled nad síťovou a API vrstvou. A bez evidence verzí nepoznáte, že běžíte na zranitelné verzi a oprava dávno existuje.
Jak zabezpečit lokální AI server: pět vrstev
Pořadí podle toho, kde selhání bolí nejvíc.
- Naslouchat jen tam, kde je to nutné. Runtime váže na localhost nebo interní rozhraní, nikdy na veřejnou IP. Přístup z jiných strojů řeší síť, ne otevřený port.
- Autentizace před runtime. Ollama ji u lokálního API nemá; dodá ji reverse proxy nebo zero-trust brána. Správu modelů (stahování, vytváření, odesílání) z nedůvěryhodné sítě nepovolujte vůbec.
- Segmentace a řízený egress. AI server patří do vlastního segmentu s pravidly, co smí volat ven. Pozor na cloudové modely: tagy s příponou „-cloud“ posílají dotazy na ollama.com. Mají-li data zůstat doma, patří k tomu politika, přepínač
OLLAMA_NO_CLOUD=1a blokace egressu. - Aktualizace podle security advisories, ne podle release notes. Jen v srpnu 2026 vyšlo třináct stabilních verzí Ollamy (0.32.6 až 0.33.2); k 2. 9. 2026 je aktuální 0.33.3. Changelog verze 0.17.1 přitom o kritické opravě mlčel.
- Logování a dohled – další sekce.
Co má dohled u AI serveru skutečně vidět?
Aplikační log ukazuje to, co runtime zapíše. To je málo. Dohled u AI serveru sleduje šest signálů:
- přístup na API z nečekaných adres nebo segmentů,
- chybějící či neúspěšnou autentizaci na proxy před runtime,
- volání správy modelů mimo změnové okno,
- anomální objem dotazů nebo zátěž GPU – v červnu 2026 popsal Sysdig útočníka, který používal cizí otevřenou Ollamu jako řídicí prvek automatizovaného útočného nástroje; žádná softwarová chyba, jen otevřený port bez autentizace,
- egress na neznámé cíle včetně DNS dotazů mimo očekávané domény,
- změnu verze runtime.
Detekční logika je veřejná: Elastic vydal v lednu 2026 pravidlo „Ollama API Accessed from External Network“ a k němu pravidlo pro DNS dotazy Ollamy na nedůvěryhodné domény. Stejný princip zapisujeme ve Wazuhu. SIEM přitom stojí u vás a logy neopouštějí firmu; automatická detekce běží nepřetržitě, lidské posouzení podle dohodnutého režimu.
Platí to i mimo Ollamu?
Ano. Open WebUI, LM Studio, vLLM, gateway proxy i vektorové databáze sdílejí stejný vzor: síťová služba navržená pro důvěryhodné okolí, kterou někdo vystaví dál, než měl. Výzkum LLMjackingu jmenuje vedle Ollamy i vLLM a obecně OpenAI-kompatibilní API bez autentizace. Pět vrstev z předchozí sekce platí beze změny – na každou komponentu zvlášť.
Gateway knihovny jsou k tomu závislosti jako každé jiné. V březnu 2026 se supply-chain útokem dostaly na PyPI podvržené verze knihovny LiteLLM (CVE-2026-33634); sbíraly klíče a přihlašovací údaje z prostředí, kde se nainstalovaly. Kontrola původu balíčků patří do provozu AI stejně jako záplaty runtime.
Jak to vypadá v provozu u nás?
AI server u nás sedí ve stejném režimu jako zbytek infrastruktury: vlastní segment, proxy s autentizací, logy do SIEM, který stojí ve firmě – to je náplň bezpečnostního dohledu. Nasazení, které si firma postavila sama, přebíráme po písemně vymezené intake review v rámci provozu a dohledu AI (od 16 900 Kč/měs.). Jedno místo přístupu s politikou, kdo smí volat který model, je práce pro AI gateway; a kde se AI server teprve staví, je úroveň zabezpečení parametrem zadání od prvního dne – AI infrastruktura.
Na co se ptáte nejčastěji
Je Ollama bezpečná pro firemní použití?
Ano, pokud ji provozujete jako každou jinou síťovou službu. Chybějící autentizace u lokálního API není chyba, ale designové rozhodnutí – runtime počítá s během na localhostu. Bezpečnost firemního nasazení proto neurčuje produkt, ale provoz kolem něj: kde naslouchá, co stojí před ním, jak se aktualizuje a kdo se dívá do logů.
Stačí, když AI server běží jen v interní síti?
Je to první krok, ne konec. Interní síť chrání před náhodným návštěvníkem z internetu, ne před kompromitovanou pracovní stanicí, notebookem dodavatele ani před vlastním zaměstnancem. Autentizaci před runtime a segmentaci proto nasazujte i uvnitř sítě a správu modelů omezte na administrátorský přístup.
Má Ollama přihlašování nebo API klíče?
U lokálního API ne – dokumentace to uvádí výslovně (stav k 3. 9. 2026). Přihlášení a API klíče slouží jen pro cloudové modely, publikování a privátní modely na ollama.com. Přístup k lokálnímu serveru proto řídí vrstva před ním: reverse proxy s autentizací nebo zero-trust brána, která pustí jen ověřené uživatele a aplikace.
Jak poznám, že je náš AI server vidět z internetu?
Zkontrolujte tři místa: bind adresu runtime, pravidla firewallu a existenci veřejné adresy nebo port-forwardu na daném stroji. Externí kontrola dostupnosti pak patří do pravidelného dohledu, ne mezi jednorázové akce – konfigurace se mění a chyba se vloudí při každém zásahu do sítě.
Jak často aktualizovat a podle čeho?
Týdenní kontrola je u tohoto typu softwaru rozumné minimum; jen v srpnu 2026 vyšlo třináct stabilních verzí Ollamy. Řiďte se bezpečnostními advisories a evidencí verzí, ne jen release notes – oprava CVE-2026-7482 vyšla ve verzi 0.17.1 bez bezpečnostního označení a víc než dva měsíce ji šlo přehlédnout. Aktualizace testujte, ale neodkládejte.
Co dělat, když už k nám někdo lezl?
Odpojit server od sítě a postupovat podle připraveného plánu, ne improvizovat. Rotujte klíče a hesla, které mohly být v paměti procesu, včetně údajů v systémových promptech. Prověřte, jaké modely na serveru jsou a kdo je nahrál, projděte logy proxy i sítě, aktualizujte – a teprve pak server vraťte do provozu. Pokud jsou ve hře osobní údaje, posuďte s právníkem ohlašovací povinnosti.
Týká se to i Open WebUI, LM Studio nebo vLLM?
Ano, jde o stejný vzor: síťová služba, která předpokládá důvěryhodné okolí. Webová rozhraní mívají vlastní přihlášení, runtime pod nimi ale často zůstává na síti otevřený – přihlášení do UI nechrání API, které UI volá. Vrstvy z tohoto článku (bind, autentizace, segmentace, aktualizace, dohled) aplikujte na každou komponentu zvlášť.
Zdroje (primární)
- Cyera Research – disclosure Bleeding Llama, CVE-2026-7482 (nahlášeno 2. 2. 2026; oprava 0.17.1 z 25. 2. bez bezpečnostního označení) – cyera.com/research (5. 5. 2026)
- Záznam CVE-2026-7482 (heap out-of-bounds read v GGUF loaderu; /api/create a /api/push bez autentizace) – nvd.nist.gov (ověřeno 3. 9. 2026)
- SentinelLABS & Censys – report „Silent Brothers“ (175 000 instancí Ollamy / 130 zemí / 293 dní pozorování / ~polovina s tool-callingem – jediná datovaná statistika článku) – sentinelone.com/labs (leden 2026)
- Autentizace API Ollamy (lokální API bez přihlášení; klíče jen pro ollama.com) – docs.ollama.com/api/authentication (ověřeno 3. 9. 2026)
- Ollama FAQ (síťové vystavení přes OLLAMA_HOST bez bezpečnostní poznámky; vypnutí cloudových funkcí
OLLAMA_NO_CLOUD=1) – GitHub, ollama/ollama docs/faq.mdx (ověřeno 3. 9. 2026) - Cloudové modely Ollamy (tagy s příponou „-cloud“ odbavované na ollama.com) – docs.ollama.com/cloud (ověřeno 3. 9. 2026)
- Kadence verzí (13 stabilních vydání v srpnu 2026, 0.32.6–0.33.2; aktuální 0.33.3) – GitHub, ollama/ollama Releases (ověřeno 3. 9. 2026)
- Sysdig Threat Research Team – LLMjacking evolved (pozorování 12. 6. 2026: otevřená Ollama jako řídicí prvek útočného nástroje) – sysdig.com/blog (červen 2026)
- Detekční pravidlo „Ollama API Accessed from External Network“ (+ sesterské pravidlo pro DNS dotazy Ollamy) – Elastic Security, prebuilt rules (9. 1. 2026)
- LiteLLM – Security update, CVE-2026-33634 (supply-chain kompromitace balíčku na PyPI) – docs.litellm.ai/blog (březen 2026)
Provozujete lokální AI a chcete vědět, které z pěti vrstev u vás skutečně stojí? Dvacet minut nad vaší konkrétní konfigurací.
Bez prezentací, bez závazku.
