Est-il sûr d'héberger des données sensibles sur des sites de référentiel tels que github, bitbucket, etc.?
Ceci est juste une question de curiosité. Je me demande à quel point il est généralement considéré comme sûr d'héberger des données sensibles sur des sites Web de référentiel tels que Github, Bitbucket, etc. Est-il assez sûr de se débarrasser de tout le code sur les machines locales et de tout stocker dessus? Qu'en est-il de la sécurité dans le sens de garder les secrets de l'entreprise? Je remarque que ces sites vantent les grandes entreprises comme Google et Yahoo utilisent leurs services, mais ces grandes entreprises conservent-elles leurs secrets commerciaux et leur code d'entreprise important sur des sites Web comme celui-ci?
Github a une page ( http://help.github.com/security ), qui contient des informations intéressantes, qui montre qu’elle le commercialise comme quelque chose d’incroyable, comme je l’ai décrit plus haut. Mais dans la pratique, les grandes entreprises comme Google constatent-elles vraiment que leurs secrets propriétaires et leurs énormes quantités de code sont vraiment à l'abri des regards indiscrets et des événements désastreux sur des sites comme ceux-ci?
Comme toujours, ça dépend :-)
Il peut y avoir deux significations différentes de "sécurité":
- Puis-je faire confiance à l'hébergeur pour qu'il garde mes affaires (propriété intellectuelle, secrets d'entreprise ...) confidentiels?
- Qu'advient-il de mon code si l'hébergeur devient soudainement hors service?
Pour 1., il n'y a pas de garantie à 100%.
Bien sûr, les gros hébergeurs comme GitHub et Bitbucket ne partageront pas votre code intentionnellement avec des tiers, mais il est toujours possible qu'un pirate informatique parvienne à récupérer le contenu de vos dépôts privés.
(cela pourrait vous arriver aussi si vous hébergez votre code en interne dans votre entreprise, mais cela est peu probable, car à moins que votre entreprise ne soit connue sous le nom de Google, par exemple, le risque que quelqu'un essaie d'attaquer votre entreprise est beaucoup plus faible que le risque que quelqu'un essaie d'attaquer un hébergeur public bien connu).
De plus, vous devez tenir compte des lois du pays où réside l'hébergeur.
Il y a quelques semaines, j'ai lu quelque part que si votre hébergeur se trouvait aux États-Unis, il pouvait être contraint par la loi de communiquer vos données au gouvernement des États-Unis dans certaines circonstances, et ces derniers ne sont même pas autorisés à ne me souviens pas du nom de la loi, mais peut-être que quelqu'un d'autre le sait).
Je suppose que tout cela force la plupart des "grandes" entreprises à pas héberger leur code sur un service public (mon entreprise est de taille moyenne et nous hébergeons également notre code privé).
En passant, comme vous l'avez mentionné Google:
Je suis sûr que Google, en particulier, n'utilise pas Bitbucket ou GitHub. Ils ont eux-mêmes infrastructure complète pour l'hébergement de projet , alors je suppose qu'ils l'utilisent également en interne. Pourquoi devraient-ils utiliser un service externe? C'est dans le nuage, oui ... mais c'est leur nuage.
Concernant le point 2: il est peu probable que GitHub ou Bitbucket fasse faillite demain, mais on ne sait jamais.
OMI, il est de votre responsabilité de créer vous-même des sauvegardes de votre code.
La nature de DVCS garantit de toute façon que vous disposiez de copies locales de votre code, mais il peut s'avérer difficile de rechercher dans de nombreuses machines de développement les versions les plus récentes de tous vos projets.
Je le fais en tirant régulièrement tous mes dépôts sur ma machine locale (j’ai écrit un outil qui peut le faire pour Bitbucket, que j’utilise pour mes projets privés)
Une des questions clés est de savoir qui a l'accès administratif. Cette personne ou ces personnes peuvent toujours lire vos données et éventuellement les divulguer à des tiers, sciemment ou non, ou simplement les lire pour leur propre divertissement ou leur éducation. Ce n'est pas seulement un problème pour les services hébergés, c'est aussi un problème si vous stockez vos données au sein de votre propre entreprise. Mais au moins, vous connaissez la personne. Pour les petites entreprises, le mot de passe administratif peut être entre les mains du propriétaire de l'entreprise.
Le point principal est que les sociétés d’hébergement de code publiques sont une cible si énorme. Il y a beaucoup à gagner à pirater un aussi grand référentiel de code. Il s’agit d’une cible très intéressante pour les agences gouvernementales. Elle est tellement importante qu’elle se fie à un initié de la société d’hébergement qui se contente de prendre une clé USB contenant toutes les données sur son retour. Cela pourrait être aussi simple que de postuler à un emploi d'administrateur et même de vous faire payer tous les avantages. Je ne pense pas que nous verrons jamais de nouvelles à ce sujet, simplement parce qu'il n'y a aucune trace à attendre, à moins que quelqu'un veuille s'en vanter. Autant que je sache, les entreprises d’accueil n’ont pas besoin d’autorisation de sécurité, contrairement aux agences gouvernementales. Et le fait que tout cela soit en mode furtif met très peu de pression sur une société d'hébergement pour qu'elle fasse quoi que ce soit.
Pour mémoire: Tout d’abord, un référentiel est une sauvegarde, puis plus tard, il concerne la sécurité.
À ce jour, nous ne voyons pas encore d'infraction de sécurité impliquant GitHub ou Bitbucket. Donc, empiriquement, ils sont en sécurité.
Cependant, nous montrons nos informations à une entreprise privée, il y a donc un risque, par exemple un employé de Github qui décide de copier nos données.
Cependant, nous devons nous rappeler qu'un référentiel est principalement une sauvegarde. Avoir un serveur privé est bien si vous possédez les ressources. Mais, nous devrions également considérer l'emplacement du serveur. Si c'est au même endroit, il y a un risque de perte de toutes les informations, par exemple une inondation, un incendie, un Thunderbolt faisant frire toutes nos machines et ainsi de suite. Donc, un dépôt distant est vraiment cool.
Si vous souhaitez utiliser un référentiel distant, alors ne soyez pas trop évident. Disons que vous êtes Cocacola Corp et que vous voulez gérer un projet important, alors ne créez pas de compte avec le nom de l'entreprise et n'appelez pas le projet sous le nom IMPORTANT_SECRET_VITAL_FOR_COCACOLA, appelez-le simplement PROJECT1. s'en foutra.