Bezpečnost nejde naklikat: Co jsme se naučili při zabezpečování Best Guestu

Co znamená bezpečnost pro platformu, jako je Best Guest?

Best Guest je SaaS platforma, která ubytovatelům pomáhá s registrací hostů a souvisejícími povinnostmi v České republice. Platforma pracuje s informacemi souvisejícími s ubytovacími zařízeními, rezervacemi a hosty — tedy s údaji, se kterými je potřeba zacházet odpovědně a bezpečně.

To znamená, že naše odpovědnost nekončí u toho, že aplikace funguje a je dostupná.

Bezpečnost je potřeba řešit napříč celým systémem: v samotné aplikaci, v infrastruktuře, na které běží, v databázích, se kterými pracuje, v externích službách, se kterými komunikuje, i v procesech, které používáme při vývoji a provozu platformy.

Neexistuje jediná bezpečnostní funkce, která by všechny tyto problémy vyřešila.

Místo toho využíváme kombinaci postupů, jejichž cílem je omezovat zbytečné vystavení systému, kontrolovat přístupy, chránit data a zajistit, aby případné selhání jedné části systému mělo co nejmenší dopad.

Následující principy pro nás byly při nedávných kontrolách infrastruktury obzvlášť důležité.

Bezpečnost začíná správnými otázkami

Jedna z nejužitečnějších otázek, kterou jsme se naučili pokládat, zní:

Kdybychom to nastavovali dnes, udělali bychom to stejně?

Někdy je odpověď ano. Někdy ne. A někdy zní: „Funguje to, ale dnes už možná existuje lepší nebo vhodnější způsob.”

Technologie se rychle mění. Infrastruktura se vyvíjí. Objevují se nové zranitelnosti. Bezpečnostní postupy, které byly před několika lety považovány za rozumné, dnes nemusí být nejlepším řešením pro moderní produkční prostředí.

To je důvod, proč by se bezpečnostní přehlídky neměly zaměřovat pouze na hledání kritických zranitelností. Měly by také zkoumať předpoklady stojící za systémem.

Během naší kontroly jsme se podívali na oblasti jako:

• veřejně dostupné služby a porty;
• správní nástroje pro databáze;
• konfiguraci webserverů;
• HTTPS a interní komunikaci;
• správu relací;
• řízení přístupu;
• ukládání tajných údajů;
• odhalování verzí;
• konfiguraci firewallu;
• oprávnění aplikací a infrastruktury.

Žádná položka samostatně neurčuje, zda je aplikace bezpečná. Bezpečnost je obvykle výsledkem mnoha menších rozhodnutí pracujících společně.

Bezpečnostní přehlídka proto není pouze cvičením v otázce: „Je to zranitelné?”

Je to také příležitost zeptat se: „Může být jednodušší, lépe omezené nebo méně vystavené, než je dnes?”

Snížení povrchu útoku

Jedna z nejjednodušších otázek, které si klademe o jakékoli službě, zní:

Opravdu to musí být dostupné z internetu?

Moderní SaaS aplikace se často skládají z více komponent. Některé se musí komunikovat s uživateli, zatímco jiné se komunikují s externími API, databázemi nebo interními službami. Ne všechny tyto komponenty musí být veřejně přístupné.

V praxi je překvapivě jednoduché, aby se interní služba dostala do poslouchání na veřejném rozhraní.

Obvykle existuje dobrý důvod. Služba mohla být vystavena během vývoje, dočasné pravidlo firewallu mohlo být přidáno pro řešení potíží, nebo se infrastruktura mohla změnit, zatímco stará konfiguracija zůstala na místě.

Čas od času se původní důvod pro veřejný přístup může ztratit bez toho, aby se samotný přístup odebral.

To je důvod, proč je snížení povrchu útoku jedním z nejpraktičtějších bezpečnostních vylepšení, která jsou k dispozici.

Pokud je to možné, interní služby by měly být dostupné pouze z místního serveru, privátní sítě nebo konkrétně autorizovaných systémů. Veřejný přístup by měl být omezen na koncové body, které skutečně potřebují obsluhovat externí uživatele nebo integrace.

