Sdílet prostřednictvím

Zabezpečení DevOps

Zabezpečení DevOps integruje postupy zabezpečení v průběhu životního cyklu vývoje softwaru (SDLC) od počátečního návrhu a kódování prostřednictvím sestavení, testování a nasazení do produkčního prostředí. Na rozdíl od tradičních přístupů zabezpečení, které považují zabezpečení za konečnou bránu, vkládají zabezpečení DevOps kontrolní mechanismy zabezpečení, automatizované testování a průběžné monitorování do každé fáze vývojového kanálu. Tento přístup rozpoznává, že moderní doručování softwaru spoléhá na složité kanály CI/CD, závislosti třetích stran, infrastrukturu jako kód a automatizovaná nasazení, přičemž každá představuje potenciální vektory útoku, které nežádoucí osoby aktivně zneužívají. Použitím principů nulové důvěryhodnosti (předpokládat porušení zabezpečení, explicitně ověřit) a hloubkových strategií ochrany zajišťuje zabezpečení DevOps, že kód, závislosti, konfigurace infrastruktury a procesy kanálů zůstanou důvěryhodné a odolné vůči návrhu prostřednictvím produkčního prostředí. Bez komplexního zabezpečení DevOps čelí organizace kritickým rizikům, včetně útoků dodavatelského řetězce, vystavení přihlašovacích údajů v kanálech, injektáže škodlivého kódu, ohrožených imagí kontejnerů a neoprávněných změn infrastruktury, které můžou navázat trvalé zadní vrátky ovlivňující všechny podřízené uživatele.

Tady jsou tři základní pilíře domény zabezpečení DevOps Security.

Zabezpečení návrhu a dodavatelského řetězce: Nejdříve proveďte modelování strukturovaných hrozeb. Chraňte dodavatelský řetězec pomocí kontroly závislostí a licencí, správy zranitelností a generování SBOM (Software Bill of Materials). Ověřte původ a integritu všech součástí.

Související ovládací prvky:

Posunout doleva ovládací prvky zabezpečení: Posunete ovládací prvky zabezpečení doleva integrací SAST, kontroly tajných údajů, kontroly IaC a DAST do kanálu CI/CD. Centralizovaná správa tajných kódů (např. Key Vault), omezení autority pro změnu kanálu a nepřetržitá kontrola a zabezpečení artefaktů (jako jsou image kontejnerů a virtuálních počítačů) před nasazením.

Související ovládací prvky:

Monitorování a audit aktivit DevOps: Shromážděte a předávat protokoly auditu a zabezpečení DevOps do centrální analytické platformy pro korelaci a reakci. Detekujte neoprávněné změny datového toku, eskalace oprávnění, anomální potvrzení a provádění mimo pracovní dobu.

Související ovládací prvky:

DS-1: Modelování hrozeb

Princip zabezpečení

Implementujte systematické modelování hrozeb pomocí metodologie STRIDE během fáze návrhu, abyste identifikovali potenciální bezpečnostní hrozby, určili prioritu rizik a implementovali vhodná zmírnění rizik před zahájením vývoje kódu. Tento přístup s posunem doleva snižuje náklady na nápravu a zlepšuje celkový stav zabezpečení.

Riziko ke zmírnění

Organizace, které během fáze návrhu neprovádí modelování hrozeb, pracují s kritickými slepými místy, které nežádoucí uživatelé systematicky zneužívají. Bez systematické analýzy hrozeb:

  • Opožděné chyby architektury: Vložené zranitelnosti návrhu vyžadují nákladné refaktorování v produkčním prostředí, přičemž náklady na nápravu jsou výrazně vyšší než řešení problému během fáze návrhu.
  • Neidentifikované prostory útoku: Vektory hrozeb, jako jsou nezabezpečené hranice důvěryhodnosti, chybějící požadavky na ověřování nebo nedostatečná ochrana toku dat, zůstanou nezadokumentované, což útočníkům umožňuje zneužít známé slabiny, které defenderi nerozpoznají.
  • Nedostatečná bezpečnostní opatření: Chybějící nebo nedostatečné kontrolní mechanismy zabezpečení (šifrování, ověřování, autorizace, protokolování auditu) jsou výsledkem neúplné analýzy hrozeb, což vytváří zneužitelné mezery ve strategii hloubkové ochrany.
  • Slepá místa dodržování předpisů: Zákonné požadavky (PCI-DSS, HIPAA, SOX) pro ověřování zabezpečeného návrhu nelze splnit bez zdokumentovaných modelů hrozeb a důkazů pro zmírnění rizik.
  • Akumulace bezpečnostního dluhu: Neustálé přidávání funkcí bez modelování hrozeb vytváří rostoucí bezpečnostní technický dluh, což činí systémy postupně zranitelnějšími a obtížněji zabezpečitelnými zpětně.

Nedostatek modelování hrozeb zvyšuje pravděpodobnost porušení zabezpečení, prodlužuje dobu trvání a zvyšuje náklady na nápravu oproti včasnému zmírnění rizik ve fázi návrhu.

MITRE ATT&CK

  • Počáteční přístup (TA0001): Zneužít veřejně přístupnou aplikaci (T1190) využívající architektonické nedostatky v ověřování, správě relací nebo ověřování vstupu, které by modelování hrozeb identifikovalo.
  • Eskalace oprávnění (TA0004): Zneužití mechanismu řízení zvýšení oprávnění (T1548) zneužívající nedostatečné oddělení oprávnění nebo chybějící kontroly autorizace v systémové architektuře.
  • Obrana před únikem (TA0005): narušení obrany (T1562) využívající chybějící protokolování auditu, mezery v monitorování nebo nedostatečné bezpečnostní telemetrie, které jsou navrženy do systému.

DS-1.1: Implementace modelování hrozeb na základě STRIDE

Systematický modelování hrozeb během fáze návrhu poskytuje základ pro zabezpečenou softwarovou architekturu tím, že identifikuje ohrožení zabezpečení před zahájením vývoje. Řešení bezpečnostních otázek ve fázi návrhu dramaticky snižuje náklady na nápravu a zabraňuje, aby se architektonické chyby stávaly součástí produkčních systémů. Raná identifikace hrozeb zajišťuje, že bezpečnostní prvky jsou integrované v architektuře, nikoli později.

Při vytváření modelování hrozeb implementujte následující strukturovaný přístup:

  • Stanovit systematickou metodologii STRIDE: Vytvořte systematické modelování hrozeb jako povinnou činnost ve fázi návrhu pomocí metodologie STRIDE (falšování identity, manipulace, repudice, zpřístupnění informací, odepření služby, zvýšení oprávnění). Začněte vytvořením diagramů toku dat (DFD), které mapují systémové komponenty, toky dat, hranice důvěryhodnosti a externí závislosti. Pro každou komponentu a tok dat systematicky vyhodnocujte potenciální hrozby ve všech šesti kategoriích STRIDE, určete prioritu rizik na základě pravděpodobnosti a dopadu a před zahájením vývoje zdokumentujte konkrétní zmírnění rizik.

  • Použití nástrojů pro modelování strukturovaných hrozeb: Pomocí nástrojů pro modelování strukturovaných hrozeb, jako je nástroj Microsoft Threat Modeling Tool , můžete udržovat konzistenci a využívat předem připravené šablony pro běžné vzory architektury (webové aplikace, rozhraní API, mikroslužby, řešení IoT). Nástroj usnadňuje vytváření DFD, automatizovanou identifikaci hrozeb na základě typů komponent a toků dat a generuje doporučení pro zmírnění rizik s přidruženými bezpečnostními prvky. Modely hrozeb můžete ukládat jako artefakty s verzemi ve správě zdrojového kódu společně s dokumentací k architektuře.

  • Integrace do vývojových pracovních postupů: Integrujte výstupy modelování hrozeb přímo do pracovních postupů vývoje exportem identifikovaných hrozeb do pracovních položek Azure DevOps s jasnými kritérii pro vlastnictví, prioritu a přijetí. Implementujte brány pro kontrolu architektury, které vyžadují dokončené modely hrozeb před schválením návrhu, a zřizujte kontroly žádostí o přijetí změn, které spouštějí kontroly modelu hrozeb při zjištění změn v architektuře. Tím se zajistí, že analýza hrozeb zůstane synchronizovaná s vývojem systému v průběhu životního cyklu vývoje.

DS-1.2: Automatizace integrace analýzy hrozeb

Škálování modelování hrozeb napříč velkými organizacemi vyžaduje automatizaci a distribuovanou funkci, aby se zabránilo kritickým bodům vývoje kontrol zabezpečení. Automatizované pracovní postupy identifikace hrozeb vložené do procesů zahájení projektu a žádostí o přijetí změn zajišťují konzistentní analýzu zabezpečení bez ručního zásahu pro každý projekt. Vytváření odborných znalostí zabezpečení v rámci vývojových týmů prostřednictvím programů pro povolení vytváří udržitelné a škálovatelné postupy modelování hrozeb.

