Karantänmönster

Använd programvaruartefakter från tredje part i leveranskedjan endast när de verifieras och markeras som säkra för användning av väldefinierade processer. Det här mönstret är en operativ sidovagn till utvecklingsprocessen. Konsumenten av det här mönstret anropar den här processen för att verifiera och blockera användningen av programvara som potentiellt kan medföra säkerhetsrisker.

Kontext och problem

Molnlösningar förlitar sig ofta på programvara från tredje part som hämtas från externa källor. Binärfiler med öppen källkod, offentliga containeravbildningar och os-avbildningar för leverantörer är några exempel på dessa typer av artefakter. Alla sådana externa artefakter måste behandlas som ej betrodda.

I ett typiskt arbetsflöde hämtas artefakten från ett arkiv utanför lösningens omfång och integreras sedan i distributionspipelinen. Det finns vissa potentiella problem i den här metoden. Källan kanske inte är betrodd, artefakten kan innehålla säkerhetsrisker eller så är den kanske inte lämplig på något annat sätt för utvecklarmiljön.

Om dessa problem inte åtgärdas kan dataintegritet och konfidentialitetsgarantier för lösningen komprometteras eller orsaka instabilitet på grund av inkompatibilitet med andra komponenter.

Vissa av dessa säkerhetsproblem kan undvikas genom att lägga till kontroller i varje artefakt.

Lösning

Ha en process som validerar programvaran för säkerhet innan du introducerar den i din arbetsbelastning. Under processen genomgår varje artefakt noggrann driftstakt som verifierar den mot specifika villkor. Först när artefakten uppfyller dessa villkor markerar processen den som betrodd.

Processen med kvartering är ett säkerhetsmått som består av en serie kontrollpunkter som används innan en artefakt används. Dessa säkerhetskontrollpunkter ser till att en artefakt övergår från en obetrodd status till en betrodd status.

Observera att karantänprocessen inte ändrar artefaktens sammansättning. Processen är oberoende av programutvecklingscykeln och anropas av konsumenter efter behov. Som konsument av artefakten blockerar du användningen av artefakter tills de har passerat karantänen.

Här är ett typiskt karantänarbetsflöde:

1. Konsumenten signalerar sin avsikt, anger artefaktens indatakälla och blockerar dess användning.

2. Karantänprocessen verifierar begärans ursprung och hämtar artefakterna från det angivna arkivet.

3. En anpassad verifieringsprocess utförs som en del av karantänen, vilket innefattar att verifiera indatabegränsningarna och kontrollera attribut, källa och typ mot etablerade standarder.

   Vissa av dessa säkerhetskontroller kan vara sårbarhetsgenomsökning, identifiering av skadlig kod och så vidare på varje skickad artefakt.

   De faktiska kontrollerna beror på artefaktens typ. Att utvärdera en OS-avbildning skiljer sig från att utvärdera ett NuGet-paket, till exempel.

4. Om verifieringsprocessen lyckas publiceras artefakten i ett säkert arkiv med tydliga anteckningar. Annars är den fortfarande inte tillgänglig för konsumenten.

   Publiceringsprocessen kan innehålla en kumulativ rapport som visar verifieringsbevis och allvarlighetsgrad för varje kontroll. Inkludera förfallodatum i rapporten där rapporten ska vara ogiltig och artefakten anses vara osäker.

5. Processen markerar slutet på karantänen genom att signalera en händelse med tillståndsinformation tillsammans med en rapport.

   Baserat på informationen kan användarna välja att vidta åtgärder för att använda den betrodda artefakten. Dessa åtgärder ligger utanför omfånget för karantänmönstret.

Problem och överväganden

• Som ett team som använder artefakter från tredje part kontrollerar du att det hämtas från en betrodd källa. Ditt val måste vara anpassat till organisationsgodkända standarder för artefakter som anskaffas från tredjepartsleverantörer. Leverantörerna måste kunna uppfylla säkerhetskraven för din arbetsbelastning (och din organisation). Kontrollera till exempel att leverantörens ansvarstagande informationsplan uppfyller organisationens säkerhetskrav.

