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

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.

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é.

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.)

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.

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.

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.

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.

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.

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.