Princip je jednoduchý: pokud služba nemusí být veřejně dosažitelná, její nepřístupnost z veřejného internetu eliminuje celou kategorii možných útoků.

Je to také dobrý příklad toho, proč bezpečnost nemusí vždy vyžadovat nový produkt nebo sofistikovanější technologií. Někdy je nejefektivnějším vylepšením jednoduše odebrání přístupu, který by nikdy neměl být veřejně dostupný.

Méně veřejných vstupních bodů usnadňuje ochranu infrastruktury

Jak aplikace rostou, je běžné, že různé služby získají své vlastní veřejné koncové body. Čas od času to může vést k infrastruktuře, kde jsou jednotlivé komponenty samostatně vystaveny internetu, každá se svou vlastní konfigurací, požadavky na ověřování a potřebami monitorování.

Lépe řízený přístup je použití centrálního veřejného brány a interní směrování provozu na služby, které to potřebují.

Tato architektura poskytuje několik praktických výhod, včetně:

• centralizované správy HTTPS;
• konzistentního protokolování;
• jednoduší konfiguraci firewallu;
• snazšího monitorování;
• méně veřejně vystavených portů;
• jasnějšího oddělení mezi veřejnými a interními službami.

Poskytuje také základ pro budoucí bezpečnostní vylepšení. Ověřování, omezování rychlosti, schopnosti Web Application Firewallu a další monitorování lze zavést v centrálním bodě, spíše než implementovat nezávisle na každé službě.

Snížení počtu veřejných vstupních bodů neodstraňuje riziko. Avšak usnadňuje to pochopení systému, jeho monitorování a ochranu.

To je důležité, protože sama složitost se může stát problémem bezpečnosti.

Čím více nezávisle vystavených komponent systém obsahuje, tím víc konfigurace musí být správné.

Vícevrstvá obrana: Proč jediná bezpečnostní kontrola není nikdy dost

Firewally jsou důležitou součástí bezpečnosti infrastruktury, ale neměly by být považovány za úplnou bezpečnostní strategii.

Firewall řídí, která síťová připojení se mohou dostat k systému. Negarantuje automaticky, že aplikace za povoleným portem je bezpečná.

Moderní aplikace se může spoléhat na několik vrstev ochrany, včetně:

• pravidel firewallu;
• reverzních proxy;
• ověřování aplikace;
• API klíčů nebo tokenů;
• ověření požadavku;
• omezení rychlosti;
• protokolování;
• monitorování.

Každá vrstva řeší jiný typ rizika.

To je princip vícevrstvé obrany: místo toho, aby se spoléhalo na jediný bezpečnostní mechanismus, se používá více nezávislých kontrol ke snížení pravděpodobnosti a dopadu selhání.

Pokud je jedna vrstva nesprávně nakonfigurována nebo obejita, jiná stále může omezit škodu.

Cílem není vytvořit systém, kde musí každá jednotlivá bezpečnostní kontrola fungovat dokonale navždy. To by bylo nerealistickým předpokladem pro jakýkoli dostatečně složitý systém.

Cílem je vyhnout se situaci, kde selhání jedné kontroly okamžitě vede k selhání všeho ostatního.

Správní nástroje by neměly být veřejné ve výchozím nastavení

Vývojové a správní nástroje jsou navrženy tak, aby učinily inženýry produktivnějšími. Rozhraní pro správu databází může například značně zjednoduš správu databází ve srovnání s prací výhradně z příkazového řádku.

Problém není v existenci těchto nástrojů.

Problém je zbytečný veřejný přístup.

Správní rozhraní vystavené internetu se stává dalším potenciálním cílem pro automatizované skenery a útočníky. I když je základní software řádně udržován, vystavení rozhraní, které nemusí být veřejné, zvyšuje počet věcí, které musí být chráněny.

Pro každý správní nástroj bychom se měli zeptat:

• Musí být tento nástroj vůbec přístupný?
• Kdo ho skutečně potřebuje?
• Lze přístup omezit IP adresou?
• Měl by být dostupný pouze přes VPN?
• Byla by lepší volba SSH tunel?
• Lze nástroj zcela odstranit z produkce?

