Référence technique des contrôles cryptographiques

S’applique à : Configuration Manager (branche actuelle)

Configuration Manager utilise la signature et le chiffrement pour protéger la gestion des appareils dans la hiérarchie Configuration Manager. Avec la signature, si les données ont été modifiées en transit, elles sont ignorées. Le chiffrement permet d’empêcher un attaquant de lire les données à l’aide d’un analyseur de protocole réseau.

L’algorithme de hachage principal utilisé par Configuration Manager pour la signature est SHA-256. Lorsque deux sites Configuration Manager communiquent entre eux, ils signent leurs communications avec SHA-256.

À compter de la version 2107, l’algorithme de chiffrement principal utilisé par Configuration Manager est AES-256. Le chiffrement se produit principalement dans les deux domaines suivants :

• Si vous autorisez le site à utiliser le chiffrement, le client chiffre ses données d’inventaire et les messages d’état qu’il envoie au point de gestion.

• Lorsque le client télécharge des stratégies secrètes, le point de gestion chiffre toujours ces stratégies. Par exemple, une séquence de tâches de déploiement de système d’exploitation qui inclut des mots de passe.

Lorsque vous utilisez la communication cliente via HTTPS, configurez votre infrastructure à clé publique (PKI) pour utiliser des certificats avec les algorithmes de hachage et les longueurs de clés maximales. Lorsque vous utilisez des certificats CNG v3, Configuration Manager clients prennent uniquement en charge les certificats qui utilisent l’algorithme de chiffrement RSA. Pour plus d’informations, consultez Configuration requise pour les certificats PKI et Vue d’ensemble des certificats CNG v3.

Pour la sécurité du transport, tout ce qui utilise TLS prend en charge AES-256. Cette prise en charge inclut lorsque vous configurez le site pour http amélioré (E-HTTP) ou HTTPS. Pour les systèmes de site locaux, vous pouvez contrôler les suites de chiffrement TLS. Pour les rôles basés sur le cloud comme la passerelle de gestion cloud (CMG), si vous activez TLS 1.2, Configuration Manager configure les suites de chiffrement.

Pour la plupart des opérations de chiffrement avec des systèmes d’exploitation Windows, Configuration Manager utilise ces algorithmes à partir de la bibliothèque CryptoAPI Windows rsaenh.dll.

Pour plus d’informations sur des fonctionnalités spécifiques, consultez Opérations de site.

Opérations de site

Les informations contenues dans Configuration Manager peuvent être signées et chiffrées. Il prend en charge ces opérations avec ou sans certificats PKI.

Signature et chiffrement de stratégie

Le site signe les affectations de stratégie client avec son certificat auto-signé. Ce comportement permet d’éviter le risque de sécurité d’un point de gestion compromis d’envoyer des stratégies falsifiées. Si vous utilisez la gestion des clients basée sur Internet, ce comportement est important, car il nécessite un point de gestion accessible sur Internet.

Lorsque la stratégie contient des données sensibles, à compter de la version 2107, le point de gestion la chiffre avec AES-256. La stratégie qui contient des données sensibles est envoyée uniquement aux clients autorisés. Le site ne chiffre pas la stratégie qui n’a pas de données sensibles.

Lorsqu’un client stocke une stratégie, il chiffre la stratégie à l’aide de l’interface de programmation d’application de protection des données (DPAPI) Windows.

Hachage de stratégie

Lorsqu’un client demande une stratégie, il obtient d’abord une affectation de stratégie. Ensuite, il sait quelles stratégies s’appliquent à elle et il peut demander uniquement ces organismes de stratégie. Chaque affectation de stratégie contient le hachage calculé pour le corps de stratégie correspondant. Le client télécharge les corps de stratégie applicables, puis calcule le hachage pour chaque corps de stratégie. Si le hachage sur le corps de la stratégie ne correspond pas au hachage dans l’attribution de stratégie, le client ignore le corps de la stratégie.

L’algorithme de hachage pour la stratégie est SHA-256.

Hachage de contenu

