Ochrana zákaznických dat — technická opatření

E-shop ví o zákaznících hodně. Jméno, adresu, telefon, e-mail, historii nákupů, často i datum narození nebo firemní údaje. Tato data se kopírují do ERP, dopravců, e-mailingu, reklamních systémů a tabulek na sdíleném disku. Každá kopie je další místo, odkud mohou uniknout.

GDPR po správci chce „vhodná technická a organizační opatření“. Formulace je záměrně obecná, protože opatření mají odpovídat riziku. Pro majitele e-shopu to ale zní mlhavě. V článku ji převedeme na konkrétní technické kroky. Právní stránku, tedy souhlasy, zpracovatelské smlouvy a záznamy o činnostech, rozebíráme v článku GDPR pro e-shopy: praktický checklist 2026.

Co říká článek 32 GDPR

Článek 32 GDPR vyjmenovává čtyři oblasti, na které se má zabezpečení zaměřit:

1. pseudonymizace a šifrování osobních údajů,
2. trvalá důvěrnost, integrita, dostupnost a odolnost systémů,
3. schopnost včas obnovit dostupnost dat po fyzickém nebo technickém incidentu,
4. proces pravidelného testování a hodnocení účinnosti opatření.

K tomu článek 5 přidává dvě zásady, které mají velký technický dopad. Minimalizace: zpracovávejte jen data, která opravdu potřebujete. Omezení uložení: nedržte je déle, než je nutné. Článek 25 pak chce, aby ochrana dat byla zabudovaná už do návrhu systému a do výchozího nastavení.

Nejbezpečnější data jsou ta, která nemáte

Než začnete šifrovat, zeptejte se, co vůbec sbírat. Každé pole ve formuláři navíc je riziko navíc.

• Datum narození potřebujete jen tehdy, když prodáváte zboží s věkovým omezením nebo posíláte narozeninové slevy se souhlasem.
• Telefon je užitečný pro dopravce, ale nemusí být povinný u elektronického zboží.
• Údaje o platebních kartách na e-shopu neukládejte vůbec. Nechte je platební bráně. Standard PCI DSS navíc zakazuje po autorizaci platby ukládat ověřovací kód karty (CVV).
• Nastavte lhůty pro mazání nebo anonymizaci. Neaktivní účty a staré objednávky po uplynutí zákonných lhůt pro účetnictví a reklamace nemusí obsahovat kompletní osobní údaje.

Šifrování a hesla

Šifrování rozlišujeme podle toho, kde data jsou.

U hesel je doporučení jednoznačné. OWASP, nezisková organizace pro bezpečnost webových aplikací, ve svém přehledu Password Storage Cheat Sheet doporučuje na prvním místě Argon2id s minimálně 19 MiB paměti, 2 iteracemi a paralelismem 1. U starších systémů je přijatelný bcrypt s pracovním faktorem aspoň 10. Moderní platformy to řeší samy. Riziko je hlavně ve vlastním vývoji a starých modulech.

Pro přenosy souborů s objednávkami nebo zákaznickými daty používejte SFTP místo FTP. Obyčejné FTP posílá data i přihlašovací údaje nešifrovaně.

Přístupy: kdo vidí zákaznická data

Únik nemusí začít průlomem zvenku. Stačí ukradené heslo zaměstnance nebo přístup dodavatele, který už dávno skončil. Proto:

• Role s minimálními oprávněními. Marketér nepotřebuje exportovat celou databázi zákazníků, grafik nepotřebuje objednávky.
• Dvoufaktorové ověření pro všechny přístupy k zákaznickým datům. Detailně v článku Dvoufaktorové ověření a správa přístupů týmu.
• Každá integrace přes REST API má vlastní klíč jen s nezbytnými oprávněními. Dopravce potřebuje adresu a telefon, ne historii nákupů.
• Pravidelná revize účtů a klíčů, třeba jednou za čtvrtletí. Po odchodu člověka nebo dodavatele přístup zrušte hned.

Exporty, testovací data a marketingové nástroje

Tyto kopie dat často nikdo nehlídá, a proto si zaslouží zvláštní pozornost.

• Exporty do tabulek. CSV se seznamem zákazníků posílané e-mailem nebo ležící na sdíleném disku je bezpečnostní díra. Pokud export potřebujete, omezte sloupce a smažte ho, když ho už nepotřebujete.
• Testovací a vývojová prostředí. Kopie ostré databáze na testovacím serveru nebo notebooku vývojáře bývá chráněná hůř než produkce a snadno se na ni zapomene. Pro vývoj používejte pseudonymizovaná data, kde jsou jména, e-maily a telefony nahrazené smyšlenými.
• Marketingové a analytické nástroje. Posílejte jim jen to, co potřebují. U měření přes server-side tracking máte nad odesílanými daty větší kontrolu a můžete je před odesláním omezit.
• AI nástroje. Zákaznická data nevkládejte do veřejných AI služeb bez smlouvy o zpracování. Víc v článku AI a GDPR: na co si dát pozor.

Logování, zálohy a připravenost na incident

GDPR chce, abyste únik dokázali zjistit a obnovit data. Obojí se musí připravit předem.

• Logujte přihlášení do administrace, exporty dat a změny oprávnění. Logy uchovávejte odděleně a hlídejte i jejich obsah, samy nesmí zbytečně obsahovat osobní údaje.
• Nastavte upozornění na neobvyklé chování, například hromadný export nebo přihlášení z nové země.
• Zálohujte šifrovaně a mimo produkci. Rytmus a místa uložení popisujeme v článku Zálohování e-shopu: jak často a kam.
• Mějte plán pro případ úniku. Podle článku 33 GDPR musíte únik ohlásit Úřadu pro ochranu osobních údajů bez zbytečného odkladu a pokud možno do 72 hodin, ledaže je nepravděpodobné, že by představoval riziko pro práva zákazníků. Úřad k tomu má online formulář. Postup krok za krokem je v článku Krizový plán při úniku dat.

Checklist technických opatření

• Víme, kde všude leží zákaznická data: e-shop, ERP, e-mailing, dopravci, tabulky, zálohy.
• Sbíráme jen údaje, které potřebujeme, a máme lhůty pro jejich mazání.
• HTTPS je na celém webu, administraci i API. Soubory posíláme přes SFTP.
• Zálohy jsou šifrované a obnovu jsme vyzkoušeli.
• Hesla zákazníků jsou uložená pomalým hashem, ověřeno i u vlastních modulů.
• Platební karty neukládáme, platby řeší brána.
• Přístupy jsou podle rolí, s dvoufaktorovým ověřením a pravidelnou revizí.
• Testovací prostředí nepoužívá ostrá data.
• Logujeme přihlášení, exporty a změny oprávnění.
• Máme plán pro únik dat včetně ohlášení ÚOOÚ.

Jak na to prakticky

Začněte mapou dat. Vezměte jednu objednávku a projděte, kam všude její údaje putují. Obvykle se ukáže víc míst, než byste čekali. Pak řešte to nejsnazší s největším dopadem: minimalizaci, přístupy a testovací data. Šifrování a logování přijdou na řadu potom.

Pokud chcete vědět, jak na tom váš e-shop je, uděláme vám audit se seznamem nálezů seřazeným podle rizika. Technické úpravy, jako je pseudonymizace testovacích dat, bezpečné exporty nebo úprava starých modulů, pak řešíme v rámci programování na míru.