Správa ohrožení zabezpečení pro službu Azure Kubernetes Service (AKS)

  • Článek

Správa ohrožení zabezpečení zahrnuje zjišťování, vyhodnocování, zmírňování a reportování všech ohrožení zabezpečení, která existují v systémech a softwaru organizace. Správa ohrožení zabezpečení je sdílená odpovědnost mezi vámi a Microsoftem.

Tento článek popisuje, jak Microsoft spravuje ohrožení zabezpečení a aktualizace zabezpečení (označované také jako opravy) pro clustery Azure Kubernetes Service (AKS).

Zjištění ohrožení zabezpečení

Společnost Microsoft identifikuje ohrožení zabezpečení a opravy a chybějící aktualizace zabezpečení pro následující komponenty:

  • Image kontejnerů AKS

  • Operační systém Ubuntu 18.04 a 22.04 pracovních uzlů: Canonical poskytuje Společnosti Microsoft buildy operačního systému, které mají všechny dostupné aktualizace zabezpečení.

  • Pracovní uzly operačního systému Windows Server 2022: Operační systém Windows Server je opravený ve druhém úterý každého měsíce. Smlouvy SLA by měly být stejné jako u smlouvy o podpoře a závažnosti.

  • Uzly operačního systému Azure Linux: Azure Linux poskytuje AKS se sestaveními operačního systému, které mají všechny dostupné aktualizace zabezpečení.

Image kontejnerů AKS

I když Cloud Native Computing Foundation (CNCF) vlastní a udržuje většinu kódu AKS, Microsoft zodpovídá za vytváření opensourcových balíčků, které nasazujeme v AKS. Tato odpovědnost zahrnuje úplné vlastnictví sestavení, skenování, podepisování, ověřování a opravy hotfix a také kontrolu nad binárními soubory v imagích kontejnerů. Odpovědnost za vytváření opensourcových balíčků nasazených v AKS nám umožňuje vytvořit softwarový dodavatelský řetězec přes binární soubor a podle potřeby software opravit.  

Microsoft je aktivní v širším ekosystému Kubernetes, který pomáhá vytvářet budoucnost výpočetních prostředků nativních pro cloud v širší komunitě CNCF. Tato práce nejen zajišťuje kvalitu každé verze Kubernetes pro celý svět, ale také umožňuje AKS rychle dostat nové verze Kubernetes do produkčního prostředí několik let. V některých případech před ostatními poskytovateli cloudu několik měsíců. Microsoft spolupracuje s dalšími oborovými partnery v organizaci zabezpečení Kubernetes. Výbor SRC (Security Response Committee) například přijímá, upřednostňuje a opravuje ohrožení zabezpečení před oznámením veřejnosti. Tento závazek zajišťuje zabezpečení Kubernetes pro všechny uživatele a umožňuje AKS rychleji opravovat a reagovat na ohrožení zabezpečení, aby naši zákazníci byli v bezpečí. Kromě Kubernetes se Společnost Microsoft zaregistrovala, aby dostávala oznámení o ohroženích zabezpečení softwaru pro produkty, jako jsou envoy, moduly runtime kontejnerů a mnoho dalších opensourcových projektů.

Microsoft prohledá image kontejnerů pomocí statické analýzy ke zjištění ohrožení zabezpečení a chybějících aktualizací v kontejnerech Kubernetes a spravovaných Microsoftem. Pokud jsou k dispozici opravy, skener automaticky zahájí proces aktualizace a vydání.