Otázka není pouze to, zda lze rozhraní zabezpečit.

Je to také to, zda rozhraní musí být veřejně dostupné.

V mnoha případech je odebrání zbytečného přístupu účinnější než přidání další vrstvy ochrany kolem rozhraní, které by nemělo být vystaveno.

HTTPS by měl být výchozím nastavením

Moderní aplikace se stále komunikují. Prohlížeče komunikují se servery, servery se komunikují s externími API a interní služby se komunikují navzájem.

Kdykoli se přenášejí citlivé informace, mělo by být připojení chráněno.

HTTPS šifruje komunikaci při přenosu a pomáhá zabránit zachycení nebo úpravě dat během přenosu. U moderních webových aplikací a API obecně není důvod pro nešifrovaný HTTP jako obvyklou komunikační metodu.

Pokud je HTTP povolen, měl by obvykle existovat pouze pro přesměrování klientů na HTTPS.

Toto není obzvlášť vzrušující bezpečnostní vylepšení. Nikdo pravděpodobně napíše případovou studii o úspěšném HTTP přesměrování.

To je pravděpodobně dobré.

Mnoho důležitých bezpečnostních vylepšení je pro uživatele neviditelné. Nevytváří novou funkci v aplikaci, ale činí základní systém bezpečnějším a odolnějším.

Vyzrazení informací a bezpečnostní průzkum

Moderní software nevyhnutelně odhaluje některé informace o sobě.

HTTP hlavičky, chybové stránky a správní rozhraní mohou vystavit podrobnosti, jako je:

• verze webserveru;
• verze PHP;
• verze databáze;
• informace o frameworku;
• nainstalovaný software.

Tyto informace automaticky nevytváří zranitelnost. Mohou však usnadnit průzkum.

Pokud útočník může rychle zjistit, který software a verze běží, snadněji to může porovnat s veřejně známými zranitelnostmi.

Snížení zbytečného vyzrazení informací je proto relativně malá úprava, která může ztížit průzkum.

Cílem není udělat systém neviditelným. Webová aplikace musí komunikovat s uživateli a jinými systémy, takže některé informace budou vždy dostupné.

Cílem je vyhnout se vystavení více, než je nezbytné.

To je důležité rozlišení, protože ne každé bezpečnostní vylepšení musí zcela eliminovat zranitelnost. Někdy je samo o sobě vhodným vylepšením snížení množství užitečných informací dostupných útočníkovi.

Bezpečné výchozí nastavení není vždy dostatečné pro produkci

Většina software funguje dokonale s výchozí konfigurací. To je vždyť účel existence výchozích nastavení.

Výchozí nastavení však obecně musí vyvažovat použitelnost, kompatibilitu a pohodlí v různých prostředích. Produkční systémy často vyžadují dodatečné posílení.

Oblasti, které stojí za přezkoumání, mohou zahrnovat:

• dobu trvání relace;
• nastavení bezpečnosti cookie;
• konfiguraci TLS;
• ověřování databáze;
• oprávnění souborů;
• zásady protokolování;
• řízení přístupu.

Systém může fungovat správně a přesto mít konfiguraci, kterou lze zlepšit.

Toto je jednou z nebezpečnějších frází v softwarovém inženýrství:

“Ale všechno to stále funguje.”

Upozornění není nutně nouzovým stavem. Mělo by to však být automaticky ignorováno. Upozornění konfigurace mohou naznačovat příležitosti ke zlepšení spolehlivosti, bezpečnosti nebo udržovatelnosti dříve, než se malý problém stane větším problémem v provozu.

Cílem není měnit každé nastavení jednoduše proto, že existuje přísnější nastavení.

Cílem je pochopit, co každé nastavení dělá, a rozhodnout, zda je současná konfigurace vhodná pro prostředí.

Ochrana tajných údajů vyžaduje pochopení hrozby

Další oblastí, kterou jsme nedávno přezkoumali, je to, jak aplikace uchovávají citlivou konfiguraci.

