Windows Server 2022 : pilotes ODBC intégrés — faut‑il les supprimer ? Sécurité, correctifs et alternatives

Après l’annonce de vulnérabilités touchant des fichiers ODBC, une question revient : faut‑il retirer les pilotes « in‑box » de Windows Server 2022 ? Voici une réponse pragmatique, axée sécurité, avec procédures et commandes concrètes.

Sommaire

Pilotes ODBC intégrés à Windows Server 2022 : faut‑il les supprimer ?

Vue d’ensemble de la question

Un administrateur a détecté des binaires liés à ODBC dans C:\Windows\SysWOW64 et s’interroge : ces fichiers (DLL et EXE) sont‑ils supprimables pour réduire la surface d’attaque ? Aucune clé de Registre « évidente » ne semble permettre la désactivation, et certains outils de sécurité recommandent de supprimer les composants non indispensables.

Réponse courte

Non, il n’est ni sûr ni supporté de supprimer les pilotes ODBC fournis avec Windows Server 2022. Ils font partie des Windows Data Access Components (souvent appelés « Windows DAC », anciennement MDAC) et sont requis par de nombreux rôles et applications. La stratégie sûre consiste à corriger (patcher), inventorier, retirer uniquement les pilotes tiers inutiles et durcir la configuration, plutôt que de supprimer des fichiers système.

Pourquoi ces fichiers existent‑ils ?

Dans l’architecture ODBC, on distingue :

Le gestionnaire de pilotes ODBC (odbc32.dll) : composant du système qui charge les pilotes, valide les paramètres et route les appels.
Les pilotes ODBC (par ex. sqlsrv32.dll pour l’ancien pilote « SQL Server ») : composants spécifiques à un moteur de base de données.
Les outils d’administration (odbcad32.exe, odbcconf.exe) : création/gestion de DSN, inspection des pilotes.

Sur une édition 64 bits de Windows Server 2022, la règle suivante s’applique :

Répertoire	Architecture	Exemples de binaires ODBC	Rôle
C:\Windows\System32	64 bits	`odbc32.dll`, `odbcad32.exe`, `odbcconf.exe`, `sqlsrv32.dll`	Gestionnaire ODBC et outils 64 bits
C:\Windows\SysWOW64	32 bits	`odbc32.dll`, `odbcad32.exe`, `odbcconf.exe`, `sqlsrv32.dll`	Équivalents 32 bits pour applications x86

Important : ne confondez pas deux acronymes proches :

Windows DAC (Windows Data Access Components) : composants d’accès aux données inclus dans Windows (dont ODBC).
WDAC (Windows Defender Application Control) : fonctionnalité de sécurité (contrôle d’intégrité de code) permettant de restreindre quels binaires peuvent s’exécuter.

Les risques concrets d’une suppression/renommage

Supprimer ou renommer des DLL/EXE ODBC peut :

Empêcher le démarrage de services s’appuyant sur ODBC ou sur des bibliothèques d’accès aux données (IIS, WSUS, moteurs d’ETL, services internes…).
Briser des outils d’administration (ODBC Administrator, assistants d’import/export, connecteurs).
Induire des erreurs applicatives difficiles à diagnostiquer (chargement de driver échoué, DSN introuvable, System.DllNotFoundException, etc.).
Perdre le support éditeur et compliquer la remédiation (SFC/DISM nécessaires).

En d’autres termes, ODBC est un composant de plateforme, au même titre que WinHTTP ou Winsock. On ne le supprime pas ; on le maintient, on l’inventorie, on le contrôle.

Plan d’action recommandé (sécurité d’abord)

1) Appliquer les correctifs de sécurité

Les failles affectant des binaires système (dont ODBC/Windows DAC) sont corrigées via les mises à jour cumulatives mensuelles. Assurez‑vous que le serveur est à jour :

# Lister les 10 derniers correctifs installés
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

# Vérifier les versions des DLL cœur ODBC (64 et 32 bits)

Get-Item 'C:\Windows\System32\odbc32.dll' | Select-Object @{n='File';e={$*.FullName}}, @{n='Version';e={$*.VersionInfo.FileVersion}}
Get-Item 'C:\Windows\SysWOW64\odbc32.dll' | Select-Object @{n='File';e={$*.FullName}}, @{n='Version';e={$*.VersionInfo.FileVersion}}

Si votre politique de patching est décalée, documentez l’écart et appliquez les cumulatives dès que possible (Windows Update, WSUS, Microsoft Configuration Manager).

2) Inventorier les pilotes et DSN réellement utilisés

Avant toute suppression, alignez l’état des lieux : quels pilotes sont installés et quels DSN pointent vers eux ? Utilisez les cmdlets ODBC disponibles nativement :

