De pijplijn en CI/CD-werkstroom beveiligen
In dit artikel wordt beschreven hoe u uw CI/CD-pijplijnen en werkstroom beveiligt.
Met automatisering en de Agile-methodologie kunnen teams sneller leveren, maar ook complexiteit toevoegen aan beveiliging, omdat de werkstroom zich uitbreidt tot de ontwikkelaarsteams zelf.
In het volgende diagram ziet u een CI/CD-werkstroom van de basislijn. Het rode configuratiepictogram 
geeft beveiligingsmachtigingen aan die door de klant moeten worden geconfigureerd. Dit volgt het model voor gedeelde verantwoordelijkheid, waarbij Azure en andere leveranciers machtigingen bieden, die door de klant moeten worden geconfigureerd volgens hun governancemodel en bedrijfsvereisten.
Laten we eens kijken naar elke fase van deze typische werkstroom, zodat u begrijpt hoe de configuraties vaak van elkaar afhankelijk zijn. Uw werkstroom kan meer fasen hebben. De volgende concepten helpen u inzicht te krijgen in CI/CD en u te helpen bij het ontwerpen van uw werkstroom voor beveiliging.
Fase 1: Git-werkstroom
Codewijzigingen, niet alleen naar software, maar ook naar pijplijn als code en infrastructuur als code, worden opgeslagen en beheerd in Git. Git is een gedistribueerde broncodebeheersoftware. Wanneer code wordt gepusht van lokale computers naar de gecentraliseerde Git-server, kunnen bedrijfsregels worden toegepast voordat deze worden geaccepteerd.
Pull-aanvragen en samenwerking
De industriestandaardwerkstroom, ongeacht uw saaS-leverancier (Software Configuration Management) software als een service (SaaS), is het gebruik van pull-aanvragen, die zowel als een geautomatiseerde kwaliteitspoortwachter als een handmatige goedkeuringsstap kunnen fungeren voordat broncode wordt geaccepteerd.
De werkstroom voor pull-aanvragen is ontworpen om gezonde wrijving te introduceren. Daarom moet deze alleen worden toegepast op beveiligde specifieke Git-vertakkingen. Met name de vertakkingen die geautomatiseerde werkstromen activeren die uw cloudresources kunnen implementeren, configureren of op een andere manier beïnvloeden. Deze vertakkingen worden beveiligde vertakkingen genoemd en volgen doorgaans naamconventies zoals production of releases/*.
Het is gebruikelijk dat pull-aanvragen het volgende vereisen:
- Peerbeoordelingen
- Continue integratie (CI)-builds doorgeven
- Handmatige goedkeuring
Als aan de vereisten wordt voldaan, worden de codewijzigingen geaccepteerd en kunnen ze worden samengevoegd.
Toegang tot beveiligde vertakkingen beperken
De werkstroom voor pull-aanvragen wordt samen met besturingselementen voor beperkte toegang gebruikt. De werkstroom voor pull-aanvragen kan echter niet worden afgedwongen, tenzij de server is geconfigureerd om directe wijzigingen in beveiligde vertakkingen af te wijzen.
Een ontwikkelaar kan niet rechtstreeks naar de production vertakking pushen, maar moet in plaats daarvan een pull-aanvraag maken die gericht is op de beveiligde vertakking. Elke SCM-leverancier heeft een andere smaak voor het bereiken van beperkte toegang tot beveiligde branches. Met GitHub is deze functie bijvoorbeeld alleen beschikbaar voor organisaties die gebruikmaken van het GitHub-team of de GitHub Enterprise-cloud.
Uw Git-toegangsmodel documentleren
Omdat het samenwerkingsmodel complex is en veel bewegende onderdelen bevat, is het handig om een tabel te maken die alle mogelijke manieren documenteert waarop codewijzigingen implementaties kunnen activeren, bijvoorbeeld:
| Naam van vertakking | Vereist pull-aanvraag? | Implementeert? | Toegang voor ontwikkelaars | Beheerderstoegang |
|---|---|---|---|---|
feat/* |
Nee | Nr. | Lezen/schrijven | Lezen/schrijven |
main |
Ja | Staging | Read | Lezen/schrijven |
production |
Ja, van main alleen |
Productie | Read | Lezen/schrijven |
Dit voorbeeld van een Git-toegangstabel is te versimpeld om het doel ervan te illustreren. In de praktijk zijn er vaak meer actoren, meer implementatiedoelen en meerdere pijplijnen die worden uitgevoerd voor verschillende use cases. De tabelstructuur kan afwijken, afhankelijk van de vereisten van uw organisatie en uw workloads.
De tabel moet u helpen bij het beantwoorden van vragen zoals:
- Als een ontwikkelaar codewijzigingen naar vertakking X pusht, wordt deze geïmplementeerd? Zo ja, naar welke omgeving?
- Op welk moment in de levenscyclus van de toepassingscode is er een scan op beveiligingsproblemen uitgevoerd?
- Als er een beveiligingsprobleem wordt gevonden, hoeveel codepushen en goedkeuringen zijn vereist voordat deze in productie terechtkomt?
Deze tabel is niet alleen handig voor foutopsporing en statische documentatie, maar ook voor teamsamenwerking. Het is transparant voor ontwikkelaars waar gezonde wrijving in de werkstroom is geïntroduceerd om prioriteit te geven aan codekwaliteit en -beveiliging. Belangrijker is dat de ontwikkelaar het verwachte pad toont voor codewijzigingen om de productie te bereiken.
Omdat DevOps een traject is, is uw Git-toegangsmodel niet statisch. Het verandert en ontwikkelt zich naarmate de teams hun eigen ritmes en volwassenheid vinden. Daarom is het belangrijk om deze documentatie zo dicht mogelijk bij de code op te slaan, bijvoorbeeld in de Git-opslagplaatsen.
Zie voor meer informatie over pull-aanvragen en beveiligde vertakkingen:
- Vertakkingsmachtigingen instellen
- Pull-aanvragen maken, weergeven en beheren
- Codekwaliteit verbeteren met vertakkingsbeleid
- Over pull-aanvragen
- Over beveiligde vertakkingen
Fase 2: Pijplijnen als code
De verplaatsing van pijplijn als code versnelde automatiseringsimplementatie en -implementaties door pijplijndefinities en -configuraties van de CI-leverancier naar de ontwikkelaars te verplaatsen, waardoor de build- en implementatielogica dichter bij de bijbehorende toepassingslogica komt. De grotere flexibiliteit hier komt ook met een grotere verantwoordelijkheid.
RBAC-besturingselementen in een pijplijn op basis van een gebruikersinterface kunnen voorkomen dat afzonderlijke gebruikers destructieve wijzigingen aanbrengen. Pijplijnen als code worden echter vaak uitgevoerd met bevoorrechte identiteiten en kunnen uw werkbelastingen vernietigen als dit wordt geïnstrueerd.
Fase 3: Uw implementatiereferenties beveiligen
Pijplijnen en codeopslagplaatsen mogen geen in code vastgelegde referenties en geheimen bevatten. Referenties en geheimen moeten ergens anders worden opgeslagen en gebruikmaken van CI-leveranciersfuncties voor beveiliging. Omdat pijplijnen worden uitgevoerd als headless agents, moeten ze nooit het wachtwoord van een persoon gebruiken. Pijplijnen moeten worden uitgevoerd met behulp van hoofdloze beveiligingsprinciplen, zoals service-principals of beheerde identiteiten. Toegang tot de referenties, database-verbindingsreeks s en API-sleutels van deze beveiligingsprincipaal moeten ook veilig worden beheerd in het CI-platform.
Hoe een referentie wordt beveiligd, poorten en goedkeuringen zijn leverancierspecifieke functies. Wanneer u een CI-platform kiest, moet u ervoor zorgen dat het alle functies ondersteunt die u nodig hebt.
Azure Pipelines is een oplossing voor continue integratie op ondernemingsniveau waarbij referenties worden opgeslagen als serviceverbindingen, waarop u goedkeuringen en controles kunt configureren. Deze configuratie omvat handmatige goedkeuring en specifieke branch- of pijplijnautorisaties.
Azure Key Vault
Als uw CI-platform dit ondersteunt, kunt u overwegen referenties op te slaan in een toegewezen geheimarchief, bijvoorbeeld Azure Key Vault. Referenties worden tijdens runtime opgehaald door de buildagent en uw kwetsbaarheid voor aanvallen wordt verminderd.
Fase 4: Uw Azure-resources beveiligen
Uw Azure-resources moeten worden beveiligd volgens het principe van minimale bevoegdheden, toegepast op zowel machtigingen als bereik.
Zie voor meer informatie:
Aangepaste rollen maken voor buildagents
CI/CD-automatisering is niet alleen van toepassing op toepassingen, maar ook op infrastructuur. IaC-sjablonen (Infrastructure as Code) zorgen voor consistente implementaties en helpen gecentraliseerde cloudplatformteams te schalen.
Het is belangrijk om te begrijpen dat IaC-automatisering fout kan gaan. Het kan onjuist worden geconfigureerd en in het slechtste geval de infrastructuur definitief verwijderen. Wanneer u uw cloudtraject plant, moet u vooraf bepalen welke bewerkingen bedrijfskritiek zijn en menselijke tussenkomst vereisen.
Beheervergrendelingen kunnen bijvoorbeeld niet worden verwijderd, kunnen worden toegepast op bedrijfskritieke resources, zoals een gegevens. Als u wilt voorkomen dat dit gebeurt, kunt u machtigingen verwijderen Microsoft.Authorization/*/Delete uit een service-principal die wordt gebruikt in CI-automatisering. In dit voorbeeld en gebruiksvoorbeeld kan de service-principal de beheervergrendeling maken , maar niet verwijderen.
Het is raadzaam om een aangepaste rol te maken voor uw CI-agents. Houd er rekening mee dat bouwagenten headless lopen en hoofdloze agents hersenloos zijn. Kies uw machtigingen zorgvuldig.
Raadpleeg voor meer informatie:
Resources
- Platformautomatisering en DevOps
- Stapsgewijze instructies voor beveiliging van pijplijnen
- Beveiliging via sjablonen
- DevSecOps in GitHub
Volgende stappen
Nu u begrijpt hoe u DevOps beveiligt, leert u meer over end-to-end-governance van DevOps naar Azure.