Serverless aplikace jsou také známé jako cloudové funkce, které vykonávají velmi specifické úlohy a existují jen několik sekund. Díky tomu jsou efektivnější, pokud jde o získání maxima výhod z cloudového prostředí a minimalizaci nákladů.
Stejně jako u všech nových technologií však bezpečnostní důsledky tohoto nového paradigmatu ještě nejsou plně prozkoumané a pochopené.
„Mnoho lidí si stále myslí, že serverless je magie a za zabezpečení jejich kódu je odpovědný někdo jiný,“ vysvětluje Ory Segal, technologický ředitel a spoluzakladatel společnosti PureSec.
Pravda je ale zcela jinde. Je však možné zvýšit bezpečnost serverless aplikací a použít nejlepší bezpečnostní metody ke snížení pravděpodobnosti kompromitace.
Způsoby hackování
Servery stále existují, samozřejmě, ale funkce jsou abstrahované a nejsou svázané se žádným konkrétním prvkem infrastruktury. Skutečnost, že server obsahuje zdrojový kód vaší funkce a alespoň jeden další hostitel dočasných kontejnerů vykonává vaše funkce, znamená, že je nutné brát zabezpečení vážně.
„Funkce serverless jsou prostě kusy kódu, které spouští poskytovatel cloudu, když nastane určitá událost,“ popisuje Segal. „Jako takové mohou trpět zranitelnostmi aplikační vrstvy stejně jako každý jiný software.“
Studie nejběžnějších bezpečnostních rizik v serverless architektuře zjistila, že jedna z pěti serverless aplikací na GitHubu obsahuje kritické chyby zabezpečení.
Zatím nejsou známé žádné významné útoky, při kterých by došlo ke kompromitaci serverless funkcí. V rámci komunity zkoumající zabezpečení však o tuto oblast existuje silný zájem – někteří si dokonce myslí, že dochází k cíleným útokům, které se ještě nedetekovaly.
„Lidé se snaží zneužít serverless funkce, zejména v oblasti open source, kde je snadné zjistit, kde se zranitelnosti v kódu nacházejí,“ uvedl ve své prezentaci na letošní konferenci Black Hat Andrew Krug, bezpečnostní inženýr společnosti Mozilla.
Letos v červenci odhalila firma PureSec zranitelnost serverless open source platformy Apache Openwhisk, která podporuje služby IBM Cloud Functions. Tato zranitelnost umožnila útočníkovi přepsat zdrojový kód a změnit logiku fungování. Apache Foundation již poskytuje opravu.
PureSec také nedávno demonstrovala útok, který využil možnosti automatického škálování aplikací serverless, aby transformoval jednu zranitelnou funkci v masivní farmu pro těžbu kryptoměn.
Během testů dokázala společnost rozběhnout těžební funkce v takovém rozsahu, že dosáhla limitu pro souběžný běh na platformě. Takový útok by mohl potenciálně vést k obrovským poplatkům na konci fakturačního období – zpráva odhaduje až 120 tisíc dolarů měsíčně na účet oběti v důsledku těžby kryptoměny s využitím neplánovaného nadměrného vytížení zdrojů.
„Nejběžnějším útočným scénářem je injektáž dat zpracovávaných při události – útočník vloží škodlivá data, která jsou následně zpracována funkcí, když dojde k události,“ popisuje Segal.
Taková škodlivá data podle něj dokážou zneužívat zranitelnosti aplikační vrstvy, jako jsou například SQL injection, command injection, použití místních souborů, únik dat a tak dále. Takové útoky budou měnit pracovní logiku dané funkce.
Během červencové konference OWASP AppSec v Londýně demonstrovali Shimshi Eshkenazi a Amit Ashbel ze společnosti Checkmarx útok injektáží kódu, který dokázal kontaminovat další funkce ve stejné aplikaci, a uměl tak vyřešit problém s přetrváním.
Během prezentace tým ukázal, jak se dokázali dostat ke kódu funkce pomocí injektáže kódu, stáhnout kód funkce, změnit ho a následně infikovat další funkce přes původní zavirovanou funkci.
„Můžete tak vytvořit vzájemnou kontaminaci, která přebývá v nekonečné smyčce, infikuje další funkce, a dostává se tak zcela mimo kontrolu,“ uvádí Eshkenazi. „Jediný způsob, jak se z této situace dostat, je obnovit všechny funkce z původního zdroje – ale všechny, aniž se na nějakou zapomene.“
Nějaké výhody?
Navzdory potenciálu kompromitace nabízejí funkce serverless přístupu určité bezpečnostní výhody. Jsou izolované, méně trvalé, jen pro čtení a často mají malá nebo žádná oprávnění, která by bylo možné zvýšit, takže jsou těžším oříškem ve srovnání s jinými typy kódu.
Jako funkce mají obecně menší odpovědnost a přístup k datům než typická monolitická aplikace a okamžitý rozsah škod je menší.
„Skutečnost, že tyto funkce běží ve svém vlastním prostředí, snižuje potenciální škody. Protože se nic neukládá – funkce se po ukončení svého běhu odstraní, smaže, vyřadí – což brání přetrvání úspěšné injektáže,“ uvedl Amit Ashbel, propagátor zabezpečení ve společnosti Checkmarx.
„Když jste nakazili něco, co se smaže (po ukončení funkce), dojde tím k automatickému vyčištění – funkce je nová a čistá. Výsledkem by měla být větší bezpečnost.“
Skutečnost, že funkce poskytují jako službu hlavní poskytovatelé cloudu, nabízí vyšší úroveň zabezpečení. Přestože zůstává kódování a konfigurace samotné funkce na vás, podobně jako AWS a Azure zajišťuje, že je nosný hardware bezpečný a opravený, budou také samotné funkce pravidelně aktualizovány a kapacita těchto poskytovatelů se dokáže lépe vyrovnat s útoky DoS.
Stejně jako špatně nakonfigurované buckety S3 vedly k mnoha zprávám o únicích dat, může vést i nesprávná konfigurace aplikací serverless k problémům a únikům dat.
„Lambda má velmi dobrou výchozí konfiguraci. Problémy zde představují výchozí konfigurace populárních serverless frameworků, které by mohly otevřít přihlašovací údaje IAM,“ varuje Krug ze společnosti Mozilla.
Jak to zabezpečit?
Technologie serverless je stále ve fázi zrodu, což se odráží také v bezpečnostních postupech týkajících se této technologie.
Průzkum serveru Serverless.com zjistil, že největší problémy týkající se serverless aplikací jsou ladění, monitorování a testování, zatímco studie PureSec zjistila, že 35 procent firem nemá žádné bezpečnostní směrnice či nástroje k zabezpečení svého serverless kódu.
Čtyřicet osm procent organizací ve studii bylo nespokojeno s úrovní bezpečnostní viditelnosti, kterou měly v serverless aplikacích. Tato hodnota dramaticky roste, když má společnost více než 50 funkcí, což ukazuje, že bezpečnostní problém roste při větším měřítku.
„Tradiční vrstva ochrany aplikací, jako jsou například firewally pro webové aplikace a řešení pro ochranu koncových bodů, se pro architekturu serverless nehodí a nelze je nasadit vzhledem k nedostatku nosné infrastruktury a přístupu k síťovým a operačním systémům,“ popisuje Segal. „Bezpečnostní testovací metodiky a nástroje pro řešení serverless stále prakticky neexistují.“
Navzdory tomu mohou organizace dodržovat některé osvědčené postupy, aby zlepšily bezpečnostní stav svých serverless aplikací a funkcí.
Používejte pokud možno následujících pět osvědčených postupů:
Při návrhu a vývoji pamatujte na bezpečnost a používejte modelování hrozeb, abyste rozuměli svým rizikům. Provádějte statické analýzy kódu a penetrační testování za účelem zjišťování zranitelností.
Ověřujte správnost vstupních údajů událostí používáním bezpečných rozhraní API, které buď čistí, nebo ověřují vstup od uživatele a skenují příchozí přenosy HTTP/HTTPS do serverless aplikace.
Ujistěte se, že jsou role a oprávnění správy identity a přístupu (IAM) správně nakonfigurované, tak aby se minimalizoval rozsah přístupu. Poskytujte svým funkcím jen tolik privilegií, kolik jich potřebují k plnění svých úkolů. Pokud funkce potřebuje jen čtení, zajistěte, aby měla oprávnění jen pro čtení.
Do zdrojového kódu funkce vkládejte co nejméně citlivých údajů. Zajistěte, aby byla všechna data šifrovaná. Stejně tak zajistěte, aby byly vaše metody autentizace robustní, a kde je to možné, použijte poskytovatele FaaS. Pravidelně to kontrolujte.
„Pokud byste nedávali citlivá data do svého kódu na server,“ popisuje Eshkenazi z Checkmarxu, „neměli byste je zapisovat ani do kódu serverless, protože ho lze získat a použít k útoku.“
Mějte dostatečné znalosti o řádném vývoji aplikací serverless. Špatně vytvořené funkce automatického škálování mohou vyčerpávat zdroje.
Například společnost Auth0 nabízí platformu Webtask.io v podobě FaaS (funkce jako služba) a Tomasz Janczuk, viceprezident této společnosti, uvádí, že lze běžně vidět situace, kdy se platforma jeví, jako by na ní probíhaly útoky DoS, ale ve skutečnosti to jsou jen uživatelské chyby.
Mezi příklady patří neefektivně navržené funkce, které se snaží vyhradit velmi velké množství paměti, snaží se zapisovat obrovské soubory do souborového systému nebo blokují procesor v důsledku nekonečných smyček.
Zajistěte si podrobnou bezpečnostní viditelnost a vhled do svých serverless aplikací. Monitorování je obzvláště důležité, zejména když zvyšujete počet funkcí. Monitorujte autentizační pokusy rozhraní API, změny konfigurací funkcí, oprávnění nebo spouštěčů a dosažení limitů včetně časových limitů.
„Ať už je aplikace tradiční, kontejnerizovaná nebo serverless, musí se bezpečnost celého řešení neustále monitorovat,“ zdůrazňuje Tim Mackey, hlavní technický evangelista společnosti Black Duck spadající pod Synopsys.
„Jak se aplikace rozkládají na funkce nasazené v modelech serverless, zvyšuje se pro tyto aplikace potenciální útočný prostor a každou funkci je potřebné považovat za odlišnou dodávku, u které je nutné vykonat kompletní kontrolu zabezpečení.“
PŘEDPLATNÉ
ČLÁNKY DO MAILU