Quelle est une bonne pratique de sécurité pour stocker une base de données critique sur les ordinateurs portables du développeur?

33

Nous avons quelques données:

Les développeurs ont besoin d'une réplique de la base de données de production sur leurs machines.
Les développeurs ont le mot de passe de cette base de données dans les fichiers App.config.
Nous ne voulons pas que les données de ladite base de données soient compromises.

Quelques solutions suggérées et leurs inconvénients:

Cryptage complet du disque. Cela résout tous les problèmes, mais dégrade les performances du portable, et nous sommes une start-up, alors n’avez pas d’argent pour les chevaux de course.
Créer une machine virtuelle avec un disque dur crypté et y stocker la base de données. Cela fonctionne bien, mais cela n'aide pas beaucoup, car il y a un mot de passe dans Web.Config.
La solution numéro 2 + demande au développeur de saisir le mot de passe de la base de données chaque fois qu'il exécute quoi que ce soit. Il résout tous les problèmes, mais il est vraiment encombrant pour les développeurs qui lancent parfois l’application plusieurs fois par minute. De plus, nous avons plusieurs applications qui se connectent à la même base de données, et la mise en place d'un écran de mot de passe devra être différente.

Ma question est donc la suivante: existe-t-il une solution commune à ce problème ou des suggestions sur la manière de rendre exploitables les solutions ci-dessus?

database security

— Svarog
source

26

Avez-vous réellement mesuré l’impact du chiffrement intégral du disque sur la performance? Je l'ai utilisé sur des ordinateurs portables assez anciens et je n'ai pas constaté de dégradation significative des performances. Les systèmes d'exploitation modernes sont assez efficaces pour la mise en cache et les disques sont lents de toute façon. Le pire impact est probablement sur la durée de vie de votre batterie.

— 5gon12eder

69

Pour être honnête, cela ne semble pas être la bonne approche. 1) Pourquoi les développeurs ont-ils besoin d'une base de données de production sur leurs machines? N'y a-t-il pas un moyen de créer des données factices pour une base de données dev? 2) Pourquoi le mot de passe est-il stocké en texte brut dans un fichier de configuration? Vous essayez de mettre un pansement sur un processus imparfait, semble-t-il. Peut-être que vous pouvez réviser ce qui vit réellement sur les machines de développement ainsi que la manière dont le mot de passe est stocké pour la base de données.

— Thomas Stringer

2

Il existe des raisons pour lesquelles les développeurs ont besoin d'une base de données de production. Pour des raisons historiques, leur travail est trop couplé avec les données en direct. Je sais que c'est une mauvaise idée et si nous ne trouvons pas de bonne solution, nous allons passer aux données factices. Pour le moment, j'essaie de trouver une bonne solution sans cela.

— Svarog

6

Aucun utilisateur de MacBook Pro ne peut vous dire, à la vitesse de la machine, si le cryptage intégral du disque est activé ou désactivé sur un lecteur SSD. Il n'y a pas de différence. Aucun que vous pouvez remarquer. Peut-être que vous pouvez mesurer, mais rien qui ne soit perceptible.

— gnasher729

5

Je soutiens le commentaire de @ gnasher729. Après avoir utilisé le chiffrement intégral du disque pendant de nombreuses années dans des environnements réglementés (finances et soins de santé), il n’est pas nécessaire que cela nuise sensiblement aux performances. Beaucoup de gens soulèvent d'autres points valables, mais dans un environnement HIPAA, il est difficile d'avoir une politique raisonnable sans chiffrement intégral du disque, même si les bases de données ne sont pas placées sur des ordinateurs portables. Les e-mails et autres fragments de données s'y retrouvent souvent. Échanger des fichiers .... etc ... Full Disk Encryption n'est pas adéquat, mais il est généralement nécessaire.

— Joshp

100

Non seulement vous ne voulez pas une copie de la base de données de production, mais cela pourrait même être illégal. Par exemple, aux États-Unis, vous ne pouvez pas déplacer des données de production de l'environnement de production si celui-ci contient des informations réglementées telles que des données personnelles sur la santé, des données financières ou même des données pouvant être utilisées pour le vol d'identité. Si vous le faites, vous risquez d’être condamné à une amende, à perdre votre statut de conformité et donc à faire l’objet d’audits plus agressifs, voire à être nommé dans une action en justice.

Si vous avez besoin de données à l'échelle de production pour les tests, vous avez plusieurs options:

Générez toutes les données factices. C'est plus compliqué qu'il n'y paraît. Il est étonnamment difficile et fastidieux de générer des données imaginaires sensibles.
Anonymisez vos données de production. Cela peut être plus facile, mais procédez avec prudence.

Pour l'option n ° 2

Dans l'environnement de production, un administrateur de base de données autorisé crée une copie des données de production.
Toujours dans l'environnement de production, le même administrateur autorisé exécute une routine qui anonymise toutes les données sensibles. En cas de doute, anonymiser.
Ce n'est qu'alors que les données doivent être déplacées vers un autre environnement.

