Partager via

Recommandations de sécurité pour l’authentification unique

  • Article

Cette section contient des recommandations sur la façon de sécuriser votre système d'Sign-On unique (SSO) d’entreprise.

Grâce au système d'authentification unique de l'entreprise (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 d’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 pour le déploiement de SSO

  • Vous devez avoir un serveur de temps dans votre environnement pour assurer la synchronisation de tous les serveurs SSO. 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 master dans l’ensemble de votre environnement, nous utilisons une configuration de cluster actif/passif pour le serveur secret master. Pour plus d’informations sur clustering le serveur secret master, consultez How to Cluster the Master Secret Server.

  • Le serveur secret master contient la clé de chiffrement que le système de l’authentification unique utilise pour chiffrer les informations de la base de données de l’authentification unique. Nous vous recommandons de ne pas installer ou configurer d’autres produits ou services sur cet ordinateur.

    Notes

    L'ordinateur sur lequel vous installez et configurez le serveur de secret principal ne doit pas être un serveur.

  • Le serveur de secret principal doit avoir accès à un support amovible ou un dossier de système de fichiers NTFS afin de 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 master dans un système de fichiers NTFS, veillez à protéger le fichier et le dossier. Seul l'administrateur SSO doit avoir accès à ce fichier.

  • Vous devez sauvegarder le secret principal dès sa génération par le serveur de secret principal. Cela vous permet de récupérer les données de la base de données de l’authentification unique en cas de défaillance du serveur secret master. Pour plus d’informations sur la sauvegarde du secret master, consultez Gestion du secret principal.

  • Sauvegardez votre secret actuel ou générez un nouveau secret régulièrement, 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 master, consultez Gestion du secret principal.

Recommandations de sécurité pour les groupes et comptes SSO

  • Nous vous recommandons d’utiliser des groupes Windows, et non des comptes d’utilisateurs uniques, en particulier pour les groupes Administrateur SSO et Administrateur affilié à l’authentification unique. Ces groupes doivent toujours avoir au moins deux comptes utilisateur comme membres du groupe.

  • Les comptes de service d'exécution SSO et les comptes utilisateur administrateurs SSO doivent être des comptes différents, même s'ils sont membres du même groupe Administrateurs SSO. Les utilisateurs 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 runtime de l’authentification unique n’ont pas besoin d’être des administrateurs Windows.

    Important

    Les droits administratifs Windows ne remplacent pas les droits d'utilisateur de l'administrateur SSO. 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 fonction de création de tickets d'authentification unique, vous devez utiliser des comptes de domaine reconnus par les ordinateurs dans le domaine de traitement (domaine où se trouvent les serveurs SSO).

  • Nous vous recommandons d’utiliser un compte de service unique pour le service d’authentification unique correspondant au serveur secret master.

  • Le compte Administrateur de l’authentification unique est un compte à privilèges élevés dans le système de l’authentification unique, qui est également le compte d’administrateur SQL Server pour le serveur SQL qui a la base de données de l’authentification unique. Vous devez avoir des comptes dédiés pour les administrateurs SSO et ne devez pas utiliser ces comptes pour un autre but. 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 SSO

  • Si votre réseau prend en charge l'authentification Kerberos, vous devez inscrire tous les serveurs SSO. Lorsque vous utilisez l’authentification Kerberos entre le serveur secret master 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 d’authentification unique.

  • Lorsque vous exécutez Windows Server 2003, si le serveur secret master 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 (telle qu’elle est utilisée pour l’authentification DTC (Data Transaction Coordinator) entre ordinateurs) sur le serveur secret master, sur les serveurs SSO (qui traitent les 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é d’authentification DTC pour les appels RPC revient à un niveau disponible dans Microsoft Windows. Pour plus d’informations sur la désactivation de la sécurité RPC, consultez Aide et support Microsoft.

  • Les administrateurs SSO doivent régulièrement surveiller le journal des événements dans le serveur de secret principal et le serveur SSO pour des audits SSO.

  • Outre les pare-feu, nous vous recommandons d’utiliser la sécurité du protocole Internet (IPsec) 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 Aide et support Microsoft.

Réseau de périmètre

Lorsque vous exécutez les services Internet (IIS) et l'authentification unique de l'entreprise, suivez ces recommandations :

  • 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 RPC (appel de procédure distante) 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 sSO et la base de données d’informations d’identification. Pour plus d’informations sur l’utilisation de SSL, consultez Aide et support Microsoft.

Pour activer SSL uniquement pour la connexion entre le serveur SSO et la base de données d’informations d’identification, vous pouvez définir la prise en charge SSL sur chaque serveur SSO à l’aide de l’utilitaire ssoconfig. Cette option permet à l’authentification unique de toujours utiliser SSL lors de l’accès à la base de données d’informations d’identification. Pour plus d’informations, consultez How to Enable SSL for Enterprise Single Sign-On.

Mots de passe forts

Il est très important d'utiliser des mots de passe forts pour tous les comptes, notamment les comptes qui sont membres du groupe Administrateurs SSO car ces utilisateurs contrôlent tout le système SSO.

Comptes administrateur SSO

Nous vous recommandons d’utiliser différents comptes de service pour les services d’authentification unique exécutés sur différents ordinateurs. Vous ne devez pas utiliser le compte administrateur SSO qui réalise des opérations administratives, telles que la génération et la sauvegarde du secret pour le service SSO. Bien que les comptes de service d’authentification unique ne doivent pas être des administrateurs locaux sur cet ordinateur, l’administrateur SSO qui effectue des opérations d’administration doit être un administrateur local sur l’ordinateur pour certaines opérations.

Serveur de secret principal

Nous vous recommandons vivement de sécuriser et de verrouiller le serveur secret master. Vous ne devez pas utiliser ce serveur comme serveur de traitement. Le seul objectif de ce serveur doit être de conserver le secret principal. Vous devez garantir la sécurité physique de cet ordinateur et seuls les administrateurs SSO doivent y accéder.

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 enregistrer un nom principal de service (SPN) sur le service SSO. 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 SSO et entre les serveurs SSO et le 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.

La 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 ou de droits utilisateur supplémentaires à l’administrateur de Sign-On unique.

Audit

L'audit est un mécanisme essentiel de 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. SSO utilise les journaux des événements et les journaux d'audit de la base de données elle-même. SSO fournit deux niveaux d'audit pour les serveurs d'authentification unique :

  • Les niveaux d’audit positifs auditent les opérations réussies.

  • Les niveaux d’audit négatifs auditent les opérations qui échouent.

    Les administrateurs SSO peuvent définir les niveaux d'audit positifs et négatifs selon 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 génère 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 pour l’audit positif est 0 (aucun) et la valeur par défaut pour l’audit négatif est 1 (faible). Vous pouvez modifier ces valeurs selon le niveau d'audit souhaité pour votre système SSO.

Important

L’audit Sign-On unique d’entreprise émet des messages générés par le service de Sign-On unique. Il ne s’agit pas d’un audit de sécurité, et le système SSO n’enregistre pas les informations dans le journal de sécurité du journal des événements. Le système SSO enregistre les messages d'audit SSO 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 suit les opérations effectuées sur la base de données Credential 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 de l’authentification unique. Vous pouvez auditer les applications associé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 SSO peuvent modifier cette taille selon leurs stratégies d'entreprise.

Utilisation de comptes de Sign-On unique d’entreprise

Cette section contient les meilleures pratiques lorsque vous utilisez des groupes de domaine et locaux, ainsi que des comptes individuels dans le système Enterprise Single Sign-On (SSO).

Groupes et comptes Windows de domaine

Lorsque vous utilisez des groupes Windows de domaine, les recommandations suivantes s’appliquent :

  • Utilisez des groupes de domaine et des comptes de domaine.

  • Utilisez un groupe de domaine pour les administrateurs SSO. Vous ne devez pas spécifier un compte de domaine individuel comme administrateur SSO car vous ne pouvez pas modifier ce compte d'un compte individuel en un autre compte individuel.

  • Bien que vous puissiez spécifier un compte de domaine individuel comme administrateur d'applications associées à SSO, vous devez utiliser un groupe de domaine.

  • Bien que vous puissiez spécifier un compte de domaine individuel comme administrateur de l'application, vous devez utiliser un groupe de domaine.

  • Vous devez utiliser des groupes de domaines pour le compte d’utilisateurs de l’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