Erweitertes Sicherheitsmanagement

Mit diesem Update haben Sie jetzt die Möglichkeit, erweiterte Sicherheit für Ihr gesamtes Projekt oder organization zu aktivieren oder zu deaktivieren. Sie können advanced Security auch automatisch für alle neu erstellten Repositorys oder Projekte aktivieren.

In Azure Pipelines haben wir ein zentrales Steuerelement hinzugefügt, um die Sicherheit von Pull Requests zu verbessern, die aus ge forkierten GitHub-Repositorys erstellt wurden.

Weitere Informationen zu diesen Features finden Sie in den Versionshinweisen.

Allgemein

Azure Pipelines

Azure Repos

Azure Artifacts

Allgemein

Projekt- und organization-Level-Aktivierung für erweiterte Sicherheit

Sie können erweiterte Sicherheit jetzt für Ihr gesamtes Projekt oder organization aktivieren oder deaktivieren. In Verbindung mit der neuen Hinzufügung der Committeranzahl vor der Aktivierung erhalten Sie durch Auswählen von "Alle aktivieren" auf Projekt- oder organization-Ebene eine Schätzung, wie viele neue aktive Committer Ihnen in Rechnung gestellt werden können. Sie können advanced Security auch automatisch für alle neu erstellten Repositorys oder Projekte unter Ihrem jeweiligen Projekt oder organization aktivieren. Bei allen Repositorys, die über diese Einstellung aktiviert werden, ist die Überprüfung des geheimen Repositorys und der Pushschutz aktiv.

Aktivierung auf Projektebene:

Screenshot der Aktivierung auf Projektebene.

Aktivierung auf Organisationsebene:

Screenshot der Aktivierung auf Organisationsebene.

Geschätzte Committeranzahl während der erweiterten Sicherheitsaktivierung

Im Rahmen Ihres Advanced Security-Onboardings können Sie jetzt eine Schätzung anzeigen, wie viele aktive Committer möglicherweise hinzugefügt wurden, nachdem Advanced Security für ein bestimmtes Repository, ein bestimmtes Projekt oder ein bestimmtes organization aktiviert wurde. Diese Anzahl ist eine Näherung, und sie können geringfügige Abweichungen zwischen der bereitgestellten Schätzung und dem, was nach der Aktivierung für die Abrechnung gemeldet wird, feststellen. Diese Schätzung kann auch über die API abgerufen werden, wobei in Kürze eine zusätzliche Dokumentation zur Erläuterung dieses Prozesses verfügbar ist.

Screenshot der Erweiterten Sicherheitsaktivierung.

Azure Pipelines

Wiederholen sie eine Phase, in der genehmigungs- und checkout

Wenn für Genehmigungen und Überprüfungen ein Timeout aussteht, wird die Phase, zu der sie gehören, übersprungen. Phasen, die eine Abhängigkeit von der übersprungenen Phase aufweisen, werden ebenfalls übersprungen.

Jetzt können Sie eine Phase wiederholen, in der das Timeout für Genehmigungen und Überprüfungen erfolgt. Bisher war dies nur möglich, wenn eine Genehmigung ein Timeout hatte.

Screenshot: Wiederholung der Phase.

Administratorrolle für alle Umgebungen

Umgebungen in YAML-Pipelines stellen eine Computeressource dar, für die Sie Ihre Anwendung bereitstellen, z. B. einen AKS-Cluster oder eine Reihe von VMs. Sie bieten Ihnen Sicherheitskontrollen und Rückverfolgbarkeit für Ihre Bereitstellungen.

Die Verwaltung von Umgebungen kann eine große Herausforderung darstellen. Dies liegt daran, dass die Person, die sie erstellt, beim Erstellen einer Umgebung automatisch zum alleinigen Administrator wird. Wenn Sie beispielsweise die Genehmigungen und Überprüfungen aller Umgebungen zentral verwalten möchten, müssen Sie jeden Umgebungsadministrator bitten, einen bestimmten Benutzer oder eine bestimmte Gruppe als Administrator hinzuzufügen und dann die REST-API zum Konfigurieren der Überprüfungen zu verwenden. Dieser Ansatz ist mühsam, fehleranfällig und skaliert nicht, wenn neue Umgebungen hinzugefügt werden.