Le service gestionnaire de distribution sur le serveur de site hache les fichiers de contenu de tous les packages. Le fournisseur de stratégies inclut le hachage dans la stratégie de distribution de logiciels. Lorsque le client Configuration Manager télécharge le contenu, il régénère le hachage localement et le compare à celui fourni dans la stratégie. Si les hachages correspondent, le contenu n’est pas modifié et le client l’installe. Si un seul octet du contenu est modifié, les hachages ne correspondent pas et le client n’installe pas le logiciel. Cette case activée permet de s’assurer que le logiciel approprié est installé, car le contenu réel est comparé à la stratégie.

L’algorithme de hachage par défaut pour le contenu est SHA-256.

Tous les appareils ne peuvent pas prendre en charge le hachage de contenu. Les exceptions sont les suivantes :

• Clients Windows quand ils diffusent du contenu App-V.

Signature et chiffrement de l’inventaire

Lorsqu’un client envoie un inventaire matériel ou logiciel à un point de gestion, il signe toujours l’inventaire. Peu importe si le client communique avec le point de gestion via E-HTTP ou HTTPS. S’ils utilisent E-HTTP, vous pouvez également choisir de chiffrer ces données, ce qui est recommandé.

Chiffrement de la migration d’état

Lorsqu’une séquence de tâches capture des données d’un client pour le déploiement du système d’exploitation, elle chiffre toujours les données. Dans les versions 2103 et ultérieures, la séquence de tâches exécute l’outil de migration d’état utilisateur (USMT) avec l’algorithme de chiffrement AES-256 .

Chiffrement des packages de multidiffusion

Pour chaque package de déploiement de système d’exploitation, vous pouvez activer le chiffrement lorsque vous utilisez la multidiffusion. Ce chiffrement utilise l’algorithme AES-256 . Si vous activez le chiffrement, aucune autre configuration de certificat n’est requise. Le point de distribution compatible avec la multidiffusion génère automatiquement des clés symétriques pour chiffrer le package. Chaque package a une clé de chiffrement différente. La clé est stockée sur le point de distribution compatible avec la multidiffusion à l’aide d’API Windows standard.

Lorsque le client se connecte à la session de multidiffusion, l’échange de clés se produit sur un canal chiffré. Si le client utilise HTTPS, il utilise le certificat d’authentification client émis par l’infrastructure à clé publique. Si le client utilise E-HTTP, il utilise le certificat auto-signé. Le client stocke uniquement la clé de chiffrement en mémoire pendant la session de multidiffusion.

Chiffrement du support de déploiement du système d’exploitation

Lorsque vous utilisez un média pour déployer des systèmes d’exploitation, vous devez toujours spécifier un mot de passe pour protéger le média. Avec un mot de passe, les variables d’environnement de séquence de tâches sont chiffrées avec AES-128. Les autres données sur le média, y compris les packages et le contenu des applications, ne sont pas chiffrées.

Chiffrement du contenu basé sur le cloud

Lorsque vous activez une passerelle de gestion cloud (CMG) pour stocker du contenu, le contenu est chiffré avec AES-256. Le contenu est chiffré chaque fois que vous le mettez à jour. Lorsque les clients téléchargent le contenu, il est chiffré et protégé par la connexion HTTPS.

Connexion aux mises à jour logicielles

Toutes les mises à jour logicielles doivent être signées par un éditeur approuvé pour vous protéger contre la falsification. Sur les ordinateurs clients, l’agent Windows Update (WUA) recherche les mises à jour du catalogue. Il n’installe pas la mise à jour s’il ne peut pas localiser le certificat numérique dans le magasin Éditeurs approuvés sur l’ordinateur local.

Lorsque vous publiez des mises à jour logicielles avec System Center Mises à jour Publisher, un certificat numérique signe les mises à jour logicielles. Vous pouvez spécifier un certificat PKI ou configurer Mises à jour Publisher pour générer un certificat auto-signé pour signer la mise à jour logicielle. Si vous utilisez un certificat auto-signé pour publier le catalogue de mises à jour, tel que Les éditeurs WSUS auto-signés, le certificat doit également se trouver dans le magasin de certificats Autorités de certification racines de confiance sur l’ordinateur local. WUA vérifie également si le paramètre de stratégie de groupe Autoriser le contenu signé à partir de l’emplacement intranet du service de mise à jour Microsoft est activé sur l’ordinateur local. Ce paramètre de stratégie doit être activé pour que WUA recherche les mises à jour qui ont été créées et publiées avec System Center Mises à jour Publisher.

Données de configuration signées pour les paramètres de conformité

