Pas de base de données centrale
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é.
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.
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 doit-elle d'abord stocker ces données sensibles?
- 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 en essayant de faire leur travail, mais qui n'ont pas besoin de le savoir?
- Est-ce que cette liste peut être raccourcie?
- 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 veulent 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'il a 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 ensemble 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 différents attaquants archétypaux, 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 des éclaboussures géantes dans le médias si leur attaque réussit, ou qui causent le plus de dégâts ), ce ne sont probablement pas les attaquants qui peuvent causer le plus de mal à 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.
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 NAT routeur.
N'oubliez pas que vous aurez besoin d'une authentification et d'un cryptage solides pour le mécanisme de notification et pour l'échange d'égal à égal.
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 apparence que les utilisateurs possèdent leurs propres données, car ils doivent accepter la synchronisation des données. Cela 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.
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échiffrées et traitées - où peut-on stocker la clé de déchiffrement? est une clé séparée 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?