Bezpečnosť v návrhu: prečo kontrola na konci projektu prichádza neskoro

Bezpečnostná chyba nájdená pri návrhu stojí rozhovor. Tá istá chyba nájdená po spustení stojí prepísanie a oznámenie zákazníkom. Rozdiel nie je v chybe, ale v tom, kedy sa na ňu prišlo.

Typický priebeh vyzerá takto: projekt sa postaví, týždeň pred spustením si niekto objedná audit, audit nájde, že autorizácia sa kontroluje na nesprávnom mieste — a oprava znamená zasiahnuť do polovice aplikácie. Termín už beží, takže sa nález „zaeviduje na neskôr". Neskôr nepríde.

Čo znamená „bezpečnosť v návrhu"

Nie viac dokumentov. Jeden krok navyše predtým, než sa začne písať funkcia: prejsť, čo sa na nej dá zneužiť, a z každej odpovede spraviť konkrétnu požiadavku.

Pri bežnej aplikácii sa to zmestí do pätnástich minút a otázky sú vždy podobné:

• Kto to smie urobiť? A kontroluje sa to na serveri, alebo sa len skryje tlačidlo?
• Čo keď si niekto zmení ID v adrese? Uvidí cudzie dáta, alebo dostane zamietnutie?
• Čo keď pošle inú sumu, než ktorá bola na obrazovke? Rozhoduje číslo od klienta, alebo si ho server počíta sám?
• Čo keď to spustí tisíckrát za minútu? A čo keď to spustí dvakrát naraz?
• Čo sa o tom dostane do logu? Neuloží sa tam heslo, token alebo celé osobné údaje?

Z hrozby musí vzniknúť test

Toto je ten rozdiel medzi bezpečnosťou v návrhu a bezpečnosťou v prezentácii. Opatrenie, ktoré existuje len ako veta v dokumente, zmizne pri prvom refaktore a nikto si to nevšimne.

Preto má každá odpoveď skončiť testom: test, že používateľ bez oprávnenia dostane zamietnutie; test, že cudzie ID vráti chybu a nie dáta; test, že suma poslaná klientom sa ignoruje. Keď niekto o pol roka tú kontrolu omylom odstráni, spadne build — nie zákazník.

Tri veci, ktoré v praxi zlyhávajú najčastejšie

Nie sú to exotické útoky. Sú to tri obyčajné veci:

• Autorizácia na nesprávnej vrstve. Aplikácia skryje tlačidlo, ale endpoint zostane otvorený. Skrytie v rozhraní nie je kontrola prístupu.
• Dôvera vstupu od klienta. Cena, zľava, množstvo či identita odosielateľa prídu z prehliadača a server ich prevezme. Čokoľvek, čo chodí od klienta, je návrh, nie fakt.
• Tajomstvá a osobné údaje v logoch. Loguje sa celý request „pre istotu" a v ňom token alebo rodné číslo. Log sa potom kopíruje do miest, kde preň neplatia rovnaké pravidlá.

Keď prichádza NIS2 a GDPR

Časť firiem sa o bezpečnosť začne zaujímať kvôli regulácii. To je legitímny dôvod a technicky sa prekrýva s tým, čo je rozumné robiť tak či tak: vedieť, kde sú aké dáta, kto sa k nim dostane, a mať záznam o tom, čo sa s nimi dialo.

Čo však z našej strany nedostanete, je posúdenie, či konkrétna povinnosť na vás dopadá a v akom rozsahu. To patrí vášmu právnikovi — my pripravíme technické podklady a opatrenia, nie právny výklad.

Audit má zmysel, len nie ako prvý krok

Nezávislé preverenie hotového riešenia robíme a dáva zmysel — pri prevzatí systému po inom dodávateľovi, pred väčším spustením alebo keď sa mení prevádzkovateľ. Prejdeme autentifikáciu, autorizáciu, spracovanie vstupov, závislosti a konfiguráciu, a výstupom je zoznam nálezov zoradený podľa reálneho dopadu s návrhom opravy.

Len to nie je náhrada za prvý krok. Audit povie, čo je zle. Bezpečnosť v návrhu zariadi, aby toho bolo málo.

Ako to robíme

Hrozby prechádzame pri každej funkcii, endpointe a dátovom modeli, a z nich vznikajú akceptačné kritériá, ktoré sa stanú testami. Dáta šifrujeme pri prenose aj v úložisku, prístup dávame podľa rolí a citlivé operácie zapisujeme do oddeleného auditného záznamu, ktorý sa nedá prepísať zvnútra aplikácie.

Ak preberáte systém po niekom inom alebo sa chystáte spúšťať niečo, kde by únik bolel, napíšte nám. Viac o tejto oblasti je na stránke služieb.