Aplikační bezpečnost bez falešného pocitu jistoty

Bezpečnostní problém v aplikaci často nezačíná sofistikovaným útokem. Stačí, aby uživatel změnil ID v URL a dostal se k cizí objednávce. Nebo aby administrátor omylem viděl data všech zákazníků místo své organizace. Aplikační bezpečnost je proto hlavně disciplína v návrhu pravidel, datových hranic a provozu. Nejde o jednu knihovnu, checkbox před spuštěním ani o stránku s ikonou zámku.

U B2B systémů je sázka obvykle vyšší, než se na první pohled zdá. Aplikace zpracovává kontakty, smlouvy, faktury, interní poznámky, přístupy zaměstnanců nebo data zákazníků zákazníka. Chyba nemusí znamenat jen technický incident. Může zastavit provoz, narušit důvěru a přinést nákladné vysvětlování.

Aplikační bezpečnost začíná u hranic systému

Než začneme vybírat konkrétní ochrany, potřebujeme vědět, co přesně chráníme. Jinak vznikají opatření, která vypadají dobře v dokumentaci, ale neřeší reálné riziko. Jiné nároky má interní nástroj pro desítku zaměstnanců, jiné víceuživatelský SaaS s oddělenými organizacemi a jiné systém napojený na účetnictví nebo platby.

Praktický začátek je prostý: popsat, jaká data aplikace drží, kdo k nim smí přistupovat, kudy se do ní dostávají a co se stane, když se kompromitují. U SaaS bývá kritická otázka izolace tenantů. Nestačí, že uživatel po přihlášení vidí správné menu. Každý dotaz na databázi, export, API endpoint i souborové úložiště musí ověřit, že požadovaná data skutečně patří jeho organizaci.

Tady se vyplatí být nepříjemně konkrétní. Má účetní právo číst všechny doklady, nebo je jen vytvářet? Může manažer přidat dalšího uživatele? Smí externí spolupracovník exportovat kontakty? Co udělá aplikace, když někdo zkusí otevřít objekt, ke kterému zná identifikátor, ale nemá na něj nárok? Odpovědi nejsou technický detail. Jsou součástí produktu.

Přihlášení není totéž co oprávnění

Častá chyba je zaměnit autentizaci a autorizaci. Autentizace potvrzuje, kdo uživatel je. Autorizace rozhoduje, co smí udělat. Aplikace může mít kvalitní přihlášení, dvoufaktorové ověření i bezpečně uložená hesla, a přesto zpřístupnit cizí data, pokud neověřuje oprávnění u každé citlivé operace.

Oprávnění má být vynuceno na serveru, ne jen skryto v uživatelském rozhraní. Tlačítko pro smazání lze schovat, ale požadavek na endpoint může kdokoli zkusit poslat přímo. Server proto musí před změnou zkontrolovat identitu uživatele, jeho roli, příslušnost k organizaci a případně stav konkrétního objektu.

Role typu administrátor, manažer a uživatel jsou dobrý začátek, ale samy o sobě nemusí stačit. Někdy dává smysl oprávnění odvodit i z vlastnictví záznamu, stavu schválení nebo konkrétního vztahu mezi firmami. Čím více výjimek produkt obsahuje, tím více potřebuje pravidla popsaná a otestovaná, ne uložená jen v hlavě vývojáře.

Co musí být součástí návrhu, ne dodělávka

Bezpečnost se výrazně prodražuje, když se řeší až nad hotovou aplikací. Ne proto, že by se později nedala opravit, ale protože zásah často mění datový model, tok obrazovek i integrační rozhraní. Při návrhu a vývoji proto průběžně řešíme několik oblastí.

První je práce se vstupy. Každý formulář, parametr v URL, import CSV, webhook a API požadavek je nedůvěryhodný vstup, i když přichází z vlastního frontendu. Server má kontrolovat formát, délku, povolené hodnoty i obchodní pravidla. Databázové dotazy musí používat parametrizaci, aby se vstup nikdy nestal kusem vykonávaného SQL. U textového obsahu je nutné ošetřit i scénáře, kdy by vložený kód mohl běžet v prohlížeči jiného uživatele.

Druhá je práce se soubory. Nahrávání příloh bývá podceňované, přesto kombinuje několik rizik: nečekané typy souborů, příliš velké uploady, škodlivý obsah nebo veřejně dostupné odkazy. Bezpečnější návrh omezuje typy a velikost souborů, ukládá je mimo veřejně servírovanou část aplikace a přístup řídí stejnými oprávněními jako zbytek systému. Pokud soubor potřebuje stáhnout jen konkrétní zákazník, nemá existovat trvalá veřejná adresa, kterou lze přeposlat dál.

