Metodika · Návrh a obrana webových aplikací
Modelování hrozeb je strukturovaný způsob, jak se na systém podívat z pohledu jeho hodnot, uživatelů, datových toků a možných selhání. Jeho cílem není vytvořit seznam hypotetických katastrof. Má pomoci rozhodnout, které části návrhu potřebují jasnější oprávnění, menší přístup, bezpečnější výchozí nastavení nebo lepší dohled. Malý tým může začít během jedné pracovní schůzky a model průběžně upravovat, když se aplikace mění.
Začněte otázkou, kterou chcete zodpovědět
Než otevřete tabuli nebo dokument, vymezte účel. Může jít o nové přihlašování, import souborů, funkci sdílení, platební krok nebo plánované propojení s externí službou. Když se pokusíte modelovat celý rozsáhlý systém najednou, diskuse snadno sklouzne k neúplnému seznamu všeho možného. Užší rozsah přináší použitelnější výsledek: co přesně se mění, kterých uživatelů se to týká a jaké rozhodnutí má tým udělat.
Zapište také hranice práce. Uveďte, které aplikace, prostředí, role a datové typy do modelu patří a co zůstává mimo. Rozlište současný stav od plánované změny. Pokud si nejste jistí závislostí nebo oprávněním některé části, označte ji jako otázku k ověření. Domněnka by neměla být skrytá mezi potvrzenými skutečnostmi.
Určete, co má aplikace chránit
Aktivem může být osobní údaj, obsah účtu, přístupová relace, konfigurace, obchodní záznam, dostupnost služby nebo důvěra mezi dvěma systémy. U každé položky si položte praktické otázky: kdo ji potřebuje, co by pro uživatele znamenala její ztráta, změna nebo zveřejnění a jak dlouho ji aplikace skutečně musí uchovávat? Tím odlišíte důležité zdroje od technických detailů, které sice vypadají složitě, ale samy o sobě nemají velkou hodnotu.
Nezapomeňte na tajemství a oprávnění. Token, který dovoluje změnit účet, může být důležitější než samotný záznam v databázi. Stejně tak může být kritická možnost změnit cizí obsah, i když žádná data nelze stáhnout. Popište hodnotu způsobem, který rozumí produktový tým: „uživatel může číst své soukromé poznámky“ je srozumitelnější než samotný název tabulky nebo služby.
Popište role a jejich legitimní možnosti
Sepište aktéry, kteří se systému dotýkají: návštěvník bez účtu, přihlášený uživatel, správce, podpůrný pracovník, plánovaná úloha nebo externí služba. U každého uveďte, co má podle návrhu dělat a která oprávnění potřebuje. Pokud stejný účet plní několik rolí, zaznamenejte, kdy se jeho oprávnění rozšiřuje a jak se kontroluje. Tato mapa často odhalí záměnu mezi tím, kdo je přihlášený, a tím, k jakému konkrétnímu objektu smí přistoupit.
Formulujte také očekávané chování. Uživatel má upravovat vlastní záznam, správce má mít přístup jen v rozsahu své práce a služba na pozadí má vykonávat přesně určenou úlohu. Tato očekávání budou později sloužit jako kontrolní body pro návrh i testování. Model se tak nezastaví u obecné věty „ověřit přihlášení“, ale ukáže, které rozhodnutí o přístupu musí aplikace udělat.
Nakreslete tok dat a hranice důvěry
Na jednoduchém náčrtu zachyťte uživatelské rozhraní, aplikační rozhraní, hlavní služby, databáze, úlohy na pozadí a případné externí závislosti. Šipka by měla znamenat konkrétní tok: kdo posílá jaký druh dat, kdo rozhoduje o oprávnění, kde se obsah ukládá a kam se výsledek vrací. Nemusíte kreslit každý server ani přesnou topologii sítě. Cílem je, aby tým viděl, kudy informace prochází a kde se mění její důvěryhodnost.
Hranice důvěry vzniká všude, kde se mění vlastník, oprávnění nebo míra kontroly nad daty. Patří sem vstup z prohlížeče, volání mezi službami, import souboru, webhook, integrační API, administrátorské rozhraní i export výsledku. U každého přechodu se ptejte, zda se vstup ověřuje, zda se znovu kontrolují oprávnění a zda cílová služba dostává jen údaje, které potřebuje. Uživatelské rozhraní může některé volby skrýt, ale skutečné rozhodnutí o přístupu musí být v místě, které danou operaci vykonává.
Nákres nemusí být krásný. Stačí legenda pro důvěryhodné zóny, označení citlivých dat a poznámka, které části jsou předpoklad. Pokud se vývojář, produktový člověk a provozní tým na obrázku neshodnou, je to užitečný signál: jejich představa o systému se liší a stojí za to rozdíl vyřešit dříve, než se promění v chybu.
Sepište realistické scénáře selhání
Pro každé aktivum a hranici napište, co se může pokazit z pohledu uživatele nebo služby. Může jít o neoprávněné přečtení cizího záznamu, nečekanou změnu obsahu, záměnu identity, únik tajemství v logu, nechtěné odesílání nadměrných požadavků nebo chybné předání dat mezi dvěma systémy. Scénář popište v jedné či dvou větách: co se děje, jaká slabina tomu může pomoci a jaký je možný následek.
Pomáhá uvažovat od očekávaného pravidla: „uživatel smí upravovat pouze své vlastní poznámky“. Potom se ptejte, zda toto pravidlo platí při načtení, úpravě, sdílení, exportu i obnově z historie. U externí integrace začněte podobně: „služba smí kontaktovat pouze schválené cíle a nesmí předávat přihlašovací údaje“. V každém případě jde o kontrolu návrhu, nikoli o zkoušení na cizích účtech nebo produkčních datech.
Počet scénářů držte zvládnutelný. U úzké funkce často stačí několik důležitých případů. Vynechte vágní věty typu „někdo hackne server“ a přepište je na konkrétní otázku: která role může obejít kontrolu vlastníka, co by pak získala a jaké omezení tomu má bránit? Konkrétní scénář se dá přiřadit vlastníkovi, opatření i ověření.
Určete prioritu bez falešné přesnosti
Ne každé představitelné selhání má stejnou důležitost. Při prioritizaci zvažte, co se může stát, kolik účtů nebo dat by bylo zasaženo, jak snadno by problém vznikl, zda je možné ho odhalit a zda existuje bezpečná cesta nápravy. Zaznamenejte i nejistotu: scénář s velkým možným dopadem, ale nejasnou pravděpodobností může vyžadovat rychlé ověření před tím, než jej tým odloží.
Vyhněte se číslům, která vypadají přesněji, než dovolují vstupní informace. Jednoduché označení „řešit před vydáním“, „naplánovat“ a „sledovat“ bývá pro menší tým praktičtější než dlouhá matice s odhady na desetinná místa. U každé priority napište krátké zdůvodnění a jméno či roli člověka, který rozhodnutí potvrdil. Model má podporovat rozhodnutí, nikoli automaticky vydávat verdikt.
Přiřaďte opatření i způsob ověření
Každý prioritní scénář potřebuje konkrétní odpověď. Může jít o kontrolu oprávnění u každé operace, minimální rozsah přístupu služby, bezpečné ukládání tajemství, omezení odchozích spojení, limity požadavků, ochranu citlivých údajů v logu nebo proces, který zabrání sdílení záznamu s nesprávnou osobou. Jedno opatření může snížit více rizik, ale vždy uveďte, na který scénář a hranici důvěry míří.
Ke každému opatření přidejte ověřitelnou podmínku: jaký benigní test nebo kontrola v lokálním či testovacím prostředí ukáže, že očekávané pravidlo platí? Například test s testovacími účty může ověřit, že účet A nevidí záznam účtu B. Kontrola konfigurace může potvrdit, že služba nemá širší přístup, než potřebuje. Nepoužívejte reálná cizí data a neprovádějte neautorizované testy. Pokud tým potřebuje bezpečnostní ověření mimo vlastní prostředí, musí mít předem výslovný rozsah a vhodné povolení.
Příklad: aplikace pro sdílené poznámky
Představme si malou aplikaci, v níž lidé vytvářejí soukromé poznámky a mohou je sdílet s pozvaným kolegou. Aktiva jsou obsah poznámek, seznam pozvaných lidí, přihlašovací relace a možnost změnit nebo odstranit záznam. Aktéry tvoří nepřihlášený návštěvník, vlastník poznámky, pozvaný čtenář, správce a služba, která posílá e-mailová upozornění. Tok dat vede z prohlížeče do aplikačního rozhraní, dále do úložiště a případně do poštovní služby.
Hranice důvěry jsou vstup z prohlížeče, ověření identity, kontrola vlastníka záznamu, proces sdílení a předání adresy poštovní službě. Scénáře mohou zahrnovat chybnou kontrolu toho, kdo smí poznámku upravit; nechtěné zveřejnění odkazu v oznámení; nebo příliš široký přístup služby k obsahu. Model pak vede k opatřením: server ověřuje vlastníka nebo pozvanou roli při každém požadavku, odkaz ke sdílení má jasnou platnost a rozsah, upozornění obsahuje minimum citlivého obsahu a poštovní služba dostane pouze údaje potřebné k odeslání.
Ověření se provede s testovacími účty a syntetickými poznámkami. Tým zkontroluje, že vlastník může provádět povolené změny, pozvaný čtenář má jen čtecí přístup a nepřihlášený návštěvník obsah nezíská. Samostatně se prověří, že zrušení pozvánky skutečně ukončí přístup a že oznámení neodhalí citlivý text. Příklad zůstává záměrně obecný: jeho cílem je ukázat postup uvažování, ne popsat slabinu konkrétní služby.
Model udržujte spolu s aplikací
Hrozbový model zastará, když se změní role, datové toky nebo závislosti. Aktualizujte jej při přidání nové integrace, změně přihlašování, zavedení veřejného sdílení nebo rozšíření oprávnění administrátora. Nevyžaduje to vždy nové setkání. Často stačí upravit nákres, zapsat nové předpoklady a přidat otázky do běžného review změny.
U každého záznamu uchovávejte datum, rozsah, vlastníka rozhodnutí a stav opatření. Rozlišujte mezi „ověřeno“, „plánováno“ a „neznámé“. Pokud se opatření opírá o další službu, napište její jméno a předpoklad důvěry. Tím se příští tým nebude muset domýšlet, proč byla určitá hranice považována za bezpečnou.
Časté chyby při modelování
- Model popisuje celou organizaci, takže nikdo neví, co se má změnit.
- Diagram ukazuje servery, ale neukazuje role, oprávnění a citlivá data.
- Scénáře jsou obecné a nemají vlastníka ani realistický následek.
- Priorita vzniká z pocitu jistoty, nikoli z dopadu, rozsahu a nejistoty.
- Opatření nemá způsob ověření nebo je závislé na předpokladu, který nikdo nepotvrdil.
- Dokument se uloží po návrhu a při další změně aplikace se už neotevře.
Pro další kontext navazuje poznámka Server-side browsing, revisited, která ukazuje, proč jsou hranice důvěry důležité u funkcí pracujících s externími cíli. Praktické zásady práce v bezpečném laboratorním prostředí jsou na stránce Tools & labs; postup koordinovaného hlášení nálezu shrnuje Responsible disclosure. Nový přístup k modelu hrozeb doplňuje také český návod jak napsat kvalitní report bezpečnostní chyby.
Jednoduchý model, který tým používá, je užitečnější než rozsáhlý dokument, který nikdo neudržuje. Začněte u změny, kterou právě připravujete, pojmenujte aktiva a hranice, vyberte několik realistických scénářů a u každého určete vlastníka i bezpečné ověření. Tím vznikne společný jazyk pro vývoj, produkt i provoz.
Rychlá osnova pro týmovou schůzku
- Jaká změna se posuzuje a co je mimo rozsah?
- Která data, oprávnění a služby mají nejvyšší hodnotu?
- Kdo se systému dotýká a co smí dělat?
- Kde data přecházejí mezi různými úrovněmi důvěry?
- Jaké tři scénáře by nejvíc ovlivnily uživatele nebo provoz?
- Jaké opatření, vlastník a test patří ke každému scénáři?
- Kdy se model znovu otevře a kdo aktualizaci potvrdí?
Časté otázky
Musí být hrozbový model technický diagram?
Nemusí. Nákres datových toků pomáhá, ale stejně důležité jsou srozumitelné role, scénáře, rozhodnutí a vlastníci opatření. Zvolte formát, kterému tým rozumí a který bude aktualizovat.
Kdy je nejlepší model vytvořit?
Ideálně při návrhu nové funkce nebo před významnou změnou architektury. Lze jej ale vytvořit i pro již běžící systém a začít částí, která pracuje s citlivými údaji nebo oprávněními.
Je model náhradou za bezpečnostní test?
Ne. Model pomáhá vybrat otázky a opatření; kontrola návrhu, testování a provozní dohled přinášejí další důkazy. Každá činnost musí proběhnout v prostředí a rozsahu, pro který má tým oprávnění.
Článek je obecným vzdělávacím průvodcem pro obranné plánování. Konkrétní opatření je třeba přizpůsobit architektuře, datům, oprávněním a dohodnutému rozsahu práce.