Neue Richtlinien für persönliche Zugriffstoken

In diesem Sprint haben wir neue Richtlinien hinzugefügt, um den Umfang und die Lebensdauer von persönlichen Zugriffstoken (PAT) einzuschränken. Darüber hinaus haben wir die Windows Shell-Erweiterung Team Foundation-Versionskontrolle (TFVC) aktualisiert, um Visual Studio 2019 zu unterstützen.

Weitere Informationen finden Sie in den folgenden Funktionsbeschreibungen.

Allgemein

• Einschränken des Bereichs und der Lebensdauer von persönlichen Zugriffstoken (Personal Access Token, PAT) über die Azure AD-Mandantenrichtlinie
• Unterstützung von Richtlinien für bedingten Zugriff für IPv6-Datenverkehr

Azure Pipelines

• Beibehalten von Pipelines, die in anderen Pipelines verwendet werden
• Änderungen bei der automatischen Erstellung von Umgebungen
• Entfernen des Insights-Dialogs aus der Buildpipeline

Azure Repos

• Updates zu Team Foundation-Versionskontrolle Windows Shell-Erweiterung (TFVC) für VS 2019

Allgemein

Einschränken des Bereichs und der Lebensdauer von persönlichen Zugriffstoken (Personal Access Token, PAT) über die Azure AD-Mandantenrichtlinie

Persönliche Zugriffstoken (PATs) erleichtern die Authentifizierung bei Azure DevOps, um sie in Ihre Tools und Dienste zu integrieren. Allerdings können durch kompromittierte Token Ihr Azure DevOps-Konto und Ihre Daten kompromittiert werden, wodurch Ihre Anwendungen und Dienste gefährdet werden.

Wir haben Feedback erhalten, dass Administratoren nicht über die erforderlichen Kontrollen verfügen, um die Bedrohungsoberfläche zu begrenzen, die durch kompromittierte PATs verursacht wird. Basierend auf diesem Feedback haben wir eine neue Gruppe von Richtlinien hinzugefügt, die verwendet werden können, um den Umfang und die Lebensdauer der persönlichen Zugriffstoken (PaTs) Ihrer organization zu beschränken! So funktionieren sie:

Benutzer, die der Azure DevOps-Administratorrolle in Azure Active Directory zugewiesen sind, können in den organization Einstellungen aller Azure DevOps-organization, die mit ihrer Azure AD verknüpft sind, zur Registerkarte Azure Active Directory navigieren.

Administratoren haben dort folgende Möglichkeiten:

1. die Erstellung globaler persönlicher Zugangstoken einschränken (Token, die für alle Azure DevOps-Organisationen funktionieren, auf die der Benutzer Zugriff hat)
2. die Erstellung von persönlichen Zugriffstokens mit vollem Umfang einschränken
3. eine maximale Lebensdauer für neue persönliche Zugriffstokens festlegen

Diese Richtlinien gelten für alle neuen PATs, die von Benutzern für Azure DevOps-Organisationen erstellt wurden, die mit dem Azure AD-Mandanten verknüpft sind. Jede der Richtlinien verfügt über eine Zulassungsliste für Benutzer und Gruppen, die von der Richtlinie ausgenommen werden sollen. Die Liste der Benutzer und Gruppen in der Liste Zulassen hat keinen Zugriff auf die Verwaltung der Richtlinienkonfiguration.

Diese Richtlinien gelten nur für neue PATs und wirken sich nicht auf vorhandene PATs aus, die bereits erstellt wurden und verwendet werden. Nachdem die Richtlinien aktiviert wurden, müssen jedoch alle vorhandenen, jetzt nicht konformen PATs aktualisiert werden, damit sie innerhalb der Einschränkungen sind, bevor sie verlängert werden können.

Unterstützung von Richtlinien für bedingten Zugriff für IPv6-Datenverkehr

Wir erweitern jetzt die Unterstützung von Richtlinien für bedingten Zugriff (Cap) um IPv6-Fencingrichtlinien. Da wir sehen, dass Benutzer zunehmend über IPv6-Adressen auf Azure DevOps-Ressourcen auf Geräten zugreifen, möchten wir sicherstellen, dass Ihre Teams so ausgestattet sind, dass sie zugriff auf jede IP-Adresse gewähren und entfernen können, einschließlich derjenigen, die von IPv6-Datenverkehr stammen.

Azure Pipelines

Beibehalten von Pipelines, die in anderen Pipelines verwendet werden

Klassische Releases hatten die Möglichkeit, builds, die sie nutzen, automatisch beizubehalten. Dies war eine der Lücken zwischen klassischen Releases und YAML-Pipelines und verhinderte, dass einige von Ihnen zu YAML wechseln. Mit dieser Version haben wir diese Lücke behoben.

Jetzt können Sie eine mehrstufige YAML-Pipeline erstellen, um Ihr Release darzustellen, und eine weitere YAML-Pipeline darin als Ressource nutzen. Wenn Sie dies tun, behält Azure Pipelines die Ressourcenpipeline automatisch bei, solange die Releasepipeline beibehalten wird. Wenn die Releasepipeline gelöscht wird, wird die Lease für die Ressourcenpipeline freigegeben, und es werden eigene Aufbewahrungsrichtlinien befolgt.