Implementujte tyto funkce automatizace a umožnění:

  • Škálování prostřednictvím automatizace a povolení: Škálování modelování hrozeb napříč organizací prostřednictvím automatizace a povolení Vkládejte bezpečnostní dotazníky do šablon pro zahájení projektu, které automaticky vyhodnocují úroveň rizika, určují požadavky na modelování hrozeb a přiřazují příslušné kontrolní body kontroly zabezpečení na základě klasifikace dat, externí expozice a regulačního rozsahu. Automatizujte spouštěče revize architektury v pracovních postupech žádostí o přijetí změn, které detekují změny hranic systému, toků ověřování nebo logiky zpracování dat, a směrujte takové změny k architektům zabezpečení pro validaci modelu hrozeb.

  • Vytváření distribuovaných funkcí pomocí šampionů zabezpečení: Vytvořte program Security Champions pro vytváření možností modelování distribuovaných hrozeb v rámci vývojových týmů. Proškolte šampiony v metodologii STRIDE, poskytněte jim nástroje a šablony pro modelování hrozeb a umožněte jim usnadnit sezení modelování hrozeb pro své týmy. Šampioni zabezpečení slouží jako první řádek kontroly a eskalují složité scénáře centralizovaným týmům zabezpečení a zároveň umožňují, aby se většina modelování hrozeb vyskytla bez kritických bodů.

Implementace automatizované analýzy hrozeb:

  • Hodnocení na základě dotazníků: Standardizované bezpečnostní dotazníky integrované do šablon Azure DevOps pro konzistentní identifikaci hrozeb
  • Program šampionů zabezpečení: Určení šampionů zabezpečení v každém vývojovém týmu vytrénovaného na usnadnění modelování hrozeb
  • Automatizace kontroly architektury: Automatizované kontroly v žádostech o přijetí změn pro aktualizace diagramu architektury vyžadující kontroly modelů hrozeb
  • Model hrozeb jako kód: Definice modelu hrozeb řízené verzí pomocí strukturovaných formátů (JSON/YAML) umožňujících automatizovanou analýzu

Příklad implementace

Organizace finančních služeb utrpěla porušení zabezpečení dat, když útočníci zneužili chybu autorizace v rozhraní API pro platby, která nebyla nikdy identifikována během vývoje, což vedlo k významným podvodným transakcím a regulačním pokutám.

Výzva: Architektura mikroslužeb s mnoha nasazenými rozhraními API bez kontroly zabezpečení Vývojové týmy nemají odborné znalosti zabezpečení k identifikaci hrozeb. Problémy se zabezpečením architektury zjištěné až po produkčních incidentech

Přístup řešení:

  • Modelování hrozeb STRIDE: Implementovali jsme nástroj Microsoft Threat Modeling pro všechny mikroslužby a koncové body rozhraní API s diagramy toku dat zobrazující architekturu a citlivé toky dat.
  • Program šampionů zabezpečení: Vytrénované zprostředkovatele modelování hrozeb v každém vývojovém týmu umožňujícím návrh zabezpečení bez kritických bodů centrálního bezpečnostního týmu.
  • Automatizovaná integrace pracovního postupu: Kontroly modelu hrozeb integrované do pracovních postupů žádostí o přijetí změn v Azure DevOps, které vyžadují schválení z hlediska zabezpečení pro architektonické změny.

Výsledek: Identifikovali jsme řadu problémů se zabezpečením před nasazením, které brání potenciálním porušením zabezpečení. Podstatně se snížila ohrožení zabezpečení v produkčním prostředí. Kontroly zabezpečení přidaly do vývojového cyklu minimální dobu.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

  • NIST SP 800-53 Rev.5: SA-11, SA-15, PL-8, RA-3, RA-5
  • PCI-DSS v4: 6.3.1, 6.3.2, 12.3.1
  • Kontroly CIS v8.1: 14.2, 14.3
  • NIST CSF v2.0: ID.RA-3, PR. IP-2
  • ISO 27001:2022: A.5.12, A.8.25
  • SOC 2: CC3.2, CC7.1

DS-2: Zabezpečení softwarového dodavatelského řetězce

Princip zabezpečení

Implementujte nulovou důvěryhodnost závislostí ověřením původu, integrity a stavu zabezpečení všech komponent třetích stran před integrací. Nepřetržitě kontrolovat závislosti na ohroženích zabezpečení, udržovat komplexní softwarovou fakturu materiálů (SBOM) a vynucovat automatizované aktualizace zabezpečení, aby se minimalizoval prostor pro útoky na dodavatelský řetězec.

Riziko ke zmírnění

Útoky na dodavatelský řetězec softwaru představují kritické hrozby, protože nežádoucí osoby využívají vztahy důvěryhodnosti mezi organizacemi a komponentami třetích stran, aby se dosáhlo rozsáhlého dopadu s minimálním úsilím. Bez komplexního zabezpečení dodavatelského řetězce:

  • Škodlivé závislosti: Útočníci vkládají backdoory do oblíbených open-sourceových knihoven (útoky ve stylu SolarWinds) nebo vytvářejí typosquattové balíčky, které spouští škodlivý kód během instalace nebo běhu programu.
  • Ohrožené knihovny třetích stran: Známé identifikátory CVE v závislostech (Log4Shell, Heartbleed, Struts) zůstávají týdny nebo měsíce neaktualizované kvůli nedostatku viditelnosti a automatizovaného řízení zranitelností.
  • Ohrožené artefakty sestavení: Útočníci manipulují s kompilovanými binárními soubory, imagemi kontejnerů nebo balíčky nasazení během skladování nebo přenosu, čímž do nich vloží malware, který obchází kontrolu zdrojového kódu.
  • Útoky na záměny závislostí: Aktéři se zlými úmysly nahrávají balíčky do veřejných úložišť s názvy odpovídajícími interním privátním balíčkům a využívají logiku řešení správce balíčků k nahrazení vlastního kódu škodlivým.
  • Přechodná rizika závislostí: Ohrožení zabezpečení v nepřímých závislostech (závislostech závislostí) zůstávají neviditelná bez hloubkové analýzy stromu závislostí a generování SBOM.
  • Nedostatek ověření provenience: Absence kryptografického ověřování umožňuje útoky na nahrazení balíčků, u kterých jsou legitimní balíčky nahrazeny škodlivými verzemi.

Kompromitace dodavatelského řetězce umožňuje rozsáhlý dopad, trvalá zadní vrátka v důvěryhodných knihovnách a vysokou odolnost při odhalování díky legitimnímu vzhledu.

MITRE ATT&CK

  • Počáteční přístup (TA0001): Ohrožení dodavatelského řetězce (T1195.001) prostřednictvím ohrožení softwarových závislostí a vývojových nástrojů za účelem získání počátečního zápatí v cílových prostředích a důvěryhodného vztahu (T1199) zneužívající důvěru mezi organizacemi a dodavateli softwaru třetích stran k poskytování škodlivých aktualizací.
  • Spouštění (TA0002): interpret příkazů a skriptování (T1059) spouštějící škodlivý kód vložený do instalačních skriptů závislostí nebo po instalaci háků.
  • Trvalost (TA0003): kompromitace binárního kódu klientského softwaru (T1554) vkládáním zadních vrátek do kompilovaných knihoven, které přetrvávají i po aktualizacích aplikací.

DS-2.1: Implementace kontroly a správy závislostí

Komplexní správa zabezpečení závislostí zabraňuje útokům dodavatelského řetězce tím, že udržuje přehled o všech komponentách třetích stran, nepřetržitě monitoruje ohrožení zabezpečení a automatizuje procesy nápravy. Moderní aplikace spoléhají na stovky nebo tisíce závislostí (přímé a tranzitivní), což znemožňuje ruční posouzení zabezpečení a vytváří rozsáhlý prostor pro útoky prostřednictvím ohrožených knihoven. Automatizované prohledávání závislostí s průběžným monitorováním zajišťuje, že organizace před zneužitím detekuje a opravují ohrožení zabezpečení.

