Příklady procesů - ochrana dat a GDPR

V této kap. budou uváděny příklady, které můžete využít pro inspiraci, pokud řešíte nastavení řízení přístupu k položkám či nějaký jiný proces s ochranou dat spojený.

Nechť chceme chránit nějakou položku z titulu GDPR, jelikož jsme vyhodnotili, že obsahuje či může obsahovat osobní údaj. Pro příklad procesu nastavení je jedno, jakou položku si pro předvedení vybereme. Nechť je takovou položkou např. položka Adresát v adrese sídla firmy (ResidenceAddress_ID.Recipient). Tj. chceme, aby obsah dané položky byl dostupný jen těm uživatelům, kteří mají mít z nějakého titulu oprávnění ji zpracovávat (např. jsou to obchodníci, kteří s danou firmou obchodují). Doporučený postup:

Pak musíme mít alespoň jednu definici ochrany dat, která:

  • používá ovladač GDPR (aby se jednalo o ochranu dat dle nařízení GDPR) a je aktivní

  • obsahuje naši položku mezi chráněnými položkami

  • mezi oprávněnými uživateli má uživatele, kteří mají oprávněný důvod daný osobní údaj zpracovávat (řekněme tedy např. naše obchodníky a ředitele firmy pana Nováka)

To ale samo o sobě pro ochranu dle GDPR nestačí. Tím je pouze dáno, že položka je chráněná a nikdo jiný, než vyjmenovaní uživatelé se k ní nedostanou. Zda se k ní ale dostanou vyjmenovaní oprávnění uživatelé u jednotlivých subjektů (v tomto případě firem), ještě u ochrany dle GDPR závisí na existenci povolení od daného subjektu. Tudíž musí existovat nějaké relevantní povolení ke zpracování dat od jednotlivých subjektů, které se odkazuje na tuto definici (mohlo vzniknout např. automatickým generováním z dokladů či ze smlouvy na základě pravidel, viz Vytváření povolení podle pravidel):

Pak budete mít ochranu dat funkční tak, tak, jak jste potřebovali. Tj. pokud se pak přihlásí jeden z obchodníků, bude položka dostupná u těch subjektů, pro něž existuje platné povolení, tedy např. pro subjekt firma ABC, ale JEN těm uživatelům, kteří jsou mezi oprávněnými, tedy např. našemu panu Novákovi.

Jakmile se ale přihlásí jiný uživatel, bude mít položku nedostupnou.

Nechť chceme chránit nějaké položky z titulu GDPR, jelikož jsme vyhodnotili, že obsahují obecné osobní údaje, ale současně evidujeme i citlivé osobní údaje. Předpokládá se, že k těm citlivým by měl správce GDPR přistupovat s "větší opatrností" a zpřístupnit je opravdu jen velmi omezenému okruhu uživatelů, kdežto ty obecné bude mít k dispozici větší okruh uživatelů, aby vůbec s danými subjekty mohli komunikovat.

Doporučený postup:

Aby toto bylo možné definovat, je třeba mít více definic ochrany dat - a každou s jinou množinou položek (zvlášť si chránit obecné osobní údaje a zvlášť ty citlivé) a každou s jinou množinou oprávněných uživatelů.

Samotné nastavení ochrany vybrané položky, viz Proces nastavení ochrany vybrané položky.

Doporučený postup:

Plyne z dále uvedených skutečností a příkladů a konkrétní varianta, kterou použijete, závisí na tom, čeho potřebujete u vás dosáhnout.

U dokladů se typicky bude rozlišovat, zda se o nich účtuje či nikoliv. Ze zákona o účetnictví je povinnost uchovávat údaje nějakou požadovanou dobu (10 let). Tím je dáno, že uživatelé pracující s těmito doklady (fakturanti, účetní, ...) mají oprávnění k přístupu k chráněným položkám subjekt z těchto dokladů po dobu danou ze zákona. Jinak je tomu např. u obchodníků, kde bude zdůvodnitelná doba, po kterou budou mít možnost zpracovávat údaje subjektu výrazně kratší (např. po dobu záruky apod. - záleží na vašich procesech a výkladu nařízení GDPR, schopnosti si zdůvodnit držení osobních údajů v tom kterém případě). Chceme z těchto dokladů příslušná povolení generovat automaticky vždy s adekvátní platností.

