Zabezpečení Flexideo

Ochrana dat není vlastností obrazovky. Je součástí aplikační architektury.

Flexideo je flexibilní platforma pro tvorbu a provoz informačních systémů. Flexibilita ale nesmí znamenat, že o bezpečnosti rozhoduje klientská aplikace, formulář nebo JavaScript v prohlížeči.

Proto je základním bezpečnostním principem Flexidea jednoduché pravidlo:

Klient může požadovat data nebo operaci. Aplikační server rozhoduje, zda na ně má konkrétní uživatel právo.

Bezpečnostní hranice tedy neleží v uživatelském rozhraní. Kontrola oprávnění probíhá na důvěryhodné serverové straně a je oddělena od způsobu, jakým uživatel nebo klientská aplikace požadavek formulují.

Tento princip přímo odpovídá doporučením OWASP, podle nichž musí být řízení přístupu vynucováno server-side a nesmí být možné je obejít například změnou URL, identifikátoru objektu nebo API požadavku. Broken Access Control je zároveň v OWASP Top 10:2025 stále nejvýznamnější kategorií rizik webových aplikací.

1. Více vrstev místo jedné bezpečnostní bariéry

Flexideo nestaví bezpečnost na předpokladu, že uživatel nezná strukturu aplikace nebo že nebude měnit požadavky odesílané prohlížečem.

Taková ochrana by byla křehká.

Místo toho je bezpečnost rozdělena mezi několik nezávislých vrstev:

ověření identity uživatele,
aplikační role a oprávnění,
omezení přístupných datových struktur,
oprávnění ke konkrétním záznamům,
kontrolu operací na aplikačním serveru,
omezená databázová oprávnění,
ochranu komunikace mezi webovými originy,
provozní a infrastrukturní bezpečnost,
logování a možnost zpětné kontroly bezpečnostních událostí.

Jednotlivé vrstvy mají rozdílný účel. Případná chyba nebo nedostatečné omezení v jedné vrstvě proto nemusí automaticky znamenat přístup k chráněným datům.

Tento přístup odpovídá principu defence in depth.

2. Role-based přístup: oprávnění podle skutečné odpovědnosti uživatele

Základním prvkem autorizace je práce s rolemi.

Uživatel nedostává přístup pouze proto, že je „přihlášený“. Jeho možnosti vycházejí z role nebo kombinace rolí, které odpovídají jeho skutečné pozici a odpovědnosti.

Role mohou určovat například:

ke kterým oblastem systému má uživatel přístup,
jaké typy dat může zobrazovat,
jaké informace smí měnit,
jaké procesní nebo administrativní operace může provádět,
jaké části systému se mu vůbec zpřístupní.

Role Based Access Control je standardní model pro řízení oprávnění ve větších informačních systémech. NIST jej popisuje právě jako způsob, jak přiřazovat oprávnění rolím odpovídajícím organizačním odpovědnostem namísto ručního nastavování práv jednotlivým uživatelům.

Ve Flexideu ale role představují pouze první část rozhodování o přístupu.

3. Nestačí vědět „co smí role“. Rozhoduje i konkrétní záznam.

Jedním z nejčastějších problémů jednodušších informačních systémů je situace, kdy aplikace správně rozpozná, že uživatel smí například pracovat s klienty, smlouvami nebo zaměstnanci, ale následně mu zpřístupní všechny záznamy daného typu.

Flexideo odděluje dvě dimenze oprávnění:

Strukturální oprávnění

Určuje, ke kterým datovým oblastem, objektům nebo funkcím smí uživatel vůbec přistupovat.

Například:

zaměstnanec může vidět docházku,
účetní finance,
vedoucí manažerské přehledy,
administrátor konfigurační funkce.

Oprávnění konkrétního záznamu

I když uživatel smí pracovat s daným typem dat, server dále rozhoduje, které konkrétní záznamy této struktury mu mohou být zpřístupněny.

Typickým příkladem je:

rodič může pracovat s údaji o dětech, ale pouze o svých dětech,
obchodník může pracovat se smlouvami, ale pouze s těmi, ke kterým má vztah,
pracovník pobočky může pracovat s klienty své organizační jednotky,
vedoucí může vidět širší množinu dat podle svého organizačního oprávnění.

Tím Flexideo chrání před typickou třídou problémů označovanou jako IDOR/BOLA — tedy před situací, kdy by znalost nebo změna ID objektu umožnila zobrazit cizí záznam.

OWASP výslovně doporučuje vynucovat vlastnictví a oprávnění ke konkrétním záznamům na serverové straně.

4. Klientská aplikace není bezpečnostní hranicí

