Pourquoi les serveurs liés seraient-ils interdits?

Question

Je travaille dans un environnement d'entreprise où la création de serveurs liés est absolument interdite. J'ai demandé la raison de la DBA et la seule réponse que j'ai jamais est, "C'est la politique". Je me trouve donc obligé d'écrire et de faire usage de paquets SSIS pour déplacer des données entre les bases de données quand un tel besoin se fait sentir.

Quelqu'un peut-il me dire quelles raisons pourraient avoir été derrière la création d'une telle politique? Cela me semble plutôt injustifié.

Answer 1

La théorie veut que si un serveur est compromis, tout serveur lié est automatiquement compromis.

Personnellement, je pense que cela signifie simplement que vous devriez réfléchir à deux fois avant de créer des liens très forts ou de confiance. Vous pouvez choisir le compte utilisé pour chaque connexion de lien et limiter l'accès de ces comptes pour créer des liens plus petits et bien définis qui autorisent uniquement l'accès pour certaines choses. Par exemple, où nous en sommes, nous avons plusieurs clients qui ont tous une base de données individuelle sur un serveur avec des schémas identiques, un autre serveur sur lequel nous travaillons beaucoup et un autre serveur qui contient une base de données commune avec les détails du client . Nous avons un lien spécial établi entre la base de données de reporting et la base de données détaillée qui permet d'insérer des informations en lecture seule dans un rapport pour l'adapter à un client spécifique, mais rien d'autre.

Answer 2

Si un attaquant met la main sur une base de données, il doit travailler plus fort pour posséder tout le système.

Answer 3

Simple. Quelqu'un a décidé qu'il appartient au panier "trop ​​dur". Il y a aussi la sécurité (accès à un serveur via une porte dérobée dans l'autre) et la stabilité (le serveur A descend et prend le serveur B avec lui).

Vous ne justifiez probablement pas votre raison d'avoir besoin d'un serveur lié assez bien pour en valoir la peine. Souvent, il est moins cher d'acheter un serveur plus rapide.

Vous pouvez toujours demander à voir où la politique est écrite. Les chances sont qu'il n'y a pas vraiment de politique formelle du tout.

Answer 4

C'est généralement un problème avec les mappages de connexion.

Si vous associez:

• « quelqu'un local spécifique à distance », alors tout le monde peut utiliser le serveur lié

• « locaux spécifiques spécifiques à distance », puis les besoins locaux une d'entrée pour l'utilisateur actuel dans sys.server_principals ce qui signifie que vous ne pouvez pas restreindre à un groupe NT: vous devez lister les utilisateurs séparément (qui n'est probablement pas dans la politique)

• "use self" (ceci est une variation de "local spécifique à remot e spécifique "), mon jeton de connexion" domaine \ bob "de confiance est utilisé pour la connexion à distance. Cela nécessite que le serveur local soit configuré pour la délégation et un SPN configuré dans AD.

aussi:

• j'ai vu des cas où la connexion à distance a des droits « sysadmin » parce qu'il est pas géré par CBM, ou est géré par un autre groupe. Cela signifie que tous les serveurs SQL sont généralement compromis.

Vous pouvez utiliser OPENDATASOURCE, mais cela nécessite un accès ad hoc pour être activé. Ce qui peut être autorisé à la place d'un serveur lié statique.

Utilisés correctement, ils sont OK, mais ils ont des limitations dans les connexions de mappage. Donc, c'est plus facile de dire non.

Nous les utilisons ici, FWIW.

Answer 5

Voici une alternative aux explications les plus probables dans les autres réponses. La politique pourrait être un survivant solitaire de l'école de pensée Service Oriented Architecture. Ce qui a déclaré que:

vise service d'orientation à un couplage lâche des services

serveurs liés sont bas niveau et fortement couplés, et un architecture astronaut pourraient serveurs liés interdisent le à cause de cela. Une façon de «corriger» cette politique est de convaincre vos clients professionnels que vous avez une bonne solution pour leur problème; mais cela nécessite absolument des serveurs liés. Les gens d'affaires parleront aux DBA, et il y a de bonnes chances que le DBA accepte un essai du serveur lié. Pour que cela fonctionne, parlez au DBA avec la plus forte opposition aux serveurs liés. Les administrateurs de base de données peuvent ralentir les développeurs, mais ils ont tendance à céder rapidement à l'entreprise.

Un essai sera la fin de la politique. Les serveurs liés fonctionnent et SOA ne fonctionne pas.

P.S. Aux Pays-Bas, nous avons eu de la chance: SOA signifie maladies sexuellement transmissibles en néerlandais, donc le SOA silver bullet a volé par :-)