Z toho plyne, že bude v praxi vhodné si nadefinovat minimálně dvě skupiny definic ochrany dat, které mají řídit přístup k položkám z titulů dokladů vzniklých v ABRA Gen:

  • Jeden typ definice pro "účtárnu", kde budou oprávnění uživatelé "z účtárny" (fakturanti, účetní, ...) a kde může být množina položek omezená (např. účetní potřebuje vidět ty položky, které jsou na účetním dokladu, ale už nepotřebuje mít přístup např. k e-mailu či fotografii dané osoby) a na kterou pak budou navázána pravidla ochrany dat pro generování z dokladů s platností podle zákona (tj. např. oněch 10 let)
  • Druhý typ definice pro "ostatní uživatele", kde bude množina položek výrazně bohatší (např. vč. fotografií), přičemž mezi oprávněnými uživateli pak mohou být např. obchodníci, ale třeba i ti fakturantni a účetní, a na kterou pak budou navázána pravidla ochrany dat s kratší platností, např. na 2 roky

Jelikož pravidla se nastavují pro jednotlivé oblasti dokladů, z nichž mohou povolení vznikat, čili zvlášť pro faktury vydané, zvlášť pro faktury přijaté atd., je pak třeba si nadefinovat pravidla pro všechny oblasti, z nichž chcete povolení u vás generovat. Čili pro každou oblast účtovaných dokladů (např. Nákup/Faktury přijaté), budete mít minimálně dvě pravidla - jedno pravidlo navázané na definic ochrany dat z titulů dokladů "pro účtárnu" a druhé pravidlo navázané na definic ochrany dat z titulů dokladů "pro účtárnu".

Podle těchto pravidel pak vzniknou ke každému dokladu z dané oblasti minimálně dvě povolení (např. naplánovanou úlohou). Jednak povolení na 2 roky k položkám subjektu (např. vč. fotografií) pro všechny uživatele a 10 let pro účtárnu. Obchodník pak uvidí údaje subjektu 2 roky vč. např. té zmíněné fotografie, ale poté už neuvidí žádnou z chráněných položek, pracovník účtárny uvidí po 2 roky např. i tu fotografii, a následujících 8 let uvidí jen ty položky, které potřebuje z titulu účetního dokladu (tj. tu fotografii už ne). Viz též Vytváření povolení podle pravidel.

Pro oblasti dokladů, o nichž se neúčtuje, vám pravděpodobně postačí jen jedna definice, na kterou pak navážete svá pravidla pro tyto oblasti (Prodej/Objednávky přijaté, Prodej/Nabídky vydané, aj.).

Pravidla lze rozlišit až na řady dokladů (viz Parametry zadávané u pravidel). Lze pak mít více pravidel a např. kromě dvou výše zmíněných mít ještě další s platností 3 roky ale jen z titulu dokladu vystaveného v nějaké konkrétní řadě XY a u pravidla na 2 roky naopak specifikovat všechny řady kromě řady XY. Pak vám z dokladu vystaveného v řadě XY vznikne jedno povolení na 3 roky a druhé na 10 let, kdežto z dokladu vystavěného mimo řadu XY vznikne jedno povolení na 2 roky a druhé na 10 let jako v předchozím případě.

I samotných definic určených pro generování povolení z dokladů podle pravidel lze mít více než jen dvě a k těmto různým definicím (různé položky, různí uživatelé) pak navázat pravidla určená jen pro určitou konkrétní řadu. U dokladů to asi není účelné, ale pokud byste to potřebovali, můžete to využít. Inspiraci najdete dále, viz příklady v sekci řízení přístupu z titulu smluv (kde to naopak účelné je).

Doporučený postup:

Plyne z dále uvedených skutečností a příkladů a konkrétní varianta, kterou použijete, závisí na tom, čeho potřebujete u vás dosáhnout.