Änderungen bei der automatischen Erstellung von Umgebungen

Wenn Sie eine YAML-Pipeline erstellen und auf eine Umgebung verweisen, die nicht vorhanden ist, erstellt Azure Pipelines die Umgebung automatisch. Diese automatische Erstellung kann entweder im Benutzerkontext oder im Systemkontext erfolgen. In den folgenden Flows kennt Azure Pipelines den Benutzer, der den Vorgang ausführt:

• Sie verwenden den Assistenten für die YAML-Pipelineerstellung in der Azure Pipelines-Weboberfläche und verweisen auf eine Umgebung, die noch nicht erstellt wurde.
• Sie aktualisieren die YAML-Datei mithilfe des Azure Pipelines-Webeditors und speichern die Pipeline, nachdem Sie einen Verweis auf eine Umgebung hinzugefügt haben, die nicht vorhanden ist.

In jedem der oben genannten Fälle verfügt Azure Pipelines über ein klares Verständnis des Benutzers, der den Vorgang ausführt. Daher wird die Umgebung erstellt und der Benutzer der Administratorrolle für die Umgebung hinzugefügt. Dieser Benutzer verfügt über alle Berechtigungen, um die Umgebung zu verwalten und/oder andere Benutzer in verschiedene Rollen für die Verwaltung der Umgebung einzuschließen.

In den folgenden Flows verfügt Azure Pipelines nicht über Informationen zum Benutzer, der die Umgebung erstellt: Sie aktualisieren die YAML-Datei mithilfe eines anderen externen Code-Editors, fügen einen Verweis auf eine Umgebung hinzu, die nicht vorhanden ist, und sorgen dann für das Auslösen einer manuellen oder Continuous Integration-Pipeline. In diesem Fall kennt Azure Pipelines den Benutzer nicht. Zuvor haben wir diesen Fall behandelt, indem wir alle Projektmitwirkenden der Administratorrolle der Umgebung hinzugefügt haben. Jedes Mitglied des Projekts konnte dann diese Berechtigungen ändern und verhindern, dass andere auf die Umgebung zugreifen.

Wir haben Ihr Feedback zum Erteilen von Administratorberechtigungen für eine Umgebung für alle Mitglieder eines Projekts erhalten. Als wir Ihr Feedback gehört haben, haben wir gehört, dass wir keine automatische Umgebung erstellen sollten, wenn nicht klar ist, wer der Benutzer ist, der den Vorgang ausführt. Mit dieser Version haben wir Änderungen an der automatischen Erstellung von Umgebungen vorgenommen:

• In Zukunft wird bei Pipelineausführungen nicht automatisch eine Umgebung erstellt, wenn sie nicht vorhanden ist und der Benutzerkontext nicht bekannt ist. In solchen Fällen schlägt die Pipeline mit dem Fehler Umgebung nicht gefunden fehl. Sie müssen die Umgebungen mit der richtigen Sicherheits- und Überprüfungskonfiguration vorab erstellen, bevor Sie sie in einer Pipeline verwenden.
• Pipelines mit bekanntem Benutzerkontext erstellen weiterhin automatisch Umgebungen wie in der Vergangenheit.
• Abschließend ist zu beachten, dass das Feature zum automatischen Erstellen einer Umgebung nur hinzugefügt wurde, um die ersten Schritte mit Azure Pipelines zu vereinfachen. Es war für Testszenarien gedacht und nicht für Produktionsszenarien. Sie sollten immer Produktionsumgebungen mit den richtigen Berechtigungen und Überprüfungen vorab erstellen und diese dann in Pipelines verwenden.

Entfernen des Insights-Dialogs aus der Buildpipeline

Basierend auf Ihrem Feedback wurde das Dialogfeld "Aufgaben-/Pipelineeinblicke", das beim Navigieren in der Buildpipeline angezeigt wird, entfernt, um den Workflow zu verbessern. Die Pipelineanalysen sind weiterhin verfügbar, damit Sie über die erforderlichen Erkenntnisse verfügen.

Azure Repos

Updates zu Team Foundation-Versionskontrolle (TFVC) Windows Shell-Erweiterung für Visual Studio 2019

Die vorherige Version der TFVC Windows Shell-Erweiterung funktionierte nur auf Computern, auf denen Visual Studio 2017 installiert war.

Wir haben eine neue Version dieses Tools veröffentlicht, die mit Visual Studio 2019 kompatibel ist. Die Erweiterung ermöglicht die Integration in Windows Explorer und die allgemeinen Dateidialoge. Mit dieser Integration können Sie viele Quellcodeverwaltungsvorgänge ausführen, ohne Visual Studio oder ein Team Foundation-Befehlszeilentool ausführen zu müssen.

Nächste Schritte

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

Senden von Feedback

Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag zu machen.

Sie können auch Rat und Ihre Fragen von der Community auf Stack Overflow beantworten lassen.

Vielen Dank,

Vijay Machiraju