Comment le module de politique TameMyCerts pour Active Directory Certificate Services (ADCS) peut aider à sécuriser des scénarios avec Microsoft Intune et d'autres systèmes de gestion des dispositifs mobiles (MDM)

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 :

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.

Modèle de fromage suisse. Source de l'image (adaptée) : Wikipedia / Davidmack, sous licence sous CC BY-SA 3.0.

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 :

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

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.

TameMyCerts a refusé une demande de certificat qui ne respectait pas les règles définies.

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 :

Sources externes

fr_FRFrançais