Chyby v oblasti bezpečnosti, které se vám vrátí jako bumerang
Existuje konkrétní okamžik, kdy bezpečnost přestává být problémem, který „vyřešíme později“. Je to v momentě, kdy vážný investor požádá o due diligence. Nebo když vám první korporátní klient zašle dotazník týkající se bezpečnosti dodavatele. Nebo když dojde k incidentu a vy si uvědomíte, že nemáte ani ponětí, co se stalo a proč. Tyto okamžiky vždy přijdou. Jedinou otázkou je, zda jste na ně připraveni. Zde je pět rozhodnutí týkajících se bezpečnosti, která se v nejnevhodnější chvíli promění v nákladné problémy.
První vývojář získá „dočasný“ přístup správce
Všechno to začíná dobrými úmysly. Potřebujete jednat rychle, a tak svému prvnímu vývojáři udělíte plná administrátorská oprávnění k produkčnímu prostředí. Samozřejmě jen dočasně. O dva roky později ten vývojář odešel. Jeho účet stále existuje. Nikdo si nepamatuje, k čemu měl přístup. A někde ve vaší infrastruktuře se nachází zapomenutý API klíč, který stále funguje.
To není hypotetický scénář. Je to výchozí bod více incidentů, než by většina startupů chtěla přiznat: přístup, který nebyl nikdy zrušen, přihlašovací údaje, které nebyly nikdy změněny, oprávnění, která nebyla nikdy zkontrolována. Řešení není složité, ale vyžaduje disciplínu, kterou většina týmů v rané fázi postrádá, protože za to nikdo nenese odpovědnost.
Bezpečnost je popsána v README, nikoli v samotném produktu
Většina startupů má někde stanovené bezpečnostní zásady. V souboru README, v dokumentu na Notionu nebo v něčí hlavě. Co jim však chybí, je jejich prosazování na úrovni kódu. Kontroly oprávnění probíhají ve frontendu. Backend předpokládá, že se o to již postaralo uživatelské rozhraní. Koncové body API vrací vše, o co jsou požádány, protože „naši uživatelé by to neudělali“.
Z pohledu útočníka je to pozvánka. Jedno přímé volání API obejde uživatelské rozhraní a najednou data, která by měla být soukromá, soukromá nejsou. Než se na to přijde (při penetračním testu před investicí nebo, v horším případě, po incidentu), vyžaduje oprava přepsání logiky v celé kódové základně. Co by na začátku trvalo týden, trvá v tomto měřítku měsíce.
GDPR řešil právník, nikoli technik
Většina startupů „řeší GDPR“ tak, že nechá právníka sepsat zásady ochrany osobních údajů. To je právní minimum. Neznamená to však, že s daty skutečně nakládají správně.
Tento rozpor se projeví při provádění due diligence. Investoři a korporátní klienti se stále častěji ptají:
Kde jsou osobní údaje uloženy?
Kdo k nim má přístup?
Jak dlouho se uchovávají?
Co se stane, když uživatel požádá o jejich vymazání?
Pokud je odpověď na některou z těchto otázek „museli bychom to zkontrolovat“, máte problém. Ne proto, že by se okamžitě objevili regulátoři, ale proto, že to investorům signalizuje, že nemáte kontrolu nad svým systémem.
Soulad s GDPR je stejně tak technický problém jako právní. Zásady ochrany osobních údajů jsou posledním krokem, ne prvním.
„Jsme příliš malí na to, abychom se stali terčem“
Toto je nejdražší omyl v oblasti bezpečnosti startupů a je mylný z velmi konkrétního důvodu. Útočníci si své cíle nevybírají ručně na základě velikosti společnosti. Automatizované skenery neustále prohledávají každý systém vystavený na internetu a hledají známé zranitelnosti, nechráněné administrátorské panely nebo nesprávně nakonfigurované cloudové úložiště. Velikost je irelevantní. Záleží pouze na tom, zda je systém vystaven riziku.
Startup s veřejným úložištěm S3, nechráněným testovacím prostředím nebo výchozími přihlašovacími údaji v administrátorském panelu… je terčem. Ať už má deset zaměstnanců nebo deset tisíc.
Náklady na bezpečnostní incident v této fázi nejsou jen náklady na nápravu. Jde o zpoždění kola financování. O obchodní dohodu, která padne. O mediální pokrytí, s nímž jste nepočítali.
Zabezpečení se plánuje „po dalším vydání“
Každý startup má seznam úkolů. Zabezpečení je téměř vždy až na samém konci a čeká na klidnější období, které nikdy nepřijde. Oprava bezpečnostního problému v produktu s deseti uživateli je úkol na dva dny. Oprava stejného problému u produktu s deseti tisíci uživateli, složitou kódovou základnou a obchodními klienty, kteří situaci pozorně sledují, je projekt na dva měsíce.
Bezpečnostní dluh se kumuluje stejně jako technický dluh. Čím později se jím zabýváte, tím více vás to stojí času, peněz a důvěry. Startupy, které to zvládají dobře, nepovažují bezpečnost za samostatný workstream. Začleňují ji do procesu brzy, když je to ještě levné.
Jak by to mělo vypadat v praxi
Pár správných výchozích nastavení má velký význam. Pokud je nastavíte správně hned na začátku, vyhnete se většině problémů, které se obvykle objeví až později.
Prosazujte autorizaci na straně serveru. Vycházejte z toho, že každý požadavek může být vytvořen ručně.
Přidělte uživatelům pouze minimální přístupová oprávnění, která potřebují, a přezkoumejte je, jakmile dojde ke změnám.
Jakmile někdo odejde, okamžitě mu odeberte přístupová oprávnění. Ne později. Ne až si na to vzpomenete.
Sledujte, kde se vaše data nacházejí a kdo k nim má přístup. Pokud to nevíte, je to první problém, který je třeba vyřešit.
Zaznamenávejte věci, u kterých byste si přáli mít záznamy: přihlášení, administrátorské akce a přístup k citlivým datům.
Neukládejte data, která nepotřebujete. Nemůžete vyzradit to, co nemáte.
Považujte bezpečnost za součást vývoje produktu, ne za něco, co přidáte, až bude „hotovo“.
Na začátku není nic z toho složité. K tomu, abyste to zvládli, nepotřebujete specializovaný bezpečnostní tým. Potřebujete někoho, kdo se podívá na vaše současné nastavení, určí, co je ve vaší fázi skutečně důležité, a řekne vám, co opravit jako první, než to udělá investor nebo útočník.
Doporučené příspěvky
