Säkerhet under körning

Körningsövervakning är praxis att observera vad arbetsbelastningar faktiskt gör medan de körs i produktion, snarare än att bara analysera vad de förväntas göra utifrån sin källkod eller konfiguration. Målet är att detektera beteende som avviker från en etablerad baslinje. Ovanliga systemanrop, oväntade nätverksanslutningar, filmodifieringar i skyddade kataloger och privilegieeskaleringsförsök.

Modern körningsövervakning använder eBPF, en Linux-kärnteknik som tillåter program att köras säkert inuti kärnan och observera systemanrop, nätverkshändelser och filsystemsoperationer med minimal overhead. eBPF-baserade verktyg instrumenterar kärnan direkt, vilket innebär att de observerar all containeraktivitet på en nod utan att modifiera containerarna, injicera agenter i dem eller kräva avbildningsändringar.

Effektiv körningsövervakning kräver en etablerad beteendebaslinje. Vilka systemanrop gör den här tjänsten normalt? Vilka filer läser eller skriver den? Vilka nätverksanslutningar initierar den? Avvikelser från denna baslinje utlöser varningar. Vissa verktyg lär sig baslinjer automatiskt, andra använder manuellt definierade tillåtningsregler.

Körningsövervakning är den sista försvarslinjen mot attacker efter driftsättning. Även en container som passerade varje säkerhetsskanning, byggdes från en minimal basavbildning och driftsattes med en restriktiv säkerhetskontext kan fortfarande komprometteras om en nolldagssårbarhet upptäcks efter driftsättning. Körningsövervakning detekterar beteende efter utnyttjande.

Falco är ett öppen källkods molnbaserat körningssäkerhetsverktyg skapat av Sysdig och nu ett CNCF-avslutat projekt. Det använder en regelmotor för att detektera avvikande beteende i körande containers, Kubernetes-pods och Linux-värdar. Falco levereras med ett omfattande bibliotek av standardregler som täcker de vanligaste attackmönstren.

Falco fungerar genom att konsumera kärnhändelser via eBPF eller en kärnmodul, berika dem med Kubernetes-metadata (poddens namn, namnrymd, containeravbildning, etiketter) och matcha dem mot sin regeluppsättning. När en regel matchar genererar Falco en strukturerad varning som inkluderar all relevant kontext. Vilken container, vilken process, vilket systemanrop och vilken användare.

En kanonisk Falco-regel detekterar ett skal som skapas inuti en container. I en produktionsmiljö bör containers aldrig köra interaktiva skal, om en skalprocess visas inuti en körande container indikerar det nästan alltid antingen en angripare som uppnått kodexekvering, eller en utvecklare som har exec:at in i en container för felsökning.

Att driftsätta Falco effektivt kräver inställning. Standardregeluppsättningen genererar brus i miljöer som gör saker som Falco behandlar som misstänkt som standard (köra privilegierade containers, använda värdnätverksnamnrymden). Inställningsprocessen innebär att inaktivera regler som genererar godtagbara och förståeliga undantag och att lägga till anpassade regler för applikationsspecifika beteenden.

Körningshändelser är de individuella observationer som registreras av ett körningssäkerhetssystem. Ett systemanrop som görs av en process, en fil som öppnas eller skrivs, en nätverksanslutning som upprättas, en ny process som skapas, en användare som skapas, ett privilegium som eskaleras. Varje händelse är en datapunkt, säkerhetsvärdet kommer från att korrelera händelser över tid.

Händelser med hög signal kräver omedelbar uppmärksamhet eftersom de har få legitima förklaringar i en produktionsmiljö. Dessa inkluderar. En process som skriver till /etc/passwd, en container som skapar ett skal, en tjänst som gör DNS-frågor till nyligen sedda domäner, en process som försöker ladda en kärnmodul och en container som monterar värdfilsystemet.

Händelsevolym är en grundläggande utmaning i körningssäkerhet. En upptagen container kan generera miljontals systemanrop per sekund, men bara en liten del är säkerhetsrelevant. Körningssäkerhetsverktyg tillämpar aggressiv filtrering, kastar bort händelser som matchar säkra baslinjemönster och vidarebefordrar bara avvikande händelser för varning.

Händelser från körningssäkerhetsverktyg bör integreras med resten av säkerhetsdatapipelinen. Att korrelera en körningsvarning (ett skal som skapas i en container kl. 03:00) med en nätverksvarning (containern skapar en utgående anslutning till en okänd IP kl. 03:01) och en autentiseringslogg skapar en berättelse om angreppet som ingen enskild händelsekälla kan ge.

Kubernetes granskningsloggar registrerar varje API-förfrågan till Kubernetes kontrollplan. Vem som gjorde förfrågan, vilken resurs som nåddes, vilken operation som utfördes och vilket resultatet var. Dessa loggar är åtskilda från applikationsloggar och körningshändelseloggar, de beskriver kontrollplansaktivitet.

Kubernetes granskningspolicy definierar vilka händelser som loggas och på vilken detaljnivå. Säkerhetsrelevanta händelser (ändringar av RBAC-policyer, åtkomst till hemligheter, podskapande, ändringar av nätverkspolicyer) bör loggas på Request- eller RequestResponse-nivå för att fånga hela innehållet i vad som ändrades.

