Déployer dans un environnement à haute disponibilité ou d'équilibrage de charge

En suivant ces directives, assurer un déploiement robuste et sécurisé pour une haute disponibilité ou un équilibrage de la charge.

Considérations clés

• Mise sur liste blanche et liste noire IP : Ces fonctionnalités nécessitent la validation de l'adresse IP du client pour garantir la sécurité et la conformité, généralement avec l'en-tête X-Forwarded-For qui doit être activé dans Administration – Paramètres du serveur – Sécurité.

  

  
  Inclure également 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 sur différents serveurs sans divulguer de détails sensibles sur le serveur comme le nom de domaine pleinement qualifié (FQDN). Cette pratique est cruciale 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 de l'infrastructure qui pourraient ê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 randomisées ou hachées comme identifiants pour obscurcir davantage les identités des serveurs.
  
  Ceci n'est pas requis pour les fonctionnalités, et chaque équilibreur de charge peut avoir sa propre méthode pour y parvenir. Cependant, identifier le serveur qui a répondu à la demande peut être une étape utile pour la résolution de problèmes.
  
  Veuillez suivre Identifier le serveur répondant 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, prendre également en compte les certificats SSL et l'en-tête X-Forwarded-For.
  Utiliser toute technologie d'équilibrage de charge qui peut ajouter l'en-tête X-Forwarded-For via des proxys ou des dispositifs intermédiaires. Cet en-tête devrait être supprimé s'il est reçu d'un client, et seulement défini par votre équipement réseau.
  Une configuration adéquate de ces éléments assure des connexions sécurisées et un suivi IP client précis à travers plusieurs serveurs. Voir les considérations clés ci-dessus à propos de la liste blanche et de la liste noire d'IP.
• Règles d'affinité client: Assigner des règles d'affinité client assure que lorsqu'un client se connecte pour la première fois, les futures requêtes du même client sont dirigées vers le même serveur web, maintenant ainsi la cohérence.
• Options d'équilibrage des charges : Si vous n'utilisez pas un é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 au hasard l'un de ces enregistrements pour répondre.
  Par exemple, si dvls.mycorp.com a deux enregistrements A pointant vers différentes IPs pour chaque serveur Web, le DNS répondra à l'un de ces enregistrements, répartissant ainsi la charge entre les serveurs.
  Cependant, l'équilibrage de charge DNS présente des limitations. Comme il manque de vérifications de l'état, si un serveur tombe en panne, le fournisseur DNS peut toujours diriger le trafic vers le serveur hors ligne, entraînant des connexions échouées. Cet exemple est expliqué dans cet article de Cloudflare sur les enregistrements DNS.

Serveurs Web / serveurs d'applications

Dans une configuration typique, deux serveurs sont configurés avec IIS, chacun exécutant une instance de Devolutions Server. Les considérations clés incluent le chiffrement, le réacheminement IP, le basculement SQL et la cohérence SSL.

• Synchroniser les 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, exporter ses clés de chiffrement et les importer sur le deuxième serveur pour assurer des capacités de déchiffrement adéquates.

• Configurer X-Forwarded-For : Mettre en place l'en-tête X-Forwarded-For pour maintenir des informations IP client précises sur les serveurs. Ceci est essentiel pour le suivi et les raisons de sécurité. Voir les considérations clés ci-dessus sur la mise en liste blanche et noire IP.

• Configurer le basculement de la base de données SQL : Dans la console Devolutions Server, suivre les étapes ci-dessous pour chaque instance de Devolutions Server.

  1. Sélectionner l'instance de Devolutions Server.
  2. Aller à Serveur – Modifier.

     

  3. Dans Base de données, cliquer sur Paramètres avancés.

     

  4. Cliquer sur Plus de paramètres.

     

  5. Définir la Valeur du paramètre MultiSubnetFailover à True.

     

  6. Cliquer 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 lorsque nécessaire.

• Assurer la cohérence du certificat SSL: Puisque les deux serveurs IIS servent la même URL à travers un équilibreur de charge (à moins que vous utilisiez IIS ARR avec un DNS en 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. Veiller à ce que l'équilibreur de charge et les deux serveurs IIS aient des certificats SSL identiques pour fournir une connexion sécurisée et unifiée pour les clients.

Serveurs de bases de données

• Configurer les serveurs SQL dans un groupe de disponibilité Always On : Pour assurer une haute disponibilité, configurer deux serveurs SQL Microsoft dans un groupe de disponibilité Always On. Cette configuration suit un modèle Actif → Passif avec un quorum (ou "témoin") pour surveiller la santé du serveur et déclencher un basculement si un serveur tombe en panne.

• Activation du mode base de données conteneurisée : La base de données Devolutions Server doit fonctionner en mode conteneurisé, permettant à l'authentification de voyager avec la base de données au lieu d'être gérée au niveau du serveur. Suivez ces étapes pour activer le mode conteneurisé (peut également être fait en utilisant des commandes T-SQL) :

  1. Ouvrir Microsoft SQL Server Management Studio.
  2. Clic-droit sur la base de données Devolutions Server et sélectionner Propriétés.
  3. Aller à Options et définir le Type de conteneurisation sur Partiel.

  Ce paramètre permet aux utilisateurs de la base de données de se déplacer avec la base de données à travers les serveurs dans le groupe de disponibilité.

• Créer des utilisateurs contenus: Avec le mode contenu activé sur la base de données, créer des utilisateurs qui sont directement liés à celle-ci.
  Ceux-ci peuvent être :

  • Utilisateurs SQL avec mots de passe: Créés spécifiquement au sein de la base de données contenue.
  • Utilisateurs Windows : Intégré sans nécessiter une connexion MSSQL server associée avec la base de données maîtresse.

  Pour une sécurité renforcée, il est recommandé d'utiliser l'authentification Windows au lieu des utilisateurs SQL avec des mots de passe. Cependant, gardez à l'esprit que si vous utilisez des utilisateurs Windows, la fonctionnalité de coffre d'infrastructure de Devolutions Server ne pourra pas 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), activer la configuration de basculement multisubnet. Ce paramètre est spécifiquement bénéfique pour les installations HA de Microsoft SQL Server et non requis pour Devolutions Server.
  Pour configurer le basculement multisubnet dans RDM :

  1. Dans Remote Desktop Manager, naviguer vers Fichier – Sources de données.
  2. Sélectionner la source de données Microsoft SQL Server dans la liste des sources de données, puis cliquer sur Modifier la source de données.

     

  3. Dans l'onglet Avancé, cliquer sur Plus de paramètres.

     

  4. Définir la Valeur du paramètre MultiSubnetFailover à True.

     

  5. Cliquer sur Ok et Sauvegarder 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 de l'email: Vérifier que tout email généré par le système contient la correcte URI publique, plutôt que le nom du serveur. Cela peut être vérifié en utilisant la fonction de messagerie de Devolutions Server.

  

• Historique des connexions et tentatives: La table LoginHistory contient l'adresse IP pour le client, et non pour les serveurs intermédiaires. La table LoginAttempts liste également l'adresse IP, mais il existe d'autres scénarios :
  • Échecs de connexion (par exemple, mauvais identifiants)
  • IPs listées dans la liste noire
  • IPs identifiées comme un nœud de sortie TOR