Gebruik softwareartefacten van derden alleen in uw toeleveringsketen wanneer deze is geverifieerd en gemarkeerd als veilig voor gebruik, door goed gedefinieerde processen. Dit patroon is een operationele sidecar voor het ontwikkelingsproces. De consument van dit patroon roept dit proces aan om het gebruik van software te verifiëren en te blokkeren die mogelijk beveiligingsproblemen kan veroorzaken.
Context en probleem
Cloudoplossingen zijn vaak afhankelijk van software van derden die is verkregen uit externe bronnen. Opensource binaire bestanden, openbare containerinstallatiekopieën, installatiekopieën van leveranciersbesturingssysteem zijn enkele voorbeelden van deze typen artefacten. Alle dergelijke externe artefacten moeten worden behandeld als niet-vertrouwd.
In een typische werkstroom wordt het artefact opgehaald uit een archief buiten het bereik van de oplossing en vervolgens geïntegreerd in de implementatiepijplijn. Er zijn enkele mogelijke problemen in deze aanpak. De bron wordt mogelijk niet vertrouwd, het artefact bevat mogelijk beveiligingsproblemen of is mogelijk niet geschikt voor de ontwikkelomgeving.
Als deze problemen niet worden aangepakt, kunnen de garanties voor gegevensintegriteit en vertrouwelijkheid van de oplossing worden aangetast of kan instabiliteit ontstaan als gevolg van incompatibiliteit met andere onderdelen.
Sommige van deze beveiligingsproblemen kunnen worden vermeden door controles toe te voegen aan elk artefact.
Oplossing
Een proces hebben waarmee de software voor beveiliging wordt gevalideerd voordat u deze in uw workload introduceert. Tijdens het proces ondergaat elk artefact een grondige operationele rigor die het verifieert tegen specifieke voorwaarden. Pas nadat het artefact aan deze voorwaarden voldoet, wordt het door het proces gemarkeerd als vertrouwd.
Het proces van quarantieren is een beveiligingsmaatregel, die bestaat uit een reeks controlepunten die worden gebruikt voordat een artefact wordt gebruikt. Deze beveiligingscontrolepunten zorgen ervoor dat een artefact overgaat van een niet-vertrouwde status naar een vertrouwde status.
Het is belangrijk te weten dat het quarantaineproces de samenstelling van het artefact niet wijzigt. Het proces is onafhankelijk van de softwareontwikkelingscyclus en wordt indien nodig aangeroepen door consumenten. Als consument van het artefact blokkeert u het gebruik van artefacten totdat ze quarantaine hebben doorgegeven.
Hier volgt een typische quarantainewerkstroom:
De consument geeft de intentie aan, geeft de invoerbron van het artefact aan en blokkeert het gebruik ervan.
Het quarantaineproces valideert de oorsprong van de aanvraag en haalt de artefacten op uit het opgegeven archief.
Er wordt een aangepast verificatieproces uitgevoerd als onderdeel van quarantaine, waaronder het verifiëren van de invoerbeperkingen en het controleren van de kenmerken, de bron en het type op basis van vastgestelde standaarden.
Sommige van deze beveiligingscontroles kunnen scannen op beveiligingsproblemen zijn, malwaredetectie, enzovoort, op elk verzonden artefact.
De werkelijke controles zijn afhankelijk van het type artefact. Het evalueren van een installatiekopieën van een besturingssysteem verschilt van het evalueren van een NuGet-pakket, bijvoorbeeld.
Als het verificatieproces is geslaagd, wordt het artefact gepubliceerd in een veilige opslag met duidelijke aantekeningen. Anders blijft deze niet beschikbaar voor de consument.
Het publicatieproces kan een cumulatief rapport bevatten waarin het bewijs van verificatie en de kritiek van elke controle wordt weergegeven. Neem de vervaldatum op in het rapport waarbuiten het rapport ongeldig moet zijn en het artefact als onveilig wordt beschouwd.
Het proces markeert het einde van de quarantaine door een gebeurtenis te signaleren met statusinformatie vergezeld van een rapport.
Op basis van de informatie kunnen de consumenten ervoor kiezen om acties uit te voeren om het vertrouwde artefact te gebruiken. Deze acties vallen buiten het bereik van het quarantainepatroon.
Problemen en overwegingen
Als een team dat artefacten van derden gebruikt, moet u ervoor zorgen dat deze wordt verkregen uit een vertrouwde bron. Uw keuze moet worden afgestemd op door de organisatie goedgekeurde standaarden voor artefacten die afkomstig zijn van externe leveranciers. De leveranciers moeten kunnen voldoen aan de beveiligingsvereisten van uw workload (en uw organisatie). Zorg er bijvoorbeeld voor dat het verantwoordelijke openbaarmakingsplan van de leverancier voldoet aan de beveiligingsvereisten van uw organisatie.
Maak segmentering tussen resources waarin vertrouwde en niet-vertrouwde artefacten worden opgeslagen. Gebruik identiteits- en netwerkbesturingselementen om de toegang tot de geautoriseerde gebruikers te beperken.
Een betrouwbare manier hebben om het quarantaineproces aan te roepen. Zorg ervoor dat het artefact niet per ongeluk wordt gebruikt totdat het is gemarkeerd als vertrouwd. De signalering moet worden geautomatiseerd. Taken met betrekking tot het melden van de verantwoordelijke partijen wanneer een artefact wordt opgenomen in de ontwikkelaarsomgeving, het doorvoeren van wijzigingen in een GitHub-opslagplaats, het toevoegen van een installatiekopie aan een privéregister, enzovoort.
Een alternatief voor het implementeren van een quarantainepatroon is het uitbesteden van het patroon. Er zijn quarantainebeoefenaars die zijn gespecialiseerd in validatie van openbare activa als hun bedrijfsmodel. Evalueer zowel de financiële als operationele kosten van het implementeren van het patroon versus het uitbesteden van de verantwoordelijkheid. Als uw beveiligingsvereisten meer controle nodig hebben, wordt het implementeren van uw eigen proces aanbevolen.
Automatiseer het opnameproces van artefacten en ook het proces van het publiceren van het artefact. Omdat validatietaken tijd kunnen kosten, moet het automatiseringsproces kunnen worden voortgezet totdat alle taken zijn voltooid.
Het patroon fungeert als een eerste momentige validatie van een verkoopkans. Het doorgeven van quarantaine zorgt er niet voor dat het artefact voor onbepaalde tijd betrouwbaar blijft. Het artefact moet doorlopend scannen, pijplijnvalidatie en andere routinebeveiligingscontroles blijven ondergaan die dienen als laatste verkoopkansvalidaties voordat de release wordt gepromoot.
Het patroon kan worden geïmplementeerd door centrale teams van een organisatie of een afzonderlijk workloadteam. Als er veel exemplaren of variaties van het quarantaineproces zijn, moeten deze bewerkingen worden gestandaardiseerd en gecentraliseerd door de organisatie. In dit geval delen workloadteams het proces en profiteren ze van offloading van procesbeheer.
Wanneer dit patroon gebruiken
Gebruik dit patroon wanneer:
De workload integreert een artefact dat buiten het bereik van het workloadteam is ontwikkeld. Dit zijn enkele veel voorkomende voorbeelden:
Een OCI-artefact (Open Container Initiative) uit openbare registers, zoals DockerHub, GitHub Container Registry, Microsoft Container Registry
Een softwarebibliotheek of pakket uit openbare bronnen, zoals de NuGet Gallery, Python Package Index, Apache Maven-opslagplaats
Een extern IaC-pakket (Infrastructure-as-Code), zoals Terraform-modules, Community Chef Cookbooks, Azure Verified Modules
Een door de leverancier geleverde installatiekopieën van het besturingssysteem
Het workloadteam beschouwt het artefact als een risico dat de moeite waard is om dit te beperken. Het team begrijpt de negatieve gevolgen van het integreren van aangetaste artefacten en de waarde van quarantaine bij het garanderen van een vertrouwde omgeving.
Het team heeft een duidelijk en gedeeld begrip van de validatieregels die moeten worden toegepast op een type artefact. Zonder consensus is het patroon mogelijk niet effectief.
Als er bijvoorbeeld een andere set validatiecontroles wordt toegepast telkens wanneer een installatiekopie van het besturingssysteem in quarantaine wordt opgenomen, wordt het algehele verificatieproces voor installatiekopieën van het besturingssysteem inconsistent.
In de volgende gevallen is dit patroon mogelijk niet geschikt:
Het software-artefact wordt gemaakt door het workloadteam of een vertrouwd partnerteam.
Het risico dat het artefact niet wordt geverifieerd, is goedkoper dan de kosten voor het bouwen en onderhouden van het quarantaineproces.
Workloadontwerp
Een architect en het workloadteam moeten evalueren hoe het quarantainepatroon kan worden gebruikt als onderdeel van de DevSecOps-procedures van de workload. De onderliggende principes worden behandeld in de pijlers van het Azure Well-Architected Framework.
| Pijler | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
|---|---|
| Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen. | De eerste verantwoordelijkheid voor beveiligingsvalidatie wordt geleverd door het quarantainepatroon. De validatie van een extern artefact wordt uitgevoerd in een gesegmenteerde omgeving voordat deze wordt gebruikt door het ontwikkelingsproces. - Se:02 Beveiligde ontwikkelingslevenscyclus - SE:11 Testen en valideren |
| Operational Excellence helpt bij het leveren van workloadkwaliteit via gestandaardiseerde processen en teamcohesie. | Het quarantainepatroon ondersteunt veilige implementatieprocedures (SDP) door ervoor te zorgen dat aangetaste artefacten niet worden gebruikt door de workload, wat kan leiden tot beveiligingsschendingen tijdens progressieve blootstellingsimplementaties. - OE:03 Softwareontwikkelingsprocedures - OE:11 Testen en valideren |
Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.
Opmerking
In dit voorbeeld wordt de oplossingswerkstroom toegepast op een scenario waarin het workloadteam OCI-artefacten van openbare registers wil integreren in een ACR-exemplaar (Azure Container Registry), dat eigendom is van het workloadteam. Het team behandelt dat exemplaar als een vertrouwd artefactarchief.
De workloadomgeving maakt gebruik van Azure Policy voor Kubernetes om governance af te dwingen. Het beperkt containerremplaren alleen van het vertrouwde registerexemplaren. Daarnaast worden Azure Monitor-waarschuwingen ingesteld voor het detecteren van importbewerkingen in dat register vanuit onverwachte bronnen.
Een aanvraag voor een externe installatiekopie wordt gedaan door het workloadteam via een aangepaste toepassing die wordt gehost in Azure Web Apps. De toepassing verzamelt de vereiste gegevens alleen van geautoriseerde gebruikers.
Beveiligingscontrolepunt: de identiteit van de aanvrager, het doelcontainerregister en de aangevraagde bron van de installatiekopieën worden geverifieerd.
De aanvraag wordt opgeslagen in Azure Cosmos DB.
Beveiligingscontrolepunt: er wordt een audittrail bijgehouden in de database, waarbij de herkomst en validaties van de installatiekopie worden bijgehouden. Dit pad wordt ook gebruikt voor historische rapportage.
De aanvraag wordt verwerkt door een werkstroomorchestrator, een duurzame Azure-functie. De orchestrator maakt gebruik van een spreidingsvergaderbenadering voor het uitvoeren van alle validaties.
Beveiligingscontrolepunt: de orchestrator heeft een beheerde identiteit met just-enough toegang om de validatietaken uit te voeren.
De orchestrator doet een aanvraag om de installatiekopieën te importeren in de quarantaine Azure Container Registry (ACR) die als een niet-vertrouwd archief wordt beschouwd.
Het importproces in het quarantaineregister haalt de installatiekopieën op uit de niet-vertrouwde externe opslagplaats. Als het importeren is geslaagd, heeft het quarantaineregister een lokale kopie van de installatiekopie om validaties uit te voeren.
Beveiligingscontrolepunt: het quarantaineregister beschermt tegen manipulatie en workloadverbruik tijdens het validatieproces.
De orchestrator voert alle validatietaken uit op de lokale kopie van de installatiekopie. Taken omvatten controles zoals COMMON Vulnerabilities and Exposures (CVE) detectie, softwarefactuur van materiaalevaluatie (SBOM), malwaredetectie, afbeeldingsondertekening en andere.
De orchestrator bepaalt het type controles, de uitvoeringsvolgorde en de uitvoeringstijd. In dit voorbeeld wordt Azure Container Instance gebruikt als taaklopers en resultaten in de Cosmos DB-controledatabase. Alle taken kunnen veel tijd in beslag nemen.
Beveiligingscontrolepunt: deze stap is de kern van het quarantaineproces waarmee alle validatiecontroles worden uitgevoerd. Het type controles kan aangepaste, opensource- of door de leverancier gekochte oplossingen zijn.
De orchestrator neemt een beslissing. Als de installatiekopie alle validaties doorgeeft, wordt de gebeurtenis vermeld in de controledatabase, wordt de installatiekopie naar het vertrouwde register gepusht en wordt de lokale kopie uit het quarantaineregister verwijderd. Anders wordt de installatiekopieën uit het quarantaineregister verwijderd om onbedoeld gebruik te voorkomen.
Beveiligingscontrolepunt: de orchestrator onderhoudt segmentatie tussen vertrouwde en niet-vertrouwde resourcelocaties.
Notitie
In plaats van de orchestrator die de beslissing neemt, kan het workloadteam die verantwoordelijkheid nemen. In dit alternatief publiceert de orchestrator de validatieresultaten via een API en bewaart de installatiekopieën gedurende een bepaalde periode in het quarantaineregister.
Het workloadteam neemt de beslissing nadat de resultaten zijn bekeken. Als de resultaten voldoen aan hun risicotolerantie, halen ze de installatiekopie uit de quarantaineopslagplaats naar hun containerinstantie. Dit pull-model is praktischer wanneer dit patroon wordt gebruikt ter ondersteuning van meerdere workloadteams met verschillende beveiligingsrisicotoleranties.
Alle containerregisters worden gedekt door Microsoft Defender for Containers, die continu scant op nieuw gevonden problemen. Deze problemen worden weergegeven in Microsoft Defender Vulnerability Management.
Volgende stappen
De volgende richtlijnen zijn mogelijk relevant bij het implementeren van dit patroon:
Aanbevelingen voor het beveiligen van een ontwikkelingslevenscyclus biedt richtlijnen voor het gebruik van vertrouwde code-eenheden in alle fasen van de ontwikkelingslevenscyclus.
Best practices voor een veilige softwareleveringsketen , met name wanneer u NuGet-afhankelijkheden in uw toepassing hebt.
Documentatie voor Azure Artifacts is een bibliotheek met informatie over het beheren van softwarepakketten met Azure Artifacts.