Řešení ochrany dat a GDPR v IS FLORES

V této kapitole je uvedeno, jakým způsobem je ochrana dat vč. ochrany osobních a citlivých dat dle nařízení GDPR řešena v rámci IS FLORES.

V IS FLORES byla implementace podpory GDPR pojata obecně a to tak, aby nesloužila pouze požadavkům nařízení GDPR, ale mohla být využita nad rámec GDPR pro ochranu obsahu i jiných údajů, než ukládá nařízení GDPR.

Např. v budoucnu pro ochranu obsahu položek obsahujících nákupní ceny apod.

Byl tedy navržen generický systém ochrany dat přesahující potřeby GDPR, v němž platí:

  • Nástroje umožní chránit jakoukoliv položku jakékoliv třídy business objektů v IS FLORES, včetně uživatelsky definovaných položek.

  • Nástroje umožní vypsat, vyexportovat či vymazat chráněná data k určité chráněné entitě (osoba, firma, ...).

    Plánováno bylo i šifrování komunikace mezi klientskou stranou a aplikačním serverem (https). Zda bude implementováno, závisí mj. na poptávce.

Obecný princip chování je následující:

Obecná ochrana dat - Ochrana dat (je-li zapnuta) podle daných pravidel umožní znepřístupnit obsah vybraných položek (tzv. chráněné položky) těm uživatelům, kteří je nemají zpracovávat (není zákonný ani jiný důvod, aby taková data viděli či je měnili), tj. nejsou oprávněnými uživateli. Jaké položky mají být chráněné a kdo je oprávněným uživatelem, je plně uživatelsky definovatelné.

Ochrana dat dle GDPR - U ochrany dat z titulu GDPR platí totéž, co u obecné ochrany dat, ale navíc se eviduje seznam povolení ke zpracování dat (souhlasy) od jednotlivých subjektů ochrany dat dle GDPR a při přístupu uživatele k chráněné položce se navíc také kontroluje, zda pro daný subjekt existuje platné povolení pro zpracování daných položek. Pak je obsah chráněných položek zpřístupněn pouze oprávněným uživatelům, jako v předchozím případě, ale pouze u záznamů těch subjektů, k jejichž údajům existuje platné povolení ke zpracování. Tedy aby ochrana dat dle GDPR zpřístupnila oprávněným uživatelům data, potřebuje mít povolení (souhlasy). Povolení mohou být získaná z externího zdroje (např. nasbírané podpisy souhlasů) nebo vygenerované ze stávajících dat.

O jakou ochranu jde a jak bude probíhat, je dáno použitým ovladačem ochrany dat. Rozdíl objasníme na zjednodušeném příkladu:

Nechť si jako chráněnou položku nadefinujeme např. e-mail osoby z Číselníku osob a jako oprávněné uživatele zadáme Nováka a Novákovou (jak, viz dále) a zapneme ochranu dat (jak, viz dále). Pokud bychom použili ovladač obecné ochrany dat (hypotetická situace, zatím takový ovladač není k dispozici, tudíž nelze popisovat jeho konkrétní chování), pak po zapnutí ochrany dat by e-mail všech osob byl dostupný pouze Novákovi a Novákové, nikdo jiný by jej neviděl. Pokud bychom použili ovladač GDPR, pak by Novák a Nováková měli dostupný e-mail jen těch osob, od nichž existuje povolení zpracovávat e-mail a e-mail jiných osob by neviděli ani oni. (Je zjevné, že obecná ochrana je vhodná např. na nákupní ceny, ne pro požadavky ochrany dle GDPR, ale jelikož jde zatím pouze o hypotetickou situaci, nelze ji přesně popisovat). Systém sice již nyní podporuje možnost definic ochrany položek napříč celým systémem (je-li licence, viz Co je třeba k provozu ochrany dat), ale v této fázi krom toho, že není k dispozici příslušný ovladač obecné ochrany, ani není funkcionalita ochrany dat všech takových položek odladěna a je pravděpodobné, že byste si jejím zapnutím způsobili nemalé potíže. Proto provozování ochrany dat pro systémové položky Business objektů nad rámec ochrany dle GDPR (viz Základní chráněné objekty z titulu GDPR) zatím nedoporučujeme.

Příklad, jak se projeví ochrana dat v agendě oprávněnému uživateli, pokud neexistuje od některých subjektů povolení

Které položky mají být chráněné, kteří uživatelé k nim mají mít oprávnění, jak má ochrana probíhat (kterým ovladačem) a odkdy (kdy se zapne) si definuje uživatel sám (může ale využít dodávaných vzorů, viz kap. Jak začít). Základní ochrana z titulu GDPR je k dispozici zdarma (systémové položky pro adresáře firem, osob, zaměstnanců), na rozšířenou ochranu je třeba licence.

Podrobněji viz dále.

V této fázi zatím není funkcionalita ochrany dat položek odladěna a je pravděpodobné, že byste si jejím zapnutím způsobili nemalé potíže. Proto provozování ochrany dat pro systémové položky Business objektů nad rámec ochrany dle GDPR (viz Základní chráněné objekty z titulu GDPR) zatím nedoporučujeme.

Z titulu GDPR je třeba chránit osobní údaje. V IS FLORES se primárně jedná o položky osob a firem (firem proto, že firma evidovaná v adresáři firem může být i fyzická osoba, navíc k formě mohou být připojeny osoby). Krom toho osoba může být současně zaměstnancem, firmy mají své provozovny (kde rovněž mohou být kontaktní údaje, které by mohly vést k identifikaci osoby, tudíž mohou být vyhodnoceny jako osobní údaj, který je nutné chránit), na záznamech se evidují nějaké obrázky atd.

Z toho důvodu se z titulu GDPR nabízí k ochraně položky pro následující třídy business objektů resp. pomocné virtuální třídy:

  • Firma (třída BO Firm) - pro ochranu údajů firem z Adresáře firem, které mají zatržený příznak Právnická osoba.
  • Firma (fyzická osoba) (virtuální třída PhysicalPersonFirm) - pro ochranu údajů firem z Adresáře firem, které nemají zatržený příznak Právnická osoba.
  • Osoba - (třída BO Person ) - pro ochranu osob "nezaměstnanců" (bez zatrženého Zaměstnanec/pracovník) a jejich údajů zobrazovaných v Adresáři osob, a samozřejmě i kdekoliv jinde, kam se údaje z adresáře osob propisují
  • Zaměstnanec (osoba) (virtuální třída EmployeePerson) - pro ochranu osob "zaměstnanců" (se zatrženým Zaměstnanec/pracovník) a jejich údajů zobrazovaných v Adresáři osob, a samozřejmě i kdekoliv jinde, kam se údaje z adresáře osob propisují
  • Zaměstnanec (třída BO Employee ) - pro ochranu údajů osob "zaměstnanců" (se zatrženým Zaměstnanec/pracovník) zobrazovaných v agendě Zaměstnanci, a samozřejmě i kdekoliv jinde, kam se údaje ze zaměstnanců propisují

  • Osoba ve firmě (třída FirmPerson) - pro ochranu údajů osob připojených k firmě

    Jak bylo řečeno v popisu záložky Osoby , některé údaje zde zobrazované jsou jen "pohledem" do adresáře Osob (pohledem na soukromé údaje dané osoby), jedná se o tytéž údaje jako v Adresáři osob, tj. soukromé (nefiremní) údaje daných osob. Tudíž jsou chráněny stejně, jako je tomu u záznamů v Adresáři osob - je-li připojená osoba-nezaměstnanec, pak se na ni vztahují chráněné položky třídy Osoba, je-li připojená osoba-zaměstnance, pak se na ni vztahují chráněné položky třídy Zaměstnanec (osoba).

Podrobněji k výše uvedeným třídám vč. příkladů použití viz Ochrana osob versus zaměstnanci a osoby a firmě a Ochrana údajů - Firmy a předchůdci, firmy právnické a fyzické.

Pomocné virtuální třídy PhysicalPersonFirm a EmployeePerson jsou zavedeny pouze pro účely ochrany dat různých typů záznamů v Adresářích osob resp. firem, tj. v definicích ochrany dat se nabízí, ale business objekty se k nim nevytváří. Proto je ani nenajdete v seznamu Business objektů v dokumentaci F1Doc.chm.

A dále třídy objektů související s objekty výše, jako jsou:

  • Provozovny (třída BO FirmOffice)
  • Obrázek k osobě (třída BO PersonPicture)
  • Obrázek zaměstnance (třída BO EmployeePicture)
  • Obrázek ve firmě (třída BO FirmPicture)
  • Rodinný příslušník (třída BO FamilyMember)

Které položky daných objektů konkrétně budete chránit, není věcí IS FLORES a není to nijak napevno dáno výrobcem (ani by to nebylo možné, jelikož co je a není osobní údaj, závisí na konkrétní situaci), ale závisí to čistě na vás a na tom, jaké si vytvoříte Definice ochrany dat, viz dále.

Nicméně, jak bylo řečeno výše v sekci Pojetí ochrany dat IS FLORES, lze chránit jakoukoliv položku jakékoliv třídy business objektů, vč. uživatelsky definovatelných i k objektům výše zmíněným, závisí jen na vaší licenci, viz též Co je třeba k provozu Ochrany dat v IS FLORES.

