Sårbarhetshantering för Azure Kubernetes Service (AKS)

Sårbarhetshantering innebär att identifiera, utvärdera, åtgärda och rapportera om eventuella säkerhetsrisker som finns i en organisations system och programvara. Sårbarhetshantering är ett ansvar som både du och Microsoft har.

Den här artikeln beskriver hur Microsoft hanterar säkerhetsrisker och säkerhetsuppdateringar (kallas även korrigeringar) för AKS-kluster (Azure Kubernetes Service).

Så här identifieras sårbarheter

Microsoft identifierar och korrigerar sårbarheter och saknade säkerhetsuppdateringar för följande komponenter:

• AKS containeravbildningar

• Ubuntu-operativsystem 18.04 och 22.04 arbetsnoder: Canonical ger Microsoft os-versioner som har alla tillgängliga säkerhetsuppdateringar tillämpade.

• Windows Server 2022 OS-arbetsnoder: Windows Server-operativsystemet korrigeras den andra tisdagen i varje månad. Serviceavtalen bör vara desamma som enligt deras supportavtal och allvarlighetsgrad.

• Azure Linux OS-noder: Azure Linux tillhandahåller AKS med OS-versioner som har alla tillgängliga säkerhetsuppdateringar tillämpade.

AKS containeravbildningar

Medan Cloud Native Computing Foundation (CNCF) äger och underhåller de flesta av de kod-AKS-körningar som körs, tar Microsoft ansvar för att skapa de paket med öppen källkod som vi distribuerar på AKS. Det ansvaret omfattar att ha fullständigt ägarskap för bygg-, genomsöknings-, signerings-, verifierings- och snabbkorrigeringsprocessen samt kontroll över binärfilerna i containeravbildningar. Med ansvar för att skapa paket med öppen källkod som distribueras på AKS kan vi upprätta en programvaruförsörjningskedja över binärfilen och korrigera programvaran efter behov.  

Microsoft är aktivt i det bredare Kubernetes-ekosystemet för att skapa framtiden för molnbaserad beräkning i den bredare CNCF-communityn. Det här arbetet säkerställer inte bara kvaliteten på varje Kubernetes-version för världen, utan gör det också möjligt för AKS att snabbt få ut nya Kubernetes-versioner i produktion under flera år. I vissa fall före andra molnleverantörer med flera månader. Microsoft samarbetar med andra branschpartners i Kubernetes säkerhetsorganisation. Till exempel tar SRC (Security Response Committee) emot, prioriterar och åtgärdar embargot säkerhetsrisker innan de meddelas till allmänheten. Det här åtagandet säkerställer att Kubernetes är säkert för alla och gör det möjligt för AKS att korrigera och reagera på sårbarheter snabbare för att hålla våra kunder säkra. Förutom Kubernetes har Microsoft registrerat sig för att ta emot förhandsmeddelanden om programvarusårbarheter för produkter som Envoy, containerkörningar och många andra projekt med öppen källkod.

Microsoft söker igenom containeravbildningar med statisk analys för att identifiera sårbarheter och saknade uppdateringar i Kubernetes och Microsoft-hanterade containrar. Om korrigeringar är tillgängliga startar skannern automatiskt uppdaterings- och lanseringsprocessen.

Förutom automatisk genomsökning identifierar och uppdaterar Microsoft sårbarheter som är okända för skannrar på följande sätt:

• Microsoft utför egna granskningar, intrångstester och sårbarhetsidentifiering på alla AKS-plattformar. Specialiserade team inom Microsoft och betrodda tredjepartssäkerhetsleverantörer utför sin egen attackforskning.

• Microsoft samarbetar aktivt med säkerhetsforskningscommunityn genom flera program för sårbarhetsbelöning. Ett dedikerat Microsoft Azure Bounty-program ger betydande resurser för den bästa sårbarheten i molnet som hittas varje år.