Přístupové údaje k databázím, API klíče a další tajnosti se běžně ukládají do souboru .env. Tento přístup je praktický a, pokud je správně zvládán, je obecně lepší než umístění přihlašovacích údajů přímo do zdrojového kódu.

Avšak to zvyšuje důležitější otázku:

Přesně co se snažíme chránit?

Existují dva různé problémy se zabezpečením:

1. Ochrana tajných údajů během jejich uložení.
2. Ochrana tajných údajů během chodu aplikace.

Tyto problémy se často zaměňují, ale vyžadují různá řešení.

Šifrování tajných údajů může pomoci chránit před náhodným vyzrazením prostřednictvím:

• úložišť zdrojového kódu;
• záloh;
• snímků serveru;
• chyb při nasazení;
• náhodně sdílených konfiguračních souborů.

Aplikace však nakonec potřebuje přístup k těmto tajnostem. Potřebuje přístupové údaje k databází pro připojení k databázi a API klíče pro komunikaci s externími službami.

Pokud útočník již dosáhl vzdáleného spuštění kódu v aplikaci, aplikace může být schopna přistupovat k těmto tajnostem bez ohledu na to, zda byla původně uložena v zašifrované formě.

Důležité rozlišení je:

Šifrování chrání uložená tajemství. Nechrání kompromitovanou aplikaci.

To neznamená, že šifrovaná tajemství jsou zbytečná. Znamená to, že bezpečnostní přínos musí být vyhodnocen proti specifické hrozbě, která se řeší.

U větších infrastruk s více vývojáři, automatizovaným nasazením a požadavky na soulad lze dedikované systémy pro správu tajemství poskytnout významné výhody.

U menších, pečlivě spravovaných prostředí mohou přísná oprávnění operačního systému, omezený přístup a bezpečné postupy nasazení poskytovat značnou praktickou ochranu bez zavedení další složitého systému.

Neexistuje cena za to mít nejkomplikovanější bezpečnostní architekturu.

Každá další komponenta také musí být nakonfigurována, udržována, monitorována a chráněna.

Někdy je správnou bezpečnostní volbou zavést novou technologií.

Někdy je to zlepšení konfigurace existujícího systému.

A někdy je nejlepším rozhodnutím nepřidávat další vrstvu složitosti, když by byl dodatečný bezpečnostní přínos omezený.

Princip nejmenších oprávnění omezuje dopad chyb

Bezpečnost není pouze o ochraně systémů před vnějšími útočníky. Je to také o omezení toho, co se stane, když se něco pokazí interně.

To je místo, kde se stává důležitý princip nejmenších oprávnění.

Každá služba, aplikace a uživatel by měly mít pouze oprávnění potřebná k výkonu své funkce.

Pokud aplikace potřebuje pouze číst z databáze, nemusí mít oprávnění k úpravě nebo odstranění všeho v databázi. Pokud služba potřebuje přístup pouze k jedné části infrastruktury, nemusí mít přístup k celému systému.

Otázky, které si pravidelně klademe, zahrnují:

• Opravdu tato služba potřebuje správcovská oprávnění?
• Lze přístup k databázi více omezit?
• Jsou přihlašovací údaje pravidelně obměňovány?
• Lze přístup auditovat?
• Jsou zálohy zašifrovány?
• Byly zálohy skutečně testovány?

Princip nejmenších oprávnění nezabrání všem útokům.

Omezuje to, co se může stát po získání přístupu.

To jej činí důležitou součástí širší strategie vícevrstvé obrany.

Bezpečnost je průběžnou disciplínou inženýrství

Snad největší lekcí, kterou jsme se naučili, je, že bezpečnost nikdy není hotová.

Objevují se nové zranitelnosti. Software se mění. Infrastruktura se vyvíjí. Nové technologie přinášejí nové možnosti a příležitostně nová rizika.

Systém, který byl dobře nakonfigurován před rokem, by nyní mohl těžit z dalšího přezkumu.

To neznamená, že je bezpečnost nemožná.

Znamená to, že bezpečnost je proces.

