Actuellement une de nos bases de données (SQL Server 2008) est accessible via un certain nombre de mécanismes différents: fournisseur de données SQLClient; SQL Server Management Studio; Diverses applications .NET et 2007 Système Microsoft Office (essentiellement Excel).
Je vois que dans le SYS.DM_EXEC_SESSSIONS DMV, il est possible de voir le nom du programme du programme accéder à la base de données pour les sessions en cours. Ma question est la suivante: est-il possible de refuser l'accès d'un programme nommé particulier? Le premier prix serait si cela pouvait être fait pour tout programme nommé, mais nous économiserions beaucoup de bénéficier de refuser l'accès à cette base de données spécifique à partir de toutes les applications Microsoft Office (en particulier Excel).
6 Réponses :
juste curieux ... Pourquoi ne délivrez-vous pas différents identifiants d'utilisateur et mots de passe à chaque application et restreindre l'accès de cette façon? Je sais que cela ne répond pas à votre question exactement, mais je pense que c'est l'approche préférée.
Mais que se passe-t-il si un utilisateur utilise l'un des programmes approuvés et Excel? Comment ne faites-vous qu'un seul travail
@Mark: Tu ne le fais pas. Le serveur ne se soucie pas de l'application de l'application. Il ne se soucie que de ce que l'utilisateur est et quels sont leurs droits d'accès. Pourquoi voulez-vous arrêter Excel?
Parce que c'est la question de l'OP. J'ai vu ODBC Accès d'Excel verrouille d'autres applications
@Mark: en quelque sorte je vous ai mélangé avec l'op.;)
J'ai vu ce problème dans la production - un utilisateur peut utiliser Excel pour créer peut exécuter SQL arbitraire, y compris des jointures croisées massives qui a) sous tables de verrouillage ODBC et B) Prenez beaucoup de processeur de serveur. Tandis qu'une application peut contraindre les requêtes
C'est définitivement l'une des préoccupations que nous avons. Nous savons, par exemple, que certaines feuilles de calcul existent il y a de nombreuses années avec le code VBA (non protégé par mot de passe) contenant des informations d'identification privilégiante élevées. Essayer de localiser toutes ces feuilles de calcul portent un risque (comment pouvons-nous garantir que tous ont été localisés) et changer les informations de connexion comportent des risques (temps pris pour localiser et modifier toutes les applications à l'aide de ces informations d'identification). Si nous étions en mesure de bloquer tout simplement tout accès Excel (vérification idéale des tentatives de connexion infructueuses, suivies à des hôtes spécifiques), alors cela aiderait grandement.
Généralement, vous passez l'inverse. Créez un ensemble de login qui ont des droits d'accès spécifiques, utilisez ensuite ces connexions dans les applications correspondantes.
Si vous avez simplement une seule connexion partagée .. Eh bien, ce n'est pas un environnement très sécurisé et vous vous retrouvez avec tout le monde ayant accès à ce qu'ils veulent.
Le mécanisme que vous pouvez utiliser pour cela est "Rôles d'application". Lors de la connexion d'une application, vous supposez un rôle particulier et que ce rôle est accordé des privilèges. Donc, toutes les applications se connectent via ce mécanisme et ne donnent pas de connexions SQL ou NT pour une utilisation non autorisée.
voir http://technet.microsoft.com/en-us/ Bibliothèque / MS190998.aspx
-krip
Merci. Je conviens que comme une solution à plus long terme, c'est probablement la direction que nous devrions nous diriger. Actuellement, le problème que nous sommes confrontés est que nous avons un ensemble inconnu d'Excel Adines qui accèdent à une base de données spécifique, à l'aide d'un ensemble inconnu d'informations d'identification. Nous ne pouvons pas désactiver les informations d'identification car ces autres applications les utilisent valablement pour se connecter. Nous souhaitons progresser vers un modèle de «pas d'accès Excel à la base de données» dans le cadre d'une initiative plus large visant à réduire la dépendance à l'échelle de l'environnement sur Excel
Si vous souhaitez limiter un accès utilisateur via une application, utilisez SSPI.
Si vous souhaitez uniquement restreindre l'application, utilisez l'impersonnation SQL Server et créez un compte pour cette application très.
De cette façon, une fois que vous ne souhaitez plus que cette application ait accès à votre serveur, vous venez de le supprimer du rôle.
En supposant que vous créez un rôle spécifique pour les applications, etc.
Il peut être utile de savoir exactement pourquoi vous voulez faire cela. Je suppose que cela ne concerne pas les raisons de sécurité, car un tel système serait assez facile à contourner.
Êtes-vous préoccupé par Excel et d'autres applications consommant une quantité disproportionnée de ressources de serveur? Si tel est le cas, jetez un coup d'œil au Fonction Gouverneur de ressources ajoutée dans SQL Server 2008. L'idée de base est que vous créez une fonction pour classer les nouvelles sessions en groupes, puis associer ces groupes avec des pools de ressources lorsque l'utilisation de la mémoire ou de la CPU (ou les deux) peut être étranglée lorsqu'il y a contenté.
Cela fait partie d'une initiative plus large visant à réduire la dépendance à l'utilisation d'Excel dans l'ensemble de l'organisation et à respecter certaines réglementations de conformité qui sont entrées en vigueur. Le principal problème que nous sommes confrontés est que nous ne sommes pas en mesure d'indiquer clairement ce que l'ensemble actuel des feuilles de calcul accessibles à la base de données est (grande organisation, de nombreux sites, etc.)
Il est Bien que vous puissiez vérifier le nom de l'application et créer des déclencheurs de connexion qui refusent des connexions basées sur cette propriété, l'application Le nom n'est pas une propriété sécurisée et peut être facilement forgé par quiconque. La dépendance à ce sujet pour la sécurité (c.-à-d. Le déni de connexion) est #fail. Aussi tant que vous abaissez votre barre et supprimez les termes comme "refuser l'accès" de votre question, est possible de fournir un Déclencheur de connexion qui inspecte le nom_fr.Name du programme de la session dans Le nom de programme est défini par certaines applications, je ne sais pas Is Office Suite définit cette propriété à quelque chose de utile ou de laisse la valeur par défaut . Et vous devez comprendre que cela peut être contourné par n'importe qui en modifiant simplement le ApplicationName propriété de la chaîne de connexion. sys.dm_exec_sessions :
Merci pour cette réponse - cela réactive exactement ce dont nous avons besoin à l'heure actuelle, ce dont nous avons besoin pour fournir un mécanisme temporaire pour refuser l'accès des tableurs Excel existants et nous aider à vous connecter à ce que cet accès provienne de sorte que nous puissions identifier ces feuilles de calcul existantes, puis Déplacez-vous vers la création de meilleurs moyens d'accéder à cette base de données particulière (création essentiellement des applications .NET pour remplacer la fonctionnalité héritée).
Je vous lisez d'autres messages et cela semble bien utiliser pour cela, suivez les applications hérités et les fichiers et éliminez-les comme ils apparaissent. Je choisis mon verbage (plutôt abrasif) juste pour vous assurer que personne d'autre ne revienne dans deux mois et que vous voyez cette réponse et dit 'hé, je peux l'utiliser pour sécuriser mon application!'
C'est parfait. Avoir besoin de refuser l'accès à la masse à un groupe d'applications Legacy que nous remplaçons. Cela nous a aidés à trouver qui les utilisait alors que nous avons reçu un courrier électronique à ce sujet sans fonctionnement et nous pourrions les mettre à jour rapidement.
Cette requête manque un support de fermeture. Il devrait être: si existez (sélectionnez * à partir de sys.dm_exec_sessions où session_id = @@ Spid and Program_Name In (N'BAD Programment ', N'Worse Programment', N'unmentialable ')))
Utilisez-vous l'authentification AD?
Juste une tête de tête, mais le nom du programme n'est pas garanti d'être précis, par exemple si vous utilisez OLEDB pour vous connecter, vous pouvez le faire tout ce que vous aimez avec
; nom de l'application = xxxxx il s'agit pour ODBC.Authentification en mode mixte - Des éléments plus récents se connectent à l'aide de l'authentification Windows, mais il existe une grande quantité d'applications, etc. qui se connectent à l'aide de l'authentification SQL Server.
À Sybase et Oracle, j'ai eu des serveurs que nous n'avons pas installé les catalogues ODBC, arrêt de ODBC et TUS Excel - Cependant, je ne suis pas certain ADO.NET et SQL Server peut fonctionner sans ces