Découvrez la gestion déclarative des appareils dans Jamf School.

Qu'est-ce que la gestion déclarative des appareils (DDM) ?

Annoncée lors de la WWDC 2021, la gestion déclarative des appareils (déjà connue sous le nom de DDM – les administrateurs Mac adorent les acronymes) est une sorte de « version 2.0 » de la MDM. Pour dire les choses simplement, la DDM rend les appareils plus intelligents et réduit le nombre d'échanges entre un appareil et le serveur MDM. Avec la DDM, les appareils informent le serveur MDM de leur état actuel en toute autonomie. Ils peuvent également évaluer leur propre état, puis appliquer ou désactiver des réglages en conséquence.

Soulignons toutefois que la DDM ne remplace pas la MDM. C'est un cadre qui s'intègre à la spécification MDM pour offrir une nouvelle façon de gérer les appareils Apple, en complément de la MDM.

Quel est l'intérêt de la gestion déclarative des appareils (DDM) ?

La spécification MDM telle que nous la connaissons aujourd'hui existe depuis une dizaine d'années – quasiment une ère géologique dans le monde de l'informatique. Les choses évoluent, le nombre d'appareils déployés augmente et la technologie s'améliore. La gestion déclarative des appareils est la réponse d'Apple à l'évolution constante de l'informatique.

Pour comprendre l'impact considérable que va avoir la DDM, faisons d'abord un point sur le fonctionnement actuel de la MDM à haut niveau.

La MDM dans l'éducation aujourd'hui

Aujourd'hui, l'appareil et le serveur MDM échangent fréquemment. En effet, l'appareil ne peut réaliser aucune opération gestion sans une instruction du serveur MDM. L'appareil ne sait même pas qu'il doit contacter le serveur tant que celui-ci ne le lui a pas dit.

Généralement, la communication entre un appareil et son serveur MDM se déroule comme suit :

