Kto všetko vidí dáta vašich zákazníkov? Bezpečnosť dát v systéme na mieru

01Kde dáta unikajú: čísla za Slovensko

Národný bezpečnostný úrad (NBÚ) eviduje dlhodobo rastúci počet hlásení kybernetických incidentov. V roku 2025 ich bolo 1 650, približne o 40 % viac ako v roku 2024. NBÚ dodáva, že časť nárastu ide na vrub novej legislatívy, pod ktorú spadá viac organizácií.

Z typov incidentov jasne vedie sociálne inžinierstvo, teda podvodné e-maily, správy a telefonáty. Útočník sa tak často dostane do systému s prihlasovacími údajmi, ktoré mu niekto sám prezradil. Preto systém nemá stáť len na hesle.

Podľa Eurostatu malo v roku 2023 bezpečnostný incident s následkami 12,3 % slovenských firiem s aspoň desiatimi zamestnancami, menej ako je priemer EÚ (21,5 %). Najčastejším následkom bola nedostupnosť služieb pre zlyhanie hardvéru alebo softvéru (9,1 % firiem). Zálohy a schopnosť systém rýchlo obnoviť sú preto rovnako dôležité ako ochrana pred útočníkmi.

Úniky sú aj drahé. Podľa správy IBM Cost of a Data Breach 2026, pre ktorú Ponemon Institute skúmal 602 organizácií v 16 krajinách a regiónoch, stál priemerný únik dát 4,99 milióna USD. Najčastejšie unikali osobné údaje zákazníkov, a to v 52 % prípadov. Čo z toho vyplýva pre vedenie firmy, rozoberáme v článku Čo musí vedenie zariadiť pred spustením aplikácie.

02O bezpečnosti sa rozhoduje v každej fáze projektu

GDPR v článku 25 vyžaduje, aby prevádzkovateľ zaviedol ochranu údajov už vo chvíli, keď určuje prostriedky spracúvania, teda keď sa systém navrhuje. Európsky výbor pre ochranu údajov (EDPB) vo svojich usmerneniach k článku 25 výslovne spomína aj obstarávanie, outsourcing, vývoj, testovanie, údržbu a mazanie. Prakticky to znamená, že každá fáza projektu má vlastné bezpečnostné úlohy.

Ako celý projekt prebieha u nás, od prvého hovoru po odovzdanie, opisujeme na stránke Ako to prebieha.

03Na začiatku je súpis údajov

Skôr ako vznikne prvá obrazovka, spíšte, aké údaje bude systém ukladať. Ku každému údaju patria tri otázky: prečo ho potrebujeme, ako dlho ho budeme mať a kto ho smie vidieť. GDPR tomu hovorí minimalizácia údajov. Čo systém nezbiera, to nemôže uniknúť.

Rovnako dôležité je mazanie. Keď pominie účel a uplynú zákonné lehoty uchovávania, údaje sa majú vymazať alebo nezvratne anonymizovať. EDPB pripomína, že prevádzkovateľ musí určiť, aké osobné údaje a na ako dlho potrebuje aj v zálohách a logoch. Mazanie preto patrí do zadania ako samostatná funkcia, napríklad nočná úloha, ktorá prejde staré záznamy.

Anonymizácia sa musí robiť poriadne. Úrad na ochranu osobných údajov SR v správe za rok 2025 opisuje zmluvy zverejnené v PDF, v ktorých boli osobné údaje len prekryté. Stačilo text skopírovať do Wordu a údaje boli čitateľné. Úrad v tom videl porušenie čl. 32 GDPR.

Ak bude systém vo veľkom rozsahu spracúvať osobitné kategórie údajov alebo systematicky monitorovať ľudí, GDPR (čl. 35) vyžaduje ešte pred spustením posúdenie vplyvu na ochranu osobných údajov. Zistiť to treba už pri zadaní.

04Kto má k čomu prístup: roly, oprávnenia a dvojfaktorové overenie

