5 nejdůležitějších kroků pro bezpečnost navrhované architektury SW

Spíš než se zločincem sedícím za počítačem v temném doupěti se budete potýkat s různými směrnicemi, GDPR, sepisováním NFRs (non-functional requirements) a podobným papírováním. A že ho je opravdu hodně.

Na co se tedy soustředit? Na následujících řádcích jsem sepsal krátký (a rozhodně ne vyčerpávající) seznam činností, které by takový architekt nebo případně analytik měl v případě bezpečnosti brát v potaz při návrhu a analýze systému.

Identifikujte minimální bezpečnostní požadavky

Ty mohou vycházet jak z požadavků zákazníka, tak z platné legislativy. Jinými slovy, dejte dohromady vše, co na aplikaci může mít vliv.

• Bude rozdíl, pokud budete pro zákazníka navrhovat intranetovou aplikaci pro pár uživatelů nebo portál dostupný celému světu.

• Zákazník také může požadovat, aby data zůstala jen na území ČR nebo EU. Zvolíte tedy umístění na vlastním serveru nebo použijete nějaký cloud?

• Jedná se o dceřinou firmu nějaké zahraniční organizace, která vyžaduje používat určité komponenty nebo je v jejich směrnicích požadavek používat jen dvou faktorovou autentizaci?

• A co legislativní požadavky? Například již zmiňované GDPR?

Získejte maximum informací o vyvíjené aplikaci

Jaké vůbec bude mít aplikace funkcionality? Jak se jich předchozí obecné požadavky týkají?

• Budou se uživatelé přihlašovat pomocí formuláře, nebo je možné jejich identitu převzít z doménového účtu, pod kterým jsou přihlášení na počítači?

• S jak citlivými daty aplikace pracuje? Znáte jejich klasifikaci?

• Jaké potenciální hrozby se mohou v aplikaci vyskytnout?

Analyzujte rizika

Vše, co jste doposud zjistili, vám přijde vhod při analýze rizik. Budete si muset nadefinovat, odkud vám hrozí nebezpečí, ohodnotit možné škody, které z toho vyplývají, a navrhnout opatření, jak tomu zabránit. A je jen na vás, a hlavně na vašem zákazníkovi, jak se k čemu postavíte. Omezit některá rizika může být oproti z toho plynoucím možným škodám natolik nákladné, že se to ani nevyplatí. Na druhou stranu můžete často nalézt hrozby, které si zaslouží pokrýt raději několika nezávislými opatřeními.

Sepište NFRs (non-functional requirements)

Mezi základní nefunkční požadavky patří výkon, škálovatelnost, spolehlivost, rozšiřitelnost, udržitelnost, spravovatelnost a bezpečnost. Vy musíte sepsat čím a do jaké míry budou jednotlivé požadavky naplněny. Vzhledem k tomu, že se některé navzájem vylučují, budete muset po dohodě se zákazníkem opět volit různé kompromisy.

• Správa logů (tj. jak a co budete logovat, po jakou dobu se logy budu zálohovat a po jaké mazat)?

• Jak budete mít zajištěnou synchronizaci času na všech zařízeních v systému?

• Jakým způsobem vyřešíte zálohování aplikace?

• Jak budete nasazovat novou verzi aplikace?

• Bude možné ovlivnit chod aplikace online změnou parametrů?

• Jaké komponenty třetích stran zvolit? Jen prověřené s certifikátem od velkých dodavatelů? Placené? Opensource? Jak to bude s licencemi?

• A spousta dalších požadavků…

Ověřte návrh

Máte konečně všechno sepsané? Co když je ve vašem návrhu chyba? Do vývoje software se kvůli nalezení chyby začleňuje fáze testování. Tu je vhodné provést i v tomto okamžiku. Najít takovou chybu na konci vývoje by vás totiž mohlo přijít pěkně draho, protože předělání špatně navrženého systému není zrovna jednoduché. Pořád je to ale lepší, než když tu chybu objeví potenciální útočník v ostrém provozu. Co byste tedy měli udělat?

Například:

• Projděte si navržené UML, UC, ER, Dataflow diagramy, … a zanalyzujte je i z hlediska bezpečnosti.

• Zkuste si představit, jak systém zareaguje, když se objeví nějaká hrozba. A namodelujte si podobnou situaci.

• Když se nastane problém, jak obnovíte správný běh systému?

• Jak zjistíte informace o tom, co se stalo? Máte nějaké auditní logy?

• Máte vybrané komponenty a služby třetích stran? Jak je zajištěné pravidelná aktualizace a kdo bude zjišťovat, zda v nich není nějaká chyba?

• Když už jste sepsali NFRs, máte nadefinována akceptační kritéria? Víte, jak budou jednotlivé požadavky splněny? Ví to i projektový manažer a počítá s tím?

• Máte zajištěno, že je systém dostatečně zdokumentovaný a jednotliví uživatelé budou vědět, jak ho používat? Například kdo a jak může nastavovat uživatelům práva?

Dočetli jste až sem? Určitě mi dáte za pravdu, že se nejedná o nějaké převratné myšlenky. Ale ruku na srdce, na kterém projektu se o bezpečnosti aplikace přemýšlí systematicky a následně se podle sestavených doporučení postupuje při vývoji i správě systému? Proto je potřeba si alespoň ty nejdůležitější body čas od času připomenout. A na ty zbývající, které jsem ani nezmínil, přijdete určitě už sami.