Governance-overwegingen voor beveiligde implementatie in Azure

De processen voor geautomatiseerde continue integratie, continue levering (CI/CD) moeten ingebouwde governance hebben die de identiteiten autoriseren en verifiëren om de taken binnen een gedefinieerd bereik uit te voeren.

Belangrijkste punten

Toegang minimaliseren

Minimaliseer het aantal personen dat toegang heeft tot beveiligde informatie of resources. Deze strategie vermindert de kans dat een kwaadwillende actor toegang krijgt of een geautoriseerde gebruiker per ongeluk een gevoelige resource beïnvloedt. Hier zijn enkele overwegingen:

• Gebruik het principe van de minste bevoegdheden bij het toewijzen van rollen en machtigingen. Alleen gebruikers die verantwoordelijk zijn voor productiereleases moeten het proces starten en alleen ontwikkelaars hebben toegang tot de broncode.

  Een pijplijn moet een of meer service-principals gebruiken. Idealiter moeten ze een beheerde identiteit zijn en worden geleverd door het platform en nooit rechtstreeks gedefinieerd in een pijplijn. De identiteit mag alleen de Azure RBAC-machtigingen hebben die nodig zijn om de taak uit te voeren. Alle service-principals moeten zijn gebonden aan die pijplijn en niet worden gedeeld tussen pijplijnen.

  Hoe definieert u CI/CD-rollen en -machtigingen?

  ---

  Azure DevOps biedt ingebouwde rollen die kunnen worden toegewezen aan afzonderlijke gebruikers van groepen. Als ingebouwde rollen onvoldoende zijn om de minste bevoegdheden voor een pijplijn te definiëren, kunt u overwegen om aangepaste Azure RBAC-rollen te maken. Zorg ervoor dat deze rollen zijn afgestemd op de actie en de teams en verantwoordelijkheden van de organisatie.

  Ter ondersteuning van de beveiliging van uw pijplijnbewerkingen kunt u gebruikers toevoegen aan een ingebouwde beveiligingsgroep, afzonderlijke machtigingen instellen voor een gebruiker of groep of gebruikers toevoegen aan vooraf gedefinieerde rollen. U beheert de beveiliging voor de volgende objecten van Azure Pipelines in de webportal, vanuit de gebruikers- of beheerderscontext.

  Zie Aan de slag met machtigingen, toegang en beveiligingsgroepen voor meer informatie.

• Voor machtigingen verleent of beperkt u machtigingen door de machtigingstoestand in te stellen op Toestaan of Weigeren, voor een beveiligingsgroep of voor een afzonderlijke gebruiker. Voor een rol voegt u een gebruiker of groep toe aan de rol.

• Gebruik afzonderlijke pijplijnidentiteiten tussen preproductie- en productieomgevingen. Indien beschikbaar, kunt u profiteren van pijplijnfuncties zoals Omgevingen om verificatie van de laatste mijl buiten de uitvoerbare pijplijn in te kapselen.

• Als de pijplijn niet vaak wordt uitgevoerd en hoge bevoegdheden heeft, kunt u overwegen om permanente machtigingen voor die identiteit te verwijderen. Gebruik JIT-roltoewijzingen (Just-In-Time), op tijd gebaseerde en op goedkeuring gebaseerde rolactivering. Deze strategie vermindert de risico's van overmatige, onnodige of verkeerd gebruik van toegangsrechten voor essentiële resources. Azure AD Privileged Identity Management ondersteunt al deze activeringsmodi.

• Controleer de CI/CD-pijplijn van de organisatie en verfijn de roltoewijzing om een duidelijke aflijning te maken tussen de ontwikkelings- en productieverantwoordelijkheden.

Meer informatie

Voor meer informatie over pijplijnmachtigingen en beveiligingsrollen, verwijzen wij u naar Verschillende niveaus van pijplijnmachtigingen instellen.

Uitvoeringsbereik

Beperk, indien praktisch, het bereik van de uitvoering in de pijplijnen.

Overweeg een pijplijn met meerdere fases te maken. Verdeel het werk in afzonderlijke eenheden en die kunnen worden geïsoleerd in een afzonderlijke pijplijn. Beperk de identiteiten alleen tot het bereik van de eenheid, zodat deze minimale bevoegdheden heeft om de actie uit te voeren. U kunt bijvoorbeeld twee eenheden hebben, één om te implementeren en een andere die broncode bouwt. Sta alleen de implementatie-eenheid toegang tot de identiteit toe, niet de build-eenheid. Als er met de build-eenheid is geknoeid, kan er met de infrastructuur worden geknoeid.

Gated-goedkeuringsproces

Zijn er goedkeuringen voor de releasepoort geconfigureerd in het DevOps-releaseproces?

Pull-aanvragen en codebeoordelingen fungeren als de eerste goedkeuringsregel tijdens de ontwikkelingscyclus. Voordat u een update voor productie uit brengt, moet u een proces hebben dat beveiligingsbeoordeling en goedkeuring vereist.

Zorg ervoor dat u het beveiligingsteam bij het plannings-, ontwerp- en DevOps-proces betrekken. Deze samenwerking helpt ze bij het implementeren van beveiligingscontroles, controle- en responsprocessen.

Worden vertakkingsbeleidsregels gebruikt voor broncodebeheer van deze workload? Hoe worden ze geconfigureerd?

Stel vertakkingsbeleidsregels in die een extra niveau van controle bieden over de code die wordt vastgelegd in de opslagplaats. Het is gebruikelijk om pushes naar de main branch als de wijziging niet is goedgekeurd. U kunt bijvoorbeeld pull-aanvraag (PR) met codebeoordeling vereisen voordat u de wijzigingen samenvoegt door ten minste één revisor, anders dan de auteur van de wijziging.

Het is raadzaam om meerdere vertakkingen te gebruiken wanneer elke vertakking een doel- en toegangsniveau heeft. Functie-vertakkingen worden bijvoorbeeld gemaakt door ontwikkelaars en zijn open voor push. Integratievertakking vereist pr en codebeoordeling. Voor de productiebranche is een andere goedkeuring van de teamleider vereist voordat deze wordt samengevoegd.

Verwante koppelingen

Terug het hoofdartikel: Veilige implementatie en testen in Azure