Ändern der Projekttransparenz zu öffentlich oder privat

Azure DevOps Services

Erfahren Sie, wie Sie die Sichtbarkeit Ihres Azure DevOps-Projekts zwischen öffentlich und privat ändern und die Sicherheits- und Zugriffsauswirkungen jeder Sichtbarkeitseinstellung verstehen.

Von Bedeutung

Wenn Sie ein privates Projekt in die öffentliche Sichtbarkeit ändern, werden alle Projektinhalte öffentlich zugänglich. Bestimmte Repositories, Bereichspfade oder Build-Artefakte können in einem öffentlichen Projekt nicht selektiv privat gehalten werden.
Nur Organisationen mit bereits aktivierter "Öffentliche Projektrichtlinie zulassen" können Projekte erstellen oder die Sichtbarkeit eines Projekts auf öffentlich ändern. Die Richtlinie ist nicht mehr für Organisationen verfügbar, die sie noch nicht verwenden. Microsoft empfiehlt die Verwendung von GitHub für alle Ihre öffentlichen Projektanforderungen.

Was ändert sich, wenn Sie ein Projekt öffentlich machen

Das Öffentliche Erstellen eines Projekts wirkt sich auf Berechtigungen, Zugriffsebenen und verfügbare Features aus:

Sicherheits- und Berechtigungsänderungen

Wenn Sie die Projektsichtbarkeit von privat zu öffentlich wechseln, treten die folgenden Änderungen auf:

Ablehnungsberechtigungen werden ignoriert: Alle berechtigungen, die explizit auf "Verweigern" festgelegt sind, werden für öffentliche Benutzer nicht erzwungen.
Mindestzugriff gewährt: Nichtmitglieder erhalten automatisch den grundlegenden Lesezugriff auf öffentliche Inhalte.
Buildpipelinebereich: Pipelines, die auf den Projektsammlungsbereich festgelegt sind, werden automatisch mit Project-Bereich ausgeführt, um die Sicherheit zu verbessern.

Unterschiede auf Zugriffsebene

Benutzertyp	Privater Projektzugriff	Öffentlicher Projektzugriff
Anonyme Benutzer	Kein Zugriff	Schreibgeschützter Zugriff auf die meisten Inhalte
Projektbeteiligte	Eingeschränkter Boards-Zugriff, kein Repos-Zugriff	Vollzugriff auf Repos und Boards
Grundlegende Benutzer	Vollzugriff mit Ausnahme von Testplänen	Vollzugriff mit Ausnahme von Testplänen
Grundlegend + Testpläne	Vollzugriff einschließlich Testplänen	Vollzugriff einschließlich Testplänen

Verfügbarkeit von Funktionen für Nichtmitglieder

Die folgende Tabelle zeigt, welche Features für Benutzer verfügbar sind, die keine Projektmitglieder sind:

Dienstbereich	Nicht-Benutzerzugriff	Hinweise
Dashboards	Schreibgeschützte, limitierte Widgets	Viele Widgets sind nicht verfügbar
Wiki	Schreibgeschützt	Vollständiger Inhalt sichtbar
Boards	Nur Arbeitsaufgaben lesen	Backlogs, Boards, Sprints ausgeblendet
Repos	Schreibgeschützte Git-Repos	TFVC-Repositorys ausgeblendet
Pipelines	Build-/Release-Ergebnisse lesen	Editoren und Bibliothek ausgeblendet
Testpläne	Kein Zugriff	Manuelle Tests sind nicht verfügbar
Search	Vollständige Suchfunktion	Barrierefreie Inhalte
Einstellungen	Kein Zugriff	Administrative Funktionen ausgeblendet

Voraussetzungen

Bevor Sie die Sichtbarkeit des Projekts ändern, stellen Sie sicher, dass Sie diese Anforderungen erfüllen:

Anforderung	Einzelheiten
Berechtigungen	Projektsammlungsadministrator oder Organisationsbesitzer
Organisationseinrichtung	Muss die Richtlinie "Öffentliche Projekte zulassen" aktivieren
Sicherheitsüberprüfung	Abschließen der Migrationsprüfliste

Prüfliste für die Sicherheit vor der Migration

