Beveiligingsproblemen beheren voor Azure Kubernetes Service (AKS)
Beheer van beveiligingsproblemen omvat het detecteren, beoordelen, verhelpen en rapporteren van beveiligingsproblemen die zich in de systemen en software van een organisatie voordoen. Het beheer van beveiligingsproblemen is een gedeelde verantwoordelijkheid van u en Microsoft.
In dit artikel wordt beschreven hoe Microsoft beveiligingsproblemen en beveiligingsupdates (ook wel patches genoemd) beheert voor AKS-clusters (Azure Kubernetes Service).
Hoe beveiligingsproblemen worden gedetecteerd
Microsoft identificeert en patches voor beveiligingsproblemen en ontbrekende beveiligingsupdates voor de volgende onderdelen:
AKS-containerinstallatiekopieën
Ubuntu-besturingssysteem 18.04- en 22.04-werkknooppunten: Canonical biedt Microsoft os-builds waarop alle beschikbare beveiligingsupdates zijn toegepast.
Windows Server 2022 OS Worker-knooppunten: het Windows Server-besturingssysteem wordt op de tweede dinsdag van elke maand gepatcht. SLA's moeten hetzelfde zijn als volgens hun ondersteuningscontract en ernst.
Azure Linux OS-knooppunten: Azure Linux biedt AKS met os-builds waarop alle beschikbare beveiligingsupdates zijn toegepast.
AKS-containerinstallatiekopieën
Hoewel de Cloud Native Computing Foundation (CNCF) eigenaar is van de meeste code die AKS wordt uitgevoerd, neemt Microsoft de verantwoordelijkheid voor het bouwen van de opensource-pakketten die we implementeren op AKS. Deze verantwoordelijkheid omvat het volledige eigendom van het build-, scan-, teken-, validatie- en hotfixproces, evenals controle over de binaire bestanden in containerinstallatiekopieën. Als u verantwoordelijk bent voor het bouwen van de opensource-pakketten die zijn geïmplementeerd op AKS, kunnen we een softwareleveringsketen opzetten via het binaire bestand en de software indien nodig patchen.
Microsoft is actief in het bredere Kubernetes-ecosysteem om de toekomst van cloudeigen compute in de bredere CNCF-community te bouwen. Dit werk zorgt niet alleen voor de kwaliteit van elke Kubernetes-release ter wereld, maar zorgt er ook voor dat AKS snel nieuwe Kubernetes-releases in productie krijgt. In sommige gevallen voor andere cloudproviders meerdere maanden. Microsoft werkt samen met andere branchepartners in de Kubernetes-beveiligingsorganisatie. De SRC (Security Response Committee) ontvangt bijvoorbeeld beveiligingsproblemen, geeft prioriteit en patches, voordat ze openbaar worden aangekondigd. Deze toezegging zorgt ervoor dat Kubernetes voor iedereen veilig is en zorgt ervoor dat AKS sneller beveiligingsproblemen kan patchen en erop kan reageren om onze klanten veilig te houden. Naast Kubernetes heeft Microsoft zich aangemeld voor het ontvangen van pre-releasemeldingen voor softwareproblemen voor producten zoals Envoy, containerruntimes en vele andere opensource-projecten.
Microsoft scant containerinstallatiekopieën met behulp van statische analyse om beveiligingsproblemen en ontbrekende updates in Kubernetes en door Microsoft beheerde containers te detecteren. Als er oplossingen beschikbaar zijn, begint de scanner automatisch met het update- en releaseproces.
Naast geautomatiseerd scannen detecteert en werkt Microsoft beveiligingsproblemen die onbekend zijn bij scanners op de volgende manieren op:
Microsoft voert zijn eigen controles, penetratietests en detectie van beveiligingsproblemen uit op alle AKS-platformen. Gespecialiseerde teams binnen Microsoft en vertrouwde externe beveiligingsleveranciers voeren hun eigen aanvalsonderzoek uit.
Microsoft neemt actief contact op met de community voor beveiligingsonderzoek via meerdere programma's voor beveiligingsproblemen. Een speciaal Microsoft Azure Bounty-programma biedt aanzienlijke premies voor het beste beveiligingsprobleem in de cloud dat elk jaar wordt gevonden.
Microsoft werkt samen met andere branche- en opensourcesoftwarepartners die beveiligingsproblemen, beveiligingsonderzoek en updates delen vóór de openbare release van het beveiligingsprobleem. Het doel van deze samenwerking is om grote onderdelen van de internetinfrastructuur bij te werken voordat het beveiligingsprobleem aan het publiek wordt aangekondigd. In sommige gevallen draagt Microsoft beveiligingsproblemen bij aan deze community.
De beveiligingssamenwerking van Microsoft vindt op veel niveaus plaats. Soms gebeurt het formeel via programma's waarbij organisaties zich registreren voor het ontvangen van pre-releasemeldingen over softwareproblemen voor producten zoals Kubernetes en Docker. Samenwerking vindt ook informeel plaats vanwege onze betrokkenheid bij veel opensource-projecten, zoals de Linux-kernel, containerruntimes, virtualisatietechnologie en andere.
Werkknooppunten
Linux-knooppunten
De nightly canonical OS beveiligingsupdates zijn standaard uitgeschakeld in AKS. Gebruik het unmanagedkanaal om ze expliciet in te schakelen.
Als u het unmanagedkanaal gebruikt, worden 's nachts canonieke beveiligingsupdates toegepast op het besturingssysteem op het knooppunt. De knooppuntinstallatiekopieën die worden gebruikt om knooppunten voor uw cluster te maken, blijven ongewijzigd. Als er een nieuw Linux-knooppunt aan uw cluster wordt toegevoegd, wordt de oorspronkelijke installatiekopieën gebruikt om het knooppunt te maken. Dit nieuwe knooppunt ontvangt alle beveiligingsupdates en kernelupdates die beschikbaar zijn tijdens de automatische evaluatie die elke nacht wordt uitgevoerd, maar blijft niet gepatcht totdat alle controles en opnieuw opstarten zijn voltooid. U kunt de upgrade van de knooppuntinstallatiekopieën gebruiken om te controleren op knooppuntinstallatiekopieën die door uw cluster worden gebruikt en bij te werken. Zie voor meer informatie over upgrade van knooppuntinstallatiekopieën azure Kubernetes Service (AKS)-knooppuntinstallatiekopieën.
Voor AKS-clusters die een ander kanaal gebruiken dan unmanaged, is het upgradeproces zonder toezicht uitgeschakeld.
Windows Server-knooppunten
Voor Windows Server-knooppunten wordt Windows Update niet automatisch uitgevoerd en worden de meest recente updates toegepast. Plan upgrades van Windows Server-knooppuntgroepen in uw AKS-cluster rond de normale releasecyclus van Windows Update en uw eigen updatebeheerproces. Met dit upgradeproces worden knooppunten gemaakt waarop de meest recente Windows Server-installatiekopieën en patches worden uitgevoerd, waarna de oudere knooppunten worden verwijderd. Zie Een knooppuntgroep upgraden in AKS voor meer informatie over dit proces.
Hoe beveiligingsproblemen worden geclassificeerd
Microsoft investeert grote investeringen in beveiliging door de hele stack te beveiligen, waaronder het besturingssysteem, de container, kubernetes en netwerklagen, naast het instellen van goede standaardinstellingen en het bieden van beveiligingsbeveiligingsbeveiligingsconfiguraties en beheerde onderdelen. Gecombineerd helpen deze inspanningen om de impact en de kans op beveiligingsproblemen te verminderen.
Het AKS-team classificeert beveiligingsproblemen volgens het Scoresysteem voor beveiligingsproblemen in Kubernetes. Classificaties houden rekening met veel factoren, waaronder AKS-configuratie- en beveiligingsbeveiligingsbeveiliging. Als gevolg van deze aanpak en de investeringen die AKS in beveiliging aanbrengt, kunnen AKS-classificaties voor beveiligingsproblemen verschillen van andere classificatiebronnen.
In de volgende tabel worden categorieën voor ernst van beveiligingsproblemen beschreven:
| Ernst | Beschrijving |
|---|---|
| Kritiek | Een beveiligingsprobleem dat gemakkelijk kan worden misbruikt in alle clusters door een niet-geverifieerde externe aanvaller die leidt tot volledig inbreuk op het systeem. |
| Hoog | Een beveiligingsprobleem dat eenvoudig kan worden misbruikt voor veel clusters die leiden tot verlies van vertrouwelijkheid, integriteit of beschikbaarheid. |
| Gemiddeld | Een beveiligingsprobleem dat kan worden misbruikt voor sommige clusters waarbij verlies van vertrouwelijkheid, integriteit of beschikbaarheid wordt beperkt door algemene configuraties, problemen met de exploit zelf, vereiste toegang of interactie van de gebruiker. |
| Laag | Alle andere beveiligingsproblemen. Exploitatie is onwaarschijnlijk of de gevolgen van exploitatie zijn beperkt. |
Hoe beveiligingsproblemen worden bijgewerkt
AKS patches Common Vulnerabilities and Exposures (CVE's) die elke week een oplossing van een leverancier hebben. Cv's zonder een oplossing wachten op een oplossing van een leverancier voordat ze kunnen worden hersteld. De vaste containerinstallatiekopieën worden in de cache opgeslagen in de volgende bijbehorende VHD-build (virtuele harde schijf), die ook de bijgewerkte gepatchte CV's voor Ubuntu/Azure Linux/Windows bevat. Zolang u de bijgewerkte VHD uitvoert, moet u geen CV's voor containerinstallatiekopieën uitvoeren met een leverancieroplossing die ouder is dan 30 dagen.
Voor beveiligingsproblemen op basis van het besturingssysteem in de VHD is AKS standaard ook afhankelijk van VHD-updates voor knooppuntinstallatiekopieën, zodat eventuele beveiligingsupdates worden geleverd met wekelijkse knooppuntinstallatiekopieën. Upgrades zonder toezicht zijn uitgeschakeld, tenzij u overschakelt naar onbeheerd, wat niet wordt aanbevolen omdat de release globaal is.
Tijdlijnen voor release bijwerken
Het doel van Microsoft is om gedetecteerde beveiligingsproblemen binnen een bepaalde periode te beperken die geschikt zijn voor de risico's die ze vertegenwoordigen. De Voorlopige autorisatie van Microsoft Azure FedRAMP High to Operate (P-ATO) omvat AKS in het controlebereik en is geautoriseerd. FedRAMP Continuous Monitoring Strategy Guide en de FedRAMP Low-, Moderate- en High Security Control-basislijnen vereisen herstel van bekende beveiligingsproblemen binnen een specifieke periode op basis van hun ernstniveau. Zoals opgegeven in FedRAMP RA-5d.
Hoe beveiligingsproblemen en updates worden gecommuniceerd
Over het algemeen communiceert Microsoft niet breed over de release van nieuwe patchversies voor AKS. Microsoft controleert en valideert echter voortdurend beschikbare CVE-patches om ze tijdig te ondersteunen in AKS. Als er een kritieke patch wordt gevonden of als er actie van de gebruiker is vereist, plaatst En werkt Microsoft details van het CVE-probleem bij op GitHub.
Beveiligingsrapportage
U kunt een beveiligingsprobleem melden bij het Microsoft Security Response Center (MSRC) door een beveiligingsrapport te maken.
Als u liever een rapport verzendt zonder u aan te melden bij het hulpprogramma, stuurt u een e-mail naar secure@microsoft.com. Versleutel uw bericht indien mogelijk met onze PGP-sleutel door het te downloaden van de PGP-sleutelpagina van het Microsoft Security Response Center.
U zou binnen 24 uur een reactie moeten krijgen. Als u dit om een of andere reden niet doet, volgt u een e-mail om ervoor te zorgen dat uw oorspronkelijke bericht is ontvangen. Ga naar het Microsoft Security Response Center voor meer informatie.
Neem de volgende gevraagde informatie op (zo veel mogelijk) om ons te helpen de aard en het bereik van het mogelijke probleem beter te begrijpen:
- Type probleem (bijvoorbeeld bufferoverloop, SQL-injectie, cross-site scripting, enzovoort)
- Volledige paden van bronbestand(en) gerelateerd aan het optreden van het probleem
- De locatie van de betreffende broncode (tag/branch/doorvoer- of directe URL)
- Elke speciale configuratie die nodig is om het probleem te reproduceren
- Stapsgewijze instructies voor het reproduceren van het probleem
- Proof-of-concept of aanvalscode (indien mogelijk)
- Impact van het probleem, waaronder hoe een aanvaller het probleem kan misbruiken.
Deze informatie helpt ons om uw gemelde beveiligingsprobleem sneller te classificeren.
Als u rapporteert voor een fout bounty, kunnen meer volledige rapporten bijdragen aan een hogere beloningsprijs. Zie Microsoft Bug Bounty Program voor meer informatie over onze actieve programma's.
Beleid
Microsoft volgt het principe van De openbaarmaking van gecoördineerde beveiligingsproblemen.
Volgende stappen
Zie het overzicht over het upgraden van Azure Kubernetes Service-clusters en -knooppuntgroepen.