Utvecklingsavdelningen behöver en ny server. Visst, det är fixat på ett kick. Du loggar in med fulla rättigheter i administrationsgränssnittet för ert virtualiseringssystem och skapar med hjälp av guide och mallar en ny server på 7 minuter och 11 sekunder.

”Han med pengarna” har koll på er effektivitet, men är nöjd eftersom tiden för utrullning av ny server gått ned med flera minuter sedan ni började med det nya virtualiseringssystemet. En nödvändighet eftersom ni numera bara är fem personer där ni tidigare var elva.

Med virtualisering har effektiviteten nått nya nivåer, men inte sällan har säkerheten svårt att hänga med. Nya rutiner för de virtuella maskinernas säkerhet är inte alltid på plats samtidigt som värdsystemen börjar användas, och det krävs nytt tänk för hur säkerheten ska byggas in i de mallar som ofta styr tillblivelsen av nya virtuella maskiner. Dessutom uppstår nya administratörsroller, och det är inte helt klart hur de rollerna ska fördelas och styras för att få maximal kontroll av säkerheten.


Tre aspekter av säkerhet
Det är viktigt att skilja på olika aspekter av säkerheten i virtuella system. Den kan delas in i tre områden: säkerhet på det underliggande virtualiseringssystemet (som operativsystem och hypervisors på värdmaskinerna), säkerheten på de virtuella maskinerna i sig, och säkerheten mellan de virtuella maskinerna eller mellan grupper av virtuella maskiner. Till de tre säkerhetsområdena hör olika typer av lösningar som tillgodoser, eller bör tillgodose, säkerheten.




I säkra virtuella nätverk sker all kommunikation mellan de virtuella maskinerna via den virtuella brandväggen – även inom samma värdmaskin. Bra virtuella brandväggar ska känna av att en virtuell maskin flyttas till en annan värdmaskin. Logiskt sett ska brandväggen spänna över alla värdmaskiner som behöver skydd för sina gästmaskiner. Observera att den virtuella brandväggen i sig är en virtuell maskin, en virtuell appliance. Kommunikationen fungerar i all enkelhet på så sätt att de virtuella maskinerna får brandväggen som sin ”default gateway”.


Vad gäller hypervisors och operativsystem skiljer sig lösningarna åt en hel del. Det finns inga säkerhetsprodukter som ska installeras direkt i Vmware ESX, medan det i fallen Windows och Hyper-V kan vara på sin plats med en säkerhetslösning direkt på operativsystemet. Orsaken till skillnaden är förstås systemens karaktär och hur stor attackyta som systemen utgör. Windows är ett generellt operativsystem, som även om det slimmas betydligt utgör en betydligt större attackyta än ESX, där attackytan hålls mycket liten.

– Designen av hypervisorn spelar en stor roll. ESXi har en design som minimerar attackvektorn mot värdmaskinen/hypervisorn eftersom den saknar ett generiskt operativsystem och endast innehåller de funktioner som behövs, säger Fredrik Rynger, områdeschef på Vmware.

Fredrik Rynger, Vmware
Fredrik Rynger, Vmware

5 måsten för säkerhet i virtuella system - enligt Vmware

1. Skydda virtuella maskiner på samma sätt som du skulle skydda dina fysiska.
2. Avaktivera funktioner som inte används.
3. Utnyttja mallar, så att säkerhetsrutinerna byggs in i stället för att bli en manuell efterhandsprocess.
4. Ge inte de virtuella maskinerna mer resurser än nödvändigt.
5. Använd rollbaserad administration så att inga administrationskonton har mer tillgång än vad som är nödvändigt.