U smluv se předpokládá, že různé typy smluv (kupní, servisní, dealerská, smlouva o dílu, ...) budou zakládat různou délku platnosti pro následná povolení a současně, že bude existovat různá množina oprávněných uživatelů, kteří budou potřebovat zpracovávat položky z titulu daného typu smlouvy. Na rozdíl např. od dokladů typu faktury vydané, kde s údaji daného subjektu, jemuž byla vystavena faktura, budou potřebovat nakládat typicky "všichni" obchodníci po určitou dobu stejnou pro všechny faktury, tak u smluv to bude pravděpodobně jinak - u dealerských to budou např. obchodníci, kdežto u servisních to budou pracovníci supportu apod., přičemž délka období, po které tyto množiny uživatelů mají mít možnost zpracovávat chráněné položky , se liší - např. u dealerských smluv to může být neomezeně, dokud smlouva nebude ukončena (a poté např. následujících několik měsíců), kdežto u servisních smluv uzavřených na rok, to může být jen ten rok apod.

Aby bylo možno toto nastavit, je nutné tyto různé typy smluv vystavovat do různých řad (tj. nadefinujte si vícero řad dokladů typu "Smlouvy").

Pak je třeba mít více definic pro řízení přístupu k položkám z titulu těchto různých smluv (např. jednu definici z titulu kupních smluv pro jednu množinu uživatelů, jinou definici z titulu servisních smluv pro jinou množinu uživatelů). Tyto definice se pravděpodobně budou shodovat v množině chráněných položek, ale budou se lišit v množině oprávněných uživatelů.

Dále je třeba mít vícero pravidel navázaných na tyto různé definice, kde u každého pravidla lze určit jinou délku platnosti povolení generovaných ze smluv daného typu, tj. z dané řady dokladů (řadu resp. řady zadáte v parametrech pravidla).

S firmou Novák & syn uzavřete dealerskou smlouvu na 5 let (do řady smluv DEAL) a dále servisní smlouvu na rok (do řady SERV). Nadefinujete si definici ochrany dat z titulu smluv SML_DEAL, kde uvedete jako oprávněné ty vaše uživatele, kteří potřebují zpracovávat údaje subjektů, s nimiž jste uzavřeli smlouvu DEAL a dále druhou definici SML_SERV (s týmiž chráněnými položkami), kde uvedete jako oprávněné ty vaše uživatele, kteří potřebují zpracovávat údaje subjektů, s nimiž jste uzavřeli smlouvu SERV (nechť je mezi uživateli první definice je např. Kulhánková, která ale není u druhé definice a nechť mezi uživateli druhé definice je např. Malá, která naopak není u první definice). A dále pravidlo A na 5 let navázané na první definici SML_DEAL a na řadu dokladů DEAL a pravidlo B na 1 rok navázané na druhou na definici SML_SERV a na řadu dokladů SERV. Z titulu první smlouvy pak vznikne povolení zpracovávat chráněné údaje firmy Novák & syn např. 5 let (v praxi si spíše nastavíte 5 a něco) podle pravidla A pro oprávněné uživatele z první definice SML_DEAL, z titulu druhé smlouvy na 1 rok (v praxi to opět bude spíše 1 a něco) podle pravidla B pro oprávněné uživatele z druhé definice SML_SERV. Pak Kulhánková bude moci zpracovávat údaje subjektu Novák & syn 5 let, Malá jen 1 rok.

Pokud by pravidla nebyla navázána na řady smluv, pak by obě pravidla vygenerovala povolení z týchž smluv. To by mohlo být na závadu, jelikož subjekty různých typů smluv typicky nebudou shodné. Objasníme na druhém příkladu:

Nechť je stejné zadání jako v předchozím případě, jen smlouvy jsou vystaveny na jiné subjekty, tj. s firmou Novák & syn uzavřete dealerskou smlouvu na 5 let (do řady smluv DEAL) a s firmou Koťátko servisní smlouvu na rok (do řady SERV). Z titulu první smlouvy pak vznikne povolení zpracovávat chráněné údaje firmy Novák & syn na 5 let podle pravidla A pro oprávněné uživatele z první definice SML_DEAL, z titulu druhé smlouvy pak vznikne povolení zpracovávat chráněné údaje firmy Koťátko na 1 rok podle pravidla B pro oprávněné uživatele z druhé definice SML_SERV. Pak Kulhánková bude moci zpracovávat údaje subjektu Novák & syn 5 let, Malá bude moci zpracovávat údaje subjektu Koťátko 1 rok.

