# Stratégie des dépôts Git de confiance

Canonical: https://www.nsecsoft.com/fr/docs/ping64-data-security/dlp/git/policy/

Language: fr-FR

Updated: 2026-11-15T03:46:51.880299Z

Le contrôle des accès aux dépôts Git définit les dépôts de confiance pour les terminaux Windows et enregistre les accès Git standard reconnaissables. Lorsqu'un dépôt non fiable est identifié, le terminal tente d'arrêter le processus Git associé. Correspondance de la règle, arrêt du processus et achèvement de l'opération sont des résultats distincts à vérifier séparément.

La fonction ne garantit pas la couverture de tous les clients Git, commandes ou modes de transport. Elle ne remplace pas les autorisations des dépôts, la sécurité réseau ni les autres contrôles de sécurité des données.

Les procédures utilisent les libellés anglais de la console d'administration.

## Préparer la configuration

-   Utilisez un compte autorisé à gérer les politiques DLP. La consultation des enregistrements associés exige le droit correspondant et peut être effectuée par une personne qui le possède. Vérifiez la connexion et les licences des terminaux pilotes Windows ainsi que leur visibilité administrative.
-   Recensez adresses, protocoles et ports des dépôts nécessaires. Distinguez l'autorisation d'un dépôt de celle d'un espace de noms entier. Ne placez pas de mot de passe, jeton d'accès ou autre identifiant secret dans l'adresse ; les droits de compte restent gérés par le service Git.
-   Préparez des cibles de test fiables et non fiables autorisées, avec comptes de test et contenus non sensibles. Une politique peut interrompre le développement ou les compilations ; commencez sur quelques terminaux récupérables et prévoyez un retour arrière.

## Configurer les dépôts de confiance

1.  Sous **DLP**, ouvrez les applications, puis **Git Repository Access Control** et **Trusted Repository Policies**.
2.  Créez ou modifiez une politique, renseignez son nom et vérifiez période d'effet ainsi que terminaux, groupes ou étiquettes. Commencez par un périmètre pilote.
3.  Sous **Trusted Repositories**, sélectionnez **Add Repository**. Pour chaque règle, choisissez **Exact Repository** ou **Repository Namespace** et saisissez l'adresse correspondante. Une politique exige de 1 à 500 règles valides, sans doublons.
4.  Vérifiez protocole, hôte, port et chemin. Les adresses HTTP, HTTPS, SSH et Git ainsi que les formes SSH abrégées courantes peuvent être saisies. Des protocoles différents ne sont pas automatiquement équivalents ; un port non standard affecte aussi la correspondance.
5.  Enregistrez l'ensemble de la politique et attendez sa réception. Testez séparément les cibles fiables et non fiables, puis vérifiez correspondance et exécution dans **Access Records**. Après validation, élargissez selon la procédure de changement.

Les adresses suivantes sont fictives et ne constituent pas un périmètre de confiance par défaut :

| Règle | Exemple | Périmètre |
| --- | --- | --- |
| **Exact Repository** | `https://git.example.com/team/project.git` | Correspond à ce dépôt, sans inclure automatiquement les autres dépôts de l'équipe. |
| **Repository Namespace** | `https://git.example.com/team` | Correspond à ce chemin et aux chemins descendants, pas à un autre niveau dont le préfixe serait seulement similaire. |

Une règle HTTPS ne doit pas être supposée couvrir l'adresse SSH du même hôte. Si les deux sont nécessaires, configurez et testez-les séparément. Un espace de noms est généralement plus large qu'un dépôt : vérifiez avant enregistrement qu'il respecte les exigences de l'organisation.

**Correspondance des adresses :** À protocole, hôte et port identiques, le suffixe `.git` final du chemin est ignoré. La casse ne distingue pas les noms d’hôte, mais elle distingue les chemins de dépôt. Par exemple, `team/project.git` et `team/project` correspondent au même chemin ; ne supposez pas que `team/Project` et `team/project` sont identiques. Testez séparément les adresses réelles du service.

## Limites et dépannage

-   **Couverture :** les opérations réseau Git standard reconnaissables comprennent clone, fetch, pull et push. Testez séparément commandes, options, clients et scénarios Git LFS. Une absence d'enregistrement ne prouve pas l'absence d'accès.
    
-   **Cible non reconnaissable :** certaines cibles impossibles à analyser ne sont pas bloquées comme dépôts non fiables. Utilisez d'autres mesures ; cette fonction ne garantit pas le contrôle de toutes les sorties.
    
-   **Accès non fiable non bloqué :** vérifiez reconnaissance de la cible, correspondance et résultat du processus. L'arrêt peut échouer ou le processus peut déjà être terminé. Même réussi, l'arrêt ne prouve pas qu'aucune communication ou transmission n'a eu lieu auparavant.
    
-   **Dépôt fiable perturbé :** vérifiez diffusion de la politique et protocole, port et chemin réels ; examinez la réécriture d'adresse et le périmètre de l'espace de noms. Retestez les cas autorisés et limités après ajustement.
    
-   **Enregistrement absent :** vérifiez état du terminal et de la politique, licences, visibilité, période et filtres ; attendez la transmission. Si le développement est perturbé, rétablissez d'abord l'activité selon la procédure de l'organisation, puis vérifiez le périmètre.
    
-   [Enregistrements d’accès aux dépôts Git](https://www.nsecsoft.com/fr/docs/ping64-data-security/dlp/git/records/)