Sécuriser les données sensibles des développeurs

61

J'ai une application d'entreprise en cours d'exécution qui utilise les banques de données MySQL et MongoDB . Mon équipe de développement dispose d’un accès SSH sur la machine pour pouvoir exécuter les versions des applications, la maintenance, etc.

J'ai récemment soulevé un risque dans l'entreprise lorsque les utilisateurs ont commencé à stocker des données extrêmement sensibles sur l'application. Les développeurs ont ainsi un accès indirect à ces données, ce qui a provoqué un véritable tollé. accessible.

Pour moi, cela ne semble pas possible, car si l'application a accès à la base de données, un développeur ayant accès à la machine et à la source de l'application sera toujours en mesure d'accéder aux données.

Clinton Bosch
la source
30
Les utilisateurs ne devraient stocker des données sensibles que sous forme cryptée. Il ne devrait pas y avoir de gros problème si les développeurs peuvent accéder au formulaire crypté, à condition que les clés correspondantes soient correctement protégées.
MSalters
3
@Clinton Avez-vous des équipes d'administration et de développement distinctes? L'administrateur du serveur peut toujours lire les données et le chiffrement n'aide pas, car il peut facilement obtenir la clé.
CodesInChaos
14
Pour être tout à fait honnête, il s’agit là d’une question complexe, et sa mise en oeuvre nécessite une grande expertise en matière de sécurité des données. Même si vous saviez exactement quoi faire, vous ferez face à des obstacles commerciaux, politiques et techniques. Je vous suggère fortement de faire appel à un consultant en sécurité des données. Ils savent non seulement quoi faire ici, mais la direction supérieure accorde généralement plus de crédit à une tierce partie qui lui dit de changer. Les cadres supérieurs ne mettent généralement pas autant en valeur ce que leurs experts internes leur disent.
maple_shaft
3
Cela vaut peut-être la peine de demander sur Information Security Stack Exchange. Il y a quelques informations connexes sur cette question
paj28
23
Pourquoi les humains touchent-ils le serveur et déploient-ils du code?
Wyatt Barnett

Réponses:

89

La sécurité n’est pas une baguette magique à la fin d’un projet, elle doit être prise en compte et intégrée dès le premier jour. régulièrement dans le cadre d'un système complet, qui est aussi fort que le maillon le plus faible.

Dans l'état actuel des choses, vous avez signalé un problème de sécurité, qui constitue un bon premier pas. Maintenant, au minimum, vous devez définir: -

  • Quelles données vous essayez de protéger?
  • De qui essayez-vous de protéger ces données?
  • Qui a réellement besoin d'accéder à quoi (et quand)?
  • Quel est l’impact juridique / financier / commercial de la compromission de ces données?
  • Quel est le besoin juridique / financier / commercial d'une personne / groupe ayant accès aux données?
  • Quel budget l'entreprise est-elle disposée à affecter à une stratégie "sécurisez, restez sécurisé" alors que ce n'était pas une exigence commerciale auparavant?
  • De quel accès le système a-t-il besoin aux données?
  • Sur quoi ce processus et les systèmes sur lesquels cette application s'appuie?
  • Que fait-on pour sécuriser ces environnements?
  • Qui sera responsable de sa mise en œuvre et de la révision de l'ensemble du processus?

Tant que vous ne connaissez pas tous ces détails, vous n’avez vraiment rien avec lequel travailler. Ces informations définiront les mesures d'atténuation de ces menaces que vous pouvez (et ne pouvez pas) appliquer et pourquoi.

La meilleure chose à faire est peut-être de reconnaître que vous n’avez pas l’expérience nécessaire et qu’il serait préférable de faire venir une nouvelle personne possédant cette expérience. J'entends assez souvent la réponse qu'il n'y a pas de budget - s'il est considéré comme réellement important, alors le budget sera trouvé.

