Behållare finns överallt: Hur säkrar du dem?

Containers ökar i antal varje dag och verkar finnas överallt, eftersom organisationer är angelägna om att dra nytta av de många fördelarna som de erbjuder, såsom agil applikationsutveckling och distribution på alla plattformar.

Många tror också att användning av behållare kan hjälpa dem att minimera säkerhetsbegränsningar på grund av deras korta livslängd. Är detta sant eller bara en annan missuppfattning?

Även om containrar inte har inneboende osäkerheter, distribueras de ofta på ett icke-säkert sätt, vilket resulterar i många säkerhetsutmaningar.

Säkerhetsutmaningar vid distribution av containrar

Det stora antalet, mångsidigheten och det tillfälliga tillståndet för utplacerade containrar plus det faktum att containrar måste kommunicera med andra enheter, leder till att organisationer inte har förmågan att äga adekvat trafiksynlighet mellan containers.

Tack vare denna brist på synlighet glöms containrar ofta bort, och intrångsförebyggande åtgärder och säkerhetskontroller blir ineffektiva, vilket ökar attackytan och därmed den övergripande affärsrisken. Dessutom kan bristen på synlighet resultera i en brist på ansvar eftersom containrar tvärs över olika miljöer från utveckling till produktion.

En annan säkerhetsutmaning relaterad till containrar är dålig sårbarhetshantering. Till exempel, när man klonar befintliga bilder för att skapa nya behållare, kommer deras sårbarheter också att replikeras.

Detta understryker nödvändigheten av att säkerheten är en integrerad del av organisationens containerstrategi. Annars kan konfigurationsfel och saknade patchar vara orsaken till att obehöriga bilder distribueras och exekveras i produktionsmiljöer, vilket leder till ökad attackyta och mer framgångsrika attacker.

Slutligen, eftersom behållare använder en delad OS-kärna, kan en kompromiss av värd-OS-kärnan av en oseriös behållare leda till förlust av åtkomst till alla eller alla körande behållare på värden, på samma sätt som andra värdar i nätverket.

Hur du säkrar dina containrar

Kanske den bästa praxisen för att säkra din containermiljö är att erkänna nödvändigheten av att göra det. Förutom detta grundläggande koncept finns det några goda råd att följa för att effektivt säkra dina containrar.

Ha insyn i dina containrar

Innan du distribuerar en behållare, se till att du förstår dess beroenden och vad som ingår i den. För att säkerställa att dina behållarbilder är orörda måste du få synlighet i alla steg från utveckling till produktion.

Att inte lita på en containers programvara är en bra utgångspunkt. Du måste kontrollera det mycket noggrant för att förstå "var de kommer ifrån, hur de producerades och deras motsvarande källor", som Dirk Hohndel, vicepresident på VMware, påpekade vid 2019 års Open Source Leadership Summit.

I ett nötskal, dubbelkolla innehållet i dina containrar innan du distribuerar dem och kör aldrig en container med okänd eller föråldrad programvara. Bara för att en containerbild påstår sig innehålla de senaste och bästa programmen och biblioteken, betyder det inte att den faktiskt gör det.

Ett sätt att lindra detta problem är att använda program som kan hjälpa dig att rensa upp dina behållare. Även om jag inte gillar att uppfinna hjulet på nytt, kanske det bästa sättet är att sluta använda andras containerbilder.

Om du, precis som Hercules, tar den svårare vägen med Virtue och börjar bygga dina egna containerbilder, kommer du att få en mycket bättre förståelse för vad som händer i containrarna, vilket har fördelar utöver säkerheten.

Kontrollera root-åtkomst

De flesta behållare är byggda med root-åtkomst som standard. Detta är dock en tveksam praxis. Även om det är lättare för utvecklare att köra behållare som root, finns det enorma risker med root-åtkomst.

