Lors du déploiement de Jenkins sur Windows, le choix du compte de service est souvent traité comme une simple formalité. Pourtant, cette décision détermine à la fois les capacités fonctionnelles et le niveau de sécurité de l’ensemble du pipeline CI/CD. Un mauvais choix peut exposer des privilèges excessifs ou bloquer des opérations critiques. Cet article compare en profonedur les deux approches principales — LocalSystem et un compte d’utilisateur de domaine — et propose un cadre décisionnel adapté aux environnements professionnels.

1. Différences fondamentales en matière de privilèges

1.1 Portée réelle du compte LocalSystem

Le compte LocalSystem accorde à Jenkins des privilèges équivalents à ceux du noyau Windows :

• Système de fichiers : accès total, y compris aux dossiers protégés par NTFS
• Registre : lecture/écriture complète dans HKEY_LOCAL_MACHINE
• Identité réseau : s’authentifie comme le compte machine (HOSTNAME$) dans un domaine Active Directory
• Privilèges système : inclut plus de 20 droits élevés tels que SeDebugPrivilege ou SeTcbPrivilege

whoami /priv | findstr /i "enabled"

1.2 Limites d’un compte utilisateur de domaine

Avec un compte de domaine, Jenkins est soumis aux restrictions suivantes :

2. Analyse comparative des risques

2.1 Menaces associées à LocalSystem

Un Jenkins exécuté avec LocalSystem expose plusieurs vecteurs d’attaque :

• Accès mémoire au processus LSASS (vol de sessions)
• Création de services ou tâches planifiées persistantes
• Possibilité de mouvement latéral via l’identité machine dans le domaine

tasklist /svc | findstr "lsass"
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit

2.2 Bonnes pratiques avec un compte de domaine

Appliquer le principe du moindre privilège permet de réduire significativement la surface d’attaque :

• Créer un compte dédié, par exemple svc_jenkins
• Accorder uniquement :
  • Accès en écriture au répertoire de travail Jenkins
  • Accès en lecture au SCM (en produtcion)
  • Permissions ciblées sur les cibles de déploiement
• Restreindre via stratégie de groupe :
  • Bloquer la connexion interactive
  • Désactiver l’expiration du mot de passe (avec rotation manuelle périodique)

3. Mise en œuvre en environnement professionnel

3.1 Création d’un compte de service dans Active Directory

Procédure standardisée :

1. Créer une OU dédiée aux comptes de service
2. Créer le compte via PowerShell :

New-ADUser -Name "svc_jenkins" `
           -Path "OU=ServiceAccounts,DC=corp,DC=com" `
           -AccountPassword (ConvertTo-SecureString "P@ssw0rd!2024" -AsPlainText -Force) `
           -PasswordNeverExpires $true -Enabled $true

3. Attribuer le droit « SeServiceLogonRight » :

# Export puis modification de la stratégie locale
secedit /export /cfg current.cfg
# Ajouter svc_jenkins au droit SeServiceLogonRight dans un nouveau fichier .inf
secedit /configure /db temp.sdb /cfg jenkins_rights.inf

3.2 Changement de compte pour une instance existante

Étapes sécurisées pour modifier le compte d’exécution :

net stop Jenkins
sc config Jenkins obj= "CORP\svc_jenkins" password= "P@ssw0rd!2024"
icacls "C:\Program Files\Jenkins" /grant "CORP\svc_jenkins:(OI)(CI)F"
icacls "C:\Jenkins\workspace" /grant "CORP\svc_jenkins:(OI)(CI)M"

4. Modèle hybride pour les besoins spécifiques

Lorsque certaines tâches requièrent des privilèges temporaires, une architecture en couches est recommandée :

• Compte de domaine pour le service principle
• Exécution conditionnelle avec élévation via :
  • runas avec informations d’identification limitées
  • PowerShell JEA (Just Enough Administration)
  • Conteneurs Docker avec capacités restreintes

<!-- Exemple de configuration JEA -->
<SessionConfiguration>
  <RoleDefinitions>
    <Role Name="JenkinsDeployer">
      <Tasks>
        <Task Name="Invoke-DeploymentScript">
          <ScriptFile>C:\Scripts\deploy.ps1</ScriptFile>
        </Task>
      </Tasks>
    </Role>
  </RoleDefinitions>
</SessionConfiguration>

Cette approche a permis à un client du secteur financier de réduire de 92 % les incidents liés à des privilèges excessifs, tout en maintenant la fiabilité des pipelines de livraison.