Pas de base de données centrale

31

J'ai un client qui cherche à créer un site Web / des applications mobiles / des applications de bureau qui traitent des données très sensibles (plus sensibles que les coordonnées bancaires / de carte). En raison de la nature sensible des données, ils ne veulent pas les enregistrer dans une base de données centrale mais ils veulent toujours que leurs applications se synchronisent (disons que j'ajoute des données dans mon application mobile, je veux ensuite pouvoir accéder à mon application de bureau et voir les mêmes données).

Je ne peux pas penser à une manière agréable et fiable de le faire et je ne suis pas sûr qu'il y en ait une. C'est pourquoi je suis ici. Est-ce que quelqu'un sait comment je pourrais traiter ces données?

Une solution à laquelle je pensais était d'avoir une base de données côté client sur chaque application qui se synchroniserait en quelque sorte entre les applications, je peux voir que cela n'est pas très fiable et devient désordonné.

— user2424495
source

2

Si vous souhaitez que les données soient synchronisées, elles doivent toujours être accessibles, afin que les données puissent être extraites dans votre application. Vous pourriez diviser les données entre plusieurs bases de données, donc si l'une d'entre elles était en quelque sorte violée, vous ne feriez pas fuir toutes vos données. Si cela satisfait le client, ajoutez simplement plus de connexions de base de données à votre application et extrayez-y vos données.

— Andy

2

Est-ce un problème d'égal à égal? ou juste 1 ordinateur de bureau parlant à 1 téléphone intelligent (pour chaque espace de données)?

— ebyrob

7

Vous pouvez garantir la confidentialité de la base de données en chiffrant les données sur le serveur avec une clé qui n'est connue que de l'utilisateur.

— Philipp

26

Cela ressemble à un schéma auquel pense une personne qui ne comprend pas la sécurité. Celui qui a formulé cette exigence devrait formuler une question sur la sécurisation des données sur Security.SE .

— jpmc26

4

@ user2424495: Si les données doivent être disponibles via un site Web, les données doivent être disponibles d'où votre site Web est servi - qui est généralement un serveur central. Ou vous devez écrire un plugin de navigateur qui fournit les données côté client.

— Bergi

60

De nombreuses informations sensibles sont stockées dans des bases de données. En fait, une base de données centrale est probablement le moyen le plus sûr de stocker ces données. Les grandes bases de données d'entreprise ont des tonnes de fonctionnalités pour faire des choses comme crypter des informations sensibles, pour vérifier qui y accède, pour limiter ou empêcher les personnes, y compris les administrateurs de base de données, de visualiser les données, etc. que vous ne perdez pas de données. Il serait presque certainement beaucoup plus facile de compromettre les données stockées sur un appareil mobile ou un ordinateur portable d'un utilisateur aléatoire que de pénétrer une infrastructure de sécurité bien conçue et de compromettre une base de données centrale appropriée.

Vous pouvez concevoir le système avec une base de données centrale qui stocke uniquement les données chiffrées et stocke la clé privée de l'utilisateur sur l'appareil de l'utilisateur. De cette façon, même si la base de données centrale est complètement compromise, les données ne sont utilisables que par l'utilisateur. Bien sûr, cela signifie que vous ne pouvez pas restaurer les données de l'utilisateur s'il perd sa clé (disons que la seule copie était sur son téléphone et que son téléphone a été endommagé). Et si quelqu'un compromet la clé et, vraisemblablement, ses informations de connexion, il pourrait voir les données.

— Justin Cave
source

24

@ user2424495 - Si l'objectif est la sécurité réelle, le stockage centralisé des données l'emporte presque certainement. D'un point de vue marketing, ce n'est peut-être pas de votre faute si le téléphone de quelqu'un est piraté. Mais cela reflétera certainement mal sur l'application si le mot sort qu'il est relativement facile de pirater (car la plupart des systèmes des gens sont très mal sécurisés). Je préfère expliquer aux gens que leurs données sont stockées cryptées à l'aide d'une sécurité de niveau militaire plutôt que d'espérer qu'ils ne me blâment pas lorsque leur téléphone mal sécurisé est piraté.

— Justin Cave

27

