Programmering

Er virtuelle maskiner sikrere enn containere?

Vi sier ofte "HTTPS er sikkert" eller "HTTP er ikke sikkert." Men det vi mener er at "HTTPS er vanskelig å snuse og gjør det vanskelig å angripe mennesker i midten" eller "bestemoren min har ingen problemer med å snuse HTTP."

HTTPS har likevel blitt hacket, og under noen omstendigheter er HTTP sikker nok. Videre, hvis jeg oppdager en utnyttbar feil i en felles implementering som støtter HTTPS (tenk OpenSSL og Heartbleed), kan HTTPS bli en hacking-gateway til implementeringen er korrigert.

HTTP og HTTPS er protokoller definert i IETF RFCer 7230-7237 og 2828. HTTPS ble designet som en sikker HTTP, men å si at HTTPS er sikker og HTTP er fortsatt ikke skjuler viktige unntak.

Virtuelle maskiner (VM) og containere er mindre nøye definert, og ingen av dem var med vilje designet for å være sikrere enn den andre. Derfor er sikkerhetsspørsmålene fortsatt mørkere.

Hvorfor jeg tror at virtuelle maskiner er sikrere enn containere

Divide and conquer er en vinnende strategi innen krig og programvare. Når en arkitektur deler et enkelt komplekst, vanskelig å løse sikkerhetsproblem i lettere problemer, vil resultatet i de fleste tilfeller være sikrere enn en enkelt løsning som løser alle problemene.

Beholdere er et eksempel på deling og erobring som brukes horisontalt på applikasjoner. Ved å låse hver applikasjon i sitt eget fengsel, svekker ikke svakhetene i en applikasjon applikasjoner i andre containere. VM deler og erobrer også, men de går et skritt videre isolert.

Marvin Waschke /

En feil i en fengslet applikasjon kan ikke påvirke andre applikasjoner direkte, men den fengslede applikasjonen kan bryte enkelt operativsystem (OS) som deles med andre containere og påvirke alle containere. Med et delt operativsystem kan feil når som helst i applikasjons-, beholder- og operativsystemimplementeringsstakken ugyldiggjøre sikkerheten til hele stakken og kompromittere den fysiske maskinen.

+ Også på Network World: Hva er billigere: containere eller virtuelle maskiner? +

En lagdelt arkitektur som virtualisering skiller utføringsstakken til hvert program helt ned til maskinvaren, og eliminerer muligheten for at applikasjoner forstyrrer hverandre gjennom det delte operativsystemet. I tillegg er grensesnittet mellom hver applikasjonsstabel og maskinvaren definert og begrenset for å forhindre misbruk. Dette gir en ekstra robust omkrets for å beskytte applikasjoner fra hverandre.

VM skiller operativsystemet som styrer brukeraktivitet fra hypervisoren som styrer interaksjonen mellom gjest OS og maskinvaren. VM gjest OS styrer brukeraktivitet, men ikke maskinvareinteraksjon. Det er lite sannsynlig at en feil i et program eller gjest OS vil påvirke den fysiske maskinvaren eller andre virtuelle maskiner. Når VM-gjest OS og OS som støtter en container er identiske, noe som ofte er tilfelle, vil ikke det samme sikkerhetsproblemet som kompromitterer alle andre containere som kjører på operativsystemet, fare for andre virtuelle maskiner. Dermed skiller virtuelle maskiner applikasjoner horisontalt og skiller også OS-er vertikalt fra maskinvare.

VM-overhead

Den ekstra sikkerheten til virtuelle maskiner koster. Kontrolloverføring er alltid kostbart i datasystemer, både i prosessorsykluser og andre ressurser. Utførelsesstabler lagres og tilbakestilles, det kan hende at eksterne operasjoner må settes på pause eller får lov til å fullføre, og så videre.

Skift mellom gjest OS og hypervisor koster mye og skjer ofte. Selv med spesielle kontrollinstruksjoner brent inn i prosessorbrikkene, reduserer kontrolloverføringsoverhead den totale effektiviteten til virtuelle maskiner. Er reduksjonen betydelig? Vanskelig spørsmål. Applikasjoner kan stilles inn for å redusere overhead ved å administrere kontrolloverføring, og de fleste serverprosessorer er nå designet for å effektivisere kontrolloverføring. Med andre ord avhenger betydningen av applikasjonen og serveren, men overhead kan aldri elimineres fullstendig, bare avta.

Hypervisor-sårbarheter

For å komplisere saken ytterligere, skaper lag i en VM-arkitektur et annet spekter: hypervisorfeil. Et hypervisorbrudd er et eneste feilpunkt med potensial for store konsekvenser, spesielt i offentlige skyer. Det kan tenkes at en enkelt hacker kan starte koden i en virtuell maskin som tar kontroll over applikasjoner som eies av andre offentlige skyforbrukere, og pwwn en del av en offentlig sky i en enkelt utnyttelse.

En bunnsolid arkitektur kan fremdeles ha implementeringsfeil som svekker et system vesentlig. Hypervisorbrudd blir ofte fjernet ved å hevde at de aldri vil skje: Historien forteller at hypervisorer er så enkle, så velskrevne, så nøye undersøkt at de aldri mislykkes. Et brudd på hypervisoren kan være like ødeleggende som WannaCry, men ikke bekymre deg for det. Men Heartbleed skjedde. Og OpenSSL har langt færre kodelinjer enn en hypervisor. Jeg må ut nå — den flygende grisen min vil ha mer hogwash.

Jeg vet ikke om noen betydelige brudd på hypervisoren hittil. Men en rask titt på Common Vulnerabilities and Exposures (CVE) -databasen avslører at forskere finner utnyttbare hypervisor-svakheter. Hypervisor-utviklerne og leverandørene har vært raske med å lappe sårbarheter når de oppstår. I mars 2017 ga Microsoft ut sikkerhetsbulletin MS17-008, som dokumenterte syv oppdaterte sårbarheter i Hyper-V hypervisor, alle utpekt som viktige eller kritiske.

Jeg tror fortsatt at virtuelle maskiner gir bedre sikkerhet enn containere, men vi må se på sikkerheten til VM-systemer med klare øyne. Jeg planlegger å diskutere hypervisor-svakheter nærmere i fremtiden. Også containere og virtuelle maskiner kombineres ofte. Det er mye som ikke er sagt.

$config[zx-auto] not found$config[zx-overlay] not found