Pokud by pravidla nebyla navázána na řadu smluv, pak:
- z titulu první smlouvy by vzniklo:
-- povolení zpracovávat chráněné údaje firmy Novák & syn na 5 let podle pravidla A pro oprávněné uživatele z první definice SML_DEAL (tedy pro Kulhánkovou, což je OK)
-- povolení zpracovávat chráněné údaje firmy Novák & syn na 1 rok podle pravidla B pro oprávněné uživatele z druhé definice SML_SERV (tedy pro Malou, což není OK!)

- z titulu druhé smlouvy by vzniklo:
-- povolení zpracovávat chráněné údaje firmy Koťátko na 5 let podle pravidla A pro oprávněné uživatele z první definice SML_DEAL (tedy pro Kulhánkovou, což není OK!)
-- povolení zpracovávat chráněné údaje firmy Koťátko na 1 rok podle pravidla B pro oprávněné uživatele z druhé definice SML_SERV (tedy pro Malou, což je OK)

Pokud by se množina uživatelů, kteří mají mít oprávnění zpracovávat položky z titulu dané smlouvy nelišila pro různé typy smluv (tj. u vás to máte tak, že se všemi typy smluv pracují titíž lidé), pak by stačilo mít jen jednu definici a k ní vícero pravidel odkazujících se na tuto jednu definici, ale s různou délkou platnosti pro následná povolení podle toho, z jaké řady smluv se povolení budou generovat. Pak daný uživatel bude mít přístup k údajům subjektu tak dlouho, jak dlouho platí povolení s nejdelší platností.

S firmou Novák & syn uzavřete dealerskou smlouvu na 5 let (do řady smluv DEAL) a současně expresní servisní smlouvu na rok (do řady SERV). Nadefinujete si definici ochrany dat z titulu smluv, kde uvedete jako oprávněné ty vaše uživatele, kteří potřebují zpracovávat údaje subjektů, s nimiž jste uzavřeli smlouvu - nechť jsou to titíž uživatelé bez ohledu na to, o jaku smlouvu jde. A dále pravidlo 1 na 5 let navázané na řadu dokladů DEAL a pravidlo 2 na 1 rok navázané na řadu dokladů SERV. Z titulu první smlouvy pak vznikne povolení zpracovávat chránění údaje firmy Novák & syn např. 5 let (v praxi to bude typicky 5 a něco) podle prvního pravidla, z titulu druhé smlouvy na 1 rok (v praxi to opět bude spíše 1 a něco) podle druhého pravidla. Nicméně, jelikož obě pravidla jsou navázána na jednu a tutéž definici s týmiž uživateli, tak uživatel uvedený mezi oprávněnými bude moci zpracovávat údaje subjektu Novák & syn 5 let (tedy i poté, co vyprší platnost prvního pravidla).

Obě situace se dají samozřejmě kombinovat, tj. na jednu definici určenou pro řízení přístupu z titulu smluv může být navázáno více pravidel s různou platností, kdežto na zbylé definice určené pro řízení přístupu z titulu smluv může být navázáno po jednom pravidle.

Může nastat i limitní případ, že nebudete smlouvy rozlišovat řadou, jak bylo řečeno výše, a množina oprávněných uživatelů pro všechny smlouvy bude shodná a platnost povolení také. Pak vám bude stačit jedna definice na ochranu položek z titulu smluv a k ní jedno pravidlo.

Většina povolení ke zpracování dat subjektů nebude vznikat ručním zadáním, ale budete je generovat automaticky z existujících záznamů v systému a to podle nastavených pravidel ochrany dat. Inspiraci pro to, jak si nastavit pravidla, můžete čerpat v předchozích příkladech. Viz též viz Vytváření povolení podle pravidel. Nechť toto máte a nyní chcete, aby povolení vznikala resp. se aktualizovala bez nutnosti obsluhy uživatele.

