Récemment, il y a eu beaucoup de nouvelles sur les fuites aléatoires de diverses données confidentielles d'un service Web pour l'hébergement de projets informatiques et leur développement conjoint par GitHub.
Je souligne qu'il s'agira de fuites aléatoires, c'est-à-dire survenue par négligence et sans intention malveillante de la part des auteurs des incidents. Annuler ces fuites sur l'inexpérience des employés dans les problèmes informatiques ne fonctionnera pas, car Les utilisateurs de GitHub sont majoritairement des développeurs, c'est-à-dire un personnel pleinement qualifié et compétent. Malheureusement, même de très bons spécialistes font parfois des erreurs triviales, surtout en ce qui concerne les problèmes de sécurité. Prenons la négligence.
Voici quelques exemples très célèbres liés à GitHub:
- 2014 - Uber a divulgué les données personnelles de 50 000 de ses chauffeurs. La raison en était que dans le référentiel public GitHub, les développeurs Uber ont enregistré Amazon Cloud Access Keys (AWS), qui, à son tour, a stocké les mêmes données perdues.
- 2017 - il s'est avéré que les développeurs du fabricant de quadrocoptères DJI stockaient dans le référentiel public GitHub la clé privée du certificat SSL de l'entreprise et les clés AES pour crypter le firmware. En outre, les informations d'identification pour Amazon Web Services y étaient stockées, qui contenaient à leur tour des journaux de vol, des données de passeport et des informations sur la licence client DJI.
- 2017 - Ingénieur d'un important sous-traitant informatique américain, DXC Technologies a téléchargé les clés d'accès AWS au référentiel public GitHub.
- 2017 - Des codes source, des rapports et des plans de développement pour plusieurs grandes institutions financières au Canada, aux États-Unis et au Japon, qui y ont été placés par des employés de la société d'externalisation indienne Tata Consultancy Service, dont les clients étaient des institutions financières affectées, ont été découverts dans le référentiel public GitHub.
De toute évidence, tous ces cas de fuites involontaires pourraient facilement être évités en surveillant les données téléchargées sur GitHub. Personne ne parle d'une interdiction totale de l'accès à GitHub, c'est une idée inutile et même nuisible (s'il y a une interdiction, mais le service est nécessaire, les développeurs contourneront cette interdiction). Vous avez besoin d'une solution qui empêche les fuites d'informations et dispose d'un analyseur de contenu en temps réel qui vous empêche de télécharger sur GitHub uniquement des données qui ne devraient pas être présentes pour des raisons de sécurité (par exemple, les clés d'accès au cloud Amazon).
Je vais vous montrer comment résoudre ce problème spécifique, en utilisant le DeviceLock DLP comme exemple. Les données initiales dont nous disposons sont les suivantes:
- Compte GitHub,
- Clé AWS,
- DeviceLock DLP version 8.3.
Pour commencer, nous déterminons que la clé AWS est les données protégées et qu'il faut l'empêcher d'accéder à GitHub.
Étant donné que la clé est un ensemble d'octets sans signature prononcée (oui, je connais le texte "BEGIN / END PRIVATE KEY" au début et à la fin, mais c'est une signature très faible et il vaut mieux ne pas s'y fier), nous utiliserons l'identification sur les empreintes digitales .
Nous allons ajouter le fichier de clés à la base de données d'empreintes digitales DeviceLock DLP afin que le produit «connaisse» notre clé «en personne» et puisse plus tard l'identifier de manière unique (et ne pas le confondre, par exemple, avec des clés de test qui peuvent très bien être téléchargées sur GitHub).
Créons maintenant une règle de filtrage de contenu pour les stockages de fichiers dans DeviceLock DLP (GitHub relève de notre classification «stockages de fichiers», dans laquelle, en plus de GitHub, plus de 15 services différents d'échange et de synchronisation de fichiers sont pris en charge).
Selon cette règle, il est interdit à tous les utilisateurs de télécharger des données avec des empreintes digitales qui correspondent à celles spécifiées ci-dessus, et si des données interdites sont détectées, les événements correspondants (enregistrements d'incidents) et les clichés instantanés doivent être enregistrés dans les journaux d'archivage centralisés, en plus de l'exécution réelle de l'action avec l'interdiction de télécharger des données sur GitHub .
Essayons maintenant de charger la clé AWS dans le référentiel GitHub.
Comme vous pouvez le voir, le processus de téléchargement "pour une raison quelconque" a échoué, et DeviceLock DLP nous a averti qu'il avait bloqué cette opération (bien sûr, le message est personnalisable et désactivé).
Dans le même temps, si vous consultez le journal des clichés instantanés DeviceLock DLP, vous pouvez y trouver la même clé.
Ainsi, dans cet exemple, il a été montré comment utiliser DeviceLock DLP pour résoudre le problème particulier de la prévention de la fuite de toute donnée confidentielle (les empreintes digitales peuvent être prises à partir de presque n'importe quel fichier) vers le stockage cloud.
Bien sûr, en plus d'empêcher les fuites de données sur GitHub, vous pouvez également inventorier périodiquement les référentiels et identifier les informations qui ne devraient pas s'y trouver. Dans le but d'analyser les référentiels GitHub, les utilitaires gratuits Gittyleaks, Git Secrets, Git Hound, Truffle Hog et bien d'autres ont été créés.