Udviklere elsker containere. De er nemme at bruge og hurtige at starte. Du kan køre mange af dem på endda simpel hardware. Startup-overhead har altid været en bane for udvikling og test, og denne omkostning stiger kun med mikrotjenestearkitekturer. Hvis en udvikler har brug for et halvt dusin tjenester, kan han let spilde en dag eller to med opsætning - konfigurering af hardware, kørsel af installatører, bekæmpelse af inkompatibilitet.
Med containere kollapser det til minutter eller sekunder og kan køres på en udviklingsarbejdsstation. De let tilgængelige arkiver med nyttige containerbilleder multiplicerer udviklerens produktivitet, ligesom open source gør, men uden besværet med at lave en build. Driftsteam har været langsommere med at vedtage containere. En af grundene er, at mange applikationer, de skal understøtte, endnu ikke er containeriserede. En anden grund er en modvilje mod at bevæge sig væk fra virtuelle computere.
For ops var skiftet fra bare metal til VM'er naturligt. Individuelle virtuelle computere ser ud og kan styres som individuelle systemer ved hjælp af de samme værktøjer og processer. Tidlige bekymringer over VM-sikkerhed blev dæmpet af den lange produktionshistorie for VM'er i mainframe-verdenen, af evnen til at anvende de samme kontroller som brugt til bare-metal-systemer, ved hardware-virtualiseringsstøtte og ved den voksende modenhed i VM-styringsværktøjer.
Mange tidlige sikkerhedsbekymringer kom ned på et spørgsmål: Var virtuelle computere så sikre som bare metal? Nu rejses lignende spørgsmål om containere. Hvor sikre er containere, og hvordan kan de sammenlignes med virtuelle computere? Bestemt hvis vi sammenligner tjenester, der kører i containere, med de samme tjenester, der kører som separate processer på det samme system, er containerversionen mere sikker. Adskillelsen tilvejebragt af Linux-navneområder og cgroups giver barrierer, der ikke findes mellem almindelige processer. Sammenligningen med VM'er er mindre tydelig. Lad os se på virtuelle computere og containere fra et sikkerhedsperspektiv.
I denne artikel vil jeg tage to forskellige tilgange til sammenligning af VM- og containersikkerhed. Den første tilgang vil være mere strukturel eller teoretisk og se på karakteristika for hver fra et sikkerhedsperspektiv. Derefter anvender jeg en mere praktisk analyse ved at se på, hvad der sker i et typisk brud, og hvordan det kan blive påvirket af container- og VM-arkitekturer.
Strukturel visning
Til den strukturelle tilgang sammenligner jeg begge systemers angrebsflade. En angrebsflade repræsenterer antallet af punkter, hvor et system kan angribes. Det er ikke nøjagtigt defineret (for eksempel som et tal), men er nyttigt til sammenligning. For en indbrudstyv har et hus med 10 døre en større angrebsflade end et hus med en dør, selvom dørene er identiske. En dør kan være ulåst; en lås kan være defekt; døre forskellige steder kan tilbyde en ubuden gæst mere privatliv osv.
I computersystemer inkluderer angrebsoverfladen alt, hvor angriberen (eller software, der handler på hans vegne) kan "berøre" målsystemet. Netværksgrænseflader, hardwareforbindelser og delte ressourcer er alle mulige angrebspunkter. Bemærk, at angrebsoverfladen ikke indebærer, at der findes en faktisk sårbarhed. Alle 10 døre er muligvis helt sikre. Men en større angrebsflade betyder flere steder at beskytte, og jo større sandsynlighed vil angriberen finde en svaghed i mindst en.
Den samlede angrebsflade afhænger af antallet af forskellige berøringspunkter og kompleksiteten af hver. Lad os se på et simpelt eksempel. Forestil dig et gammeldags system, der betjener børsnoteringer. Den har en enkelt grænseflade, en simpel seriel linje. Protokollen på denne linje er også enkel: Et aktiesymbol med fast længde, f.eks. Fem tegn, sendes til serveren, som reagerer med et tilbud på fast længde - sig 10 tegn. Der er ingen Ethernet, TCP / IP, HTTP osv. (Jeg arbejdede faktisk på sådanne systemer for længe siden i en galakse langt, langt væk.)
Angrebsoverfladen på dette system er meget lille. Angriberen kan manipulere de elektriske egenskaber ved den serielle linje, sende forkerte symboler, sende for meget data eller på anden måde ændre protokollen. Beskyttelse af systemet vil indebære implementering af passende kontroller mod disse angreb.
Forestil dig nu den samme service, men i en moderne arkitektur. Tjenesten er tilgængelig på Internettet og udsætter en RESTful API. Den elektriske side af angrebet er væk - alt, hvad der vil gøre, er at stege angriberens egen router eller switch. Men protokollen er enormt mere kompleks. Det har lag til IP, TCP, muligvis TLS og HTTP, der hver giver mulighed for en udnyttelig sårbarhed. Det moderne system har en meget større angrebsflade, selvom det stadig ser ud for angriberen som et enkelt interface-punkt.
Overflade med blåt metal
For en hacker, der ikke er fysisk til stede i datacentret, er den første angrebsoverflade netværket i serveren. Dette førte til "perimetervisningen" af sikkerhed: Beskyt indgangspunkterne i datacentret, og intet kommer ind. Hvis angriberen ikke kan komme ind, betyder det ikke noget, hvad der sker mellem systemer på indersiden. Det fungerede godt, når perimetergrænsefladerne var enkle (tænk dial-up), men fremmede svagheder på interne grænseflader. Angribere, der fandt et hul i omkredsen, ville ofte opdage, at serverfarmens interne angrebsflade var meget større end den eksterne, og de kunne gøre betydelig skade, når de først var inde.
Denne interne angrebsflade omfattede netværksforbindelser mellem servere, men også proces-til-proces-interaktioner inden for en enkelt server. Værre, da mange tjenester kører med forhøjede privilegier (“root” -bruger), ville det med succes at bryde ind i en faktisk betyde uhindret adgang til andet på det system uden at skulle lede efter yderligere sårbarheder. En hel industri voksede op omkring at beskytte servere - firewalls, antimalware, detektion af indtrængen og igen og igen - med mindre end perfekte resultater.
Der er også interessante "sidekanal" -angreb mod servere. Forskere har vist eksempler på brug af strømforbrug, støj eller elektromagnetisk stråling fra computere til at udtrække information, undertiden meget følsomme data såsom kryptografiske nøgler. Andre angreb har brugt eksponerede grænseflader som trådløse tastaturprotokoller. Generelt er disse angreb imidlertid vanskeligere - de kan f.eks. Kræve nærhed til serveren - så hovedstien for at komme "ned ad ledningen" er mere almindelig.
VM-angrebsoverflade
Når virtuelle maskiner bruges på samme måde som bare metal, uden forskel i applikationens arkitektur (som de ofte er), deler de de fleste af de samme angrebspunkter. En yderligere angrebsoverflade er mulig fejl i hypervisor, OS eller hardware til korrekt isolering af ressourcer mellem virtuelle computere, hvilket gør det muligt for en VM på en eller anden måde at læse hukommelsen på en anden VM. Interfacet mellem VM og hypervisor repræsenterer også et angrebspunkt. Hvis en VM kan bryde igennem og få vilkårlig kode kørende i hypervisoren, kan den få adgang til andre VM'er på det samme system. Hypervisoren repræsenterer selv et angrebspunkt, da den afslører ledelsesgrænseflader.
Der er yderligere angrebspunkter afhængigt af typen af VM-system. Type 2 VM-systemer bruger en hypervisor, der kører som en proces på et underliggende værts-OS. Disse systemer kan angribes ved at angribe værts-OS. Hvis angriberen kan få kode til at køre på værtssystemet, kan han potentielt påvirke hypervisoren og VM'erne, især hvis han kan få adgang som en privilegeret bruger. Tilstedeværelsen af et helt operativsystem inklusive værktøjer, styringsværktøjer og muligvis andre tjenester og indgangspunkter (såsom SSH) giver et antal mulige angrebspunkter. Type 1 VM-systemer, hvor hypervisor kører direkte på den underliggende hardware, eliminerer disse indgangspunkter og har derfor en mindre angrebsflade.
Containerangreb overflade
Som med virtuelle maskiner deler containere de grundlæggende netværksindgangsangrebspunkter i bare-metal-systemer. Desuden er containersystemer, der bruger et "fuldt indlæst" værts-OS, ligesom Type 2-virtuelle maskiner underlagt alle de samme angreb, der er tilgængelige mod hjælpeprogrammerne og tjenesterne i det værts-OS. Hvis angriberen kan få adgang til den vært, kan han prøve at få adgang til eller på anden måde påvirke de kørende containere. Hvis han får privilegeret (“root”) adgang, vil angriberen være i stand til at få adgang til eller kontrollere enhver container. Et "minimalistisk" OS (såsom Apcera's KurmaOS) kan hjælpe med at reducere denne angrebsoverflade, men kan ikke fjerne det helt, da der kræves en vis adgang til værts-OS til containeradministration.
De grundlæggende mekanismer til separering af containere (navneområder) tilbyder også potentielle angrebspunkter. Derudover er ikke alle aspekter af processer på Linux-systemer navneområdet, så nogle emner deles på tværs af containere. Dette er naturlige områder, som angribere kan undersøge. Endelig er processen til kerneinterface (til systemopkald) stor og eksponeret i hver container i modsætning til den meget mindre grænseflade mellem en VM og hypervisoren. Sårbarheder i systemopkald kan tilbyde potentiel adgang til kernen. Et eksempel på dette er den for nylig rapporterede sårbarhed i Linux-nøglering.
Arkitektoniske overvejelser
For både virtuelle maskiner og containere kan angrebsoverfladens størrelse påvirkes af applikationsarkitekturen, og hvordan teknologien bruges.
Mange ældre VM-applikationer behandler VM'er som bare metal. Med andre ord har de ikke tilpasset deres arkitekturer specifikt til VM'er eller til sikkerhedsmodeller, der ikke er baseret på perimetersikkerhed. De installerer muligvis mange tjenester på den samme virtuelle computer, kører tjenesterne med rodrettigheder og har få eller ingen sikkerhedskontrol mellem tjenesterne. Omarkitektur af disse applikationer (eller mere sandsynligt at erstatte dem med nyere) kan bruge virtuelle computere til at give sikkerhedsadskillelse mellem funktionelle enheder snarere end blot som et middel til styring af større antal maskiner.
Containere er velegnede til mikrotjenestearkitekturer, der "strækker sammen" et stort antal (typisk) små tjenester ved hjælp af standardiserede API'er. Sådanne tjenester har ofte en meget kort levetid, hvor en containertjeneste startes efter behov, svarer på en anmodning og ødelægges, eller hvor tjenester hurtigt rampes op og ned baseret på efterspørgsel. Dette brugsmønster afhænger af den hurtige instantiering, som containere understøtter. Fra et sikkerhedsperspektiv har det både fordele og ulemper.
Det større antal tjenester betyder et større antal netværksgrænseflader og dermed en større angrebsflade. Det giver dog også mulighed for flere kontroller på netværkslaget. For eksempel skal al container-til-container-trafik i Apcera-platformen være eksplicit tilladt. En useriøs container kan ikke vilkårligt nå ud til ethvert netværksendepunkt.
Kort containerlevetid betyder, at hvis en angriber kommer ind, er den tid, han skal gøre noget, begrænset i modsætning til det mulighedsvindue, som en langvarig tjeneste giver. Ulempen er, at retsmedicin er sværere. Når beholderen er væk, kan den ikke sonderes og undersøges for at finde malware. Disse arkitekturer gør det også sværere for en hacker at installere malware, der overlever efter ødelæggelse af containere, da han måske på blottet metal ved at installere en driver, der indlæses ved opstart. Containere indlæses normalt fra et pålideligt, skrivebeskyttet arkiv, og de kan sikres yderligere ved kryptografisk kontrol.
Lad os nu overveje, hvad der foregår under en overtrædelse.
Beskyttelse mod overtrædelser
Angribere har typisk et eller to mål med at knække ind i et serversystem. De ønsker at få data eller gøre skade.
Hvis de er på udkig efter data, vil de infiltrere så mange systemer som muligt med de højest mulige privilegier og opretholde denne adgang så længe som muligt. At opnå dette giver dem tid til at finde de data, der måske allerede er der - for eksempel en dårligt sikret database - eller måske kræve langsom indsamling over tid, når de siver ind, såsom at indsamle transaktioner, når de kommer ind fra brugerne. Opretholdelse af adgang i lang tid kræver stealth. Angrebet kræver også en måde at få dataene ud.
Hvis angriberen blot forsøger at gøre skade, er målet igen at få adgang til så mange systemer og privilegier som muligt. Men der er en afbalanceringshandling: Når skaden starter, bemærkes det sandsynligvis, men jo længere angriberen venter på at starte (mens malware filtrerer fra system til system), jo større er chancen for at blive opdaget. At få data ud er mindre vigtigt end koordineret kontrol med malware. Ideen er at inficere så mange systemer som muligt og derefter beskadige dem på et synkroniseret punkt, enten forudbestemt eller på kommando.
Overtrædelser involverer en række elementer. Lad os se på hver og se, om virtuelle computere og containeriserede arkitekturer kan påvirke angrebsoverfladen for hver.
