Verbeterd beveiligingsbeheer

Met deze update hebt u nu de mogelijkheid om Geavanceerde beveiliging voor uw hele project of organisatie in of uit te schakelen. U kunt geavanceerde beveiliging ook automatisch inschakelen voor nieuwe opslagplaatsen of projecten.

In Azure Pipelines hebben we een gecentraliseerd besturingselement toegevoegd om de beveiliging van pull-aanvragen te verbeteren die zijn gebouwd op basis van geforkte GitHub-opslagplaatsen.

Bekijk de releaseopmerkingen voor meer informatie over deze functies.

General

• Inschakeling op project- en organisatieniveau voor geavanceerde beveiliging

• Geschat aantal committers tijdens inschakeling van geavanceerde beveiliging

Azure-pipelines

• Herhaal een fase als goedkeuringen en verificaties verlopen

• Beheerdersrol voor alle omgevingen

• Gecentraliseerde controle voor het aanmaken van pull-aanvragen vanuit geforkte GitHub-opslagplaatsen

Azure Repos

• Nieuw vertakkingsbeleid waardoor gebruikers hun eigen wijzigingen niet kunnen goedkeuren

Azure Artifacts

• Introductie van Azure Artifacts-ondersteuning voor Cargo Crates (openbare preview)

General

Inschakeling op project- en organisatieniveau voor geavanceerde beveiliging

U kunt advanced security nu in- of uitschakelen voor uw hele project of organisatie. In combinatie met de nieuwe toevoeging die het aantal committers weergeeft vóór de activatie, krijgt u bij het selecteren van 'Alles inschakelen' op project- of organisatieniveau een schatting van het aantal nieuwe actieve committers waarvoor u mogelijk gefactureerd zult worden. U kunt er ook voor kiezen om Advanced Security automatisch in te schakelen voor nieuwe opslagplaatsen of projecten onder uw respectieve project of organisatie. Alle opslagplaatsen die via deze instelling zijn ingeschakeld, hebben het scannen van geheime opslagplaatsen en pushbeveiliging actief.

Inschakeling op projectniveau:

Inschakeling op organisatieniveau:

Geschat aantal committers tijdens het inschakelen van geavanceerde beveiliging

Als onderdeel van uw onboardingproces voor Geavanceerde beveiliging kunt u nu een schatting zien van hoeveel actieve committers zijn toegevoegd door het inschakelen van Geavanceerde beveiliging voor een bepaalde repository, project of organisatie. Dit aantal is een benadering en u ziet mogelijk kleine verschillen tussen de opgegeven schatting en wat wordt gerapporteerd voor facturering na inschakeling. Deze schatting kan ook worden verkregen via API met aanvullende documentatie waarin wordt uitgelegd dat dit proces binnenkort beschikbaar is.

Azure-pipelines

Probeer een fase opnieuw wanneer goedkeuringen en controles een time-out ondergaan.

Bij een time-out van goedkeuringen en controles wordt de fase waartoe ze behoren overgeslagen. Fasen met een afhankelijkheid van de overgeslagen fase worden ook overgeslagen.

U kunt nu een fase opnieuw uitvoeren bij een time-out van goedkeuringen en tests. Voorheen was dit alleen mogelijk als er een time-out optrad bij een goedkeuring.

Beheerdersrol voor alle omgevingen

Omgevingen in YAML-pijplijnen vertegenwoordigen een rekenresource waarnaar u uw toepassing implementeert, bijvoorbeeld een AKS-cluster of een set virtuele machines. Ze bieden u beveiligingscontroles en traceerbaarheid voor uw implementaties.

Het beheren van omgevingen kan behoorlijk lastig zijn. Dit komt doordat wanneer een omgeving wordt gemaakt, de persoon die deze maakt, automatisch de enige beheerder wordt. Als u bijvoorbeeld de goedkeuringen en controles van alle omgevingen op gecentraliseerde wijze wilt beheren, moet u elke omgevingsbeheerder vragen om een specifieke gebruiker of groep toe te voegen als beheerder en vervolgens REST API gebruiken om de controles te configureren. Deze aanpak is tijdrovend, foutgevoelig en schaalt niet wanneer er nieuwe omgevingen worden toegevoegd.

Met deze sprint hebben we een beheerdersrol toegevoegd op het niveau van de omgevingen-hub. Dit brengt omgevingen op niveau met serviceverbindingen of agentpools. Als u de beheerdersrol wilt toewijzen aan een gebruiker of groep, moet u al een omgevingshubbeheerder of organisatie-eigenaar zijn.

Een gebruiker met deze beheerdersrol kan machtigingen beheren, beheren, weergeven en gebruiken in elke omgeving. Dit omvat het openen van omgevingen voor alle pijplijnen.

Wanneer u een gebruikersbeheerderrol op omgevingsniveau verleent, worden ze beheerders voor alle bestaande omgevingen en voor toekomstige omgevingen.

Gecentraliseerd beheer voor het bouwen van PR's vanuit geforkte GitHub-opslagplaatsen

Als u openbare opslagplaatsen bouwt vanuit GitHub, moet u rekening houden met uw houding bij fork-builds. Forks zijn vooral gevaarlijk omdat ze afkomstig zijn van buiten uw organisatie.

U kunt de beveiliging verbeteren van pijplijnen die openbare GitHub-opslagplaatsen bouwen door onze aanbevelingen te bekijken over het bouwen van GitHub-opslagplaatsen en de beveiliging van opslagplaatsen. Helaas kan het beheren van talloze pijplijnen en ervoor zorgen dat hun naleving van best practices een aanzienlijke hoeveelheid inspanning vergt.

