Est-il urgent de révoquer l'accès à un repo privé une fois qu'une personne a été accordée par erreur et d'en prendre connaissance?
Il y a eu n article sur Niebezpiecznik.pl , un blog InfoSec populaire, décrivant une situation intéressante.
Une entreprise a accordé par erreur l'accès à leur référentiel BitBucket à un programmeur aléatoire. Ce programmeur a par la suite alerté divers employés de l'entreprise, les exhortant à révoquer l'accès dès que possible. Il a trouvé ces employés paresseux (par exemple, l'un a dit qu'il ne révoquerait l'accès qu'à son retour de vacances), a donc alerté le blog Niebezpiecznik, qui a ensuite contacté l'entreprise. Ce n'est qu'alors que l'accès a été révoqué.
Il est clair que le programmeur a considéré que le manque de révocation rapide de l'accès était une erreur très grave au nom de la politique de sécurité de l'entreprise. Et c'est là que je suis surpris.
Alors, considérons cela du point de vue de l'entreprise. Quelqu'un les a contactés, affirmant qu'il avait faussement obtenu l'accès à leur dépôt privé et les exhortant à retirer cet accès. Maintenant, cette personne est ou n'est pas intéressée par le contenu de ce dépôt; il a aussi ou n'a pas des valeurs morales assez fortes pour s'abstenir de le télécharger. S'il est disposé à inspecter le contenu du dépôt, il a déjà eu amplement le temps de le faire; et s'il ne l'a pas encore fait, il ne l'aura probablement pas encore fait lorsque l'employé sera de retour de vacances. En d'autres termes, le lait a déjà coulé et rien de pire que ce qui s'est déjà produit ne risque de se produire à l'avenir.
En conséquence, je pense que la situation n'est plus urgente et peut profondément attendre que l'employé revienne de ses vacances.
Où ai-je tort?
Il y a plusieurs raisons:
- Si cela est arrivé à une seule personne, cela aurait pu arriver à plus. Ces autres personnes pourraient ne pas être aussi gentilles.
- Qui sait, cette personne pourrait changer d'avis. Quand ils ont fait l'effort de vous contacter, et reçoivent juste un "meh" en retour, ils pourraient être un peu ennuyés et décider de vous punir pour cela.
- Ou peut-être qu'ils veulent juste fouiner un peu pour le plaisir et casser accidentellement quelque chose.
- Vous voudrez probablement vérifier les journaux pour voir que cette personne dit la vérité. Peut-être qu'ils ont volé vos clés de chiffrement en silence avant de vous contacter. Vous voulez probablement faire pivoter tous vos secrets juste pour être sûr.
- Et surtout, il s'agit d'un Big F * cking Deal ™. Quiconque ne réagit pas avec choc et horreur, mais ordonne à la place une autre piña colada, ne comprend clairement pas la gravité de la situation.
Il y a de très bons points dans les commentaires et cette réponse que tout pourrait bien se passer dans certaines circonstances (par exemple, accès en lecture seule, aucun secret dans le code, etc.). C'est exact, mais je dirais quand même que cela devrait être pris plus au sérieux. Êtes-vous vraiment sûr à 100% qu'il n'y a pas de secret dans un vieux commit de votre repo? Le fait même que quelqu'un qui ne devrait pas avoir accès à vos systèmes l’ait de toute façon est en soi un mauvais présage.
Bien qu'il soit impossible de lire dans les pensées des personnes en jeu - je pense que le programmeur indépendant
A) Ne veut pas être accusé d'irrégularité - Il est beaucoup plus difficile d'être accusé de vol de propriété intellectuelle si vous criez et criez pour que votre accès soit révoqué après la hâte.
B) Est consterné par la posture de sécurité de l'entreprise qui contrôle le référentiel privé et sait que s'il était responsable, il voudrait être informé.
Une chose à noter est que donner à un utilisateur supplémentaire un accès à un référentiel ouvre un tout nouveau vecteur d'attaque possible. Si quelqu'un d'autre avec des intentions malveillantes a accès au compte auquel le repo a été accordé sans que le titulaire du compte d'origine ne le sache, cette personne pourrait facilement télécharger l'intégralité de votre code source.
Pour fournir un point de vue différent de la majorité, cela ne devrait vraiment pas être un risque pour la sécurité iff le projet est bien géré.
Il y a fondamentalement deux choses qui doivent être remplies. Tout d'abord,
- Vous ne pouvez pas introduire de code dans les branches de publication sans que d'autres personnes aient à le signer. Cela est généralement réalisé en exigeant des demandes d'extraction et des révisions de code sur tout code entrant dans une branche de publication. Dans ce cas, si la personne n'a obtenu qu'un accès en lecture au référentiel, vous n'avez pas à vous en préoccuper. Mais vous devriez tout de même avoir cela en place.
et deuxièmement
- Personne n'inclut de secrets dans le référentiel. Oui, vous pourriez avoir des clés d'API secrètes, des certificats de signature de code et quoi d'autre, mais les vrais devraient JAMAIS être dans votre référentiel principal accessible à tous. Si certains secrets sont requis pour que le code fonctionne, incluez des versions fictives de développement/test dans votre référentiel. Mais les vrais doivent être conservés séparément avec seulement un petit nombre de personnes ayant accès, de préférence afin que votre système de construction les inclue automatiquement sans intervention manuelle.
Si les deux sont vrais, je ne vois vraiment aucun mal du point de vue de la sécurité. La question de savoir s'il existe de précieux secrets commerciaux dans le code qui pourraient être divulgués à un concurrent est un sujet différent.
Ou une autre façon de penser: la situation ici n'a rien de spécial. Vous devez faire face aux mêmes problèmes, chaque fois qu'un employé quitte! Si votre référentiel contenait des secrets, une personne externe les connaît tous maintenant.
Si des trucs sont volés, regardez d'abord quelles personnes ont la clé du coffre-fort.
J'ai donné des coups de pied et des cris dans le passé, pour ne pas avoir que clé, donc si (quand) quelque chose était volé, ils ne me regarderaient pas comme un auteur potentiel.
Donc, cela pourrait avoir été le même pour ce programmeur. Il ne voulait pas avoir la clé that.
Vous avez raison de dire que la situation pourrait ne pas être urgente du tout et que la réaction laxiste des employés pourrait être justifiée. Peut-être que l'employé ne s'est pas soucié du problème parce que le code en question n'était plus utilisé ou qu'il n'avait aucun secret.
J'ai déjà travaillé pour une startup où tout le monde utilisait les mêmes clés SSH parce que quelqu'un pensait qu'il serait plus facile de supprimer/remplacer une clé si quelqu'un fait quelque chose de stupide.
Il y a aussi la possibilité que le développeur ait sa clé stockée dans une machine accessible au public comme un ordinateur à l'université. Cela peut sembler très peu sûr, mais convient pour "Hello World" et "Practice Papers".
Dans ce cas, comme vous l'avez dit, l'entreprise peut être relativement sûre que la personne qui a signalé l'incident n'essaiera pas de lui faire du mal. Mais vous ne pouvez jamais être sûr de qui a accès au compte/clés de la personne qui a signalé l'incident.
Je ne lis pas le polonais, alors pardonnez tout ce qui a déjà été abordé:
Bitbucket héberge les dépôts git et Mercurial - les deux sont distribués CVS; ceux-ci sont généralement incompatibles avec les contrôles technologiques pour protéger la propriété intellectuelle/empêcher la sortie de la propriété intellectuelle; tout clone/fork existant pourrait être cloné sans visibilité de piste d'audit centrale.
Des contrôles de sécurité appropriés doivent être en place pour modifier tout référentiel, par exemple.
- Approbation de l'ICP pour tous les commits
- repo en lecture seule avec demandes de tirage
Ainsi, tout dommage possible est déjà fait.
La sécurité - au bout du compte - est un ensemble de processus et de procédures et un état d'esprit. C'est pas un ensemble de règles rigides et rapides. Si vous pensez qu'un système est vulnérable en raison de un misérable violation, votre état d'esprit de sécurité dans son ensemble est au mieux défectueux et pourrait être utile uniquement pour Henny Penny/Chicken Little .
Si les informations d'identification ne sont pas exposées, qui s'en soucie? D'après mon expérience en tant que codeur, administrateur de systèmes Linux et gars de nettoyage/réparation de sécurité, le plus gros problème avec le code être exposé dans un repo est simplement le risque que les informations d'identification soient exposées. La réalité est la plupart les codeurs sensés savent coder sans coder en dur les informations d'identification dans leur code. Mais la plupart des codeurs sont simplement paresseux et savent pourquoi - ou comment - quelqu'un peut concevoir un système avec des informations d'identification séparées du code principal.
Donc, si ce système était géré par des codeurs sensés et que le dépôt n'expose pas les informations d'identification, vous savez quoi? On s'en fout. Mais - comme beaucoup d’entre nous le savent déjà - il existe des codeurs de niveau "flic de centre commercial" minables qui ne font qu’introduire des informations d’identification dans le code de base et c’est tout. Vous devez le jouer à l'oreille.
L'exposition au secret commercial est un risque. Cela dépend de l'industrie et des exigences sous lesquelles le code a été créé. Si le code est pour un blog ou un simple site Web? Peu importe. Même s'il s'agit d'un site de commerce électronique, s'il s'agissait d'une copie localisée de quelque chose comme Magneto, ce n'est pas vraiment un risque puisqu'il s'agit d'un logiciel open source. Mais si ce logiciel était quelque chose de propriétaire et risqué à exposer - comme quelque chose qui pourrait exposer des dossiers financiers et peut-être même du nouveau code à un jeu - alors c'est un risque.
Mais à la fin de la journée, le travail d'un pirate "chapeau blanc" est d'informer les autres sur les problèmes. S'ils vont prendre un "Qui s'en soucie?" attitude envers l'exposition, c'est leur problème. Peut-être qu'ils ne voient vraiment aucun risque? Peut-être qu'ils ne s'en soucient vraiment pas et que l'exposition nuira aux autres? Ce sont peut-être des idiots? Peut-être qu'ils sont si intelligents que l'exposition au code ne signifierait que - peut-être - quelques jours de refactorisation pour limiter les risques? Mais à la fin de la journée, il y a tellement de choses à faire pour empêcher quelqu'un de se faire du mal.