ODPOVĚĎ

Ollama ve firmě: jak zabezpečit lokální AI server

Téma
AI bezpečnost
Čtení
3 min
Publikováno
Obsah · 6 kapitol

STRUČNÁ ODPOVĚĎ

Lokální Ollama potřebuje omezenou síťovou dostupnost, oddělené přístupy a kontrolu navazujících aplikací. Ověřte místní běh modelu i všechny cesty, kterými dokumenty opouštějí zařízení.

Instalace Ollamy je začátek provozu, nikoli jeho bezpečnostní kontrola. Zvlášť rozlišujte soukromý experiment na notebooku a sdílený server pro více lidí. Ve druhém případě potřebujete rozhodnout, kdo může zadávat úlohy, kdo čte historii a které aplikace se k modelu připojují. Slovo „lokální“ neříká nic o zabezpečení webového rozhraní, přístupných složek ani záloh.

Dokumentace Ollamy uvádí výchozí naslouchání na adrese 127.0.0.1 a portu 11434. Změna OLLAMA_HOST může dostupnost rozšířit. Dokumentace také rozlišuje místní a cloudové modely a popisuje vypnutí cloudových funkcí. Tyto vlastnosti ověřujte v konkrétní verzi. Nastavení modelového serveru neprokazuje, že lokálně zůstává i další aplikace, která nad ním běží.

Kontrolní tabulka pro dva způsoby provozu

OblastJeden pracovní počítačSdílený firemní server
DostupnostJen potřebné místní aplikacePouze schválená vnitřní cesta
IdentitaChráněný pracovní účetRozlišitelní uživatelé v přístupové vrstvě
DokumentyVybraná pracovní složkaOddělená úložiště podle rolí
SprávaVlastník zařízeníVlastník služby a zastupitelnost
ObnovaOvěřená záloha nastaveníOtestovaný návrat služby i oprávnění

Sdílený server nepřipojujte přímo na veřejnou síť jen proto, aby byl dostupný z domova. Potřebnou vzdálenou cestu navrhněte se správcem a ověřte její autentizaci. Síťové omezení, identity a aplikační oprávnění řeší různé hranice. Ani jedna vrstva sama nezaručuje, že uživatel neuvidí cizí dokument vložený do společné znalostní databáze.

Postup ověření bez citlivých dat

  1. Nakreslete cestu dokumentu od výběru souboru přes uživatelské rozhraní až k modelu a případnému vyhledávání. U každého kroku napište provozovatele a místo ukládání.
  2. Použijte syntetický dokument s jedinečnou značkou. Ověřte, že jej zpracovává zamýšlený místní model a že nejsou zapnuté nepotřebné cloudové funkce.
  3. Z jiného nepovoleného zařízení ověřte, že modelový server není dostupný. Test musí být součástí dohodnuté správy vlastní sítě.
  4. Zkontrolujte uživatelské rozhraní, protokoly, historii a index dokumentů. Přístup k modelu není totéž co přístup ke všem těmto datům.
  5. Otestujte ukončení přístupu jednoho uživatele a obnovu služby ze schválené konfigurace. Výsledky zapište před přechodem k reálným podkladům.

Příklad: asistent pro interní pracovní návody

Výrobní firma v modelovém scénáři chce prohledávat návody, nikoli personální dokumenty. Správce připraví samostatnou složku se schválenými texty a oddělí ji od ostatních disků. Rozhraní má právo používat tuto knihovnu, ne procházet celý server. Operátoři dostanou stejné dostupné návody jako v běžném pracovním systému.

Po přidání návodu tým ověří také odstranění staré verze z indexu. Model nesmí doporučovat zrušený postup jen proto, že zůstal ve vedlejší kopii. Pokud se připojí nová funkce pro webové hledání, posoudí se samostatně jako nová datová cesta. Lokální inference není automatické schválení dalších konektorů.

Aktualizace a provozní hranice

Zaznamenejte verzi Ollamy, přesné označení modelu, konfiguraci rozhraní a vlastníka aktualizací. Aktualizaci nejdříve vyzkoušejte nad zkušebními dotazy a ponechte ověřenou cestu návratu. Hodnocení zahrnuje kvalitu odpovědí i síťovou dostupnost. Funkční nová odpověď neznamená, že zůstaly zachovány stejné přístupy.

Začněte návodem k instalaci Ollamy, volbu prostředí posuďte přes cloudovou a lokální AI a provozní kontrolu doplňte o test obnovy ze zálohy. Tento článek rozhoduje o provozních hranicích, nikoli o tom, který model má nejlepší výkon na vašich úlohách.

ZDROJE A OVĚŘENÍ

automatická redakční kontrola CIAD editorial research; Codex review ·

Potřebujete odpověď pro svou organizaci?

Projdeme s vámi konkrétní situaci a navrhneme další krok.

Kontaktovat CIAD