Dois-je crypter les données dans la base de données?

J'ai un client, pour lequel je vais faire une application Web sur les soins aux patients, la gestion des patients, les consultations, l'historique, les calendriers, tout cela à la base.

Le problème est qu'il s'agit de données sensibles, d'antécédents de patients et autres.

Le client insiste pour chiffrer les données au niveau de la base de données, mais je pense que cela va détériorer les performances de l'application Web. (Mais peut-être que je ne devrais pas m'en inquiéter)

J'ai lu les lois sur la protection des données sur les questions de santé (Portugal), mais je ne suis pas très précis à ce sujet (je viens de les interroger à ce sujet, j'attends leur réponse).

J'ai lu le lien suivant , mais ma question est différente, dois-je crypter ou non les données dans la base de données.

Un problème que je prévois dans le cryptage des données, c'est que je vais avoir besoin d'une clé, cela pourrait être le mot de passe de l'utilisateur, mais nous savons tous comment sont les mots de passe des utilisateurs (12345, etc.) et générer une clé que je devrais stocker quelque part, cela signifie que le programmeur, dba, tout ce qui pourrait y avoir accès, des réflexions à ce sujet?

Même l'ajout d'un sel aléatoire au mot de passe utilisateur ne résoudra pas le problème car je peux toujours y accéder, et donc décrypter les données.

Je vérifierais personnellement les lois à ce sujet. Si les données doivent être cryptées, elles doivent être cryptées.

Si vous ne recevez pas de conseils, je viserais à protéger le lien entre le patient et ses données. C'est-à-dire que vous en avez probablement un PatientIDqui est utilisé dans les tableaux de la base de données. PatientIDn'identifie pas un patient, seulement les antécédents médicaux du patient, etc ... Cependant, pour identifier le PatientIDcomme Joe Bloggs vivant à Rua de São Bernardo Lisbonne, je garderais cela dans une BD distincte si je le peux. Utilisez TDE pour les détails personnels du patient et envisagez de le chiffrer en plus de cela à l'aide de clés dans votre application Web.

Bien que le vol de ces données médicales sans les moyens d'identifier les patients soit extrêmement embarrassant, il est peu probable qu'il y ait autre chose que cela. Il existe littéralement des concours en ligne qui utilisent ces données médicales anonymisées.

Avec la séparation des données médicales des données personnelles du patient. Utilisez un ensemble solide de rôles pour limiter le personnel à ce dont il a besoin. À l'exception du personnel médical qui doit traiter directement avec le patient (infirmières et médecins de première ligne), personne ne devrait avoir accès aux deux. Les réceptionnistes n'ont besoin que des données personnelles du patient, le personnel du laboratoire n'a besoin que du dossier médical et du PatientID, les infirmières chirurgicales ne sont actuellement que l'état de santé et le prénom.

Lorsque vous avez identifié chaque ensemble de rôles, visez non seulement à les implémenter dans votre application Web, mais également dans la base de données ainsi qu'une couche de sécurité supplémentaire.

Oui, vous devez crypter la base de données.

Le chiffrement de base des données stockées ("données au repos") est un principe de sécurité généralement accepté, et est probablement imposé par la loi si votre pays a des lois qui protègent les informations personnelles ou de santé.

Nous utilisons SQL Server 2008, nous utilisons donc le TDE de Microsoft; il peut y avoir une solution tierce pour MySQL ou peut-être juste une approche générale de chiffrement de volume (comme TrueCrypt) fonctionnerait (même si je voudrais avoir quelque chose qui a été certifié pour une utilisation avec une base de données).

Si cela est fait correctement, la performance devrait être faible.

Soit dit en passant, le lien que vous avez mentionné (concernant la séparation des informations sensibles) est quelque chose que vous devez considérer en plus du chiffrement de base de la base de données.

