Déploiement dans un environnement en haute disponibilité ou équilibrage de charge

En respectant ces directives, garantir un déploiement solide et sécurisé en haute disponibilité ou en équilibrage de charge.

• 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 du serveur doit ajouter un identifiant unique et non descriptif aux en-têtes des réponses HTTP. Cet identifiant, qui pourrait ê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 du 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 de détails d'infrastructure qui pourraient être exploités. Les organisations axées sur une sécurité accrue devraient envisager des précautions supplémentaires telles que l'utilisation de valeurs aléatoires ou hachées comme identifiants pour obscurcir davantage les identités des serveurs.
  
  Cela n'est pas requis pour le fonctionnement, et chaque équilibreur de charge peut avoir sa propre méthode pour y parvenir. Cependant, identifier le serveur ayant répondu à la requête peut être une étape utile de dépannage.
  
  Veuillez suivre Identifier le serveur répondant sur une topologie à haute disponibilité pour plus d'informations.

• X-Forwarded-For et certificats SSL: Lors de la mise en œuvre de l'équilibrage de charge, tenir également compte des certificats SSL et de 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 mandataires ou des dispositifs intermédiaires. Cet en-tête doit être retiré s'il est reçu d'un client, et uniquement défini par votre équipement réseau.
  Une configuration appropriée de ces éléments assure des connexions sécurisées et un suivi précis de l'IP client à travers plusieurs serveurs. Voir les considérations clés ci-dessus concernant la liste blanche et la liste noire IP.

• Règles d'affinité client : Attribuer des règles d'affinité client garantit que lorsqu'un client se connecte pour la première fois, les requêtes futures du même client sont dirigées vers le même serveur Web, assurant la cohérence.

• Options d'équilibrage de charge: 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 IP pour chaque serveur Web, le DNS répondra à l'un de ces enregistrements, distribuant effectivement la charge entre les serveurs.
  Cependant, l'équilibrage de charge DNS a des limites. Comme il manque de vérifications d'intégrité, si un serveur tombe en panne, le fournisseur DNS peut toujours 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.

Dans une configuration typique, deux serveurs sont configurés avec IIS, chacun exécutant une instance de Devolutions Server. Considérations clés incluent le chiffrement, l'acheminement IP, tolérance de panne SQL et la cohérence SSL.

• Synchroniser les clés de chiffrement : Chaque serveur nécessite des clés de chiffrement assorties 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 garantir de bonnes capacités de déchiffrement.

• Configurer X-Forwarded-For : Configurer l'en-tête X-Forwarded-For pour maintenir des informations IP précises des clients à travers les serveurs. Ceci est essentiel à des fins de suivi et de sécurité. Voir les considérations clés ci-dessus concernant la liste blanche et la liste noire IP.

• Configurer le basculement de la base de données SQL : Dans la console de 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 Database, cliquer sur Advanced settings.

  4. Cliquer sur Plus de paramètres.

  5. Définir la Valeur du paramètre MultiSubnetFailover sur 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 si nécessaire.

• Assurer la cohérence des certificats SSL: Puisque les deux serveurs IIS utilisent la même URL à travers un équilibrage de charge (à moins que vous n'utilisiez 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. Assurer que l’équilibreur de charge et les deux serveurs IIS aient des certificats SSL correspondants pour fournir une connexion sécurisée et unifiée aux clients.

• Configurer les serveurs SQL dans un groupe de disponibilité Always On : Pour assurer une haute disponibilité, configurer deux serveurs Microsoft SQL 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 de santé du serveur et déclencher un basculement si un serveur tombe en panne.

• Activation du mode base de données contenue : La base de données Devolutions Server doit fonctionner en mode contenu, 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 contenu (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 confinement 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 y sont directement rattachés.
  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és sans nécessiter une connexion au serveur MSSQL associée à la base de données maître.

  Pour renforcer la sécurité, il est recommandé d'utiliser l'authentification Windows au lieu des utilisateurs SQL avec mots de passe. Toutefois, 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 un environnement haute disponibilité (HA), activer la configuration de basculement multisous-réseau. Ce paramètre est spécifiquement avantageux pour les installations HA de Microsoft SQL Server et n'est pas requis pour Devolutions Server.
  Configurer le Basculement multisous-réseau dans RDM :

  1. Dans Remote Desktop Manager, naviguer jusqu'à 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 sur True.

  5. Cliquer 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 à haute disponibilité.

• Validation des courriels : Vérifier 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é en utilisant la fonctionnalité de messagerie de Devolutions Server.

• Historique et tentatives de connexion: La table LoginHistory contient l'adresse IP du client, et non pas de tout serveur intermédiaire. La table LoginAttempts répertorie également l'adresse IP, mais dans d'autres scénarios:

  • Échecs de connexion (par exemple, mauvais identifiants)

  • IPs de la liste noire

  • IPs identifiées comme noeud de sortie TOR