Vi siger ofte "HTTPS er sikkert" eller "HTTP er ikke sikkert." Men hvad vi mener er, at "HTTPS er svært at snuse og gør mand-i-midten-angreb vanskelige" eller "min bedstemor har ingen problemer med at snuse HTTP."
Ikke desto mindre er HTTPS blevet hacket, og under visse omstændigheder er HTTP sikker nok. Desuden, hvis jeg opdager en udnyttelig defekt i en fælles implementering, der understøtter HTTPS (tænk OpenSSL og Heartbleed), kan HTTPS blive en hacking-gateway, indtil implementeringen er rettet.
HTTP og HTTPS er protokoller defineret i IETF RFC'er 7230-7237 og 2828. HTTPS blev designet som en sikker HTTP, men det at sige HTTPS er sikker og HTTP skjuler stadig ikke vigtige undtagelser.
Virtuelle maskiner (VM'er) og containere er mindre strengt definerede, og ingen af dem var med vilje designet til at være mere sikre end den anden. Derfor er sikkerhedsspørgsmålene stadig mørkere.
Hvorfor jeg tror, at virtuelle computere er mere sikre end containere
Opdel og erobre er en vindende strategi inden for krig og software. Når en arkitektur deler et enkelt komplekst, svært at løse sikkerhedsproblem i lettere problemer, vil resultatet i de fleste tilfælde være mere sikkert end en enkelt løsning, der løser alle problemer.
Beholdere er et eksempel på deling og erobring, der anvendes vandret på applikationer. Ved at låse hver applikation i sin egen fængsel svækker svaghederne i en applikation ikke applikationer i andre containere. VM'er deler og erobrer også, men de går et skridt videre isoleret.
Marvin Waschke /En fejl i en fængslet applikation kan ikke påvirke andre applikationer direkte, men den fængslede applikation kan bryde det enkelte operativsystem (OS), der deles med andre containere, og påvirke alle containerne. Med et delt operativsystem kan fejl på ethvert tidspunkt i applikations-, container- og OS-implementeringsstaket ugyldiggøre sikkerheden for hele stakken og kompromittere den fysiske maskine.
+ Også på Network World: Hvilket er billigere: Containere eller virtuelle maskiner? +
En lagdelt arkitektur som virtualisering adskiller udførelsesstakken for hver applikation helt ned til hardwaren, hvilket eliminerer muligheden for, at applikationer forstyrrer hinanden gennem det delte operativsystem. Derudover er grænsefladen mellem hver applikationsstak og hardwaren defineret og begrænset for at forhindre misbrug. Dette giver en ekstra robust omkreds til at beskytte applikationer fra hinanden.
VM'er adskiller operativsystemet, der styrer brugeraktivitet, fra hypervisoren, der styrer interaktionen mellem gæst OS og hardware. VM-gæst OS styrer brugeraktivitet, men ikke hardwareinteraktion. En fejl i en applikation eller gæstens OS vil sandsynligvis ikke påvirke den fysiske hardware eller andre virtuelle computere. Når VM-gæst OS og OS, der understøtter en container, er identiske, hvilket ofte er tilfældet, vil den samme sårbarhed, der kompromitterer alle andre containere, der kører på OS, ikke bringe andre VM'er i fare. Således adskiller VM'er applikationer vandret og også lodret adskiller OS'er fra hardware.
VM-overhead
Den ekstra sikkerhed for virtuelle computere kommer til at koste. Kontroloverførsel er altid dyr i computersystemer, både i processorcyklusser og andre ressourcer. Eksekveringsstakke gemmes og nulstilles, eksterne handlinger skal muligvis pauses eller tillades at udføre osv.
Skift mellem gæstesystemet og hypervisoren koster meget og sker ofte. Selv med specielle kontrolinstruktioner, der er brændt ind i processorchipsene, reducerer kontroloverførselsomkostningerne den samlede effektivitet af virtuelle computere. Er faldet signifikant? Vanskeligt spørgsmål. Applikationer kan indstilles til at reducere omkostningerne ved at styre kontroloverførsel, og de fleste serverprocessorer er nu designet til at strømline kontroloverførsel. Med andre ord afhænger betydningen af applikationen og serveren, men omkostningerne kan aldrig elimineres fuldstændigt, kun mindskes.
Hypervisor-sårbarheder
For yderligere at komplicere sager hæver et andet spøgelse ved at adskille lag i en VM-arkitektur: hypervisorfejl. En overtrædelse af hypervisor er et enkelt fejlpunkt med potentiale for store konsekvenser, især i offentlige skyer. Det kan tænkes, at en enkelt hacker kunne starte kode i en VM, der tager kontrol over applikationer, der ejes af andre offentlige skyforbrugere, og pwwn en tranche af en offentlig sky i en enkelt udnyttelse.
En bundsolid arkitektur kan stadig have implementeringsfejl, der svækker et system væsentligt. Hypervisorbrud bliver ofte fjernet ved at hævde, at de aldrig vil ske: Historien siger, at hypervisorer er så enkle, så velskrevne, så omhyggeligt undersøgt, at de aldrig fejler. Et hypervisorbrud kan være så ødelæggende som WannaCry, men bekymre dig ikke om det. Men Heartbleed skete. Og OpenSSL har langt færre linjer med kode end en hypervisor. Jeg er nødt til at gå ud nu - min flyvende gris vil have mere svin.
Jeg kender ikke nogen væsentlige overtrædelser af hypervisor til dato. Men et hurtigt kig på Common Vulnerabilities and Exposures (CVE) -databasen afslører, at forskere finder udnyttelige hypervisor-svagheder. Hypervisor-udviklerne og -leverandørerne har været hurtige til at patchere sårbarheder, når de opstår. I marts 2017 udsendte Microsoft sikkerhedsbulletin MS17-008, der dokumenterede syv patchede sårbarheder i sin Hyper-V hypervisor, alle udpeget vigtige eller kritiske.
Jeg tror stadig, at virtuelle computere giver bedre sikkerhed end containere, men vi er nødt til at se på sikkerheden ved VM-systemer med klare øjne. Jeg planlægger at diskutere hypervisor-svagheder mere detaljeret i fremtiden. Containere og VM'er kombineres også ofte. Der er meget, der endnu ikke skal siges.
