Meilleures pratiques pour sécuriser la planification et le déploiement d'AD FS
Cette rubrique fournit des informations sur les meilleures pratiques qui vous aideront à planifier et à évaluer la sécurité dans la conception de votre déploiement des services de fédération Active Directory (AD FS). Elle constitue un point de départ pour examiner et étudier les aspects qui influent sur la sécurité globale de l’utilisation d’AD FS. Les informations qu’elle contient sont destinées à compléter et à étendre vos meilleures pratiques en matière de planification de la sécurité et de conception.
Meilleures pratiques principales en matière de sécurité pour AD FS
Les meilleures pratiques de base suivantes concernent toutes les installations d’AD FS dont la sécurité de la conception ou du déploiement doit être améliorée ou étendue :
Sécurisation d’AD FS en tant que système de « niveau 0 » :
En raison de sa nature de système d’authentification, AD FS doit être traité comme un système de « niveau 0 », comme les autres systèmes d’identité de votre réseau. Pour plus d’informations, consultez Modèle de niveau d’administration 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 serveurs proxy de fédération.
L’outil Assistant Configuration de la sécurité est préinstallé sur tous les ordinateurs Windows Server 2008, Windows Server 2008 R2 et Windows Server 2012. Vous pouvez l'utiliser pour appliquer des meilleures pratiques de sécurité qui permettent de réduire la surface d'attaque d'un serveur, en fonction des rôles serveurs que vous installez.
Quand vous installez AD FS, le programme d'installation crée des fichiers d'extension de rôle, que vous pouvez utiliser avec l'Assistant Configuration de la sécurité pour créer une stratégie de sécurité à appliquer au rôle serveur AD FS (serveur de fédération ou serveur proxy de fédération) que vous choisissez pendant 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 n'est présent que si vous avez configuré l'ordinateur dans le rôle de serveur proxy de fédération.)
Pour appliquer les extensions de rôle AD FS dans l'Assistant Configuration de la sécurité, effectuez les étapes suivantes dans l'ordre indiqué :
Installez AD FS et choisissez le rôle serveur approprié pour cet ordinateur. Pour plus d’informations, consultez Installation du service de rôle proxy FSP (Federation Service Proxy) dans le guide de déploiement d’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 exécutée correctement en examinant le fichier SCWRegister_log.xml, situé dans le répertoire WindowssecurityMsscwLogs.
Vous devez effectuer toutes ces étapes sur chaque ordinateur serveur de fédération ou serveur proxy de fédération auquel vous souhaitez appliquer des stratégies de sécurité AD FS dans l'Assistant Configuration de la sécurité.
Le tableau suivant explique comment inscrire l'extension de rôle appropriée dans l'Assistant Configuration de la sécurité, 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 SQL Server 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 Rôle de la base de données de configuration AD FS.
Utilisez la détection de réexécution de jeton dans les situations où la sécurité constitue un problème très important, par exemple en cas de recours à des bornes. La détection de réexécution de jeton constitue une fonctionnalité d’AD FS grâce à laquelle toute tentative de réexécution d’une demande de jeton effectuée auprès du service FS (Federation Service) est détectée et se solde par l’abandon de la demande. La détection des relectures de jetons est activée par défaut. Elle fonctionne à la fois pour le profil passif WS-Federation et pour le profil WebSSO SAML (Security Assertion Markup Language) et s'assure qu'un même jeton n'est jamais réutilisé.
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. À mesure que des demandes de jeton sont ajoutées au cache, la possibilité de détecter des tentatives de relecture d'une demande de jeton augmente pour le service de fédération. Si vous désactivez la détection de relectures de jetons, puis que vous décidez de la réactiver, gardez à l'esprit que le service de fédération acceptera toujours des jetons qui ont peut-être déjà été utilisés, ce jusqu'à ce que le système alloue au cache de relectures suffisamment de temps pour qu'il régénère 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 une légère incidence sur le débit, mais en général, elle s'effectue de manière transparente et, dans de nombreux déploiements, les avantages procurés par une sécurité renforcée compensent largement les pertes de performances éventuellement accusées par les serveurs.
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 quand vous créez une approbation de partie de confiance ou ultérieurement. Si vous souhaitez ajouter par la suite un certificat de chiffrement à l’approbation d’une partie de confiance existante, vous pouvez définir le certificat dans l’onglet Chiffrement des propriétés d’approbation à l’aide du composant logiciel enfichable AD FS. Pour spécifier un certificat pour une approbation existante à l’aide des cmdlets AD FS, utilisez le paramètre EncryptionCertificate de la cmdlet Set-ClaimsProviderTrust ou de la cmdlet Set-RelyingPartyTrust. Pour définir le certificat dont le service FS devra se servir pendant le déchiffrement des jetons, employez la cmdlet Set-ADFSCertificate en spécifiant «
Token-Encryption» pour le paramètre CertificateType. Vous pouvez activer et désactiver le chiffrement pour une approbation de partie de confiance spécifique à l'aide du paramètre EncryptClaims de l'applet de commande Set-RelyingPartyTrust.Utilisation de la protection étendue pour l’authentification :
Pour sécuriser vos déploiements, vous pouvez définir et utiliser la fonctionnalité de protection étendue de l’authentification avec AD FS. Ce paramètre spécifie le niveau de protection étendue de l’authentification pris en charge par un serveur de fédération.
La protection étendue de l'authentification assure une protection contre les attaques de l'intercepteur, dans lesquelles une personne malveillante intercepte les informations d'identification d'un client et les transmet à un serveur. La protection contre les attaques de ce type s'effectue par le biais d'un jeton de liaison de canal qui peut être autorisé, imposé ou non imposé par le serveur quand il établit des communications avec des clients.
Pour activer la protection étendue, utilisez le paramètre ExtendedProtectionTokenCheck de l'applet de commande Set-ADFSProperties. Les valeurs possibles de ce paramètre et le niveau de sécurité qu'elles fournissent sont décrits dans le tableau suivant.
Valeur du paramètre Niveau de sécurité Paramétrage de la protection Exiger Le serveur est entièrement sécurisé. La protection étendue est appliquée et toujours obligatoire. Autoriser Le serveur est partiellement sécurisé. La protection étendue est appliquée sur les systèmes concernés qui ont fait l'objet d'un correctif pour prendre en charge cette fonctionnalité. Aucun Le serveur est vulnérable. La protection étendue n'est pas appliquée. Si vous utilisez la journalisation et le suivi, protégez la confidentialité des informations sensibles.
Par défaut, AD FS n’expose pas d’informations d’identification personnelle, ni n’en effectue le suivi, que ce soit directement dans le cadre du service FS ou en fonctionnement normal. Toutefois, quand la journalisation des événements et de la trace de débogage est activée dans AD FS, certains types de revendications et les valeurs associées peuvent, suivant la stratégie de revendications configurée, contenir des informations d’identification personnelle susceptibles d’être consignées dans les journaux d’événements ou de traçage d’AD FS.
Nous vous recommandons donc vivement d’appliquer le contrôle d’accès à la configuration d’AD FS et à ses fichiers journaux. Si vous souhaitez que ce type d’informations demeure invisible, vous devez désactiver la journalisation ou retirer toutes les informations d’identification personnelle et données sensibles des journaux avant de les partager.
Les conseils suivants vous permettent d'éviter l'exposition involontaire du contenu d'un fichier journal :
Vérifiez que les fichiers journaux d’événements et de trace d’AD FS sont protégés par des listes de contrôle d’accès qui limitent l’accès aux seuls administrateurs approuvés ayant besoin d’utiliser ces fichiers.
Ne copiez pas ou n'archivez pas les fichiers journaux en utilisant des extensions de fichier ou des chemins d'accès qui peuvent être facilement fournis à l'aide d'une demande web. Par exemple, l'extension de nom de fichier .xml n'est pas un choix judicieux. Consultez le guide d'administration IIS (Internet Information Services) pour obtenir la liste des extensions qui peuvent être fournies.
Si vous modifiez le chemin d'accès du fichier journal, veillez à spécifier un chemin d'accès absolu pour l'emplacement de ce fichier, qui doit se trouver en dehors du répertoire public de la racine virtuelle de l'hôte web afin d'empêcher tout intervenant externe d'y accéder à 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 qui se présente sous la forme de demandes d’authentification effectuées avec des mots de passe non valides (incorrects) et transitant par le Proxy d’application Web, le verrouillage de l’extranet AD FS vous permet de protéger vos utilisateurs contre un verrouillage de compte AD FS. Il vous préserve également des attaques par force brute tentant de deviner le mot de passe.
Pour plus d’informations sur le verrouillage logiciel de l’extranet pour AD FS sur Windows Server 2012 R2, consultez Protection contre le verrouillage logiciel de l’extranet AD FS.
Pour plus d’informations sur le verrouillage intelligent de l’extranet pour AD FS sur Windows Server 2016, consultez Protection intelligente contre le verrouillage de l’extranet AD FS.
Meilleures pratiques propres à SQL Server en matière de sécurité pour AD FS
Les meilleures pratiques suivantes en matière de sécurité concernent Microsoft SQL Server® ou la Base de données interne Windows quand ces technologies sont utilisées pour gérer des données pendant la conception et le déploiement d’AD FS.
Remarque
Ces recommandations étendent, mais ne remplacent pas, les conseils de sécurité pour SQL Server. Pour plus d’informations sur la planification d’une installation SQL Server sécurisée, consultez Considérations sur la sécurité d’une installation SQL Server (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 SQL Server ne doit jamais être directement exposée à Internet. Seuls les ordinateurs qui se trouvent dans votre centre de données doivent pouvoir accéder à votre installation SQL Server prenant en charge AD FS. Pour plus d’informations, consultez Liste de contrôle 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 par défaut 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. Dans le but de renforcer la sécurité de votre installation SQL Server pour AD FS, utilisez dans la mesure du possible 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é de ce compte dans votre déploiement Active Directory. Cela permet une authentification mutuelle entre le client et le serveur. Si vous n'inscrivez pas le nom de principal de sécurité d'un compte de service distinct, seul le client est authentifié, car SQL Server utilise alors l'authentification NTLM ou Windows.
Réduisez au minimum l'exposition de SQL Server.
Activez uniquement les points de terminaison SQL Server qui sont nécessaires. Par défaut, SQL Server fournit un point de terminaison TCP intégré unique qui ne peut pas être supprimé. Dans le cas d’AD FS, activez ce point de terminaison TCP pour l’authentification Kerberos. Pour passer en revue les points de terminaison TCP actuels afin de déterminer si des ports TCP définis par l'utilisateur 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 : Configuration du Moteur de base de données pour écouter sur plusieurs ports TCP (https://go.microsoft.com/fwlink/?LinkID=189231).
Évitez d'utiliser l'authentification SQL.
Pour que les mots de passe ne circulent pas sur votre réseau sous la forme de texte en clair ou qu'ils ne soient pas stockés dans les paramètres de configuration, n'utilisez l'authentification Windows qu'avec votre installation SQL Server. L'authentification SQL Server est un mode d'authentification hérité. Nous vous déconseillons de stocker les informations d'identification SQL (noms d'utilisateur et mots de passe SQL) quand vous utilisez l'authentification SQL Server. Pour plus d’informations, consultez Modes d’authentification (https://go.microsoft.com/fwlink/?LinkID=189232).
Déterminez attentivement si vous devez renforcer la sécurité des canaux dans votre installation SQL.
Même si l'authentification Kerberos est appliquée, l'interface SQL Server SSPI (Security Support Provider Interface) ne fournit pas de sécurité de niveau canal. Toutefois, pour les installations dans lesquelles les serveurs sont reliés de manière sécurisée à un réseau protégé par un pare-feu, le chiffrement des communications SQL n'est pas forcément nécessaire.
Bien que le chiffrement soit un outil précieux qui aide à garantir la sécurité, il ne doit pas être envisagé pour toutes les données et connexions. Lorsque vous décidez de mettre en œuvre ou non le chiffrement, tenez compte de la manière dont les utilisateurs accèderont aux données. Si les utilisateurs accèdent aux données via un réseau public, le chiffrement des données peut être requis pour augmenter la sécurité. Toutefois, si l’accès aux données SQL par AD FS fait systématiquement appel à une configuration intranet sécurisée, le chiffrement ne s’impose peut-être pas. Toute utilisation du chiffrement doit également inclure une stratégie de maintenance pour les mots de passe, les clés et les certificats.
Si vous pensez que des données SQL risquent d'être exposées ou altérées via votre réseau, utilisez la sécurité du protocole Internet (IPsec) ou SSL (Secure Sockets Layer) pour sécuriser vos connexions SQL. Toutefois, cela pourrait nuire aux performances SQL Server et donc, dans certaines situations, à celles d’AD FS. Concernant l’émission de jetons par exemple, les performances d’AD FS peuvent se dégrader si cette fonctionnalité doit faire appel à des recherches d’attribut dans un magasin d’attributs SQL. Pour éliminer le risque d'altération des données SQL, vous pouvez privilégier une configuration dans laquelle la sécurité est concentrée sur un périmètre clairement défini. Par exemple, une meilleure solution pour sécuriser votre installation SQL Server consiste à la rendre inaccessible aux utilisateurs et ordinateurs Internet, de manière à ce que seuls les utilisateurs ou les ordinateurs appartenant à l'environnement de votre centre de données puissent y accéder.
Pour plus d’informations, consultez Chiffrement des connexions à SQL Server ou Chiffrement SQL Server.
Configuration d’un accès sécurisé pour que toutes les recherches SQL de données stockées SQL effectuées par AD FS passent par des procédures stockées :
Pour améliorer l'isolation des services et des données, vous pouvez créer des procédures stockées pour toutes les commandes de recherche dans le 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é du service Windows AD FS ce rôle de base de données. Le service Windows AD FS ne doit pouvoir exécuter aucune instruction SQL autre que les procédures stockées utilisées pour la recherche d’attribut. Le verrouillage de l'accès à la base de données SQL Server de cette manière réduit le risque d'une attaque par élévation de privilège.