Chybné riadenie prístupu je v rebríčku rizík OWASP Top 10:2025 na prvom mieste a nejakú jeho formu našli testeri pri 100 % testovaných aplikácií. Typický príklad: obchodník si v adrese zmení číslo zákazníka a otvorí kartu klienta, ktorého nemá vidieť. Podrobne tieto chyby rozoberáme v článku Chyby v kóde, cez ktoré unikajú dáta.

• Oprávnenia kontroluje server pri každej požiadavke. Skryté tlačidlo v aplikácii nič nechráni.
• Roly podľa skutočnej práce. Obchodník vidí svojich klientov, účtovníčka faktúry, podpora len to, čo potrebuje na vyriešenie požiadavky.
• Najmenšie nutné oprávnenia. Nový používateľ začína s minimom a oprávnenia sa mu pridávajú podľa potreby.
• Hromadný export osobitne. Stiahnuť celú databázu zákazníkov do Excelu má môcť len pár ľudí a každý export sa zapíše.
• Osobné účty, žiadne zdieľané. Účet „admin“ so spoločným heslom znemožní zistiť, kto čo urobil.
• Odchod zamestnanca znamená zrušenie prístupu v ten istý deň. Najlepšie prepojením na personálnu evidenciu alebo firemné účty, aby sa na to nedalo zabudnúť.

K oprávneniam patrí aj bezpečné prihlásenie. Keďže sociálne inžinierstvo tvorí takmer dve tretiny nahlásených incidentov, samotné heslo nestačí. Dvojfázové overenie má podľa Eurostatu len 37,2 % slovenských firiem. Pri internom systéme s údajmi zákazníkov by malo byť samozrejmosťou, aspoň pre správcov a pre roly s exportom. Ako ho nastaviť pri bežných účtoch, ukazujeme v návode Ako zabezpečiť telefón a účty.

05Auditný log: kto sa na čo pozeral a čo zmenil

Keď sa niečo stane, prvá otázka znie: kto k údajom pristupoval? Bez záznamu prístupov na ňu neodpoviete. GDPR v čl. 32 vyžaduje schopnosť zabezpečiť trvalú dôvernosť a integritu systémov a bez logu nepreukážete, že údaje nevidel nikto nepovolaný.

• kto, kedy a odkiaľ sa prihlásil, vrátane neúspešných pokusov,
• kto otvoril, zmenil, vymazal alebo exportoval ktorý záznam,
• zmeny rolí a oprávnení a kto ich urobil,
• prístupy správcov a dodávateľa, osobitne tie mimo bežného pracovného času.

Do logu naopak nepatria heslá, prístupové tokeny, celé rodné čísla ani čísla kariet. Log musí byť chránený pred úpravami a mať stanovenú dobu uchovávania. Nemá zmysel ho držať večne, ale ani tak krátko, aby zmizol skôr, ako sa na únik príde. IBM uvádza, že odhalenie a zastavenie úniku trvalo v priemere 247 dní.

Slovenské firmy šifrujú častejšie ako priemer EÚ, v zálohách, logoch, viacfaktorovom overení aj v dokumentácii bezpečnosti však zaostávajú. Práve tieto opatrenia sa pri systéme na mieru dajú zaviesť lacno, keď sa s nimi počíta od začiatku.

06Šifrovanie: pri prenose, v databáze aj v zálohe

Podľa IBM 53 % organizácií, ktorým unikli dáta, nemalo citlivé údaje šifrované zároveň pri uložení aj pri prenose. Organizácie, ktoré šifrovanie používali, mali cenu úniku v priemere o 213 478 USD nižšiu.