Warnung

Öffentliche Projekte machen frühere Daten verfügbar, einschließlich alter Commits, Arbeitselemente und Buildprotokolle. Überprüfen Sie alle Inhalte sorgfältig, bevor Sie ein Projekt öffentlich machen.

Organisations- und Identitätsexposition

[ ] Mitgliedsinformationen: Alle Namen und E-Mail-Adressen aller Organisationsmitglieder werden sichtbar
[ ] Organisationseinstellungen: schreibgeschützte Ansicht aller offengelegten Organisations- und Projekteinstellungen
[ ] Prozessmetadaten: Alle Auswahllistenwerte in Organisationsprojekten werden sichtbar
[ ] Buildverlauf: Namen und E-Mail-Adressen aus Buildtriggern und Git-Commits verfügbar gemacht

Überlegungen zu projektübergreifenden Projekten

[ ] Verknüpfte Artefakte: Auf Links zu privaten Projekten überprüfen, die vertrauliche Informationen möglicherweise verfügbar machen
[ ] Freigegebene Ressourcen: Überprüfen der Ressourcen auf Organisationsebene, auf die vom Projekt zugegriffen wird

Überprüfung der Inhaltssicherheit

Arbeitsaufgaben und Agile-Tools

[ ] Historische Arbeitsaufgaben: Überprüfen aller Arbeitsaufgaben, einschließlich geschlossener Elemente, auf vertrauliche Informationen
[ ] Bereichspfadsicherheit: Stellen Sie sicher, dass keine Bereichspfade spezielle Sicherheitseinschränkungen aufweisen (abgelehnte Berechtigungen werden in öffentlichen Projekten ignoriert)
[ ] Diskussionen und Kommentare: Überprüfen aller Arbeitsaufgabendiskussionen auf sensible oder unangemessene Inhalte

Quellcode-Repositories

[ ] Commit-Verlauf: Überprüfen des gesamten Git-Verlaufs auf Anmeldeinformationen, Sicherheitsrisiken oder proprietären Code
[ ] Commit-Nachrichten: Überprüfen Sie alle Commit-Nachrichten auf vertrauliche Informationen oder unangemessene Inhalte
[ ] Dateiinhalte: Stellen Sie sicher, dass keine Dateien Anmeldeinformationen, API-Schlüssel oder vertrauliche Daten enthalten

Erstellen und Freigeben von Pipelines

[ ] Pipelinedefinitionen: Überprüfen auf verfügbar gemachte Anmeldeinformationen, interne URLs oder Umgebungsdetails
[ ] Buildprotokolle: Überprüfen von historischen Buildprotokollen auf vertrauliche Informationen
[ ] Dienstverbindungen: Überprüfen Sie, dass es keine privaten Feed-Abhängigkeiten gibt, auf die Nichtmitglieder nicht zugreifen können

Artefakte und Pakete

[ ] Paketinhalte: Überprüfen aller Pakete in projektbezogenen Feeds auf Datenschutzbedenken
[ ] Feedeinstellungen: Verstehen Sie, dass Upstream-Einstellungen für öffentliche Projektfeeds deaktiviert sind

Erweiterungen und Anpassungen

[ ] Benutzerdefinierte Erweiterungen: Überprüfen, ob Erweiterungen für Nichtmitglieder ordnungsgemäß funktionieren
[ ] Anpassungen des Arbeitselementformulars: Testen benutzerdefinierter Steuerelemente und Felder mit nichtemberem Zugriff

Schritt 1: Aktivieren öffentlicher Projekte für Ihre Organisation