1. Le serveur MDM demande à Apple d'envoyer une notification push à l'appareil pour lui demander de le contacter.
2. Apple demande à l'appareil de se connecter à son serveur MDM.
3. L'appareil envoie ensuite au serveur MDM un message qui s'apparente à « On m'a demandé de vous contacter ».
4. Le serveur MDM peut répondre, par exemple : « Pouvez-vous me dire quel est votre état (version de l'OS, activation du code secret, applications installées, etc.) ? »
5. L'appareil fournit les informations demandées.
6. Sur cette base, le serveur peut envoyer à l'appareil une configuration supplémentaire.
7. Et l'appareil applique la configuration en question.
8. Le serveur demande ensuite à l'appareil de lui communiquer son nouvel état ou de confirmer qu'il a appliqué la nouvelle configuration.
9. L'appareil répond en donnant son nouvel état.

Cela représente beaucoup de trafic réseau pour un seul échange. Maintenant, multipliez ces allers-retours par le (grand) nombre de transactions survenant chaque jour sur les centaines, voire les milliers d'appareils de votre déploiement. Et si l'état de l'appareil change entre deux prises de contact avec le serveur MDM, la MDM – et donc l'administrateur – n'en a aucune idée.

Quels sont les inconvénients de cette approche ?

Prenons un exemple.

Un appareil vient de contacter le serveur et d'indiquer qu'il est sécurisé par un code. En tant qu'administrateur Jamf School, je peux voir dans la console que l'appareil est conforme à notre règle sur l'activation du code. Si l'appareil n'a pas de code secret, j'ajoute une configuration supplémentaire qui masque les applications contenant des données sensibles, comme le client d'e-mail ou les applications de stockage cloud, en ajoutant l'appareil à un groupe intelligent.

Cinq minutes après la prise de contact, l'utilisateur décide de supprimer le code de l'appareil, car il en a assez de le saisir à répétition pendant qu'il travaille dans un café.

L'appareil n'est plus conforme à notre règle. Pourtant, si je consulte la console Jamf School, l'appareil apparaît toujours conforme et le reste jusqu'à ce qu'à la prochaine prise de contact.

Autrement dit, l'appareil ne sait pas qu'il doit appliquer une configuration supplémentaire, et ses applications sensibles restent utilisables. Entre-temps, l'utilisateur a quitté le café en oubliant son iPad. Un client du café prend l'appareil et commence à parcourir les e-mails de notre utilisateur, qui se trouve être le principal d'une grande école secondaire.

La fréquence de contact d'un appareil dépend de votre solution MDM. Dans le cas de Jamf School, c'est toutes les deux heures. Il peut donc s'écouler jusqu'à deux heures avant que l'appareil ne se manifeste à nouveau auprès de Jamf School, l'informe qu'il n'a plus de code secret et soit classé dans le groupe intelligent qui lui enverra une configuration supplémentaire adéquate.

Comment la DDM va-t-elle améliorer mes workflows ?

• Le canal de statut permet aux appareils de publier certaines données d'inventaire de façon proactive. Le serveur peut s'abonner à ce canal pour recevoir les informations en question. Les appareils ont donc un moyen de signaler d'eux-mêmes un changement d'état dans les secondes qui suivent.
• Et grâce aux déclarations, l'appareil peut décider des configurations à appliquer en fonction de son état. Imaginons que l'entreprise souhaite appliquer une configuration VPN, mais seulement si l'appareil est protégé par un code secret. Les déclarations fournissent à la fois le détail de la configuration VPN et les conditions nécessaires à son application. Quand l'appareil remplit ces conditions, il applique la configuration VPN en toute autonomie.

La DDM ne se contente pas de réduire les échanges entre l'appareil et le serveur MDM : elle apporte aussi une grande fluidité à l'expérience utilisateur.

Et c'est tout l'objectif : offrir une technologie qui soutient l'enseignement et l'apprentissage sans l'entraver.

Je vous recommande vivement de regarder la conférence Declarative Device Management de la WWDC 2021 pour un aperçu plus approfondi de cette méthode.

Comment la DDM est-elle prise en charge dans Jamf School ?

Jamf School prend désormais en charge plusieurs informations d'inventaire qui pourront être publiées via le canal de statut – modèle d'appareil, OS installé, identifiants de l'appareil et activation du code secret.

Voici la liste complète des attributs DDM pris en charge par Jamf :

• device.model.family
• device.model.identifier
• device.model.marketing-name
• device.operating-system.build-version
• device.operating-system.family
• device.operating-system.marketing-name
• device.operating-system.version
• device.identifier.serial-number
• device.identifier.udid
• passcode.is-compliant
• passcode.is-present

En tant qu'administrateur Jamf School, vous n'avez rien à configurer. Jamf School enverra automatiquement une commande de gestion à distance pour activer la gestion déclarative des appareils sur les appareils compatibles.

Pour être compatibles, les appareils doivent être équipés de macOS 13 ou plus, d'iOS 16.1 ou iPadOS 16.1 ou plus, ou encore de tvOS 16 ou plus.

Dans la console Jamf School, les nouveaux éléments d'inventaire « Gestion déclarative des appareils prise en charge » et « Gestion déclarative des appareils activée » vous indiquent quels appareils sont compatibles et si la DDM est activée.

Pour plus d'informations, lisez la documentation de Jamf School.

Quel est l'impact sur mon travail de la prise en charge de la DDM dans Jamf School ?

En dehors des rapports quasi instantanés sur les éléments d'inventaire évoqués plus haut, qui peuvent s'avérer utiles au moment de la sortie d'un nouvel OS, cette mise à jour n'affectera pas les administrateurs Jamf School.

Soulignons toutefois l'intérêt du signalement de l'activation du code secret. Nous avons vu à quel point il pouvait être utile dans le scénario où un utilisateur oublie son appareil dans un café après avoir désactivé son code.

L'expérience serait bien meilleure avec la prise en charge du canal de statut. Jamf School est abonné au canal qui signale la présence ou l'absence de code secret : dans les secondes qui suivent sa désactivation, l'appareil en informe Jamf School spontanément et en toute autonomie. C'est toute la puissance de la DDM.

Dès que Jamf School est informé du changement (« Code présent = Oui » est devenu « Code présent = Non »), l'appareil est ajouté au groupe intelligent des appareils sans code secret, quelques secondes seulement après la désactivation. L'appartenance à ce groupe implique automatiquement l'envoi d'une configuration supplémentaire qui masque les applications sensibles. Cette fois, c'est la « MDM traditionnelle » qui se charge de déployer le profil.

Résultat : dans les minutes qui suivent la suppression du code (en 30 secondes la plupart du temps selon mes tests), l'appareil masque les applications sensibles.

C'est un progrès considérable, obtenu uniquement avec le canal de statut et la MDM avec déploiement côté serveur. Mais à l'avenir, les déclarations permettront sans doute de faire tout cela instantanément et de manière autonome.

L'avenir de la prise en charge de la DDM dans Jamf School

L'ajout de la DDM est une étape passionnante pour notre solution ! Aujourd'hui, la transmission des données d'inventaire sur le canal de statut n'a pas encore un impact énorme sur les administrateurs. Mais comme le montre l'exemple du code secret, c'est le début d'une nouvelle ère pour la gestion des appareils Apple avec Jamf School.

Nous l'avons dit, le canal de statut n'est qu'une partie de la gestion déclarative des appareils. Apple apporte chaque année de nouveaux éléments à ce cadre, et nous attendons avec impatience la disponibilité des déclarations à grande échelle.

Elles vont véritablement changer la donne. Place à la MDM 2.0 et à la WWDC 2023 ! Je suis sûr qu'elle dévoilera bien d'autres nouveautés sur la DDM.