• Microsoft samarbetar med andra bransch- och programvarupartner med öppen källkod som delar sårbarheter, säkerhetsforskning och uppdateringar innan sårbarheten lanseras offentligt. Målet med det här samarbetet är att uppdatera stora delar av Internetinfrastrukturen innan sårbarheten tillkännages för allmänheten. I vissa fall bidrar Microsoft med sårbarheter som finns i den här communityn.

• Microsofts säkerhetssamarbete sker på många nivåer. Ibland sker det formellt via program där organisationer registrerar sig för att ta emot förhandsmeddelanden om programvarusårbarheter för produkter som Kubernetes och Docker. Samarbete sker också informellt på grund av vårt engagemang med många projekt med öppen källkod, till exempel Linux-kerneln, containerkörningar, virtualiseringsteknik och andra.

Arbetsnoder

Linux-noder

De nattliga kanoniska os-säkerhetsuppdateringarna är inaktiverade som standard i AKS. Använd kanalen för att aktivera dem explicit.unmanaged

Om du använder unmanaged kanalen tillämpas nattliga kanoniska säkerhetsuppdateringar på operativsystemet på noden. Nodavbildningen som används för att skapa noder för klustret förblir oförändrad. Om en ny Linux-nod läggs till i klustret används den ursprungliga avbildningen för att skapa noden. Den här nya noden tar emot alla säkerhets- och kerneluppdateringar som är tillgängliga under den automatiska utvärderingen som utförs varje natt, men förblir okopplad tills alla kontroller och omstarter har slutförts. Du kan använda nodavbildningsuppgradering för att söka efter och uppdatera nodavbildningar som används av klustret. Mer information om uppgradering av nodbild finns i Azure Kubernetes Service (AKS) nodbilduppgradering.

För AKS-kluster som använder en annan kanal än unmanagedinaktiveras den obevakade uppgraderingsprocessen.

Windows Server-noder

För Windows Server-noder körs inte Windows Update automatiskt och tillämpar de senaste uppdateringarna. Schemalägg uppgraderingar av Windows Server-nodpoolen i ditt AKS-kluster runt den vanliga Windows Update-versionscykeln och din egen uppdateringshanteringsprocess. Den här uppgraderingsprocessen skapar noder som kör den senaste Windows Server-avbildningen och korrigeringarna och sedan tar bort de äldre noderna. Mer information om den här processen finns i Uppgradera en nodpool i AKS.

Hur sårbarheter klassificeras

Microsoft gör stora investeringar i säkerhetshärdning av hela stacken, inklusive operativsystemet, containern, Kubernetes och nätverksskikten, förutom att ställa in bra standardvärden och tillhandahålla säkerhetshärdade konfigurationer och hanterade komponenter. Tillsammans bidrar dessa ansträngningar till att minska effekten och sannolikheten för sårbarheter.

AKS-teamet klassificerar sårbarheter enligt Kubernetes sårbarhetsbedömningssystem. Klassificeringar beaktar många faktorer, inklusive AKS-konfiguration och säkerhetshärdning. Som ett resultat av den här metoden och de investeringar AKS gör i säkerhet kan AKS sårbarhetsklassificeringar skilja sig från andra klassificeringskällor.

I följande tabell beskrivs allvarlighetsgradskategorier för sårbarhet:

Allvarlighetsgrad	beskrivning
Kritiskt	En sårbarhet som är lätt att utnyttja i alla kluster av en oautentiserad fjärranfallare som leder till fullständig systemkompromiss.
Högt	En sårbarhet som är lätt att utnyttja för många kluster som leder till förlust av konfidentialitet, integritet eller tillgänglighet.
Medium	En sårbarhet som kan utnyttjas för vissa kluster där förlust av konfidentialitet, integritet eller tillgänglighet begränsas av vanliga konfigurationer, svårigheter med själva exploateringen, nödvändig åtkomst eller användarinteraktion.
Låg	Alla andra säkerhetsrisker. Utnyttjandet är osannolikt eller så är följderna av utnyttjandet begränsade.