— Corbin March
source

31

et le mot de passe de la copie de la base de données ne doit pas être le même que celui de la version de production .....

— Lightness Races with Monica

3

"Par exemple, aux États-Unis, vous ne pouvez pas déplacer des données de production de l'environnement de production si elles contiennent des informations réglementées" Quoi? Avez-vous une source pour cela? Par exemple, ne pouvez-vous pas utiliser les sauvegardes d'une base de données de production en tant que données pour l'environnement de transfert, ou pour tester des bases de données sur des machines de développement?

— Nounou

12

@nanny Pas si vous utilisez des données réglementées. Par exemple, j'ai travaillé sous la réglementation HIPAA. Selon HIPAA "Les entités couvertes doivent également mettre en œuvre les politiques et procédures minimales nécessaires raisonnables qui limitent la quantité d'informations de santé protégées utilisées, divulguées et demandées à certaines fins". Une politique minimale nécessaire est sujette à interprétation. Notre conseiller juridique a suggéré une interprétation stricte dans laquelle les données sensibles étaient conservées là où les développeurs ne pouvaient pas y accéder. (Est-il vraiment nécessaire qu'ils fassent leur travail?) La même prudence s'applique à la conformité financière telle que PCI.

— Corbin Mars

4

@nanny Prenez ceci comme une rumeur d'un non-avocat, mais si je comprends bien, les règles varient considérablement d'un État à l'autre. Le conseiller juridique avec lequel je travaille a toujours tendance à être prudent. Strictement parlant, les développeurs n'ont pas besoin de SSN pour s'acquitter de leurs tâches. Les conseillers juridiques suggèrent donc que ces SSN vivent dans un environnement protégé où les développeurs ne peuvent pas y accéder. Ne m'écoute pas, cependant. Un avocat veillant sur vos intérêts à long terme sera la meilleure ressource.

— Corbin Mars

5

Strictement parlant, il n’est pas illégal d’être négligent avec PPI, à moins que vous ne travailliez pour le gouvernement, le titre 32 entre alors en jeu ... mais c’est un grave risque de responsabilité civile. Ceci est une excellente réponse cependant. upvoted.

— dwoz

9

Pouvez-vous au moins indiquer aux développeurs les machines virtuelles de votre centre de données qu'ils peuvent utiliser pour ce travail? Bien qu'ils devraient vraiment travailler avec des données hors production, ce serait plus sûr jusqu'à ce que vous puissiez y accéder, car les données ne seraient pas stockées sur des ordinateurs portables facilement volés.

— Brian Knoblauch
source

cela se lit plus comme un commentaire, voir Comment répondre

— Gnat

5

@gnat, cette réponse peut être courte mais c'est une très bonne alternative suggérée.

Ne sois pas si pédant, @gn ... c'est une bonne réponse.

— Dwoz

@ dan1111 C'est le problème. Ce n'est pas une réponse. C'est une alternative. Cela en fait un commentaire, pas une réponse.

— CorsiKa

2

@corsiKa, les réponses qui remettent en cause la prémisse de la question sont autorisées et sont souvent de très bonnes réponses. Voir le problème XY: meta.stackexchange.com/questions/66377/what-is-the-xy-problem . Et des réponses plus détaillées peuvent être meilleures, mais c'est toujours une réponse.

8

Changez votre façon de travailler si possible.

Comme d'autres l'ont fait remarquer:

L'utilisation des données de production pour le développement n'est pas une bonne pratique.
Avoir un mot de passe stocké en clair n'est pas une bonne pratique.

Ces deux facteurs vous exposent à des risques importants et doivent être modifiés si possible. Vous devriez au moins évaluer sérieusement le coût de ces changements. S'il s'agit d'une dépendance externe que vous n'avez pas le pouvoir de changer, envisagez de la soulever comme une préoccupation pour quiconque a ce pouvoir.

Dans le monde réel, cependant, il ne sera peut-être pas possible de changer cela. En supposant que ce que vous faites soit légal, vous devrez peut-être vivre avec cet arrangement (au moins temporairement).

Si cela est vraiment nécessaire, il vous suffit de procéder au chiffrement intégral du disque.

Compte tenu des risques, vous devez utiliser la meilleure option de sécurité disponible, et c'est tout. S'il y a un succès de performance, vivre avec elle. C'est un coût de travailler avec des données sensibles.

Si j'étais votre client, je ne serais pas impressionné que vous ayez décidé de ne pas utiliser la meilleure option de sécurité disponible avec mes données, car vos ordinateurs portables seraient un peu plus lents.

1

"Pas une solution idéale" devrait être changé pour "une idée complètement stupide" IMO

— Darkhogg

