Est-ce généralement une mauvaise idée de crypter les champs de la base de données?
Je travaille dans une petite entreprise, c'est littéralement moi (le programmeur) et le propriétaire. Le propriétaire m'a demandé de crypter plusieurs champs dans une base de données pour protéger les données des clients. Il s'agit d'une application Web qui aide les cabinets d'avocats à gérer leurs données.Elle stocke donc essentiellement des informations sur les personnes et les poursuites (qui est poursuivi, pourquoi, pour combien). Il considère ces informations sensibles qui ne devraient pas être facilement visibles. Sa crainte est "Je ne veux pas que des personnes non autorisées voient ces informations". Seuls d'autres cabinets d'avocats pourraient être intéressés par ces données, donc cela ne devrait pas être aussi important que les cartes de crédit, par exemple.
J'ai beaucoup lu à ce sujet sur le Web et je pensais simplement utiliser un cryptage symétrique sur ces champs, afin que les performances ne soient pas si mauvaises. La clé serait stockée sur le serveur. Cependant, this thread sur stackoverflow dit que c'est une mauvaise idée.
Je ne comprends pas comment le cryptage des champs et la sauvegarde de la clé sur le serveur peuvent être si inutiles. Je ne crains pas que les disques soient volés car ils sont sur Amazon EC2. Je ne suis pas un expert en sécurité, mais à mon avis, si quelque chose pouvait mal tourner, je dirais que la base de données fuit. Même alors, les informations importantes seraient cryptées. Maintenant, si le gars réussissait même à pirater mon serveur EC2, eh bien, je suppose qu'il n'y aurait que peu ou pas de protection que je pourrais faire pour aider cela. Comme nous sommes une toute petite entreprise, nous n'avons qu'un seul serveur qui fait tout, de la diffusion des pages au stockage des données.
Ma question est, étant donné que nous ne pouvons nous permettre qu'un seul serveur, est de crypter ces champs avec une clé symétrique, qui est enregistrée sur ce serveur, d'accord?
Commentaires généraux. Il semble qu'il serait utile pour vous et votre patron d'apprendre quelques concepts de sécurité de base avant de continuer. La sécurité est un domaine spécialisé. Vous ne demanderiez pas à une personne au hasard dans la rue de vous opérer à cœur ouvert; et vous ne devez pas vous attendre à ce qu'un développeur de logiciel moyen sache comment sécuriser vos systèmes.
Je sens quelques idées fausses ici. Par exemple, il semble que votre patron ait assimilé la sécurité à la cryptographie. Mais c'est une erreur. Comme Bruce Schneier l'a souligné, La cryptographie n'est pas une poussière de lutin magique que vous pouvez saupoudrer sur un système pour le sécuriser . Et comme Roger Needham l'a dit une fois, Si vous pensez que la cryptographie résoudra votre problème, soit vous ne comprenez pas la cryptographie, soit vous ne comprenez pas votre problème .
Lors de la sécurisation d'un système informatique, un concept important est le modèle de menace . Cela signifie que vous devez réfléchir soigneusement aux types d'attaques et d'adversaires que vous essayez d'arrêter et à ce que vous n'êtes pas. Un échec à penser clairement le modèle de menace peut conduire à théâtre de sécurité : des mécanismes de sécurité qui semblent bons à première vue, mais qui sont en réalité terriblement inadéquats dans la pratique. Une bonne gestion de la sécurité se résume souvent à la gestion des risques : une analyse minutieuse des risques les plus graves, puis l'élaboration de stratégies pour atténuer ou gérer ces risques particuliers.
Il est également important de comprendre que la sécurité est une propriété de maillon le plus faible: la sécurité de votre système est aussi forte que le maillon le plus faible . Une vulnérabilité dans une partie du système peut compromettre la sécurité de l'ensemble du système. Cela signifie qu'il n'y a pas de réponse unique qui suffira pour protéger votre système; au lieu de cela, pour défendre votre système, vous devez obtenir la sécurité à plusieurs endroits.
Plonger dans les détails. Il semble que vos objectifs soient d'empêcher la divulgation non autorisée de données sensibles. Si c'est le cas, vous devrez vous concentrer sur un certain nombre d'éléments. Il n'y a pas une seule balle magique magique qui puisse résoudre ce problème pour vous; vous allez devoir travailler sur la sécurité des applications en général.
Permettez-moi de suggérer certaines choses qui devraient être prioritaires pour vous, si j'ai bien compris vos objectifs:
Sécurité des applications. Vous devez commencer à étudier la sécurité des applications Web. Peu importe la quantité de crypto que vous jetez au problème; si un attaquant peut trouver une faille de sécurité dans le code de votre application, vous êtes arrosé. Pour des informations sur la sécurité des applications Web, OWASP dispose de nombreuses excellentes ressources. Assurez-vous de vous renseigner sur le Top Ten OWASP, sur XSS, l'injection SQL, le nettoyage/validation des entrées, l'échappement des sorties, la liste blanche et d'autres concepts.
Contrôle d'accès. Votre application Web doit avoir des contrôles d'accès solides, pour garantir qu'un utilisateur de votre système ne puisse pas accéder aux informations d'un autre utilisateur (sans autorisation). Les détails de cela dépendront des spécificités de votre système particulier, donc si vous voulez une aide supplémentaire à ce sujet, vous devrez probablement poster une question séparée avec plus de détails sur votre application et votre stratégie actuelle de contrôle d'accès.
Authentification. Votre application Web aura besoin d'un moyen d'authentifier ses utilisateurs. Le schéma standard de moindre effort consiste à simplement utiliser un nom d'utilisateur et un mot de passe. Cependant, cela a de sérieuses limites dans la pratique qui sont bien comprises. Si les utilisateurs choisissent leurs propres mots de passe, ils choisissent souvent de mauvais mots de passe, ce qui peut nuire à la sécurité de votre système.
Cycle de vie de développement logiciel sécurisé. Vous devez intégrer la sécurité dans le processus de développement logiciel. Lorsque vous élaborez l'architecture logicielle, vous devez penser aux exigences de sécurité et effectuer une modélisation des menaces et une analyse des risques architecturaux. Lors de l'écriture de code, vous devez connaître les erreurs d'implémentation courantes qui peuvent porter atteinte à la sécurité et assurez-vous de les éviter. Une fois le logiciel créé, vous devez tester sa sécurité et évaluer en permanence vos performances en matière de sécurité. Lorsque vous déployez le logiciel, vos opérateurs doivent savoir comment le gérer en toute sécurité. Microsoft dispose d'excellentes ressources sur le cycle de vie de développement logiciel sécurisé (SDL). Voir aussi BSIMM pour plus.
Évaluation de la sécurité. Si vous êtes préoccupé par la sécurité, je suggère de faire évaluer la sécurité de votre application. Un simple point de départ pourrait être de demander à quelqu'un d'effectuer une analyse approfondie de votre application Web pour vérifier certains types d'erreurs courantes. Ce n'est en aucun cas une garantie de sécurité, mais parfois, cela peut aider à servir de réveil en cas de nombreux problèmes majeurs. Vous pourriez regarder les services de WhiteHat Security; il existe également de nombreux autres qui effectueront des pentestings sur le Web.
Si vous avez l'impression que ce n'est pas une entreprise insignifiante, je m'excuse, mais c'est effectivement le cas. D'un autre côté, la bonne nouvelle est qu'il existe de nombreuses ressources, et de plus, vous n'avez pas besoin de devenir un gourou de la sécurité de niveau expert: il vous suffit de vous familiariser avec certains concepts de base et une sécurité commune des erreurs dans la programmation Web, et cela répondra à la plupart de vos besoins.
Le cryptage des données dans la base de données protégera les informations si la base de données est en quelque sorte volée. Mais, il ne fera rien pour protéger contre le site Web attaqué. Par exemple, en devinant un nom d'utilisateur/mot de passe. Cela peut ralentir quelqu'un s'il a compromis le serveur car il doit trouver la clé mais cela ne l'arrêtera pas. Il a également un prix potentiellement élevé. Par exemple, les champs chiffrés ne peuvent plus être recherchés de manière efficace. Vous devez également être conscient des implications de la sauvegarde et vous assurer que la clé est sauvegardée, de préférence séparément dans les sauvegardes de la base de données pour éviter que la base de données ne soit décryptée si une bande de sauvegarde est volée. ET vous devez vous assurer que vous disposez de plusieurs copies de la clé et les tester régulièrement.
Un bon concept de SoA est d'avoir un service de chiffrement, fonctionnant de manière isolée des autres processus sur votre serveur (votre application Web devrait également fonctionner de manière isolée!). Ensuite, lorsque vous devez crypter/décrypter un objet/champ, vous envoyez du texte en clair/cryptage au service de cryptographie et vous êtes renvoyé avec crypttext/texte en clair. De cette façon, même si votre application Web est compromise, l'attaquant ne peut pas lire la clé de chiffrement, car seul le service de chiffrement connaît la clé. De plus, comme votre application Web est isolée, ce qu'il pourrait faire sur votre système est très limité. L'isolement des services se fait généralement avec un système MAC comme SElinux, TOMOYO (beaucoup plus facile à utiliser que SElinux imo), AppArmor. Je recommanderais également d'exécuter le dernier noyau Linux corrigé avec grsecurity.
Réponse courte: Oui, utilisez un cryptage symétrique. Cela empêchera certaines attaques comme la lecture de données SQL via l'injection SQL. Cependant, si votre application Web est attaquée, cela n'a pas d'importance. Si quelqu'un a suffisamment accès à votre serveur, vous ne pouvez pratiquement rien faire. Même avec un cryptage asymétrique.