Déployer dans un environnement haute disponibilité ou d'équilibrage de charge
Le contenu de cet article s'applique exclusivement aux systèmes d'exploitation Windows.
En respectant ces directives, vous pouvez assurer un déploiement robuste et sécurisé en haute disponibilité ou avec équilibrage de charge.
Considérations clés
Liste d'autorisation et liste de blocage d'adresses IP : Ces fonctionnalités nécessitent la validation de l'adresse IP du client pour assurer la sécurité et la conformité, généralement à l'aide de l'en-tête X-Forwarded-For qui doit être activé dans Administration – Paramètres du serveur – Sécurité. Veuillez également inclure l'en-tête X-Forwarded-For dans les journaux IIS pour assurer un suivi précis des adresses IP des clients.
En-têtes de réponse HTTP : Chaque nœud de serveur doit ajouter un identifiant unique et non descriptif aux en-têtes des réponses HTTP. Cet identifiant, qui peut être aussi générique que « node1 » ou « node2 », sert à suivre le chemin des requêtes à travers différents serveurs sans divulguer de détails sensibles sur le serveur, tels que le nom de domaine pleinement qualifié (FQDN). Cette pratique est essentielle non seulement pour cartographier le parcours des requêtes, mais aussi pour maintenir la sécurité opérationnelle, car elle limite l'exposition des détails d'infrastructure pouvant être exploités. Les organisations axées sur une sécurité renforcée devraient envisager des précautions supplémentaires, comme l'utilisation de valeurs aléatoires ou hachées comme identifiants pour masquer davantage l'identité des serveurs. Cela n'est pas requis pour la fonctionnalité, et chaque équilibreur de charge peut avoir sa propre méthode pour y parvenir. Cependant, identifier le serveur qui a répondu à la requête peut être une étape de dépannage utile. Veuillez consulter Identifier le serveur qui répond dans une topologie de haute disponibilité pour plus d'informations.
Architecture
Équilibreur de charge
X-Forwarded-For et certificats SSL : Lors de la mise en œuvre de l'équilibrage de charge, tenez également compte des certificats SSL et de l'en-tête X-Forwarded-For. Utilisez toute technologie d'équilibrage de charge capable d'ajouter l'en-tête X-Forwarded-For via des proxys ou des équipements intermédiaires. Cet en-tête doit être supprimé s'il est reçu d'un client, et uniquement défini par votre équipement réseau. Une configuration adéquate de ces éléments garantit des connexions sécurisées et un suivi précis des adresses IP des clients sur plusieurs serveurs. Consultez les considérations clés ci-dessus concernant la liste d'autorisation et la liste de blocage d'adresses IP.
Règles d'affinité client : L'attribution de règles d'affinité client garantit que lorsqu'un client se connecte pour la première fois, les requêtes ultérieures de ce même client sont dirigées vers le même serveur Web, assurant ainsi la cohérence.
Options d'équilibrage de charge : Si vous n'utilisez pas d'équilibreur de charge virtuel ou matériel dédié devant les serveurs Web, l'équilibrage de charge DNS peut être une alternative pratique. Dans cette approche, plusieurs enregistrements DNS (A, AAAA ou CNAME) sont configurés pour le même domaine. Lorsqu'un client se connecte, le fournisseur DNS sélectionne aléatoirement l'un de ces enregistrements pour répondre. Par exemple, si devolutions-server.mycorp.com possède deux enregistrements A pointant vers des adresses IP différentes pour chaque serveur Web, le DNS répondra avec l'un de ces enregistrements, distribuant ainsi efficacement la charge sur les serveurs. Cependant, l'équilibrage de charge DNS présente des limitations. Comme il ne dispose pas de vérifications de l'état, si un serveur tombe en panne, le fournisseur DNS peut tout de même diriger le trafic vers le serveur hors ligne, entraînant des échecs de connexion. Cet exemple est expliqué dans cet article Cloudflare sur les enregistrements DNS.
Serveurs Web / serveurs d'applications
Dans une configuration standard, deux serveurs sont configurés avec IIS, chacun exécutant une instance de Devolutions Server. Les considérations clés incluent le chiffrement, la transmission des adresses IP, le basculement SQL et la cohérence SSL.
Synchronisation des clés de chiffrement : Chaque serveur nécessite des clés de chiffrement identiques pour déchiffrer les données dans la base de données partagée. Après avoir installé le premier serveur, exportez ses clés de chiffrement et importez-les sur le second serveur pour assurer les capacités de déchiffrement appropriées.
Configuration de X-Forwarded-For : Configurez l'en-tête X-Forwarded-For pour maintenir des informations précises sur l'adresse IP du client à travers les serveurs. Cela est essentiel à des fins de suivi et de sécurité. Consultez les considérations clés ci-dessus concernant la liste d'autorisation et la liste de blocage d'adresses IP.
Configuration du basculement de base de données SQL : Dans la console Devolutions Server, suivez les étapes ci-dessous pour chaque instance de Devolutions Server.
Sélectionnez l'instance Devolutions Server.
Accédez à Serveur – Modifier.
Dans Base de données, cliquez sur Paramètres avancés.
Cliquez sur Plus de paramètres.
Définissez la Valeur du paramètre MultiSubnetFailover à True.
Cliquez sur Ok pour enregistrer vos modifications et fermer les fenêtres.
Ce paramètre permet à l'application de se connecter à plusieurs serveurs de base de données SQL dans le groupe de disponibilité Always On, assurant un basculement rapide si nécessaire.
Assurer la cohérence des certificats SSL : Étant donné que les deux serveurs IIS servent la même URL via un équilibreur de charge (sauf si vous utilisez IIS ARR avec un DNS round-robin ou un autre schéma d'équilibrage de charge), il est crucial que tous les certificats SSL correspondent et soient correctement servis tout au long de la chaîne. Assurez-vous que l'équilibreur de charge et les deux serveurs IIS disposent de certificats SSL correspondants pour fournir une connexion sécurisée et unifiée aux clients.
Serveurs de base de données
Configuration des serveurs SQL dans un groupe de disponibilité Always On : Pour assurer la haute disponibilité, configurez deux Microsoft SQL Servers dans un groupe de disponibilité Always On. Cette configuration suit un modèle Actif → Passif avec un quorum (ou « témoin ») pour surveiller l'état des serveurs et déclencher le basculement si l'un d'eux tombe en panne.
Activation du mode de base de données autonome : La base de données Devolutions Server doit fonctionner en mode autonome, permettant à l'authentification de voyager avec la base de données plutôt que d'être gérée au niveau du serveur. Suivez ces étapes pour activer le mode autonome (peut également être effectué à l'aide de commandes T-SQL) :
Ouvrez Microsoft SQL Server Management Studio.
Faites un clic droit sur la base de données Devolutions Server et sélectionnez Propriétés.
Accédez à Options et définissez le Type de relation contenant-contenu à Partiel.
Ce paramètre permet aux utilisateurs de la base de données de se déplacer avec la base de données entre les serveurs du groupe de disponibilité.
Création d'utilisateurs autonomes : Avec le mode autonome activé sur la base de données, vous pouvez créer des utilisateurs directement liés à celle-ci. Il peut s'agir de :
Utilisateurs SQL avec mots de passe : Créés spécifiquement dans la base de données autonome.
Utilisateurs Windows : Intégrés sans avoir besoin d'une connexion au serveur MSSQL associée à la base de données master.
Pour une sécurité renforcée, il est recommandé d'utiliser l'authentification Windows plutôt que des utilisateurs SQL avec mots de passe. Cependant, gardez à l'esprit que si vous utilisez des utilisateurs Windows, la fonctionnalité de coffre d'infrastructure de Devolutions Server ne sera pas en mesure de gérer ces utilisateurs, car elle ne prend actuellement en charge que les utilisateurs authentifiés par SQL.
Client Remote Desktop Manager : Lors de l'utilisation du client Remote Desktop Manager avec un Microsoft SQL Server dans une configuration de haute disponibilité (HA), activez la configuration de basculement multi-sous-réseau. Ce paramètre est spécifiquement bénéfique pour les installations HA de Microsoft SQL Server et n'est pas requis pour Devolutions Server. Pour configurer le basculement multi-sous-réseau dans RDM :
Dans Remote Desktop Manager, accédez à Fichier – Espaces de travail.
Sélectionnez l'espace de travail Microsoft SQL Server dans la liste des espaces de travail, puis cliquez sur Modifier l'espace de travail.
Dans l'onglet Avancé, cliquez sur Plus de paramètres.
Définissez la Valeur du paramètre MultiSubnetFailover à True.
Cliquez sur Ok et Enregistrer pour enregistrer vos modifications et fermer les fenêtres.
Cette configuration permet au client Remote Desktop Manager de gérer plusieurs sous-réseaux, assurant un basculement rapide entre les serveurs SQL dans un environnement de haute disponibilité.
Processus de vérification
Validation des courriels : Vérifiez que tout courriel généré par le système contient l'URI public correct, plutôt que le nom du serveur. Cela peut être vérifié à l'aide de la fonctionnalité de messagerie de Devolutions Server.
Historique des connexions et tentatives : La table LoginHistory contient l'adresse IP du client, et non celle des serveurs intermédiaires. La table LoginAttempts répertorie également l'adresse IP, mais couvre davantage de scénarios :
Échecs de connexion (par exemple, identifiants incorrects)
Adresses IP bloquées
Adresses IP identifiées comme nœud de sortie TOR
Mis à jour
Ce contenu vous a-t-il été utile ?