Melden Sie sich bei Ihrer Organisation an (https://dev.azure.com/{yourorganization}).
Wählen Sie Organisationseinstellungen aus.
Wählen Sie "Richtlinien" aus.
Aktivieren Sie unter "Sicherheitsrichtlinien" öffentliche Projekte zulassen.

Schritt 2: Ändern der Projektsichtbarkeit

Navigieren Sie zu Ihrem Projekt (https://dev.azure.com/{yourorganization}/{yourproject}).
Wählen Sie "Projekteinstellungen" aus.
Wählen Sie Übersicht aus.
Wählen Sie im Dropdownmenü "Sichtbarkeit" die Option "Öffentlich" oder "Privat" aus.
Wählen Sie Speichern aus.

Verwalten von Mitwirkenden in öffentlichen Projekten

Hinzufügen von Projektmitgliedern

Fügen Sie Mitwirkende zu öffentlichen Projekten auf die gleiche Weise wie private Projekte hinzu:

Wechseln Sie zu Projekteinstellungen>Berechtigungen.
Wählen Sie "Hinzufügen" aus, um Benutzer einzuladen.
Weisen Sie geeignete Zugriffsebenen zu (Stakeholder, Basic oder Basic + Test Plans).

Weitere Informationen finden Sie unter Hinzufügen von Benutzern zu Ihrer Organisation.

Überlegungen zu externen Benutzern

Wenn Sie externe Benutzer zu öffentlichen Projekten einladen:

Sie erhalten Zugriff auf alle öffentlichen Inhalte in Ihrer Organisation
Erwägen Sie, separate Organisationen für öffentliche Projekte zu erstellen, wenn Sie an anderer Stelle vertrauliche Inhalte haben

Alternative Ansätze für vertrauliche Inhalte

Option 1: Separate Organisation für öffentliche Projekte

Wenn Ihre aktuelle Organisation vertrauliche Materialien enthält:

Erstellen einer neuen Organisation speziell für öffentliche Projekte
Nur nicht sensible Inhalte in die neue Organisation migrieren
Vertrauliche Projekte in der ursprünglichen privaten Organisation beibehalten

Option 2: Selektive Inhaltsmigration

Verschieben vertraulicher Arbeitsaufgaben

Verwenden des Features "Arbeitsaufgaben verschieben" zum Übertragen vertraulicher Elemente in ein privates Projekt
Projektübergreifende Verknüpfungen arbeiten weiterhin für Mitglieder, bleiben aber von Nichtmitgliedern ausgeblendet

Git-Repository-Spitzenmigration

Migrieren Sie bei Repositorys mit problematischer Historie nur den aktuellen Zustand:

Warnung

Diese Aktion erstellt ein neues Repository ohne Verbindung mit dem Original. Der Pull-Anforderungsverlauf und die Änderungsnachverfolgung gehen verloren.

# Clone the existing repository
git clone <original_clone_URL>
cd <repository_name>

# Ensure you're on the desired branch
git checkout main

# Remove Git history
rm -rf .git  # On Windows: rmdir /s .git

# Initialize new repository
git init

# Connect to new repository in public project
git remote add origin <new_public_repo_URL>

# Push current state as initial commit
git add .
git commit -m "Initial public release"
git push --set-upstream origin main

Einschränkungen für Nichtmember

Nichtmitglieder öffentlicher Projekte können die folgenden Aktionen nicht ausführen:

Bearbeiten oder Erstellen von Inhalten (Dateien, Arbeitsaufgaben, Pipelines)
Anzeigen von E-Mail-Adressen oder Kontaktinformationen von Projektmitgliedern
Zugreifen auf administrative Einstellungen oder Konfigurationsseiten
Verwenden erweiterter Suchfunktionen in der gesamten Organisation
Navigieren zwischen mehreren öffentlichen Projekten in derselben Organisation
Artefakte favorisieren oder folgen

Fehlerbehebung beim Zugang zu öffentlichen Projekten

Häufig auftretende Probleme

Problem: Nonmembers können nicht auf das Projekt zugreifen, nachdem es öffentlich wurde.

Lösung: Überprüfen, ob die Richtlinie "Öffentliche Projekte zulassen" der Organisation aktiviert ist

Problem: Einige Inhalte werden weiterhin eingeschränkt angezeigt

Lösung: Überprüfen Sie Verweigerungsrechte, die sich auf bestimmte Bereiche auswirken könnten.

Problem: Externe Benutzer können keinen Beitrag leisten

Lösung: Stellen Sie sicher, dass sie als Projektmitglieder mit entsprechenden Zugriffsebenen hinzugefügt werden

Nächster Schritt

Einrichten von Git für Ihr Projekt

Feedback

War diese Seite hilfreich?

Last updated on 2025-08-27