• Prenos: HTTPS všade, aj medzi vlastnými službami a pri volaní API. Nastavenie servera a certifikátov opisujeme v článku Ako zabezpečiť server, HTTPS a cloud.
• Uloženie: šifrovaný disk a databáza. V cloude ide väčšinou len o zapnutie, ale treba to overiť.
• Citlivé polia: rodné čísla alebo zdravotné údaje šifrovať navyše priamo v aplikácii, s kľúčom uloženým mimo databázy.
• Heslá: ukladať ako hash pomalým algoritmom (Argon2, bcrypt), aby sa z uniknutej databázy nedali zistiť.
• Zálohy: šifrované a s iným kľúčom a inými prístupmi ako ostrý systém.

Šifrovanie má aj právnu výhodu. Keď uniknú údaje, ktoré sú pre nepovolané osoby nezrozumiteľné, napríklad vďaka šifrovaniu, prevádzkovateľ podľa čl. 34 ods. 3 písm. a) GDPR nemusí o porušení informovať dotknuté osoby, ak nebol prezradený aj kľúč. Oznámenie úradu tým však automaticky neodpadá.

07Ostré dáta nepatria do vývoja ani na testovací server

Najrýchlejší spôsob, ako otestovať novú funkciu, je stiahnuť si kópiu ostrej databázy. Je to aj jeden z najčastejších spôsobov, ako údaje opustia kontrolované prostredie. Testovací server býva horšie chránený, pristupuje k nemu viac ľudí a kópie končia na notebookoch vývojárov.

Americký štandard NIST SP 800-53 (opatrenia SA-3(2) a PM-25) upozorňuje, že použitie ostrých dát vo vývoji a testovaní môže znamenať výrazné riziko, a odporúča testovacie alebo vymyslené údaje. GDPR samo testovanie na ostrých dátach výslovne nezakazuje, no zásady minimalizácie a ochrany už pri návrhu smerujú rovnakým smerom. Pozor na častý omyl: pseudonymizované údaje sú stále osobné údaje. EDPB to zdôrazňuje vo svojich usmerneniach k pseudonymizácii z januára 2025 (zatiaľ verzia na verejnú konzultáciu). Ak sa záznam dá podľa kľúča alebo iných údajov priradiť ku konkrétnemu človeku, GDPR sa naň vzťahuje naďalej.

• Na vývoj používajte generované údaje, ktoré vyzerajú realisticky, ale nepatria nikomu skutočnému.
• Keď potrebujete skutočný objem alebo štruktúru, anonymizujte kópiu nezvratne ešte na produkčnom serveri, skôr ako ho opustí.
• Testovací server schovajte za prihlásenie a nenechávajte ho verejne dostupný.
• Vývojári nemajú mať trvalý prístup do ostrej databázy. Výnimky len na nevyhnutný čas a so záznamom v logu.

/* Kópia na testovanie: osobné údaje prepísať skôr, ako dáta opustia produkciu */
UPDATE customers SET
  name = 'Zákazník ' || id,
  email = 'zakaznik' || id || '@example.com',
  phone = NULL,
  birth_number = NULL,
  note = NULL;

Ako ľahko údaje opustia kontrolované prostredie aj vo veľkých firmách, ukázal prípad Microsoftu. Tím výskumníkov AI v roku 2020 zverejnil na GitHube odkaz na trénovacie dáta. Zdieľací token však namiesto jedného priečinka otváral celý účet úložiska (storage account) s právami na úplnú kontrolu a s platnosťou neskôr predĺženou až do roku 2051. Podľa spoločnosti Wiz, ktorá chybu v roku 2023 našla, bolo dostupných 38 TB dát vrátane zálohy počítačov dvoch zamestnancov s heslami, kľúčmi a viac ako 30 000 internými správami z Teams. Microsoft potvrdil, že údaje zákazníkov medzi nimi neboli.

08Tajné kľúče a zdrojový kód u dodávateľa

Toyota v októbri 2022 oznámila (tlačová správa je len po japonsky), že mohlo uniknúť 296 019 e-mailových adries a zákazníckych čísel používateľov služby T-Connect. Príčina: firma, ktorá pre Toyotu vyvíjala webovú stránku služby T-Connect, v decembri 2017 v rozpore s pravidlami nahrala časť zdrojového kódu do verejného účtu na GitHube. V kóde bol prístupový kľúč k dátovému serveru a takmer päť rokov si to nikto nevšimol.

