Aller au contenu

Guide Entreprise : Déploiement en Environnements Sécurisés & Durcis

Navigation : Documentation > Guide Entreprise
Spécifications techniques associées :
- 09. Environnements Durcis : WDAC & Re-Signature
- 04. Dépôts et Distribution Légère
- 08. Solutions d'Ingénierie & Sécurité

Sommaire

  1. Contexte et Contraintes des Parcs d'Entreprise
  2. Re-Signature de Code Locale (WDAC & AppLocker)
  3. 2.1 Le blocage des binaires par le noyau NT
  4. 2.2 Architecture du pipeline de re-signature locale
  5. 2.3 Configuration dans config.nu
  6. 2.4 Mode Signature Intégrée (Embedded Authenticode) vs Mode Catalog (.cat)
  7. 2.5 Contournement AppLocker par déportation de la racine
  8. Buckets Privés d'Entreprise (Dépôts Git Internes)
  9. 3.1 Vocation du bucket privé
  10. 3.2 Hébergement sur serveur Git interne d'entreprise
  11. 3.3 Enregistrement et synchronisation sur les postes clients
  12. 3.4 Gestion de l'authentification Git d'entreprise
  13. 3.5 Automatisation CI interne : Index compilé et signature d'entreprise
  14. Réseaux Isolés (Air-Gapped) & Proxies d'Entreprise
  15. 4.1 Réécriture dynamique d'URLs vers Artifactory / Nexus
  16. 4.2 Support des autorités de certification (CA) internes
  17. Déploiement Séquentiel par Fichier de Configuration (erable apply) & Surcharges Réseau
  18. 5.1 Principe et utilité en entreprise
  19. 5.2 Format du fichier de bundle TOML
  20. 5.3 Mécanisme de bascule automatique (Fallback)
  21. 5.4 Modes de Réconciliation : --mode append vs --mode replace
  22. 5.5 Exemple d'exécution
  23. Récapitulatif des Variables de Configuration d'Entreprise
  24. Liens et Références Associées

1. Contexte et Contraintes des Parcs d'Entreprise

Dans les parcs informatiques modernes de grandes entreprises, banques, institutions publiques et Opérateurs d'Importance Vitale (OIV), les postes de travail sont soumis à des durcissements de sécurité stricts (recommandations ANSSI, NIST, CIS) :

  • Politiques de contrôle d'exécution (WDAC / AppLocker) : Tout exécutable ou script non signé par une autorité approuvée par le domaine d'entreprise est immédiatement bloqué par le noyau Windows.
  • Réseaux fermés ou filtrés : Absence d'accès direct à Internet, passage obligatoire par des mandataires (proxies TLS avec déchiffrement de flux et certificats racine privés) ou isolation totale (air-gap).
  • Distribution d'outillages internes spécifiques : Nécessité de distribuer des outils de production propriétaires ou des versions certifiées de CLIs open-source sans dépendre de dépôts publics externes.

Érable a été conçu pour résoudre ces problématiques de manière native, sans jamais obliger les administrateurs à accorder des droits d'administrateur local aux développeurs.

2. Re-Signature de Code Locale (WDAC & AppLocker)

2.1 Le blocage des binaires par le noyau NT

Lorsque Windows Defender Application Control (WDAC) est activé en mode Enforce :

  • Le module Code Integrity du noyau NT refuse d'exécuter tout fichier PE (.exe, .dll) qui n'est pas signé numériquement par un certificat Authenticode approuvé par la politique déployée par GPO ou Intune.
  • Or, plus de 95% des outils open-source portables (ex: ripgrep, neovim, kubectl, fzf) ne disposent pas de signature Authenticode commerciale. L'utilisateur est alors confronté à une erreur de sécurité immédiate : 
    "Windows Defender Application Control a bloqué le fichier car il n'est pas conforme aux règles d'intégrité du code." (Event ID 3077)

2.2 Architecture du pipeline de re-signature locale

Érable résout ce blocage grâce à son pipeline natif de re-signature post-extraction :

flowchart TD
    A["Téléchargement archive / binaire<br>(contrôle SHA-256 certifié)"] --> B["Extraction locale dans<br><code>packages/<nom>/<version>/</code>"]
    B --> C{"$env.erable_ENTERPRISE_SIGNING<br>activé ?"}
    C -->|Oui| D["Invocation de <code>signtool.exe</code><br>avec certificat d'entreprise"]
    D --> E["Vérification cryptographique de la signature"]
    E --> F["Déploiement du Trampoline Rust<br>et du pointeur <code>.target</code>"]
    C -->|Non (Poste standard)| F
  1. Le binaire est téléchargé et son intégrité SHA-256 est validée.
  2. Le moteur extrait le binaire dans le répertoire de la version.
  3. Le hook de signature interne intervient immédiatement sur tous les fichiers .exe et .dll.
  4. Le certificat d'entreprise (stocké dans le magasin de certificats Windows, une carte à puce ou un TPM matériel) est appliqué via signtool.exe.
  5. Le trampoline de routage est déployé : le noyau Windows autorise l'exécution sans alerte de sécurité.