Zajištění nepřetržitého zabezpečení závislostí prostřednictvím těchto základních funkcí:

  • Zajištění komplexní viditelnosti a generování SBOM: Vytvořte nepřetržitou správu zabezpečení závislostí se třemi základními funkcemi: komplexní viditelnost, automatizovaná detekce ohrožení zabezpečení a proaktivní náprava. Začněte generováním kompletních inventářů závislostí, které mapují přímé závislosti (explicitně deklarované v manifestech balíčků) a tranzitivní závislosti (závislosti závislostí) ve všech úložištích. Udržujte softwarové vyúčtování materiálů (SBOM) ve standardních formátech (SPDX, CykloneDX) pro dodržování právních předpisů a připravenost reakce na incidenty.

  • Implementace automatizovaného skenování zranitelností a jejich náprav: Implementujte automatizované skenování zranitelností, které nepřetržitě monitoruje závislosti vůči Národní databázi zranitelností (NVD), Databázi GitHub Advisory a jazykově specifickým bezpečnostním doporučením. Nastavte upozorňování v reálném čase, když jsou zveřejněny nové CVE, které ovlivňují vaše úložiště závislostí, se směrováním podle jejich závažnosti na příslušné týmy. Povolte automatizované aktualizace zabezpečení, které vytvářejí pull requesty s upgrady verzí závislostí, zahrnující testování kompatibility a inteligentní řešení konfliktů při slučování, což snižuje zátěž spojenou s ručním řešením problémů.

  • Integrace ověřování zabezpečení do vývojových pracovních postupů: Integrujte ověřování zabezpečení závislostí přímo do vývojových pracovních postupů prostřednictvím kontrol žádostí o přijetí změn, které automaticky vyhodnocují dopad změn závislostí na zabezpečení a označují nové závislosti se známými ohroženími, problémy s dodržováním licencí nebo podezřelými charakteristikami (jako je překlepována jména a nedostatek reputace udržovatelů). Vytvořte schvalovací brány pro změny vysoce rizikových závislostí a vynucujte zásady zakazující závislosti s kritickými ohroženími zabezpečení při slučování do chráněných větví.

  • Rozšiřte viditelnost do produkčních prostředí: Rozšiřte viditelnost nad rámec zdrojového kódu do nasazených prostředí pomocí nástrojů, jako je Microsoft Defender for Cloud DevOps Security , abyste korelovaly závislosti kódu se spuštěnými úlohami, identifikujte cesty útoku prostřednictvím řetězů závislostí a upřednostnit nápravu na základě skutečné produkční expozice, a ne pouze teoretická rizika. Nástroje, jako je GitHub Advanced Security , poskytují komplexní vizualizaci grafů závislostí, automatizované aktualizace řízené dependabotem a podporu vlastních vzorců ohrožení zabezpečení pro vlastní ekosystémy balíčků.

Příklad implementace

Zdravotnická organizace zjistila škodlivý balíček npm v produkční aplikaci, který exfiltroval data pacientů po dobu několika měsíců. Šetření odhalilo rozsáhlé zranitelné závislosti se známými CVE, včetně kritické zranitelnosti Log4Shell.

Výzva: Tisíce závislostí ve stovkách úložišť bez přehledu o ohroženích zabezpečení nebo škodlivých balíčcích. Ruční kontroly závislostí vyžadovaly týdny práce na každou aplikaci. Regulační audit identifikoval kritické mezery v dodavatelském řetězci.

Přístup řešení:

  • Automatizovaná správa ohrožení zabezpečení:Pokročilé zabezpečení GitHub bylo povoleno s nástrojem Dependabot, který prozkoumává závislosti a automaticky vytváří pull requesty pro aktualizace zabezpečení.
  • Transparentnost dodavatelského řetězce: Implementovali jsme nástroj Microsoft SBOM , který generuje softwarové vyúčtování materiálů ve formátu SPDX pro dodržování právních předpisů a reakce na incidenty.
  • Ověření balíčku: Nakonfigurované Azure Artifacts s ověřováním podpisů a připnutím závislostí brání konfuzním útokům a neoprávněným nahrazováním balíčků.
  • Monitorování zabezpečení DevOps: Nasadili jsme Microsoft Defender for Cloud DevOps Security pro sledovatelnost kódu do cloudu.

Výsledek: Rychle zjištěny a opravovány rozsáhlé ohrožené závislosti. Zabránilo několika škodlivým incidentům balíčků prostřednictvím automatizovaného ověření. Bylo dosaženo souladu s předpisy s komplexní dokumentací SBOM.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

  • NIST SP 800-53 Rev.5: SR-3, SR-4, SR-6, SA-12, SA-15(9), RA-5
  • PCI-DSS v4: 6.2.4, 6.3.2, 6.3.3
  • Kontroly CIS v8.1: 16.1, 16.2, 16.11
  • NIST CSF v2.0: ID.SC-2, ID.SC-4, DE.CM-8
  • ISO 27001:2022: A.5.19, A.5.22, A.5.23
  • SOC 2: CC3.2, CC8.1

DS-3: Zabezpečení infrastruktury DevOps

Princip zabezpečení

Implementujte hloubkovou ochranu pro infrastrukturu sestavení prostřednictvím komplexního řízení tajných informací, řízení přístupu k potrubí se schvalovacími branami, konfigurace zabezpečeného agenta sestavení a průběžného monitorování. Eliminujte pevně zakódované přihlašovací údaje a vynucujte přístup s nejnižšími oprávněními k ochraně integrity procesu vývoje a nasazení softwaru.

Riziko ke zmírnění

Nezabezpečená infrastruktura DevOps vytváří kritická ohrožení zabezpečení, která nežádoucí osoba zneužívají k ohrožení celého řetězce doručování softwaru. Bez komplexního zabezpečení infrastruktury:

  • Ohrožené kanály CI/CD: Útočníci získají přístup ke kanálům buildu prostřednictvím odcizených přihlašovacích údajů, zneužití ohrožení zabezpečení nebo přístupu insider, povolení injektáže kódu, manipulace s artefakty nebo manipulace s nasazením, která ovlivní všechny podřízené uživatele.
  • Vystavené tajné kódy v protokolech sestavení a artefaktech: Pevně zakódované přihlašovací údaje, klíče rozhraní API, certifikáty a připojovací řetězce unikají prostřednictvím protokolů zpracování, chybových zpráv nebo kompilovaných artefaktů, čímž poskytují útočníkům přímý přístup k produkčním prostředím.
  • Neoprávněné úpravy kanálu: Nedostatek pracovních postupů řízení změn a schvalování umožňuje škodlivým subjektům upravovat definice kanálu, vkládat škodlivé kroky sestavení nebo měnit konfigurace nasazení bez detekce.
  • Nedostatečné řízení přístupu: Nadměrně permisivní přiřazení rolí a nedostatek oddělení povinností umožňují laterální přesun, eskalaci oprávnění a trvalé zřízení přístupu v rámci infrastruktury DevOps.
  • Nezabezpečené agenty sestavení: Nepatchované, chybně nakonfigurované nebo ohrožené agenty sestavení poskytují útočníkům trvalý přístup k prostředí sestavení a potenciálním bodům pivotu do produkčních sítí.
  • Chybějící záznamy auditu: Nedostatečné protokolování a monitorování aktivit DevOps brání detekci neoprávněného přístupu, podezřelých úprav nebo vnitřních hrozeb.

Ohrožení infrastruktury umožňuje útočníkům vkládat kód na zdroj, obejít důvěryhodné kanály a ovlivnit všechny podřízené aplikace.

MITRE ATT&CK

  • Počáteční přístup (TA0001): platné účty (T1078) využívající odcizené přihlašovací údaje nebo tajné údaje hlavní služby pro přístup k platformám a pipelinám DevOps.
  • Trvalost (TA0003): Manipulace s účtem (T1098) vytváří instanční objekty backdooru, osobní přístupové tokeny nebo klíče SSH pro udržovaný přístup.
  • Přístup k přihlašovacím údajům (TA0006):: Nezabezpečené přihlašovací údaje (T1552.001) zjistují tajné kódy z protokolů kanálu, proměnných prostředí nebo konfiguračních souborů.
  • Obcházení obrany (TA0005): poškození obrany (T1562) zablokování kroků kontroly zabezpečení, protokolování auditu nebo schvalovacích bran v definicích kanálového potrubí.

DS-3.1: Implementace správy tajných kódů pro kanály

Centralizovaná správa tajných kódů eliminuje vystavení přihlašovacích údajů v kanálech DevOps odebráním pevně zakódovaných tajných kódů z kódu, konfiguračních souborů a definic kanálů. Přihlašovací údaje vložené do YAML kanálu, proměnných prostředí nebo zdrojových úložišť představují primární vektor útoku pro ohrožení kanálu a umožňují útočníkům získat přístup k úložištím nebo protokolům k extrakci produkčních přihlašovacích údajů. Implementace kryptograficky chráněného úložiště tajných kódů s dynamickým způsobem načítání a vzory přístupu za běhu brání krádeži přihlašovacích údajů při zachování provozní efektivity.

