Mise en contexte d'exécution à l'intérieur déclencheur de connexion

Question

J'ai une base de données appelée MyDB dans une instance express Microsoft SQL Server 2008 en utilisant l'authentification en mode mixte. L'application à l'aide de la base de données MyDB relie actuellement en utilisant l'authentification Windows, en utilisant les informations d'identification Windows de l'utilisateur actuel. Cette connexion est un membre du rôle de serveur « public », et a un utilisateur associé à la base de données dans MyDB. Cet utilisateur de base de données est un membre des rôles de base de données et db_datareader db_datawriter.

Ce que je voudrais est que lorsque l'application se connecte, il a des permissions de lecture et d'écriture dans MyDB. Mais quand une autre application se connecte en utilisant la même connexion, il ne devrait être autorisé à lire.

Ma pensée est que je voudrais créer un déclencheur d'ouverture de session, qui vérifierait le nom de l'application une partie de la chaîne de connexion, et sur cette base décider si le contexte d'exécution doit être commuté. (Pour mémoire, je sais qu'il est en aucune façon sûre de compter sur le nom de l'application de la chaîne de connexion, et qu'il est très facile à contourner. Le but est de ne pas sécuriser la base de données, mais pour les utilisateurs d'aider à éviter de changer les données lors de leur connexion en utilisant une autre application, tel que Microsoft Excel)

J'ai créé une nouvelle connexion appelée « myapp_reader » mis en correspondance avec un utilisateur dans la base de données MyDB, qui est membre de db_datareader.

Je puis essayé de créer un déclencheur d'ouverture de session avec le TSQL suivant:

CREATE TRIGGER CheckUser
ON ALL SERVER
AFTER LOGON AS
BEGIN
IF APP_NAME() <> 'My Application Name'
    BEGIN
        EXECUTE AS LOGIN = 'myapp_reader' WITH NO REVERT
    END
END

Mais malheureusement, cela ne fonctionne pas. Lorsque je tente de me relier l'erreur suivante:

  

Échec de la connexion pour la connexion « MyComputer \ MyWindowsUsername » en raison de l'exécution de déclenchement.
  nouveau contexte de base de données « maître ».
  Modification du paramètre de langue à us_english. (Microsoft SQL Server, erreur: 17892)

Et quand je regarde dans le journal des erreurs, il dit:

  

Erreur: 15590, gravité: 16, état: 1.
  Ne peut utiliser les options « Non Revert » ou « Cookie » avec la mention « Exécuter En tant que » au niveau adhoc.
  Erreur: 17892, gravité: 20, état: 1.
  Échec de la connexion pour la connexion « MyComputer \ MyWindowsUsername » en raison de l'exécution de déclenchement. [CLIENT: xxx.xxx.xxx.xxx]

Est-ce que cette erreur signifie que je ne peux pas changer de façon permanente le contexte d'exécution dans le déclencheur d'ouverture de session?

Answer 1

Je ne pense pas il est possible de changer le contexte d'exécution pour toute la session. Vous pouvez créer un déclencheur DML pour INSERT, UPDATE et DELETE pour chaque table / vue dans votre base de données qui fait un retour en arrière pour un certain app_name (). Vous pouvez écrire une procédure pour automatiser la création de tous ces éléments déclencheur.

Par ailleurs, si vous avez eu la possibilité d'avoir des applications telles que Excel se connectant via un serveur lié, vous pouvez alors changer le contexte d'exécution à ce stade. Et créer un déclencheur d'ouverture de session qui restaure la connexion si les utilisateurs tentent une connexion via Excel ou d'autres applications directement sur le serveur.

Answer 2

En supposant que vous avez le contrôle de l'application et peut le modifier, puis des rôles d'application feront exactement ce que vous voulez. Voir sp_setapprole dans la documentation en ligne pour commencer.

Answer 3

Vous ne pouvez pas le faire de la façon que vous voulez.

• Une connexion utilisateur a les mêmes informations d'identification tout au long sauf pour certains spécifiques scopes utilisant EXECUTE AS.
• Vous avez réalisé que vous ne pouvez pas compter sur APP_NAME () ou HOST_NAME () pour détecter quand quelqu'un différemment Connects, ce qui signifie un déclencheur de baisse de prix par table ne peut pas compter là-bas
• Votre application repose sur l'accès en écriture de table directe

Quelques options que je peux penser à ...

• Votre utilisation d'applications stockées procs, les utilisateurs ont un accès en lecture seule aux tables
• Utilisez SET CONTEXT_INFO dans votre application pour définir une clé "secret" pour rollback déclencheurs
• Changer votre application pour utiliser un compte de service / est un service Windows / etc et proxies le nom d'utilisateur dans (comme une page Web ferait)
• ... ou quelques permutations LEURS

Answer 4

Vous avez vraiment besoin de faire votre esprit sur la façon d'organiser et de gérer les informations d'identification d'abord.

Si vous utilisez sp_setapprole qui contourner l'authentification Windows et autoriser l'accès via cette application pour tous les utilisateurs. Si c'est ce que vous voulez vraiment faire alors si l'application est un serveur créer un compte utilisateur pour cette application et l'exécuter sous les informations d'identification de cet utilisateur.

Si c'est une application client puis faire un service Web qui ne liront et envoyer des données particulières que les besoins d'applications et exécuter ce service Web sous un nouveau compte. Puis, en IIS7 vous pouvez mettre un ACL sur le service Web lui-même afin qu'il soit toujours protégé.

Aussi, si cette application n'est pas digne de confiance pour être propre et de savoir ce qu'il fait demander alors qu'il doit être examiné le code avant qu'il ne soit autorisé à toucher serveur SQL. Si c'est votre propre application puis commencer à vous faire confiance: -)