Podporu ochrany dat řeší modul Ochrana dat pro generickou ochranu dat. Zastřešuje souhrn agend a funkcí, které umožňují správci systému chránit jednotlivé položky Business objektů před neoprávněným zpracováním. Specifickou součástí modulu Ochrana dat jsou nastavení a funkce, které realizují ochranu osobních dat podle legislativy GDPR. Rozdíl mezi obecnou ochranou dat a ochranou dat dle GDPR byl popsán výše.

Agendy obecné ochrany dat:

Základní agendou ochrany dat je agenda Definice ochrany dat. Definice obsahuje výčet chráněných datových položek a výčet oprávněných uživatelů, kteří mají k uvedeným položkám přístup. Každá definice se odkazuje na ovladač (driver), který určuje, jakou technologií získají určení uživatelé přístup k vyjmenovaným položkám. Dále každá definice eviduje, zda je aktivní (bude se uplatňovat), důvod ochrany dat a v případě, že se jedná o definici s ovladačem GDPR, tak i řadu dalších údajů potřebných pro ochranu dat podle legislativy GDPR. Mezi nimi např. kategorie dat (obecná / citlivá data, zatím pouze evidenční charakter).

Ovladače jsou evidovány v číselníku Ovladače ochrany dat. Ovladač identifikuje technologii, tj. způsob, jakým se určí, zda existuje oprávněný důvod k přístupu k chráněným položkám. Ovladače představují základní stavební kámen, propojující mechanismus ochrany dat s aplikační logikou IS FLORES. Nabídka ovladačů i jejich funkcionalita je dána výrobcem. Základním ovladačem dodávaným v systému je ovladač GDPR. Ten vyhodnotí, zda pro přístup k chráněným osobním datům osoby (subjektu ochrany dat) existuje Povolení ke zpracování dat, tj. důvod v souladu s legislativou, např. udělený souhlas se zpracováním dat nebo plnění uzavřené smlouvy apod. Použití některých ovladačů není možné ovlivnit (aplikují se automaticky na pozadí, pokud nastane určitá specifická situace, k jejímuž řešení má konkrétní ovladač sloužit), jiné lze uživatelsky přiřazovat k definicím ochrany dat nebo důvodům ochrany dat (jedná se o ovladače, které mají vlastnost Nabízet k použití nastavenou na hodnotu Ano).

Průběžně aktualizovaný seznam dodávaných ovladačů se stručným vysvětlením jejich významu je uveden v samostatné kapitole Ovladače ochrany dat.