Konfigurace správy tajných kódů pomocí těchto bezpečnostních prvků:

  • Odstranění pevně zakódovaných přihlašovacích údajů s centralizovaným úložištěm: Eliminujte pevně zakódované přihlašovací údaje z definic kanálů a zdrojového kódu tím, že centralizujete všechny tajné kódy ve vyhrazené infrastruktuře správy tajných kódů pomocí kryptografických řízení přístupu a komplexních tras auditu. Nastavte princip, že tajné kódy nesmí být nikdy uloženy v souborech YAML kanálu, proměnných prostředí viditelných v protokolech nebo konfiguračních souborech v úložištích– to jsou primární vektory pro vystavení přihlašovacích údajů v prostředích DevOps.

  • Konfigurace dynamického načítání tajných kódů se spravovanými identitami: Implementujte centralizované úložiště tajných kódů pomocí řešení, jako je Azure Key Vault , které poskytují šifrované úložiště tajných kódů, podrobné zásady přístupu, automatickou obměnu tajných kódů a komplexní protokolování auditu. Nakonfigurujte kanály tak, aby dynamicky načítaly tajné kódy za běhu prostřednictvím připojení zabezpečených služeb, a ne jejich vkládání do definic kanálů. Pomocí spravovaných identit nebo federace identit úloh ověřte přístup kanálu k úložištím tajných kódů a eliminujte potřebu dlouhodobých přihlašovacích údajů instančního objektu, které se samy stanou cíli pro krádež.

  • Vynucování přístupu právě včas pomocí schvalovacích bran: Vynucujte vzory přístupu k tajným heslům právě včas, kde se hesla načítají pouze v případě potřeby, s automatickým odvoláním po dokončení zpracovatelského toku, aby se minimalizovalo vystavení přihlašovacích údajů během jejich platnosti. Implementujte omezení přístupu vázaná na čas a pro přístup k produkčním tajným kódům vyžadují autorizaci více osob (schvalovací brány), čímž se zajistí, že k citlivým přihlašovacím údajům bez dalšího ověření nebude mít přístup žádný ohrožený účet.

  • Vytvoření řízení přístupu k infrastruktuře ve vrstvách: Vytvoření vrstvených řízení přístupu pro DevOps infrastrukturu: Omezení práv k úpravám kanálů na pracovníky s kontrolovaným zabezpečením, vynucení oprávnění specifických pro prostředí, které vyžadují schválení pro produkční nasazení, implementace omezení připojení služby na úrovni úložišť brání kanálům v přístupu k tajným datům mimo jejich zamýšlený rozsah a nasazení zodolněných místně hostovaných agentů sestavení s izolací sítě pro citlivé úlohy. Integrujte skenování zabezpečení infrastruktury jako kódu do potrubí, abyste zabránili nasazení chybně nakonfigurovaných prostředků, které by mohly vystavit citlivé informace nebo vytvořit neoprávněné přístupové cesty.

Příklad implementace

Maloobchodní organizace utrpěla narušení zabezpečení, když útočníci použili ukradené přihlašovací údaje služebního principu nalezené v záznamech pipeline k přístupu k produkčním databázím, čímž odhalili miliony záznamů zákazníků.

Výzva: Připojovací řetězce databáze a klíče rozhraní API pevně zakódované v proměnných kanálu. Nadměrná práva pipeline umožňovala všem vývojářům nasazování do produkčního prostředí. Kompromitace agenta sestavení poskytla trvalý přístup k infrastruktuře.

Přístup řešení:

  • Centralizovaná správa tajných kódů: Implementace integrace služby Azure Key Vault eliminuje pevně zakódované tajné kódy z kanálů. Nakonfigurované ověřování spravované identity, které odstraňuje riziko vystavení přihlašovacích údajů.
  • Řízení přístupu do kanálu: Zavedené schvalovací brány a oprávnění specifická pro prostředí pomocí Azure DevOps Environments vyžadující schválení týmu zabezpečení pro produkční nasazení.
  • Agenty sestavení s pevnějším zabezpečením: Agenty hostované na vlastním serveru byly nasazeny s posílením zabezpečení a izolací sítě pro zpracování citlivé pracovní zátěže zahrnující regulovaná data.
  • Kontrola zabezpečení infrastruktury: Integrované ověřování zabezpečení pro šablony ARM a konfigurace Terraformu brání nasazení nesprávných konfigurací.

Výsledek: Eliminované tajné kódy z protokolů kanálu brání krádeži přihlašovacích údajů. Eliminovali jsme neautorizované produkční nasazení. Zjištěné a blokované chybné konfigurace infrastruktury před nasazením

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

  • NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, SC-12, SC-13, AU-2, AU-6
  • PCI-DSS v4: 8.3.2, 8.6.1, 8.6.3, 12.3.3
  • Kontroly CIS v8.1: 4.1, 4.7, 6.1, 6.5
  • NIST CSF v2.0: PR. AC-4, PR. DS-5, DE. CM-7
  • ISO 27001:2022: A.5.15, A.5.16, A.8.3
  • SOC 2: CC6.1, CC6.6, CC6.7

DS-4: Integrace testování zabezpečení statických aplikací (SAST)

Princip zabezpečení

Implementujte komplexní automatizované testování zabezpečení prostřednictvím několika specializovaných skenerů SAST (Static Application Security Testing) integrovaných do každého procesu sestavení. Využijte pokrytí více skenerů pro komplexní detekci, implementujte skenování tajných hodnot s ochranou při pushi a nasaďte sémantickou analýzu kódu k identifikaci a blokování zranitelností před dosažením produkčního prostředí.

Riziko ke zmírnění

Ohrožení zabezpečení na úrovni kódu, která předcházejí detekci během vývoje, vytvářejí trvalé slabé stránky zabezpečení, které nežádoucí osoba systematicky zneužívají. Bez komplexní integrace SAST:

  • Ohrožení zabezpečení injektáže: Injektáž SQL, skriptování mezi weby (XSS), injektáž příkazů a chyby injektáže LDAP umožňují útočníkům manipulovat s aplikační logikou, extrahovat citlivá data nebo spouštět libovolný kód.
  • Pevně zakódované přihlašovací údaje: Vývojáři neúmyslně potvrdí hesla, klíče rozhraní API, certifikáty a připojovací řetězce do úložišť zdrojového kódu a poskytují útočníkům přímý přístup k produkčním systémům a datům.
  • Nezabezpečené kryptografické implementace: Slabé šifrovací algoritmy (DES, MD5), pevně zakódované šifrovací klíče, nesprávné inicializační vektory nebo nedostatečné délky klíčů ohrožují důvěrnost a integritu dat.
  • Přetečení vyrovnávací paměti a poškození paměti: Nebezpečné operace paměti v aplikacích C/C++ umožňují libovolné spuštění kódu, eskalaci oprávnění a útoky na odepření služeb.
  • Chyby obchodní logiky: obcházení autentizace, autorizační mezery, závodní podmínky a nedostatečné ověřování vstupu umožňují eskalaci oprávnění, podvody a neoprávněný přístup.
  • Chybné konfigurace infrastruktury jako kódu (IaC): Nezabezpečený Terraform, šablony ARM nebo manifesty Kubernetes nasazují zranitelnou infrastrukturu s nadměrně podmíněným přístupem, chybějícím šifrováním nebo vystavenými koncovými body správy.

Při absenci automatizovaného SAST se zranitelnosti hromadí jako technický dluh, prodlužují dobu zotavení a stávají se nákladnými na odstranění v produkčním prostředí.

MITRE ATT&CK

  • Počáteční přístup (TA0001): Zneužití veřejně přístupné aplikace (T1190) využitím zranitelností injekce nebo obcházení ověřování v kódu aplikace.
  • Spuštění (TA0002): Zneužití při spuštění na straně klienta (T1203) zneužívající zranitelnosti na straně klienta, jako je XSS nebo nezabezpečená deserializace.
  • Přístup k přihlašovacím údajům (TA0006):: Přihlašovací údaje z úložišť hesel (T1555) extrahují pevně zakódované přihlašovací údaje ze zdrojového kódu, konfiguračních souborů nebo kompilovaných binárních souborů.
  • Eskalace oprávnění (TA0004): Využití pro eskalaci oprávnění (T1068) využívající přetečení vyrovnávací paměti nebo poškození paměti ke zvýšení úrovně přístupu.

DS-4.1: Implementace kanálu SAST s více skenery

Komplexní testování zabezpečení statických aplikací integrované do každého sestavení poskytuje včasnou detekci ohrožení zabezpečení na úrovni kódu, než se dostanou do produkčních prostředí. Moderní aplikace používají různé jazyky, architektury a infrastrukturu jako kód, které vyžadují specializované analyzátory– žádný jediný skener nezjistí všechny třídy ohrožení zabezpečení. Vícevrstvé strategie SAST kombinující specializované nástroje s automatickým spouštěním a branami pro zvýšení kvality zajišťují komplexní pokrytí a současně poskytují vývojářům okamžitou zpětnou vazbu při zjištění problémů se zabezpečením.

