Často říkáme „HTTPS je zabezpečený“ nebo „HTTP není zabezpečený“. Ale to, co máme na mysli, je, že „HTTPS se těžko snoopuje a ztěžuje útoky typu man-in-the-middle“ nebo „moje babička nemá problémy se snoopováním HTTP.“
Přesto byl HTTPS napaden a za určitých okolností je HTTP dostatečně bezpečný. Kromě toho, pokud zjistím zneužitelnou vadu v běžné implementaci podporující HTTPS (myslím OpenSSL a Heartbleed), může se HTTPS stát hackerskou bránou, dokud nebude implementace opravena.
HTTP a HTTPS jsou protokoly definované v IETF RFC 7230-7237 a 2828. HTTPS byl navržen jako zabezpečený HTTP, ale když říká, že HTTPS je bezpečný a HTTP stále skrývá důležité výjimky.
Virtuální stroje (VM) a kontejnery jsou definovány méně důsledně a žádný z nich nebyl záměrně navržen tak, aby byl bezpečnější než ten druhý. Proto jsou bezpečnostní problémy stále temnější.
Proč se domnívám, že virtuální počítače jsou bezpečnější než kontejnery
Rozděl a panuj je vítězná strategie ve válce a softwaru. Když architektura rozdělí jeden složitý problém zabezpečení, který se dá těžko vyřešit, na jednodušší problémy, bude výsledek ve většině případů bezpečnější než jediné řešení, které řeší všechny problémy.
Kontejnery jsou příkladem rozdělení a dobývání, který se na aplikace aplikuje vodorovně. Uzamčením každé aplikace ve vlastním vězení slabiny jedné aplikace neoslabí aplikace v jiných kontejnerech. Virtuální počítače se také dělí a dobývají, ale jdou o krok dále v izolaci.
Marvin Waschke /Chyba ve vězněné aplikaci nemůže přímo ovlivnit jiné aplikace, ale vězněná aplikace může rozbít jediný operační systém (OS) sdílený s jinými kontejnery a ovlivnit všechny kontejnery. Se sdíleným operačním systémem mohou chyby v kterémkoli bodě v implementačním zásobníku aplikace, kontejneru a OS zneplatnit zabezpečení celého zásobníku a ohrozit fyzický stroj.
+ Také v síti Network: Co je levnější: Kontejnery nebo virtuální stroje? +
Vrstvená architektura, jako je virtualizace, odděluje spouštěcí zásobník každé aplikace až po hardware, čímž eliminuje možnost vzájemného ovlivňování aplikací prostřednictvím sdíleného operačního systému. Kromě toho je rozhraní mezi jednotlivými aplikačními zásobníky a hardwarem definováno a omezeno, aby se zabránilo zneužití. To poskytuje další robustní obvod pro ochranu aplikací od sebe navzájem.
Virtuální počítače oddělují operační systém, který řídí aktivitu uživatelů, od hypervisoru, který řídí interakci mezi hostujícím operačním systémem a hardwarem. Hostující OS VM řídí aktivitu uživatele, ale ne interakci hardwaru. Chyba v aplikaci nebo hostujícím OS pravděpodobně neovlivní fyzický hardware nebo jiné virtuální počítače. Pokud jsou hostující operační systém virtuálního počítače a operační systém podporující kontejner identický, což se často stává, stejná chyba zabezpečení, která ohrozí všechny ostatní kontejnery spuštěné v operačním systému, neohrozí ostatní virtuální počítače. Virtuální počítače tedy oddělují aplikace horizontálně a také vertikálně oddělují OS od hardwaru.
Režie VM
Zvláštní zabezpečení virtuálních počítačů je na úkor. Přenos řízení je ve výpočetních systémech vždy nákladný, a to jak v procesorových cyklech, tak v jiných zdrojích. Zásobníky spuštění se ukládají a resetují, externí operace bude možná nutné pozastavit nebo nechat dokončit atd.
Posuny mezi hostujícím OS a hypervisorem stojí hodně a často k nim dochází. Dokonce i se speciálními řídicími pokyny vypálenými do procesorových čipů snižuje režie přenosu řízení celkovou účinnost virtuálních počítačů. Je pokles výrazný? Těžká otázka. Aplikace lze vyladit tak, aby snižovaly režii správou přenosu řízení, a většina serverových procesorů je nyní navržena tak, aby zjednodušila přenos řízení. Jinými slovy, význam závisí na aplikaci a serveru, ale režii nelze nikdy úplně vyloučit, pouze snížit.
Zranitelnosti hypervisoru
Aby se věci ještě více zkomplikovaly, oddělování vrstev v architektuře VM vyvolává další spektrum: chyby hypervisoru. Narušení hypervisoru je jediný bod selhání s potenciálem obrovských důsledků, zejména ve veřejných cloudech. Jeden hacker by mohl spustit kód na virtuálním počítači, který by převzal kontrolu nad aplikacemi vlastněnými jinými spotřebiteli veřejného cloudu, což by v jednom zneužití vytvořilo tranši veřejného cloudu.
Skalní architektura může stále mít vady implementace, které podstatně oslabují systém. Porušení hypervisorů se často fobuje tvrzením, že k nim nikdy nedojde: Říká se, že hypervisory jsou tak jednoduché, tak dobře napsané a pečlivě prověřené, že nikdy nezklamou. Porušení hypervisoru může být stejně zničující jako WannaCry, ale nebojte se o to. Ale Heartbleed se stalo. A OpenSSL má mnohem méně řádků kódu než hypervisor. Teď musím jít ven - moje létající prase chce víc parchantů.
Doposud nevím o žádném významném porušení hypervisoru. Rychlý pohled do databáze CVE (Common Vulnerabilities and Exposures) však odhaluje, že vědci nacházejí slabiny hypervisoru, které lze zneužít. Vývojáři a prodejci hypervisorů rychle řešili chyby zabezpečení, když se vyskytnou. V březnu 2017 vydala společnost Microsoft Bulletin zabezpečení MS17-008, který ve svém hypervizoru Hyper-V dokumentoval sedm opravených chyb, které byly označeny jako důležité nebo kritické.
Stále věřím, že virtuální počítače poskytují lepší zabezpečení než kontejnery, ale musíme se na bezpečnost systémů VM dívat čistýma očima. V budoucnu plánuji podrobněji probrat slabiny hypervisoru. Také kontejnery a virtuální počítače se často kombinují. Ještě je třeba mnoho říci.
