Richtlinie für vertrauenswürdige Git-Repositories
Die Git-Repositoryzugriffskontrolle legt für Windows-Endpunkte einen Bereich vertrauenswürdiger Repositorys fest und erfasst erkennbare Standard-Git-Zugriffe. Erkennt ein Endpunkt ein nicht vertrauenswürdiges Repository, versucht er den zugehörigen Git-Prozess zu beenden. Regelübereinstimmung, Prozessbeendigung und Abschluss der Repositoryoperation sind unterschiedliche Ergebnisse und müssen getrennt geprüft werden.
Die Funktion garantiert keine Abdeckung sämtlicher Git-Clients, Befehle oder Übertragungsarten und ersetzt keine Repositoryberechtigungen, Netzwerksicherheit oder andere Datensicherheitskontrollen.
Die Schritte verwenden die englischen Bezeichnungen der Verwaltungskonsole.
Vor der Konfiguration
- Verwenden Sie ein Konto mit Verwaltungsberechtigung für DLP-Richtlinien. Für die Anzeige zugehöriger Aufzeichnungen ist die entsprechende Leseberechtigung erforderlich; eine entsprechend berechtigte Person kann sie prüfen. Prüfen Sie Anbindung und Lizenz der Windows Testendpunkte sowie deren administrativen Sichtbereich.
- Erfassen Sie Adressen, Protokolle und Ports der benötigten Repositorys. Unterscheiden Sie die Freigabe eines einzelnen Repositorys von einem gesamten Namensraum. Repositoryadressen dürfen keine Passwörter, Zugriffstoken oder andere Zugangsdaten enthalten; Kontoberechtigungen verwaltet weiterhin der Git-Dienst.
- Bereiten Sie genehmigte vertrauenswürdige und nicht vertrauenswürdige Testziele, Testkonten und Inhalte ohne sensible Daten vor. Da die Richtlinie Entwicklung oder Builds unterbrechen kann, beginnen Sie mit wenigen wiederherstellbaren Endpunkten und bereiten Sie ein Rückfallverfahren vor.
Vertrauenswürdige Repositorys konfigurieren
- Öffnen Sie unter DLP im Anwendungsbereich Git Repository Access Control und wählen Sie Trusted Repository Policies.
- Erstellen oder bearbeiten Sie eine Richtlinie, geben Sie einen Namen ein und prüfen Sie Gültigkeitszeit sowie Zielendpunkte, Gruppen oder Tags. Wählen Sie zunächst einen Testbereich.
- Wählen Sie unter Trusted Repositories die Aktion Add Repository. Wählen Sie für jede Regel Exact Repository oder Repository Namespace und geben Sie die entsprechende Adresse ein. Eine Richtlinie benötigt 1 bis 500 gültige, nicht doppelte Regeln.
- Prüfen Sie Protokoll, Host, Port und Pfad. Sie können HTTP-, HTTPS-, SSH- und Git-Protokolladressen oder gebräuchliche SSH-Kurzformen verwenden. Unterschiedliche Protokolle sind nicht automatisch gleichwertig; auch ein nicht standardmäßiger Port beeinflusst den Abgleich.
- Speichern Sie die gesamte Richtlinie und warten Sie auf den Empfang am Testendpunkt. Testen Sie vertrauenswürdige und nicht vertrauenswürdige Ziele separat und prüfen Sie Treffer und Ausführungsergebnis unter Access Records. Erweitern Sie den Bereich nach erfolgreicher Prüfung gemäß Änderungsverfahren.
Die folgenden Adressen sind Beispiele und kein standardmäßig vertrauenswürdiger Bereich:
| Regel | Beispiel | Geltungsbereich |
|---|---|---|
| Exact Repository | https://git.example.com/team/project.git |
Gilt für dieses Repository und umfasst nicht automatisch andere Repositorys des Teams. |
| Repository Namespace | https://git.example.com/team |
Gilt für diesen Pfad und untergeordnete Pfade, nicht für eine andere Pfadebene mit lediglich ähnlichem Namenspräfix. |
Nehmen Sie beispielsweise nicht an, dass eine HTTPS-Regel die SSH-Adresse desselben Hosts abdeckt. Wenn beide erforderlich sind, konfigurieren und testen Sie sie getrennt. Ein Namensraum ist meist weiter gefasst als ein einzelnes Repository; prüfen Sie vor dem Speichern die Organisationsanforderungen.
Hinweis zum Adressabgleich: Bei gleichem Protokoll, Host und Port wird ein abschließendes .git im Repositorypfad beim Abgleich ignoriert. Hostnamen unterscheiden nicht zwischen Groß- und Kleinschreibung, Repositorypfade dagegen schon. Beispielsweise entsprechen team/project.git und team/project demselben Repositorypfad; team/Project und team/project sind nicht automatisch gleich. Testen Sie die tatsächlichen Dienstadressen getrennt.
Einschränkungen und Fehlerbehebung
Abdeckung: Erkennbare Standard-Git-Netzwerkoperationen umfassen clone, fetch, pull und push. Testen Sie Befehle, Optionen, Clients und Git-LFS-Szenarien jeweils separat. Fehlende Aufzeichnungen beweisen keinen fehlenden Zugriff.
Ziel nicht erkennbar: Einige nicht auflösbare Ziele werden nicht als nicht vertrauenswürdiges Repository blockiert. Kombinieren Sie andere Sicherheitsmaßnahmen; die Funktion garantiert keine Kontrolle aller externen Übertragungen.
Nicht vertrauenswürdiger Zugriff nicht blockiert: Prüfen Sie Zielerkennung, Treffer und Prozessausführung. Die Beendigung kann fehlschlagen oder der Prozess bereits beendet sein. Selbst eine erfolgreiche Beendigung beweist nicht, dass zuvor keine Netzwerkkommunikation oder Datenübertragung stattfand.
Vertrauenswürdiges Repository betroffen: Prüfen Sie Richtlinienverteilung sowie tatsächliches Protokoll, Port und Pfad; kontrollieren Sie Adressumschreibungen und Namensraumbereich. Testen Sie nach Anpassung erlaubte und eingeschränkte Szenarien erneut.
Aufzeichnung fehlt: Prüfen Sie Endpunkt- und Richtlinienstatus, Lizenz, Sichtbereich, Zeit und Filter und warten Sie auf die Übertragung. Bei Auswirkungen auf die Entwicklung stellen Sie zuerst den Betrieb nach Organisationsverfahren wieder her und prüfen anschließend den Richtlinienbereich.
Aktualisiert