Podobných prípadov je veľa. Podľa správy GitGuardian State of Secrets Sprawl 2026 pribudlo len za rok 2025 vo verejných commitoch na GitHube 28,65 milióna nových tajných kľúčov a hesiel. Z platných kľúčov nájdených v roku 2022 ich v januári 2026 stále fungovalo viac ako 64 %. Ako kľúče chrániť a ako sa brániť útokom cez závislosti, rozoberáme v článku Ako sa kradnú API kľúče.

• Repozitár so zdrojovým kódom má byť na účte vašej firmy a dodávateľ v ňom má vlastný prístup.
• Heslá a kľúče patria do správcu tajných kľúčov (secret manager) alebo do premenných prostredia, nikdy do kódu.
• Repozitár má mať zapnutú automatickú kontrolu uniknutých kľúčov.
• Po skončení spolupráce s dodávateľom alebo po odchode vývojára sa kľúče vymenia.

09Nástroje AI: údaje zákazníkov do chatu nepatria

Podľa tohtoročnej správy IBM sa 43 % bezpečnostných incidentov v skúmaných organizáciách týkalo takzvanej tieňovej AI, teda nástrojov, ktoré zamestnanci používajú bez schválenia firmy. To je viac ako dvojnásobok oproti predchádzajúcej správe. Stačí, aby niekto vložil export zákazníkov do verejného chatbota a požiadal o zhrnutie.

Spomedzi organizácií, ktoré riešili únik súvisiaci s AI, navyše 92 % nemalo správne nastavené riadenie prístupu pre AI. To sa týka aj funkcií AI priamo v systéme. Asistent, ktorý pracuje s údajmi z CRM, musí rešpektovať rovnaké oprávnenia ako prihlásený používateľ, inak sa cez neho dá opýtať na čokoľvek.

• Určte, ktoré nástroje AI sa vo firme smú používať a s akými údajmi.
• Údaje zákazníkov posielajte len do služieb, s ktorými máte zmluvu o spracúvaní a ktoré údaje nepoužívajú na trénovanie.
• Funkcie AI v systéme napojte na rovnaké oprávnenia, aké má používateľ, a ich dopyty logujte.

Aké povinnosti prináša európske nariadenie o umelej inteligencii, zhŕňame v článku AI Act: čo musia firmy riešiť.

10Zálohy, z ktorých sa dajú dáta naozaj obnoviť

GDPR v čl. 32 počíta so schopnosťou včas obnoviť dostupnosť osobných údajov po incidente. Zálohu na oddelené miesto má podľa Eurostatu 73,2 % slovenských firiem, menej ako je priemer EÚ (79,2 %). Že na zálohách záleží, ukazuje NBÚ vo svojej správe za rok 2025. Úrad geodézie, kartografie a katastra na začiatku roka 2025 zasiahol ransomvér, údaje katastra sa však dali obnoviť zo zálohy. Celková obnova infraštruktúry aj tak trvala niekoľko mesiacov. V inom prípade firma útočníkovi zaplatila výkupné, dostala dešifrovací nástroj len na časť súborov a až potom sa ukázalo, že má funkčné zálohy.

• Pravidlo 3-2-1, ktoré odporúča aj SK-CERT: aspoň tri kópie dát, na dvoch rôznych typoch médií a jedna mimo pracoviska.
• Aspoň jedna kópia offline alebo nemenná, aby ju ransomvér nemohol zašifrovať ani vymazať. SK-CERT upozorňuje, že zálohovacie médium nemá byť neustále pripojené k zálohovanému zariadeniu.
• Zálohy na inej infraštruktúre a s inými prístupmi ako ostrý systém. Kto ovládne server, nesmie sa tým dostať aj k zálohám.
• Obnovu pravidelne skúšať naostro. Kontrola, že záloha prebehla, nestačí.
• Vopred určiť, ako dlho smie systém stáť a o koľko údajov môžete najviac prísť. Podľa toho sa nastaví frekvencia záloh.