James Snell
la source
33
Whoa ... cela rend la sécurité sonore ... non-trivial. (Désolé pour le sarcasme; j'ai vu beaucoup de gens surpris par cela.)
Paul Draper
4
Je crois qu'un certain nombre de personnes pensent qu'il y a une make-application-securecommande magique à exécuter.
TMH
27

Tu as raison. Si une application est capable d'accéder au contenu stocké sur les ordinateurs de l'entreprise sans que l'utilisateur ne passe à chaque fois des informations supplémentaires , les programmeurs, les mainteneurs, les administrateurs système, etc. du fournisseur de services peuvent accéder à ce contenu. Ceci est fondamentalement inévitable et constitue une source majeure d’insécurité (Edward Snowden était un administrateur système et disposait de privilèges spéciaux par rapport à "Top Secret" car il n’y avait tout simplement pas moyen de ne pas les accorder.)

Le seul moyen d'éviter cela est d'imposer à l'utilisateur de fournir des informations qui ne parviennent jamais aux ordinateurs de l'entreprise. C’est fastidieux et source d’erreurs, car personne ne peut se souvenir d’assez d’informations pour constituer une barrière d’accès sécurisée et, par conséquent, les gens commenceront immédiatement à stocker leurs identifiants de manière électronique dans un endroit qui deviendra alors la nouvelle cible de l’attaque (et probablement une cible plus faible que celle que vous maintenez). Mais si vous voulez affirmer honnêtement que "nos employés ne sont pas physiquement capables d'accéder au contenu de nos utilisateurs", c'est le seul moyen.

(Notez également qu'un tel modèle commercial semble devenir politiquement intenable. Les services de sécurité ont forcé des entreprises à cesser leurs activités pour avoir tenté de faire exactement cela. Je comprends que donner des garanties de confidentialité a une valeur commerciale, mais il ne peut pas en avoir plus valeur commerciale que l’objectif fondamental de rester en affaires.)

Kilian Foth
la source
6
Il est possible de concevoir le matériel de telle sorte qu'il soit physiquement impossible d'accéder à certaines données sans créer un enregistrement permanent de cet accès qui ne pourrait pas être détruit sans la collaboration de plusieurs personnes indépendantes et qui, même avec cette collaboration, ne pourrait pas être détruit. sans laisser de trace évidente de destruction délibérée. La mise à jour de tels systèmes pour gérer les exigences changeantes risque cependant d'être très coûteuse par rapport à la mise à jour de systèmes de sécurité basés sur logiciel.
Supercat
5
Vous avez raison, j'ai complètement oublié de mentionner l' auditabilité comme alternative possible à l'hébergement sans connaissances. C'est un peu plus facile à réaliser et assez souvent pour l'analyse de rentabilisation.
Kilian Foth
Votre dernier paragraphe. Faites-vous référence à des histoires de type LavaBit? Je suis confus.
Jpmc26
1
@supercat Vous devez également avoir confiance que les créateurs du matériel l'ont fait faire ce qu'ils ont dit.
user253751
2
@immibis: C'est vrai, mais la conception et la fabrication de matériel sécurisé pourraient être vérifiées par plusieurs personnes indépendantes. En outre, dans un système conventionnel, un morceau de code "sournois" peut faire quelque chose puis se supprimer lui-même sans trace, mais si un matériel sécurisé n'est pas supposé avoir un magasin de contrôle en écriture, une telle chose serait impossible. Soit le code furtif devrait être en permanence dans le magasin de contrôle, ou le magasin de contrôle devrait avoir un moyen de modification câblé en permanence, ce qui serait détectable après coup.
Supercat
15

Tu as plutot raison; certains développeurs auront toujours besoin d'accéder aux données Live, ne serait-ce que pour diagnostiquer les problèmes de production. Le mieux que vous puissiez faire est de limiter les dommages potentiels en réduisant le nombre de personnes impliquées.

With great power comes great ... opportunity to really, *really* foul things up. 

De nombreux développeurs ne voudront pas cette responsabilité et d'autres, ne seront tout simplement pas "prêts" à la tenir et ne l'auraient donc pas dû.

Question: Pourquoi votre équipe de développement exécute- t-elle les versions Live ?
Je suggérerais que vous ayez besoin d'une "équipe" de gestion des versions (même s'il ne s'agit que d'un sous-ensemble de votre équipe, ainsi que d'une représentation commerciale permettant de prendre des "décisions" sur le jour, comme "Go / No-Go")? Cela éliminerait une grande partie de la "nécessité" pour les développeurs de toucher n'importe quoi en direct.

Avez-vous un accord de non-divulgation / confidentialité entre les développeurs et la société? C'est lourd, mais ça pourrait avoir du mérite.

Phill W.
la source
Ce qui n’empêche pas un malfaiteur déterminé de cacher la porte dérobée dans l’application, mais cela réduit l’opportunité que représente le voleur.
Jan Hudec
Oui, ce n'est pas toute l'équipe de développement, mais plutôt une équipe de gestion de sous-ensembles / versions. Le contrat de travail contient certainement une clause sur la surveillance des données que vous ne devriez pas, c'est une infraction passible de renvoi.
Clinton Bosch
@JanHudec Surtout depuis l'ajout de code l'application laisse des traces dans le contrôle de version.
CodesInChaos
@CodesInChaos: Un bon programmeur peut donner à la porte dérobée l'apparence d'une erreur honnête. Vous les soupçonnerez, mais vous ne plaiderez jamais contre eux. Mais oui, c'est une autre ligne de défense.
Jan Hudec
@ Jan: C'est pourquoi toutes les modifications de code devraient être examinées et validées avant d'être autorisées dans la branche de publication.
SilverlightFox
9

Le problème est que vos développeurs ont accès aux systèmes. S'ils ont besoin de données de production pour le débogage, donnez-leur un vidage de la base de données dans lequel toutes les informations sensibles sont supprimées. Ensuite, les développeurs peuvent utiliser ce vidage.

Le déploiement d'une nouvelle version ne doit impliquer aucun développeur, ni une tâche d'administration pure, ni même mieux, une tâche entièrement automatisée. Sachez également que la libération et le déploiement sont deux tâches très différentes. Si votre processus n'en a pas conscience, changez-le en conséquence.

SpaceTrucker
la source
1
Nous n'avons pas besoin des données de production issues du débogage, nous avons un vidage de données assaini pour cela, mais un déploiement nécessite parfois diverses migrations de données, etc. qui sont exécutées par certains développeurs de l'équipe de gestion des versions (mais ils sont toujours des développeurs)
Clinton Bosch
2
@ClintonBosch Ensuite, vous n'avez pas clairement séparé les rôles d'administrateur et de développeur. Ensuite, une autre question que vous devriez vous poser est la suivante: comment pouvons-nous nous assurer que le logiciel publié est également effectivement déployé? Vous devez vous connecter à la version et autoriser uniquement le déploiement de packages signés en production. Aussi encore l'automatisation est votre ami. Les migrations ne devraient nécessiter aucune étape manuelle.
SpaceTrucker
4
@ClintonBosch Identifiez les champs de données hautement confidentiels et chiffrez-les. Assurez-vous de définir la sécurité du système d'exploitation de production afin de pouvoir accéder aux ID utilisateur lisant le fichier de clé pour vous assurer que personne d'autre que l'utilisateur de l'application ne le fait. Ne donnez pas aux développeurs le mot de passe de l'utilisateur de l'application. Faites-en des sudo pour obtenir des droits sur la production et enregistrez ce qu'ils font. C'est probablement le moyen le plus sûr de veiller à ce que vous gardiez les quelques personnes qui auraient accès à la garderie et à ce qu'elles ne puissent pas voir par hasard ou accidentellement des données auxquelles elles ne sont pas supposées avoir accès.
maple_shaft
6

Règle n ° 1 de la sécurité: si quelqu'un a accès à l'information, il a accès à cette information

Cette tautologie est agaçante, mais c'est vrai. Si vous donnez accès à une personne, elle aura accès aux données. Pour les utilisateurs, cela signifie généralement un contrôle d'accès, mais pour les développeurs ... eh bien ... ce sont eux qui doivent écrire le contrôle d'accès.

S'il s'agit d'un problème majeur pour vous (et que cela semble être le cas), envisagez de renforcer la sécurité de votre logiciel. Un modèle courant consiste à concevoir des logiciels sécurisés en couches. Au niveau le plus bas, une équipe de développement de confiance conçoit un logiciel qui gère le contrôle d'accès le plus nu possible. Ce logiciel est validé et vérifié par autant de personnes que possible. Toute personne qui conçoit ce code a accès à tout, la confiance est donc essentielle.

Après cela, les développeurs peuvent créer un contrôle d'accès plus flexible au-dessus de cette couche principale. Ce code doit toujours être V & Vd, mais il n'est pas aussi rigoureux, car vous pouvez toujours compter sur la couche principale pour couvrir l'essentiel.

Le motif s'étend vers l'extérieur.

La partie difficile, en effet l’ art de concevoir ces systèmes, consiste à construire chaque couche de manière à ce que les développeurs puissent continuer à développer et à déboguer tout en fournissant à votre entreprise la sécurité que vous attendez. En particulier, vous devrez accepter le fait que le débogage nécessite plus de privilèges que vous ne le pensez normalement, et tenter de verrouiller cela entraînerait la colère de certains développeurs.

En tant que solution secondaire, envisagez de créer des bases de données "sûres" à des fins de test, afin que les développeurs puissent extraire tous les mécanismes de sécurité et procéder à un débogage sérieux.

En fin de compte, vous et vos développeurs devez comprendre un principe fondamental de la sécurité: toute sécurité est un équilibre entre sécurité et convivialité. Vous devez trouver votre propre équilibre en tant qu’entreprise. Le système ne sera pas parfaitement sécurisé et ne sera pas parfaitement utilisable. Cet équilibre évoluera probablement à mesure que votre entreprise grandira et / ou que les exigences envers les développeurs changeront. Si vous êtes ouvert à cette réalité, vous pouvez y remédier.

Cort Ammon
la source
3

Configurez deux déploiements de l'application qui utilisent également des déploiements de base de données séparés. Le premier est le déploiement en production et le second est le déploiement de test.

Le déploiement de test ne doit contenir que des données de test. Il peut s'agir de données fantaisistes créées à cet effet ou d'une copie des données de production anonymisées afin d'empêcher les développeurs de découvrir les personnes et entités réelles à l'origine des données.

Philipp
la source
Oui, c'est exactement le scénario que nous avons. Mais à un moment donné, quelqu'un doit travailler sur l'environnement de production pour faciliter le déploiement / la migration des données
Clinton Bosch
3

Dans deux entreprises financières, les développeurs n’avaient pas accès aux machines de production. Toutes les demandes de modification de machines de production devaient passer par un processus d'approbation, avec un script, et étaient approuvées par les responsables. L'équipe de dev-ops a terminé les déploiements réels. Je suppose que cette équipe était composée uniquement d'employés et avait passé avec succès les vérifications des antécédents. Ils ne possédaient pas non plus de connaissances en matière de développement, ils ne pouvaient donc probablement pas espionner s'ils le voulaient. En plus de cela, vous devez chiffrer toutes les entrées de la base de données à l'aide d'une clé secrète stockée dans les variables d'environnement. Même si les bases de données ont été divulguées publiquement, personne ne pourrait les lire. Cette clé peut être davantage protégée par mot de passe (PBKDF) afin que seul un dirigeant puisse la déverrouiller. Votre système peut nécessiter le mot de passe de l'administrateur au démarrage (ou plus probablement délégué à dev-ops ou à un responsable de dev-ops). Fondamentalement, la stratégie consiste à disperser les connaissances de sorte qu'une masse critique des connaissances requises n'existe pas chez une seule personne et qu'il existe des mécanismes de contrôle. C’est ainsi que Coca-Cola protège sa formule. Honnêtement, certaines de ces réponses sont des échappatoires.

Chloe
la source
-1

MongoDB a des contrôles de sécurité limités et dépend d'un environnement sécurisé. Lier à une adresse IP et un port spécifiques (et ssl depuis 2.2), et une authentification grossière, voilà ce qu’il offre. MYSQL ajoute GRANT o ON db.t TO ... Les données inactives ne sont pas cryptées et ssl n'est pas utilisé par défaut. Créer une clôture. L'accès en lecture seule des développeurs aux fichiers journaux liés aux applications devrait être suffisant pour le débogage. Automatiser le cycle de vie de l'application.

Ansible nous a aidés à automatiser les opérations standard (déployer, mettre à niveau, restaurer) sur de nombreux environnements à un seul tenant, tout en utilisant des coffres-forts cryptés distincts pour stocker les variables d'environnement sensibles telles que les hôtes, les ports et les informations d'identification. Si chaque coffre-fort ne peut être déchiffré que par différents rôles, et uniquement sur un hôte bastion, pour les opérations consignées, alors la vérifiabilité offre une sécurité acceptable. Si vous accordez SSH, utilisez svp selinux pour éviter toute falsification de clé, utilisez un hôte bastion avec une authentification LDAP / Kerberos pour l’administration et utilisez judicieusement sudo.

bbaassssiiee
la source