Hit hör även den kategori säkerhetsprodukter som kanske blivit mest omtalad i dessa sammanhang på senare tid, nämligen de som använder ett api till hypervisorn och kan läsa av och kontrollera vad som händer i de virtuella maskinerna utan vara installerade lokalt. I fallet Hyper-V är det här egentligen inget nytt eftersom Windows är ett generiskt operativsystem som tillåter installation av säkerhetsprodukter. Men det är inte så enkelt. Microsoft släpper inte in främmande kod i själva Hyper-V, vilket gör systemet säkrare, enligt Ulf Alvarsson, produktchef på Microsoft. Företaget är tydligt med att säkerhetsprodukterna inte ska köras på värdmaskinen, utan på var och en av gästerna, och all kommunikation ska ske över det virtuella nätverket och inte via delat minne. Den ”parent partition” som huserar själva Hyper-V-stacken är stängd för säkerhetsleverantörerna. Ett virusskydd installerat på en Hyper-V-värdmaskin ger alltså skydd åt det mesta, utom just värdmaskinen och är med andra ord tämligen meningslöst.


Vmware bjuder in
Vmware har valt en helt annan linje. Genom api:et Vmsafe bjuder man in säkerhetsleverantörerna att ta fram produkter som går in på djupet i hypervisorn och kan läsa av minnesareor, processorinstruktioner och nätverkstrafik för varje virtuell maskin, utan att vara installerade på just den maskinen. Om det räknas som att ”bjuda in främmande kod” i systemets hjärta kan diskuteras, men man ska komma ihåg att det är en radikal skillnad mellan att ge ut ett api till ett generiskt operativsystem och att ge det till ett system med betydligt mindre attackyta. Leverantörer som Trend Micro och McAfee har hakat på och tagit fram produkter som är anpassade till Vmware ESX.




Vmwares Vmsafe är ett programmeringsgränssnitt, ett api, som ger säkerhetsleverantörerna möjligheter att skapa säkerhetssystem för virtuella system. Api:et ger säkerhetsprodukterna speciella privilegier att genomsöka processorinstruktioner, arbetsminne och nätverkstrafik på hypervisornivå. Även säkerhetssystemet i sig är en virtuell maskin – det är en vanlig missuppfattning att säkerhetsprogrammet installeras direkt på hypervisorn ESX. En mycket viktig funktion som varje säkerhetssystem bör innefatta är att kunna genomsöka såväl aktiva, startade virtuella maskiner, som inaktiva avstängda maskiner. Det enklaste sättet att attackera en virtuell maskin vore annars att infektera dess maskinfil – den kan ju inte exekvera ett virusskydd om den är avstängd.

En väsentlig detalj i sammanhanget är att de säkerhetsprodukter som använder Vmsafe inte skyddar själva hypervisorn, utan de virtuella maskinerna. ESX är tekniskt sett lika oskyddad som tidigare. Vmsafe-produkterna installeras i sig som virtuella maskiner, fast med speciella systemprivilegier som ger dem möjlighet att skydda andra virtuella maskiners minne, instruktioner och trafik. Det är en vanlig missuppfattning att säkerhetsprodukterna installeras under själva ESX-operativsystemet – så är inte fallet.

Behövs i så fall säkerhetsprodukter på gästmaskinerna? I fallet Hyper-V är svaret absolut ett ja, men enligt Fredrik Rynger på Vmware är svaret nej angående Vmware ESX.

– Vmsafe kan ”övervaka” nätverkstrafik, CPU och minne i värdmaskinen från skadlig kod.

Här kan man tänka sig att Vmware har en fördel – antivirus drar systemresurser, och att behöva använda de resurserna på i stort sett varje gäst blir ett slags slöseri jämfört med den centrala lösningen i Vmsafe. Gästerna ska i möjligaste mån koncentrera sig på sin primära uppgift, att tillhandahålla tjänsterna de levererar. Å andra sidan tar en säkerhetsprodukt som använder Vmsafe en del resurser från värdmaskinen, resurser som hade kunnat användas till en gästmaskin. Vilka skillnaderna är kan vara svårt att spekulera i, men intuitivt känns Vmsafe-lösningen mer tilltalande.



Sida 1 / 5
Föregående Nästa

Innehållsförteckning