Bezpečnost v návrhu: proč kontrola na konci projektu přichází pozdě

Bezpečnostní chyba nalezená při návrhu stojí rozhovor. Tatáž chyba nalezená po spuštění stojí přepsání a oznámení zákazníkům. Rozdíl není v chybě, ale v tom, kdy se na ni přišlo.

Typický průběh vypadá takto: projekt se postaví, týden před spuštěním si někdo objedná audit, audit najde, že autorizace se kontroluje na nesprávném místě — a oprava znamená zasáhnout do poloviny aplikace. Termín už běží, takže se nález „zaeviduje na později". Později nepřijde.

Co znamená „bezpečnost v návrhu"

Ne víc dokumentů. Jeden krok navíc předtím, než se začne psát funkce: projít, co se na ní dá zneužít, a z každé odpovědi udělat konkrétní požadavek.

U běžné aplikace se to vejde do patnácti minut a otázky jsou vždy podobné:

• Kdo to smí udělat? A kontroluje se to na serveru, nebo se jen skryje tlačítko?
• Co když si někdo změní ID v adrese? Uvidí cizí data, nebo dostane zamítnutí?
• Co když pošle jinou částku, než která byla na obrazovce? Rozhoduje číslo od klienta, nebo si ho server počítá sám?
• Co když to spustí tisíckrát za minutu? A co když to spustí dvakrát naráz?
• Co se o tom dostane do logu? Neuloží se tam heslo, token nebo celé osobní údaje?

Z hrozby musí vzniknout test

Tohle je ten rozdíl mezi bezpečností v návrhu a bezpečností v prezentaci. Opatření, které existuje jen jako věta v dokumentu, zmizí při prvním refaktoru a nikdo si toho nevšimne.

Proto má každá odpověď skončit testem: test, že uživatel bez oprávnění dostane zamítnutí; test, že cizí ID vrátí chybu a ne data; test, že částka poslaná klientem se ignoruje. Když někdo za půl roku tu kontrolu omylem odstraní, spadne build — ne zákazník.

Tři věci, které v praxi selhávají nejčastěji

Nejsou to exotické útoky. Jsou to tři obyčejné věci:

• Autorizace na nesprávné vrstvě. Aplikace skryje tlačítko, ale endpoint zůstane otevřený. Skrytí v rozhraní není kontrola přístupu.
• Důvěra vstupu od klienta. Cena, sleva, množství či identita odesílatele přijdou z prohlížeče a server je převezme. Cokoli, co chodí od klienta, je návrh, ne fakt.
• Tajemství a osobní údaje v lozích. Loguje se celý request „pro jistotu" a v něm token nebo rodné číslo. Log se potom kopíruje do míst, kde pro něj neplatí stejná pravidla.

Když přichází NIS2 a GDPR

Část firem se o bezpečnost začne zajímat kvůli regulaci. To je legitimní důvod a technicky se překrývá s tím, co je rozumné dělat tak jako tak: vědět, kde jsou jaká data, kdo se k nim dostane, a mít záznam o tom, co se s nimi dělo.

Co ale z naší strany nedostanete, je posouzení, jestli konkrétní povinnost na vás dopadá a v jakém rozsahu. To patří vašemu právníkovi — my připravíme technické podklady a opatření, ne právní výklad.

Audit má smysl, jen ne jako první krok

Nezávislé prověření hotového řešení děláme a dává smysl — při převzetí systému po jiném dodavateli, před větším spuštěním nebo když se mění provozovatel. Projdeme autentizaci, autorizaci, zpracování vstupů, závislosti a konfiguraci, a výstupem je seznam nálezů seřazený podle reálného dopadu s návrhem opravy.

Jen to není náhrada za první krok. Audit řekne, co je špatně. Bezpečnost v návrhu zařídí, aby toho bylo málo.

Jak to děláme

Hrozby procházíme u každé funkce, endpointu a datového modelu, a z nich vznikají akceptační kritéria, která se stanou testy. Data šifrujeme při přenosu i v úložišti, přístup dáváme podle rolí a citlivé operace zapisujeme do odděleného auditního záznamu, který nejde přepsat zevnitř aplikace.

Pokud přebíráte systém po někom jiném nebo se chystáte spouštět něco, kde by únik bolel, napište nám. Víc o této oblasti je na stránce služeb.