Det finns flera sätt att hantera denna fråga. Ett sätt är att fastställa en företagspolicy att inga containrar någonsin får köra som root. Ett alternativt sätt är att utöva minsta privilegieprincipen. Du kan ange en icke-rootanvändare i Dockerfilen, när du skapar en containeravbildning, för att köra containern som den specifika användaren med minsta nödvändiga systemåtkomst.

Slutligen kan du också använda användarnamnutrymme när du kör privilegierade containerprocesser för att hjälpa säkra containrar. Med den här metoden är UID:t för att köra dessa processer inom behållaren noll (vilket är roten), men utanför behållaren är UID:et den oprivilegierade 1000.

Kontrollera behållarens körtid

National Institute of Standards and Technologys (NIST) SP 800-190 " Application Container Security Guide " påpekar att containerkörningstider också är sårbara för attacker. Även om detta inte är en vanlig säkerhetslucka, påpekar NIST att säkerhetssårbarheter i containerruntime kan vara " särskilt farliga ", om de tillåter scenarier där skadlig programvara kan attackera resurser i andra containrar och själva värdoperativsystemet.

En angripare kan också kunna utnyttja sårbarheter för att äventyra själva runtime-programvaran och sedan ändra den programvaran så att den tillåter angriparen att komma åt andra behållare, övervaka behållare-till-behållare-kommunikation, etc.

Säkerhetsproblem är mycket vanligare med runtime-konfigurationer. Behållarkörningstider avslöjar vanligtvis många konfigurerbara alternativ. Felaktig inställning av dem kan sänka systemets relativa säkerhet.

Till exempel, på Linux-containervärdar, är uppsättningen av tillåtna systemanrop ofta begränsad som standard till endast de som krävs för säker drift av containrar. Om den här listan utökas kan den utsätta behållare och värdoperativsystemet för ökad risk från en komprometterad behållare.

På liknande sätt, om en behållare körs i privilegierat läge, har den åtkomst till alla enheter på värden, vilket gör att den i huvudsak fungerar som en del av värdoperativsystemet och påverkar alla andra behållare som körs på den.

Ett annat exempel på en osäker körtidskonfiguration är att tillåta behållare att montera känsliga kataloger på värden. Om en komprometterad behållare kan göra ändringar i dessa sökvägar, kan den användas för att höja privilegier och attackera själva värden såväl som andra behållare som körs på värden.

Hårda operativsystemet

NIST rekommenderar också att köra ett containerspecifikt operativsystem eftersom hoten vanligtvis är mer minimala eftersom operativsystemen är specifikt utformade för att vara värd för containrar och har andra tjänster och funktionalitet inaktiverade.

Dessutom, eftersom dessa optimerade operativsystem är utformade specifikt för att vara värd för containrar, har de vanligtvis skrivskyddade filsystem och använder andra härdningsmetoder som standard. När det är möjligt bör organisationer använda dessa minimalistiska operativsystem för att minska sina attackytor och minska de typiska riskerna och hårdnande aktiviteterna som är förknippade med operativsystem för allmänna ändamål.

Organisationer som inte kan använda ett containerspecifikt operativsystem bör följa riktlinjerna i NIST SP 800-123, Guide to General Server Security för att minska attackytan för sina värdar så mycket som möjligt.

Till exempel bör värdar som kör behållare endast köra behållare och inte köra andra appar, som en webbserver eller databas, utanför behållare. Värd-OS bör inte köra onödiga systemtjänster, såsom en utskriftsspooler, som ökar dess attackyta.

Slutligen bör värdar kontinuerligt genomsökas efter sårbarheter och uppdateringar tillämpas snabbt, inte bara på behållarens körtid utan också på komponenter på lägre nivå, såsom kärnan som behållare förlitar sig på för säker, fackindelad drift.

Containersäkerhet har högsta prioritet

Med fler och fler företag som antar och distribuerar containrar, blir deras säkerhet en högsta prioritet för företaget. Enligt en färsk undersökning har 94 % av de tillfrågade upplevt en säkerhetsincident i sina containermiljöer. Detta belyser bara hur viktigt det är att få behållarsäkerhetsrättigheter för att skydda ditt företag och dina kunder.