Je développe une nouvelle application Web à l'aide de .NET 3.5 et SQL Server 2008 qui devra stocker des numéros de sécurité sociale. Je fais une lecture initiale sur le cryptage de la base de données et c'est un peu déroutant.
Je serais agréable de chiffrer les SSN à l'aide d'une clé asymétrique, car cette façon, l'application du public ne serait pas en mesure de récupérer l'une des données une fois qu'elle a été cryptée. Je pensais que seule l'interface d'administration serait capable de déchiffrer et d'afficher les données. Mais il semble que SQL Server protège uniquement les données à l'aide d'une clé symétrique?
Alors, quelle est la meilleure façon de chiffrer les SSNS dans SQL Server 2008? Points bonus Si vous liez un bon tutoriel ou deux.
3 Réponses :
Si vous chiffrez des données, vous devez vous demander qui va le déchiffrer. Si vous utilisez un système de cryptage asymétrique (E.G. RSA), le cryptage utilise la clé publique et le décryptage utilise la clé privée correspondante; "Asymétrie" vient du fait que la clé privée ne peut pas être recalculée de la clé publique (bien que les deux clés soient liées mathématiquement reliées).
Le cryptage asymétrique a tendance à avoir des frais généraux. Une première remarque est que ce cryptage doit avoir une partie aléatoire en elle, car tout le monde peut crypter (la clé publique est, oui, publique): si le processus de cryptage est déterministe, tout le monde peut chiffrer tous les SSN possibles (il y a moins d'une milliards d'entre eux, qui est un très petit nombre pour un ordinateur moderne) et correspond à la valeur cryptée. Par conséquent, il doit y avoir des ajouts aléatoires pendant le cryptage et le SSN crypté est plus grand que le SSN enable.
Les systèmes de cryptage asymétriques connus utilisent des structures mathématiques qui ont leur propre coût. Fondamentalement, pour le système de cryptage RSA, avec une clé "assez forte", un message crypté aura une longueur d'au moins 128 octets. Certains systèmes de cryptage font mieux; En tenant compte des chemins bien-trodernes de la recherche académique, je pouvais le faire dans 41 octets ou plus (avec el-gamal sur la courbe elliptique NIST K-163). Plus petit semble plus difficile.
Il n'est donc pas étonnant qu'un système de base de données donné n'inclut pas une telle caractéristique par défaut.
Pour votre problème, vous devez d'abord définir (et écrire), aussi clairement que vous pouvez:
Et alors seulement vous vous demandez si le cryptage est un outil approprié pour cela. Le cryptage est bon lorsque l'attaquant envisagé peut avoir la main sur les données brutes et stockées. Cela signifie que l'attaquant a contourné les protections du système d'exploitation. À ce stade, quel que soit le système d'exploitation le sait, l'attaquant le sait également. Si la base de données est hébergée sur une machine et que la machine SSN déchiffrée peut être obtenue, cette machine "sait" comment obtenir les données, de même que l'attaquant ... d'autre part, si l'hôte, si l'hôte Le système d'exploitation de la machine est considéré comme assez résilient, puis le cryptage ne semble pas être nécessaire du tout.
cryptage symétrique sur la base de données peut aborder un problème plus faible, dans lequel l'attaquant obtient une copie du disque dur après . Le système hôte connaît la clé de cryptage symétrique, mais elle ne le connaît que dans la RAM. Un attaquant volant le disque dur n'aura pas cette clé.
Pour répondre au deuxième paragraphe, salage de la SSN sonne comme une bonne idée. Quant au 5ème paragraphe: les données que je veux protéger sont la SSN. Les utilisateurs entreront les données, mais ne le récupéreront pas. Seuls les administrateurs utilisant une application différente pourront lire les données. Quant à votre deuxième paragraphe du dernier paragraphe, il existe toutes sortes de vulnérabilités de sécurité qui apparaissent avec des systèmes qui ne nécessitent pas nécessairement que l'attaquant ait un accès physique à la machine. Dans les deux cas, la clé privée ne serait pas stockée sur le même serveur.
Si vous devez stocker SSNS et que vous souhaitez qu'ils soient cryptés, je vous recommande d'utiliser un mécanisme de cryptage de clé symétrique comme 3DES ou AES. Demandez que la clé de cryptage soit une dérivation de certaines phrases de passage que seuls ceux autorisés à accéder aux données savent et qu'ils doivent entrer chaque fois qu'ils accèdent aux données.
ex: Ne vous inquiétez pas de la base de données elle-même pour effectuer le cryptage (bien que ce soit certainement dans des fonctionnalités telles que TDE ou quel que soit le système d'exploitation hôte, vous exécutez la prise en charge du cryptage complet du disque ou du fichier en tant que mécanisme de sécurité secondaire), plutôt utilisez. Les bibliothèques Crypto intégrées de .NET et quel que soit le langage de programmation que vous utilisez pour lire et écrire sur la DB.
Cela vous donne l'avantage de ne pas avoir à stocker une clé publique et privée ou générer ces clés (ce qui est coûteux en calcul) et qu'ils sont relativement grands, le stockage est donc plus cher (relativement), vous ne le faites pas non plus Vous devez vous inquiéter de la clé comprominée lorsqu'un utilisateur non autorisé gagne d'accès à la machine exécutant votre code (à l'exclusion des attaques MITM survenant lorsqu'un utilisateur entre dans la phrase de la passe). Deuxièmement, il garantit que lorsqu'il a accès à la seule façon dont ils peuvent être déchiffrés, c'est un utilisateur autorisé (connaître le mot de passe). Selon votre budget (temps, effort, ressources), vous pouvez ajouter une authentification multi-facteurs où la clé de cryptage provient à la fois d'une phrase de passe, mais également de jeton que les utilisateurs autorisés auraient comme une carte à puce. Troisièmement, crypter et décrypter les données à l'aide d'un algorithme de cryptage de clé symétrique sera beaucoup plus rapide. (phrase de passe de caractères de plus de 10+) -> SHA-1 => clé.
Avec une clé symétrique, vous n'avez pas besoin de la phrase secrète afin de chiffrer les données? Cela me rendrait plus à l'aise d'avoir quelque chose qui pourrait être utilisé pour déchiffrer les données du côté public des choses.
J'ai supposé que vous n'auriez pas d'API ou de mécanisme pour déchiffrer ces données, à l'exception du côté contrôlé lorsqu'un utilisateur autorisé accède à votre système.
Cela dépend de ce que vous entendez par utilisateur autorisé. Toutes ces choses doivent déjà être protégées par les contrôles d'accès descs stockés normaux, par exemple. Je veux un niveau de sécurité supplémentaire.
Vous ne voulez vraiment pas utiliser de cryptage asymétrique parce que c'est très lent. Vous voulez plutôt protéger une touche symétrique avec une clé asymétrique, puis gardez la clé symétrique pratique. Pour être honnête, je collerais avec ce qui est dans SQL Server plutôt que de concevoir des choses vous-même. Un très bon démarrage est ici ici http://dotnetslackers.com/articles/sql/introductionTosqlserverencyPrypypseTutorial.aspx < / a>
Je pense que je comprends bien la raison de cela si vous avez une grande quantité de données à chiffrer. Je suppose que chaque pièce de données aurait-elle sa propre clé symétrique qui serait ensuite cryptée par la clé publique commune, non? Mais dans ce cas, les SSN ne seraient-ils pas plus petits que les clés symétriques?
Êtes-vous sûr vous devez stocker SSNS? Voulez-vous vraiment cette responsabilité juridique massive sur vos épaules?
Je fais du mieux que je ne peux pas. Mais ce sera un système d'inscription ouvert des avantages et si vous ajoutez une nouvelle personne à charge, les informations SSN sont nécessaires.
Ça a du sens. Assurez-vous simplement que ce n'est pas une situation où quelque chose comme les quatre derniers chiffres ou un hachage à sens unique suffirait.
C'est certainement bon conseil, je pense.