• Skapa segmentering mellan resurser som lagrar betrodda och ej betrodda artefakter. Använd identitets- och nätverkskontroller för att begränsa åtkomsten till behöriga användare.

• Ha ett tillförlitligt sätt att anropa karantänprocessen. Kontrollera att artefakten inte används oavsiktligt förrän den har markerats som betrodd. Signaleringen ska automatiseras. Till exempel uppgifter som rör att meddela ansvariga parter när en artefakt matas in i utvecklarmiljön, genomföra ändringar i en GitHub-lagringsplats, lägga till en avbildning i ett privat register och så vidare.

• Ett alternativ till att implementera ett karantänmönster är att lägga ut det på entreprenad. Det finns karantänutövare som specialiserar sig på validering av offentliga tillgångar som affärsmodell. Utvärdera både de ekonomiska och operativa kostnaderna för att implementera mönstret jämfört med att lägga ut ansvaret på entreprenad. Om dina säkerhetskrav behöver mer kontroll rekommenderar vi att du implementerar din egen process.

• Automatisera artefaktinmatningsprocessen och även publiceringsprocessen för artefakten. Eftersom valideringsuppgifter kan ta tid måste automatiseringsprocessen kunna fortsätta tills alla aktiviteter har slutförts.

• Mönstret fungerar som en första tillfällig validering av affärsmöjligheten. Om karantänen skickas ser du inte till att artefakten förblir tillförlitlig på obestämd tid. Artefakten måste fortsätta att genomgå kontinuerlig genomsökning, pipelinevalidering och andra rutinmässiga säkerhetskontroller som fungerar som sista affärsmöjlighetsvalidering innan versionen marknadsförs.

• Mönstret kan implementeras av centrala team i en organisation eller ett enskilt arbetsbelastningsteam. Om det finns många instanser eller varianter av karantänprocessen bör dessa åtgärder standardiseras och centraliseras av organisationen. I det här fallet delar arbetsbelastningsteamen processen och drar nytta av avlastningsprocessens hantering.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

• Arbetsbelastningen integrerar en artefakt som utvecklats utanför arbetsbelastningsteamets omfång. Vanliga exempel:

  • En OCI-artefakt (Open Container Initiative) från offentliga register som DockerHub, GitHub Container Registry, Microsoft Container Registry

  • Ett programvarubibliotek eller paket från offentliga källor, till exempel NuGet-galleriet, Python Package Index, Apache Maven-lagringsplatsen

  • Ett externt IaC-paket (Infrastructure-as-Code), till exempel Terraform-moduler, Community Chef Cookbooks, Azure Verified Modules

  • En os-avbildning som tillhandahålls av leverantören

• Arbetsbelastningsteamet betraktar artefakten som en risk som är värd att minimera. Teamet förstår de negativa konsekvenserna av att integrera komprometterade artefakter och värdet av karantän i att säkerställa en betrodd miljö.

• Teamet har en tydlig och delad förståelse för de valideringsregler som ska tillämpas på en typ av artefakt. Utan konsensus kanske mönstret inte är effektivt.

  Om till exempel en annan uppsättning verifieringskontroller tillämpas varje gång en OS-avbildning matas in i karantän blir den övergripande verifieringsprocessen för OS-avbildningar inkonsekvent.

Det här mönstret är kanske inte användbart om:

• Programvaruartefakten skapas av arbetsbelastningsteamet eller ett betrott partnerteam.

• Risken att inte verifiera artefakten är billigare än kostnaden för att skapa och underhålla karantänprocessen.

Design av arbetsbelastning

En arkitekt och arbetsbelastningsteamet bör utvärdera hur karantänmönstret kan användas som en del av arbetsbelastningens DevSecOps-metoder. De underliggande principerna beskrivs i grundpelarna i Azure Well-Architected Framework.

Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.

Exempel

Det här exemplet tillämpar lösningsarbetsflödet på ett scenario där arbetsbelastningsteamet vill integrera OCI-artefakter från offentliga register till en Azure Container Registry-instans (ACR), som ägs av arbetsbelastningsteamet. Teamet behandlar den instansen som ett betrott artefaktarkiv.

