Aller au contenu

09. Environnements Durcis : Politiques WDAC, AppLocker et Re-Signature de Code

Navigation : Documentation > 09. WDAC & Re-Signature de Code
Guide pratique associé : Guide Entreprise

Sommaire

  1. Contexte et Problématique : Les Politiques de Contrôle d'Applications
  2. L'Architecture erable : Pipeline de Re-Signature Locale par PKI d'Entreprise
  3. Spécification Technique de l'Implémentation
  4. Déclaration dans ~/.erable/config.nu
  5. Implémentation du Pilote de Signature
  6. Alternative Légère : Fichiers Catalogs Signés (.cat)
  7. Résolution du Cas Particulier d'AppLocker sur les Chemins (Path Rules)

1. Contexte et Problématique : Les Politiques de Contrôle d'Applications sous Windows

Dans les parcs informatiques modernes d'entreprises, d'institutions bancaires, d'opérateurs d'importance vitale (OIV) et de ministères, les postes de travail sont soumis à des durcissements de sécurité stricts conformes aux recommandations de l'ANSSI, du NIST et de Microsoft.

Ces postes activent deux technologies majeures de restriction d'exécution :

  1. AppLocker : Bloque l'exécution d'exécutables, de scripts (.ps1, .cmd, .bat) et de DLLs situés dans les dossiers accessibles en écriture par l'utilisateur standard (typiquement %USERPROFILE%, %APPDATA%, %LOCALAPPDATA%, et donc ~/.erable).
  2. WDAC (Windows Defender Application Control) : Intégré au cœur du noyau Windows (module Code Integrity du kernel NT). Lorsqu'il est configuré en mode Enforce, le noyau NT refuse catégoriquement d'allouer des pages de mémoire exécutables (PAGE_EXECUTE_READWRITE) pour tout binaire binaire PE (.exe, .dll) qui n'est pas signé numériquement par un certificat Authenticode approuvé par la politique de sécurité de l'entreprise.
Tentative d'exécution d'un binaire non signé sur poste durci :
C:\Users\User\.erable\bin\rg.exe
==> BLOQUÉ PAR LE NOYAU NT (Code Integrity Event ID 3077)
"Windows Defender Application Control a bloqué le fichier car il n'est pas conforme aux règles d'intégrité du code."

Pourquoi cela paralyse les gestionnaires comme Scoop et Homebrew ?

  • Les outils open source distribués sur GitHub (comme ripgrep, neovim, bat, fzf, jq) sont généralement compilés et packagés gratuitement par des mainteneurs bénévoles.
  • L'obtention d'un certificat commercial Microsoft Authenticode (certificat de signature de code EV) coûte entre 300 $ et 800 $ par an et exige une vérification d'identité juridique complexe.
  • En conséquence, 95% des binaires open source portables ne sont pas signés, rendant leur exécution strictement impossible dans un environnement d'entreprise durci.

2. L'Architecture erable : Pipeline de Re-Signature Locale par PKI d'Entreprise

Pour permettre aux développeurs d'utiliser leurs outils open source préférés sur des machines professionnelles sécurisées sans compromettre la politique de sécurité du RSSI, erable intègre un pipeline natif de re-signature locale post-extraction.

flowchart TD
    subgraph Bucket ["1. Dépôt erable (Bucket)"]
        PKG["Archive téléchargée : ripgrep.zip (Hash SHA-256 certifié)"]
    end

    subgraph Moteur ["2. Moteur erable sur Poste Client"]
        EXTRACT["Extraction dans packages/ripgrep/14.1.0/rg.exe (Non signé)"]
        TEST_WDAC{"Politique WDAC Active ou erable_SIGN_HOOK configuré ?"}
        SIGN["Invocation Sécurisée du Hook de Signature Locale (signtool.exe)"]
        VERIF["Vérification Cryptographique du Binaire Signé"]
        DEPLOY["Déploiement du Trampoline et du fichier .target"]
    end

    subgraph EntreprisePKI ["3. Infrastructure de Sécurité d'Entreprise"]
        CERT["Certificat de Signature Interne Entreprise (Stocké en TPM ou Carte à Puce / Store Windows)"]
    end

    PKG --> EXTRACT
    EXTRACT --> TEST_WDAC
    TEST_WDAC -->|Oui| SIGN
    CERT -.->|Applique signature Authenticode| SIGN
    SIGN --> VERIF
    VERIF -->|Signature Valide| DEPLOY
    TEST_WDAC -->|Non (Poste standard)| DEPLOY