Mit diesem Sprint haben wir eine Administratorrolle auf der Ebene von environments-hub hinzugefügt. Dadurch werden Umgebungen mit Dienstverbindungen oder Agentpools gleichauf. Um einem Benutzer oder einer Gruppe die Rolle Administrator zuzuweisen, müssen Sie bereits ein Umgebungen-Hub-Administrator oder organization-Besitzer sein.

Screenshot der Rolle

Ein Benutzer mit dieser Administratorrolle kann Berechtigungen verwalten, verwalten, anzeigen und verwenden. Dies schließt die Öffnung von Umgebungen für alle Pipelines ein.

Wenn Sie einer Benutzeradministratorrolle auf Der Ebene von umgebungen-hubs zugewiesen werden, werden sie zu Administratoren für alle vorhandenen Umgebungen und für alle zukünftigen Umgebungen.

Zentrale Steuerung zum Erstellen von PRs aus ge forkierten GitHub-Repositorys

Wenn Sie öffentliche Repositorys in GitHub erstellen, müssen festlegen, wie mit Forkbuilds umzugehen ist. Forks sind besonders gefährlich, da sie von Quellen außerhalb Ihrer Organisation kommen.

Sie können die Sicherheit von Pipelines verbessern, die öffentliche GitHub-Repositorys erstellen, indem Sie unsere Empfehlungen zum Erstellen von GitHub-Repositorys und zum Repositoryschutz lesen. Leider kann die Verwaltung zahlreicher Pipelines und die Sicherstellung ihrer Einhaltung bewährter Methoden einen erheblichen Aufwand erfordern.

Um die Sicherheit Ihrer Pipelines zu erhöhen, haben wir ein Steuerelement auf organization-Ebene hinzugefügt, um zu definieren, wie Pipelines PRs aus forkierten GitHub-Repositorys erstellen. Die neue Einstellung heißt Limit building pull requests from forked GitHub repositorys and funktioniert auf organization- und Projektebene.

Die Einstellung organization-Ebene schränkt die Einstellungen ein, die Projekte haben können, und die Einstellung auf Projektebene schränkt die Einstellungen ein, die Pipelines haben können.

Sehen wir uns an, wie der Umschalter auf organization Ebene funktioniert. Das neue Steuerelement ist standardmäßig deaktiviert, sodass keine Einstellungen universell erzwungen werden.

Screenshot: Umschalten organization Ebene

Wenn Sie die Umschaltfläche aktivieren, können Sie das Erstellen von PRs aus geschmiedeten GitHub-Repositorys deaktivieren. Das bedeutet, dass keine Pipeline ausgeführt wird, wenn ein solcher PR erstellt wird.

Screenshot: Ein-Umschalten

Wenn Sie die Option Sicheres Erstellen von Pull requests aus forkierten Repositorys auswählen, können alle Pipelines, organization-weit, keine Geheimnisse für PRs-Builds aus forkierten Repositorys verfügbar machen, können diese Builds nicht die gleichen Berechtigungen wie normale Builds haben und müssen durch einen PR-Kommentar ausgelöst werden. Projekte können trotzdem entscheiden, dass Pipelines solche PRs nicht erstellen dürfen.

Screenshot: Sicheres Erstellen von PR.

Wenn Sie die Option Anpassen auswählen, können Sie definieren, wie Pipelineeinstellungen eingeschränkt werden sollen. Sie können beispielsweise sicherstellen, dass alle Pipelines einen Kommentar benötigen, um einen PR aus einem ge forkierten GitHub-Repository zu erstellen, wenn der PR Nicht-Teammitgliedern und Nicht-Mitwirkenden gehört. Sie können jedoch zulassen, dass sie Geheimnisse für solche Builds verfügbar machen. Projekte können entscheiden, dass Pipelines solche PRs nicht erstellen oder sicher erstellen oder noch restriktivere Einstellungen als auf organization Ebene festlegen.