Implementujte automatizované testování zabezpečení s těmito komponentami:

  • Implementace strategie vícevrstvé kontroly: Vložte automatizované testování zabezpečení statických aplikací do každého sestavení, abyste zjistili ohrožení zabezpečení před tím, než kód dosáhne produkčního prostředí. Implementujte vícevrstvou strategii SAST, která kombinuje několik specializovaných skenerů – žádný jednotlivý nástroj nedokáže detekovat všechny třídy zranitelností, takže pro komplexní pokrytí je třeba analyzátory specifické pro jazyk (Python, JavaScript, C/C++), skenery infrastruktury jako kódu (Terraform, šablony ARM, manifesty Kubernetes), detekci citlivých údajů a sémantickou analýzu kódu pro komplexní zranitelnosti v toku dat.

  • Konfigurace automatického spouštění s využitím kvalitativních bran: Nakonfigurujte kontrolu SAST tak, aby se spouštěla automaticky u každého potvrzení a pull requestu, což vývojářům poskytuje okamžitou zpětnou vazbu na problémy se zabezpečením, když je kontext kódu čerstvý. Vytvořte kontroly kvality založené na závažnosti, které blokují sloučení nebo nasazení při zjištění kritických nebo vysoce závažných zranitelností, čímž zabráníte tomu, aby zranitelný kód postupoval v rámci kanálu. Nakonfigurujte skenery tak, aby vystavovaly závěry ve standardizovaných formátech (SARIF), které umožňují konzistentní sledování ohrožení zabezpečení, odstranění duplicitních dat napříč nástroji a integraci s centralizovanými řídicími panely zabezpečení.

  • Nasazení kontroly tajných kódů pomocí ochrany nabízených oznámení: Implementujte specializovanou kontrolu tajných kódů s ochranou nabízených oznámení, která vývojářům brání v potvrzení přihlašovacích údajů, klíčů rozhraní API, certifikátech nebo tokenech do úložišť zachytávání tajných kódů v době potvrzení, a ne jejich zjišťování v kontrolách auditu později. Podpora standardních vzorů tajných kódů (klíčů AWS, tokenů Azure, připojovacích řetězců databáze) a vlastních vzorů specifických pro organizaci pro vlastní mechanismy ověřování. Po zjištění tajných kódů poskytněte okamžité pokyny k nápravě, včetně postupů obměna přihlašovacích údajů a bezpečných alternativ.

  • Použití sémantické analýzy kódu pro složitá ohrožení zabezpečení: Nasaďte sémantické nástroje pro analýzu kódu, jako je GitHub CodeQL , které provádějí hloubkovou analýzu toku dat a identifikují složitá ohrožení zabezpečení neviditelná pro skenery odpovídající vzorům, jako je injektáž SQL prostřednictvím více volání funkcí, ověřování obchází obchodní logikou nebo nezabezpečené řetězce deserializace. Vytvářejte vlastní dotazy zabezpečení přizpůsobené architekturám vaší organizace, požadavkům na zabezpečení a běžným vzorům ohrožení zabezpečení identifikovaným v retrospektivních incidentech. Integrace zjištění SAST přímo do vývojářských pracovních postupů prostřednictvím komentářů žádostí o přijetí změn s konkrétními čísly řádků, vysvětleními ohrožení zabezpečení a doporučeními pro nápravu

  • Orchestrace s jednotnými platformami: Jednotné platformy SAST, jako je rozšíření Microsoft Security DevOps, mohou orchestrovat několik specializovaných skenerů (AntiMalware, Bandit, BinSkim, Checkov, ESLint, Template Analyzer, Terrascan, Trivy) prostřednictvím jedné úlohy kanálu, standardizují správu konfigurace a agregaci výsledků napříč heterogenními ekosystémy nástrojů.

Příklad implementace

Poskytovatel SaaS utrpěl útok SQL injekcí, který vystavil stovky tisíc záznamů zákazníků. Analýza po incidentu odhalila rozsáhlá ohrožení zabezpečení na úrovni kódu, včetně pevně zakódovaných přihlašovacích údajů a chyb injektáže, které existovaly po dobu měsíců.

Výzva: Ruční kontroly kódu zachytily jenom malý zlomek ohrožení zabezpečení. Vývojářům chybělo školení v oblasti bezpečnosti k identifikaci injekčních chyb a kryptografických slabin ve šifrování. Žádná automatizovaná kontrola před produkčním nasazením.

Přístup řešení:

  • SAST s více skenery: Nasazeno rozšíření Microsoft Security DevOps s CodeQL, ESLint a Bandit, které poskytuje komplexní pokrytí napříč jazyky a typy zranitelností.
  • Ochrana tajemství: Nainstalovali jsme GitHub Advanced Security s kontrolou tajemství a ochranou push, která brání odhalení přihlašovacích údajů v potvrzeních.
  • Sémantická analýza: Nakonfigurovali jsme GitHub CodeQL s vlastními dotazy pro ohrožení zabezpečení obchodní logiky a vzory zabezpečení specifické pro konkrétní frameworky.
  • Bezpečnostní brány: Zavedené brány kanálu ve službě Azure Pipelines blokují nasazení zjištění s vysokou závažností.

Výsledek: Byly rychle identifikovány a odstraněny rozsáhlé zranitelnosti. Zabránili jsme kritickým chybám zabezpečení v dosažení produkce. Podstatně se snížil dluh v oblasti bezpečnosti.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

  • NIST SP 800-53 Rev.5: SA-11, RA-5, SI-2
  • PCI-DSS v4: 6.3.2, 6.4.1, 11.3.1
  • Kontroly CIS v8.1: 16.3, 16.6
  • NIST CSF v2.0: PR.IP-2, DE.CM-4
  • ISO 27001:2022: A.8.25, A.8.29
  • SOC 2: CC7.1, CC7.2

DS-5: Integrace dynamického testování zabezpečení aplikací (DAST)

Princip zabezpečení

Implementujte komplexní dynamické testování zabezpečení v předprodukčních prostředích prostřednictvím kontroly zabezpečení kontejnerů pro kontejnerizované úlohy, automatizované penetrační testování webových aplikací a aplikačních programovacích rozhraní (API) a specializovaného testování pro ověřování, autorizaci a správu relací. Ověření modulu runtime identifikuje slabá místa konfigurace a ohrožení zabezpečení integrace, která statická analýza nedokáže rozpoznat.

Riziko ke zmírnění

Ohrožení zabezpečení za běhu, která nejsou viditelná pro statickou analýzu, vytvářejí kritické mezery zabezpečení, které nežádoucí osoba zneužívají po nasazení aplikací. Bez komplexního DAST:

  • Slabé stránky konfigurace nasazení: Chybně nakonfigurovaní zprostředkovatelé ověřování, příliš povolující CORS, slabé konfigurace TLS, nebo chybějící hlavičky zabezpečení (CSP, HSTS, X-Frame-Options) umožňují útoky, které nelze zjistit revizí zdrojového kódu.
  • Mezery zabezpečení rozhraní API: Rozhraní REST a GraphQL API s průchody ověřováním, selháním autorizace, nadměrným vystavením dat, chybějícím omezením rychlosti nebo nezabezpečenými přímými odkazy na objekty (IDOR) umožňují neoprávněný přístup a extrakci dat.
  • Obejití ověřování a autorizace: Chyby ve správě relací, procesy resetování hesel, implementace vícefaktorového ověřování nebo logika řízení přístupu podle role umožňují eskalaci oprávnění a převzetí účtů.
  • Zranitelnosti správy relací: Předvídatelné tokeny relace, nedostatečné vynucení časového limitu, zranitelnosti relací z důvodu fixace nebo chybějící zrušení tokenu umožňují únos relací a krádež přihlašovacích údajů.
  • Problémy se zabezpečením specifické pro prostředí: Integrační body s databázemi, frontami zpráv, externími rozhraními API nebo službami třetích stran přinášejí při vývoji nebo izolovaném testování neviditelná ohrožení zabezpečení za běhu.
  • Chyby obchodní logiky: Závodní podmínky, zranitelnosti při manipulaci se stavem, nedostatečné ověřování vstupu v komplexních pracovních postupech nebo problémy s integritou transakcí umožňují podvody a manipulaci s daty.

DAST ověřuje chování za běhu, konfiguraci prostředí a zabezpečení integrace a poskytuje pokrytí, které statická analýza nemůže nabídnout.

