Secure SQL Server accessible par un gros client

Existe-t-il un moyen de sécuriser une database SQL Server à laquelle accède un gros client? Signification: L'application communique directement avec la database car elle place elle-même les instructions sql. Cela signifie que la string de connection doit être quelque part sur le client. En utilisant cette string de connection (soit avec l'authentification du server winauth ou sql) n'importe quel user peut accéder à la database en utilisant un studio de gestion ou une command line et placer différentes instructions sur la database.
Que faire à ce sujet? Je ne peux pas placer une autre couche entre le client et la database car cette architecture est corrigée.

Dans tous les templates de security, y compris Windows et l'authentification SQL, les droits d'access sont accordés à un user (une identité) et non à une application. par conséquent, tout droit d'access requirejs par l'application doit être accordé à l'user exécutant l'application. Lorsque l'authentification Windows est utilisée, cela signifie que le même user peut tirer parti de tous les privilèges requirejs par l'application elle-même, à partir d'une requête SSMS. C'est une règle fondamentale que tout administrateur doit comprendre. Du sharepoint vue de la security (ce qui signifie des choses comme la conformité CC et autres), c'est un fait et toute tentative pour le contourner est condamnée.

Mais d'un sharepoint vue pratique, certaines mesures peuvent être déployées. Le plus couramment utilisé consiste à utiliser un triggersur d'ouverture de session qui valide APP_NAME() et autorise l'access à SSMS uniquement à partir d'un set bien défini de stations de travail client et pour un set d'users bien défini.

 CREATE TRIGGER reject_SSMS ON ALL SERVER WITH EXECUTE AS '...' FOR LOGON AS BEGIN IF (APP_NAME() = 'Microsoft SQL Server Management Studio' OR APP_NAME() = 'Microsoft SQL Server Management Studio - Query') AND (ORIGINAL_LOGIN() NOT IN (...) OR HOST_NAME() NOT IN (...)) ROLLBACK; END;

Ce qui est important de comprendre que de tels mécanismes ne sont pas des fonctionnalités de security, car ils peuvent être facilement contournés par un user malveillant. Ils ressemblent plus à des serrures de porte: ils n'empêchent pas les voleurs, ils gardent honnêtes les users honnêtes.

C'est ce que les permissions SQL Server sont pour.

Vous pouvez, par exemple, accorder des permissions à un user dans une vue ou une procédure stockée sans accorder à l'user des permissions sur les tables sous-jacentes.

Vous pourriez vouloir regarder dans les rôles d'application

http://msdn.microsoft.com/en-us/library/ms190998.aspx

http://www.sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/

Tout d'abord, l'intérêt d'une vulnérabilité SQL Injection est que l'attaquant est capable de manipuler les requêtes. Ce protocole proposé est une vulnérabilité encore pire. Mais ce n'est pas seulement une violation flagrante de CWE-602: l'application côté client de la security côté server et CWE-603: l'utilisation de l'authentification côté client .

Pour sécuriser cela, vous devez effectuer les opérations suivantes:

Chaque user doit également avoir sa propre database verrouillée. Comme ils ont seulement select / update / delete / insert et aucun autre privilège ( surtout pas xp_cmdshell () !!!! ). Vous ne pouvez pas autoriser les users à partager une database, ou un attaquant pourra voir les informations d'autres users. Un attaquant sera toujours capable d'get le nom d'user / mot de passe pour le server SQL et de se connecter directement avec son propre client. Il est difficile de penser que cette relation soit sûre, dans presque tous les cas, c'est une vulnérabilité massive.

En réalité, il s'agit d'une faille architecturale très sérieuse et vous devez build un composant côté server qui construit des cahiers pour le client. Ceci est généralement fait avec SOAP (wcf pour les plateforms ms).