2.3 Configuration dans config.nu

Dans le fichier de configuration utilisateur ou global déployé par la DSI (~/.erable/config.nu) :

# ~/.erable/config.nu - Configuration Entreprise de Re-Signature

$env.erable_ENTERPRISE_SIGNING = {
    # Active la re-signature systématique post-extraction
    enabled: true,

    # Méthode : "authenticode_embedded" ou "catalog"
    method: "authenticode_embedded",

    # Emplacement de l'utilitaire signtool (Windows SDK)
    tool_path: "C:/Program Files (x86)/Windows Kits/10/bin/10.0.22621.0/x64/signtool.exe",

    # Empreinte SHA-1 du certificat interne entreprise (Store "My" ou "Root")
    cert_thumbprint: "3A7F8B9C0D1E2F3A4B5C6D7E8F9A0B1C2D3E4F5A",

    # Serveur d'horodatage RFC-3161 interne ou public
    timestamp_server: "http://timestamp.digicert.com"
}

2.4 Mode Signature Intégrée (Embedded Authenticode) vs Mode Catalog (.cat)

Érable gère deux méthodes selon les contraintes de vos binaires :

Méthode Fonctionnement Cas d'Usage Recommandé
authenticode_embedded signtool sign injecte la signature directement dans l'en-tête du binaire PE. Standard (99% des outils) : Simple, autonome, le binaire reste signé même s'il est déplacé.
catalog Génère un fichier de catalogue .cat signé et l'enregistre dans la base de sécurité locale (signtool catdb). Outils auto-vérifiés : Pour les rares outils qui calculent leur propre somme de contrôle interne au démarrage et refuseraient une altération binaire.

2.5 Contournement AppLocker par déportation de la racine

Si la politique AppLocker de votre entreprise interdit l'exécution depuis %USERPROFILE% et restreint les exécutions à un dossier approuvé (ex: C:\ProgramData\erable ou C:\Tools\erable) :

Il suffit de déclarer la variable d'environnement racine dans votre profil : 

$env.erable_ROOT = "C:/ProgramData/erable"
L'intégralité du moteur (bin/, packages/, tools/, cache/) est immédiatement déportée dans cet espace sans impacter le fonctionnement standard.

👉 Pour approfondir l'analyse technique de sécurité, consultez 09. Environnements Durcis : WDAC, AppLocker et Re-Signature.

3. Buckets Privés d'Entreprise (Dépôts Git Internes)

3.1 Vocation du bucket privé

Un Bucket Privé d'Entreprise permet à une organisation :

  • De distribuer des outils internes propriétaires développés par les équipes internes (scripts CLI, binaires compilés en interne, générateurs de code).
  • De proposer un catalogue maîtrisé et qualifié d'outils open-source approuvés par le RSSI (versions figées, validées sur le plan de la sécurité et des vulnérabilités CVE).
  • D'interdire ou compléter les buckets publics officiels.

3.2 Hébergement sur serveur Git interne d'entreprise