3. Spécification Technique de l'Implémentation

3.1 Déclaration de la Configuration de Signature dans ~/.erable/config.nu

L'administrateur système ou le développeur configure le mécanisme de signature approuvé par son entreprise dans son fichier de configuration global :

# ~/.erable/config.nu - Configuration Entreprise

$env.erable_ENTERPRISE_SIGNING = {
    enabled: true,

    # Méthode : "authenticode_embedded" (injection dans le binaire) ou "catalog" (.cat séparé)
    method: "authenticode_embedded",

    # Outil de signature standard (Windows SDK signtool.exe)
    tool_path: "C:/Program Files (x86)/Windows Kits/10/bin/10.0.22621.0/x64/signtool.exe",

    # Empreinte SHA-1 du certificat interne installé dans le magasin "Personnel" (My)
    cert_thumbprint: "3A7F8B9C0D1E2F3A4B5C6D7E8F9A0B1C2D3E4F5A",

    # Serveur d'horodatage RFC-3161 (Timestamp Authority)
    timestamp_server: "http://timestamp.digicert.com"
}

3.2 Implémentation du Pilote de Signature dans platform/windows.nu

Immédiatement après l'extraction de l'archive et avant la création des liens symboliques dans bin/, le pilote Windows exécute la re-signature systématique de tous les exécutables et bibliothèques dynamiques (.exe, .dll) :

# platform/windows.nu - Module de Signature Authenticode

export def sign-binaries-if-configured [install_dir: path] {
    let sign_cfg = ($env.erable_ENTERPRISE_SIGNING? | default { enabled: false })

    if ($sign_cfg.enabled != true) {
        return
    }

    print "[SECURITE WDAC] Détection d'un environnement d'entreprise durci. Re-signature locale des binaires..."

    # Recherche de tous les exécutables et DLLs extraits
    let binaries_to_sign = (ls ($install_dir | path join "**/*") 
        | where type == file 
        | where { $it.name | str ends-with ".exe" or ($it.name | str ends-with ".dll") })

    for bin in $binaries_to_sign {
        print $"[signtool] Signature de : ($bin.name)"

        let sign_res = (do -i {
            ^$sign_cfg.tool_path sign /fd sha256 /sha1 $sign_cfg.cert_thumbprint /tr $sign_cfg.timestamp_server /td sha256 $bin.name
        } | complete)

        if $sign_res.exit_code != 0 {
            error make {
                msg: $"[ERREUR WDAC] Échec de la re-signature locale de '($bin.name)' : ($sign_res.stderr)"
            }
        }
    }

    print "[SECURITE WDAC] Tous les binaires ont été signés avec succès avec le certificat d'entreprise."
}

4. Alternative Légère : Fichiers Catalogs Signés (.cat)

L'injection directe d'une signature Authenticode dans un binaire PE (signtool sign) modifie la structure physique du fichier (ajout de la section IMAGE_DIRECTORY_ENTRY_SECURITY).
Bien que cela n'altère pas l'exécution de 99% des outils, certains rares binaires auto-vérifient leur propre somme de contrôle SHA-256 au démarrage.

Pour ces cas particuliers, erable supporte le mode Catalog (.cat) :

  1. erable génère un fichier de catalogue Windows (package.cdf) listant les empreintes de tous les fichiers extraits.
  2. makecat compile le catalogue.
  3. Seul le fichier package.cat est signé numériquement par signtool.

  4. Le catalogue signé est enregistré dans le sous-système de sécurité Windows via la commande standard :
    signtool catdb /v /u package.cat

  5. Le noyau NT reconnaît alors l'intégrité de tous les binaires du dossier sans avoir modifié un seul octet des exécutables originaux.

5. Résolution du Cas Particulier d'AppLocker sur les Chemins (Path Rules)

Si la politique d'entreprise AppLocker s'appuie sur des règles de chemin plutôt que des règles d'éditeurs (par exemple : interdiction d'exécuter depuis %USERPROFILE%, mais autorisation d'exécuter depuis C:\Tools ou %ProgramData%) :

  • erable résout cette contrainte nativement grâce à la configurabilité de son préfixe racine : 
    # Redirection de la racine erable vers le répertoire autorisé par la politique AppLocker
$env.erable_ROOT = "C:/ProgramData/erable"
  • L'ensemble des répertoires (bin/, packages/, installed/) est immédiatement déporté dans l'espace approuvé par la DSI sans altérer le fonctionnement multi-utilisateurs.