Les fichiers MDF SQL Server 2005 sont-ils sécurisés? (re: security)

Question

Nous avons commencé à utiliser SQL Server 2005 Express pour un projet et j'ai remarqué que chaque base de données possède ses propres fichiers MDF/LDF. Chaque fois que nous avons besoin de dupliquer notre base de données (vers un autre serveur SQL), nous copions simplement ces fichiers, puis les attachons à la base de données.

Cependant, cela m'interroge sur la sécurité de ces fichiers. Si quelqu'un de l'extérieur en obtient une copie, est-ce qu'ils sont chiffrés ou peuvent-ils simplement les joindre comme je le fais? Je ne suis pas invité à entrer un mot de passe lorsque je le copie/attache moi-même, donc je suis un peu nerveux.

Merci, John

Answer 1

Ils ne sont pas cryptées et peuvent être chargés/fixés par toute personne ayant un accès en lecture aux fichiers MDF/LDF.

Il existe plusieurs approches possibles pour protéger les fichiers MDF réels. (Cela suppose que l'utilisation simple des autorisations de fichiers pour verrouiller l'accès est impossible, par exemple si vous devez protéger contre les utilisateurs avec des droits d'administrateur sur la machine ou l'accès disque dur direct.)

1. Utilisez EFS ou BitLocker ou similaire crypter les fichiers eux-mêmes. Cela ne protégera pas contre les autres applications dans la même session/contexte d'accès aux fichiers, mais protégera contre les autres comptes accédant aux fichiers (EFS) ou quelqu'un volant un ordinateur portable/disque dur (EFS/BitLocker).
2. Chiffrez les données sensibles dans la base de données elle-même. Vous souhaiterez évidemment stocker la clé de cryptage séparément (en utilisant éventuellement DPAPI pour la protéger, par exemple). SQL Server 2008 Enterprise Edition introduit une fonctionnalité appelée Chiffrement de base de données transparent (TDE) pour faciliter ce processus, ce qui, malheureusement, n'aide pas beaucoup pour 2005 ou Express Edition. Votre meilleure option dans ce cas pourrait être de faire un cryptage personnalisé des données sensibles dans votre application. (Malheureusement, en 2005, cela nécessitera l'utilisation de champs varbinaires ou de valeurs cryptées codant en Base64, etc.)
3. Ne stockez pas les données localement en premier lieu (c'est-à-dire, utilisez un serveur SQL distant plutôt qu'une instance Express locale). Cela ne résout pas vraiment le problème, mais il le réduit (il suffit de protéger l'instance distante plutôt que N copies locales/express).