Om de beveiliging van uw pijplijnen te verbeteren, hebben we een controle op organisatieniveau toegevoegd voor het definiëren van hoe pijplijnen PR's bouwen vanuit geforkte GitHub-opslagplaatsen. De nieuwe instelling heet Beperk pull-aanvragen bouwen vanaf geforkte GitHub-repositories en werkt op organisatie- en projectniveau.

De instelling op organisatieniveau beperkt de instellingen die projecten kunnen hebben en de instelling op projectniveau beperkt de instellingen die pijplijnen kunnen hebben.

Laten we eens kijken hoe de wisselknop werkt op organisatieniveau. Het nieuwe besturingselement is standaard uitgeschakeld, dus er worden geen instellingen universeel afgedwongen.

Wanneer u de wisselknop inschakelt, kunt u ervoor kiezen om bouw-PULL's uit te schakelen vanuit geforkte GitHub-opslagplaatsen. Dit betekent dat er geen pijplijn zal draaien wanneer een dergelijke pull request wordt gemaakt.

Wanneer u de optie Beveiligd bouwen van pullverzoeken vanuit geforkte repositories kiest, kunnen alle pijplijnen op organisatieniveau niet geheimen beschikbaar maken voor builds van pullverzoeken vanuit geforkte repositories, kunnen deze builds niet dezelfde machtigingen hebben als normale builds, en moeten worden geactiveerd door een pullverzoekopmerking. Projecten kunnen nog steeds besluiten om pijplijnen niet toe te staan om dergelijke pull requests op te zetten.

Wanneer u de optie Aanpassen kiest, kunt u definiëren hoe u de pijplijninstellingen kunt beperken. U kunt er bijvoorbeeld voor zorgen dat voor alle pijplijnen een opmerking is vereist om een PR te maken vanuit een gevorkte GitHub-opslagplaats, wanneer de PR afkomstig is van niet-teamleden en niet-bijdragers. U kunt er echter voor kiezen om geheimen beschikbaar te maken voor dergelijke builds. Projecten kunnen besluiten om niet toe te staan dat pijplijnen zulke PR's bouwen, of om ze veilig te laten bouwen, of nog restrictievere instellingen aan te houden dan wat er op organisatieniveau is vastgelegd.

Azure Repos

Nieuw vertakkingsbeleid waardoor gebruikers hun eigen wijzigingen niet kunnen goedkeuren

Om de controle te verbeteren over de wijzigingen die de gebruiker goedkeurt en voldoet aan strengere wettelijke/nalevingsvereisten, bieden we een optie om te voorkomen dat de gebruiker zijn eigen wijzigingen goedkeurt, tenzij dit expliciet is toegestaan.

Gebruiker met de mogelijkheid om het vertakkingsbeleid te beheren, kan nu de zojuist toegevoegde optie 'Ten minste één goedkeuring vereisen voor elke iteratie' onder 'Wanneer nieuwe wijzigingen worden gepusht' overschakelen. Wanneer deze optie is geselecteerd, is ten minste één goedkeuringsstem vereist voor de laatste wijziging van de bronbranch. De goedkeuring van de gebruiker wordt niet meegeteld bij een eerdere niet-goedgekeurde iteratie die door die gebruiker wordt gepusht. Als gevolg hiervan is aanvullende goedkeuring vereist voor de laatste iteratie door een andere gebruiker.

In de volgende afbeelding ziet u een pull-aanvraag die is gemaakt door gebruiker A en 4 doorvoeringen (iteraties) die zijn gemaakt voor die pull-aanvraag door gebruikers B, C, A en C. Nadat de tweede iteratie (doorvoer uitgevoerd door gebruiker B) is uitgevoerd, heeft gebruiker C dat goedgekeurd. Op dat moment werd goedkeuring van de eerste commit van gebruiker A geïmpliceerd (toen het pull-verzoek werd aangemaakt) en zal het pas geïntroduceerde beleid van kracht worden. Na de vijfde iteratie (laatste doorvoering van gebruiker C) is de goedkeuring uitgevoerd door gebruiker A. Deze impliciete goedkeuring voor eerdere doorvoering door gebruiker C, maar impliceerde geen goedkeuring voor de tweede door gebruiker A uitgevoerde doorvoer in de vierde iteratie. Als u het zojuist geïntroduceerde beleid wilt voltooien, moet de niet-goedgekeurde iteratie vier worden goedgekeurd door goedkeuring van gebruiker B, C of een andere gebruiker die geen wijzigingen heeft aangebracht in de pull-aanvraag.

Azure Artifacts

Introductie van Azure Artifacts-ondersteuning voor Cargo Crates (openbare preview)

We zijn verheugd om aan te kondigen dat Azure Artifacts nu systeemeigen ondersteuning biedt voor Cargo-kratten. Deze ondersteuning omvat functiegelijkheid met betrekking tot onze bestaande protocollen, naast dat crates.io beschikbaar is als een upstream-bron. Rust-ontwikkelaars en -teams kunnen nu naadloos hun Cargo-kratten gebruiken, publiceren, beheren en delen, terwijl ze gebruikmaken van de robuuste infrastructuur van Azure en in de vertrouwde Azure DevOps-omgeving blijven.

Er is geen registratie nodig voor de preview; U kunt aan de slag door naar uw Azure DevOps-project te navigeren, Artefacten te selecteren en de instructies te volgen om uw Rust-project te verbinden met uw Azure Artifacts-feed.

Volgende stappen

Ga naar Azure DevOps en kijk eens.

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.

Bedankt

Gepleiu Andrica