Containersäkerhet handlar om att skydda images, körmiljö, nätverk och åtkomst genom hela livscykeln. Ett bra första steg är att använda betrodda basimages, ge minsta möjliga behörighet och skanna kontinuerligt.
Säkerheten behöver fungera både när en image byggs och när containern redan körs. Det räcker alltså inte att bara kontrollera koden vid ett tillfälle.
Rätt arbetssätt beror på plattform, ansvarsfördelning och vilka data verksamheten hanterar. Här är ett praktiskt sätt att strukturera arbetet.
Vad containersäkerhet omfattar
Containersäkerhet omfattar hela kedjan från källkod och bygge till register, driftsättning och löpande drift. Målet är att minska sannolikheten för intrång och begränsa skadan om en container, en identitet eller en komponent ändå komprometteras. Kontrollerna behöver därför hänga ihop i stället för att ligga som enstaka punktinsatser.
Skydd av image, register och byggkedja
En containerimage kan innehålla kända sårbarheter i både operativsystemspaket och applikationens beroenden. Välj därför betrodda basimages och håll reda på vilka komponenter som följer med i bygget. Images bör skannas före driftsättning, men också efter publicering eftersom nya sårbarheter kan upptäckas senare.
Registret och byggkedjan behöver också skyddas mot oönskade ändringar. Begränsa vem som får publicera och använda images, och använd policykontroller för att stoppa artefakter som inte uppfyller organisationens krav. Signerade artefakter kan ge bättre spårbarhet kring vad som faktiskt har byggts och godkänts.
Skydd under körning och i nätverket
När containern körs blir konfiguration, åtkomst och kommunikation centrala frågor. En container ska bara få de rättigheter den behöver för sin uppgift. Begränsad nätverkskommunikation minskar också ytan för angrepp och gör det lättare att se trafik som avviker från det normala.
Loggning och övervakning behövs för att upptäcka misstänkta händelser och förstå vad som har hänt. Exakt utformning beror på exempelvis containerplattform, molnleverantör och orkestreringsmiljö.
Vanliga risker i containerbaserade miljöer
Sårbara beroenden och osäkra basimages
En image kan vara liten men ändå innehålla många paket och beroenden. Om basimagen inte är betrodd, eller om beroenden är kända som sårbara, kan risken följa med hela vägen till produktion. Ett vanligt misstag är att skanna en image vid bygge och sedan betrakta den som säker för all framtid.
Hantera detta som ett löpande arbete: identifiera berörda images, bedöm var de används och uppdatera när det behövs. Prioriteringen bör utgå från verksamhetens egen risknivå, dataklasser och interna policyer.
För breda behörigheter och exponerade hemligheter
För breda behörigheter ökar konsekvenserna om ett konto eller en container tas över. Principen om minsta privilegium innebär att åtkomst ska begränsas till det som krävs för den aktuella uppgiften. Samma tanke gäller åtkomst till register, driftmiljö och administrativa funktioner.
Lösenord, API-nycklar och andra hemligheter bör inte byggas in i images eller lagras i källkod. De behöver i stället hanteras på ett sätt som passar organisationens plattform och policy. Kontrollera också att hemligheter inte råkar hamna i byggloggar eller andra loggar.
Bygg in säkerhet i utvecklingsflödet
Skanning, policykontroller och signerade artefakter
Skanning fungerar bäst när den är en naturlig del av flödet, inte ett sent manuellt steg. Kontrollera images före driftsättning och fortsätt att skanna dem löpande. Då går det att fånga upp nya kända sårbarheter även när imageinnehållet inte har ändrats.
Policykontroller kan användas för att ställa tydliga krav på vilka images och konfigurationer som får gå vidare. Signerade artefakter bidrar till spårbarhet i byggkedjan. Vilka kontroller som ska vara blockerande och vilka som ska leda till uppföljning behöver avgöras utifrån verksamhetens risk och ansvarsfördelning.
Säker konfiguration före driftsättning
Granska konfigurationen innan en workload sätts i drift. Kontrollera särskilt behörigheter, åtkomst till hemligheter och vilken nätverkskommunikation som verkligen behövs. Många risker uppstår inte i själva applikationskoden, utan i en konfiguration som ger mer åtkomst än avsett.
Det är också klokt att tydliggöra vem som ansvarar för respektive kontroll. Fördelningen mellan utveckling och drift ser olika ut i olika organisationer och bör vara dokumenterad.
| Område | Praktiskt fokus | Varför det spelar roll |
|---|---|---|
| Image | Betrodda basimages och återkommande skanning | Kända sårbarheter kan finnas i paket och beroenden. |
| Åtkomst | Minsta privilegium | Begränsar konsekvenserna vid kompromettering. |
| Hemligheter | Inte i image eller källkod | Minskar risken att känsliga uppgifter exponeras. |
| Drift | Loggar, övervakning och nätverksbegränsning | Underlättar upptäckt och begränsning av incidenter. |
Säkra driftmiljön steg för steg
Åtkomstkontroll, segmentering och uppdateringar
Börja med att kartlägga vilka identiteter, tjänster och containers som behöver åtkomst till vad. Minska därefter onödiga rättigheter. Begränsa nätverkskommunikationen så att tjänster bara kan prata med de delar de behöver för sin funktion.
Följ även upp images som redan används. Nya sårbarheter kan bli kända efter publicering, vilket gör återkommande skanning och planerade uppdateringar viktiga. Hur uppdateringar ska testas och införas beror på den aktuella miljön.
Loggar, larm och incidenthantering
Loggar och övervakning ger underlag för att upptäcka avvikande beteenden. Larm bör kopplas till en tydlig hantering, så att någon kan bedöma händelsen och vid behov begränsa påverkan. Begränsad kommunikation mellan tjänster kan samtidigt göra en incident mer hanterbar.
Incidenthantering bör omfatta både tekniska och organisatoriska delar: vem undersöker, vem fattar beslut och hur återställning sker. Detaljerna behöver anpassas till interna policyer, gällande regelverk och den data som behandlas.
Prioritera åtgärder efter verksamhetens risk
Alla miljöer har inte samma förutsättningar. Börja därför med de risker som kan få störst konsekvenser för den egna verksamheten. Plattform, leverantör, dataklasser och befintliga kontroller behöver vägas in innan krav och rutiner fastställs.
En enkel checklista för första förbättringarna
Kontrollera att basimages är betrodda och att images skannas både före driftsättning och löpande. Gå igenom behörigheter enligt principen om minsta privilegium. Säkerställ att hemligheter inte finns i images eller källkod. Begränsa onödig nätverkskommunikation och se till att relevanta loggar samt övervakning finns på plats. Avsluta med att klargöra ansvar mellan utveckling och drift.
Avslutning
Containersäkerhet blir mer hanterbar när arbetet delas upp mellan bygge, driftsättning och löpande drift. Betrodda images, återkommande skanning och begränsade behörigheter ger en stabil grund. Hemligheter, nätverkskommunikation och övervakning behöver sedan hanteras med samma omsorg. Anpassa prioriteringen efter den egna riskbilden och följ upp kontrollerna över tid.
Information som är bra att känna till
1. En skannad image kan få nya kända sårbarheter efter publicering. 2. Minsta privilegium gäller både containers och användarkonton. 3. Hemligheter hör inte hemma i källkod eller containerimages. 4. Nätverksbegränsning och loggning kompletterar varandra vid incidenter.
Viktiga punkter i korthet
Skydda hela containerlivscykeln, inte bara applikationskoden. Skanna images kontinuerligt, begränsa behörigheter och nätverksåtkomst, håll hemligheter utanför images och källkod samt använd loggar och övervakning för att kunna upptäcka och begränsa incidenter.
Vanliga frågor
Q1. Vad är containersäkerhet?
A1. Containersäkerhet är arbetet med att skydda containerimages, byggkedjan, register, körmiljö, nätverk och åtkomst under hela livscykeln. Det omfattar bland annat sårbarhetsskanning, hantering av hemligheter, begränsade behörigheter och övervakning.
Q2. Hur minskar man risken med sårbara containerimages?
A2. Använd betrodda basimages och skanna images före driftsättning. Fortsätt sedan med löpande skanning, eftersom nya sårbarheter kan upptäckas efter att imagen har publicerats. Prioritera åtgärder utifrån var imagen används och verksamhetens riskbedömning.
Q3. Vilka säkerhetsåtgärder behövs för Kubernetes?
A3. För Kubernetes bör man bland annat tillämpa minsta privilegium, granska konfigurationer före driftsättning, begränsa nätverkskommunikation, hantera hemligheter utanför images och källkod samt använda loggning och övervakning. Den exakta utformningen beror på miljö, policyer och ansvarsfördelning.
