Moderní informační systém musí řídit přístup i podle dat, vztahů a kontextu
V mnoha firmách se přístupová práva stále zjednodušují na otázku:
Kdo smí do kterého modulu?
Jenže reálný provoz je složitější.
Nestačí rozhodnout, že obchodník „vidí obchod“, účetní „vidí faktury“ a mistr výroby „vidí výrobu“. Ve skutečnosti je potřeba řídit i to, která konkrétní data kdo uvidí, co s nimi smí dělat, které jejich části může upravit a za jakých podmínek.
Právě tady se láme rozdíl mezi běžným systémem a systémem, který odpovídá realitě firmy.
Co je klasické RBAC a proč je pořád důležité
Role-Based Access Control, zkráceně RBAC, je zavedený model řízení přístupu, ve kterém se oprávnění nepřiřazují přímo jednotlivým uživatelům, ale rolím. Uživatel pak získává oprávnění podle role, kterou v systému zastává. Typicky tedy například jako obchodník, auditor, technolog, backoffice nebo vedoucí provozu. NIST RBAC popisuje právě jako model, ve kterém uživatel pracuje skrze roli a ta určuje, jaké akce smí provádět. (NIST Computer Security Resource Center)
To je důležité, protože role velmi dobře odpovídají tomu, jak firmy skutečně fungují. V organizaci bývají relativně stabilní pracovní odpovědnosti, zatímco konkrétní lidé a jednotlivá oprávnění se mění častěji. Role proto dávají systému základní řád, přehlednost a lepší správu přístupů. (NIST Computer Security Resource Center)
RBAC je tedy stále správný základ. Jenže v praxi často nestačí.
Kde samotné role přestávají stačit
Představme si několik běžných situací:
- obchodník má vidět jen své obchodní případy,
- mistr výroby má vidět jen zakázky své linky nebo provozu,
- auditor může číst dokumenty, ale nesmí měnit jejich obsah,
- regionální manažer má vidět data jen své pobočky,
- některá role smí vidět fakturu, ale ne její nákladové ceny,
- po uzavření dokumentu už některá pole nesmí být editovatelná.
V takové chvíli už nestačí jen říct, že někdo je „účetní“ nebo „manažer“. Je potřeba rozhodovat i podle obsahu záznamu, jeho vazeb, stavu, vlastníka, organizační příslušnosti nebo konkrétní akce, kterou chce uživatel provést. Právě proto OWASP u moderních aplikací doporučuje neomezovat se jen na čisté RBAC a preferovat i atributové a vztahové řízení přístupu tam, kde je to potřeba. (OWASP Cheat Sheet Series)
Přístup k typům dat není totéž jako přístup ke konkrétním záznamům
Tohle je zásadní rozdíl, který se v mnoha systémech podceňuje.
Jedna věc je říct, že určitá role má přístup k entitě „faktura“, „smlouva“, „výrobní příkaz“, „pracovník“, „zakázka“ nebo „kontakt“. To je první rovina: přístup ke struktuře systému.
Druhá rovina je mnohem jemnější:
Ke kterým konkrétním fakturám, smlouvám nebo zakázkám se tato role opravdu dostane?
A právě zde už se dostáváme za klasické RBAC k jemnějšímu řízení přístupu. NIST popisuje ABAC jako model, ve kterém se přístup rozhoduje podle atributů subjektu, objektu, akce a prostředí. Jinými slovy: nejen kdo jste, ale i k čemu přistupujete, co s tím chcete dělat a v jakém kontextu. (NIST Computer Security Resource Center)
Jak k tomu přistupuje Flexideo
Ve Flexideu role tvoří důležitý základ, ale nekončíme u nich.
1. Role lze definovat plně podle reality firmy
Role ve Flexideu nejsou pevně daný seznam. Lze je volně navrhnout, pojmenovat a dále rozvíjet podle konkrétní firmy, oboru i konkrétního způsobu použití systému.
Role tedy mohou odpovídat skutečnému provozu firmy, ne jen obecným kategoriím typu „admin“ a „uživatel“. Může jít například o role jako:
- obchodní backoffice,
- mistr výroby,
- auditor,
- technolog,
- kontrolor kvality,
- externí partner,
- servisní koordinátor,
- regionální vedoucí.
Systém se tak nepřizpůsobuje předem daným rolím. Naopak role se definují podle reality klienta.
2. Přístup lze řídit na úrovni typů entit i jejich částí
Flexideo nepracuje jen s tím, že určitá role vidí nebo nevidí určitou oblast systému.
Řídit lze i to:
- které entity daná role vůbec používá,
- zda má přístup jen ke čtení,
- zda může vybírat, zapisovat nebo editovat,
- zda může vytvářet nové záznamy,
- zda může schvalovat nebo uzavírat určité kroky,
- zda smí vidět jen část dat uvnitř záznamu.
To je důležité například ve chvíli, kdy uživatel může pracovat s fakturou nebo zakázkou jako celkem, ale nesmí vidět některé finanční údaje, interní poznámky, nákladové ceny nebo citlivé vazby.
Jinými slovy: nejde jen o přístup k modulu, ale i o jemné řízení práce s konkrétní strukturou dat.
3. Flexideo umí řídit i přístup ke konkrétním záznamům
Tím ale řízení oprávnění nekončí.
Ve Flexideu lze definovat i to, které konkrétní záznamy má daná role nebo konkrétní uživatel k dispozici. A to nejen podle jednoduchého filtru, ale i podle vazeb mezi daty, organizační struktury, obsahu propojených záznamů nebo dalších podmínek.
Právě zde vzniká rozdíl mezi běžným „vidí modul fakturace“ a skutečně použitelným podnikovým systémem.
Mistr výroby tak nemusí vidět všechny výrobní příkazy ve firmě, ale jen ty, které patří jeho provozu. Obchodník nemusí vidět celý obchodní funnel celé firmy, ale jen své klienty nebo svůj region. Auditor může mít přístup jen k dokumentům, které spadají do jeho auditu nebo odpovědnosti.
To už není jen hrubé rozdělení rolí. To je řízení přístupu podle datové reality firmy.
4. Uživatel ve Flexideu není jen login, ale součást datového modelu
Velkou výhodou Flexidea je, že uživatelský účet nemusí být izolovaný technický objekt.
Stejně jako lze definovat strukturu faktur, smluv, zakázek, linek, poboček nebo kontaktů, lze definovat i strukturu uživatele a jeho vazby na další entity systému.
Uživatel tak může být napojen například na:
- organizaci,
- pobočku,
- pracovníka,
- externí kontakt,
- obchodní případ,
- konkrétní tým,
- konkrétní roli v procesu.
Díky tomu lze přístup řídit nejen podle obecné role, ale i podle skutečného vztahu uživatele k datům.
A právě tím se Flexideo dostává i k logice, kterou dnešní bezpečnostní praxe popisuje jako atributové nebo vztahové řízení přístupu: rozhodnutí není dáno jen tím, jakou roli uživatel má, ale i tím, k jaké části reality firmy patří a jaký má vztah ke konkrétnímu záznamu. NIST ABAC popisuje přesně tuto logiku práce s atributy a OWASP výslovně doporučuje pro moderní aplikace vedle RBAC zohledňovat i atributy a vztahy. (NIST Computer Security Resource Center)
Proč je důležité řídit oprávnění pod povrchem systému, ne jen v obrazovce
V řadě aplikací bývá bezpečnost ve skutečnosti řešena jen „vizuálně“. Uživatel nevidí tlačítko, nevidí menu nebo nevidí určitý formulář — a systém se tváří, že je problém vyřešen.
Jenže to není skutečné řízení přístupu.
OWASP dlouhodobě upozorňuje, že oprávnění mají být kontrolována průběžně a na každém požadavku, ne jen schována v uživatelském rozhraní. Broken Access Control patří podle OWASP mezi nejzávažnější třídy aplikačních chyb a souvisí právě s tím, když systém nevynucuje přístupová pravidla důsledně.
Proto je důležité, že ve Flexideu lze přístup řídit nejen na úrovni rozhraní, ale i pod ním — na úrovni dat, vazeb, stavů a pravidel.
To znamená, že systém může:
- řídit, která data se uživateli vůbec načtou,
- řídit, která pole mohou být editovatelná,
- řídit, které části rozhraní mají být dostupné,
- řídit práci se záznamem podle jeho stavu,
- řídit oprávnění napříč tabulkami, formuláři, dokumenty, diagramy nebo dalšími pohledy.
UI je pak důležité pro přehlednost a ergonomii. Ale skutečná pravidla musí být vynucena hlouběji.
Co to znamená v praxi pro firmy
Pro klienta to není jen technická zajímavost.
Je to rozdíl mezi systémem, který jen „nějak funguje“, a systémem, který odpovídá skutečnému provozu firmy.
Dobře navržené řízení přístupu znamená například:
- menší riziko, že někdo uvidí data, která vidět nemá,
- menší riziko nechtěných zásahů do citlivých údajů,
- přehlednější práci pro jednotlivé role,
- jednodušší provoz i onboarding nových lidí,
- bezpečnější práci napříč odděleními, pobočkami a partnery,
- lepší podporu schvalování, odpovědností a auditovatelnosti.
A hlavně: systém není postavený jen jako univerzální software pro všechny, ale jako nástroj odpovídající tomu, jak konkrétní firma opravdu funguje.
Kde končí běžný systém a začíná řešení na míru
Běžné aplikace často zvládnou základ:
- uživatel,
- skupina,
- role,
- modul,
- jednoduché oprávnění.
Jakmile ale firma potřebuje řídit přístup jemněji — podle poboček, týmů, vztahů, stavů dokumentů, vlastnictví záznamu, části dat nebo složitějších provozních pravidel — začnou se objevovat limity.
A právě tam dává smysl systém, který má řízení přístupu zabudované jako součást svého návrhu, ne jako dodatečný kompromis.
Shrnutí
RBAC je správný základ. Role jsou důležité a bez nich se podnikový informační systém obvykle neobejde. Standardní bezpečnostní zdroje ale zároveň ukazují, že u moderních aplikací samotné role často nestačí a je potřeba rozhodovat i podle atributů, vztahů a kontextu přístupu. (NIST Computer Security Resource Center)
Právě to je směr, kterým se ubírá Flexideo.
Ve Flexideu lze řídit nejen to, kdo má jakou roli, ale i:
- s jakými entitami pracuje,
- které konkrétní záznamy uvidí,
- které části dat smí číst nebo měnit,
- jak se přístup mění podle vazeb, stavu a kontextu,
- co se má a nemá zobrazit v konkrétním rozhraní.
Proto ve Flexideu neřešíme jen otázku
„kdo smí do systému“,
ale hlavně otázku
„kdo smí pracovat s jakými daty, jakým způsobem a za jakých podmínek“.
A právě v tom se pozná opravdu použitelný informační systém.