Webový prohlížeč je prostředí uživatele. Proto jej nelze považovat za důvěryhodnou bezpečnostní vrstvu.

Uživatel může:

sledovat síťovou komunikaci,
měnit parametry požadavků,
upravit JavaScript,
změnit ID objektu,
vytvořit vlastní HTTP požadavek,
použít vývojářské nebo penetrační nástroje.

Flexideo s tímto principem počítá.

Server tedy nevychází z předpokladu:

„Klient nám poslal tento identifikátor, takže k němu zřejmě má oprávnění.“

Naopak vyhodnocuje identitu a oprávnění přihlášeného uživatele nezávisle na tom, co klient požaduje.

Požadavek klienta vyjadřuje, o co má uživatel zájem. Neurčuje jeho oprávnění.

To je zásadní architektonický rozdíl proti aplikacím, ve kterých jsou bezpečnostní omezení realizována především skrýváním tlačítek nebo filtrováním dat až v uživatelském rozhraní.

5. Generické SQL bez předání kontroly nad databází

Jednou z vlastností Flexidea je možnost pracovat s obecnými datovými dotazy.

To je důležitá součást flexibility platformy: aplikace nemusí mít pro každý pohled nebo variantu práce s daty pevně naprogramovaný samostatný endpoint.

Možnost formulovat obecný dotaz ale není totéž jako oprávnění provést nad databází libovolnou operaci.

Bezpečnostní model odděluje dvě otázky:

Co chce klient zjistit?

Co mu smí server skutečně zpřístupnit?

Aplikační server omezuje výsledky podle oprávnění přihlášeného uživatele jak z hlediska dostupných struktur, tak na úrovni jednotlivých záznamů.

Další bezpečnostní hranicí je samotný databázový účet používaný pro klientské dotazy. V doporučené konfiguraci jde o speciální SQL účet s minimálními oprávněními. Nemá operační systémová práva a jeho databázový přístup je omezen na určené pohledy; nemá běžný přístup k tabulkám ani uloženým procedurám.

Flexideo tedy nespoléhá pouze na to, že dotaz bude „správně napsaný“. Omezuje také bezpečnostní kontext, ve kterém může být vykonán.

Tento princip odpovídá zásadě least privilege — každý technický účet má mít pouze oprávnění nezbytná pro svou úlohu.

6. Proč znalost datového modelu neznamená přístup k datům

Ve webové aplikaci je možné sledováním komunikace často zjistit názvy objektů, API operací nebo identifikátorů.

Bezpečnost Flexidea proto není založena na jejich utajení.

Samotná znalost:

názvu struktury,
ID záznamu,
syntaxe požadavku,
názvu endpointu,
nebo způsobu sestavení datového dotazu

nesmí uživateli rozšířit oprávnění.

To je důležitý rozdíl mezi utajením implementačních detailů a skutečnou autorizací.

Omezení informací zveřejňovaných klientovi může být užitečným hardeningem a zmenšovat attack surface, ale základní ochrana musí fungovat i tehdy, pokud útočník princip komunikace zná.

7. CORS: explicitně řízená komunikace mezi doménami

Webové prohlížeče používají mechanismus Cross-Origin Resource Sharing — CORS — pro rozhodování, zda může JavaScript načtený z jedné originy číst data poskytovaná jinou originou.

Flexideo podporuje explicitní řízení těchto přístupů.

Pokud aplikace cross-origin přístup nepotřebuje, není důvod jej povolovat.

Pokud jej konkrétní integrace potřebuje, lze povolit konkrétní důvěryhodný origin.

Správný princip tedy není:

Povolit přístup odkudkoliv.

ale:

Povolit pouze konkrétní originy, které mají legitimní důvod dané API používat.

Tento přístup odpovídá doporučení OWASP, které preferuje explicitní seznam důvěryhodných originů a varuje před plošným používáním Access-Control-Allow-Origin: * u citlivých služeb.

CORS přitom není náhradou aplikační autorizace. I povolený origin musí stále podléhat autentizaci a serverovým oprávněním.

8. CSRF: nechtěná operace není zvýšení oprávnění

Cross-Site Request Forgery řeší jiný typ rizika.

Cílem CSRF útoku může být přimět již přihlášeného uživatele, aby jeho browser odeslal operaci, kterou uživatel sám nezamýšlel provést.

Důležité je ale rozlišit CSRF od prolomení autorizace.

Takový požadavek stále běží pod oprávněními daného uživatele.

CSRF samo o sobě:

