Vedoucí má v aplikaci více možností, zaměstnanec vidí jen své úkoly a administrátorské tlačítko zůstává ostatním schované. Z pohledu použitelnosti je všechno v pořádku. Otázka zabezpečení ale začíná o vrstvu níž: jaká data jsou těmto lidem skutečně dostupná a které operace jim dovolí datový zdroj. Přehledné rozhraní a správná oprávnění se mají doplňovat, ne navzájem nahrazovat.
Uvažujme aplikaci pro interní požadavky několika poboček. Zaměstnanec otevře přehled a vidí pouze svůj tým. Manažer může schvalovat, ostatní ne. Při běžné ukázce se systém chová přesně podle očekávání. Důležitá kontrola však ještě chybí: je přístup omezený také mimo konkrétní obrazovku?
Pokud má uživatel oprávnění číst nebo upravovat širší sadu dat v podkladovém systému, samotný filtr v aplikaci tato oprávnění nezmění. Stejně jako cedulka „pouze pro zaměstnance“ nenahrazuje zámek, ani skryté tlačítko nevytváří bezpečnostní hranici. Může lidem usnadnit orientaci. O přístupu ale musí rozhodovat odpovídající vrstva řešení.
Rozhraní má pomáhat. Datový zdroj má vynucovat pravidla.
V Power Apps dává smysl přizpůsobit obrazovky rolím. Nákupčí nepotřebuje administraci číselníků, recepce nepotřebuje rozpočet servisního oddělení. Méně nepotřebných funkcí znamená srozumitelnější práci a menší prostor pro omyl. Tím však návrh oprávnění nekončí.
Dataverse používá bezpečnostní role, které určují dostupná data a povolené operace. U SharePointu nebo jiného zdroje je potřeba vycházet z jeho vlastního modelu přístupů. Sdílení aplikace proto nelze považovat za automatické dokončení zabezpečení všech součástí, které používá.
Praktickým východiskem je popsat konkrétní činnosti. Kdo smí případ vytvořit, kdo ho může číst, kdo měnit a kdo schvalovat? Může pracovník upravit cizí požadavek? Platí stejné podmínky pro všechny pobočky? Teprve z těchto odpovědí vzniká technické nastavení, které odpovídá skutečné odpovědnosti lidí.
Automatizace může mít větší oprávnění než její uživatel
Zvláštní pozornost si zaslouží cesta z aplikace do toku nebo další služby. Taková součást může používat vlastní připojení a mít možnost provést operace, které běžnému uživateli přímo dostupné nejsou. To může být správně, pokud je záměr jasný a požadavky se odpovídajícím způsobem kontrolují.
Představme si uzavření finančního požadavku. Nestačí, že tlačítko vidí jen manažer. Služba, která změnu skutečně provede, musí mít spolehlivý způsob, jak ověřit oprávněnost operace. Jinak by se z pohodlné automatizace mohla stát cesta kolem pravidel datového zdroje.
Podobně je potřeba zacházet se změnami rolí. Kolega přejde na jiné oddělení, získá novou odpovědnost nebo firmu opustí. Přístupový model musí počítat i s odebráním práv. Bez této části zůstává zabezpečení fotografií organizační struktury z doby, kdy aplikace vznikla.
Dobrý test má skončit také zamítnutím
Při ověřování nestačí vyzkoušet, že administrátor dokáže všechno otevřít. Potřebujeme také běžné uživatelské účty a situace, ve kterých systém správně odmítne cizí záznam nebo nepovolenou změnu. Neúspěšná operace je v tomto případě požadovaný výsledek, ne chyba k rychlému odstranění.
Součástí řešení má být i dohledatelnost důležitých změn. Kdo schválil požadavek, kdo upravil jeho obsah a pod jakou identitou proběhl automatický krok? Takový přehled pomáhá při podpoře i při hledání nesrovnalostí. Nenahrazuje však oprávnění; doplňuje je o potřebný kontext.
Pro firmu je cílem srozumitelný systém, ve kterém lidé dostanou právě ty možnosti, které potřebují. Nemusí rozumět jeho bezpečnostní architektuře. Ta ale musí fungovat i ve chvíli, kdy jejich cesta nevede přes očekávané tlačítko. V Evenaut proto patří návrh přístupů ke stejnému zadání jako formuláře, integrace a uživatelská zkušenost.
Chcete prověřit přístupy ve firemní aplikaci? Napište nám na customers@evenaut.com.