Doporučený postup:

Vytvoříme si pravidla typu Generování pro jednotlivé oblasti navázané na příslušné definice /inspirace viz příklady výše. Dále si vytvoříme naplánované úlohy typu Generování povolení ke zpracování dat. Do Parametrů úloh vybereme postupně ta pravidla pro generování, která se mají provádět ve shodných intervalech - např. generování povolení z dokladů či aktivit je účelné provádět často (např. denně), kdežto aktualizace povolení ze zaměstnanců či smluv by mohla stačit např. jen jednou týdně - a u úloh nastavíme požadovaný intervalu spouštění.

V limitním případě můžete mít jen jednu naplánovanou úlohu typu Generování povolení a s ní generovat v jednom a tom samém čase povolení podle všech vašich pravidel pro generování (počítejte však s tím, že každé generování je jistá zátěž pro server).

Připomínáme, že k používání naplánovaných úloh je zapotřebí mít nainstalovaný a zprovozněný automatizační server, viz Co je třeba k provozu autoserveru a naplánovaných úloh.

Pokud by nastala situace, že nebude možné čekat, až se povolení vygenerují automaticky (potřebujeme data konkrétní firmy zpracovávat dříve), můžeme si potřebné povolení vygenerovat ručně funkcí Generovat v agendě Pravidla ochrany dat, případně Generovat povolení v Adresáři firem.

Nechť potřebujeme odeslat e-mailovou kampaň. V tomto momentě potřebujeme vidět / smět použít jen e-maily subjektů, na které máme oprávnění pro marketing, jiné obesílat nechceme (i když třeba k daným položkám máme přístup z jiného důvodu, např. z titulu řešení reklamací, z titulu účetních dokladů apod.).

Pro tento účel využijeme možnost filtrovat za firmy Jen s platným povolením ke zpracování dat k definici resp. obdobně za osoby z Adresáře osob. Zde vybereme definici (či definice), která chrání položku e-mail a je určena pro následná povolení přístupu k položkám pro marketingové účely. Čili vytvořili jsme si ji proto, abychom k ní pak vytvářeli Povolení ke zpracování dat od subjektů pro marketingové účely (je jedno, zda je pak budeme vytvářet na základě nějakých pravidel, či zda to budou ručně sbíraná povolení). Za dnou definici si zafiltrujeme. Tím máme jistotu, že vybrané firmy/osoby jsou ty subjekty, k jejichž e-mailu

Mějme 3 definice chránící položku e-mail z adresy sídla firmy ResidnceAddress_ID.EMAIL, jak ukazuje následující obrázek, přičemž nechť přihlášený uživatel je oprávněným uživatelem v každé z nich.

Nechť u subjektu AAA1 položky e-mail povolují dvě definice (definice "GDBU" , která je určena pro ochranu položek na základě existence dokladu s daným subjektem a definice ABRA_WEB, která je určena na tvorbu pravidel na základě sbíraných souhlasů od subjektů.

U subjektu Kofr nechť položku e-mail povoluje pouze definice GDBU. Firma Kofr nedala souhlas k použití e-mailu k marketingovým účelům:

Pokud si zafiltrujeme za Jen s platným povolením ke zpracování dat k definici a vybereme definici pro marketing, vybere se JEN firma AAA1. Takové firmy pak můžeme (např. přes ABRA schránku) převzít do kampaní.

Jelikož Ochrana dat se postupně upravuje, je možné, že se množina chránitelných položek jednotlivých tříd objektů může v čase měnit (např. v nižší verzi výrobce předpokládá, že by položka nějaké třídy Business objektů měla být chránitelná (v nabídce položek pro vybranou třídu business objektu v záložce Chráněné položky definice ochrany dat je dostupná), ve vyšší verzi tuto položku z ochrany vyloučí, např. z důvodu nějakého technického omezení.

Možné důsledky: Definice obsahující takovou položku je pak nevalidní (např. nebude možné ji smazat, skrýt apod.).

Doporučený postup: Po update na vyšší verzi proveďte kontrolu definic ochrany dat (funkce Kontrola definic a příp. funkce Porovnat se vzorem) a definice si zaktualizujte.