Manažer bezpečnosti: Výpomoc interním vývojářům

Trouble Ticket
Co řešit: Implementovat šifrovací a autentizační funkce do vlastního softwaru.
Akční plán: Zvážit všechny alternativy a pokud možno využít už hotové systémy či technologie jako třeba AES nebo Active Directory.

Tento týden jsem zjistil, že naše firma interně vyvíjí software. To jsem dosud netušil, ale myslím, že bych se neměl divit. Většina společností, ve kterých jsem pracoval, si nějaký vlastní jednoúčelový software vytvářela.  O našem projektu vývoje softwaru jsem se dozvěděl teprve v okamžiku, kdy se mě jeden z programátorů zeptal na nejlepší způsob ukládání jmen a hesel v databázi aplikace.

Rozumíte dobře – snaží se vestavět autentizaci rovnou do aplikace namísto volání externí autentizační služby. Pokud uvažujete jako já, víte, že je to hloupost. Proč se snažit o implementaci vlastní autentizace, když už používáme Active Directory?

Jsem přesvědčen, že využití Microsoft API k provedení autentizace uživatele by bylo mnohem pohodlnější a bezpečnější. Nejsem však programátor. Nemám ponětí, proč se to naši lidé snaží realizovat právě takto.

Ve firmě využíváme mnoho standardních aplikací a vypadá to, že jen polovina z nich pracuje s Active Directory. Zbytek má své vlastní mechanizmy ukládání jmen a hesel uživatelů. Není to tedy žádná výjimka.

V tomto případě se naše firma snaží vytvořit novou webovou službu pro zákazníky. Využíváme přes internet mnoho aplikací SaaS (software jako služba) a u každé z nich jsem zkontroloval úroveň zabezpečení. Chci totéž provést i pro tuto novinku, pomocí které vstupujeme do sféry SaaS.

Jsem si jist, že někteří naši zákazníci se budou chtít ujistit o stupni ochrany stejným způsobem, jako tak činím já sám (přesto jsem udiven, že jsem prý „první“, kdo chce kontrolovat zabezpečení nějaké konkrétní služby -- i společnosti zvučných jmen tento proces zanedbávají).

V prvním kroku potřebuji zodpovědět otázku týkající se ukládání hesel v aplikaci. Vývojáři chtěli ukládat hesla přímo do databáze aplikace a potřebovali vědět, zda by měla být hesla ukládána v zašifrované podobě. Samozřejmě že odpověď je ano – hesla by vždy měla být zakódována, a to s využitím silné šifry, aby je v případě kompromitace databáze nebylo možno rovnou použít k získání neautorizovaného přístupu k naší aplikaci.

Dále chtěli vědět, zda si mají vytvořit vlastní šifrování v programu a nějak skrýt klíč v kódu nebo použít veřejný standard jako AES. Vysvětlil jsem jim, že veřejné standardy, zejména AES, prošly mnoha kontrolami, takže je jasné, že fungují velmi dobře. Není v našich možnostech vytvořit vlastní metodu šifrování se stejnou úrovní zabezpečení.

Stále si však myslím, že bychom měli využít služeb Active Directory nebo LDAP. Vždyť právě k tomu jsou určeny. Nezajišťují jen dotazy na uživatelské jméno a heslo a následné ověření, ale také mají vestavěné funkce pro správu účtů, vynucení zásad, změny hesla či jejich vymazání. Proč toto všechno vytvářet znovu, když to není nutné?

Manažeři naší firmy se rozhodli, že zákazníkům poskytneme lepší služby, když jim nabídneme novou internetovou aplikaci. Je to ušlechtilá myšlenka, ale myslím si, že se to zkomplikuje poněkud více, než se původně čekalo.

Řešíte podobné problémy jako J. F. Rice? Podělte se o svoje zkušenosti s námi i se čtenáři Computerworldu. Můžete psát na adresu bezpecnost@idg.cz.

Tento příspěvek do Zápisníku manažera pro bezpečnost napsal skutečný manažer bezpečnosti, který zde vystupuje jako J. F. Rice. Jeho pravé jméno ani jméno zaměstnavatele z pochopitelných důvodů neuvádíme.