Lorsque vous importez des données de configuration, Configuration Manager vérifie la signature numérique du fichier. Si les fichiers ne sont pas signés ou si la signature case activée échoue, la console vous avertit de continuer l’importation. Importez les données de configuration uniquement si vous faites explicitement confiance à l’éditeur et à l’intégrité des fichiers.

Chiffrement et hachage pour la notification client

Si vous utilisez la notification du client, toutes les communications utilisent TLS et les algorithmes les plus élevés que le serveur et le client peuvent négocier. La même négociation se produit pour le hachage des paquets transférés pendant la notification du client, qui utilise SHA-2.

Certificats

Pour obtenir la liste des certificats d’infrastructure à clé publique (PKI) qui peuvent être utilisés par les Configuration Manager, les exigences ou limitations spéciales et la façon dont les certificats sont utilisés, consultez Exigences relatives aux certificats PKI. Cette liste inclut les algorithmes de hachage et les longueurs de clé pris en charge. La plupart des certificats prennent en charge la longueur de clé SHA-256 et 2048 bits.

La plupart des opérations Configuration Manager qui utilisent des certificats prennent également en charge les certificats v3. Pour plus d’informations, consultez Vue d’ensemble des certificats CNG v3.

Configuration Manager nécessite des certificats PKI pour les scénarios suivants :

• Quand vous gérez Configuration Manager clients sur Internet

• Quand vous utilisez une passerelle de gestion cloud (CMG)

Pour la plupart des autres communications qui nécessitent des certificats pour l’authentification, la signature ou le chiffrement, Configuration Manager utilise automatiquement des certificats PKI si disponibles. S’ils ne sont pas disponibles, Configuration Manager génère des certificats auto-signés.

Gestion des appareils mobiles et certificats PKI

Déploiement de système d’exploitation et certificats PKI

Lorsque vous utilisez Configuration Manager pour déployer des systèmes d’exploitation et qu’un point de gestion nécessite des connexions client HTTPS, le client a besoin d’un certificat pour communiquer avec le point de gestion. Cette exigence est même lorsque le client est dans une phase de transition, comme le démarrage à partir d’un média de séquence de tâches ou d’un point de distribution compatible PXE. Pour prendre en charge ce scénario, créez un certificat d’authentification client PKI et exportez-le avec la clé privée. Ensuite, importez-le dans les propriétés du serveur de site et ajoutez également le certificat d’autorité de certification racine approuvé du point de gestion.

Si vous créez un média de démarrage, vous importez le certificat d’authentification client lorsque vous créez le média de démarrage. Pour protéger la clé privée et les autres données sensibles configurées dans la séquence de tâches, configurez un mot de passe sur le support de démarrage. Chaque ordinateur qui démarre à partir du média de démarrage utilise le même certificat avec le point de gestion que celui requis pour les fonctions clientes telles que la demande de stratégie cliente.

Si vous utilisez PXE, importez le certificat d’authentification client sur le point de distribution compatible PXE. Il utilise le même certificat pour chaque client qui démarre à partir de ce point de distribution compatible PXE. Pour protéger la clé privée et d’autres données sensibles dans les séquences de tâches, vous devez disposer d’un mot de passe pour PXE.

Si l’un de ces certificats d’authentification client est compromis, bloquez les certificats dans le nœud Certificats de l’espace de travail Administration , nœud Sécurité . Pour gérer ces certificats, vous avez besoin de l’autorisation Gérer le certificat de déploiement de système d’exploitation.

Une fois que Configuration Manager a déployé le système d’exploitation a installé le client, le client a besoin de son propre certificat d’authentification client PKI pour la communication du client HTTPS.

Solutions de proxy ISV et certificats PKI

Les éditeurs de logiciels indépendants (ISV) peuvent créer des applications qui étendent Configuration Manager. Par exemple, un éditeur de logiciels indépendant peut créer des extensions pour prendre en charge les plateformes clientes non-Windows. Toutefois, si les systèmes de site nécessitent des connexions client HTTPS, ces clients doivent également utiliser des certificats PKI pour la communication avec le site. Configuration Manager inclut la possibilité d’attribuer un certificat au proxy ISV qui active les communications entre les clients proxy isv et le point de gestion. Si vous utilisez des extensions qui nécessitent des certificats de proxy ISV, consultez la documentation de ce produit.

