2008-09-29 7 views
7

J'ai un site Web ASP .NET 2.0 connecté à une base de données SQL Server 2005. Le site est assez simple et stocke des informations sur le personnel, y compris le salaire. Quelle est la meilleure façon de chiffrer la valeur salariale afin que personne (y compris moi-même) ne puisse jamais voir ce que c'est, sauf pour le personnel autorisé qui utilise l'application Web?Cryptage Valeur salariale dans ASP .NET 2.0 et SQL Server 2005

Je ne veux pas crypter/décrypter sur SQL Server parce que je pourrais simplement exécuter SQL Profiler pour afficher les informations, donc je suppose que le cryptage/décryptage se produit dans le BLL sur le serveur Web?

De plus, ai-je besoin de SSL pour empêcher quelqu'un de renifler des réponses HTTP entre le navigateur et le serveur Web?

Un grand merci!

Anthony

Répondre

4

SSL est probablement votre meilleur pari pour empêcher quelqu'un de renifler, mais sachez qu'il est encore possible. En ce qui concerne l'autre bit, SQL Server 2005 prend en charge le chiffrement au niveau de la table immédiatement. Here's an article on it. Vous pouvez créer une table SALARY liée à un employé et conserver cette table chiffrée.

2

Il existe de nombreuses méthodes de chiffrement que vous pouvez utiliser ici dans votre code. Assurez-vous de choisir celui qui prend une clé et un «sel» (par opposition à simplement utiliser la même clé à chaque fois). Si vous utilisez la même clé (sans sel) chaque fois que vous cryptez un salaire, deux employés ayant le même salaire afficheront la même valeur cryptée dans la base de données, compromettant ainsi la sécurité de l'information sur le salaire.

Vous pouvez utiliser l'ID unique de chaque employé comme sel.

+0

La méthode de chiffrement ne doit pas prendre de sel ... le sel peut simplement être ajouté aux données. –

+0

aussi, un sel qui peut facilement être compris est comme aucun sel du tout. Les sels aident à ralentir une attaque par force brute de la table arc-en-ciel, mais seulement légèrement. Si la puissance parallèle est suffisante, la plupart des techniques de cryptage peuvent être forcées par la force si quelqu'un le veut. – stephenbayer

+0

Il s'agit de ne pas en faire l'effort. –

2

Vous avez certainement besoin de SSL pour empêcher le reniflement du trafic Web sensible (sans mentionner les connexions), mais cela ne résout pas votre problème de chiffrement côté serveur. Pour que le développeur ne puisse pas accéder aux données, il est difficile de se fissurer. Pour que cela fonctionne vraiment, tout le cryptage/décryptage doit être fait uniquement sur les machines auxquelles vous n'avez pas accès. Théoriquement, vous devrez créer une sorte d'extension de navigateur qui déchiffre les données salariales sur les machines clientes. Votre employeur devrait vous faire suffisamment confiance pour ne pas mettre une porte dérobée dans le code côté client (ou du moins tenir la possibilité d'un audit de code sur votre tête).

Dans la plupart des cas, il est plus facile de faire confiance au développeur pour ne pas divulguer les données. C'est une bonne idée de le garder sur la base du besoin de savoir, mais finalement certaines personnes ont besoin de savoir. (Par exemple, les gens de la comptabilité voient les données salariales tout le temps.)

2

Vous voulez absolument utiliser SSL pour la sécurité du transport. Vous pouvez également configurer IPSec pour le transport entre le serveur Web et le serveur de base de données.

En ce qui concerne la sécurisation dans la base de données, SQL Server 2005 dispose de plusieurs fonctions de chiffrement:

1) EncryptByAsymKey - http://msdn.microsoft.com/en-us/library/ms186950.aspx
2) EncryptByKey - http://msdn.microsoft.com/en-us/library/ms174361.aspx
3) EncryptByPassPhrase - http://msdn.microsoft.com/en-us/library/ms190357.aspx
4) EncryptByCert - http://msdn.microsoft.com/en-us/library/ms188061.aspx

De toute évidence, tous ceux-ci ont une fonction de décryptage associée.

Vous pouvez stocker la clé ou tout ce que vous choisissez sur le serveur Web (dans le fichier machine.config ou web.config ou ailleurs) et ensuite le transmettre à vos procédures stockées (ou avec votre SQL en quelque sorte) pour le cryptage.

3

Les développeurs de la webapp peuvent toujours accéder aux chiffres de salaire - tout est une question de confiance. Pour contrer cela, vous pouvez passer au modèle où le cryptage/décryptage se passe du côté du client, mais c'est plus encombrant et toujours pas sécurisé à 100%. La sécurité est toujours un compromis avec la commodité.

Vous devez utiliser TLS/SSL (c'est-à-dire, HTTPS) pour que l'écoute indue sur le trafic HTTP soit plus difficile à effectuer.

Une attaque que vous pouvez envisager consiste à remplacer votre propre chiffre de salaire chiffré par celui de la personne qui vous intéresse, puis à appeler le service de comptabilité et à demander quel est votre salaire actuel. Une façon d'annuler l'attaque consiste à faire référencer le contenu du champ de salaire chiffré à la personne à laquelle il appartient.