Notes
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 rubrique fournit des informations recommandées pour vous aider à planifier et à évaluer la sécurité lorsque vous concevez votre déploiement des services de fédération Active Directory (AD FS). Cette rubrique est un point de départ pour examiner et évaluer les considérations qui affectent la sécurité globale de votre utilisation d’AD FS. Les informations contenues dans cette rubrique sont destinées à compléter et à étendre votre planification de la sécurité existante et d’autres meilleures pratiques de conception.
Meilleures pratiques de sécurité de base pour AD FS
Les meilleures pratiques principales suivantes sont communes à toutes les installations AD FS où vous souhaitez améliorer ou étendre la sécurité de votre conception ou déploiement :
Sécuriser AD FS en tant que système « Niveau 0 »
Étant donné que AD FS est fondamentalement un système d’authentification, il doit être traité comme un système de « niveau 0 » comme d’autres systèmes d’identité sur votre réseau. Pour plus d’informations, consultez le modèle de niveau administratif Active Directory.
Utilisez l’Assistant Configuration de la sécurité pour appliquer les meilleures pratiques de sécurité propres à AD FS aux serveurs de fédération et aux ordinateurs proxy de serveur de fédération
L’Assistant Configuration de la sécurité (SCW) est un outil préinstallé sur tous les ordinateurs Windows Server 2008, Windows Server 2008 R2 et Windows Server 2012. Vous pouvez l’utiliser pour appliquer les meilleures pratiques de sécurité qui peuvent aider à réduire la surface d’attaque d’un serveur, en fonction des rôles de serveur que vous installez.
Lorsque vous installez AD FS, le programme d’installation crée des fichiers d’extension de rôle que vous pouvez utiliser avec le scW pour créer une stratégie de sécurité qui s’applique au rôle serveur AD FS spécifique (serveur de fédération ou proxy de serveur de fédération) que vous choisissez lors de l’installation.
Chaque fichier d’extension de rôle installé représente le type de rôle et de sous-rôle pour lequel chaque ordinateur est configuré. Les fichiers d’extension de rôle suivants sont installés dans le répertoire C :WindowsADFSScw :
Farm.xml
SQLFarm.xml
StandAlone.xml
Proxy.xml (ce fichier est présent uniquement si vous avez configuré l’ordinateur dans le rôle proxy du serveur de fédération.)
Pour appliquer les extensions de rôle AD FS dans le SCW, effectuez les étapes suivantes dans l’ordre :
Installez AD FS et choisissez le rôle serveur approprié pour cet ordinateur. Pour plus d’informations, consultez Installer le service de rôle proxy du service de fédération dans le Guide de déploiement AD FS.
Inscrivez le fichier d’extension de rôle approprié à l’aide de l’outil en ligne de commande Scwcmd. Consultez le tableau suivant pour plus d’informations sur l’utilisation de cet outil dans le rôle pour lequel votre ordinateur est configuré.
Vérifiez que la commande s’est terminée correctement en examinant le fichier SCWRegister_log.xml, qui se trouve dans le répertoire WindowssecurityMsscwLogs.
Vous devez effectuer toutes ces étapes sur chaque serveur de fédération ou ordinateur proxy de serveur de fédération auquel vous souhaitez appliquer des stratégies de sécurité SCW basées sur AD FS.
Le tableau suivant explique comment inscrire l’extension de rôle SCW appropriée, en fonction du rôle serveur AD FS que vous avez choisi sur l’ordinateur sur lequel vous avez installé AD FS.
Rôle serveur AD FS Base de données de configuration AD FS utilisée Tapez la commande suivante depuis une invite de commandes : Serveur de fédération autonome Base de données interne Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwStandAlone.xml"Serveur de fédération appartenant à une batterie Base de données interne Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwFarm.xml"Serveur de fédération appartenant à une batterie Serveur SQL scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwSQLFarm.xml"Serveur proxy de fédération N/A scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwProxy.xml"Pour plus d’informations sur les bases de données que vous pouvez utiliser avec AD FS, consultez Le rôle de la base de données de configuration AD FS.
Utilisez la détection de relecture de jeton dans les situations où la sécurité est un problème très important, par exemple, lorsque des kiosques sont utilisés. La fonctionnalité de détection de rejouement de jeton d'AD FS assure que toute tentative de rejouement d'une demande de jeton adressée au service de fédération est détectée et que la demande est rejetée. La détection des relectures de jetons est activée par défaut. Il fonctionne à la fois pour le profil passif WS-Federation et le profil WebSSO SAML (Security Assertion Markup Language) en veillant à ce que le même jeton ne soit jamais utilisé plus d'une fois.
Quand le service de fédération démarre, il commence par créer un cache de toutes les demandes de jeton qu'il traite. Au fil du temps, à mesure que les demandes de jeton ultérieures sont ajoutées au cache, la capacité de détecter toute tentative de répéter une demande de jeton augmente pour le service de fédération. Si vous désactivez la détection de relecture de jeton et que vous choisissez ultérieurement de l’activer à nouveau, n’oubliez pas que le service de fédération accepte toujours les jetons pendant une période de temps qui peut avoir été utilisée précédemment, jusqu’à ce que le cache de relecture ait été autorisé à reconstruire son contenu. Pour plus d’informations, consultez l’article The Role of the AD FS Configuration Database (Rôle de la base de données de configuration AD FS).
Utilisez le chiffrement de jetons, notamment si vous prenez en charge la résolution d'artefacts SAML.
Le chiffrement de jetons est vivement conseillé pour accroître la sécurité et la protection contre les attaques de l’intercepteur susceptibles de viser votre déploiement d’AD FS. L'utilisation du chiffrement peut avoir un léger impact sur le débit, mais en général, cela ne devrait généralement pas être remarqué et, dans de nombreux déploiements, les avantages d'une sécurité accrue surpassent les éventuels coûts en termes de performances du serveur.
Pour activer le chiffrement de jetons, définissez d'abord un certificat de chiffrement pour vos approbations de partie de confiance. Vous pouvez configurer un certificat de chiffrement lors de la création d’une relation de confiance ou plus tard. Pour ajouter un certificat de chiffrement ultérieurement à une relation de confiance existante, vous pouvez définir un certificat à utiliser sous l’onglet Chiffrement dans les propriétés d’approbation lors de l’utilisation du composant logiciel enfichable AD FS. Pour spécifier un certificat pour une approbation existante à l’aide des applets de commande AD FS, utilisez le paramètre EncryptionCertificate des applets de commande Set-ClaimsProviderTrust ou Set-RelyingPartyTrust . Pour définir un certificat pour le service de fédération à utiliser lors du déchiffrement des jetons, utilisez l’applet de commande Set-ADFSCertificate et spécifiez «
Token-Encryption» pour le paramètre CertificateType . L’activation et la désactivation du chiffrement pour un partenaire de confiance spécifique s'effectue à l’aide du paramètre EncryptClaims de l’applet de commande Set-RelyingPartyTrust.Utiliser la protection étendue pour l’authentification
Pour sécuriser vos déploiements, vous pouvez définir et utiliser la protection étendue pour la fonctionnalité d’authentification avec AD FS. Ce paramètre spécifie le niveau de protection étendue pour l’authentification prise en charge par un serveur de fédération.
La protection étendue pour l’authentification permet de se protéger contre les attaques mitm (man-in-the-middle), dans lesquelles un attaquant intercepte les informations d’identification du client et les transfère à un serveur. La protection contre ces attaques est rendue possible via un jeton de liaison de canal (CBT) qui peut être requis, autorisé ou non requis par le serveur lorsqu’il établit des communications avec des clients.
Pour activer la fonctionnalité de protection étendue, utilisez le paramètre ExtendedProtectionTokenCheck sur l’applet de commande Set-ADFSProperties . Les valeurs possibles pour ce paramètre et le niveau de sécurité que les valeurs fournissent sont décrites dans le tableau suivant.
Valeur du paramètre Niveau de sécurité Paramètre de protection Require (Rendre obligatoire) Le serveur est entièrement renforcé. La protection étendue est appliquée et toujours requise. Permettre Le serveur est partiellement sécurisé. La protection étendue est appliquée lorsque les systèmes impliqués ont été corrigés pour le prendre en charge. Aucun Le serveur est vulnérable. La protection étendue n’est pas appliquée. Si vous utilisez la journalisation et le suivi, assurez-vous de la confidentialité des informations sensibles.
AD FS ne fait pas, par défaut, exposer ou suivre les informations d’identification personnelle (PII) directement dans le cadre du service de fédération ou des opérations normales. Lorsque la journalisation des événements et la journalisation des traces de débogage sont activées dans AD FS, toutefois, selon la stratégie de revendications que vous configurez certains types de revendications et leurs valeurs associées peuvent contenir des informations d’identification personnelles susceptibles d’être consignées dans l’événement AD FS ou les journaux de suivi.
Par conséquent, l’application du contrôle d’accès sur la configuration AD FS et ses fichiers journaux est fortement recommandée. Si vous ne souhaitez pas que ce type d’informations soit visible, vous devez désactiver la connexion ou filtrer les informations personnelles ou sensibles dans vos journaux avant de les partager avec d’autres personnes.
Les conseils suivants peuvent vous aider à empêcher l’exposition involontaire du contenu d’un fichier journal :
Vérifiez que le journal des événements AD FS et les fichiers journaux de suivi sont protégés par des listes de contrôle d’accès (ACL) qui limitent l’accès aux seuls administrateurs approuvés qui ont besoin d’y accéder.
Ne copiez pas ou archivez les fichiers journaux à l’aide d’extensions de fichier ou de chemins d’accès qui peuvent être facilement servis à l’aide d’une requête Web. Par exemple, l’extension de nom de fichier .xml n’est pas un choix sûr. Vous pouvez consulter le guide d’administration iis (Internet Information Services) pour afficher la liste des extensions qui peuvent être traitées.
Si vous modifiez le chemin d’accès au fichier journal, veillez à spécifier un chemin absolu pour l’emplacement du fichier journal, qui doit être en dehors du répertoire public de la racine virtuelle de l’hôte web (vroot) pour empêcher son accès par un tiers externe à l’aide d’un navigateur Web.
Verrouillage logiciel de l’extranet AD FS et protection intelligente contre le verrouillage de l’extranet AD FS :
En cas d’attaque sous la forme de demandes d’authentification avec des mots de passe non valides (incorrects) qui transitent par le proxy d’application web, le verrouillage extranet AD FS vous permet de protéger vos utilisateurs contre un verrouillage de compte AD FS. Outre la protection de vos utilisateurs contre un verrouillage de compte AD FS, le verrouillage extranet AD FS protège également contre les attaques devinage de mot de passe par force brute.
Pour le verrouillage progressif de l'extranet pour AD FS sur Windows Server 2012 R2, consultez Protection contre le verrouillage progressif pour l’extranet d’AD FS.
Pour le verrouillage extranet intelligent pour AD FS sur Windows Server 2016, consultez la protection de verrouillage extranet intelligent AD FS.
Bonnes pratiques de sécurité propres à SQL Server pour AD FS
Les meilleures pratiques de sécurité suivantes sont spécifiques à l’utilisation de Microsoft SQL Server® ou d’une base de données interne Windows (WID) lorsque ces technologies de base de données sont utilisées pour gérer les données dans la conception et le déploiement AD FS.
Remarque
Ces recommandations sont destinées à étendre, mais pas à remplacer, les conseils de sécurité des produits SQL Server. Pour plus d’informations sur la planification d’une installation sécurisée de SQL Server, consultez Considérations relatives à la sécurité pour une installation SQL sécurisée (https://go.microsoft.com/fwlink/?LinkID=139831).
Déployez toujours SQL Server derrière un pare-feu dans un environnement réseau physiquement sécurisé.
Une installation de SQL Server ne doit jamais être exposée directement à Internet. Seuls les ordinateurs qui se trouvent à l’intérieur de votre centre de données doivent être en mesure d’atteindre l’installation de votre serveur SQL qui prend en charge AD FS. Pour plus d’informations, consultez liste de vérification des meilleures pratiques de sécurité (https://go.microsoft.com/fwlink/?LinkID=189229).
Exécutez SQL Server sous un compte de service au lieu d’utiliser les comptes de service système intégrés.
Par défaut, SQL Server est souvent installé et configuré pour utiliser l’un des comptes système intégrés pris en charge, tels que les comptes LocalSystem ou NetworkService. Pour améliorer la sécurité de votre installation de SQL Server pour AD FS, dans la mesure du possible, utilisez un compte de service distinct pour accéder à votre service SQL Server et activez l’authentification Kerberos en inscrivant le nom de principal de sécurité (SPN) de ce compte dans votre déploiement Active Directory. Cela permet l’authentification mutuelle entre le client et le serveur. Sans inscription SPN d’un compte de service distinct, SQL Server utilise NTLM pour l’authentification Windows, où seul le client est authentifié.
Réduisez la surface d’exposition de SQL Server.
Activez uniquement les points de terminaison SQL Server nécessaires. Par défaut, SQL Server fournit un point de terminaison TCP intégré unique qui ne peut pas être supprimé. Pour AD FS, vous devez activer ce point de terminaison TCP pour l’authentification Kerberos. Pour passer en revue les points de terminaison TCP actuels pour voir si des ports TCP définis par l’utilisateur supplémentaires sont ajoutés à une installation SQL, vous pouvez utiliser l’instruction de requête « SELECT * FROM sys.tcp_endpoints » dans une session Transact-SQL (T-SQL). Pour plus d’informations sur la configuration du point de terminaison SQL Server, consultez Guide pratique pour configurer le moteur de base de données pour écouter sur plusieurs ports TCP (https://go.microsoft.com/fwlink/?LinkID=189231).
Évitez d’utiliser l’authentification basée sur SQL.
Pour éviter de devoir transférer des mots de passe en texte clair sur votre réseau ou stocker des mots de passe dans les paramètres de configuration, utilisez l’authentification Windows uniquement avec votre installation de SQL Server. L’authentification SQL Server est un mode d’authentification hérité. Le stockage des informations d’identification de connexion SQL (Nom d’utilisateur et mots de passe SQL) lorsque vous utilisez l’authentification SQL Server n’est pas recommandée. Pour plus d’informations, consultez Modes d’authentification (https://go.microsoft.com/fwlink/?LinkID=189232).
Évaluez attentivement la nécessité d’une sécurité de canal supplémentaire dans votre installation SQL.
Même avec l’authentification Kerberos en vigueur, l’interface du fournisseur de support de sécurité SQL Server (SSPI) ne fournit pas de sécurité au niveau du canal. Toutefois, pour les installations dans lesquelles les serveurs se trouvent en toute sécurité sur un réseau protégé par le pare-feu, le chiffrement des communications SQL peut ne pas être nécessaire.
Bien que le chiffrement soit un outil précieux pour garantir la sécurité, il ne doit pas être pris en compte pour toutes les données ou connexions. Lorsque vous décidez s’il faut implémenter le chiffrement, réfléchissez à la façon dont les utilisateurs accèdent aux données. Si les utilisateurs accèdent aux données sur un réseau public, le chiffrement des données peut être nécessaire pour renforcer la sécurité. Toutefois, si tous les accès aux données SQL par AD FS impliquent une configuration intranet sécurisée, le chiffrement peut ne pas être requis. Toute utilisation du chiffrement doit également inclure une stratégie de maintenance pour les mots de passe, les clés et les certificats.
S’il existe une préoccupation indiquant que toutes les données SQL peuvent être vues ou falsifiées sur votre réseau, utilisez la sécurité IPsec (Internet Protocol Security) ou SSL (Secure Sockets Layer) pour sécuriser vos connexions SQL. Toutefois, cela peut avoir un effet négatif sur les performances de SQL Server, ce qui peut affecter ou limiter les performances AD FS dans certaines situations. Par exemple, les performances AD FS dans l’émission de jetons peuvent se dégrader lorsque les recherches d’attributs à partir d’un magasin d’attributs SQL sont essentielles pour l’émission de jetons. Vous pouvez mieux éliminer une menace de falsification SQL en ayant une configuration de sécurité de périmètre forte. Par exemple, une meilleure solution pour sécuriser votre installation de SQL Server est de s’assurer qu’elle reste inaccessible pour les utilisateurs et les ordinateurs Internet et qu’elle reste accessible uniquement par les utilisateurs ou les ordinateurs de votre environnement de centre de données.
Pour plus d’informations, consultez Chiffrement des connexions à SQL Server ou SQL Server Encryption.
Configurez l'accès conçu de manière sécurisée à l'aide de procédures stockées pour effectuer toutes les recherches SQL d'AD FS sur des données SQL stockées.
Pour améliorer le service et l’isolation des données, vous pouvez créer des procédures stockées pour toutes les commandes de recherche de magasin d’attributs. Vous pouvez créer un rôle de base de données auquel vous accordez ensuite l’autorisation d’exécuter les procédures stockées. Attribuez l’identité de service du service Windows AD FS à ce rôle de base de données. Le service Windows AD FS ne doit pas être en mesure d’exécuter une autre instruction SQL, autre que les procédures stockées appropriées utilisées pour la recherche d’attributs. Le verrouillage de l’accès à la base de données SQL Server de cette façon réduit le risque d’attaque par élévation de privilèges.