Granskningsloggar är kritiska för att detektera komprometterade tjänstkonton och insiderhot. Om ett tjänstkonto som normalt bara läser från en specifik ConfigMap plötsligt börjar lista alla hemligheter i alla namnrymder, skapa nya pods med förhöjda privilegier eller ändra ClusterRoleBindings, fångar granskningsloggen all denna aktivitet i detalj.

Granskningsloggar måste skickas utanför klustret för att vara tillförlitliga. En angripare med kluster-admin-åtkomst kan modifiera eller radera loggar i klustret. Att exportera loggar till en extern, tilläggsbar destination (en S3-bucket med Object Lock, en hanterad SIEM) säkerställer att de förblir pålitliga bevis. Lagringstider för granskningsloggar bör anpassas till incidenthantering och efterlevnadskrav.

Hälsokontroller är applikationsendpointarna som rapporterar om en arbetsbelastning fungerar korrekt. Kubernetes använder liveness-prober (som avgör om en container ska startas om), readiness-prober (som avgör om en container ska ta emot trafik) och startup-prober. Ur ett säkerhetsperspektiv tjänar hälsokontroller ytterligare syften. De kan ta bort komprometterade containers från produktionstrafik.

Liveness-prober får Kubernetes att starta om containers som är fastnade eller skadade. Om en angripares exploateringskod gör att hälsokontrollens endpoint slutar svara startar Kubernetes om containern, vilket i en oföränderlig infrastrukturmodell innebär att starta om från den ursprungliga avbildningen. Detta ger ett svagt men verkligt motståndskraft.

Readiness-prober kontrollerar trafikruttning på tjänstenivå. En container som misslyckas med sin readiness-prob tas bort från tjänstens endpoint-uppsättning och slutar ta emot nya förfrågningar. Detta begränsar skadeverkningarna medan utredning och åtgärd pågår.

Ett vanligt misstag är att implementera hälsokontrollsendpointarna som alltid returnerar HTTP 200 utan att inspektera något applikationstillstånd. En trivial liveness-prob som returnerar framgång oavsett faktisk applikationshälsa ger ingen användbar signal och fångar inte fastnade tillstånd, skadade konfigurationer eller saknade beroenden.

Varningstriage är processen att utvärdera inkommande säkerhetsvarningar, bestämma deras prioritet och besluta om lämpligt svar. I ett körningssäkerhetssammanhang innebär detta att undersöka Falco-händelser, avvikelsedetektionsfynd och granskningslogghändelser för att skilja verkliga hot från falskt positiva, och eskalera säkra signaler för omedelbar incidenthantering.

Effektiv triage kräver kontext. En varning om att ett skal skapades inuti en container betyder olika saker beroende på vilken container det är, när det hände, vilken användare eller tjänstkonto som utlöste det, och om korrelerade varningar föregick det. Säkerhetsteam som investerar i anrikad varning och korrelering minskar dramatiskt medeltiden för triage.

Varningströtthet är den primära fienden till effektiva säkerhetsoperationer. När varningsvolymer är höga och falskt positiva frekvenser är höga lär sig analytiker att ignorera varningar. Lösningen är systematisk inställning. Undertrycka kända säkra mönster, öka varningskvaliteten snarare än kvantiteten och fokusera på de säkraste signalerna.

Triage-spelböcker dokumenterar de förväntade utredningsstegen för varje varningstyp. För en Falco-varning 'skal skapas i container' kan spelboken specificera. Identifiera pod och namnrymd, kontrollera Kubernetes granskningsloggar, granska nätverksflödesloggar och ta en ögonblicksbild av containerns filsystem om den fortfarande körs. Spelböcker minskar den kognitiva belastningen under högtrycks-händelser.

Incidenthantering (IR) i molnbaserade miljöer skiljer sig från traditionell server-IR på flera grundläggande sätt. Containers är efemera. Bevis för en kompromiss kan vara borta innan en utredning börjar om containern redan har startats om eller ersatts. Infrastrukturen är programmerbar. En angripare med tillräcklig åtkomst kan dölja spår genom att radera loggar eller ta bort pods.

Bevisbevarelse är den första prioriteten när en kompromiss detekteras. Eftersom containers kan avslutas när som helst måste bevisinsamling automatiseras och utlösas omedelbart när en misstänkt händelse detekteras. Detta innebär. Att fånga containerns filsystem, exportera alla tillgängliga loggar och dokumentera Kubernetes resurstillståndet.

Inneslutning i molnbaserad IR använder plattformens kontroller snarare än nätverksbrandväggsregler. En misstänkt komprometterad pod kan isoleras genom att tillämpa en NetworkPolicy som blockerar all trafik, genom att avfärda noden eller genom att ta bort pod:en från tjänstens lastbalanserare. Dessa åtgärder kan automatiseras.

Granskning efter incidenter driver systematisk förbättring. Efter varje incident bör teamet svara på. Hur fick angriparen initial åtkomst, vilka kontroller misslyckades eller saknades, vilka kontroller lyckades begränsa skadan och vilka ändringar skulle förhindra upprepning. Svaren blir åtgärdspunkter i säkerhetsbacklogen. Denna förbättringsloop skiljer mogna säkerhetsprogram från dem som upprepade gånger reagerar på samma typer av incidenter.