Les appareils iOS tels que les iPads et les iPhones font rapidement partie du paysage informatique des entreprises, dans le cadre d'une tendance parfois appelée "consumérisation de l'informatique". Du point de vue des spécialistes de la sécurité, un certain nombre de facteurs sont préoccupants, notamment la perspective que des appareils non gérés ou "sous-gérés" accèdent aux données de l'entreprise, la variété des appareils et des facteurs de forme concernés, et le rythme rapide de l'adoption, pour n'en citer que quelques-uns.
L'infrastructure à clé publique d'entreprise (PKI) et les certificats numériques peuvent aider. Les iPhones et les iPads sont nativement capables d'utiliser des certificats numériques pour l'authentification des réseaux et des données de l'entreprise de diverses manières :
- Réseaux sans fil d'entreprise (802.1X et EAP-TLS)
- Passerelles VPN via le client Cisco intégré
- Microsoft ActiveSync
- Sites web SSL mutuellement authentifiés via le navigateur Safari
Chacun de ces éléments permet à une organisation de restreindre l'accès aux ressources susmentionnées à SEULEMENT les appareils qui ont reçu un certificat de l'entreprise PKI. Ceci, combiné à des contrôles robustes entourant l'émission de certificats, et à des paramètres de politique organisationnelle tels que les codes de passe et les capacités d'effacement à distance (par exemple via ActiveSync), peut commencer à apporter un certain contrôle à la situation, et ce de manière relativement évolutive. En outre, l'utilisation de certificats peut atténuer la nécessité pour chaque application iOS de collecter et de stocker le nom d'utilisateur et le mot de passe de l'utilisateur, ce qui est également une bonne chose.
Comme pour toute application compatible avec le site PKI, une mise en œuvre correcte nécessite une planification minutieuse du cycle de vie des certificats. Il y a souvent plus d'aspects, mais toute planification de certificat devrait inclure des domaines tels que :
- Délivrance: Quels sont les utilisateurs et/ou les dispositifs qui ont besoin de certificats et quel est le processus pour les obtenir ?
- Renouvellement: Tous les certificats expirent, généralement au bout d'un à deux ans. La mise en place d'un processus bien défini de gestion des renouvellements peut permettre d'éviter d'énormes maux de tête à l'avenir. La planification doit indiquer qui est responsable de l'identification des certificats sur le point d'expirer et de la procédure à suivre pour les renouveler.
- Révocation: En cas de perte d'un dispositif ou de suspicion de compromission de la clé privée d'un certificat, les certificats doivent être révoqués pour éviter qu'ils ne continuent à être des références valables pour l'entreprise.
- Remplacement: Si un certificat est accidentellement supprimé ou perdu, il doit être soit récupéré (dans le cas des certificats de cryptage), soit remplacé purement et simplement. Souvent, les efforts déployés ici peuvent imiter ceux utilisés pour l'émission ou le renouvellement.
Lorsqu'il s'agit d'émettre des certificats pour les iPhones ou les iPads, il existe deux options générales :
- Créez un fichier PKCS#12 (.pfx) contenant le certificat et la clé privée. Ce fichier peut être installé sur l'appareil en pointant le navigateur Safari vers un serveur web contenant le fichier, ou en incluant le fichier .pfx dans un profil iOS.
- Configurez l'appareil pour qu'il s'inscrive à un certificat via SCEP (Simple Certificate Enrollment Protocol) dans un profil iOS (fichier .mobileconfig). Les autorités de certification Microsoft incluent nativement la prise en charge de SCEP en tant que rôle supplémentaire sur les systèmes d'exploitation Windows Server 2008 et Server 2008 R2.
Les deux approches posent toutefois certains problèmes. CSS considère que les fichiers .pfx sont intrinsèquement un peu dangereux : étant des fichiers, ils sont assez mobiles et il peut être difficile de contrôler où ils vont. En outre, ils sont susceptibles d'être devinés par un mot de passe hors ligne et, une fois le mot de passe deviné, la clé est compromise. Enfin, la "non-répudiation" de PKI est affaiblie : étant donné que la clé est créée de manière centralisée, il est difficile d'attester avec une certitude de 100 % que seul le porteur du certificat a eu accès à la clé privée.
L'enrôlement basé sur SCEP est certainement une meilleure option du point de vue de la sécurité, car la clé privée est générée sur l'appareil et n'est pas exportable. Le principal problème ici est un problème d'échelle: le profil iOS place le contenu du certificat tel que le sujet (Distinguished Name), et le mot de passe "challenge" SCEP à usage unique dans les informations de configuration. Les profils .mobileconfig ne peuvent donc pas être partagés entre les appareils - chacun a besoin du sien. Il est possible de modifier les paramètres du mot de passe de défi afin que les défis puissent être réutilisés, mais il convient de noter qu'il s'agit d'une terrible la façon dont SCEP fonctionne, les informations d'identification Active Directory ne sont pas impliquées, de sorte que le défi est vraiment le seul facteur utilisé pour authentifier la demande de certificat. facteur utilisé pour authentifier la demande de certificat.
Enfin, quelle que soit la méthode d'émission utilisée, les certificats expireront, et iOS ne fait actuellement rien pour gérer cela automatiquement. Ainsi, comme mentionné ci-dessus, une sorte de processus devra être mis en place pour gérer l'expiration imminente des certificats.
À venir demain : Utilisation de l'outil de rapport sur les certificats de CSS pour faciliter la gestion des certificats pour les iPads et les iPhones.