Kromě automatizované kontroly Microsoft zjistí a aktualizuje chyby zabezpečení, které skenery nezná, následujícími způsoby:

  • Microsoft provádí vlastní audity, penetrační testování a zjišťování ohrožení zabezpečení na všech platformách AKS. Specializované týmy v Microsoftu a důvěryhodní dodavatelé zabezpečení třetích stran provádějí vlastní výzkum útoků.

  • Microsoft aktivně spolupracuje s komunitou výzkumu zabezpečení prostřednictvím několika programů odměňování ohrožení zabezpečení. Vyhrazený program Microsoft Azure Bounty poskytuje významné odměny za nejlepší ohrožení zabezpečení cloudu zjištěné každý rok.

  • Microsoft spolupracuje s jinými oborovými a opensourcovými softwarovými partnery, kteří sdílejí ohrožení zabezpečení, výzkum zabezpečení a aktualizace před veřejným vydáním tohoto ohrožení zabezpečení. Cílem této spolupráce je aktualizovat velké části internetové infrastruktury před oznámením ohrožení zabezpečení veřejnosti. V některých případech Microsoft přispívá k ohrožením zabezpečení nalezená v této komunitě.

  • Spolupráce Microsoftu na zabezpečení probíhá na mnoha úrovních. Někdy k němu dojde formálně prostřednictvím programů, ve kterých se organizace zaregistrují, aby dostávaly oznámení o ohroženích zabezpečení softwaru pro produkty, jako jsou Kubernetes a Docker. Spolupráce také probíhá neformálně kvůli našemu zapojení do mnoha opensourcových projektů, jako je jádro Linuxu, moduly runtime kontejnerů, virtualizační technologie a další.

Pracovní uzly

Uzly Linuxu

Noční kanonické aktualizace zabezpečení operačního systému jsou ve výchozím nastavení v AKS vypnuté. Pokud je chcete explicitně povolit, použijte unmanagedkanál.

Pokud používáte unmanagedkanál, pak se na operační systém na uzlu použijí noční kanonické aktualizace zabezpečení. Image uzlu použitá k vytvoření uzlů pro váš cluster zůstane beze změny. Pokud do clusteru přidáte nový linuxový uzel, použije se k vytvoření uzlu původní image. Tento nový uzel obdrží všechny aktualizace zabezpečení a jádra dostupné během automatického hodnocení prováděného každou noc, ale zůstane nepatchovaný, dokud nebudou dokončeny všechny kontroly a restartování. Upgrade image uzlu můžete použít ke kontrole a aktualizaci imagí uzlů používaných clusterem. Další informace o upgradu image uzlu najdete v tématu Upgrade image uzlu Azure Kubernetes Service (AKS).

U clusterů AKS, které používají jiný kanál než unmanaged, je proces bezobslužného upgradu zakázán.

Uzly Windows Serveru

U uzlů Windows Serveru se služba Windows Update nespustí automaticky a nainstaluje nejnovější aktualizace. Naplánujte upgrady fondu uzlů Windows Serveru v clusteru AKS kolem běžného cyklu vydávání verzí služba Windows Update a vlastního procesu správy aktualizací. Tento proces upgradu vytvoří uzly, na kterých běží nejnovější image a opravy Windows Serveru, a pak odebere starší uzly. Další informace o tomto procesu najdete v tématu Upgrade fondu uzlů v AKS.

Jak se klasifikují ohrožení zabezpečení

Microsoft kromě nastavení vhodných výchozích hodnot a poskytování konfigurací a spravovaných komponent zajišťuje velké investice do posílení zabezpečení celého zásobníku, včetně operačního systému, kontejneru, Kubernetes a síťových vrstev. Tyto snahy společně pomáhají snížit dopad a pravděpodobnost ohrožení zabezpečení.

Tým AKS klasifikuje ohrožení zabezpečení podle systému vyhodnocování ohrožení zabezpečení Kubernetes. Klasifikace berou v úvahu řadu faktorů, včetně konfigurace AKS a posílení zabezpečení. V důsledku tohoto přístupu se investice AKS v oblasti zabezpečení mohou klasifikace ohrožení zabezpečení AKS lišit od jiných zdrojů klasifikace.

Následující tabulka popisuje kategorie závažnosti ohrožení zabezpečení:

Závažnost Popis
Kritické Ohrožení zabezpečení snadno zneužitelné ve všech clusterech neověřeným vzdáleným útočníkem, které vede k úplnému ohrožení systému.
Nejvyšší Ohrožení zabezpečení snadno zneužitelné pro mnoho clusterů, které vede ke ztrátě důvěrnosti, integrity nebo dostupnosti.
střední Ohrožení zabezpečení zneužitelné pro některé clustery, u kterých je ztráta důvěrnosti, integrity nebo dostupnosti omezená běžnými konfiguracemi, potížemi samotného zneužití, požadovaným přístupem nebo interakcí uživatele.
Nejnižší Všechna ostatní ohrožení zabezpečení. Zneužití je nepravděpodobné nebo důsledky zneužití jsou omezené.