@Darkhogg, vous avez raison, cela devrait être plus fort. Édité. Je ne voudrais pas aller aussi loin que "complètement stupide" sans savoir à quel point l'application est sensible. En pratique, le risque de compromission est très, très faible si vous utilisez le chiffrement intégral du disque. Il est donc possible d’en faire trop pour des raisons de sécurité.

Je suis d'accord avec le premier point, mais pas le second. Si vous ne stockez pas votre mot de passe en texte brut, où le stockez-vous (1) en cryptogramme ou (2) dans votre cerveau. Si (1), où stockez-vous le mot de passe pour le chiffrement (boucle infinie détectée). Si (2), j'espère que vous aimerez vous lever à 2 heures du matin pour taper le mot de passe pour redémarrer le service.

— emory

1

La réponse de Corbin March est plutôt bonne, je vais juste ajouter un détail supplémentaire, à savoir que vous avez généralement deux classes de données dans votre base de données de production: métadonnées système / application; et données utilisateur client / données transactionnelles. Ce dernier ne devrait JAMAIS être utilisé dans un environnement de développement "tel quel".

Il est très rare en effet que vous ayez besoin des informations du client de production pour effectuer le développement.

Toutefois, si le problème décrit ici par le PO concerne des données secrètes commerciales ou des données système hautement propriétaires qui ne concernent pas les données client, cela est demandé par les développeurs. le mot de passe de la base de données est conservé en clair dans un fichier de ressources quelque part. Il doit exister un mécanisme permettant, par exemple, de régénérer un mot de passe quotidien, qui n'est pas stocké sur le disque.

— Dwoz
source

5

client user data/transactional data... should NEVER be used in a development environment "as is." - Cela me semble impraticable. Des problèmes de programmation liés à la production liés aux données d'un client spécifique seraient insolubles dans le cadre de cet arrangement. De plus, les données réelles réelles sont extrêmement utiles du point de vue des tests. L’effort de privatisation ou d’anonymisation doit être axé uniquement sur les données spécifiquement réglementées.

— Robert Harvey

@ RobertHarvey, c'est inutilisable si vous ne pouvez pas reproduire le problème de production dans un environnement de développement. Je pense que tout au long de ma carrière, je peux compter sur quelques doigts le nombre de fois que des données de test correctement assainies ne sont pas suffisantes pour reproduire un bug de production. Les "informations commerciales exclusives" vont bien au-delà des numéros SSN et CC!

— Dwoz

4

Mais si vous vous engagez dans cette voie, vous aurez des informaticiens qui ne peuvent pas faire leur travail car ils ne disposent pas d'un accès administratif à tout. J'admets que cela cause des problèmes potentiels à Snowden, mais je ne vois pas d'alternative viable, si ce n’est d’embaucher des personnes de confiance. Sarbanes Oxley et HIPAA spécifient très précisément le type de données à séquestrer et n'incluent pas «toutes les données de production», pas de loin. Cela dit, je ne crois pas que des données de production d'aucune sorte devraient exister sur les ordinateurs portables itinérants.

— Robert Harvey

1

-1 pour JAMAIS. Vos commentaires plus nuancés valent mieux que votre réponse; vous devriez les éditer dedans.

1

@ dan1111 nous pouvons accepter d'être en désaccord alors. Les données client "telles quelles" ne doivent JAMAIS JAMAIS être utilisées dans des systèmes de développement. Il devrait toujours être désinfecté. Vous n'y croyez pas parce que vous n'avez pas encore été mordu par cette mangouste enragée ... et c'est ce que c'est, quand cela se produit. Un rongeur fou enragé qui a l'intention de tirer votre sang. Suivez mon conseil, évitez la mangouste enragée.

— Dwoz

1

Vous ne précisez pas quelle base de données et quel environnement.

Si vous pouvez utiliser la sécurité intégrée, la base de données n'est pas accessible sans être connecté en tant qu'utilisateur. Oui, si les données sont sur le disque dur, elles peuvent être piratées, mais il s’agit d’une défense de premier niveau.

App.config me fait penser que cela pourrait être un .NET. Mettez config dans une clé USB et lisez-la à partir de la clé USB. Si le lecteur n'est pas présent, indiquez à l'utilisateur le mot de passe.

Est-il possible de stocker le mot de passe en mémoire la première fois qu'il est saisi et lu par tous? Encore une fois, vous ne déclarez pas l'environnement. Fichiers mappés en mémoire

Avec certains TDE, vous pouvez stocker la clé sur un périphérique séparé afin qu’ils ne la fournissent que lorsque le serveur de base de données est démarré.

— paparazzo
source

0

Une option possible consiste à créer une copie de la base de données et à la nettoyer à l'aide d'un script afin d'obtenir des données différentes de celles en cours de production. Vous ne vous retrouverez pas avec les mêmes données que la production, mais vous aurez la même échelle.

— Jason Crosby
source

cela semble simplement répéter le point soulevé et expliqué dans la réponse principale il y a environ une semaine

— Gnat