Screenshot: Anpassen.

Azure Repos

Neue "Branchrichtlinie" verhindert, dass Benutzer ihre eigenen Änderungen genehmigen können

Um die Kontrolle darüber zu verbessern, welche Änderungen der Benutzer genehmigen und strengeren gesetzlichen/Compliance-Anforderungen entsprechen, bieten wir eine Option, um zu verhindern, dass Benutzer eigene Änderungen genehmigen, sofern dies nicht explizit zulässig ist.

Benutzer mit der Möglichkeit, die Branchrichtlinien zu verwalten, können jetzt die neu hinzugefügte Option "Mindestens eine Genehmigung für jede Iteration anfordern" unter "Wenn neue Änderungen pusht werden" wechseln. Wenn diese Option ausgewählt ist, ist mindestens eine Genehmigungsstimme für die letzte Quellbranchänderung erforderlich. Die Zustimmung des Benutzers wird nicht für eine vorherige nicht genehmigte Iteration gezählt, die von diesem Benutzer gepusht wurde. Daher ist eine zusätzliche Genehmigung für die letzte Iteration von einem anderen Benutzer erforderlich.

Die folgende Abbildung zeigt pull request created by user A and additional 4 commits (iterations), die von den Benutzern B, C, A und C für diesen Pull Request erstellt wurden. Nachdem die zweite Iteration (Commit durch Benutzer B) abgeschlossen wurde, hat Benutzer C dies genehmigt. Zu diesem Zeitpunkt implizierte dies die Genehmigung des ersten Commits von Benutzer A (beim Erstellen des Pull Request) und die neu eingeführte Richtlinie wird erfolgreich sein. Nach der fünften Iteration (letzter Commit von Benutzer C) wurde die Genehmigung durch Benutzer A durchgeführt. Diese implizierte Genehmigung für einen früheren Commit, der von Benutzer C durchgeführt wurde, implizierte aber nicht die Genehmigung für den zweiten Commit, der von Benutzer A in der vierten Iteration durchgeführt wurde. Damit die neu eingeführte Richtlinie erfolgreich ist, muss die nicht genehmigte Iteration 4 entweder durch Genehmigung von Benutzer B, C oder einem anderen Benutzer genehmigt werden, der keine Änderung am Pull Request vorgenommen hat.

Berechtigungsverwaltungsimage.

Azure Artifacts

Einführung in Azure Artifacts-Unterstützung für Cargo Crates (öffentliche Vorschau)

Wir freuen uns, ihnen mitteilen zu können, dass Azure Artifacts jetzt native Unterstützung für Cargo-Kisten bietet. Diese Unterstützung umfasst featureparität in Bezug auf unsere vorhandenen Protokolle, zusätzlich zu crates.io als Upstream Quelle verfügbar zu sein. Rust-Entwickler und -Teams können ihre Cargo-Kisten jetzt nahtlos nutzen, veröffentlichen, verwalten und freigeben, während sie die robuste Infrastruktur von Azure nutzen und in der vertrauten Azure DevOps-Umgebung bleiben.

Für die Vorschau ist keine Registrierung erforderlich. Sie können zunächst zu Ihrem Azure DevOps-Projekt navigieren, Artefakte auswählen und die Anweisungen zum Verbinden Ihres Rust-Projekts mit Ihrem Azure Artifacts-Feed befolgen.

Nächste Schritte

Hinweis

Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.

Wechseln Sie zu Azure DevOps, und sehen Sie sich an.

Senden von Feedback

Wir würden uns freuen zu hören, was Sie über diese Features denken. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Screenshot Machen Sie einen Vorschlag.

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Vielen Dank,

Silviu Andrica