Les entreprises utilisent Gestion des dispositifs mobiles (MDM) Produits permettant de gérer, de configurer et de mettre à jour des appareils mobiles tels que des smartphones, des tablettes ou des systèmes de bureau via Internet (Over-the-Air, OTA).
Les produits de gestion des dispositifs mobiles les plus courants sont :
- Microsoft Intune
- VMware Workspace One (précédemment connu sous le nom de marque AirWatch)
- Ivanti MobileIron UEM
- Jamf Pro
- Gestion de la mobilité d'entreprise Baramundi
- BlackBerry Enterprise Mobility Suite
- Sophos Mobile Control
- SOTI MobiControl
- Samsung Knox
- IBM MaaS360
TameMyCerts est un Module de politiquepour sécuriser l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend les fonctions de l'autorité de certification et permet de l'application élargie de la réglementationIl permet d'automatiser en toute sécurité l'émission de certificats. TameMyCerts est unique dans l'écosystème Microsoft et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement.
TameMyCerts est open source et peut être utilisé gratuitement. Toutefois, pour une utilisation en entreprise, il est recommandé d'utiliser le Conclusion d'un contrat de maintenance. Cela garantit que vous recevrez un soutien qualifié et que le module pourra être développé à long terme avec une qualité élevée.
Fonctionnement
Tous ces systèmes, associés à une autorité de certification Microsoft, utilisent un concept comparable : ils agissent comme un intermédiaire entre l'appareil géré, le service d'annuaire de l'entreprise et l'autorité de certification. En termes de PKI, ils remplissent le rôle de l'autorité de certification. Autorité d'enregistrement (angl. Registration Authority, RA) à partir de. Ils utilisent tous une sorte de connecteur pour transmettre les demandes de certificat à l'autorité de certification Microsoft AD CS.
Tous les systèmes MDM courants exigent donc que le modèle de certificat configuré soit configuré comme modèle de certificat hors ligne, c'est-à-dire que l'identité contenue dans le certificat et confirmée par l'autorité de certification soit prédéfinie par le demandeur, c'est-à-dire le système MDM („Enrollee supplies Subject“).

L'organisme de certification doit donc n'a aucune connaissance du contenu du certificat demandé, elle délivre les exigences de certification à l'aveugle et doit être faire entièrement confiance au système MDM à cet égard.
Les erreurs de classement par le système MDM ne sont pas rares
Il n'est malheureusement pas rare que des erreurs soient commises par le système MDM ou avec ses autorisations. Les raisons possibles sont les suivantes
- Mauvaise configuration du système MDM.
- un mauvais comportement du système MDM. Par exemple, il peut arriver que des certificats soient demandés pour des appareils qui ne sont plus associés à un utilisateur existant. Dans ce cas, il peut arriver que des certificats soient demandés avec des identités vides.
- Compromettre le compte de service utilisé et exploiter ses autorisations de demande (voir attaque ESC1).
C'est donc la porte ouverte aux incidents de sécurité et de protection des données.
Les installations habituelles de systèmes MDM en combinaison avec les services de certificats Microsoft Active Directory sont donc vulnérables au Modèle de fromage suisse, Il s'agit d'un système dans lequel de petites lacunes qui traversent la chaîne de tous les systèmes impliqués peuvent entraîner des dommages importants.

Exemple concret : aucun utilisateur valide n'est attribué à un appareil géré.
Dans la pratique, il arrive souvent avec les systèmes MDM qu'aucun compte d'utilisateur valable ne soit attribué à un terminal géré.
Dans un cas simple, il serait par exemple configuré que le Subject Distinguished Name (DN) d'un certificat contienne un commonName avec la variable du nom d'utilisateur.
CN={EnrollmentUser}
Dans cet exemple, nous utilisons la syntaxe de VMware Workspace One, mais tous les systèmes MDM courants fonctionnent de manière comparable.
Si cette variable est vide parce qu'aucun compte d'utilisateur valable n'est attribué au terminal, une demande de certificat avec un Subject Distinguished Name (DN) vide peut être générée. Il semble que les systèmes MDM se comportent différemment dans ce cas :
- Gestion de la mobilité d'entreprise Baramundi génère dans ce cas une séquence vide et l'autorité de certification refusera la demande de certificat avec le message d'erreur „Error Parsing Request The request subject name is invalid or too long. 0x80094001 (-2146877439 CERTSRV_E_BAD_REQUESTSUBJECT)“ refuser.
- VMware Workspace One va générer une demande de certificat avec un Subject Distinguished Name (DN) contenant un commonName vide. Une telle demande de certificat est émise par l'autorité de certification. Le certificat qui en résulte ne contiendra cependant pas d'identité.
Si l'on a en plus la malchance que l'application qui vérifie le certificat lors de la connexion (p. ex. un système d'authentification unique (SSO)) ne puisse pas gérer un tel cas de manière adéquate, il peut arriver qu'avec un tel certificat, l'identité d'un autre utilisateur valide soit attribuée lors de la connexion. Et voilà, l'incident de sécurité et de protection des données est terminé.
La solution : TameMyCerts
Le module TameMyCerts Policy pour Microsoft Active Directory Certificate Services peut combler cette lacune au niveau de l'autorité de certification en permettant de contrôler les demandes de certificats par la mise en œuvre d'un ensemble de règles finement granulaires.
Parmi les possibilités, on peut citer
- Imposer des règles syntaxiques pour la langue demandée Subject Distinguished Name et Sujet Nom alternatif.
- Création d'une Lien entre l'identité demandée dans le certificat et l'objet correspondant dans Active Directory. Appliquer des règles à l'objet associé, par exemple sur la base de son statut (actif ou désactivé), de son appartenance à des groupes ou à des unités organisationnelles et d'autres critères.
- Modification du contenu du certificat demandé avant l'émission du certificat. Transférer ou supprimer des champs de certificat, ajouter des valeurs statiques ou des valeurs de l'objet Active Directory associé.
Les demandes de certificat qui ne respectent pas les règles définies sont rejetées et l'incident est clos. consigne. Il est ainsi possible de mettre en place une alerte afin de pouvoir suivre les incidents de sécurité potentiels.

Microsoft Intune utilise le Service d'inscription des périphériques réseau (NDES) comme connecteur entre Intune et l'autorité de certification. NDES, tout comme l'autorité de certification elle-même, peut être complétée par des modules de politique. Microsoft met à disposition pour Intune un module de politique pour NDES, il n'est donc pas possible d'ajouter un autre module de politique à une instance NDES qui a été configurée pour Intune. Cependant, comme TameMyCerts opère au niveau de l'autorité de certification et est installé sur celle-ci, il est possible de combiner sans problème les avantages des deux modules.
Liens complémentaires :
- Un module de politique pour les apprivoiser : Présentation du module de politique TameMyCerts pour Microsoft Active Directory Certificate Services
- Principes de base du service d'enregistrement des périphériques réseau (Network Device Enrollment Service, NDES)
Sources externes
- Guide d'intégration et d'administration pour le module de politique TameMyCerts pour Active Directory Certificate Services
- Extension de la surface d'attaque AD CS au cloud avec les certificats Intune - dirkjanm.io (Dirk-jan Mollema)
- VU#971035 - Le protocole SCEP (Simple Certificate Enrollment Protocol) n'authentifie pas strictement les demandes de certificat (Université Carnegie Mellon)
- Swiss cheese model (Wikipedia)