Si le certificat ISV est compromis, bloquez-le dans le nœud Certificats de l’espace de travail Administration , nœud Sécurité .

Copier le GUID pour le certificat de proxy ISV

À compter de la version 2111, pour simplifier la gestion de ces certificats de proxy ISV, vous pouvez maintenant copier son GUID dans la console Configuration Manager.

1. Dans la console Configuration Manager, accédez à l’espace de travail Administration.

2. Développez Sécurité, puis sélectionnez le nœud Certificats .

3. Triez la liste des certificats en fonction de la colonne Type .

4. Sélectionnez un certificat de type Proxy ISV.

5. Dans le ruban, sélectionnez Copier le GUID du certificat.

Cette action copie le GUID de ce certificat, par exemple : aa05bf38-5cd6-43ea-ac61-ab101f943987

Asset Intelligence et certificats

Depuis novembre 2021, nous avons déprécié Asset Intelligence et nous recommandons aux clients de désinstaller ce rôle.

Services et certificats Azure

La passerelle de gestion cloud (CMG) nécessite des certificats d’authentification serveur. Ces certificats permettent au service de fournir une communication HTTPS aux clients via Internet. Pour plus d’informations, consultez Certificat d’authentification serveur de la passerelle de gestion cloud.

Les clients ont besoin d’un autre type d’authentification pour communiquer avec une passerelle de gestion cloud et le point de gestion local. Ils peuvent utiliser Microsoft Entra ID, un certificat PKI ou un jeton de site. Pour plus d’informations, consultez Configurer l’authentification client pour la passerelle de gestion cloud.

Les clients n’ont pas besoin d’un certificat PKI client pour utiliser le stockage cloud. Une fois qu’ils s’authentifient auprès du point de gestion, le point de gestion émet un jeton d’accès Configuration Manager au client. Le client présente ce jeton à la passerelle de gestion cloud pour accéder au contenu. Le jeton est valide pendant huit heures.

Vérification de la liste de révocation de certificats pour les certificats PKI

Une liste de révocation de certificats PKI augmente la sécurité globale, mais nécessite une surcharge d’administration et de traitement. Si vous activez la vérification de la liste de révocation de certificats, mais que les clients ne peuvent pas y accéder, la connexion PKI échoue.

IIS active la vérification de la liste de révocation de certificats par défaut. Si vous utilisez une liste de révocation de certificats avec votre déploiement pKI, vous n’avez pas besoin de configurer la plupart des systèmes de site qui exécutent IIS. L’exception concerne les mises à jour logicielles, qui nécessitent une étape manuelle pour activer la vérification de la liste de révocation de certificats afin de vérifier les signatures sur les fichiers de mise à jour logicielle.

Lorsqu’un client utilise HTTPS, il active la vérification de la liste de révocation de certificats par défaut.

Les connexions suivantes ne prennent pas en charge l’archivage de la liste de révocation de certificats dans Configuration Manager :

• Connexions de serveur à serveur

Communication du serveur

Configuration Manager utilise les contrôles de chiffrement suivants pour la communication du serveur.

Communication de serveur au sein d’un site

Chaque serveur de système de site utilise un certificat pour transférer des données vers d’autres systèmes de site dans le même Configuration Manager site. Certains rôles de système de site utilisent également des certificats pour l’authentification. Par exemple, si vous installez le point de proxy d’inscription sur un serveur et le point d’inscription sur un autre serveur, ils peuvent s’authentifier mutuellement à l’aide de ce certificat d’identité.

Quand Configuration Manager utilise un certificat pour cette communication, s’il existe un certificat PKI disponible avec la fonctionnalité d’authentification du serveur, Configuration Manager l’utilise automatiquement. Si ce n’est pas le cas, Configuration Manager génère un certificat auto-signé. Ce certificat auto-signé a une fonctionnalité d’authentification serveur, utilise SHA-256 et a une longueur de clé de 2 048 bits. Configuration Manager copie le certificat dans le magasin de Personnes approuvé sur d’autres serveurs de système de site qui peuvent avoir besoin d’approuver le système de site. Les systèmes de site peuvent ensuite se faire confiance en utilisant ces certificats et PeerTrust.