MITRE ATT&CK

  • Počáteční přístup (TA0001): Zneužít veřejně přístupnou aplikaci (T1190) s využitím obcházejících se ověřování, chyb injektáže nebo nezabezpečených koncových bodů rozhraní API zjištěných prostřednictvím testování za běhu.
  • Přístup k přihlašovacím údajům (TA0006): Hrubá síla (T1110) využívající absence omezení rychlosti, slabé zásady hesel nebo předvídatelné tokeny relace zjištěné během DAST.
  • Eskalace oprávnění (TA0004): Platné účty (T1078) zneužívající obejití autorizace nebo chyby v manipulaci s rolemi v nasazených aplikacích.
  • Shromažďování (TA0009): data z úložišť informací (T1213) extrahují citlivá data prostřednictvím nadměrných odpovědí rozhraní API, procházení adresářů nebo nezabezpečených ohrožení zabezpečení přímého odkazu na objekty.
  • Exfiltrace (TA0010): exfiltrace prostřednictvím webové služby (T1567) využívající mezery v zabezpečení rozhraní API k extrahování dat ve velkém měřítku bez detekce.

DS-5.1: Implementace automatizovaného DAST v předprodukčním prostředí

Dynamické testování zabezpečení aplikací ověřuje ovládací prvky zabezpečení ve spuštěných aplikacích a zjišťuje ohrožení zabezpečení za běhu, která statická analýza nedokáže rozpoznat. Zatímco SAST zkoumá zdrojový kód, test DAST testuje nasazené aplikace s konfiguracemi podobných produkčním prostředím a identifikuje problémy specifické pro nasazení, včetně chyb ověřování, chyb autorizace a mezer zabezpečení integrace, které se projeví jenom v provozních prostředích. Automatizované DAST v předprodukčním prostředí zajišťuje validaci zabezpečení před použitím zákazníky během testování realistických scénářů útoku proti integrovaným systémům.

Implementujte ověřování zabezpečení za běhu prostřednictvím těchto možností:

  • Doplňte SAST ověřováním za běhu: Doplňte statickou analýzu pomocí dynamického testování zabezpečení aplikací, které ověřuje zabezpečení ve spuštěných aplikacích pomocí konfigurací podobných produkčním prostředím. Zatímco SAST identifikuje ohrožení zabezpečení ve zdrojovém kódu, DAST zjistí problémy s modulem runtime neviditelné pro statickou analýzu: slabá místa konfigurace nasazení (chybně nakonfigurovaní zprostředkovatelé ověřování, zásady cors, chybějící hlavičky zabezpečení), chyby integrace specifické pro prostředí (zabezpečení připojení k databázi, autorizace rozhraní API v nasazených kontextech) a chyby zabezpečení obchodní logiky, které se projeví pouze v realistických provozních podmínkách.

  • Nasazení v přípravných prostředích podobných produkčním prostředím: Nasaďte kontrolu DAST v předprodukčních přípravných prostředích, která zrcadlí produkční architekturu, topologii sítě, externí závislosti a parametry konfigurace. Automatizované spouštění DAST by se mělo aktivovat při nasazení do přípravy, systematicky testovat toky ověřování, hranice autorizace, správu relací, ověřování vstupu, zabezpečení rozhraní API a zpracování chyb v rámci reálného zatížení a způsobu použití. Tím se ověří, že bezpečnostní prvky fungují správně, když jsou integrované s externími systémy podobným produkčním prostředím (zprostředkovatelé identit, databáze, fronty zpráv, rozhraní API třetích stran).

  • Implementace monitorování modulu runtime pro kontejnery: U kontejnerizovaných úloh implementujte monitorování nepřetržitého zabezpečení modulu runtime, které kombinuje kontrolu imagí před nasazením s analýzou chování po nasazení. Zkontrolujte image kontejnerů na známé zranitelnosti před nasazením, a pak monitorujte spuštěné kontejnery kvůli neobvyklým síťovým připojením, neautorizovanému spouštění procesů, modifikacím souborového systému a pokusům o eskalaci oprávnění. Profilujte normální chování úloh Kubernetes a detekujte odchylky označující ohrožení a průběžně vyhodnocujte konfigurace kontejnerů vůči srovnávacím testům CIS a osvědčeným postupům zabezpečení.

  • Zaměřte se na vysoce rizikové oblasti útoku: Zaměřte specializované úsilí DAST na vysoce rizikové oblasti útoku: REST a GraphQL API (testování obejití ověřování, chyby autorizace, zranitelnosti injektáže, nadměrné vystavení dat, nezabezpečené přímé odkazy na objekty), ověřování a správu relací (ověření zabezpečení tokenu, vynucení časového limitu, odhlašování, toky resetování hesla, vícefaktorové ověřování) a obchodní postupy logiky (testování závodních podmínek, manipulace se stavem, problémy integrity transakcí). Vytvořte pracovní postupy korelace SAST/DAST, které kombinují závěry z obou přístupů a upřednostňují ohrožení zabezpečení potvrzená prostřednictvím statické i dynamické analýzy jako nejvyššího rizika.

  • Využití integrovaných platforem: V případě kontejnerizovaných prostředí poskytuje Microsoft Defender for Containers integrované posouzení ohrožení zabezpečení modulu runtime, profilaci úloh a možnosti detekce hrozeb v průběhu životního cyklu kontejneru.

Příklad implementace

Organizace elektronického obchodování zjistila obejití ověřování v rozhraní API pro platby, což umožňuje neoprávněné slevy. SAST vynechal chybu konfigurace modulu runtime, která se projevila pouze v nasazených prostředích s externími zprostředkovateli ověřování.

Výzva: SAST zjistila ohrožení zabezpečení kódu, ale nezmeškala problémy s konfigurací modulu runtime a chyby autorizace rozhraní API. Konfigurace produkčního nasazení se liší od vývoje, který vytváří mezery zabezpečení neviditelné až po statickou analýzu.

Přístup řešení:

  • Automatizované skenování DAST: Nasazení OWASP ZAP v předprodukčním prostředí testuje nasazené aplikace s konfiguracemi podobných produkčním prostředím.
  • Ochrana za běhu kontejneru: Implementovali jsme Microsoft Defender for Containers pro monitorování zabezpečení runtime a zjišťování zranitelností.
  • Testování zabezpečení rozhraní API: Nakonfigurovali jsme specializované testování rozhraní API pro ověřování, autorizaci a ověřování dat v nasazených koncových bodech REST a GraphQL.
  • Korelace SAST/DAST: Vytvořili jsme pracovní postupy korelace ohrožení zabezpečení, které kombinují statická a dynamická zjištění pro komplexní ověřování zabezpečení.

Výsledek: Zjištěné zranitelnosti runtime, které neodhalil SAST, včetně obcházení autentizace a chyb autorizace rozhraní API. Zabránili jsme incidentům zabezpečení prostřednictvím předprodukční detekce.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

  • NIST SP 800-53 Rev.5: SA-11, CA-8, RA-5
  • PCI-DSS v4: 6.4.2, 11.3.2
  • Kontroly CIS v8.1: 16.7, 16.8
  • NIST CSF v2.0: DE.CM-4, PR.IP-12
  • ISO 27001:2022: A.8.29, A.8.30
  • SOC 2: CC7.1, CC7.3

DS-6: Zabezpečení životního cyklu úloh

Azure Policy: Viz předdefinované definice zásad Azure: DS-6.

Princip zabezpečení

Implementujte neměnnou infrastrukturu s komplexním zabezpečením obrazů prostřednictvím registrů kontejnerů a skenování zabezpečení pro úlohy kontejnerů, správy zlatých obrazů a automatizovaného sestavování pro úlohy virtuálních počítačů a nepřetržitého skenování zranitelností s automatizovanou karanténou. Ověřte kryptografické podpisy, udržujte minimální základní image a vynucujte standardní hodnoty zabezpečení v průběhu životního cyklu úloh.

Riziko ke zmírnění

Nezabezpečená správa životního cyklu úloh umožňuje ohroženým nebo ohroženým artefaktům dosáhnout produkčního prostředí a vytvářet trvalé vektory útoku, které nežádoucí osoby systematicky zneužívají. Bez komplexního zabezpečení úloh:

  • Ohrožené produkční image virtuálních počítačů: Nepatchované standardní hodnoty operačního systému nebo chybně nakonfigurované zlaté image šíří slabá místa napříč všemi nasazenými virtuálními počítači.
  • Nepatchované ohrožené základní obrazy: Kontejnery postavené na základních obrazech ovlivněných CVE (Log4Shell, Heartbleed, OpenSSL) vystavují úlohy riziku zneužití a úniku.
  • Zastaralé ohrožené artefakty: Obrázky a balíčky zůstaly nezkontrolované akumulují se CVE a zvětšují prostor pro útoky.
  • Nedostatečné ověření obrázku: Nedostatek kryptografického podepisování a ověření původu umožňuje nežádoucím osobam nahradit legitimní image ohroženými verzemi obsahujícími zadní vrátka nebo malware.
  • Nafouknutá plocha útoku: Kontejnerové obrazy obsahující nepotřebné balíčky, vývojové nástroje nebo ladicí nástroje zvyšují zranitelnost a poskytují útočníkům další nástroje pro zneužití.
  • Chybějící standardní hodnoty zabezpečení: Image virtuálních počítačů a kontejnerů nasazené bez dodržování předpisů srovnávacího testu CIS, posílení zabezpečení nebo minimální konfigurace oprávnění vytvářejí zneužitelné mezery v hloubkové ochraně.