Jak se aktualizují ohrožení zabezpečení

AKS opravuje běžná ohrožení zabezpečení a ohrožení zabezpečení (CVE), které mají opravu dodavatele každý týden. Všechny cve bez opravy čekají na opravu dodavatele, než je možné je opravit. Pevné image kontejnerů se ukládají do mezipaměti v dalším odpovídajícím buildu virtuálního pevného disku (VHD), který obsahuje také aktualizované prostředí CVEs s opravami Ubuntu, Azure Linuxu nebo Windows. Pokud používáte aktualizovaný virtuální pevný disk, neměli byste spouštět žádné cve image kontejneru s opravou dodavatele, která je starší než 30 dnů.

V případě ohrožení zabezpečení na základě operačního systému ve virtuálním pevného disku spoléhá AKS ve výchozím nastavení také na aktualizace image uzlu vhd, takže všechny aktualizace zabezpečení budou součástí týdenních vydaných imagí uzlů. Bezobslužné upgrady jsou zakázány, pokud nepřepnete na nespravované, což se nedoporučuje, protože jeho vydání je globální.

Aktualizace časových os vydání

Cílem Společnosti Microsoft je zmírnit zjištěná ohrožení zabezpečení během časového období vhodného pro rizika, která představují. Vysoká prozatímní autorizace Microsoft Azure FedRAMP pro provoz (P-ATO) zahrnuje AKS v rozsahu auditu a má autorizaci. Průvodce strategií průběžného monitorování FedRAMP a standardní hodnoty FedRAMP Low, Moderate a High Security Control vyžadují nápravu známých ohrožení zabezpečení v určitém časovém období podle jejich úrovně závažnosti. Jak je uvedeno v protokolu RA-5d FedRAMP.

Způsob komunikace ohrožení zabezpečení a aktualizací

Microsoft obecně nesděluje obecně vydání nových verzí oprav pro AKS. Microsoft ale neustále monitoruje a ověřuje dostupné opravy CVE, aby je podporovaly v AKS včas. Pokud je nalezena kritická oprava nebo je vyžadována akce uživatele, Microsoft publikuje a aktualizuje podrobnosti o problému CVE na GitHubu.

Vytváření sestav zabezpečení

Problém se zabezpečením můžete nahlásit službě Microsoft Security Response Center (MSRC) vytvořením sestavy ohrožení zabezpečení.

Pokud chcete odeslat sestavu bez přihlášení k nástroji, odešlete e-mail na secure@microsoft.comadresu . Pokud je to možné, zašifrujte zprávu pomocí našeho klíče PGP tak, že ji stáhnete ze stránky klíče PGP centra Zabezpečení Response Center.

Odpověď byste měli obdržet do 24 hodin. Pokud z nějakého důvodu ne, postupujte podle e-mailu a ujistěte se, že jsme dostali vaši původní zprávu. Další informace najdete v centru Microsoft Security Response Center.

Uveďte následující požadované informace (co nejvíce, co můžete poskytnout), které nám pomůžou lépe porozumět povaze a rozsahu možného problému:

  • Typ problému (například přetečení vyrovnávací paměti, injektáž SQL, skriptování mezi weby atd.)
  • Úplné cesty ke zdrojovým souborům souvisejícím s projevem problému.
  • Umístění dotčeného zdrojového kódu (značka/větev/zapsání nebo přímá adresa URL).
  • Jakákoli speciální konfigurace potřebná k reprodukci problému
  • Podrobné pokyny k reprodukci problému
  • Testování konceptu nebo zneužití kódu (pokud je to možné)
  • Dopad problému, včetně toho, jak by útočník mohl problém zneužít.

Tyto informace nám pomůžou rychleji určit prioritu nahlášených problémů se zabezpečením.

Pokud hlásíte zprávu o bounty chyby, mohou podrobnější sestavy přispět k vyšší odměně. Další informace o našich aktivních programech naleznete v programu Microsoft Bug Bounty Program.

Zásada

Společnost Microsoft se řídí principem koordinovaného zveřejňování chyb zabezpečení.

Další kroky

Podívejte se na přehled upgradu clusterů a fondů uzlů Azure Kubernetes Service.