Arbetsbelastningsmiljön använder Azure Policy for Kubernetes för att framtvinga styrning. Den begränsar endast containerhämtningar från deras betrodda registerinstans. Dessutom konfigureras Azure Monitor-aviseringar för att identifiera importer till registret från oväntade källor.

1. En begäran om en extern avbildning görs av arbetsbelastningsteamet via ett anpassat program som finns i Azure Web Apps. Programmet samlar endast in nödvändig information från behöriga användare.

   Säkerhetskontrollpunkt: Identiteten för beställaren, målcontainerns register och den begärda avbildningskällan verifieras.

2. Begäran lagras i Azure Cosmos DB.

   Säkerhetskontrollpunkt: En spårningslogg underhålls i databasen och håller reda på ursprung och valideringar av avbildningen. Den här leden används också för historisk rapportering.

3. Begäran hanteras av en arbetsflödesorkestrerare, som är en beständig Azure-funktion. Orkestreraren använder en punktinsamlingsmetod för att köra alla valideringar.

   Säkerhetskontrollpunkt: Orkestratorn har en hanterad identitet med tillräckligt med åtkomst för att utföra valideringsuppgifterna.

4. Orkestratorn skickar en begäran om att importera avbildningen till Azure Container Registry (ACR) i karantän som anses vara ett ej betrott arkiv.

5. Importprocessen i karantänregistret hämtar avbildningen från den ej betrodda externa lagringsplatsen. Om importen lyckas har karantänregistret en lokal kopia av avbildningen för att köra verifieringar.

   Säkerhetskontrollpunkt: Karantänregistret skyddar mot manipulering och arbetsbelastningsförbrukning under valideringsprocessen.

6. Orchestrator kör alla valideringsuppgifter på den lokala kopian av avbildningen. Uppgifter omfattar kontroller som, IDENTIFIERING av vanliga sårbarheter och exponeringar (CVE), utvärdering av programvarufakturering av material (SBOM), identifiering av skadlig kod, bildsignering med mera.

   Orkestratorn bestämmer typen av kontroller, körningsordningen och tidpunkten för körningen. I det här exemplet använder den Azure Container Instance som uppgiftslöpare och resultaten finns i Cosmos DB-granskningsdatabasen. Alla uppgifter kan ta mycket tid.

   Säkerhetskontrollpunkt: Det här steget är kärnan i karantänprocessen som utför alla valideringskontroller. Typen av kontroller kan vara anpassade lösningar med öppen källkod eller leverantörsköp.

7. Orkestratorn fattar ett beslut. Om avbildningen klarar alla valideringar noteras händelsen i granskningsdatabasen, avbildningen skickas till det betrodda registret och den lokala kopian tas bort från karantänregistret. I annat fall tas avbildningen bort från karantänregistret för att förhindra oavsiktlig användning.

   Säkerhetskontrollpunkt: Orchestrator upprätthåller segmentering mellan betrodda och ej betrodda resursplatser.

   Kommentar

   I stället för att orkestratorn fattar beslutet kan arbetsbelastningsteamet ta på sig det ansvaret. I det här alternativet publicerar orkestreraren valideringsresultatet via ett API och behåller avbildningen i karantänregistret under en tidsperiod.

   Arbetsbelastningsteamet fattar beslutet efter att ha granskat resultaten. Om resultaten uppfyller risktoleransen hämtar de avbildningen från karantänlagringsplatsen till sin containerinstans. Den här pull-modellen är mer praktisk när det här mönstret används för att stödja flera arbetsbelastningsteam med olika säkerhetsrisktoleranser.

Alla containerregister omfattas av Microsoft Defender for Containers, som kontinuerligt söker efter nyligen hittade problem. Dessa problem visas i Microsoft Defender – hantering av säkerhetsrisker.

Nästa steg

Följande vägledning kan vara relevant när du implementerar det här mönstret:

• Rekommendationer för att skydda en utvecklingslivscykel ger vägledning om hur du använder betrodda kodenheter genom alla faser i utvecklingslivscykeln.

• Metodtips för en säker leverantörskedja för programvara, särskilt när du har NuGet-beroenden i ditt program.

• Dokumentation om Azure Artifacts är ett bibliotek med information som rör hantering av programvarupaket med Azure Artifacts.