nezvyšuje roli uživatele,
neposkytuje administrátorská oprávnění,
nedává přístup k cizím datům,
neumožňuje provést operaci, kterou server danému účtu běžně nepovolí.

Rizikem je především nechtěné provedení operace, kterou uživatel provést smí.

Ochrana proto zahrnuje kombinaci vlastností session cookies, SameSite politiky a podle konkrétní architektury také validaci původu nebo CSRF tokeny. OWASP doporučuje SameSite chápat jako jednu z vrstev ochrany a u stav měnících operací podle architektury doplňovat další kontrolní mechanismy.

9. Session ID není autentizační tajemství

Je důležité rozlišovat interní identifikátor session a skutečný autentizační token.

V architektuře Flexidea není samotné číselné SessionID bezpečnostním credentialem.

Bezpečnost přihlášení je založena na samostatném náhodném autentizačním tokenu. Technická dokumentace serverové vrstvy uvádí 256bitový náhodný token uložený v autentizační cookie.

Znalost nebo změna samotného SessionID proto nedává možnost převzít identitu jiného uživatele.

To je další příklad oddělení technického identifikátoru od skutečné bezpečnostní identity.

10. Bezpečná konfigurace je součást bezpečnosti

Ani dobře navržená platforma nemůže být bezpečná, pokud je nasazena se zásadně chybnou konfigurací.

OWASP Top 10:2025 řadí Security Misconfiguration již na druhé místo nejvýznamnějších kategorií rizik webových aplikací.

Flexideo proto rozlišuje například:

produkční a vývojové prostředí,
produkční a debug konfiguraci,
databázové účty aplikace a účty pro klientské dotazy,
explicitně povolené cross-origin zdroje,
oprávnění technických služeb,
role a oprávnění aplikačních uživatelů.

Například klientský query mechanismus musí používat správně omezený databázový účet. Pokud by byl omylem nakonfigurován pod vysoce privilegovaným systémovým účtem, bezpečnostní hranice databázové vrstvy by byla zbytečně oslabena.

To není specifikum Flexidea — je to obecná vlastnost bezpečnosti informačních systémů. Proto je správná produkční konfigurace samostatnou bezpečnostní disciplínou.

11. Ochrana proti eskalaci oprávnění

Při každém požadavku je zásadní rozdíl mezi:

autentizací — kdo uživatel je,

autorizací — co smí dělat.

Přihlášení samo o sobě nezakládá právo na konkrétní data nebo operaci.

Flexideo proto neposuzuje oprávnění pouze při vstupu do systému. Oprávnění se vztahují také na konkrétní oblasti, data a operace.

Tím se omezuje například riziko:

přístupu běžného uživatele k administrativním funkcím,
změny cizího záznamu pomocí jeho ID,
čtení dat jiné organizační jednotky,
přístupu k objektům mimo oprávněný kontext,
provedení akce pouze prostřednictvím přímého API volání.

Princip server-side kontroly každého požadavku a „deny by default“ patří mezi základní doporučení OWASP pro authorization design.

12. Audit, logování a dohledatelnost

Prevence není jedinou součástí bezpečnosti.

Druhou důležitou oblastí je schopnost zjistit, že se někdo o nepovolenou operaci pokoušel.

Bezpečnostní logování může zachytit například:

chyby autentizace,
odmítnuté autorizační požadavky,
podezřelé změny session,
aplikační chyby,
technické problémy,
administrativní nebo vysoce citlivé operace.

OWASP doporučuje zaznamenávat zejména autentizační a autorizační selhání, session management chyby a další bezpečnostně relevantní události.

Rozsah logování a alertingu je vždy nutné nastavit přiměřeně rizikovosti konkrétního řešení. Cílem není ukládat co největší množství dat, ale mít dostatek informací pro diagnostiku, bezpečnostní dohled a případnou analýzu incidentu.

13. DDoS a dostupnost služby: správná ochrana patří do více vrstev

Distributed Denial of Service útok se od většiny aplikačních útoků liší tím, že jeho cílem často není získat data, ale vyčerpat síťové nebo výpočetní prostředky a službu znepřístupnit.

Proto není správné řešit volumetrickou DDoS ochranu pouze uvnitř aplikačního serveru.

Patří především na úroveň provozního prostředí:

síťové infrastruktury,
firewallu,
reverse proxy,
WAF,
CDN nebo anti-DDoS služby,
poskytovatele konektivity a datového centra.

OWASP rozlišuje síťové, session/protokolové a aplikační DoS útoky a doporučuje kombinovat ochrany na různých vrstvách, včetně rate limitingu, resource limits a případně cloudových filtračních služeb.