Le bucket privé est hébergé sur l'infrastructure Git privée de l'entreprise :

  • GitLab interne (ex: https://gitlab.corp.internal/dsi/erable-bucket.git)
  • GitHub Enterprise Server (ex: https://github.corp.internal/infra/erable-bucket.git)
  • Serveur Git / Artifactory / Azure DevOps Server.

3.3 Enregistrement et synchronisation sur les postes clients

Pour déclarer le bucket d'entreprise sur un poste client :

# 1. Cloner le bucket interne dans ~/.erable/buckets/
git clone https://gitlab.corp.internal/dsi/erable-bucket.git ~/.erable/buckets/corporate

# Sous Windows (PowerShell) :
git clone https://gitlab.corp.internal/dsi/erable-bucket.git $HOME\.erable\buckets\corporate

Une fois le bucket cloné :

  • La commande erable update met à jour automatiquement le bucket interne en même temps que les autres : 
    erable update
  • Les outils internes deviennent immédiatement cherchables et installables : 
    erable search mon-cli-interne
erable install mon-cli-interne

3.4 Gestion de l'authentification Git d'entreprise

Comme le bucket est hébergé sur un dépôt privé d'entreprise nécessitant une authentification :

  • Clés SSH d'entreprise : Utilisez l'URL SSH (git@gitlab.corp.internal:...).
  • Jetons d'accès personnels (PAT) ou SSO Kerberos : Érable s'appuie sur le client git standard du système. Le gestionnaire de crédentiels système (Git Credential Manager, GCM) ou les variables d'environnement GIT_ASKPASS / SSH Agent prennent en charge l'authentification de manière transparente sans stocker de mot de passe en clair dans Érable.

3.5 Automatisation CI interne : Index compilé et signature d'entreprise

Pour que le bucket d'entreprise offre des performances optimales (erable search instantané), le dépôt Git interne doit intégrer un pipeline d'intégration continue (ex: .gitlab-ci.yml) qui génère l'index index.nuon :

# Exemple de pipeline GitLab CI interne pour le bucket d'entreprise
compile_index:
  stage: build
  script:
    - nu -c "
        let pkgs = (ls packages/*/*/parts/package.toml | each { |f| open $f.name });
        $pkgs | to nuon | save -f index.nuon
      "
    # Signature avec la clé privée Ed25519 de l'entreprise
    - openssl dgst -sha256 -sign /etc/pki/erable-signer.key -out index.nuon.sig index.nuon
  artifacts:
    paths:
      - index.nuon
      - index.nuon.sig

4. Réseaux Isolés (Air-Gapped) & Proxies d'Entreprise

4.1 Réécriture dynamique d'URLs vers Artifactory / Nexus

Dans les infrastructures fermées sans accès aux URLs publiques de téléchargement (GitHub Releases, sites d'éditeurs), le moteur Érable intègre une règle de réécriture transparente :

# ~/.erable/config.nu - Réécriture vers le proxy d'artefacts d'entreprise

$env.erable_MIRROR_REWRITE = {
    enabled: true,
    prefix_match: "https://github.com/",
    replace_with: "https://artifactory.corp.internal/artifactory/github-cache/"
}

Lors de l'installation, toute URL commençant par prefix_match est automatiquement substituée par l'URL interne du miroir Artifactory/Nexus d'entreprise. L'intégrité cryptographique SHA-256 reste strictement validée.

4.2 Support des autorités de certification (CA) internes

Si le réseau utilise une inspection TLS profonde (Proxy SSL Interception) :

  • Érable utilise le client HTTP natif et les commandes système respectant le magasin de certificats d'entreprise Windows (certmgr.msc) ou les variables d'environnement standard (SSL_CERT_FILE, REQUESTS_CA_BUNDLE).

5. Déploiement Séquentiel par Fichier de Configuration (erable apply) & Surcharges Réseau

5.1 Principe et utilité en entreprise

Dans un contexte d'entreprise, l'installation manuelle paquet par paquet n'est pas adaptée au provisionnement des postes de travail des développeurs ni aux exécuteurs d'intégration continue (CI/CD).

La commande erable apply permet d'appliquer un fichier de description déclaratif au format TOML (appelé Bundle). Elle assure :

  1. Un déploiement ordonné et déterministe : Les paquets sont analysés et installés séquentiellement en respectant l'ordre ou les dépendances.
  2. L'injection de surcharges réseau d'entreprise (override_url) : Chaque paquet peut être pointé vers un emplacement privilégié interne (miroir Nexus/Artifactory, partage réseau Windows UNC de type \\nas-corp\share\binaries\... ou serveur interne HTTP).
  3. Une résilience maximale par bascule automatique (Automatic Fallback) : Si la ressource interne est inaccessible (par exemple, collaborateur en télétravail hors VPN, coupure du partage réseau ou fichier manquant), Érable bascule automatiquement sur l'URL d'origine certifiée du bucket sans interrompre le déploiement global.

5.2 Format du fichier de bundle TOML

Un bundle d'entreprise est un simple fichier texte versionnable dans Git (ex: developer-stack.toml) :

# developer-stack.toml - Configuration du poste développeur type
[bundle]
name = "dev-workstation-full"
version = "1.0.0"
description = "Socle standard pour développeurs d'entreprise"

[[packages]]
name = "kubectl"
version = "1.28.1"
bucket = "main"
# Surcharge réseau : miroir interne local ou partage réseau UNC
override_url = "https://nexus.corp.internal/repository/raw-tools/kubectl/1.28.1/kubectl.exe"

[[packages]]
name = "nodejs"
version = "20.10.0"
bucket = "main"
# Exemple avec un partage réseau d'entreprise Windows (SMB/UNC)
override_url = "\\\\nas-storage.corp.internal\\softwares\\nodejs-v20.10.0-win-x64.zip"

[[packages]]
name = "sysinternals-procexp"
version = "17.06"
bucket = "main"
# Sans override_url : téléchargement direct depuis la source certifiée du bucket

5.3 Mécanisme de bascule automatique (Fallback)

Lorsqu'un paquet comporte un champ override_url :

flowchart TD
    A["Lecture du bundle <code>erable apply</code>"] --> B["Pour chaque paquet déclaré"]
    B --> C{"Champ <code>override_url</code><br>renseigné ?"}
    C -->|Oui| D["Tentative de téléchargement / copie<br>depuis <code>override_url</code>"]
    C -->|Non| E["Téléchargement depuis l'URL upstream<br>du manifeste du bucket"]
    D --> F{"Téléchargement réussi ?"}
    F -->|Succès| G["Contrôle d'intégrité SHA-256<br>Extraction & Enregistrement"]
    F -->|Échec (404, VPN éteint, UNC inaccessible)| H["⚠️ Avertissement : Échec source locale<br>Bascule automatique sur upstream"]
    H --> E
    E --> G
  1. Tentative prioritaire : Érable tente d'accéder à l'URL ou au chemin local/réseau défini dans override_url.
  2. Détection d'erreur sans arrêt brutal : Si la requête HTTP renvoie une erreur (404, 403, 500) ou si le chemin réseau Windows UNC est inaccessible (VPN déconnecté), Érable émet un avertissement d'information.
  3. Bascule immédiate (Failover) : Le moteur récupère immédiatement l'URL upstream déclarée dans le manifeste du bucket (package.toml ou targets.toml).
  4. Vérification d'intégrité inviolable : Quelle que soit la source empruntée (miroir local ou upstream officiel), l'empreinte SHA-256 du fichier téléchargé est validée contre celle enregistrée dans le manifeste signé du bucket.

5.4 Modes de Réconciliation : --mode append vs --mode replace

Lorsqu'un administrateur ou un développeur applique un bundle TOML via erable apply, deux modes d'alignement de configuration sont disponibles via l'option --mode :

  1. Mode Ajout (--mode append, mode par défaut) :
  2. Parcourt les paquets déclarés dans le bundle.
  3. Installe les paquets manquants ou met à jour ceux dont la version a évolué.
  4. Préservation de l'existant : Tout outil déjà installé sur le poste utilisateur mais absent du bundle reste intact.

  5. Cas d'usage : Provisionnement initial de nouveaux outils sans impacter les utilitaires personnels du développeur. 

    erable apply developer-stack.toml --mode append

  6. Mode Remplacement Strict (--mode replace) :

  7. Réconcilie rigoureusement le poste client avec l'état exact défini dans le fichier de bundle (Fleet State Enforcement).
  8. Installe les paquets manquants déclarés dans le bundle.
  9. Purge automatique du superflu : Tout paquet présent dans ~/.erable/packages/ qui n'est PAS listé dans le bundle est immédiatement et proprement désinstallé (suppression des fichiers, des trampolines dans bin/, des raccourcis Start Menu et exécution des hooks post_uninstall.nu).
  10. Cas d'usage : Postes de production, exécuteurs CI/CD, environnements durcis où aucun logiciel non autorisé ou obsolète ne doit subsister sur la machine. 
    erable apply developer-stack.toml --mode replace

[!NOTE] Les options --mode append et --mode replace sont strictement spécifiques au mode déclaratif par fichier bundle (erable apply). Les commandes unitaires erable install et erable uninstall continuent d'opérer au niveau unitaire sans effet de bord.

5.5 Exemple d'exécution

Pour appliquer une configuration sur le poste client :

# Application de la pile d'outils en mode remplacement strict
erable apply developer-stack.toml --mode replace

Sortie console type : 

[erable:apply] Lecture du plan de deploiement sequentiel : developer-stack.toml...
[erable:apply] Mode de reconciliation actif : replace

[erable:apply:replace] Nettoyage du superflu : 1 paquets non declares a desinstaller...
[PURGE] Desinstallation automatique du paquet superflu 'sysinternals-procexp'...
sysinternals-procexp desinstalle avec succes.

[erable:apply] Deploiement sequentiel de 2 paquets...
--- Traitement de 'kubectl' ---
kubectl v1.28.1 installe avec succes !

--- Traitement de 'nodejs' ---
nodejs v20.10.0 installe avec succes !

==========================================================
   Rapport de deploiement : 2/2 paquets installes avec succes.
==========================================================

6. Récapitulatif des Variables de Configuration d'Entreprise

Variable d'Environnement Type Description
erable_ROOT Chemin Déporte la racine d'installation (ex: C:\ProgramData\erable) pour respecter les règles de chemin AppLocker.
erable_ENTERPRISE_SIGNING Enregistrement (record) Active et paramètre la re-signature Authenticode locale automatique via signtool.exe.
erable_MIRROR_REWRITE Enregistrement (record) Réécrit à la volée les URLs de téléchargement vers le miroir d'artefacts interne (Artifactory / Nexus).

7. Liens et Références Associées