11Kde údaje ležia: hosting, cloud a prenos mimo EÚ

Služba, ktorá pre vás a na váš pokyn spracúva osobné údaje, je podľa GDPR spravidla sprostredkovateľ. Typicky ide o hosting, cloud, rozosielanie e-mailov, sledovanie chýb v aplikácii alebo služby AI. Sprostredkovateľ nesmie zapojiť ďalšieho sprostredkovateľa bez vášho povolenia (čl. 28 ods. 2 GDPR). Vyžiadajte si preto od dodávateľa zoznam všetkých služieb, cez ktoré budú údaje v systéme tiecť, aj s krajinou, kde ležia.

Pri službách z USA hrá úlohu rámec na ochranu osobných údajov medzi EÚ a USA (Data Privacy Framework). Európska komisia ho schválila 10. 7. 2023 a platí len pre americké firmy, ktoré sa k nemu prihlásili. Všeobecný súd EÚ v septembri 2025 zamietol žalobu, ktorá ho napádala, proti rozsudku sa však žalobca odvolal na Súdny dvor EÚ. Kde sa dá, je preto jednoduchšie mať údaje uložené v EÚ.

Ani v cloude nerieši bezpečnosť všetko poskytovateľ. V roku 2024 upozornili firmy Mandiant a Snowflake približne 165 zákazníkov dátovej platformy Snowflake, že im útočníci mohli odcudziť dáta. Podľa vyšetrovania spoločnosti Mandiant pritom nebola prelomená samotná platforma. Útočníci použili ukradnuté heslá k účtom bez viacfaktorového overenia a niektoré sa nezmenili až štyri roky.

Myslite aj na odchod. Nariadenie EÚ o údajoch (Data Act) sa uplatňuje od 12. 9. 2025 a ukladá poskytovateľom cloudu uľahčiť prechod k inému poskytovateľovi. Od 12. 1. 2027 za prechod a za prenos údajov von nesmú účtovať žiadne poplatky, ako uvádza Európska komisia.

12Zmluva s dodávateľom: čo v nej nesmie chýbať

Dodávatelia sú dnes jednou z hlavných ciest k údajom. Podľa správy Verizon DBIR 2026 sa tretia strana podieľala na 48 % únikov, o 60 % viac ako rok predtým. NBÚ v správe za rok 2025 píše, že „kybernetický incident u dodávateľa môže mať vplyv na desiatky ďalších organizácií v dodávateľskom reťazci“.

Ak sa dodávateľ pri vývoji, správe alebo podpore dostane k osobným údajom, je sprostredkovateľom a GDPR v čl. 28 vyžaduje písomnú zmluvu. Že to nie je formalita, ukazuje kontrola úradu z roku 2025: firma, ktorá skartovala dokumenty pre viacerých prevádzkovateľov, s nimi nemala uzavreté sprostredkovateľské zmluvy ani neprijala primerané opatrenia. Zmluva by mala obsahovať najmä toto:

• spracúvanie len na váš pokyn a mlčanlivosť všetkých ľudí dodávateľa, ktorí majú k údajom prístup,
• konkrétne bezpečnostné opatrenia (šifrovanie, dvojfaktorové overenie, logy, zálohy), nie len odkaz na čl. 32,
• subdodávatelia len s vaším predchádzajúcim povolením a s rovnakými povinnosťami,
• oznámenie incidentu bez zbytočného odkladu, najlepšie s lehotou v hodinách, aby ste stihli svojich 72 hodín,
• pomoc so žiadosťami dotknutých osôb o prístup k údajom alebo o výmaz,
• vrátenie alebo vymazanie údajov vrátane kópií po skončení spolupráce, podľa vašej voľby,
• právo na kontrolu alebo audit,
• mimo GDPR: zdrojový kód a repozitár na vašom účte, bezpečnostný test pred spustením, aktualizácie knižníc a individuálne prístupy pre každého človeka dodávateľa.