Důvody, na základě kterých se data zpracovávají resp. danou definicí chrání, se evidují v číselníku Důvody ochrany dat. V oblasti GDPR existují legislativou předepsané účely zpracování (viz např. http://www.privacy-regulation.eu/cs/6.htm) – jim odpovídající záznamy v této agendě jsou dodávány jako systémové.

Pro evidenci záznamů o prohřešcích vůči zásadám ochrany dat slouží agenda Incidenty. Záznam incidentu může být zadán uživatelem (např. na základě oznámení o ztrátě dat). Každý incident spadá do určité kategorie, která slouží k odlišení incidentu podle jeho charakteru (ztráta dat, neoprávněný přístup...). Kategorie se evidují v číselníku Kategorie incidentů. V budoucích verzích budou incidenty generovány také automaticky systémem na základě definovaných událostí (např. vypnutí ochrany dat, zadání slabého hesla). Pro automatické zjišťování prohřešků, které lze zjistit z dat, bude sloužit naplánovaná úloha Bezpečností incidenty.

Agendy ochrany dat podle GDPR:

U ochrany dat podle specifických požadavků nařízení GDPR do hry vstupují navíc povolení subjektů data zpracovávat (souhlasy se zpracováním osobních dat), které se evidují v agendě Povolení ke zpracování dat. Jednotlivá povolení obsahují odkaz na subjekt ochrany dat (osoby nebo firmy), k jehož osobním údajům se povolení vztahuje, a dále odkaz na definici ochrany dat - tím je dáno, které položky z údajů daného subjektu se daným povolením zpřístupňují a kterým uživatelům, jaký ovladač bude řídit přístup k položkám, důvod, na jehož základě se dané údaje zpracovávají aj. Dále obsahuje informaci o zdroji povolení, na základě kterého povolení vzniklo (písemný souhlas, webový formulář, automatické generování z dokladů apod.). Zdroje povolení jsou evidovány v číselníku Zdroje povolení ke zpracování dat. U každého povolení by dále mělo být uvedeno, kde je archivováno - tj. jeho umístění. Umístění jsou evidována v číselníku Umístění povolení ke zpracování dat. Slouží pak jako informativní třídící položka povolení ke zpracování dat k určení fyzického umístění dokumentu, který stvrzuje platnost onoho povolení. Může jít o umístění fyzická (budova, místnost, trezor, šanon), ale také například umístění v rámci informačního systému, určité agendy nebo diskového úložiště. To je důležité zejména u povolení, která se týkají zejména zpracování z titulu ustanovení článku 6 - 1a a článku 9 - 2a.

Aby systém ochrany dat dle GDPR fungoval, je zapotřebí k pořizovaným datům potřebná povolení ke zpracování dat doplňovat průběžně a existující povolení aktualizovat (např. upravit platnost na základě nově vzniklého dokladu, změny data ukončení smlouvy apod.). Aby nebylo nutné každé jednotlivé povolení vytvářet resp. aktualizovat ručně (ručním zadáním resp. opravou povolení), což by ani v praxi v tom množství dat nebylo možné, je k dispozici agenda Pravidla ochrany dat, kde si lze definovat pravidla pro automatické vytváření resp. aktualizaci povolení (ať už na základě existujících dokladů či jiných skutečností). Podle těchto pravidel se pak aktualizace seznamu povolení provádí (na základě určité akce, což může být např. zadání nové osoby, vyvolání funkce na generování povolení dle pravidel, využitím naplánovaných úloh apod.).

Máme zaměstnance s neukončeným pracovním poměrem. Ze zákona tedy máme nárok data uchovávat 30 let. Lze tedy říci, že mohu mít automat, který nejenom že povolení (souhlas) založí, ale bude schopen aktualizovat i jeho horní hranici platnosti.

Obdobně potřebujeme vytvářet povolení ke zpracování dat firem, od kterých dostáváme faktury, tak, aby se při vystavení nové faktury vygenerovalo povolení na subjekt z dané faktury (firmu, osobu, ...), povolující přístup na zadanou dobu (např. 10 let účetním, 2 roky obchodníkům. Obdobně i zde tedy lze mít automat, který povolení z titulu dané faktury povolení založí nebo bude schopen aktualizovat horní hranice platnosti.

Princip fungování pravidel a zásady generování resp. aktualizace povolenek podle pravidel viz podrobněji dále Vytváření povolení podle pravidel.

Dále ke k dispozici agenda Požadavky GDPR, která soustřeďuje požadavky subjektů ochrany dat (firem nebo osob) na zpracování dat podle legislativy GDPR. Požadavky jsou běžnou dokladovou agendou, kde požadavek je zařazený v řadě dokladů a v jejím rámci je číslovaný, eviduje své datum vzniku, řešitele, stav řešení a kategorii. Kategorie se evidují v číselníku Kategorie požadavků GDPR. Kategorie umožňují odlišovat požadavky podle jejich charakteru (Oprava= uplatnění práva na opravu osobních údajů, Výmaz = uplatnění práva na výmaz osobních údajů, Námitka = uplatnění práva vznést námitku proti zpracování osobních údajů, Přenositelnost = uplatnění práva na přenositelnost osobních údajů).

Schéma modulu:

Schéma modulu Ochrana dat

Obsah položky je uživateli k dispozici pro zpracování (čtení a/nebo zápis), pokud je splněna jedna z následujících podmínek:

  • položka není uvedena mezi chráněnými položkami v žádné definici ochrany

    Výjimkou je ochrana údajů zaměstnanců prostřednictvím práva Vidět osobní údaje zaměstnanců - přestože příslušné položky (vybrané údaje ze záznamu zaměstnance, případně z připojené adresy) nejsou explicitně obsaženy v rámci žádné definice ochrany, v případě neudělení práva jejich obsah není přístupný, pokud jej nějaký jiný ovladač ochrany dat prostřednictvím svých mechanismů dotyčnému uživateli nezpřístupní. Více v popisu práva Vidět osobní údaje zaměstnanců.

  • nebo je položka uvedena mezi chráněnými položkami alespoň v jedné aktivní definici ochrany dat a přitom zároveň:

    • alespoň v jedné z těchto aktivních definic s chráněnou položkou je uveden uživatel v seznamu oprávnění

    • alespoň pro jednu aktivní definici s chráněnou položkou a uživatelem v seznamu oprávnění vyhodnotí ovladač ochrany dat uvedený v definici, že tuto položku lze zpracovávat - např. pro definici s ovladačem GDPR lze položku zpracovávat, pokud je v záznamu spojená se subjektem (osobou/firmou), pro který existuje platné povolení ke zpracování dat vázané na uvedenou definici

Uživatelé, kteří nesplňují uvedené podmínky pro oprávnění ke zpracování chráněné položky, mají obsah chráněné položky skrytý zástupnými znaky. Pokud tedy tito uživatelé vidí u chráněné položky pouze zástupné znaky, platí, že nesmějí data zpracovávat.

V agendě Uživatelé existuje speciální oprávnění Obejít ochranu dat, které umožňuje ve zcela výjimečných případech tento princip částečně porušit. Viz též Možnosti zapnutí/vypnutí ochrany dat, obejití ochrany dat.

Podle legislativy GDPR se obsah chráněných položek, ke kterému již neexistuje povolení ke zpracování, musí vymazat – pozor, nemusí jít o výmaz celého záznamu, např. osoby, ale jen o nahrazení chráněného údaje (např. rodného čísla) zástupnými znaky. Vymazání se provádí hromadně na pokyn obsluhy nebo naplánovanou úlohou.

Kdy se ochrana dat začne projevovat

Samotná instalace verze systému IS FLORES obsahující podporu pro ochranu dat nezpůsobí sama o sobě žádné změny v chování aplikace. Instalace nové verze, případně update ze starší verze bez podpory ochrany dat, se tedy není nutné obávat, ochrana data sama od sebe se nezapne.

Ochrana dat (nedostupnost položek) se v systému začne projevovat teprve poté, co vytvoříte Definice ochrany dat a označíte je jako aktivní. Od této chvíle začne být přístup k datovým položkám obsaženým v definici řízen ovladači ochrany dat, na které se odkazují dané definice, a část dat může přestat být pro některé nebo všechny uživatele dostupná, pokud nesplňují podmínky nezbytné k povolení přístupu (zpravidla nemají oprávnění k související definici ochrany dat, případně k definici ochrany dat neexistuje potřebné platné povolení ke zpracování dat). Pokud bude ochrana dat nastavena a zapnuta, pak ovladače ochrany dat zadané v definicích začnou pro přihlášeného uživatele vyhodnocovat, zda mu má obsah položky daného záznamu být dostupný. Pokud vyhodnotí, že nikoliv, budou údaje v daných položkách nedostupné.

Jak a kde se nedostupnost dat projeví

Nedostupnost dat (způsobená nastavenou ochranou) se může projevovat dvěma základními způsoby:

  • přímo v aplikaci (formuláře včetně definovaných panelů apod, tiskové sestavy, exporty...) se přihlášenému uživateli místo obsahu položek zobrazují zástupné znaky (*****)

  • při pokusu o přístup k datům, ke kterým uživatel nemá přístup prostřednictvím skriptingu, OLE, Web API a podobně se nezobrazují zástupné znaky, ale je vyvolána výjimka

  • případně v některých případech při přebírání obsahu chráněné položky daná položka zůstane prázdná. Např. při kopírování záznamu a jeho chráněných údajů, příp. i jinde (např. při přebírání údajů firny do adresátů kampaní, kdy je např. položka e-mail řetězcovou položkou, tudíž se nevyplní *****) apod.

Ochrana obsahu položky by se měla projevit všude, kde uživatel k datům přistupuje, tedy nejen při zobrazování na vstupních formulářích (ať už pevných, definovatelných či variabilních), ale i v def. panelech, tiskových sestavách, exportech, při přístupu k datům prostřednictvím skriptování, Web API, OLE atd.

Příklad, jak se projeví ochrana dat vizuálně v agendě.

Ochrana dat se neprojevuje pouze vizuálním skrytím položky zástupnými znaky, ale položka je nedostupná k použití. To se může projevit různě v různých částech systému - např.:

  • při editaci záznamu - nemá-li uživatel k dané položce daného subjektu přístup, tak ji nemůže ani měnit

    Příklad, jak se projeví ochrana dat při editaci záznamu, pokud uživatel nemá k položkám daného záznamu přístup

  • ochrana dat funguje i při zadávání nového záznamu, nemá-li uživatel k dané položce přístup, tak ji nemůže ani zadávat (pro jejich zadání je třeba dočasné povolení, viz text pod obrázkem)

    Příklad, jak se může projevit ochrana dat při zadávání nového záznamu. Zde zatím není znám subjekt ochrany dat (čili nelze zatím řešit existenci povolení od daného subjektu, nicméně na pozadí se vytváří dočasné povolení pro nově zakládaný subjekt na základě pravidel typu zakládání nových osob, zaměstnanců a firem), nicméně, pokud definice ochrany dat, na níž se odkazuje dané pravidlo pro tvorbu dočasných povolení, nezpřístupňuje uživateli např. i položku Rodné číslo a tato je chráněna jinou definicí, pak ji uživatel nebude moci zadat.

  • při jiných akcích v systému. Např.:

    • uživatel nemající přístup ke všem potřebným položkám nebude moci provést výpočet mezd, nebude moci dokončit uzávěrku mezd, nebude moci doklad předkontovat, tudíž ani uložit apod.
    • neuvidí obsah nedostupných položek ani po zkopírování do/ze schránky (clipboardu) apod.
    • neuvidí obsah chráněných položek při vyhodnocování výrazů (např. při vyhodnocování proměnných kampaní) apod.
    • nedostupnost položek se projeví i při výběru subjektů v číselníkových položkách, viz interaktivní hledání v číselníkových položkách

    • nedostupnost se projeví v omezení/filtrování, pokud se jedná o výběr např. z číselníku a položka, která by měl být zobrazena, je alespoň u jednoho ze záznamů nedostupná

      Příklad, jak se projeví ochrana dat v Omezení

    • ošetřeny jsou výpočty různých QR výrazů (QR funkcí), kdy pokud uživatel nemá přístup k některým položkám, které QR výraz používá. Zde záleží na místě, kde je daný QR výraz použit. Příklady možností:

      • kritický údaj se vyhvězdičkuje.

        Např. v tisk. sestavách, je-li vybraný objekt zadán přes tečkovou notaci, tj. např. MAIN.ResidenceAddress_ID.Street a není-li dostupný, budou *****. V takovém případě se v náhledu zobrazí speciální oranžový pruh.

        Příklad, jak se může projevit ochrana dat v tisk. sestavě. Zobrazuje se oranžový pruh s informací, že byla některá data zakryta

        Výše uvedené vyhvězdičkování zatím nefunguje, je-li daná položka v definici tisk. sestavy vybrána přímo z DynSQL bez účasti Business logiky (položky tj. definované přes jednu tečku a získané prostřednictvím DynSQL přes aliasy přímo z databáze (např. MAIN.OrgIdentNumber, MAIN.Address_Street), které se do datasetu pak načítají přímo z DynSQL. Obdobně je tomu s podmínkami (podmínky výrazů, podmínky pruhů). Obdobně je tomu v exportech.
        Zatím je problém i u adres, kdy by byla položka zadána sice přes více hvězdiček, ale bez ID hlavního objektu, např. MAIN.Address_ID.Street. V tuto chvíli systém sice ví, že je ulice chráněná, ale už neví na jakém objektu je použita (nemá ID z firmy).

      • příp. se vrací výjimka, tj. uživateli se zobrazí adekvátní informace o chybě - pokud v daném místě nelze, aby QR výraz "cosi" spočítal bez použití dané položky (kde jsou hvězdičky) a uživatel se domníval, že výsledná hodnota je správná).

        Např. v tiskových sestavách se v takovém případě v náhledu zobrazí speciální červený pruh.

        Příklad, jak se může projevit ochrana dat v tisk. sestavě. V tomto případě i s červeným pruhem s informací, proč nebylo možné některé výrazy, podmínky apod. vyhodnotit

    • apod.

    Přístup k obsahu chráněných položek řeší logika jednotlivých Business objektů. Pokud byla někde místa, kde se k položkám nepřistupuje přes Business logiku, ale jiným způsobem, např. položky či výrazy, které se nevyhodnocují pomocí BO, ale přímo z databáze z dat získaných pomocí DynSQL, byla tato místa speciálně ošetřena.
    Nicméně mohou existovat místa, která nejsou (zatím) zcela ošetřena. Viz též často kladené otázky, otázka Pokrývá ochrana dat úplně všechny oblasti, kterými je potenciálně možné data získat?

 

Nejen pro účely ladění počátečního nastavení je v celé aplikaci (ve všech agendách, kde to dává věcný smysl) k dispozici záložka Ochrana dat. Pokud se přihlášenému uživateli v určité agendě na konkrétním záznamu v některých záznamech zobrazují místo některých položek zástupné znaky (*****) či něco nevidí, dle předpokladů (např. obrázky(foto)), může si na záložce Ochrana dat zkontrolovat, které definice ochrany dat přístupu ke konkrétní položce brání.

Pokud jsou v určité agendě obsaženy chráněné položky, na záložce Ochrana dat je možné zjistit důvod, jakým ovladačem jsou chráněny, na základě jakých definic ochrany dat je přístup ke konkrétní položce blokován a zda je nakonec pro přihlášeného uživatele zpřístupněn či zablokován. V popisu záložka Ochrana dat, je popsáno podrobněji a dále je zde uvedena velká řada dalších příkladů, kde je objasněno, kdy je obsah záložky Ochrana dat prázdný, kdy nikoliv a co a jak zobrazuje.

A pokud se jedná o nežádoucí stav, zjednat nápravu:

Může se stát, že se definice ochrany dat nastaví natolik restriktivně, že se zástupné znaky v určité agendě zobrazí prakticky všude a znemožní identifikaci chráněných záznamů, takže není možné určit, které záznamy jsou chráněny (všechny vypadají stejně - *****) a problematickou definici není možné dohledat a opravit. Pro podobné případy je k dispozici možnost ochranu dat vypnout nebo obejít, viz Možnosti zapnutí/vypnutí ochrany dat, obejití ochrany dat.

Řízení přístupu k položkám prostřednictvím mechanismů ochrany dat se aktivuje/deaktivuje:

  • Aktivací definic(e) ochrany dat - zatržením příznaku Aktivní u alespoň jedné definice obsahující chráněnou položku – v tuto chvíli začne být zpracování chráněných položek obsažených v definici řízeno mechanismy ochrany dat.

  • Aktivací/deaktivací ovladače ochrany dat - pokud není ovladač ochrany dat nastaven jako Aktivní, související mechanismy ochrany dat nejsou aplikovány (ovladač žádná data nechrání / neřídí k nim přístup, resp. systém IS FLORES se chová, jako by příslušný ovladač neexistoval).

    Deaktivace ovladače GDPR má na chování systému stejný dopad, jako deaktivace všech definic ochrany dat, které mají ve svých vlastnostech nastavený ovladač GDPR (pokud je neaktivní ovladač GDPR, automaticky se jako neaktivní chovají i všechny definice, tj. nijak neomezují přístup k chráněným položkám). V rámci implementace GDPR je tedy možné v případě potřeby celou ochranu dat dočasně vypnout na jediném místě - deaktivací ovladače. Dočasná deaktivace ovladače GDPR je vhodná v situacích, kdy při nastavování ochrany uděláte zásadní chybu, která uživatelům výrazně zkomplikuje nebo znemožní práci a je nutné situaci rychle vyřešit.

    Řízení přístupu k položkám prováděné ovladači ovladač BYPP a ovladač EMPD lze vypnout pouze deaktivací ovladače. Defaultně jsou aktivní. Tudíž aktivně řídí přístup k příslušným položkách, i když ochranu dat s jiným ovladačem (např. GDPR ovladačem) jste zatím nezapínali. Tudíž i v záložce Ochrana dat se může nějaká chráněná položka objevit, i když jste nic zatím nezapnuli.

    V běžném provozu není vhodné kombinovat ovladač GDPR s dalšími ovladači. Pokud například aktivujete ovladač GDPR, nastavíte ochranu určitých položek a nedeaktivujete ovladač EMPD, uživatelé s privilegiem Supervisor díky ovladači EMPD získají právo Vidět osobní údaje zaměstnanců. bez ohledu na nastavení ochrany příslušných položek v rámci definic ochrany dat využívajících ovladač GDPR. Podrobnější informace viz upozornění k souběžnému používání více ovladačů v kapitole Ovladače ochrany dat.

Obejít řízení přístupu k chráněným položkám lze provést:

  • Využitím uživatele s nastavením Obejít ochranu dat - uživatel s tímto nastavením má vždy přístup k určité omezené množině chráněných položek (bez ohledu na to, zda je mezi oprávněnými uživateli, resp. bez ohledu na existenci platného povolení. Podrobnější informace viz Dodávané ovladače ochrany dat (k řešení popsané situace systém využívá speciální ovladač BYPP).

    Určeno pro výjimečné případy, kdy potřebujete v dané agendě rychle vyřešit potenciální problém s nedostupností dat způsobený například chybným nastavením ochrany - např. dohledat záznam se všemi údaji překrytými zástupnými znaky (*****), ale nechcete ochranu dat vypínat, s tím, že nápravě situace (úpravě definic, doplnění povolení) se budete věnovat později.

Jak bylo řečeno již výše v popisu agend ochrany dat, definice ochrany dat jsou stěžejní agendou nutnou pro ochranu dat. Určují mj. seznam chráněných položek, oprávněných uživatelů, metodu ochrany (ovladač), důvod, proč se dané položky pro daný subjekt evidují aj. Váží se na ně povolení ke zpracování dat a pravidla, podle kterých lze povolení generovat.

Pro práci s definicemi mj. platí:

  • Nabízené položky:

    • Které třídy objektů se nabízejí k nastavení ochrany v rámci definice, je dáno licencí. Viz též Co je třeba k provozu Ochrany dat v IS FLORES k ochraně dat a Základní chráněné objekty z titulu GDPR. Nenabízejí se třídy objektů z agend Ochrany dat/GDPR.

    • V rámci dané třídy se typicky nenabízí všechny existující položky daného objektu (porovnejte např. s položkami nabízenými v rámci datového modelu daného objektu v jiných částech systému, například v editoru sloupců), ale jen vybrané (dáno výrobcem):

      • Nenabízejí se položky řádkových kolekcí.

      • Nenabízejí se položky, které výrobce z ochrany dat vyloučil.

        Typicky se jedná o položky, u nichž to není smysluplné, nebo by to mohlo vést k zacyklení, příp. jsou nějaká technická omezení:

        • Nenabízí se položky typu ID, ObjVersion, Hidden apod.
        • Obecně není podporována například ochrana položek, které podporují automatické generování kódu (např. kód skladové karty a další), položky související s jeho generováním (suffix, prefix aj.).
        • Není možné chránit příznaky Zaměstnanec (na osobě) a Právnická osoba (na firmě).

      • Pro nabízení vnořených objektů platí, že se nabízí jen 2. úroveň vnoření v rámci struktury daného Business objektu (například při definování ochrany dat položek z třídy Aktivita je možné rozbalit odkaz na navázanou firmu (přes Firm_ID) a následně nastavit jako chráněnou nějakou položku z číselníku firem, ale není možné chránit položku z objektu navázaného na navázaný objekt (např. název dealerské třídy navázané na firmu navázané na aktivitu).

        Příklad položek nabízených k třídě objektů Aktivit - v případě potřeby je možné chránit například kód pravděpodobnosti úspěchu resp. jeho vazbu na konkrétní aktivitu (srovnejte s datovým modelem Aktivity nabízeným jinde).

        Pro navázané číselníky (nevlastněné objekty) platí, že pokud se ochrana jejich položek nastaví uvedeným způsobem, jsou položky chráněny pouze v kontextu dané vazby. Vysvětlíme na příkladu.

        Mějme číselník obecných pracovních pozic, jehož položky samy o sobě nechceme a nepotřebujeme chránit (obsah číselníku bude volně přístupný). Chceme ovšem chránit přiřazení konkrétních pracovních pozic ke konkrétním osobám, neboť teprve tímto přiřazením se z nich potenciálně stávají osobní údaje.

        Abychom toho dosáhli, vytvoříme si definici ochrany dat a mezi chráněné položky přidáme z třídy Osoba ve firmě položky z navázaného číselníku, viz přiložený obrázek. Tímto způsobem zajistíme ochranu informací o pracovních pozicích pouze ve vztahu ke konkrétním Osobám ve firmě.

        Nastavení ochrany přiřazení pracovních pozic k osobám.

  • Zahrnutí konkrétního uživatele do seznamu uživatelů, kteří mají přístup k položkám chráněným danou definicí, je pro zpřístupnění obsahu chráněných položek podmínkou nutnou, nikoli však postačující. Je-li určitá položka obsažená v definici (tj. je chráněná), uživatel není uveden v seznamu oprávněných uživatelů (a není uveden v seznamu oprávněných uživatelů ani v žádné jiné definici, která obsahuje danou položku), k obsahu položky přístup nemá. Pokud je uživatel uveden mezi oprávněnými uživateli, o udělení přístupu rozhoduje ovladač ochrany dat přiřazený k dané definici (v případě ovladače GDPR ovladač kontroluje, zda k definici existuje platné povolení ke zpracování dat).
  • Pro jednoho uživatele je možné vytvořit libovolné množství definic ochrany dat s různě definovanými skupinami chráněných položek. Na tyto definice mohou být navázána povolení ke zpracování dat s různou platností, například pro různé fáze cyklu obchodního případu (předprodejní jednání, vlastní prodej, záruční doba).

  • Které položky jsou chráněny, určuje sjednocení množin položek aktivních definic. Položka se chová jako chráněná, pokud je obsažena v alespoň jedné aktivní definici.

Pro účely ladění zejména u počátečního nastavení je v celé aplikaci (ve všech agendách, kde to dává věcný smysl) k dispozici záložka Ochrana dat, kde lze zkontrolovat, které definice ochrany dat přístupu ke konkrétní položce brání, a pokud se jedná o nežádoucí stav, zjednat nápravu.

Přehled chráněných položek vč. informace, ve které definici se vyskytuje a kteří uživatelé k ní mají přístup, a přehled uživatelů uvedených v definicích vč. informace, ve které definici je zapsán a ke kterým položkám má přístup, získáte v rámci dodávaných tiskových sestav v agendě definic ochrany dat.

Je možné, že se množina chránitelných položek jednotlivých tříd objektů může v čase změnit. Pro kontrolu a aktualizaci je k dispozici funkce Kontrola definic. Viz též Příklady procesů - Aktualizace definic po update, smazání definice, obnova ze skrytých.

Jak bylo řečeno již výše v popisu agend ochrany dat, aby systém ochrany dat dle GDPR fungoval, je zapotřebí k pořizovaným datům potřebná povolení ke zpracování dat doplňovat průběžně a existující povolení aktualizovat (např. upravit platnost na základě nově vzniklého dokladu, změny data ukončení smlouvy apod.). Aby nebylo nutné každé jednotlivé povolení vytvářet resp. aktualizovat ručně, lze si v agendě Pravidla ochrany dat definovat pravidla pro automatické vytváření resp. aktualizaci povolení (ať už na základě existujících dokladů či jiných skutečností). Každé pravidlo je určitého typu, který ovlivňuje kdy a jak se aplikuje, má ve svých údajích mj. zadán povinný odkaz na Definici ochrany dat (k ní se pak bude vztahovat vygenerované povolení, které bude ovlivňovat dostupnost položek chráněných danou definici oprávněným uživatelům z dané definice) a dále platnost, která bude ovlivňovat, jak dlouho má být vytvořené povolení platné (odkdy se platnost vyčísluje, závisí na tom, o jaké pravidlo se jedná a co je podkladem pro generování povolení (např. u dokladů to může být datum vzniku daného dokladu)).

Dále je uvedeno:

Je možné vytvářet pravidla několika typů (typ pravidla definuje, kdy se pravidlo uplatňuje, tj. k čemu se pravidlo bude používat, na základě čeho se spustí a vzniknou příslušná povolení):

Jedná se o následující typy pravidel: Generování

Pravidla tohoto typu slouží pro generování povolení ke zpracování dat z vybraných agend. V údajích každého pravidla se určuje mj. oblast, která pro dané pravidlo určuje, která agenda bude pokladem pro generování. Podkladem mohou být prodejní doklady (např. faktury vydané, pokladní příjemky), nákupní doklady (např. faktury přijaté), účtenky maloobchodního prodeje, dále to mohou být aktivity (typicky aktivity týkající se nějakého obchodního vztahu, což lze odlišit např. řadou aktivit), dále platné pracovní poměry se zaměstnanci a smlouvy.

Potřebujeme vytvářet povolení ke zpracování dat firem, od kterých dostáváme faktury přijaté. Vytvoříme si pravidlo typu Generování, jako Oblast zvolíme Nákup / Faktury přijaté. Součástí definice pravidla je také odkaz na určitou definici ochrany dat, která určuje, ke kterým chráněným položkám získají oprávnění uživatelé z dané definice na základě vygenerovaných povolení přístup. Podle daného pravidla se povolení z faktur budou generovat (ručně na pokyn uživatele nebo naplánovanou úlohou např. jednou denně, viz dále Generování/aktualizace povolení podle pravidel.

Pravidel pro jednu oblast můžete mít více a v praxi tomu tak bude. Typickým příkladem jsou doklady, o nichž se účtuje.

Ze zákona je třeba uchovávat účetní doklady po zákonnou lhůtu 10-ti let, tudíž existuje oprávněný důvod zpracovávat údaje subjektu ochrany dat do danou dobu (i kdyby s tím daný subjekt sám o sobě nesouhlasil). Ale týká se to samozřejmě jen těch uživatelů, u nichž lze zdůvodnit, že mají mít možnost k účetním dokladům přistupovat - čili např. pracovníci účtárny, obchodní ředitel, a pouze údajů, které musí být povinně na daném účetním dokladu. Vedle toho jsou např. obchodníci, u nichž lze rovněž zdůvodnit, že mají oprávněný zájem přistupovat k datům subjektu z daného dokladu, takových položek bude bezpochyby více (např. i e-mail), ale bude to zase po kratší dobu (kterou dokážete zdůvodnit). Pak budete mít pro každou oblast dokladů, o nichž se účtuje, minimálně dvě pravidla - jedno navázané na definici ochrany dat určenou pro účtárnu a druhé na definici určenou pro obchodníky. Viz též příklady procesů - např. Nastavování řízeného přístupu k položkám z titulu dokladů.

Většina pravidel typu Generování (kromě oblasti Zaměstnanci) má dále možnost zadat doplňující Parametry.

Zde lze mj. specifikovat řadu dokladů, z jaké se mají povolení generovat. To umožňuje si např. pro jednu řadu dokladů nastavit pravidlo jiné než pro jinou řadu dokladů (např. s vazbou na jinou definici dat obsahující jiné chráněné položky a jiný okruh oprávněných uživatelů, ale může to být i na stejnou definici ale s jinou platností apod.).

Pro některé typy úloh je nutností definovat pravidla až ke konkrétním řadám dokladů. Viz též příklady procesů - např. Nastavování řízeného přístupu k položkám z titulu smluv.

Kromě řad lze v parametrech některých pravidel některých oblastí ještě nastavit, pro jaký subjekt se dle daného pravidla budou povolení generovat, u některých pravidel je to dáno rovnou oblastí daného pravidla:

U pravidel pro oblast Zaměstnanci se subjekt uživatelsky nenastavuje, povolení se generuje z agend modulu Mzdy a personalistika, tudíž se může vygenerovat jen pro osoby-zaměstnance (mají zatržený příznak Zaměstnanec/Pracovník), ale jen ty, kteří jsou současně evidovány v modulu Mzdy a personalistika.

Aplikují se při založení nových záznamů. Jedná se o pravidla typu Nová firma, Nová firma (fyzická osoba), Nová osoba, Nový zaměstnanec (osoba) - typicky se používají pro generování jakýchsi dočasných povolení, aby údaje, které mají být chráněny, nebyly znepřístupněny bezprostředně po založení záznamu do adresáře a bylo možné pro ně vygenerovat dlouhodobější povolení.

Jedná se o následující typy pravidel:

V případě existence pravidla tohoto typu se systém zachová následovně: bezprostředně po založení příslušného záznamu, např. firmy- právnické osoby v Číselníku firem, obdrží subsystém Ochrana dat signál, že záznam vznikl - v tomto případě firma. Signál je delegován na ovladače ochrany dat a příslušný ovladač založí automaticky ihned potřebné dočasné povolení podle nastavení pravidel ochrany dat typu "Nová firma".

Takovému povolení můžeme říkat "dočasné povolení" proto, že by nemělo být na dlouho dobu, ale mělo by platit je dočasně, např, jen na 2-3 měsíce, po které budete schopni odůvodnit, že údaje daného subjektu zpracováváte, i když k tomu zatím nemáte žádný jiný právní důvod (zatím např. ještě nedošlo k uzavření smlouvy s danou firmou či nevznikl jiný obchodní vztah). Samozřejmě počet měsíců, po které takové povolení bude platit, si uživatel může nastavit sám v příslušném pravidle daného typu.

Na tato pravidla nezapomeňte v rámci implementace ochrany dat.

Nezapomeňte se seznámit s informacemi uvedenými dále v sekci Ochrana - osoby versus zaměstnanci.

Jedná se o speciální případ. Slouží pro případ potřeby hromadného vygenerování povolení k vybraným firmám bez požadavku na existenci záznamů z jiných agend. Tj. v podstatě "obejde" mechanismy automatického generování povolení vyžadující nějaký relevantní podklad splňující podmínky (doklad, smlouva, aktivita, prac. poměr aj.) v nějaké agendě IS FLORES a povolení na vybrané firmy resp. osoby vygeneruje vždy. Povolení Nemělo by se ale nemělo generovat "jen tak". Tato možnost je zde hlavně jako pojistka pro případ, že uživatel příslušné podklady má, pouze z nějakého důvodu nemůže automatické generování z dokladů použít (např. má příslušné doklady evidované mimo IS FLORES).

Z toho důvodu se aplikuje se pouze v případě ručního vyvolání z adresářů:

Nelze jej spouštět z agendy pravidel v rámci automatického generování povolení (funkce Generovat) ani naplánovanou úlohou. Viz Možnosti, jak vyvolat vytváření/aktualizaci povolení podle pravidel.

Oprávněnost použití je na uživateli! Takto vygenerovaná povolení by si měl umět vždy zdůvodnit.

Pro výpočet platnosti povolení ke zpracování dat platí následující postup:

Je-li vyvoláno vytváření povolení (ať už spuštěním funkce či nějakou jinou akcí), projdou se příslušná pravidla, kterých se daná akce týká (podle toho, jak a na základě čeho bylo vytváření pravidel vyvoláno). Pravidlo se zpracuje a vytvoří se povolení pro příslušné subjekty (firmy/osoby dle nastavení pravidel) ze zdrojových záznamů (které to budou, je dáno typem pravidla resp. jeho oblastí), přičemž platnost povolení se odvodí z rozhodného data z daného zdrojového záznamu a požadované délky platnosti povolení zadané v údajích pravidla. Vygenerované povolení si pamatuje, na základě jakého pravidla bylo vytvořeno. Toho se využívá pro posouzení, zda se má vytvořit nové nebo zaktualizovat stávající.

Postup vytváření povolení si objasníme podrobněji:

  • generování automatických povolenek u povolení vzniklých na základě pravidel typu generování:

    • Generátor pracuje postupně nad všemi pravidly ochrany dat, které jsou typu Generování a nejsou skryté (skryté jsou ignorovány, povolení se podle nich nevytvářejí, ale ani neaktualizují). Postupně vezme jedno pravidlo a zabývá se jen povolenkami pro toto pravidlo. Povolenek pro jiná pravidla nebo bez pravidla si nijak nevšímá.

      Při vytváření povolení dle pravidel, se nijak nezohledňuje, zda je definice ochrany dat odkazovaná z pravidla nastavena jako Aktivní či nikoliv. Dokonce je tomu naopak, jelikož při implementaci GDPR je žádoucí, aby tomu tak nebylo, tj. aby se nejdříve vygenerovaly povolenky a teprve poté se aktivovala ochrana podle jednotlivých definic.

    • Generátor povolení si nejdříve stanoví rozhodný interval, v němž bude v minulosti hledat zdrojové záznamy (např. faktury vydané, platné prac. poměry atd.) pro generování povolení:

      "den generování minus platnost nastavená na pravidle" ⇒ interval, v němž bude hledat zdroj. záznamy

    • V tomto intervale hledá, které zdroj. záznamy do něj spadají. Získá seznam subjektů (tj. ID nejdříve firem, pak osob) z dokladů v daném intervalu. Pro jednotlivé oblasti se používá různé rozhodné datum k posouzení, zda daný záznam do daného intervalu spadá, a pro vyčíslení platnosti vygenerovaného povolení:

      • prodejní / nákupní doklady / účtenky POS:

        • dohledá doklady, jejichž datum vystavení spadá do daného intervalu

        • z daných dokladů si pro následná povolení zapamatuje ID firem nebo osob (což je dáno daným pravidlem, viz pro jaký subjekt se dle daného pravidla budou povolení generovat)

          Např. u dokladů jako jsou faktury apod. systém vrací požadované subjekty ochrany dle GDPR (což případě GDPR jsou osoby a firmy) podle položek Firm_ID a Person_ID. Pokud by řádek dokladu, který se odkazuje na hlavičku dokladu s firmou/osobou měl navíc na sobě též "svůj subjekt" ochrany dat dle GDPR, pak se volání deleguje na hlavičku, tj. vrátí se subjekt z hlavičky.

        • platnost povolení: datum vystavení dokladu / aktivity + platnosti nastavená na pravidle

      • aktivity:

      • smlouvy:

        • dohledá smlouvy, které mají nastaveno, že mohou být podkladem pro Povolit zpracování pravidlem ochrany dat a které jsou alespoň po část daného intervalu platné (posuzuje datum Platná do)
        • z daných smluv si zapamatuje ID firem resp. osob
        • platnost povolení: je-li vyplněno datum Platná do, pak Platná do + platnost nastavená na pravidle, jinak datum generování + platnost nastavená na pravidle

      • mzdy / zaměstnanci:

        • dohledá prac. poměry (PP), které jsou alespoň po část daného intervalu platné (posuzuje Výstup dne)

        • z daných prac. poměrů si zapamatuje ID osob

          Vazba zaměstnanec → osoba je jednoznačná, viz též Ochrana údajů - osob versus zaměstnanci.

        • platnost povolení: je-li vyplněno datum Výstup dne, pak Výstup dne + platnost nastavená na pravidle, jinak datum generování + platnost nastavená na pravidle

      Mějme zaměstnance Koblihu, Nového a Pěknou. Kobliha nechť má neukončený PP, Nový nechť má PP ukončený k datu 1.5.2018 a Malá má ukončený PP k datu 31.12.2015. Nechť je aktuální datum 28.10.2018 a na pravidle nechť je nastavena platnost 12 měsíců. Spustíme generování podle daného pravidla.

      Po generování bude existovat povolení:

      - pro Koblihu s platností do 28.10.2020 (datum generování 28.10.2018+24 měsíců
      - pro Nového s platností do 1.5.2020 (datum ukončení PP + 24 měsíců)
      - pro Malou povolení nevznikne (Malá má PP ukončený před intervalem, v němž se hledá (datum generování 28.10.2018 - 24 měsíců)

      Pokud se v oblasti, pro kterou je aktuální pravidlo definováno, vyskytuje větší množství záznamů týkajících se jednoho subjektu údajů (pro který se bude generovat povolení), odvodí se datum platnosti z každého záznamu a na povolení se nastaví nejvyšší z nich.

      Pokud máme nadefinované pravidlo pro generování povolení z určité řady faktur vydaných a v této řadě se nachází několik faktur navázaných na jednu konkrétní osobu, pro stanovení platnosti povolení ke zpracování dat této osoby bude rozhodující faktura s nejnovějším datem vystavení.

    • Pro jednotlivé subjekty zkontroluje, zda už existuje povolení (vytvořené daným pravidle, pro daný subjekt).

      Pokud ne, pak se vygeneruje nové a nastaví vypočtenou platnost (výpočet platnosti pro jednotlivé oblasti viz výše).

      Pokud ano, tak se zaktualizuje (mohl např. přibýt nový doklad, na jehož podkladě se platnost povolení prodlouží, nebo naopak se mohl doklad smazat, tudíž se platnost naopak zkrátí, jelikož se nově bude pro daný subjekt počítat z jiné faktury, přičemž může dojít i k situaci, že už není z jaké faktury a povolení se zneplatní (deaktivuje, viz dále), mohlo se změnit i pravidlo samotné, např. požadovaná platnost či parametry pravidla).

      Přitom platí:

      • Libovolná změna v nastavení pravidla nebo ve zdrojových datech (např. smazání FV; změna firmy/osoby na FV) vede při novém generování ke konzistenci v povolenkách příslušejících tomuto pravidlu.

        Mějme pravidlo na generování povolení pro osoby z oblasti faktur s platností 24 měsíců. Mějme povolení vytvořené na osobu Nováka na základě faktury FV-100 vystavené před 19 měsíci, tudíž povolení je platné ještě pro následující 5 měsíců. Opravíme pravidlo a zkrátíme platnost na 20 měsíců. Po novém generování se povolení zaktualizuje a platnost bude už "jen" jeden následující měsíc.

      • V rámci procesu vytváření povolení podle pravidel se žádná existující povolení nemažou. Pokud je potřeba povolenku smazat (algoritmus zjistí, že tam povolenka nemá být), jelikož v aktuálních datech již není důvod k existenci nějakého dříve vytvořeného povolení, provede zneplatnění/deaktivaci povolení (nastavením Platnosti do na "včera).

        Mějme pravidlo na generování povolení pro osoby z oblasti faktur s platností 24 měsíců. Mějme povolení vytvořené na osobu Nováka na základě faktury FV-100 vystavené před 19 měsíci, tudíž povolení je platné ještě pro následující 5 měsíců. Opravíme pravidlo a zkrátíme platnost na 12 měsíců. Pak zdrojová faktura vypadne z rozhodného intervalu a už by nadále nebyl důvod k existenci daného povolení. Povolení pro subjekt Nováka vytvořené podle tohoto pravidla se nesmaže, ale deaktivuje se nastavením platnosti "na včera".

      • Na povolení si nevšímá hodnot Platnost pozastavena – ta na algoritmus nemá vliv.
      • Všude se počítá jen s datem bez času
      • Pokud by vyšlo, že Platnost od je v budoucnosti (např. faktura vydaná s datem vystavení "pozítří"), použije se datum "dnes".

      • Je-li subjektem "firma", znamená to "všechny verze" jedné firmy, tj. zohledňuje existenci předchůdců dané firmy.

        Mějme firmu AAA1. Vystavíme FV-1 na firmu AAA1. Pak ji zásadně opravíme na firmu AAA2 a vystavíme na ni fakturu FV-2. Pak firmu zásadně opravíme na AAA3. Generujeme povolení podle pravidla s oblastí pro tyto faktury. V daném intervalu dohledá všechny faktury vystavené na firmu AAA3 nebo na její předchůdce, tj. firmu AAA2 a AAA1. Nechť FV-1 i FV-2 do rozhodného intervalu spadají. Generátor použije fakturu FV-2 (nejnovější z faktur dohledaných pro firmu AAA3 a její předchůdce) a pro subjekt AAA3 (aktuální firma, následník firmy AAA2 z FV-2) vytvoří povolení s platností vypočtenou na základě faktury FV-2.

      • Pokud by vyšlo, že Platnost od je v budoucnosti (např. faktura vydaná s datem vystavení "pozítří"), použije se datum "dnes".

      • Do povolení se zapíše odkaz na zdrojový záznam, na jehož základě povolenka vznikla resp. byla aktualizovaná (např. fakturu vydanou, zaměstnance) a do Poznámky k povolení se zapíše, na základě jakého zdrojového záznamu se povolení vytvořilo, jakým pravidlem a podle jaké definice a kdy naposledy proběhla aktualizace.

    • Má-li subjekt firma/ osoba ve svých údajích nastaven příznak Omezení zpracování, je vyloučen z generování/aktualizace pravidel.

    • Po zpracování všech subjektů, které pravidlo určilo, se generátor podívá, která povolení jsou tam "navíc". U nich rovněž provede zneplatnění/deaktivaci tím, že jim nastaví Platnost do = "včera", jelikož jak již bylo řečeno výše, v rámci procesu vytváření povolení podle pravidel se žádná existující povolení nemažou.

      Mějme povolení na firmu AAA3 z předchozího příkladu (tj. firma následník, mající dva předchůdce, firmu AAA1, na níž existuje FV-1 a firmu AAA2, na níž existuje faktura FV-2). Faktury FV-1 a FV-2 vymažeme. Po vyvolání generování podle pravidel pro oblast faktur se již z daných faktur nedohledá žádná pro subjekt AAA3 či její předchůdce, dané povolení pro firmu AAA3 je tam tedy navíc, již není oprávněné. Tudíž povolení pro firmu AAA3 "zneplatní" tím, že na něm nastaví platnost do "včera".

      Obdobně mějme pravidlo na generování z oblasti smluv z řady obchodních smluv OS povolení vygenerované z takové smlouvy OS1 s platností do 31.12.2025. Opravíme pravidlo a měníme řadu na SML. Pak se při příštím generování se zjistí, že toto pravidlo je navíc, jelikož bylo vytvořeno na základě smlouvy z jiné řady, než která je aktuálně v pravidle nastavena, a toto povolení deaktivuje nastavením platnosti "na včera",

  • u povolení vzniklých na základě pravidel typu hromadné ruční generování

    Zde je situace jednoduchá:  spouštěcí akcí pouze vyvolání příslušné funkce v Adresáři (viz jak a na základě čeho bylo vytváření pravidel vyvoláno) a povolenky se nevytváří z dokladů, ale rovnou k vybraným firmám/osobám (viz popis pravidel pro hromadné ruční generování).

    • platnost povolení: datum generování povolení + platnost nastavená na pravidle v měsících

    Zde platí:

    • je-li subjektem "firma", zde to NEZNAMENÁ "všechny verze" jedné firmy, ale zpracuje POUZE aktuální firmu, tj. zde nezohledňuje existenci předchůdců dané firmy.

    • Mějme firmu AAA1. Vystavíme FV-1 na firmu AAA1. Pak ji zásadně opravíme na firmu AAA2 a vystavíme na ni fakturu FV-2. Pak firmu zásadně opravíme na AAA3. Z adresáře pro tuto firmu AAA3 spustíme generování povolení hromadně ručně. Pro subjekt AAA3 se vytvoří povolení. Fakt, že firma AAA3 má nějaké předchůdce se nijak nezohledňuje, pro předchůdce se touto akcí povolení netvoří.

      Srovnejte s příkladem výše, kde se povolení generovala z dokladů a kde se existence předchůdců zohledňovala.

  • u povolení vzniklých na základě pravidel typu zakládání nových osob, zaměstnanců a firem

    Zde je situace jednoduchá:  spouštěcí akcí je pouze založení nové firmy/osoby resp. případně osamostatnění předchůdců (viz jak a na základě čeho bylo vytváření pravidel vyvoláno) a povolenky se nevytváří z dokladů, ale rovnou k pro danou jednu firmu resp. osobu

    • platnost povolení: aktuální datum (datum zadání nového záznamu) + platnost nastavená na pravidle v měsících

Může se stát, že povolení vytvářené dle postupu výše nevznikne. To může být dáno různými příčinami, např.:

Mějme pravidlo pro oblast Nákup/Faktury přijaté s platností 2 roky s nastavením generovat pro firmy i pro osoby. Na firmu Janáček mějme fakturu přijatou vystavenou před 5-ti lety, žádnou čerstvější. Spustíme generování povolení dle daného pravidla. Pro firmu Janáček žádní pravidlo nevznikne.

Pro mazání povolení platí:

  • jak bylo řečeno výše v popisu vytváření povolení podle pravidel, v rámci procesu vytváření povolení podle pravidel se žádná existující povolení nemažou (tj. pokud zanikl důvod k existenci povolení (např. je smazán zdrojový doklad), tak se povolení nevymaže, ale zneplatní se
  • je-li vymazán (bez možnosti obnovení, tedy nikoli pouze skryt) chráněný subjekt (firma/osoba), pak se spolu s ním vymažou i všechna k němu existující povolení vytvořená podle pravidel (neplatí pro případná ručně zadaná povolení na daný subjekt, ta si musí uživatel nejdříve vymazat sám)

Mějme nastaveno pravidlo typu Nová osoba na automatické vytvoření povolení p založení nové osoby. Založme novou osobu. Tudíž vzniklo povolení typu "Nová osoba". Pak vystavme na danou osobu nějaký doklad (např. aktivitu obchodního typu). Po spuštění pravidel po oblast CRM vznikne druhé povolení pro danou osobu na základě dané Aktivity.

Poté Aktivitu smažme (tudíž zanikl důvod pro existenci povolení z aktivit). Při opětovném generování povolení dle pravidel se toto nevymaže, pouze zneplatní.

Poté vymažme i osobu bez možnosti obnovení. V tuto chvíli se spolu s ní vymažou i obě povolení na ni vytvořená. (Je tomu tak proto, aby bylo možné firmu/osobu vymazat).

Jelikož tato oblast je celkem složitá na pochopení, vypíchneme ji samostatně. Pro správné pochopení a implementaci ochrany dat dle GDPR pro osoby versus zaměstnance je třeba vzít v potaz fakta, která vypíchneme v následujícím textu:

  • každý zaměstnanec evidovaný v personalistice v agendě Zaměstnanci má současně záznam odpovídající osoby v agendě Číselník osob. (Takovou osobu pak z Číselníku osob nelze opravovat, mazat a skrývat, skrytí zaměstnance způsobí i skrytí dané osoby apod.)
  • každá osoba v Číselníku osob má zatržítko Zaměstnanec/pracovník
  • zatržítko je zatrženo automaticky u všech zaměstnanců evidovaných v personalistice, ale může být zatrženo (uživatelem) i u jiných osob, které evidovány v personalistice nejsou, přičemž i s takovými by mělo být nakládáno s vyšší opatrností, než u běžných osob
  • některé údaje osoby-zaměstnance evidovaného v personalistice jsou dostupné jen v Číselníku osob (např. Jméno FirstName, Příjmení LastName), některé jen v personalistice, některé na obou místech

Z toho plyne:

  • je třeba rozlišovat ochranu dat osob-zaměstnanců (se zatrženým Zaměstnanec/pracovník) a osob-nezaměstnanců a údajů zobrazovaných v Číselníku osob a v personalistice. Proto je v záložce Chráněné položky možno nastavit ochrany položek pro tyto třídy objektů resp. pomocné virtuální třídy (jejich popis viz výše):

Tudíž, pokud je třeba chránit např. datum narození osoby, musí existovat definice, které chrání současně položku datum narození osob-nezaměstnanců (třída Osoba), současně datum narození osob-zaměstnanců (třída Zaměstnanec (osoba)) a pokud se jedná o osoby-zamětsnance evidované také v personalistice (třída Zaměstnanec), pak i datum narození daného zaměstnance v personalistice. Objasníme na příkladu:

Nechť je třeba chránit např. datum narození osoby (jak pro nezaměstnance, tak pro zaměstnance, a to jak v adresáři osob tak v personalistice). Pak je potřeba mít mezi chráněnými položkami všechny tyto položky pro všechny tři objekty Osoba, Zaměstnanec (osoba) a Zaměstnanec (v praxi to pravděpodobně nebudou všechny tři v jedné definici, ale budou v rámci různých definic):

Pak pokud bude některá z definic chránící tyto položky aktivní a uživatel nebude mezi oprávněnými uživateli aspoň jedné z definic, které některou z těchto položek chrání anebo pokud nebude existovat platné povolení od daného subjektu (fyzické osoby) navázané na příslušnou definici, tak přihlášený uživatel Datum narození neuvidí (uvidí *****):

Znepřístupněný údaj "Datum narození" osoby - nezaměstnance v adresáři osob

Znepřístupněný údaj "Datum narození" osoby - zaměstnance v adresáři osob (bez ohledu na to, zda je tato osoba současně evidována v personalistice)

Znepřístupněný údaj "Datum narození" osoby - zaměstnance v personalistice

Nezapomeňte, že do hry ještě může vstupovat ovladač EMPD. Po zapnutí ochrany dat by měl být deaktivován, nicméně, pokud jej deaktivován nemáte a pokud přihlášený uživatel nevidí v údajích osob ***** dle očekávání a dle textu výše (za splnění podmínek výše uvedených) a datum narození vidí, je to dáno zmíněným ovladačem. Ovladač po aktivaci definic ochrany dat dle doporučení vypněte, jinak vás bude zbytečně mást.

Jak bylo řečeno, v praxi nebudou pravděpodobně všechny tři položky v rámci jedné definice, ale budou roztroušeny u různých definic. Pak např. definice pro ochranu údajů zaměstnanců by je měla obsahovat takto, aby bylo chráněno datum narození daného zaměstnance jak v agendách personalistiky, tak v ostatních agendách:

Dále, pokud je třeba chránit např. telefony a e-mail osob zobrazované v Číselníku osob u osob připojených k firmám, musí existovat definice, které chrání současně položky firemní telefon a e-mail osob připojených k firmě (třída Osoba na firmě), současně soukromé telefony a mail osob, přičemž, jak bylo objasněno výše, zvlášť je třeba toto nastavit u osob-nezaměstnanců (třída Osoba) a osob-zaměstnanců (třída Zaměstnanec (osoba)). Objasníme na příkladu:

Nechť chceme chránit všechny telefony a e-maily osob připojených k firmě a zobrazovaných u dané firmy. V Číselníku firem na subzáložce sooby se jednak v seznamu připojených zobrazují "firemní údaje" (viz firemní telefon, firemní e-mail) a jednak se ke každé osobě ve spodní části záložky zobrazují osobní údaje dané osoby.

Mějme např. v Číselníku firem u firmy ABC připojenou osoby Blok a Bláha. V horní části záložky Osoby zobrazují "firemní údaje" (viz firemní telefon, firemní e-mail, tj. telefon a mail na osoby Blok resp. Bláha do dané firmy) a jednak ve spodní části jejich Osobní údaje (pohled do Adresáře osob na osobní telefon a mail dané osoby):

Firemní kontaktní údaje vyznačeny červeně, osobní kontaktní údaje z Číselníku osob vyznačeny zeleně

Pokud chceme chránit firemní telefon a mail, musí definice obsahovat nastavení ochrany pro objekt Osoba ve firmě nísledovně: 

Nastavená ochrana "firemních" kontaktů na danou osobu.

Pak pokud bude taková definice aktivní a uživatel nebude mezi oprávněnými uživateli aspoň jedné z definic, které některou z těchto položek chrání anebo pokud nebude existovat platné povolení od daného subjektu (fyzické osoby) navázané na příslušnou definici, tak přihlášený uživatel firemní telefon a mail osob připojených k firmám neuvidí (uvidí *****):

Nastavená ochrana "firemních" kontaktů na danou osobu.

Aby byly chráněny (znepřístupněny) i zobrazené "osobní" údaje osob připojených k firmě, je třeba chránit příslušné položky objektů Osoba resp. Zaměstnanec (osoba), jak bylo řečeno výše v příkladu ochrany osob versus zaměstnanců, aby byly znepřístupněny osobní údaje připojených osob ať už mají zatrženo, že jsou Zaměstnanec/pracovník, nebo ne). Pokud tedy chceme mít chráně telefony mail (firemní i osobní) zobrazený u připojených osob, pak je potřeba mít mezi chráněnými položkami všechny tyto položky (v praxi to pravděpodobně nebudou všechny tři v jedné definici, ale budou v rámci různých definic):

Pak pokud bude taková definice aktivní a uživatel nebude mezi oprávněnými uživateli aspoň jedné z definic, které některou z těchto položek chrání anebo pokud nebude existovat platné povolení od daného subjektu (fyzické osoby) navázané na příslušnou definici, tak přihlášený uživatel firemní telefon a mail osob připojených k firmám neuvidí (uvidí *****):

Znepřístupněný firemní telefony a mail (červeně) a osobní telefony a mail (zeleně) zobrazované u osoby připojené k firmě

Nezapomeňte, že do hry ještě může vstupovat ovladač EMPD a může ovlivňovat zobrazování údajů osob - zaměstnanců. Po zapnutí ochrany dat by měl být deaktivován, nicméně, pokud jej deaktivován nemáte a pokud přihlášený uživatel nevidí v údajích osob ***** dle očekávání, je to dáno zmíněným ovladačem. Ovladač po aktivaci definic ochrany dat dle doporučení vypněte, jinak vás bude zbytečně mást.

Pro správné pochopení a implementaci ochrany dat dle GDPR pro osoby versus firmy, je dále třeba vzít v potaz následující fakta:

Z toho plyne:

  • je třeba rozlišovat ochranu dat firem-právnických osob (se zatrženým Právnická osoba) a firem osob-fyzických osob. Proto je v záložce Chráněné položky možno nastavit ochrany položek pro tyto třídy objektů resp. pomocné virtuální třídy (jejich popis viz výše):

Jak bylo zmíněno výše v popisu vytváření povolení typu generování, na základě pravidel typu generování, je-li subjektem "firma", znamená to "všechny verze" jedné firmy, tj. zohledňuje se existence předchůdců dané firmy. Tj. podkladem pro povolení může být jak doklad vystavený na aktuální firmu tak na jejího předchůdce. Povolení se generuje vždy na aktuální firmu.

Mějme fakturu FV-1 vystavenou na firmu AAA1. Pak firmu zásadně opravíme na firmu AAA2. Spustíme generování povolení podle pravidel pro oblast faktur. Nechť FV-1 spadá do rozhodného období pro dané pravidlo. Pak na základě dané faktury vznikne povolení z dokladů pro firmu AAA2.

Mějme fakturu FV-1 vystavenou na firmu AAA1. Spustíme generování povolení podle pravidel pro oblast faktur. Nechť FV-1 spadá do rozhodného období pro dané pravidlo. Pak na základě dané faktury vznikne povolení z dokladů pro firmu AAA1. Pak firmu zásadně opravíme na firmu AAA2. I když je povolení na firmu AAA1, budou na jeho podkladě zpřístupněny i položky následovníka AAA2. Až dojde k dalšímu generování povolení, toto se zaktualizuje (a na povolení již bude uvedena firma AAA2).

Nařízení GDPR zavádí určitá práva subjektů. Zde uvedeme, jaké kroky může uživatel podniknout v rámci GDPR v IS FLORES v souvislosti s uplatněním některého z daných práv.

Možnosti řešení, dojde-li k požadavku naplnit Právo na opravu:

  • Systém IS FLORES umožňuje své záznamy normálně opravovat, tudíž požadavek na plnění tohoto práva je lehce realizovatelný prostřednictvím funkcí oprav v dané agendě.

Možnosti řešení, dojde-li k požadavku naplnit Právo na přístup:

  • K dispozici je možnost poskytnout sdělení, jaké informace jsou v systému IS FLORES o daném subjekty zpracovávány. V agendě Požadavky GDPR je k dispozici tisk. sestava Informace o subjektu, kterou lze požadovaný výpis pořídit. Dále je zde k dispozici funkce Zpracovat, která umožní provést report s využitím zmíněné tiskové sestavy a která následně zapíše na požadavek informace o jeho vyřízení.

    K získání informací pro tisk. sestavu se využívají dvě nové QR funkce NxGDPRReportSubjectPersonToMT, NxGDPRReportSubjectFirmToMT, které naplní paměťové tabulky tisk. sestavy chráněnými položkami a jejich hodnotami. Použití funkce vyžaduje speciální právo Zpracovat práva subjektů.

Možnosti řešení, dojde-li k požadavku naplnit Právo na omezení zpracování:

Možnosti řešení, dojde-li k požadavku naplnit Právo na výmaz:

  • V agendě Požadavky GDPR je k dispozici funkce Anonymizovat, kterou se provede pro daný subjekt vymazání těch evidovaných údajů v chráněných položkách, které nejsou povoleny platným povolením.

Aktuálně není definovaný žádný formát, který by měl být použit, tudíž zatím není v IS FLORES nijak zvlášť řešeno.

Možnosti řešení, dojde-li k požadavku naplnit Právo na přenositelnost:

  • lze relativně rychle nadefinovat uživatelský export podle potřeb a přání konkrétního uživatele
  • případně je možné jednoduše data přenést využitím kopie do schránky (Ctrl+C nad seznamem v dané agendě apod.).

Uživatel bude mít možnost využít datové zdroje, které jsou v systému k dispozici v rámci naplňování práva na přístup k informacím.

V souvislosti s ochranou dat probíhají v systému i mimo něj následující procesy

  • automatické úlohy průběžně aktualizují povolení ke zpracování dat a zaznamenávají incidenty
  • pověření uživatelé zaznamenávají požadavky GDPR

  • řešitelé pověření správou povolení ke zpracování dat:

    • kontrolují jejich platnost
    • řeší povolení ke zpracování dat s ukončenou platností - tj. zajišťují výmaz obsahu chráněných položek
    • řeší povolení ke zpracování dat závislé na souhlasu subjektu s platností končící v blížícím se termínu – tj. např. vznášejí požadavky na prodloužení souhlasu

    • řeší požadavky na ochranu dat, např.:

      • zajistí prověření oprávněnosti požadavku, např. námitky proti zpracování údajů
      • v případě potřeby zajistí výmaz obsahu chráněných položek u povolení, u kterých byl vznesen požadavek na výmaz

      • v případě potřeby pozastaví platnost povolení na dobu prověření oprávněnosti požadavku

        Jak na to při řešení uplatňování práv GDPR, viz řešení práv viz výše Řešení práv subjektů dle legislativy GDPR.

    • řešitelé pověření správou požadavků GDPR (mohou být shodní s řešiteli povolení ke zpracování):

      • zadávají nové požadavky
      • zajišťují jejich plnění a evidují průběh řešení (změnu stavu, popis průběhu apod.)

O průběhu akcí spojených s ochranou dat si můžeme zobrazit log. Logování událostí ochrany dat se konfiguruje jako ostatní logování v konfiguračním souboru Nexus.cfg v sekci [DataProtection~Group] (pro celou oblast ochrany dat, případně v sekcích pro jednotlivé třídy - popsáno v rámci sekce [DataProtection~Group]). Konfigurační soubor Nexus.cfg systém hledá ve stejné cestě, jako je IS FLORES.exe.

Při sledování změn se ochrana dat při zápisu změn neuplatňuje (je třeba zaevidovat skutečná data, která byla předmětem změn). Ochrana je až na úrovni prohlížení změn.

Používání ochrany dat s sebou přináší zvýšenou zátěž na celý systém - každý spuštěný klient IS FLORES se musí před zpřístupněním chráněných položek dotazovat na stav jejich ochrany. Aby byla odezva systému přijatelná, jsou informace o nastavení ochrany dat cachovány a chráněné položky jsou následně zpřístupňovány v souladu s nastavením ochrany dat platným v okamžiku poslední obnovy cache klientem.

Opětovné načtení stavu ochrany dat (obnova cache) se provádí při každém spuštění klienta a dále automaticky v intervalu obnovy cache, který je možné nastavit parametrem Nexus.cfg - CacheLifeSpan. Výchozí hodnota je 10 hodin.

Pokud tedy provádíte v nastavení ochrany dat změny (například přidáváte chráněné položky nebo oprávněné uživatele do definic ochrany dat, položky nebo uživatele z definic ochrany odebíráte, případně generujete Povolení ke zpracování dat), pro aplikování těchto změn může být zapotřebí ukončit a znovu spustit klienta IS FLORES.

Nezbytnou podmínkou pro provoz Ochrany dat je, aby byla tato část systému nainstalována a licencována.