Aplikační architektura zároveň pomáhá omezovat množství funkcí dostupných anonymně a odděluje privilegované operace prostřednictvím autentizace a autorizace.

Konkrétní úroveň DDoS ochrany je proto vlastností kombinace Flexideo řešení a zvoleného provozního prostředí, nikoli pouze aplikačního kódu.

14. Transportní a infrastrukturní bezpečnost

Některé oblasti bezpečnosti z principu neleží pouze v aplikační platformě.

Patří mezi ně například:

HTTPS/TLS,
firewall a síťová segmentace,
aktualizace operačního systému,
aktualizace databázového serveru,
ochrana proti DDoS,
zálohování a obnova,
ochrana a monitoring infrastruktury,
bezpečnost administrátorských účtů,
ochrana tajných klíčů a technických přístupů.

Tyto oblasti jsou součástí provozního návrhu konkrétní instalace Flexidea.

Bezpečnost informačního systému proto vždy vzniká kombinací bezpečné platformy, správné konfigurace a správně provozovaného prostředí.

15. Co řeší aplikační server a co jiné vrstvy

Pro správné posouzení bezpečnosti je užitečné rozdělit odpovědnost podle vrstev.

Vrstva	Typická bezpečnostní odpovědnost
Flexideo aplikační server	autentizace, autorizace, role, kontrola datového rozsahu, record-level oprávnění, kontrola operací, bezpečnost generických dotazů
Databázová vrstva	minimální technická oprávnění, oddělení aplikačních/query účtů, omezení databázových objektů
Klientská aplikace	bezpečné vykreslení obsahu, práce s uživatelským vstupem, ochrana klientských funkcí
Provozní prostředí	TLS, firewall, DDoS/WAF, OS a DB aktualizace, infrastruktura, zálohy, dostupnost
Konfigurace konkrétního řešení	role, uživatelé, organizační hranice, oprávnění, povolené originy a provozní pravidla
Monitoring	logy, alerty, diagnostika a reakce na bezpečnostní události

Toto rozdělení je důležité i při bezpečnostním auditu: například chybná konfigurace databázového účtu není totéž jako chyba serverové autorizace a nevhodně otevřené CORS není totéž jako broken access control uvnitř aplikace.

16. Bezpečnost není založená na skrývání systému

Flexideo je definition-driven a vysoce konfigurovatelná platforma. Některé části její komunikace a datového modelu proto mohou být pro technicky zkušeného uživatele čitelné.

Bezpečnost ale nesmí být závislá na tom, že si jich nikdo nevšimne.

Proto je důležitý jiný princip:

I když uživatel ví, jak požadavek vypadá, zná ID objektu nebo rozumí datové struktuře, nesmí tím získat práva, která mu server nepřidělil.

To je jeden z hlavních rozdílů mezi bezpečností založenou na architektuře a bezpečností založenou pouze na skrytí implementačních detailů.

17. Bezpečnost jako součást návrhu řešení

Silná platforma sama o sobě nezaručí, že každé výsledné informační řešení bude navrženo správně.

Při návrhu konkrétní aplikace je proto potřeba určit:

kdo jsou jednotlivé typy uživatelů,
jaké mají role,
která data patří kterým organizačním celkům,
kdo smí konkrétní data číst,
kdo je může měnit,
které operace jsou citlivé,
kde je nutné oddělení odpovědností,
které události mají být auditovány.

To je také důvod, proč jsou role, permissions a segmentace dat ve Flexideo Solution Designu návrhovým rozhodnutím, nikoliv až dodatečnou technickou úpravou.

18. Shrnutí

Flexideo staví ochranu dat na serverové straně.

Klientská aplikace může být flexibilní a může formulovat obecné požadavky, ale nerozhoduje o rozsahu oprávnění uživatele.

Bezpečnost vychází především z kombinace:

silné autentizace,
sofistikovaného role-based přístupu,
strukturálních oprávnění,
kontroly každého konkrétního záznamu,
serverového vynucování autorizace,
principu nejmenších databázových oprávnění,
řízené cross-origin komunikace,
oddělení produkční a vývojové konfigurace,
auditních a diagnostických mechanismů,
a bezpečně provozované infrastruktury.

Flexibilita platformy tak není postavena proti bezpečnosti.

Flexideo odděluje svobodu formulovat požadavek od oprávnění získat nebo změnit data. O tom druhém rozhoduje důvěryhodná serverová vrstva.

Právě toto oddělení je základem toho, aby bylo možné nad jednou flexibilní platformou bezpečně provozovat rozsáhlé informační systémy s rozdílnými uživateli, rolemi, organizačními strukturami a datovými hranicemi.