Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette section contient des recommandations pour vous aider à sécuriser votre système Enterprise Single Sign-On (SSO).
Avec le système Enterprise Single Sign-On (SSO), les utilisateurs peuvent se connecter à différents systèmes à l’aide d’un seul ensemble d’informations d’identification. Host Integration Server utilise le système d’authentification unique comme magasin pour les informations sensibles. Bien qu’il s’installe automatiquement chaque fois que vous installez le runtime Host Integration Server, vous pouvez également installer Enterprise Single Sign-On en tant que composant autonome, indépendamment de votre environnement Host Integration Server. Nous vous recommandons de suivre ces instructions pour sécuriser et déployer les services et ressources d’authentification unique d’entreprise dans votre environnement.
Recommandations générales de déploiement pour l’authentification unique
Vous devez disposer d’un serveur de temps dans votre environnement pour vous assurer que tous les serveurs d’authentification unique sont synchronisés. Si les horloges des serveurs d’authentification unique ne sont pas synchronisées, cela peut compromettre la sécurité de votre environnement.
Étant donné qu’il n’existe qu’un seul serveur secret principal dans l’ensemble de votre environnement, nous utilisons une configuration de cluster actif-passif pour le serveur secret principal. Pour plus d’informations sur le clustering du serveur secret principal, consultez Comment clusterr le serveur secret principal.
Le serveur secret principal contient la clé de chiffrement utilisée par le système d’authentification unique pour chiffrer les informations dans la base de données sSO. Nous vous recommandons de ne pas installer ni configurer d’autres produits ou services sur cet ordinateur.
Note
L’ordinateur sur lequel vous installez et configurez le serveur secret maître n’a pas besoin d’être un serveur.
Le serveur secret principal doit avoir accès à un support amovible ou à un dossier de système de fichiers NTFS pour sauvegarder et restaurer le secret principal. Si vous utilisez un média amovible, veillez à prendre les mesures appropriées pour protéger le média amovible. Si vous sauvegardez le secret principal dans un système de fichiers NTFS, veillez à protéger le fichier et le dossier. Seul l’administrateur de l’authentification unique doit avoir accès à ce fichier.
Vous devez sauvegarder le secret principal dès que le serveur secret maître le génère. C’est pourquoi vous pouvez récupérer les données dans la base de données sSO en cas d’échec du serveur secret principal. Pour plus d’informations sur la sauvegarde du secret principal, consultez Gestion du secret principal.
Sauvegardez votre secret actuel ou générez régulièrement un nouveau secret, par exemple une fois par mois. Sans le secret, vous ne pouvez pas récupérer les informations de la base de données sSO. Pour plus d’informations sur la sauvegarde et la restauration du secret principal, consultez Gestion du secret principal.
Recommandations de sécurité pour les groupes et comptes d’authentification unique
Nous vous recommandons d’utiliser des groupes Windows et non des comptes d’utilisateur uniques, en particulier pour les groupes d’administrateur d’authentification unique et d’administrateur d’affiliés de l’authentification unique. Ces groupes doivent avoir au moins deux comptes d’utilisateur en tant que membres du groupe à tout moment.
Les comptes de service d’exécution de l’authentification unique et les comptes d’utilisateur d’administrateur SSO doivent être différents, même lorsqu’ils sont membres du même groupe Administrateurs d’authentification unique. Les utilisateurs de l’administrateur de l’authentification unique qui effectuent des tâches d’administration telles que la génération et la sauvegarde du secret doivent être des administrateurs Windows, tandis que les comptes de service d’exécution de l’authentification unique n’ont pas besoin d’être administrateurs Windows.
Important
Les droits utilisateur de l’administrateur Windows ne remplacent pas les droits utilisateur de l’administrateur de l’authentification unique. Pour effectuer une tâche au niveau de l’administration de l’authentification unique, vous devez être membre du groupe Administrateurs de l’authentification unique, même si vous êtes déjà administrateur Windows.
Si vous utilisez la fonctionnalité de ticket d’authentification unique, vous devez utiliser des comptes de domaine que les ordinateurs du domaine de traitement (domaine où les serveurs d’authentification unique sont) reconnaissent.
Nous vous recommandons d’utiliser un compte de service unique pour le service d’authentification unique correspondant au serveur secret principal.
Le compte Administrateur de l’authentification unique est un compte hautement privilégié dans le système d’authentification unique, qui est également le compte d’administrateur SQL Server pour le serveur SQL qui a la base de données sSO. Vous devez disposer de comptes dédiés pour les administrateurs de l’authentification unique et ne doit pas utiliser ces comptes à d’autres fins. Vous devez limiter l’appartenance au groupe Administrateurs de l’authentification unique uniquement aux comptes responsables de l’exécution et de la maintenance du système d’authentification unique.
Recommandations de sécurité pour un déploiement d’authentification unique
Si votre réseau prend en charge l’authentification Kerberos, vous devez inscrire tous les serveurs d’authentification unique. Lorsque vous utilisez l’authentification Kerberos entre le serveur secret principal et la base de données SSO, vous devez configurer les noms de principal de service (SPN) sur le serveur SQL où se trouve la base de données SSO.
Lorsque vous exécutez Windows Server 2003, si le serveur secret maître se trouve sur un domaine différent des autres serveurs d’authentification unique et de la base de données sSO, vous devez désactiver la sécurité RPC (utilisée pour l’authentification DTC (Data Transaction Coordinator) entre les ordinateurs) sur le serveur secret principal, sur les serveurs SSO (traitement des ordinateurs du domaine de traitement), et sur la base de données de l’authentification unique. La sécurité RPC est une nouvelle fonctionnalité DTC dans Windows Server 2003. Lorsque vous désactivez la sécurité RPC, le niveau de sécurité de l’authentification DTC pour les appels RPC est rétabli à celui disponible dans Microsoft Windows. Pour plus d’informations sur la désactivation de la sécurité RPC, consultez Aide et support Microsoft.
Les administrateurs d’authentification unique doivent surveiller régulièrement le journal des événements dans le serveur secret principal et le serveur d’authentification unique pour les événements d’audit de l’authentification unique.
En plus des pare-feu, nous vous recommandons d’utiliser la sécurité IPsec (Internet Protocol Security) ou SSL (Secure Sockets Layer) entre tous les serveurs d’authentification unique et la base de données SSO. Pour plus d’informations sur SSL, consultez l’aide et le support Microsoft.
Réseau de périmètre
Lors de l’exécution d’Internet Information Services (IIS) et de l’authentification unique Entreprise, suivez les recommandations suivantes :
Si IIS se trouve dans un réseau de périmètre (également appelé sous-réseau filtré), fournissez un autre serveur exécutant IIS derrière le pare-feu pour se connecter au système d’authentification unique.
N’ouvrez pas le port d’appels de procédure distante (RPC) sur IIS.
Accès SQL Server
Tous les serveurs d’authentification unique accèdent à la base de données d’informations d’identification SQL Server.
Microsoft vous recommande d’utiliser SSL (Secure Sockets Layer) et/ou la sécurité du protocole Internet (IPsec) pour sécuriser la transmission des données entre les serveurs d’authentification unique et la base de données d’informations d’identification. Pour plus d’informations sur l’utilisation de SSL, consultez l’aide et le support Microsoft.
Pour activer SSL uniquement pour la connexion entre le serveur d’authentification unique et la base de données d’informations d’identification, vous pouvez définir la prise en charge SSL sur chaque serveur d’authentification unique à l’aide de l’utilitaire ssoconfig. Cette option permet à l’authentification unique d’utiliser toujours SSL lors de l’accès à la base de données d’informations d’identification. Pour plus d’informations, consultez Comment activer SSL pour l’authentification unique Entreprise.
Mots de passe forts
Il est très important d’utiliser des mots de passe forts pour tous les comptes, en particulier les comptes membres du groupe Administrateurs de l’authentification unique, car ces utilisateurs ont le contrôle sur l’ensemble du système d’authentification unique.
Comptes d’administrateur SSO
Nous vous recommandons d’utiliser différents comptes de service pour les services d’authentification unique s’exécutant sur différents ordinateurs. Vous ne devez pas utiliser le compte d’administrateur de l’authentification unique qui effectue des opérations d’administration telles que la génération et la sauvegarde du secret pour le service d’authentification unique. Bien que les comptes de service d’authentification unique ne doivent pas être des administrateurs locaux sur cet ordinateur, l’administrateur de l’authentification unique qui effectue des opérations d’administration doit être un administrateur local sur l’ordinateur pour certaines opérations.
Serveur secret principal
Nous vous recommandons vivement de sécuriser et de verrouiller le serveur secret principal. Vous ne devez pas utiliser ce serveur comme serveur de traitement. Le seul objectif de ce serveur doit être de contenir le secret principal. Vous devez garantir la sécurité physique de cet ordinateur et seuls les administrateurs de l’authentification unique doivent avoir accès à cet ordinateur.
Kerberos
L’authentification unique prend en charge Kerberos et nous vous recommandons de configurer Kerberos pour l’authentification unique. Pour configurer Kerberos avec l’authentification unique, vous devez inscrire un nom de principal sécurisé (SPN) pour le service d’authentification unique. Par défaut, lorsque vous configurez Kerberos, l’authentification unique utilise ce spN pour authentifier les composants à l’aide du service d’authentification unique. Nous vous recommandons de configurer l’authentification Kerberos entre les sous-services d’administration de l’authentification unique et le serveur d’authentification unique. Vous pouvez également utiliser l’authentification Kerberos entre les serveurs d’authentification unique et entre les serveurs sSO et SQL Server où se trouve la base de données d’informations d’identification.
Pour configurer et vérifier Kerberos, vous utilisez les utilitaires setspn et kerbtray.
Délégation
Lorsque vous utilisez Windows Server 2003, vous pouvez utiliser la délégation contrainte, mais nous vous recommandons de ne pas utiliser la délégation pour effectuer les tâches de l’administrateur de Sign-On unique. De même, nous vous recommandons de ne pas déléguer de tâches supplémentaires ni de droits utilisateur à l’administrateur de Sign-On unique.
Auditing
L’audit est un mécanisme essentiel pour le suivi des informations dans votre environnement. Enterprise Single Sign-On (SSO) audite toutes les opérations effectuées dans la base de données d’informations d’identification. L’authentification unique utilise les journaux des événements et les journaux d’audit de la base de données elle-même. L’authentification unique fournit deux niveaux d’audit pour les serveurs single Sign-On :
Les niveaux d’audit positifs auditent les opérations réussies.
Les niveaux d’audit négatifs vérifient les opérations qui échouent.
Les administrateurs de l’authentification unique peuvent définir les niveaux d’audit positifs et négatifs qui correspondent à leurs stratégies d’entreprise.
Vous pouvez définir des audits positifs et négatifs sur l’un des niveaux suivants :
0 = Aucun - Ce niveau ne émet aucun message d’audit.
1 = Faible
2 = Moyen
3 = Élevé : ce niveau émet autant de messages d’audit que possible.
La valeur par défaut de l’audit positif est 0 (aucun), et la valeur par défaut de l’audit négatif est 1(faible). Vous pouvez modifier ces valeurs en fonction du niveau d’audit souhaité pour votre système d’authentification unique.
Important
L'audit d'authentification unique d'entreprise émet des messages générés par le service Single Sign-On. Il ne s’agit pas d’un audit de sécurité et le système d’authentification unique n’enregistre pas les informations dans le journal de sécurité du journal des événements. Le système d’authentification unique enregistre les messages d’audit de l’authentification unique directement dans le journal des événements de l’application.
Audit au niveau de la base de données
Pour l’audit au niveau de la base de données, le système d’authentification unique effectue le suivi des opérations effectuées sur la base de données d’informations d’identification dans les tables d’audit de la base de données. La taille de ces tables d’audit est définie au niveau du système d’authentification unique. Vous pouvez auditer les applications affiliées supprimées, les mappages supprimés et les recherches d’informations d’identification effectuées. Par défaut, la taille d’audit est définie sur 1 000 entrées. Les administrateurs d’authentification unique peuvent modifier cette taille pour répondre à leurs stratégies d’entreprise.
Utilisation de comptes d'Sign-On uniques d’entreprise
Cette section contient les meilleures pratiques lorsque vous utilisez des groupes de domaine et des groupes locaux et des comptes individuels dans le système Enterprise Single Sign-On (SSO).
Groupes et comptes Windows de domaine
Lorsque vous travaillez avec des groupes Windows de domaine, les recommandations suivantes s’appliquent :
Utilisez des groupes de domaines et des comptes de domaine.
Utilisez un groupe de domaines pour les administrateurs d’authentification unique. Vous ne devez pas spécifier de compte de domaine individuel en tant qu’administrateur de l’authentification unique, car vous ne pouvez pas modifier ce compte d’un compte individuel à un autre compte individuel.
Bien que vous puissiez spécifier un compte de domaine individuel en tant qu’administrateur affilié à l’authentification unique, vous devez utiliser un groupe de domaines.
Bien que vous puissiez spécifier un compte de domaine individuel en tant qu’administrateur d’application, vous devez utiliser un groupe de domaines.
Vous devez utiliser des groupes de domaine pour le compte d’utilisateurs d’application. Le compte d’utilisateurs des applications SSO ne prend pas en charge un compte individuel.
Voir aussi
Comment auditer l’authentification unique d'entreprise
Mise à jour de la base de données d’informations d’identification