Ohrožené artefakty se stanou trvalými vektory útoku, usnadňují laterální pohyb a jeví se jako legitimní pro obránce.

MITRE ATT&CK

  • Počáteční přístup (TA0001): Zneužít veřejně přístupnou aplikaci (T1190) s využitím nepatchovaných chyb zabezpečení v kontejnerech aplikací nebo webových službách.
  • Spuštění (TA0002): Nasaďte kontejner (T1610) a nasaďte škodlivé kontejnery, které se zobrazují legitimní kvůli nedostatečnému ověření image.
  • Eskalace oprávnění (TA0004): únik k hostiteli (T1611) zneužívající ohrožení zabezpečení kontejneru k přerušení izolace kontejneru a ohrožení hostitelského systému.
  • Lateral Movement (TA0008): využívání vzdálených služeb (T1210) prokládané mezi ohroženými virtuálními počítači nebo kontejnery nasazenými z ohrožených imagí.

DS-6.1: Implementace zabezpečení imagí kontejneru

Image kontejnerů a virtuálních počítačů představují kritické oblasti útoku, které v průběhu životního cyklu vyžadují komplexní bezpečnostní prvky. Ohrožené základní obrazy přenášejí slabiny do každé nasazené instance a zesilují dopad napříč infrastrukturou. Zacházení s artefakty úloh se stejnou kategorií zabezpečení jako se zdrojovým kódem, včetně skenování, podepisování a zabezpečeného úložiště, zajišťuje, že organizace nasazují jenom ověřené, důvěryhodné image a zároveň brání útočníkům v zneužití známých ohrožení zabezpečení nebo nahrazování škodlivých imagí.

Zabezpečte artefakty úloh pomocí těchto postupů:

  • Stanovení neměnných principů infrastruktury: Zacházejte s obrazy kontejnerů a virtuálních počítačů jako s důležitými artefakty, které vyžadují stejnou úroveň zabezpečení, protože image mohou obsahovat zranitelnosti v kódu, což může šířit slabiny do všech nasazených instancí. Vytvořte zásady neměnné infrastruktury, kde jsou artefakty úloh vytvořeny jednou, důkladně proskenovány, kryptograficky podepsány a nasazeny bez úprav, aby byla zajištěna konzistence a sledovatelnost během celého životního cyklu.

  • Použití minimálních základních imagí s vícefázovými buildy: U úloh kontejnerů implementujte zabezpečení vrstvených imagí počínaje minimálními základními imagemi, které obsahují pouze základní komponenty modulu runtime, což výrazně snižuje prostor pro útoky oproti úplným imagím operačního systému. Použijte vícefázová sestavení k oddělení závislostí pro sestavení od imagí pro runtime – kompilujte a sestavujte v imagích s bohatými funkcemi a poté kopírujte pouze konečné artefakty do minimálních imagí pro runtime. Tímto eliminujte vývojové nástroje, správce balíčků a sestavení závislostí, které zvyšují riziko ohrožení zabezpečení a poskytují útočníkům nástroje pro zneužití.

  • Integrace automatizovaného skenování se zásadami karantény: Integrujte automatizované skenování zranitelností do procesu sestavení image, který kontroluje každý image před uložením do registru, kontroluje komplexní databáze CVE a průběžně prověřuje uložené image, jakmile jsou odhaleny nové zranitelnosti. Implementujte automatizované zásady karantény, které zabraňují nasazení obrazů s kritickými nebo vysoce závažnými zranitelnostmi, přičemž výjimky musí být schváleny bezpečnostním týmem a s dokumentovaným přijetím rizik. Vytvořte zásady aktualizace základních imagí pomocí automatizovaných spouštěčů pipeline při vydání oprav zabezpečení a zajistěte, aby se v imagích v průběhu času nehromadily CVE.

  • Vynucení kryptografického podepisování a ověření: Prosazujte integritu obrazu prostřednictvím kryptografického podepisování a ověřování na každé úrovni: podepisujte obrazy v době sestavení, ověřujte podpisy před nasazením a automaticky zamítejte nepodepsané nebo manipulované obrazy. Zabráníte tak útokům na náhradu obrázků, kdy nežádoucí uživatelé nahrazují legitimní image ohroženými verzemi obsahujícími zadní vrátka. Ukládání imagí v zabezpečených registrech kontejnerů pomocí řízení přístupu k síti (privátní koncové body, integrace virtuální sítě), zásad přístupu na základě rolí, které omezují, kdo může odesílat a stahovat image, a komplexní protokolování auditu všech operací registru.

  • Udržujte posílené zlaté image pro virtuální počítače: U úloh virtuálních počítačů udržujte centralizovaná úložiště zlatých imagí se standardem CIS vyhovujícím srovnávacím testům, posílenými základními imagemi, které procházejí pravidelnými opravami zabezpečení a ověřováním dodržování předpisů. Implementujte automatizované kanály vytváření imagí, které zahrnují aktualizace zabezpečení, odebírat nepotřebné služby, vynucovat konfigurace s nejnižšími oprávněními a generovat nové image podle definovaných plánů, a ne opravovat spuštěné systémy.

  • Využití integrovaných platforem zabezpečení: Řešení, jako je Azure Container Registry s integrací Microsoft Defenderu for Containers , poskytují automatizované prohledávání, pracovní postupy karantény, důvěryhodnost obsahu a replikaci ve více oblastech s konzistentními zásadami zabezpečení.

Příklad implementace

Logistická organizace nasadila kontejnerovou aplikaci s nepatchovanou imagí základní obsahující kritickou zranitelnost vzdáleného spuštění kódu. Útočníci zneužili tuto chybu zabezpečení krátce po nasazení a zneužili tak expediční data.

Výzva: Mnoho obrazů kontejnerů bez skenování zranitelností Obrazy vytvořené před měsíci nahromadily mnoho Common Vulnerabilities and Exposures, včetně kritických slabin zabezpečení. Žádné ověření nezabránělo nahrazení škodlivého obrázku.

Přístup řešení:

  • Zabezpečení registru kontejnerů: Implementovali Azure Container Registry s analýzou zranitelností, která před nasazením umisťuje do karantény obrazy s vysokou závažností CVE.
  • Posílené image virtuálních počítačů: Nasadili Azure sdílenou galerii imagí s imagemi virtuálních počítačů v souladu s benchmarkem CIS pro regulované pracovní zátěže.
  • Ochrana za běhu: Nakonfigurovali jsme Microsoft Defender for Containers pro průběžné zjišťování hrozeb a monitorování odchylek.
  • Integrita artefaktů: Vytvořili jsme kryptografické podepisování a ověřování, které zajišťuje pravost obrázků v průběhu životního cyklu.

Výsledek: Zablokovali jsme ohrožené image z produkčního nasazení. Výrazně se snížil počet kontejnerových CVE na každý obraz. Zabránili útokům na nahrazení obrázků prostřednictvím ověření podpisu.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

  • NIST SP 800-53 Rev.5: CM-2, CM-3, SI-2, SI-7, RA-5
  • PCI-DSS v4: 6.2.4, 6.3.3, 11.3.1
  • Kontroly CIS v8.1: 4.1, 7.3, 7.4
  • NIST CSF v2.0: PR.IP-1, PR.IP-3, DE.CM-8
  • ISO 27001:2022: A.8.9, A.8.31, A.8.32
  • SOC 2: CC7.2, CC8.1

DS-7: Implementace protokolování a monitorování DevOps

Princip zabezpečení

Implementujte komplexní protokolování aktivit DevOps prostřednictvím streamování auditu s integrací do centralizovaných platforem siEM (Security Information and Event Management) pro analýzu zabezpečení, detekci hrozeb v reálném čase a automatizovanou reakci. Vytvořte analýzu chování, detekci anomálií a metriky zabezpečení, abyste umožnili rychlou reakci na incidenty a udržovali záznamy auditu dodržování předpisů.

Riziko ke zmírnění