Každý přezkum infrastruktury je příležitostí k nahlédnutí na předchozí rozhodnutí. Každá kontrola kódu je příležitostí chytit problém brzy. Každý audit závislostí je příležitostí odstranit zastaralý software. Každý penetrační test je příležitostí naučit se něco nového.

Cílem není vytvořit systém, který nelze nikdy napadnout. Žádný odpovědný inženýr to nemůže slíbit.

Cílem je průběžně snižovat zbytečné vystavení, omezovat dopad selhání a vylepšovat systém v čase.

Co to znamená pro Best Guest

Best Guest pomáhá ubytovatelům se správou registrace hostů a souvisejícími povinnostmi v České republice.

Platforma pracuje s informacemi souvisejícími s nemovitostmi, rezervacemi a hosty. To znamená, že bezpečnost a odpovědné zpracování dat nejsou oddělenými obavami, které lze přidat poté, co byl produkt postaven.

Jsou součástí inženýrských rozhodnutí, která se podílejí na vývoji a provozu platformy.

To je důvod, proč pravidelně přezkoumáváme naši infrastrukturu a postupy vývoje.

Nemusí to být proto, že něco není v pořádku.

Často je tomu opak.

Systém může pracovat správně a stále mít prostor pro zlepšení. Veřejná služba může být zbytečná. Oprávnění mohou být širší, než je nutné. Výchozí konfigurace mohou být více omezující. Chybová odpověď mohou vystavit více informací, než je nutné.

Mnoho z těchto vylepšení je pro zákazníky neviditelné.

Neexistuje žádné nové tlačítko, na které by se dalo kliknout, a žádná funkce ovládacího panelu, kterou by bylo možné demonstrovat.

Služba může jednoduše již není veřejně dostupná. Oprávnění mohou být více omezená. Proces nasazení mohou pečlivěji zacházet s citlivou konfigurací.

Většina uživatelů se nikdy nedoví, že tyto změny byly provedeny.

To je přesně to, jak by měla fungovat dobrá bezpečnost.

Významná část bezpečnosti se odehrává potichu, za scénou.

Pohled do budoucnosti

Jak Best Guest pokračuje v růstu, budeme nadále vyvíjet náš přístup k bezpečnosti.

Budeme pokračovat v přezkoumávání konfigurace infrastruktury, řízení přístupu, závislostí, procesů nasazení, správy tajemství, monitorování a síťové architektury.

Budeme pokračovat v učení se z bezpečnostního výzkumu, průmyslových praktik a vlastních přezkoumání.

Budeme také pokračovat v otázkách, zda nová bezpečnostní technologie skutečně řeší smysluplný problém, než ji zavedeme.

Protože přidávání více technologií není automaticky to samé jako přidávání více bezpečnosti.

Někdy je správná odpověď nový nástroj.

Někdy je to lepší konfigurace.

Někdy je to odstranění něčeho, co by nikdy nemělo být veřejně dostupné.

Závěrečné myšlenky

Žádná společnost nemůže poctivě slíbit, že její software je “100 % bezpečný”.

Software je komplexní. Infrastruktura se mění. Objevují se nové zranitelnosti. Lidé dělají chyby.

To, co můžeme dělat, je brát bezpečnost vážně.

Můžeme přezkoumávat naše systémy, zpochybňovat naše předpoklady, omezovat zbytečný přístup, udržovat závislosti aktualizované, používat více vrstev obrany a učit se z toho, co zjistíme.

Bezpečnost není funkce, kterou lze přidat jednomu.

Není to zaškrtnuté políčko na plánu projektu.

Je to průběžná disciplína inženýrství.

Pro Best Guest to znamená nepřetržité přezkoumávání toho, jak stavíme a provozujeme platformu, vylepšování naší infrastruktury, jak se mění technologická krajina, a zacházení s informacemi, kterým se nám svěřuje, s péčí, kterou si zaslouží.

Cílem není tvrzení, že je bezpečnost dokonalá.

Cílem je učinit systém bezpečnějším, odolnějším a lépe pochopitelným s každým přezkoumáním.