# Pilotes ODBC installés (32 et 64 bits)
Get-OdbcDriver | ForEach-Object {
  [PSCustomObject]@{
    Name     = $_.Name
    Plateforme = $_.Platform
    Dll      = $_.Attribute['Driver']
    Version  = $_.Attribute['DriverODBCVer']
  }
} | Sort-Object Name, Plateforme | Format-Table -Auto

# DSN (utilisateur, système) et leur pilote

Get-OdbcDsn | Select-Object Name, DsnType, Platform, DriverName | Sort-Object DsnType, Name

Exportez une vue d’inventaire partageable avec l’équipe sécurité :

$drivers = Get-OdbcDriver | ForEach-Object {
  [PSCustomObject]@{
    Type      = 'Driver'
    Name      = $_.Name
    Platform  = $_.Platform
    Dll       = $_.Attribute['Driver']
    Version   = $_.Attribute['DriverODBCVer']
  }
}
$dsns = Get-OdbcDsn | ForEach-Object {
  [PSCustomObject]@{
    Type      = 'DSN'
    Name      = $_.Name
    DsnType   = $_.DsnType
    Platform  = $_.Platform
    Driver    = $_.DriverName
  }
}
$report = $drivers + $dsns
$dest = 'C:\Temp\odbc_inventory.csv'
$null = New-Item -ItemType Directory -Path (Split-Path $dest) -ErrorAction SilentlyContinue
$report | Export-Csv -NoTypeInformation -Path $dest
Write-Host "Inventaire exporté vers $dest"

3) Contrôler l’intégrité et les versions des DLL sensibles

Calculez des empreintes pour intégration SIEM et vérifiez que les versions correspondent à vos baselines après patch :

# Fichiers ODBC cœur à contrôler (liste non exhaustive)
$files = @(
  'C:\Windows\System32\odbc32.dll',
  'C:\Windows\System32\odbcconf.exe',
  'C:\Windows\System32\odbcad32.exe',
  'C:\Windows\System32\sqlsrv32.dll',
  'C:\Windows\SysWOW64\odbc32.dll',
  'C:\Windows\SysWOW64\odbcconf.exe',
  'C:\Windows\SysWOW64\odbcad32.exe',
  'C:\Windows\SysWOW64\sqlsrv32.dll'
) | Where-Object { Test-Path $_ }

$files | ForEach-Object {
$fi = Get-Item $_
[PSCustomObject]@{
File     = $fi.FullName
Version  = $fi.VersionInfo.FileVersion
Sha256   = (Get-FileHash $fi.FullName -Algorithm SHA256).Hash
}
} | Format-Table -Auto

4) Retirer uniquement les pilotes tiers inutilisés

Les pilotes ODBC modernes pour bases de données (ex. « ODBC Driver 18 for SQL Server », pilotes Oracle/MySQL/PostgreSQL) ne font pas partie du cœur Windows : ils sont installés par les administrateurs, par des rôles applicatifs ou par des setups. Ce sont eux que vous pouvez cibler en priorité s’ils ne sont plus nécessaires.

Identifiez les DSN qui s’y rattachent via Get-OdbcDsn ou odbcad32.exe.
Supprimez d’abord les DSN correspondants (onglet Sources de données dans odbcad32.exe 32 bits et 64 bits).
Désinstallez le pilote via Programmes et fonctionnalités / Applications (ou l’uninstalleur éditeur). Évitez les suppressions manuelles de fichiers DLL.

Attention : retirer un DSN ne désinstalle pas le pilote. Inversement, retirer un pilote toujours référencé par un DSN cassera les connexions.

5) Limiter l’exposition (durcissement sans casse)

Restreindre l’accès à l’Administration ODBC

Si seuls les administrateurs doivent gérer les DSN, restreignez l’exécution d’odbcad32.exe :

# Exemple : retirer l'exécution aux utilisateurs non-admins (testez en préprod)
icacls "C:\Windows\System32\odbcad32.exe" /inheritance:r
icacls "C:\Windows\System32\odbcad32.exe" /grant:r "Administrators:(RX)"
icacls "C:\Windows\System32\odbcad32.exe" /deny "Users:(X)"
icacls "C:\Windows\SysWOW64\odbcad32.exe" /inheritance:r
icacls "C:\Windows\SysWOW64\odbcad32.exe" /grant:r "Administrators:(RX)"
icacls "C:\Windows\SysWOW64\odbcad32.exe" /deny "Users:(X)"

Alternative plus souple : un raccourci protégé par UAC, ou un Just‑Enough Administration (JEA) exposant des fonctions PowerShell pour créer/modifier des DSN.

