SQL Server Management Studio pour une base de données distante

Avec une base de données SQL Sever qui se trouve sur un serveur dédié hébergé à distance, je peux travailler à l'aide de SQL Server Management Studio installé sur le même serveur ou sur mon ordinateur local. Dans le premier cas, je devrais travailler en utilisant Remote Desktop et cela rend le travail un peu plus lent. Dans le deuxième cas, j'ai besoin d'ouvrir un port supplémentaire dans le pare-feu du serveur, mais j'aurai une expérience utilisateur plus confortable.

Quelle est la pratique recommandée de ces deux?

L'ouverture du serveur SQL pour diriger les connexions externes est une idée à éviter si vous le pouvez - vous augmentez considérablement votre surface visible pour les attaques et toute communication entre vous et le serveur (à part les informations de connexion dans la phase d'authentification, peut-être) ne sera pas crypté. Si vous devez ouvrir le port, assurez-vous qu'il est ouvert uniquement à vos adresses IP fixes (en supposant que vous avez des adresses fixes qui ne sont partagées par personne d'autre, c'est-à-dire que vous n'utilisez pas un FAI qui vous a derrière un arrangement NAT comme la plupart des fournisseurs Internet mobiles).

Une bien meilleure option serait d'installer une configuration VPN (comme OpenVPN par exemple) ou un service SSH ( Cygwincomprend un port de la norme commune OpenSSH que je finance actuellement fonctionne bien ainsi qu'un service sous Windows 2003 et 2008) par lequel vous pouvez tunneliser une connexion. De cette façon, SSH ou le VPN gèrent à la fois l'authentification et le cryptage, et ajoutent (en supposant que vous avez des mots de passe / clés sécurisés) une couche de protection importante qu'un port directement ouvert n'aurait pas. La prise en charge de la compression offerte offre des temps de réponse pour toutes les requêtes qui renvoient également plus qu'une petite quantité de données. Un arrangement basé sur SSHd peut être plus facile à configurer, surtout si vous êtes déjà familier avec SSH, bien que la plupart des vrais VPN (comme OpenVPN) aient l'avantage que la communication par-dessus eux soit plus susceptible de survivre à de courtes coupures de communication (comme la perte d'un routeur ADSL synchronisation et reconnexion). L'option VPN est également moins compliquée si plusieurs instances de SQL Server s'exécutent sur la machine cible ou sur le site cible. J'ai utilisé les deux méthodes avec succès pour un certain nombre de choses, y compris pour parler à SQL Server en utilisant des versions locales des outils standard et je les ai trouvées bien fonctionner (bien que mes serveurs OpenVPN soient tous sur Linux, mais on me dit que cela fonctionne bien aussi). serveur sous Windows également).

La connexion directe à la machine distante (in) comme celle-ci peut être très pratique, mais sachez que même avec une configuration VPN soignée, vous augmentez le nombre de machines auxquelles votre SQL Server est exposé, en particulier s'il s'agit d'un système de production avec votre données réelles de l'utilisateur, assurez-vous de prendre le temps de vous assurer que les machines qui peuvent voir le serveur via le VPN / tunnel sont sécurisées et non infectées elles-mêmes (vous le faites probablement déjà, bien sûr, mais cela vaut toujours la peine d'être réaffirmé!).

La façon dont je sais de le faire est d'établir une connexion VPN à l'autre site, éclipsant ainsi la nécessité d'ouvrir un port et de maintenir la sécurité de la configuration, tout en éliminant la nécessité de RDP dans l'autre serveur. Certes, vous courez le risque de supprimer une connexion pendant que vous travaillez, ce qui peut éventuellement mettre fin aux requêtes prématurément, mais sinon ... c'est ce que nous faisons et cela fonctionne bien pour nous.

Si vous allez les utiliser régulièrement à distance, vous pouvez rechercher une connexion VPN semi-permanente (je suis sûr qu'il y a un meilleur nom .. Pont VPN?) Qui vous permettra de vous connecter simplement par adresse IP. Un gars de réseautage peut mieux peser ici.

Dans notre bureau, nous avons deux pare-feu, un pare-feu pour l'Internet public et un pour le réseau interne. Si vous êtes sur le réseau interne, vous pouvez vous connecter directement au serveur SQL. Si vous sur Internet externe, vous ne pouvez pas, car le port n'est pas ouvert sur le pare-feu. Si vous souhaitez vous connecter via Internet, vous devez vous connecter via VPN.

Dans notre bureau, nous avons un VPN permanent pour tous les serveurs db et nous travaillons avec Management Studio local sur des serveurs distants. L'utilisation du bureau à distance est un peu plus lente que celle des outils locaux :).

Lorsque la connexion au bureau à distance est vraiment nécessaire, vous pouvez utiliser un outil gratuit (comme Royal TS) et conserver toutes les connexions du serveur dans un fichier crypté et ne l'utiliser que lorsque cela est nécessaire.