Nedostatečné protokolování a monitorování v DevOps vytváří kritická slepá místa, která útočníci zneužívají k tomu, aby mohli operovat nezjištěně, udržovat perzistenci a exfiltrovat citlivý kód nebo přihlašovací údaje. Bez komplexní viditelnosti:

  • Nedetekované ohrožení zabezpečení kanálu: Útočníci upravují kanály CI/CD tak, aby vkládaly škodlivý kód, exfiltrovaly tajné kódy nebo navazovaly zadní vrátka, aniž by aktivovaly výstrahy kvůli chybějícímu nebo nedostatečnému protokolování auditu.
  • Vnitřní hrozby, které upravují kód nebo infrastrukturu: Zlomyslní insideři nebo účty, které byly ohroženy, provádějí neoprávněné změny zdrojového kódu, definic infrastruktury nebo konfigurací nasazení, aniž by byly detekovány.
  • Nedostatek komplexních tras auditu: Absence podrobných protokolů aktivit zabraňuje forenznímu vyšetřování, posouzení dopadů a analýze původní příčiny, když dojde k prodloužení doby trvání incidentů zabezpečení a zvýšení dopadu na porušení zabezpečení.
  • Zpožděná reakce na incident: Střední doba detekce (MTTD) se prodlužuje od hodin po týdny, kdy bezpečnostní týmy nemají výstrahy v reálném čase, detekci anomálií a automatizovanou korelaci událostí zabezpečení DevOps.
  • Selhání auditu dodržování předpisů: Zákonné požadavky (SOX, PCI-DSS, HIPAA, ISO 27001) umožňující komplexní záznamy auditu, sledování změn a protokolování přístupu nelze splnit bez centralizovaného monitorování DevOps.
  • Slepota vůči eskalaci oprávnění: Neautorizované zvýšení oprávnění, vytvoření zadních dveří v účtech nebo úprava řízení přístupu probíhá nedetekovaně bez analýzy chování a monitorování oprávnění.

Mezery v protokolování skrývají škodlivé změny v pipeline, eskalaci oprávnění a trvalé pokusy o přístup ve vývojových prostředích s vysokými oprávněními.

MITRE ATT&CK

  • Vyhýbání se obraně (TA0005): oslabení obrany (T1562) zakázání protokolování auditu, kroků kontroly zabezpečení nebo monitorovacích agentů, které pracují ve slepých místech, a odstranění indikátorů (T1070) vymazání protokolů auditu nebo historie spuštění procesu za účelem skrytí škodlivých aktivit.
  • Trvalost (TA0003): Manipulace s účtem (T1098) vytváření dalších služebních identit, osobních přístupových tokenů nebo klíčů SSH bez detekce.
  • Shromažďování (TA0009): data z úložišť informací (T1213) exfiltrují zdrojový kód, tajné kódy nebo duševní vlastnictví prostřednictvím přístupu ke kanálu.
  • Přístup k přihlašovacím údajům (TA0006):: Nezabezpečené přihlašovací údaje (T1552) zpřístupňují tajné kódy z protokolů kanálu nebo historie spuštění.

DS-7.1: Implementace protokolování auditu pro platformy DevOps

Platformy DevOps s privilegovaným přístupem k produkční infrastruktuře a citlivým zdrojovým kódem vyžadují komplexní monitorování zabezpečení pro detekci nežádoucích aktivit a vnitřních hrozeb. Díky chybám protokolování auditu můžou aktéři se zlými úmysly pracovat nedetekce po delší období, zatímco centralizovaná agregace protokolů umožňuje korelaci s širší telemetrií zabezpečení, která odhalí sofistikované řetězy útoků. Analýzy chování v reálném čase identifikují podezřelé vzory neviditelné v izolovaných událostech a transformují nezpracovaná data auditu na použitelné inteligentní funkce zabezpečení.

Zajištění komplexního monitorování zabezpečení DevOps prostřednictvím těchto možností:

  • Zachytávání komplexních aktivit souvisejících se zabezpečením: Vytvořte komplexní protokolování auditu, které zachycuje všechny aktivity DevOps relevantní pro zabezpečení: události ověřování uživatelů a autorizace, potvrzení zdrojového kódu a operace větví, vytváření a úpravy kanálu, spouštění nasazení, přístup k tajným kódům, změny oprávnění, vytváření instančního objektu a akce správy. Platformy DevOps mají privilegovaný přístup k produkční infrastruktuře a citlivé mezery v evidenci kódu umožňují nepřátelům a škodlivým insiderským osobám pracovat neodhaleně po delší dobu.

  • Předávání protokolů do centralizovaného SYSTÉMU SIEM v reálném čase: Předávat protokoly auditu v reálném čase na centralizované platformy SIEM místo toho, aby se spoléhaly na nativní uchovávání platformy DevOps (obvykle 90 dnů), což umožňuje dlouhodobou forenzní analýzu, generování sestav dodržování předpisů a korelaci s událostmi zabezpečení z jiných systémů. Streamování protokolů do center operací zabezpečení prostřednictvím standardizovaných protokolů (/azure Event Hubs, syslog) ve strukturovaných formátech (JSON), které umožňují automatizovanou analýzu, analýzu a upozorňování bez ruční kontroly protokolů.

  • Nasazení analýzy chování a detekce anomálií: Implementace analýzy chování a detekce anomálií v datech auditu DevOps za účelem identifikace podezřelých vzorů neviditelných v jednotlivých událostech: úpravy kanálů po hodinách, neobvyklý přístup k citlivým úložištím, eskalace rychlých oprávnění, vytvoření instančního objektu následované podezřelými nasazeními, spouštěním kanálů z neočekávaných umístění nebo neobvyklými vzory přístupu k tajným kódům. Vytvořte profily chování podle směrného plánu pro uživatele a služby a upozorňování na statisticky významné odchylky, které můžou značit ohrožení zabezpečení nebo vnitřní hrozby.

  • Konfigurace automatizovaného upozorňování pro vysoce rizikové aktivity: Nakonfigurujte automatizované upozorňování na vysoce rizikové aktivity s okamžitým oznámením týmům zabezpečení: selhání produkčního nasazení, úpravy kanálu v chráněných větvích, vytvoření nového instančního objektu, události zvýšení oprávnění, zakázané kroky kontroly zabezpečení, změny konfigurace předávání protokolů auditu nebo pokusy o přístup k tajným kódům z neautorizovaných kanálů. Implementujte eskalaci založenou na závažnosti, která zajistí, že kritické výstrahy okamžitě dosáhnou operací bezpečnosti, zatímco rutinní události jsou seskupovány pro analýzu.

  • Integrace s širší telemetrií zabezpečení: Integrujte protokoly auditu DevOps s širší telemetrií zabezpečení na platformách SIEM pro korelaci s detekcí koncových bodů, zabezpečením sítě, událostmi identit a informačními kanály analýzy hrozeb. To umožňuje detekci sofistikovaných řetězů útoků, kdy je ohrožení DevOps jednou fází ve vícefázových operacích, například korelace phishovaných pověření s následnými úpravami pipeline a neobvyklým zřizováním cloudových prostředků.

  • Využití integrovaných platforem SIEM: Platformy, jako je streamování auditu Azure DevOps s integrací Microsoft Sentinelu , poskytují předávání protokolů v reálném čase, předem připravená pravidla detekce pro hrozby DevOps, sešity zabezpečení pro šetření a automatickou orchestraci odpovědí.

Příklad implementace

Výrobní organizace zjistila vnitřní hrozbu, když bývalý dodavatel upravil CI/CD kanál a vložil do produkční aplikace kód se zadními vrátky. Incident zůstal po dobu měsíců nezjištěný kvůli nedostatečnému protokolování auditu.

Výzva: Žádné centralizované protokolování aktivit DevOps. Změny kanálu a změny privilegovaného přístupu se nesledovaly. Forenzní vyšetřování bylo ztíženo nedostatkem auditorských stop. Audit dodržování předpisů selhal kvůli nedostatečnému sledování změn.

Přístup řešení:

  • Centralizované protokolování auditu: Aktivovali jsme směrování událostí Azure DevOps Audit Streaming do Microsoft Sentinel pro analýzu zabezpečení a dlouhodobé uchování.
  • Behaviorální analýza: Implementovali jsme detekci anomálií, která identifikuje neobvyklé vzory přístupu, úpravy kanálů po hodinách a eskalace oprávnění označující vnitřní hrozby.
  • Automatizované upozorňování: Nakonfigurovaná upozornění pro podezřelé aktivity, včetně neautorizovaných produkčních nasazení a směrování vytvoření zástupce služby do operací zabezpečení.
  • Vytváření sestav dodržování předpisů: Vytvořili jsme automatizované generování záznamu auditu, které splňují zákonné požadavky s komplexním sledováním změn.

Výsledek: Neoprávněné úpravy kanálu byly rychle zjištěny a následně jim bylo zabráněno. Výrazně se zkrátila doba vyšetřování incidentů pomocí komplexních tras auditu. Bylo dosaženo souladu s dokumentovanou správou změn.

Úroveň závažnosti

Mělo by být.

Mapování ovládacích prvků

  • NIST SP 800-53 Rev.5: AU-2, AU-3, AU-6, AU-12, SI-4
  • PCI-DSS v4: 10.2.1, 10.2.2, 10.3.4
  • Kontroly CIS v8.1: 8.2, 8.5, 8.11
  • NIST CSF v2.0: DE.CM-1, DE.CM-7, RS.AN-1
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2, CC7.3
  • Last updated on