Vous avez deux alternatives :
-
Contrôle cryptographique. Avec cela, seuls les utilisateurs qui connaissent le mot de passe peuvent déchiffrer les données. L'inconvénient est que l'utilisateur doit saisir le mot de passe de déchiffrement chaque fois qu'ils accèdent aux données. Un rapport devra contenir un paramètre de mot de passe que l'utilisateur exécutant le rapport remplit avec le mot de passe d'accès aux données. L'application doit demander le mot de passe à l'utilisateur. Les sites Web doivent demander un mot de passe au visiteur. Et ainsi de suite
-
Contrôle d'accès. Les données sont cryptées avec une clé à laquelle SQL Server lui-même a accès (en fin de compte, la chaîne de cryptage va jusqu'à la clé principale du service et celle-ci est cryptée à l'aide de DPAPI). Cela ne vous donne pas plus de protection autre que l'octroi et le refus de SELECT vous donnerait :est l'accès contrôle, pas de contrôle cryptographique. Un tel schéma protège uniquement contre la perte accidentelle de supports (quelqu'un trouve un disque avec votre base de données, ou vous perdez un ordinateur portable avec la base de données dessus). Vous pouvez obtenir le même résultat en utilisant chiffrement transparent des données ou chiffrement au niveau du fichier (BitLocker ).
Le scénario de chiffrement de données courant consiste à chiffrer les données avec une clé symétrique, puis à chiffrer la clé symétrique avec une clé asymétrique (généralement la clé privée d'un certificat). La clé asymétrique est alors à son tour chiffrée avec un mot de passe, et ce mot de passe doit être présenté lors d'une tentative d'accès aux données. La principale raison de cette indirection à deux niveaux est le changement de mot de passe :lorsqu'un mot de passe ou une clé privée est compromis, la clé symétrique est rechiffrée avec une clé asymétrique différente ou la clé asymétrique est rechiffrée avec un mot de passe différent. De cette façon, le mot de passe d'accès a changé sans nécessiter un rechiffrement de toutes les données . Si l'accès était accordé directement à la clé symétrique, un compromis de mot de passe nécessiterait éventuellement de rechiffrer toutes les données , téraoctets de données possibles.
Là où les deux scénarios que j'ai présentés diffèrent, c'est si la clé asymétrique est également chiffrée avec la clé principale de la base de données ou non. Cas 1) ce n'est pas le cas, cas 2) c'est le cas. Tout cela est expliqué dans Hiérarchie de chiffrement .
