Web API a ochrana dat
V rámci zavedení obecné funkcionality ochrany dat do systému IS FLORES došlo v REST API k určitým změnám, se kterými je při návrhu klientských aplikací zapotřebí počítat, aby během provozu nedocházelo k chybám. Tyto změny byly nezbytné pro plnohodnotnou implementaci ochrany dat.
Při práci s jakýmikoli daty obecně je zapotřebí brát v úvahu, že jejich dostupnost závisí na uživatelském účtu, který je používán k zasílání HTTP požadavků - práva jednotlivých uživatelů se obvykle liší.
Ochrana dat umožňuje znepřístupňovat data uložená v určitých polích (položkách, fieldech) business objektů (BO) konkrétním uživatelům. Jaká pole BO jsou znepřístupněna kterým uživatelům, záleží na konfiguraci ochrany dat (nastavení se liší v rámci každé instalace). Chráněné položky (odpovídající fieldům business objektů) se nastavují v rámci definic ochrany dat. Více informací naleznete v kapitole Jak začít - Ochrana dat a GDPR v IS FLORES.
V REST API má výše uvedené dopad na výběr, vytváření i aktualizace BO.
- při výběru dat jsou místo obsahu polí se znepřístupněným obsahem vraceny Informační objekty signalizující, že jsou data pro aktuálního uživatele nepřístupná (skrytá)
-
při vytváření a aktualizaci je při pokusu o nastavení hodnoty pole, ke kterému uživatel nemá přístup, buď vrácen status 403 nebo je příslušné pole ignorováno (v závislosti na nastavení režimu aplikace změn)
Uživatelem se rozumí uživatelský účet použitý k zaslání HTTP požadavku.
Při výběru dat je místo obsahu znepřístupněné chráněné položky BO vrácen Informační objekt (viz Tabulka 1). To platí i pro pole obsahující výsledek výrazu (např. pokud vybíráme řetězec složený z několika položek BO, jedna z položek je chráněná a její obsah je aktuálnímu uživateli nepřístupný, je vrácen Informační objekt).
| Tabulka 1 - Struktura Informačního objektu | ||
|---|---|---|
| Vlastnost | Typ | Obsah |
|
|
|
|
"birthnumber": {
"@protected_value": true
}
V případě, že je kterákoli z položek chráněná (a aktuálnímu uživateli nepřístupná), je součástí vráceného objektu pole
| Tabulka 2 - Struktura Objektu informací o chráněných fieldech ( |
||
|---|---|---|
| Vlastnost | Typ | Obsah |
|
|
|
Pole dotazu obsahující skrytá/znepřístupněná data ( |
"@dataprotection": {
"query_fields": [
{
"name": "birthnumber"
},
{
"name": "dateofbirth$date"
}
]
}
Při vytváření nebo aktualizacích BO jsou k dispozici dva různé režimy aplikace změn - striktní a nestriktní.
-
Výchozí režim je striktní (při pokusu o nastavení znepřístupněného chráněného fieldu je vrácen status 403, požadavek se neprovede). Vypnout jej lze nastavením query parametru strictdataprotection na hodnotu false.
POST /{connection}/{kolekce BO}?strictdataprotection=false - V nestriktním režimu jsou znepřístupněné chráněné fieldy přeskakovány/ignorovány (jejich hodnoty nejsou do BO propsány).
Byly přidány dva typy zdrojů, které umožňují načítat informace o chráněných položkách na business objektech.
Získáme jej zasláním požadavku
GET /{connection}/{kolekce BO}/meta/dataprotection
Vrací seznam fieldů BO, které mohou být chráněny.
Zda jsou data obsažená v daném fieldu konkrétního záznamu danému uživateli přístupná nebo ne záleží na nastavení ochrany dat - může se pro jednotlivé záznamy lišit.
Výsledkem dotazu na tento zdroj je pole Objektů chráněných fieldů - viz tabulky 3 a 4.
| Tabulka 3 - Struktura Objektu chráněných fieldů (pole) | ||
|---|---|---|
| Vlastnost | Typ | Obsah |
|
|
|
Obsahuje objekty jednotlivých chráněných fieldů |
| Tabulka 4 - Struktura Objektu chráněného fieldu (prvek pole) | ||
|---|---|---|
| Vlastnost | Typ | Obsah |
|
|
|
Název chráněného fieldu BO |
{
"object_fields": [
{
"name": "dateofbirth$date"
},
{
"name": "birthnumber"
}
]
}
Získáme jej zasláním požadavku
GET /{connection}/{kolekce BO}/{id}/meta/dataprotection
Požadavek vrací seznam chráněných fieldů, které jsou na daném business objektu aktuálnímu uživateli znepřístupněny.
Výsledkem dotazu na tento zdroj je pole Objektů chráněného fieldu - viz tabulky 5 a 6.
| Tabulka 5 - Struktura Objektů chráněných fieldů (pole) | ||
|---|---|---|
| Vlastnost | Typ | Obsah |
|
|
|
Obsahuje objekty jednotlivých chráněných fieldů, jejichž obsah je aktuálnímu uživateli znepřístupněn |
| Tabulka 6 - Struktura Objektu chráněného fieldu (prvek pole) | ||
|---|---|---|
| Vlastnost | Typ | Obsah |
|
|
|
Název fieldu BO |
|
|
|
|
{
"object_fields": [
{
"name": "dateofbirth$date",
"accessible": false
},
{
"name": "birthnumber",
"accessible": false
}
]
}
Kromě ochrany dat ve smyslu obecné funkcionality ochrany dat, která je předmětem této kapitoly, systém IS FLORES zohledňuje i v rámci Web API práva aktuálního uživatele k chráněným objektům, včetně nastavení omezení pro číselníky chráněných objektů.
Při práci s doklady tvořenými hlavičkou a řádky platí:
- Je uplatňována stejná logika jako při práci s doklady ve vizuálním prostředí IS FLORES - tj. pokud doklad obsahuje řádky s odkazy na chráněné objekty, ke kterým uživatel nemá přístup, doklad je možné načíst (včetně řádků), ale není možné jej uložit.
Pro bezpečnostní omezení (security parametry) platí:
- Pro systémové položky na jednotlivých business objektech jsou brány v úvahu informace zaregistrované z DynSQL - pokud není změna v DynSQL, použije se výchozí (DynSQL)SecurityMask z číselníku. Výchozí hodnota parametru SecurityWithNull je False.
- Parametry definovatelných položek (běžných uživatelských položek i extra položek) jsou načítány zvlášť, bezpečnostní omezení jsou u nich společná pro výběr i pro ukládání.
- Bezpečnostní omezení jsou aplikována i na vlastněné kolekce. Výchozí hodnota SecurityWithNull na kolekcích je True. Hlavičkové záznamy jsou vybrány tehdy, když k hlavičce existuje alespoň jeden řádkový záznam odpovídající omezení, nebo k dané hlavičce neexistuje ani jeden řádkový záznam.
- Na hierarchické business objekty nejsou bezpečnostní omezení aplikována. Přesněji nejsou aplikována na referenční položky business objektu, které ukazují na stejný typ business objektu, jako je ten, na kterém jsou definovány. Příkladem je hierarchická struktura středisek - i když je struktura definována (s využitím položky Parent_ID), bezpečnostní omezení je zapotřebí nastavit pro každý záznam (středisko) zvlášť, bez ohledu na hierarchii.