Bloquer le chargement de DLL depuis des emplacements non approuvés

Même si ODBC lui‑même est patché, la chaîne de confiance doit empêcher l’injection de DLL malicieuses. Trois approches complémentaires :

Windows Defender Application Control (WDAC) : créez une politique d’audit puis de refus des binaires non signés/tiers en dehors des répertoires système.
AppLocker : appliquez des règles chemin/éditeur pour autoriser uniquement %WINDIR%\System32 et %WINDIR%\SysWOW64 pour les DLL exécutées par vos services.
Software Restriction Policies (SRP) : en environnements hérités, bloquez %USERPROFILE%\AppData\*, %PROGRAMDATA%\* pour les bibliothèques chargeables.

Exemple WDAC en mode audit (à raffiner selon vos besoins) :

# Générer une politique WDAC de base en audit (autoriser éditeur Microsoft)
$xml = 'C:\Temp\cipolicy.xml'
$bin = 'C:\Temp\cipolicy.bin'
New-CIPolicy -Level Publisher -Fallback Hash -FilePath $xml -UserPEs
Set-RuleOption -FilePath $xml -Option 3     # Activer le mode Audit
ConvertFrom-CIPolicy -XmlFilePath $xml -BinaryFilePath $bin
# Déployer le .bin dans C:\Windows\System32\CodeIntegrity\ (redémarrage requis pour prise en compte)

Avec AppLocker, créez des règles « Autoriser » pour %WINDIR%\System32\*.dll et « Refuser » pour les répertoires écrits par les utilisateurs. Placez l’ensemble en Audit d’abord, puis Appliquer.

Surcouche EDR/Exploit Protection

Activez l’enregistrement des chargements de modules (via EDR/SIEM) pour repérer des DLL ODBC en dehors des chemins attendus.
Utilisez les ASR (rules) adaptées à votre parc et désactivez l’exécution depuis zones web/téléchargements quand cela n’impacte pas vos applis.

6) Surveiller en continu

Installez une télémétrie minimale :

Journaux CodeIntegrity/Operational (WDAC) et AppLocker.
Événements 4688 (création de processus) pour odbcad32.exe et odbcconf.exe.
Hachages des DLL ODBC essentiels (liste ci‑dessus), envoyés régulièrement au SIEM.

« À éviter » (et pourquoi)

Suppression manuelle de odbc* ou sqlsrv32.dll : forte probabilité d’instabilité et de perte de support.
Modifications hasardeuses du Registre : ODBC s’appuie sur plusieurs ruches (64 bits et 32 bits). Une clé désactivée isolément crée des incohérences sans réelle mitigation.
Blocage brutal d’odbcad32.exe pour tous les comptes : privilégiez un déni ciblé (utilisateurs standards), laissez l’accès aux administrateurs.

Clés de Registre utiles (lecture, pas « désactivation »)

Pour inspection/audit (ne pas supprimer sans plan de retour arrière) :

Clé	Usage	Architecture
`HKLM\SOFTWARE\ODBC\ODBCINST.INI\ODBC Drivers`	Liste des pilotes 64 bits	64 bits
`HKLM\SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI\ODBC Drivers`	Liste des pilotes 32 bits	32 bits
`HKLM\SOFTWARE\ODBC\ODBC.INI` / `HKCU\SOFTWARE\ODBC\ODBC.INI`	Définition des DSN (système / utilisateur)	64 bits
`HKLM\SOFTWARE\WOW6432Node\ODBC\ODBC.INI` / `HKCU\SOFTWARE\WOW6432Node\ODBC\ODBC.INI`	Définition des DSN (système / utilisateur)	32 bits

Là encore, privilégiez Get-OdbcDriver, Get-OdbcDsn et odbcad32.exe pour gérer, plutôt que d’éditer ces clés à la main.

FAQ & cas pratiques

Les pilotes SQL Server « ODBC Driver 18/17 » sont‑ils fournis par Windows ?

Non. Windows fournit le gestionnaire ODBC et certains composants de compatibilité (dont le pilote hérité sqlsrv32.dll). Les pilotes modernes SQL Server (ODBC 17/18), Oracle, MySQL, PostgreSQL sont installés séparément. Inventoriez‑les et désinstallez ceux qui sont réellement inutiles.

Comment savoir si un service utilise ODBC ?

Plusieurs approches : audit des DSN, revue de configuration applicative, observation des chargements de modules (EDR, Process Monitor en pré‑production) pour vérifier l’ouverture de odbc32.dll et du pilote cible.

Existe‑t‑il une GPO « désactiver ODBC » globale ?

