Vývojári milujú kontajnery. Ľahko sa používajú a ich spustenie je rýchle. Môžete ich spustiť veľa aj na jednoduchom hardvéri. Režijné náklady pri spustení boli vždy priekopníkom vývoja a testovania a tieto režijné náklady sa zvyšujú iba pri architektúrach mikroslužieb. Ak vývojár potrebuje pol tucta služieb, môže ľahko stratiť deň alebo dva dni s nastavením - konfiguráciou hardvéru, spustením inštalačných programov, bojom proti nekompatibilite.
S kontajnermi sa to zrúti na minúty alebo sekundy a dá sa spustiť na jednej vývojovej pracovnej stanici. Ľahko dostupné úložiská užitočných obrázkov kontajnerov znásobujú produktivitu vývojárov, podobne ako to robí open source, ale bez problémov s vytváraním. Operačné tímy prijímali kontajnery pomalšie. Jedným z dôvodov je, že veľa aplikácií, ktoré musia podporovať, ešte nie je kontajnerovaných. Ďalším dôvodom je neochota vzdialiť sa od VM.
Pre operátorov bol prechod od holého kovu k virtuálnym počítačom prirodzený. Jednotlivé virtuálne počítače vyzerajú a je možné ich spravovať ako jednotlivé systémy pomocou rovnakých nástrojov a procesov. Prvotné obavy o zabezpečenie virtuálnych počítačov rozptýlila dlhá história výroby virtuálnych počítačov vo svete sálových počítačov, schopnosť aplikovať rovnaké ovládacie prvky, aké sa používajú pre systémy s obmedzeným prístupom, podpora virtualizácie hardvéru a vyvíjajúca sa vyspelosť nástrojov na správu virtuálnych počítačov.
Mnoho raných bezpečnostných obáv sa podpísalo na jednej otázke: Boli VM bezpečné ako holý kov? Teraz sa vynárajú podobné otázky týkajúce sa kontajnerov. Ako bezpečné sú kontajnery a v porovnaní s virtuálnymi počítačmi? Iste, ak porovnáme služby bežiace v kontajneroch s rovnakými službami bežiacimi ako samostatné procesy v rovnakom systéme, verzia kontajnera je bezpečnejšia. Oddelenie poskytované mennými priestormi a skupinami Linux poskytuje bariéry, ktoré medzi jednoduchými procesmi neexistujú. Porovnanie s VM je menej jednoznačné. Pozrime sa na VM a kontajnery z bezpečnostného hľadiska.
V tomto článku uplatním dva rôzne prístupy na porovnanie zabezpečenia virtuálnych počítačov a kontajnerov. Prvý prístup bude štrukturálnejší alebo teoretickejší, zameriava sa na charakteristiky každého z hľadiska bezpečnosti. Potom použijem praktickejšiu analýzu zameranú na to, čo sa stane pri typickom porušení a ako to môže byť ovplyvnené architektúrami kontajnerov a VM.
Štrukturálny pohľad
Pre štrukturálny prístup porovnám útočnú plochu oboch systémov. Útočná plocha predstavuje počet bodov, na ktoré možno napadnúť systém. Nie je presne definovaný (napríklad ako číslo), ale je užitočný na porovnanie. Zlodej má dom s 10 dverami väčšiu útočnú plochu ako dom s jednými dverami, aj keď sú dvere identické. Jedny dvere môžu byť odomknuté; jeden zámok môže byť chybný; dvere na rôznych miestach môžu útočníkovi ponúknuť viac súkromia atď.
V počítačových systémoch zahŕňa útočná plocha čokoľvek, kde sa útočník (alebo softvér konajúci v jeho mene) môže „dotknúť“ cieľového systému. Sieťové rozhrania, hardvérové pripojenia a zdieľané zdroje sú všetky možné body útoku. Upozorňujeme, že povrch útoku neznamená, že existuje skutočná chyba zabezpečenia. Všetkých 10 dverí môže byť úplne bezpečných. Väčšia útočná plocha však znamená viac chránených miest a väčšia pravdepodobnosť, že útočník nájde slabinu aspoň v jednom.
Celková útočná plocha závisí od počtu rôznych kontaktných bodov a zložitosti každého z nich. Pozrime sa na jednoduchý príklad. Predstavte si staromódny systém slúžiaci na kótovanie na burze. Má jediné rozhranie, jednoduchú sériovú linku. Protokol na tomto riadku je tiež jednoduchý: Na server sa odošle burzový symbol pevnej dĺžky, povedzme päť znakov, ktorý odpovie cenovou ponukou pevnej dĺžky - povedzme 10 znakov. Neexistuje žiadny ethernet, TCP / IP, HTTP atď. (V skutočnosti som na takýchto systémoch pracoval dávno v galaxii ďaleko, ďaleko odtiaľto.)
Útočná plocha tohto systému je veľmi malá. Útočník môže manipulovať s elektrickými charakteristikami sériovej linky, posielať nesprávne symboly, posielať príliš veľa údajov alebo inak meniť protokol. Ochrana systému by zahŕňala implementáciu vhodných kontrol proti týmto útokom.
Teraz si predstavte rovnakú službu, ale v modernej architektúre. Služba je k dispozícii na internete a sprístupňuje rozhranie RESTful API. Elektrická stránka útoku je preč - stačí iba vypáliť útočníkovi vlastný smerovač alebo prepínač. Ale protokol je nesmierne zložitejší. Má vrstvy pre IP, TCP, prípadne TLS a HTTP, pričom každá ponúka možnosť zneužiteľnej zraniteľnosti. Moderný systém má oveľa väčšiu útočnú plochu, aj keď sa na útočníka stále pozerá ako na jeden bod rozhrania.
Útočná plocha z holého kovu
Pre útočníka, ktorý sa fyzicky nenachádza v dátovom centre, je počiatočnou útočnou plochou sieť na serveri. To viedlo k „perimetrickému pohľadu“ na bezpečnosť: Chráňte vstupné body do dátového centra a nič sa nedostane dovnútra. Ak sa útočník nemôže dostať dovnútra, nezáleží na tom, čo sa stane medzi systémami vo vnútri. Fungovalo to dobre, keď boli obvodové rozhrania jednoduché (myslím vytáčané pripojenie), ale posilnilo to slabiny vnútorných rozhraní. Útočníci, ktorí našli dieru v obvode, často zistili, že vnútorný útočný povrch serverovej farmy bol oveľa väčší ako ten vonkajší a mohli by vnútri spôsobiť značné škody.
Tento povrch interného útoku zahŕňal sieťové pripojenia medzi servermi, ale aj interakcie medzi procesmi v rámci jedného servera. Horšie je, že keďže veľa služieb beží so zvýšenými oprávneniami (používateľ „root“), úspešné rozdelenie do jednej by skutočne znamenalo neobmedzený prístup k čomukoľvek inému v tomto systéme, bez toho, aby ste museli hľadať ďalšie chyby zabezpečenia. Celé odvetvie vyrastalo okolo ochrany serverov - brány firewall, antimalware, detekcia vniknutia a ďalšie a ďalšie - s menej ako dokonalými výsledkami.
Existujú tiež zaujímavé útoky typu „side channel“ na servery. Vedci preukázali príklady použitia spotreby energie, šumu alebo elektromagnetického žiarenia z počítačov na získanie informácií, niekedy veľmi citlivých údajov, ako sú kryptografické kľúče. Iné útoky využili odkryté rozhrania, napríklad protokoly bezdrôtovej klávesnice. Všeobecne sú však tieto útoky ťažšie - môžu vyžadovať napríklad blízkosť k serveru - takže hlavná cesta „po drôte“ je bežnejšia.
Útočná plocha VM
Keď sa virtuálne počítače používajú rovnakým spôsobom ako holý kov, bez rozdielu v architektúre aplikácie (ako to býva často), zdieľajú väčšinu rovnakých útočných bodov. Jedným ďalším povrchom útoku je potenciálne zlyhanie hypervízora, operačného systému alebo hardvéru pri správnej izolácii zdrojov medzi virtuálnymi počítačmi, čo umožňuje virtuálnemu počítaču nejako čítať pamäť iného virtuálneho počítača. Rozhranie medzi VM a hypervízorom predstavuje tiež bod útoku. Ak VM dokáže preraziť a v hypervízore spustiť ľubovoľný kód, potom môže pristupovať k ďalším VM v rovnakom systéme. Samotný hypervisor predstavuje bod útoku, pretože vystavuje rozhrania pre správu.
V závislosti od typu systému VM existujú ďalšie útočné body. Systémy VM typu 2 používajú hypervízor bežiaci ako proces na podkladovom hostiteľskom OS. Tieto systémy môžu byť napadnuté útokom na hostiteľský OS. Ak útočník dokáže spustiť kód na hostiteľskom systéme, môže to mať vplyv na hypervízora a virtuálne počítače, najmä ak môže získať prístup ako privilegovaný používateľ. Prítomnosť celého OS vrátane pomôcok, nástrojov na správu a prípadne ďalších služieb a vstupných bodov (napríklad SSH) poskytuje množstvo možných útočných bodov. Systémy VM typu 1, kde hypervisor beží priamo na základnom hardvéri, eliminujú tieto vstupné body, a preto majú menšiu útočnú plochu.
Útočná plocha kontajnera
Rovnako ako v prípade virtuálnych počítačov, kontajnery zdieľajú základné vstupné body vstupu do siete systémov s holým kovom. Okrem toho, podobne ako virtuálne stroje typu 2, aj kontajnerové systémy, ktoré používajú „plne načítaný“ hostiteľský OS, sú vystavené všetkým rovnakým útokom, ktoré sú k dispozícii proti pomocným programom a službám tohto hostiteľského OS. Ak môže útočník získať prístup k danému hostiteľovi, môže sa pokúsiť získať prístup alebo inak ovplyvniť fungujúce kontajnery. Ak získa privilegovaný („root“) prístup, útočník bude mať prístup alebo kontrolu nad akýmkoľvek kontajnerom. „Minimalistický“ OS (napríklad KurmaOS od spoločnosti Apcera) môže pomôcť znížiť tento povrch útoku, ale nemôže ho úplne eliminovať, pretože pre správu kontajnerov je potrebný určitý prístup k hostiteľskému OS.
Potenciálne útočné body ponúkajú aj základné mechanizmy oddelenia kontajnerov (menné priestory). Okrem toho nie všetky aspekty procesov v systémoch Linux majú pomenované oblasti, takže niektoré položky sú zdieľané naprieč kontajnermi. Toto sú prirodzené oblasti, ktoré majú útočníci skúmať. Napokon je rozhranie procesu k jadru (pre systémové volania) veľké a vystavené v každom kontajneri, na rozdiel od oveľa menšieho rozhrania medzi VM a hypervisorom. Zraniteľnosti systémových volaní môžu ponúknuť potenciálny prístup k jadru. Jedným z príkladov je nedávno oznámená chyba zabezpečenia v kľúčenke Linux.
Architektonické úvahy
Pre VM aj kontajnery môže byť veľkosť útočnej plochy ovplyvnená architektúrou aplikácie a tým, ako sa technológia používa.
Mnoho starších aplikácií pre virtuálne počítače zaobchádza s virtuálnymi počítačmi ako s kovom. Inými slovami, neprispôsobili svoju architektúru špeciálne pre VM alebo pre modely zabezpečenia, ktoré nie sú založené na obvodovom zabezpečení. Môžu inštalovať veľa služieb na ten istý VM, spúšťať služby s oprávneniami root a medzi službami mať len malú alebo žiadnu kontrolu zabezpečenia. Opätovná výskum týchto aplikácií (alebo pravdepodobnejšie ich nahradenie novšími) by mohol pomocou virtuálnych počítačov poskytnúť zabezpečenie medzi funkčnými jednotkami, a nie iba ako prostriedok riadenia väčšieho počtu strojov.
Kontajnery sú vhodné pre architektúry mikroslužieb, ktoré „spájajú dohromady“ veľké množstvo (zvyčajne) malých služieb pomocou štandardizovaných rozhraní API. Takéto služby majú často veľmi krátku životnosť, keď sa kontajnerová služba spustí na požiadanie, odpovie na žiadosť a zničí sa, alebo keď sa služby rýchlo zvyšujú a znižujú na základe dopytu. Tento vzor použitia závisí od rýchlej inštancie, ktorú kontajnery podporujú. Z hľadiska bezpečnosti to má výhody aj nevýhody.
Väčší počet služieb znamená väčší počet sieťových rozhraní a tým aj väčšiu útočnú plochu. Umožňuje však tiež viac ovládacích prvkov na sieťovej vrstve. Napríklad na platforme Apcera musí byť výslovne povolená všetka prevádzka z kontajnera na kontajner. Nepravý kontajner nemôže svojvoľne osloviť žiadny koncový bod siete.
Krátka životnosť kontajnera znamená, že ak sa útočník skutočne dostane dovnútra, čas, ktorý musí niečo urobiť, je obmedzený na rozdiel od možnosti, ktorú ponúka dlhodobá služba. Nevýhodou je, že súdne lekárstvo je ťažšie. Akonáhle je kontajner preč, nemožno ho sondovať a preskúmať, či sa v ňom nenachádza malware. Tieto architektúry tiež útočníkovi sťažujú inštaláciu škodlivého softvéru, ktorý prežije po zničení kontajnera, pretože by to mohol na holých kovoch nainštalovať ovládač, ktorý sa načíta pri štarte. Kontajnery sa zvyčajne načítajú z dôveryhodného úložiska iba na čítanie a dajú sa ďalej zabezpečiť kryptografickými kontrolami.
Teraz sa pozrime, čo sa stane počas porušenia.
Ochrana pred porušením
Útočníci majú zvyčajne jeden alebo dva ciele vtrhnúť do serverového systému. Chcú získať údaje alebo poškodiť.
Ak hľadajú údaje, chcú preniknúť do čo najväčšieho počtu systémov s čo najvyššími oprávneniami a udržiavať tento prístup čo najdlhšie. Dosiahnutie tohto cieľa im dáva čas na nájdenie údajov, ktoré by tam už mohli byť - napríklad slabo zabezpečená databáza - alebo by mohli vyžadovať pomalý zber v priebehu času, ako to zasekne, napríklad zhromažďovanie transakcií, keď prichádzajú od používateľov. Dlhodobé udržanie prístupu si vyžaduje utajenie. Útok si tiež vyžaduje spôsob, ako tieto údaje dostať von.
Ak sa útočník snaží jednoducho poškodiť, cieľom je znova získať prístup k čo najväčšiemu počtu systémov a privilégií. Existuje však vyrovnávací čin: akonáhle dôjde k poškodeniu, pravdepodobne si ho všimnete, ale čím dlhšie útočník čaká na spustenie (zatiaľ čo malware filtruje zo systému na systém), tým väčšia je pravdepodobnosť odhalenia. Získanie údajov je menej dôležité ako koordinovaná kontrola škodlivého softvéru. Cieľom je infikovať čo najviac systémov a potom ich poškodiť v synchronizovanom bode, buď vopred dohodnutých, alebo na príkaz.
Porušenia zahŕňajú množstvo prvkov. Pozrime sa na každú z nich a zistíme, či môžu virtuálne počítače a kontajnerované architektúry ovplyvniť útočnú plochu každého z nich.