EDIT: Le cryptage mentionné ci-dessus crypterait le volume. Si quelqu'un volait le disque dur, il trouverait les données cryptées. Cependant, si quelqu'un devait exécuter des requêtes sur la base de données, il verrait les données non cryptées (c'est pourquoi j'ai mentionné la séparation des informations, même si l'OP ne voulait pas en discuter).

Notez que cette recommandation est conçue comme le minimum que vous devriez faire. Si vous voulez des conseils juridiques, vous devrez bien sûr chercher ailleurs. Si vous voulez une discussion plus approfondie sur l'écriture de code sécurisé, je commencerais par le livre Writing Secure Code .

Avant de décider de ces questions de sécurité, vous devez évaluer le modèle de menace. Sans idée de ce contre quoi vous vous défendez, toutes les mesures que vous prendrez auront probablement peu de valeur.

Maintenant, vous pouvez vous préoccuper de certaines choses dans ce contexte:

• Les attaquants obtenant un accès physique à vos données (par exemple, pénétrer dans le centre de données, voler des bandes de sauvegarde, etc.)
• Les attaquants obtiennent un accès en lecture à votre base de données brute
• Les attaquants compromettant votre application, par exemple par injection SQL, dépassements de mémoire tampon, etc.

Pour le premier scénario, le stockage de la base de données et de toutes les sauvegardes sur des volumes chiffrés devrait fonctionner, à condition que le serveur soit sans tête - le vol du serveur ou des bandes nécessiterait alors de casser le chiffrement au niveau du disque.

Pour le deuxième scénario, le chiffrement des données de la base de données est utile, mais uniquement si vous ne stockez nulle part les clés ou les mots de passe requis.

Dans le troisième scénario, tout dépend du contexte dans lequel l'attaque se produit: s'il s'agit, par exemple, d'une attaque XSS ou CSRF, alors un attaquant peut faire tout ce que l'utilisateur légitime peut faire, et le cryptage de vos données n'aide en rien .

Votre modèle de menace est donc un attaquant qui obtient un accès en lecture à la base de données brute, soit en trouvant les informations de connexion et en réussissant à se connecter au serveur de base de données de l'extérieur, soit en obtenant un accès root au serveur de base de données. Un chemin typique consiste à obtenir d'abord un accès shell sur le serveur Web; à partir de là, un attaquant peut alors lire les informations d'identification d'accès à partir du fichier de configuration et se connecter à la base de données.

Une autre considération est l'endroit où vous conservez les clés et les phrases secrètes, surtout si vous utilisez une plate-forme avec un modèle d'exécution sans état tel que PHP. Idéalement, vous demandez au client de taper sa phrase secrète si nécessaire, et de la conserver uniquement en mémoire, ou mieux, de faire le déchiffrement côté client (mais ce n'est pas souvent faisable). Sur une plate-forme sans état, l'état est généralement effectué à l'aide de sessions, de memcache, de bases de données ou de fichiers plats; mais tous ces éléments sont bien plus vulnérables que de conserver l'état dans la mémoire d'une application Web avec état. Éviter cela est un problème de poule et d'oeuf, car si vous cryptez l'état avant de le persister, vous venez de créer un autre secret dont vous devez vous souvenir en toute sécurité. Se souvenir de la phrase secrète sur le client et l'envoyer avec chaque demande qui en a besoin peut être la solution la moins horrible alors;

Ignorant un instant ce que le client demande et quelles que soient les lois ...

Non, vous ne devriez probablement pas crypter les données. Si vous le faites, vous ne pourrez pas le rechercher facilement. Par exemple, comment rechercher un nom de famille like 'Smith%'si chaque entrée de nom est cryptée? Comment traceriez-vous la tension artérielle d'un patient au fil du temps si vous ne pouvez pas select .... from.... where patient_id = N?

Vous devez, bien sûr, vous assurer que le serveur est correctement sécurisé, la connexion réseau est sécurisée et que l'interface utilisateur est correctement sécurisée (y compris les délais d'expiration de session afin que les utilisateurs ne puissent pas quitter en laissant l'accès à toute personne qui utilise leur ordinateur). Vous pouvez également vouloir chiffrer les sauvegardes de base de données. Et sécuriser physiquement la pièce dans laquelle se trouve le serveur. Mais je ne crypterais pas les données en direct.

Clarification: cela suppose que l'OP demandait de chiffrer les données dans la base de données. Pas le système de fichiers sur lequel réside la base de données.

Si vous développez l'application Web avec soin en utilisant un framework MVC efficace comme CakePHP. Zend ou Rails, alors vous devriez pouvoir activer / désactiver le cryptage au niveau Modal des données.

CakePHP par exemple a quelques exemples de comportements pour Modal qui chiffrent les données. Rendre le processus transparent pour les contrôleurs et les vues.

Ignorer les problèmes d'indexation et d'autres problèmes de base de données techniques lors de cette opération. Il devrait être possible de l'avoir comme option configurable.

De plus, j'activerais le chiffrement ultérieurement ou uniquement sur le serveur de production. Les données chiffrées sont difficiles à déboguer et à utiliser lors du développement, et ne peuvent être effectuées que sur certaines colonnes.

Oui, vous devez crypter la base de données.

Étant donné qu'il s'agit d'informations personnelles et sensibles, je pense vraiment qu'elles le devraient.

Du mot de passe, vous pouvez dériver une clé de chiffrement que vous ne stockez que pour la session. De cette façon, il n'est stocké nulle part et personne (y compris les DBA) ne peut le savoir car personne ne peut non plus connaître le mot de passe. Quiconque essaie de visualiser la base de données directement regardera le charabia. Le seul moyen de corrompre cela est via le détournement de session, mais je suppose ici que les sessions sont également sécurisées.

Je me demande pourquoi le client vous demande de crypter la base de données? S'il vous demandait de protéger les données, je serais d'accord, mais il a déjà une implication implicite en tête. Donc tant qu'il ne sait pas exactement de quoi il parle, il ne fait que lancer des mots à la mode de mon point de vue.

Je trouve également très inutile de crypter la base de données, car je suis convaincu que littéralement tous les principaux SGBD prennent en compte la sécurité de manière appropriée et probablement mieux que vous ne le pourriez. Pour accéder à la base de données via le SGBD, vous aurez besoin d'informations d'identification. Dans le cas d'une base de données chiffrée, vous auriez également besoin de ces informations d'identification et pour déchiffrer les données, vous auriez besoin de ces informations d'identification que vous semblez déjà avoir.

En suivant cet état d'esprit, je propose de laisser le SGBD gérer la sécurité et de faire des efforts pour protéger les informations d'identification de l'entrée d'utilisateur à l'accès à la base de données, peut également appliquer des mots de passe forts et des changements périodiques.