En plus de ce certificat pour chaque serveur de système de site, Configuration Manager génère un certificat auto-signé pour la plupart des rôles de système de site. Lorsqu’il existe plusieurs instance du rôle de système de site dans le même site, ils partagent le même certificat. Par exemple, vous pouvez avoir plusieurs points de gestion dans le même site. Ce certificat auto-signé utilise SHA-256 et a une longueur de clé de 2 048 bits. Il est copié dans le magasin de Personnes approuvé sur les serveurs de système de site qui peuvent avoir besoin de l’approuver. Les rôles de système de site suivants génèrent ce certificat :

• Point de synchronisation Asset Intelligence

• Point Endpoint Protection

• Point de status de secours

• Point de gestion

• Point de distribution compatible avec la multidiffusion

• Point Reporting Services

• Point de mise à jour logicielle

• Point de migration d’état

Configuration Manager génère et gère automatiquement ces certificats.

Pour envoyer des messages status du point de distribution au point de gestion, Configuration Manager utilise un certificat d’authentification client. Lorsque vous configurez le point de gestion pour HTTPS, il nécessite un certificat PKI. Si le point de gestion accepte les connexions E-HTTP, vous pouvez utiliser un certificat PKI. Il peut également utiliser un certificat auto-signé avec la fonctionnalité d’authentification client, utilise SHA-256 et a une longueur de clé de 2 048 bits.

Communication du serveur entre les sites

Configuration Manager transfère des données entre les sites à l’aide de la réplication de base de données et de la réplication basée sur des fichiers. Pour plus d’informations, consultez Transferts de données entre sites et Communications entre points de terminaison.

Configuration Manager configure automatiquement la réplication de base de données entre les sites. S’il est disponible, il utilise des certificats PKI avec la fonctionnalité d’authentification du serveur. S’il n’est pas disponible, Configuration Manager crée des certificats auto-signés pour l’authentification du serveur. Dans les deux cas, il s’authentifie entre les sites à l’aide de certificats dans le magasin de Personnes approuvé qui utilise PeerTrust. Il utilise ce magasin de certificats pour s’assurer que seuls les serveurs SQL Server de la hiérarchie Configuration Manager participent à la réplication de site à site.

Les serveurs de site établissent une communication de site à site à l’aide d’un échange de clés sécurisé qui se produit automatiquement. Le serveur de site d’envoi génère un hachage et le signe avec sa clé privée. Le serveur de site récepteur vérifie la signature à l’aide de la clé publique et compare le hachage à une valeur générée localement. Si elles correspondent, le site de réception accepte les données répliquées. Si les valeurs ne correspondent pas, Configuration Manager rejette les données de réplication.

La réplication de base de données dans Configuration Manager utilise la SQL Server Service Broker pour transférer des données entre les sites. Il utilise les mécanismes suivants :

• SQL Server à SQL Server : cette connexion utilise les informations d’identification Windows pour l’authentification du serveur et les certificats auto-signés avec 1 024 bits pour signer et chiffrer les données avec l’algorithme AES. S’il est disponible, il utilise des certificats PKI avec la fonctionnalité d’authentification du serveur. Il utilise uniquement des certificats dans le magasin de certificats personnel de l’ordinateur.

• SQL Service Broker : ce service utilise des certificats auto-signés avec 2 048 bits pour l’authentification et pour signer et chiffrer les données avec l’algorithme AES. Il utilise uniquement des certificats dans la base de données SQL Server master.

La réplication basée sur des fichiers utilise le protocole SMB (Server Message Block). Il utilise SHA-256 pour signer des données qui ne sont pas chiffrées et ne contiennent pas de données sensibles. Pour chiffrer ces données, utilisez IPsec, que vous implémentez indépendamment de Configuration Manager.

Clients qui utilisent HTTPS

Lorsque les rôles de système de site acceptent des connexions clientes, vous pouvez les configurer pour accepter les connexions HTTPS et HTTP, ou uniquement les connexions HTTPS. Les rôles de système de site qui acceptent les connexions à partir d’Internet acceptent uniquement les connexions clientes via HTTPS.

