Aktualizovaný průvodce pro technickou implementaci a ochranu citlivých údajů.
1. Základní bezpečnostní principy
- Minimalizace dat – Neukládáme nic, co asistent skutečně nepotřebuje k funkci. Dle principů GDPR (Článek 5) by měla být data omezena na nezbytný rozsah. [Zdroj: GDPR Art. 5]
- Oddělení tajemství – API klíče, hesla a tokeny nesmí být součástí zdrojového kódu. Využíváme Secrets Vaults.
- Šifrování „in transit“ – Veškerá komunikace probíhá přes TLS 1.2+. Standardy NIST doporučují prioritizaci TLS 1.3 pro maximální bezpečnost. [Zdroj: NIST TLS Guidelines]
- Šifrování „at rest“ – Úložiště a databáze šifrované pomocí AES-256.
- Jemnozrnná kontrola přístupu – Implementace modelu nejmenších oprávnění (PoLP) a RBAC.
- Audit & detekce – Logování přístupů k citlivým datům a monitoring v reálném čase.
- Rotace a expirace – Automatizovaný životní cyklus kryptografických klíčů.
2. Způsoby šifrování
V kontextu AI aplikací rozlišujeme několik rovin ochrany dat podle jejich stavu a účelu zpracování.
| Vrstva / Typ | Příklad dat | Opatření |
|---|---|---|
| Transparentní (TDE) | Databázové soubory, zálohy | Šifrování na úrovni disků a blokových úložišť (AES-256). |
| Field-level (FLE) | E-maily, jména, identifikátory | Šifrování konkrétních polí v aplikaci před odesláním do DB. |
| Pseudonymizace | Kontext promptu, historie chatu | Maskování entit (NER) a nahrazení tokeny před vstupem do LLM. |
| Application Layer | API klíče, systémové proměnné | Hardware Security Modules (HSM) nebo Cloud KMS. |
3. Postup implementace (praktický checklist)
A. Kategorizace a inventura dat
Identifikujte citlivá pole a přiřaďte jim štítky (public / internal / confidential). Vymezte whitelist dat povolených pro externí AI modely.
B. Správa klíčů (KMS)
Klíče musí spravovat dedikovaná služba (AWS KMS, GCP KMS, Azure Key Vault). Aplikace nikdy nepracuje s master key přímo. [Zdroj: Key Management Best Practices]
C. Pipeline pro maskování promptů
Před odesláním dat do modelu nasaďte pipeline: NER filtry → Nahrazení placeholderem (např. <<ID_01>>) → Lokální mapovací tabulka.
D. Logging a monitoring
Před uložením logů provádějte scrubbing (odstranění PII). Nastavte alerty na neobvyklé dešifrovací operace.
E. Testování a audit
Provádějte pravidelné penetrační testy zaměřené na úniky dat skrze prompty (Prompt Injection). [Zdroj: OWASP Top 10 for LLM]
4. Technické standardy šifrování
| Typ | Využití | Technická poznámka |
|---|---|---|
| AES-256 (GCM) | Data „at rest“ | Symetrické šifrování s ověřenou integritou. |
| TLS 1.3 | Data „in transit“ | Moderní standard eliminující slabé šifry. |
| SHA-256 + Salt | Vyhledávání (e-maily) | Jednosměrný hash pro porovnávání bez dešifrování. |
| FPE | Strukturovaná data | Format-preserving encryption pro zachování formátu (např. čísla karet). |
5. Pseudonymizace vs. anonymizace
Z hlediska bezpečnosti AI je kritické tyto pojmy nezaměňovat:
Pseudonymizace: Identifikátory jsou nahrazeny, ale proces je vratný (máme mapovací klíč). Nutné pro funkčnost asistentů, kteří pracují s historií uživatele.
Anonymizace: Data jsou nevratně upravena. Identifikace subjektu je nemožná. Ideální pro trénování vlastních modelů a analytiku.
6. Nejčastější chyby v implementaci
- Plaintext v logování: Únik PII při ladění chyb aplikace.
- Hard-coded secrets: Ukládání klíčů přímo v repozitáři (např. GitHub).
- Neřešené zálohy: Šifrování produkční DB, ale ponechání nešifrovaných SQL dumpů.
- Absence rotace klíčů: Používání jednoho API klíče po dobu několika let.
- Nedostatečné maskování: Odesílání celých smluv do AI modelu bez předchozí filtrace jmen a částek.
