Využívat artefakty softwaru třetích stran ve vašem dodavatelském řetězci pouze v případě, že je ověřený a označený jako bezpečný pro použití pomocí dobře definovaných procesů. Tento model je provozní sajdkárna pro vývojový proces. Příjemce tohoto modelu vyvolá tento proces, který ověří a zablokuje použití softwaru, který by mohl potenciálně zavést ohrožení zabezpečení.
Kontext a problém
Cloudová řešení se často spoléhají na software třetích stran získaný z externích zdrojů. Příkladem těchto typů artefaktů jsou opensourcové binární soubory, veřejné image kontejnerů, image operačního systému dodavatele. Všechny takové externí artefakty musí být považovány za nedůvěryhodné.
V typickém pracovním postupu se artefakt načte z úložiště mimo obor řešení a pak se integruje do kanálu nasazení. V tomto přístupu jsou některé potenciální problémy. Zdroj nemusí být důvěryhodný, artefakt může obsahovat chyby zabezpečení nebo nemusí být vhodný jiným způsobem pro vývojářské prostředí.
Pokud tyto problémy nejsou vyřešené, můžou být ohroženy záruky integrity dat a důvěrnosti řešení nebo způsobit nestabilitu kvůli nekompatibilitě s jinými komponentami.
Některé z těchto problémů se zabezpečením se dají vyhnout přidáním kontrol do jednotlivých artefaktů.
Řešení
Než ho do úlohy zavedete, ověřte software pro zabezpečení. Během procesu prochází každý artefakt důkladnou provozní rigorií, která ho ověřuje na základě konkrétních podmínek. Až po splnění těchto podmínek artefakt označí proces jako důvěryhodný.
Proces kvazování je bezpečnostní opatření, které se skládá z řady kontrolních bodů, které se používají před spotřebou artefaktu. Tyto kontrolní body zabezpečení zajišťují, že artefakt přejde z nedůvěryhodného stavu na důvěryhodný stav.
Je důležité si uvědomit, že proces karantény nemění složení artefaktu. Proces je nezávislý na cyklu vývoje softwaru a podle potřeby je vyvolán spotřebiteli. Jako příjemce artefaktu zablokujte používání artefaktů, dokud nepřejdou do karantény.
Tady je typický pracovní postup karantény:
Příjemce signalizuje svůj záměr, určuje vstupní zdroj artefaktu a blokuje jeho použití.
Proces karantény ověří původ požadavku a získá artefakty ze zadaného úložiště.
Vlastní proces ověření se provádí jako součást karantény, která zahrnuje ověření vstupních omezení a kontrolu atributů, zdroje a typu podle zavedených standardů.
Některé z těchto kontrol zabezpečení můžou být kontroly ohrožení zabezpečení, detekce malwaru atd. u každého odeslaného artefaktu.
Skutečné kontroly závisí na typu artefaktu. Vyhodnocení image operačního systému se liší od vyhodnocení balíčku NuGet, například.
Pokud je proces ověření úspěšný, artefakt se publikuje v bezpečném úložišti s jasnými poznámkami. V opačném případě zůstane pro příjemce nedostupný.
Proces publikování může obsahovat kumulativní sestavu, která zobrazuje doklad o ověření a závažnost každé kontroly. Zahrnout vypršení platnosti do sestavy, nad kterou by měla být sestava neplatná, a artefakt je považován za nebezpečný.
Proces označuje konec karantény tím, že signalizují událost se stavovými informacemi doprovázenými sestavou.
Na základě informací se uživatelé můžou rozhodnout provést akce, které použijí důvěryhodný artefakt. Tyto akce jsou mimo rozsah vzoru Karanténa.
Problémy a důležité informace
Jako tým, který využívá artefakty třetích stran, se ujistěte, že je získán z důvěryhodného zdroje. Vaše volba musí být v souladu se standardy schválenými organizací pro artefakty, které se pořují od dodavatelů třetích stran. Dodavatelé musí být schopni splnit požadavky na zabezpečení vaší úlohy (a vaší organizace). Ujistěte se například, že plán zodpovědného zveřejnění od dodavatele splňuje požadavky vaší organizace na zabezpečení.
Vytvořte segmentaci mezi prostředky, které ukládají důvěryhodné a nedůvěryhodné artefakty. Pomocí identit a síťových ovládacích prvků omezte přístup k autorizovaným uživatelům.
Spolehlivá možnost vyvolání procesu karantény. Ujistěte se, že artefakt není neúmyslně spotřebovaný, dokud se neoznačí jako důvěryhodný. Signál by měl být automatizovaný. Například úlohy související s upozorňováním zodpovědných stran, když se artefakt ingestuje do vývojářského prostředí, potvrdí změny v úložišti GitHub, přidá image do privátního registru atd.
Alternativou k implementaci modelu karantény je jeho outsourcovat. Existují odborníci na karanténu, kteří se specializují na ověřování veřejných aktiv jako svého obchodního modelu. Vyhodnoťte finanční i provozní náklady na implementaci modelu a odsoudíte odpovědnost. Pokud vaše požadavky na zabezpečení vyžadují větší kontrolu, doporučujeme implementovat vlastní proces.
Automatizujte proces příjmu artefaktů a také proces publikování artefaktu. Vzhledem k tomu, že úlohy ověřování můžou nějakou dobu trvat, proces automatizace musí být schopný pokračovat, dokud se nedokončí všechny úkoly.
Vzor slouží jako první ověření momentální příležitosti. Úspěšné předání karantény nezajistí, že artefakt zůstane po neomezenou dobu důvěryhodný. Artefakt musí i nadále procházet nepřetržitou kontrolou, ověřováním kanálu a dalšími rutinními kontrolami zabezpečení, které slouží jako poslední ověření příležitostí před povýšením vydané verze.
Model je možné implementovat centrálními týmy organizace nebo individuálního týmu úloh. Pokud existuje mnoho instancí nebo variací procesu karantény, měly by být tyto operace standardizované a centralizované organizací. V tomto případě týmy úloh sdílejí proces a využívají výhod správy procesů snižování zátěže.
Kdy se má tento model použít
Tento model použijte v těchto případech:
Úloha integruje artefakt vyvinutý mimo rozsah týmu úloh. K běžným příkladům patří:
Artefakt Open Container Initiative (OCI) z veřejných registrů, jako jsou DockerHub, GitHub Container Registry, Microsoft Container Registry
Softwarová knihovna nebo balíček z veřejných zdrojů, jako je galerie NuGet, index balíčků Pythonu, úložiště Apache Maven
Externí balíček infrastruktury jako kódu (IaC), jako jsou moduly Terraformu, cookbooky Community Chefu, ověřené moduly Azure
Image operačního systému dodávaná dodavatelem
Tým úloh považuje artefakt za riziko, které stojí za zmírnění. Tým rozumí negativním důsledkům integrace ohrožených artefaktů a hodnotě karantény zabezpečující důvěryhodné prostředí.
Tým má jasné a sdílené znalosti ověřovacích pravidel, která by se měla použít na typ artefaktu. Bez konsensu nemusí být vzor efektivní.
Pokud se například použije jiná sada kontrol ověření při každém ingestování image operačního systému do karantény, celkový proces ověření imagí operačního systému bude nekonzistentní.
Tento model nebude pravděpodobně vhodný v následujících případech:
Artefakt softwaru je vytvořen týmem úloh nebo důvěryhodným partnerským týmem.
Riziko neověřování artefaktu je levnější než náklady na sestavení a údržbu procesu karantény.
Návrh úloh
Architekt a tým úloh by měli vyhodnotit způsob použití modelu karantény v rámci postupů DevSecOps úlohy. Základní principy jsou popsané v pilířích architektury Azure Well-Architected Framework.
| Pilíř | Jak tento model podporuje cíle pilíře |
|---|---|
| Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy. | První odpovědnost za ověření zabezpečení obsluhuje model karantény. Ověření externího artefaktu se provádí v segmentovaném prostředí předtím, než ho proces vývoje spotřebuje. - SE:02 Zabezpečený životní cyklus vývoje - SE:11 Testování a ověřování |
| Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti. | Model karantény podporuje postupy bezpečného nasazení (SDP) tím, že zajišťuje, že ohrožené artefakty úlohy nespotřebovávají, což by mohlo vést k narušení zabezpečení během postupného nasazení expozice. - OE:03 Postupy vývoje softwaru - OE:11 Testování a ověřování |
Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.
Příklad
Tento příklad aplikuje pracovní postup řešení na scénář, ve kterém tým úloh chce integrovat artefakty OCI z veřejných registrů do instance služby Azure Container Registry (ACR), která je vlastníkem týmu úloh. Tým zachází s danou instancí jako s důvěryhodným úložištěm artefaktů.
Prostředí úloh používá azure Policy pro Kubernetes k vynucení zásad správného řízení. Omezuje načítání kontejnerů pouze z důvěryhodné instance registru. Upozornění služby Azure Monitor jsou navíc nastavená tak, aby detekují všechny importy do daného registru z neočekávaných zdrojů.
Žádost o externí image provádí tým úloh prostřednictvím vlastní aplikace hostované ve službě Azure Web Apps. Aplikace shromažďuje požadované informace pouze od autorizovaných uživatelů.
Kontrolní bod zabezpečení: Ověřuje se identita žadatele, cílového registru kontejneru a požadovaný zdroj image.
Požadavek je uložený ve službě Azure Cosmos DB.
Kontrolní bod zabezpečení: V databázi se udržuje záznam auditu, který sleduje rodokmen a ověřování image. Tato trasa se také používá pro historické hlášení.
Požadavek zpracovává orchestrátor pracovního postupu, což je odolná funkce Azure Functions. Orchestrátor používá pro spuštění všech ověření přístup bodového shromažďování.
Kontrolní bod zabezpečení: Orchestrátor má spravovanou identitu s dostatečným přístupem k provádění úloh ověřování.
Orchestrátor odešle požadavek na import image do karantény služby Azure Container Registry (ACR), která se považuje za nedůvěryhodné úložiště.
Proces importu v registru karantény získá image z nedůvěryhodného externího úložiště. Pokud je import úspěšný, má registr karantény místní kopii image ke spuštění ověření.
Kontrolní bod zabezpečení: Registr karantény chrání před manipulací a spotřebou úloh během procesu ověřování.
Orchestrátor spouští všechny úlohy ověření na místní kopii image. Mezi úkoly patří kontroly, jako je detekce běžných ohrožení zabezpečení a ohrožení (CVE), vyhodnocení faktury za software (SBOM), detekce malwaru, podepisování obrázků a další.
Orchestrátor rozhoduje o typu kontrol, pořadí provádění a čase provádění. V tomto příkladu používá azure Container Instance jako spouštěče úloh a výsledky jsou v databázi auditu Cosmos DB. Všechny úkoly můžou nějakou dobu trvat.
Kontrolní bod zabezpečení: Tento krok je jádrem procesu karantény, který provádí všechny kontroly ověření. Typ kontrol může být vlastní, open source nebo řešení zakoupená dodavatelem.
Orchestrátor se rozhodne. Pokud image projde všemi ověřeními, událost je zaznamenána v databázi auditu, image se odešle do důvěryhodného registru a místní kopie se odstraní z registru karantény. Jinak se image odstraní z registru karantény, aby se zabránilo jeho neúmyslným použití.
Kontrolní bod zabezpečení: Orchestrátor udržuje segmentaci mezi důvěryhodnými a nedůvěryhodnými umístěními prostředků.
Poznámka:
Místo orchestrátora, který provádí rozhodnutí, může tým úloh převzít tuto odpovědnost. V této alternativě orchestrátor publikuje výsledky ověření prostřednictvím rozhraní API a uchovává image v registru karantény po určitou dobu.
Tým úloh rozhodne po kontrole výsledků. Pokud výsledky splňují jejich odolnost vůči riziku, přetáhnou image z úložiště karantény do instance kontejneru. Tento model vyžádání změn je praktičtější, když se tento model používá k podpoře více týmů úloh s různými tolerancemi rizik zabezpečení.
Všechny registry kontejnerů jsou pokryté programem Microsoft Defender for Containers, který nepřetržitě vyhledává nově zjištěné problémy. Tyto problémy se zobrazují v Microsoft Defender Správa zranitelností.
Další kroky
Při implementaci tohoto modelu můžou být relevantní následující pokyny:
Doporučení k zabezpečení životního cyklu vývoje poskytují pokyny k používání důvěryhodných jednotek kódu ve všech fázích životního cyklu vývoje.
Osvědčené postupy pro zabezpečený dodavatelský řetězec softwaru, zejména pokud máte v aplikaci závislosti NuGet.
Dokumentace k Azure Artifacts je knihovna informací souvisejících se správou softwarových balíčků pomocí Azure Artifacts.