Třetí oblastí jsou tajemství. Hesla uživatelů se neukládají v čitelné podobě. Přístupové klíče k e-mailu, platební bráně, AI službě nebo cloudovému úložišti nepatří do zdrojového kódu ani do repozitáře. Produkční konfigurace musí být oddělená, přístupy omezené a klíče vyměnitelné. To zní samozřejmě, dokud není potřeba rychle opravit produkční problém a někdo neposílá citlivou hodnotu v chatu nebo e-mailu.

API a integrace mají vlastní pravidla

Integrace zvyšují hodnotu produktu, ale současně rozšiřují jeho útokovou plochu. API nesmí předpokládat, že každý příchozí požadavek je legitimní jen proto, že přišel z očekávané IP adresy nebo obsahuje známé jméno klienta. Potřebuje ověření identity, přesně vymezená oprávnění a omezení objemu požadavků tam, kde hrozí zneužití.

U webhooků je důležité ověřit podpis zprávy a počítat s opakovaným doručením. U exportních API je vhodné hlídat, zda klient nezískává více dat, než potřebuje. A u napojení na služby třetích stran je potřeba rozhodnout, která data do nich skutečně musí odejít. Pokud funkce funguje bez předání celé databáze zákazníků, není důvod ji předávat.

Bezpečnostní požadavky se někdy střetnou s pohodlím. Dvoufaktorové ověření přidá krok při přihlášení, krátká platnost relace může obtěžovat uživatele a omezené exporty komplikují práci administrátorům. Správná odpověď není vždy maximální restrikce. Je potřeba zvážit hodnotu chráněných dat, profil uživatelů a dopad případného zneužití. Administrátor s přístupem ke všem organizacím potřebuje přísnější ochranu než běžný uživatel, který pracuje s omezenou sadou dat.

Bezpečný kód bez bezpečného provozu nestačí

Aplikace se po spuštění nemění na hotový objekt. Přibývají funkce, uživatelé, integrace i závislosti. A každá změna může vytvořit novou slabinu. Proto má bezpečnost místo ve vývojovém procesu, ne jen v závěrečném testování. Před go-live praktické bezpečnostní testy chytí nudné chyby, které reálně bolí; otázky níže jsou o tom, aby ty kontroly nebyly jen divadlo.

Základem jsou code review, automatizované testy kritických oprávnění a kontrola závislostí na známé zranitelnosti. Ne každá aktualizace knihovny musí jít do produkce okamžitě, protože může rozbít kompatibilitu nebo vyžadovat úpravy. Ale musí existovat přehled, co aplikace používá, kdo aktualizace vyhodnotí a jak se oprava dostane ven, když je riziko skutečné.

Produkční prostředí potřebuje oddělené přístupy a jasnou odpovědnost. Vývojář nemá automaticky potřebovat plný přístup ke všem produkčním datům. Testovací prostředí by pokud možno nemělo obsahovat ostrá osobní data. Zálohy musí být šifrované, dostupné jen oprávněným lidem a hlavně pravidelně ověřené obnovou. Záloha, kterou nelze obnovit, není plán obnovy.

Důležitou roli mají i logy. Pomáhají dohledat, kdo změnil oprávnění, spustil export, upravil fakturu nebo se opakovaně neúspěšně pokoušel přihlásit. Zároveň nesmí samy vytvářet problém tím, že do nich zapisujeme hesla, přístupové tokeny, celé platební údaje nebo zbytečně citlivý obsah. Logování je vždy hledání rovnováhy mezi dohledatelností a minimalizací dat.

Jak poznat, že bezpečnostní práce odpovídá vašemu produktu

Nejužitečnější otázka nezní, zda je aplikace stoprocentně bezpečná. Takový stav nelze poctivě slíbit. Lepší je ptát se, jaká rizika jsou známá, jak byla ošetřena a jak se budou řešit změny po spuštění.

U dodavatele má smysl chtít konkrétní odpovědi. Jak se vynucují oprávnění v API? Kde jsou uložená tajemství? Jak probíhá nasazení oprav? Kdo má přístup do produkce? Jak se řeší zálohy a incidenty? Pokud odpověď zůstává u obecných frází, je to varovný signál. Bezpečnost je vidět v rozhodnutích kolem dat, přístupů, testů a provozu. Když potřebujete nezávislý pohled na existující produkt, bývá audit bezpečnosti aplikace užitečnější než další checklist abstraktních opatření.

V Nextrey ji proto neoddělujeme od běžného vývoje. Když navrhujeme přihlášení, databázové hranice, administraci nebo integraci, řešíme zároveň, kdo smí co vidět, změnit a exportovat. U existující aplikace pak dává smysl začít mapováním nejcitlivějších toků místo náhodného seznamu opatření. Jak k bezpečnosti přistupujeme u spuštění a dalšího provozu, je na stránce spuštění, provoz a růst.

Dobrá aplikační bezpečnost vzniká jasnými pravidly u důležitých rozhodnutí, vynucením na správném místě a týmem, který systém udrží bezpečný i po dalším vydání — ne tím, že produkt obalíte co největším počtem kontrol.