Pri prístupoch dodávateľa odporúča SK-CERT vydávať individuálne účty namiesto spoločného účtu s menom firmy a otvárať prístup len na obmedzený čas, keď ho dodávateľ naozaj potrebuje.

Ak je vaša firma prevádzkovateľom základnej služby podľa zákona č. 69/2018 Z. z. o kybernetickej bezpečnosti, ktorý po novele účinnej od 1. 1. 2025 preberá smernicu NIS2, musíte s treťou stranou, ktorá pre vás vykonáva činnosť priamo súvisiacu s prevádzkou vašich sietí a informačných systémov, uzavrieť zmluvu o zabezpečení plnenia bezpečnostných opatrení a notifikačných povinností a pri tom vykonať analýzu rizík (§ 19 ods. 2). Čo robiť, keď dodávateľ prestane komunikovať a údaje aj kód drží u seba, opisujeme v článku Ako prevziať web od dodávateľa.

13Keď údaje predsa uniknú

Na plán reakcie je neskoro vo chvíli, keď k úniku dôjde. Lehoty sú krátke a plynú od okamihu, keď sa o probléme dozviete.

Porušenie ochrany osobných údajov sa oznamuje Úradu na ochranu osobných údajov SR. Úrad v správe za rok 2025 konštatuje, že väčší prevádzkovatelia postupujú spravidla správne, u menších však pretrváva neznalosť povinnosti únik oznámiť. Dokumentovať pritom treba všetky prípady, aj tie, ktoré sa neoznamujú.

Do plánu reakcie patrí, kto rozhoduje o ďalšom postupe, ako sa kontaktuje dodávateľ mimo pracovného času a ako rýchlo zistíte, ku ktorým záznamom sa kto dostal. Tu opäť prichádza na rad auditný log. Kto ho nemá, často nevie preukázať, čo zostalo v bezpečí, a musí rátať s najhoršou možnosťou. NBÚ pri tom pripomína pravidlo nikdy neplatiť útočníkovi, pretože obeť nemá žiadnu záruku, že dáta naozaj dostane späť.

14Otázky, ktoré položiť dodávateľovi

Skôr ako podpíšete zmluvu na systém na mieru, položte dodávateľovi týchto osem otázok. Na každú by mal odpovedať konkrétne a bez dlhého premýšľania.

Ak zvažujete, či systém na mieru vôbec potrebujete, pomôže článok Kedy už firme nestačí Excel. Orientačné ceny vývoja nájdete v cenníku.

15Časté otázky

16Zdroje

• ÚOOÚ SR: Správa o stave ochrany osobných údajov za rok 2025
• ÚOOÚ SR: Oznámenie porušenia ochrany osobných údajov
• NBÚ: Správa o kybernetickej bezpečnosti v SR v roku 2025
• SK-CERT: Zálohovanie
• SK-CERT: Riadenie prístupov pre dodávateľov
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov
• Zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti
• Nariadenie GDPR na EUR-Lex
• EDPB: Guidelines 4/2019 on Article 25
• EDPB: Guidelines 01/2025 on Pseudonymisation
• Eurostat: ICT security in enterprises
• IBM: Cost of a Data Breach Report 2026
• Verizon: 2026 DBIR Executive Summary
• OWASP Top 10:2025, A01 Broken Access Control
• NIST SP 800-53 Rev. 5
• GitGuardian: State of Secrets Sprawl 2026
• Wiz: 38 TB dát z Microsoftu
• Toyota: tlačová správa k T-Connect (po japonsky)
• Mandiant: UNC5537 a Snowflake
• Európska komisia: Data Act explained