Så här uppdateras sårbarheter

AKS korrigeringar Vanliga sårbarheter och exponeringar (CVE) som har en leverantörskorrigering varje vecka. Eventuella CVE:er utan en fix väntar på en leverantörsfix innan de kan åtgärdas. De fasta containeravbildningarna cachelagras i nästa motsvarande VHD-version (virtuell hårddisk), som även innehåller uppdaterade Ubuntu/Azure Linux/Windows-korrigerade CVE:er. Så länge du kör den uppdaterade virtuella hårddisken bör du inte köra några cv:er för containeravbildningar med en leverantörskorrigering som är över 30 dagar gammal.

För de OS-baserade säkerhetsriskerna i den virtuella hårddisken förlitar sig AKS också på vhd-uppdateringar av nodavbildningar som standard, så alla säkerhetsuppdateringar kommer med veckovisa nodavbildningsversioner. Obevakade uppgraderingar inaktiveras om du inte växlar till ohanterad, vilket inte rekommenderas eftersom dess version är global.

Uppdatera släpptidslinjer

Microsofts mål är att minimera identifierade sårbarheter inom en tidsperiod som är lämplig för de risker som de utgör. Microsoft Azure FedRAMP High Provisional Authorization to Operate (P-ATO) innehåller AKS i granskningsomfånget och har auktoriserats. FedRAMP:s strategiguide för kontinuerlig övervakning och baslinjerna för fedRAMP-låg, måttlig och hög säkerhetskontroll kräver reparation av kända sårbarheter inom en viss tidsperiod enligt deras allvarlighetsgrad. Enligt beskrivningen i FedRAMP RA-5d.

Så här kommuniceras sårbarheter och uppdateringar

I allmänhet kommunicerar Microsoft inte i stort sett versionen av nya korrigeringsversioner för AKS. Microsoft övervakar och validerar dock ständigt tillgängliga CVE-korrigeringar för att stödja dem i AKS i tid. Om en kritisk korrigering hittas eller en användaråtgärd krävs, utfärdar Microsoft inlägg och uppdaterar CVE-probleminformation på GitHub.

Säkerhetsrapportering

Du kan rapportera ett säkerhetsproblem till Microsoft Security Response Center (MSRC) genom att skapa en sårbarhetsrapport.

Om du föredrar att skicka en rapport utan att logga in på verktyget skickar du e-post till secure@microsoft.com. Kryptera om möjligt ditt meddelande med vår PGP-nyckel genom att ladda ned det från PGP-nyckelsidan för Microsoft Security Response Center.

Du bör få ett svar inom 24 timmar. Om du av någon anledning inte gör det följer du upp med ett e-postmeddelande för att säkerställa att vi har fått ditt ursprungliga meddelande. Mer information finns i Microsoft Security Response Center.

Ta med följande begärda information (så mycket du kan tillhandahålla) för att hjälpa oss att bättre förstå arten och omfattningen av det möjliga problemet:

• Typ av problem (till exempel buffertspill, SQL-inmatning, skript för flera platser osv.)
• Fullständiga sökvägar för källfiler relaterade till manifestationen av problemet
• Platsen för den berörda källkoden (tagg/gren/incheckning eller direkt-URL)
• Alla särskilda konfigurationer som krävs för att återskapa problemet
• Steg-för-steg instruktioner för att återskapa problemet
• Konceptbevis eller exploateringskod (om möjligt)
• Effekten av problemet, inklusive hur en angripare kan utnyttja problemet

Den här informationen hjälper oss att sortera ditt rapporterade säkerhetsproblem snabbare.

Om du rapporterar om en bug bounty kan mer fullständiga rapporter bidra till en högre belöning. Mer information om våra aktiva program finns i Microsoft Bug Bounty Program.

Policy

Microsoft följer principen om samordnat avslöjande av säkerhetsrisker.

Nästa steg

Se översikten över uppgradering av Azure Kubernetes Service-kluster och nodpooler.