Discussion :

[papouAlain]

Je developpe une application en .NET basée sur une DB MSDE.
Cette DB met en oeuvre beaucoup de SP.
Le client demande que le fichier soit protégé contre les pertes de confidentialité et de savoir faire métier que recelent ces SP.
Comment puis-je faire en sorte pour que le fichier MDF ne puisse être lu que par mon application ?.
Dans l'idéal il faudrait qu'aucune application autre que celle ayant les droits ne puisse lire la moindre donnée, c'est à dire que Entreprise Manager (ou tout autre outil de Design SQL Server) ne puisse également accéder au MDF qu'en respectant la même règle que l'application cible.
J'ai déjà donné au serveur MSDE un nom d'instance et un password, mais ça ne semble pas protéger contre Entreprise Manager qui de toute façon arrive à y accéder avec la gestion des droits Windows...
I Need some Help...

[Fabien Celaia]

Il n'y a pas de trigger sur connexion dans MS-SQL...
Il y a toujours la possibilité "bidouillée" de vider la table syscomments...
Vious pouvez tout protéger, mais pas pour un system admin !

[papouAlain]

Est-ce que en définissant :
- un rôle application (avec password) <> public
- un Utilisateur <> dbo (ayant le rôle précédemment défini).

dans la mesure ou j'ai déjà défini une instance nommée de MSDE (<> instance par défaut) ayant son propre SQL Password.

un utilisateur de Entreprise Manager ne pourra y enregistrer mon serveur que s'il connait mon Password : Comment peut-il l'obtenir ?

en imaginant qu'il le trouve ou qu'il instancie un autre serveur auquel il souhaite attacher ma base de données, il devra spécifier un propriétaire de la base de données (c'est à dire l'utilisateur que j'ai défini précédemment et qui est protégé par un second password) :
Comment peut-il l'obtenir ?

S'il indique que le propriétaire de la base de données est sa :
Est-ce qu'il pourra attacher puis ouvrir cette base de données?

[SQLpro]

Il n'y a AUCUNE solution à votre problème autre que d'utiliser les droits systèmes. Autrement dit placer votre MSDE sur un serveur et gérer des droits au niveau système et des privilèges SQL. Cela n'empêchera nullement un quelconque administrateur de domaine de faire ce qu'il veut des fichiers de la base.
Quand à EM, c'est un outil d'administrateur SGBDR. Il est donc parfaitement normal qu'il accède à votre serveur. On ne peut l'en empêcher (et heureusement car en cas de perte du mot de passe c'est le seul moyen), sauf à le supprimer des postes ou il est installé.

La première des sécurités consiste à responsabiliser le personnel.

A +

[papouAlain]

La première des sécurités consiste à responsabiliser le personnel.

Tu semble considérer que la seule implémentation d'une base de données SQL Server serait une base entreprise, avec un administrateur et des postes clients.
Ce n'est pas du tout l'objet de cette application qui est déployée dans des très petites structures et très souvent sans adminsitrateur digne de ce nom (c'est un peu le marché de MSDE non ?).
Le client (qui va commercialiser l'application) souhaite seulement ne pas retrouver sa base de données exploitée par des application concurrentes sur SON marché... (il a investi dans un design qu'il souhaite ne pas offrir aux "bricoleurs".

[Fabien Celaia]

Quand à EM, c'est un outil d'administrateur SGBDR. Il est donc parfaitement normal qu'il accède à votre serveur. On ne peut l'en empêcher (et heureusement car en cas de perte du mot de passe c'est le seul moyen), sauf à le supprimer des postes ou il est installé.

EM n'est qu'un outil graphique client. Tout ce que l'on peut faire avec EM (et bien plus) peut être fait sans, en ligne de commande...

[elsuket]

Bonjour,

Il n'y a pas de trigger sur connexion dans MS-SQL...

Si, mais dès SQL Server 2005

@++