Les connexions clientes via HTTPS offrent un niveau de sécurité plus élevé en s’intégrant à une infrastructure à clé publique (PKI) pour protéger la communication client-serveur. Toutefois, la configuration des connexions clientES HTTPS sans une compréhension approfondie de la planification, du déploiement et des opérations PKI peut toujours vous laisser vulnérable. Par exemple, si vous ne sécurisez pas votre autorité de certification racine, les attaquants peuvent compromettre la confiance de l’ensemble de votre infrastructure PKI. L’échec du déploiement et de la gestion des certificats PKI à l’aide de processus contrôlés et sécurisés peut entraîner des clients non managés qui ne peuvent pas recevoir de mises à jour ou de packages logiciels critiques.

Communication non chiffrée lorsque les clients utilisent HTTPS

Lorsque les clients communiquent avec les systèmes de site via HTTPS, la plupart du trafic est chiffré. Dans les situations suivantes, les clients communiquent avec les systèmes de site sans utiliser le chiffrement :

• Le client ne parvient pas à établir une connexion HTTPS sur l’intranet et revient à utiliser HTTP lorsque les systèmes de site autorisent cette configuration.

• Communication avec les rôles de système de site suivants :

  • Le client envoie des messages d’état au point de status de secours.

  • Le client envoie des requêtes PXE à un point de distribution compatible PXE.

  • Le client envoie des données de notification à un point de gestion.

Vous configurez les points Reporting Services pour utiliser HTTP ou HTTPS indépendamment du mode de communication client.

Clients qui utilisent E-HTTP

Lorsque les clients utilisent la communication E-HTTP avec des rôles de système de site, ils peuvent utiliser des certificats PKI pour l’authentification client ou des certificats auto-signés générés par Configuration Manager. Quand Configuration Manager génère des certificats auto-signés, ils ont un identificateur d’objet personnalisé pour la signature et le chiffrement. Ces certificats sont utilisés pour identifier le client de manière unique. Ces certificats auto-signés utilisent SHA-256 et ont une longueur de clé de 2 048 bits.

Déploiement du système d’exploitation et certificats auto-signés

Lorsque vous utilisez Configuration Manager pour déployer des systèmes d’exploitation avec des certificats auto-signés, le client doit également disposer d’un certificat pour communiquer avec le point de gestion. Cette condition est requise même si l’ordinateur est dans une phase de transition, comme le démarrage à partir d’un média de séquence de tâches ou d’un point de distribution compatible PXE. Pour prendre en charge ce scénario pour les connexions client e-HTTP, Configuration Manager génère des certificats auto-signés qui ont un identificateur d’objet personnalisé pour la signature et le chiffrement. Ces certificats sont utilisés pour identifier le client de manière unique. Ces certificats auto-signés utilisent SHA-256 et ont une longueur de clé de 2 048 bits. Si ces certificats auto-signés sont compromis, empêchez les attaquants de les utiliser pour emprunter l’identité de clients approuvés. Bloquez les certificats dans le nœud Certificats de l’espace de travail Administration , nœud Sécurité .

Authentification client et serveur

Lorsque les clients se connectent via E-HTTP, ils authentifient les points de gestion à l’aide de services de domaine Active Directory ou à l’aide de l’Configuration Manager clé racine approuvée. Les clients n’authentifient pas les autres rôles de système de site, tels que les points de migration d’état ou les points de mise à jour logicielle.

Lorsqu’un point de gestion authentifie pour la première fois un client à l’aide du certificat client auto-signé, ce mécanisme offre une sécurité minimale, car n’importe quel ordinateur peut générer un certificat auto-signé. Utilisez l’approbation du client pour améliorer ce processus. Approuvez uniquement les ordinateurs approuvés, soit automatiquement par Configuration Manager, soit manuellement par un utilisateur administratif. Pour plus d’informations, consultez Gérer les clients.

À propos des vulnérabilités SSL

Pour améliorer la sécurité de vos Configuration Manager clients et serveurs, effectuez les actions suivantes :

• Activez TLS 1.2 sur tous les appareils et services. Pour activer TLS 1.2 pour Configuration Manager, consultez Comment activer TLS 1.2 pour Configuration Manager.

• Désactivez SSL 3.0, TLS 1.0 et TLS 1.1.

• Réorganisez les suites de chiffrement liées au protocole TLS.

Si vous souhaitez en savoir plus, consultez les articles suivants :

• Limiter l’utilisation de certains algorithmes et protocoles de chiffrement dans Schannel.dll
• Hiérarchisation des suites de chiffrement Schannel

Ces procédures n’affectent pas Configuration Manager fonctionnalité.