Non. ODBC est un composant de plateforme. Utilisez plutôt WDAC/AppLocker pour restreindre l’exécution et le chargement de DLL depuis des zones non approuvées, et contrôlez l’accès à l’outil d’administration.

Je dois absolument neutraliser un pilote tiers vulnérable mais encore présent. Que faire ?

Retirer les DSN qui l’utilisent.
Isoler le binaire en ajustant les ACL (retrait de l’exécution pour les comptes de service non concernés).
WDAC/AppLocker pour bloquer sa DLL par éditeur/hash en Audit puis Enforcement.
Plan de remédiation avec l’éditeur (version corrigée) et fenêtre de maintenance.

Et si quelqu’un a déjà supprimé une DLL ODBC « pour voir » ?

Restaurez l’état système :

# Vérifier et réparer les composants manquants/corrompus
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

En cas d’endommagement persistant, procédez à une réparation sur place de Windows (in‑place upgrade) pendant une fenêtre de maintenance.

Bonnes pratiques opérationnelles

Baselines : conservez un snapshot (versions + SHA256) des DLL ODBC après chaque Patch Tuesday.
Moindre privilège : réservez l’accès à odbcad32.exe aux administrateurs, et déléguez via JEA si nécessaire.
Élimination des héritages : traquez les pilotes « orphelins » (plus de DSN, plus d’applications) et désinstallez‑les proprement.
Tests : avant tout durcissement (WDAC/AppLocker/ACL), activez d’abord un mode audit et surveillez plusieurs cycles d’activité.
Documentation : liez chaque pilote à un Owner applicatif et une fenêtre de patch dédiée.

Tableau récapitulatif des actions

Action	Commande / Outil	Objectif	Impact applicatif
Vérifier les cumulatives installées	`Get-HotFix`	Confirmer l’application des patchs récents	Sans impact
Lister les pilotes ODBC	`Get-OdbcDriver`	Voir les pilotes actifs et leurs DLL	Sans impact
Lister les DSN	`Get-OdbcDsn` / `odbcad32.exe`	Identifier les connexions configurées	Sans impact
Contrôler version & hash des DLL	`Get-Item`, `Get-FileHash`	Baseline d’intégrité	Sans impact
Restreindre l’accès à ODBC Admin	`icacls`	Moindre privilège	Faible (si ciblé)
Durcir le chargement de DLL	WDAC/AppLocker	Empêcher des DLL non approuvées	Moyen (tester d’abord)
Désinstaller pilotes tiers	Programmes & fonctionnalités	Réduire la surface d’attaque	Variable (vérifier les DSN)

Checklist décisionnelle

✔️ Le serveur est‑il à jour (Patch Tuesday appliqué) ?
✔️ Ai‑je l’inventaire des pilotes et des DSN ?
✔️ Ai‑je identifié des pilotes tiers non utilisés ? (si oui, plan de désinstallation)
✔️ Les administrateurs seuls peuvent‑ils lancer odbcad32.exe ?
✔️ WDAC/AppLocker est‑il en Audit (puis Enforcement) pour bloquer les DLL non approuvées ?
✔️ Les logs de chargement de modules et les hachages sont‑ils envoyés au SIEM ?

Conclusion

Les pilotes ODBC intégrés à Windows Server 2022 existent par conception et supportent une large variété de services et d’applications. Les supprimer n’est pas une mesure de sécurité : c’est une source d’instabilité. La bonne approche consiste à rester à jour, inventorier, retirer proprement les pilotes tiers inutiles et durcir le chargement de DLL avec WDAC/AppLocker, tout en contrôlant l’accès à l’outil d’administration. En procédant ainsi, vous réduisez réellement la surface d’attaque sans casser le système.

Annexes : repères utiles

Où se trouvent les deux ODBC Admin ?

64 bits : C:\Windows\System32\odbcad32.exe
32 bits : C:\Windows\SysWOW64\odbcad32.exe

Fichiers système ODBC courants (non exhaustif)

odbc32.dll – gestionnaire ODBC
odbcad32.exe – administration ODBC
odbcconf.exe – configuration ODBC en ligne de commande
sqlsrv32.dll – pilote ODBC hérité « SQL Server »

Commande rapide de vérification version+hash

$core = 'C:\Windows\System32\odbc32.dll','C:\Windows\SysWOW64\odbc32.dll'
$core | % { (Get-Item $_).VersionInfo | Select-Object FileName,FileVersion }
$core | % { Get-FileHash $_ -Algorithm SHA256 | Select-Object Path,Hash }

Rappel : testez toujours vos changements (ACL, WDAC, AppLocker) en pré‑production, avec un plan de retour arrière clair.

Windows Server 2022 : pilotes ODBC intégrés — faut‑il les supprimer ? Sécurité, correctifs et alternatives