C'est la seule réponse à ce jour qui réponde vraiment à la question et fournit le meilleur résultat de sécurité possible. Les exigences que le PO a été données sont ridicules. Si les données sont si sensibles que l'idée que les données soient même disponibles sur un réseau public est offensante pour les utilisateurs, alors l'idée de l'application n'est pas réaliste. Arrêt complet. Les appareils clients ne sont pas sécurisés et ne peuvent pas être approuvés.

— maple_shaft

2

@mharr si la base de données ne stocke que des données chiffrées (chiffrées avant de quitter l'appareil), peu importe ce que dit une ordonnance du tribunal, elle ne peut pas être déchiffrée physiquement sans les clés de chiffrement, que seul l'utilisateur possède.

— Richard Tingle

9

@RichardTingle <tinfoil> À moins que ladite agence gouvernementale n'ait déjà rompu le cryptage. </tinfoil>

— Bob

3

Je n'ai jamais dit que le problème n'était pas "intéressant", je trouve la question et les réponses jusqu'à présent très intrigantes et stimulantes. C'est EXACTEMENT le genre de question qui rend ce site génial. Je remets vraiment en question les exigences et certaines des hypothèses qui sont peut-être formulées au sujet des données. Mon sens vague me crie juste que ces exigences et ces hypothèses sur l'importance des données sont les réflexions d'une entreprise blovée et auto-adoratrice qui s'imagine informée et perspicace mais en réalité cont ...

— maple_shaft

38

Vous devez sauvegarder quelques étapes et, en consultation avec votre client, élaborer un modèle de menace . (Oui, c'est un lien vers un livre de 600 pages; oui, je vous recommande sérieusement de lire le tout.)

Un modèle de menace commence par poser des questions comme

Pourquoi l'application a-t-elle besoin de stocker ces données sensibles en premier lieu?
- Pouvez-vous éviter de le stocker du tout?
- Peut-il être jeté après un court instant?
- Doit-il vraiment être accessible à plusieurs appareils?
- S'il doit être accessible sur plusieurs appareils, doit-il être stocké sur plusieurs appareils?
Quelles sont les personnes autorisées à voir les données sensibles de chaque utilisateur?
- Cette liste peut-elle être raccourcie?
Quelles sont les personnes qui peuvent entrer en contact avec les données sensibles de chaque utilisateur tout en essayant de faire leur travail, mais n'ont pas besoin de le savoir?
- Peut cette liste être plus courte?
- Les données peuvent-elles leur être inaccessibles sans nuire à leur capacité de faire leur travail?
- S'il ne peut pas être inaccessible, peut-il au moins être rendu incompréhensible? (C'est ce que fait le chiffrement, dans l'abstrait: il rend les données incompréhensibles.)
Quelles sont les personnes qui souhaitent voir les données sensibles, mais ne sont pas autorisées?
- Quelles opportunités ont-ils pour accéder aux données?
- Que veulent-ils faire avec les données une fois qu'elles les ont?
- Comment seront-ils en colère s'ils n'obtiennent pas ce qu'ils veulent?
- Combien d'argent, de temps, de cycles CPU et d'efforts humains sont-ils prêts à dépenser?
- Se soucient-ils si quelqu'un sait qu'ils ont vu les données?
- Souhaitent-ils accéder aux données sensibles de certains utilisateurs ou est-ce que quelqu'un le fera?
- Que savent-ils déjà?
- À quoi ont-ils déjà accès?

Une fois que vous connaissez les réponses à ces questions, vous serez bien mieux placé pour savoir quoi faire.

Gardez à l'esprit qu'il peut y avoir plus d'une réponse à chaque série de questions, en particulier celles concernant les attaquants (les personnes qui veulent les données sensibles mais ne sont pas autorisées à les avoir). Si vous ne pouvez pas penser à au moins une demi-douzaine d' attaquants archétypaux différents , avec des motivations, des objectifs et des ressources différents, vous avez probablement manqué quelque chose.

Gardez également à l'esprit que les attaquants qui vous causent (et / ou le client) le plus de problèmes, sont les plus susceptibles de faire une éclaboussure géante dans les médias si leur attaque réussit, ou qui causent le plus de dégâts agrégés , sont probablement pas les attaquants qui peuvent causer le plus grand tort aux utilisateurs individuels si leur attaque réussit. L'entreprise de votre client se soucie rationnellement davantage des dommages globaux, mais les utilisateurs se soucient rationnellement davantage des préjudices qui leur sont causés.

— zwol
source

4

Cela n'essaie pas vraiment de répondre à la question ou de la réfuter, mais c'est vraiment une réponse impressionnante à une question qui n'a pas été posée.

— maple_shaft

11

@maple_shaft: Eh bien, cela répond à la question que l'OP voulait poser. Étant donné que la question pourrait bien être considérée comme souffrant d'un problème XY , cela semble une bonne réponse.

— sleske

8

Une option pour effectuer la synchronisation serait de le faire de pair à pair. Cela nécessitera toujours un serveur central, mais ce serveur ne traitera aucune des données.

Lorsqu'un appareil se connecte, un serveur central reçoit une notification avec l'ID utilisateur. Lorsqu'un deuxième appareil du même utilisateur se connecte, le serveur envoie aux deux appareils les adresses IP de l'autre. Les appareils peuvent alors échanger directement des données. Attention: un appareil doit agir comme un serveur, donc au moins un ne peut pas être derrière un routeur NAT.

N'oubliez pas que vous aurez besoin d'une authentification et d'un chiffrement solides pour le mécanisme de notification et pour l'échange d'égal à égal.

— Philipp
source

1

Cela ressemblerait à un schéma de versionnage serait également nécessaire pour éviter d'envoyer toutes les données d'avant en arrière tout le temps entre les deux appareils ...

— ebyrob

L'échange p2p serait une excellente solution, si ce n'était de la nécessité d'une configuration inutile forçant l'utilisateur final, ce qui, à mon avis, rendrait l'utilisation de l'application moins conviviale. Ensuite, il y a la question de savoir si le client veut choisir entre la vulnérabilité des données et un peu d'agitation lors de la configuration de l'application, ce qui dépend beaucoup de la sensibilité exacte des données et de l'attention des utilisateurs.

— Andy

1

@DavidPacker en supposant que vous configuriez et mainteniez le premier serveur, quelles sont les étapes de configuration supplémentaires?

— ebyrob

@ebyrob Je pourrais être mal compris, mais je comprends que le serveur fourni par le créateur de l'application ne conta que la procédure de synchronisation p2p. Mais les données doivent être extraites de ce serveur à partir de l'un des appareils des clients - et le client doit se rendre, ou rendre ses données, accessibles - c'est la configuration dont j'ai parlé.

— Andy

1

@David, Philipp suggère l'échange d'égal à égal des données sensibles, donc pas d'envoi de celles-ci ni même via le serveur central. Le serveur central n'est là que pour faciliter la recherche d'un autre pair par un pair; alors il se dérange.

— Erik Eidt du

5

Faites-en le problème de quelqu'un d'autre.

Stockez les données localement dans chaque application, puis donnez aux utilisateurs la possibilité d'activer la synchronisation en utilisant leur propre compte avec un service tiers (Dropbox, Google Drive, etc.). Pensez également à chiffrer toutes les données téléchargées sur le service tiers (il y a des avantages et des inconvénients à le faire).

Cela donne l' impression que les utilisateurs possèdent leurs propres données, car ils doivent accepter la synchronisation des données. Il rend les applications utiles pour les personnes qui ne souhaitent pas que le partage se produise. Et cela rend quelqu'un d'autre responsable (techniquement et, potentiellement, légalement) des maux de tête continus liés à la sécurité des données partagées.

— James Mason
source

1

La préoccupation de votre client semble concerner la visibilité de ces données. la première question à poser à votre client est de savoir si les données ont été cryptées, où peuvent-elles être stockées? Demandez ensuite à votre client quels types de contrôles d'accès il souhaite mettre en place avant que les données puissent être décryptées et traitées - où la clé de décryptage peut-elle être stockée? est une clé distincte par utilisateur? etc...

Si votre client ne veut pas que les données soient stockées n'importe où, veut-il que l'utilisateur les saisisse à chaque fois?

— Michael Shaw
source