¿Qué tan seguro es alojar datos confidenciales en sitios de repositorys como github, bitbucket, etc.?

Esta es solo una pregunta por curiosidad. Me pregunto qué tan seguro se considera que aloja datos confidenciales en sitios web de repositorys como Github, Bitbucket, etc. ¿Es lo suficientemente seguro deshacerse de todos los códigos en las máquinas locales y simplemente almacenar todo allí? ¿Qué hay de la security en el sentido de save secretos de la empresa? Observo que estos sitios pregonan que las grandes compañías como Google y Yahoo usen sus services, pero, ¿acaso estas grandes empresas almacenan sus secretos comerciales y su importante código de empresa en sitios web como este?

Github tiene una página ( http://help.github.com/security ), que tiene información interesante, que muestra que la están comercializando como algo a testing de tontos como lo describí. Pero en la práctica, ¿las grandes compañías como Google realmente descubren que sus secretos patentados y cantidades masivas de código están realmente a salvo de miradas indiscretas y ocurrencias desastrosas en sitios como estos?

Como siempre, depende 🙂

Puede haber dos significados diferentes de "security":

  1. ¿Puedo confiar en que el hoster mantendrá mis cosas (propiedad intelectual, secretos de la empresa …) en privado?
  2. ¿Qué le sucede a mi código si el hoster se desconecta repentinamente?

Para 1., no hay garantía del 100%.
Por supuesto, los grandes hosters como GitHub y Bitbucket no compartirán tu código intencionalmente con terceros, pero siempre existe la posibilidad de que algún hacker logre get el contenido de tus repositorys privados.
(Esto también podría sucederle si aloja su código internamente en su empresa, pero esto es poco probable, porque a less que su empresa sea tan conocida como, por ejemplo, Google, la posibilidad de que alguien intente atacar a su empresa es mucho menor que la posibilidad de que alguien intente atacar a un proveedor público conocido).

Además, debes tener en count las leyes del país donde reside el hoster.
Hace algunas semanas leí en alguna parte que si su proveedor de alojamiento de services de hospedaje se encuentra en los EE. UU., En virtud de la ley puede obligarlos a entregar sus datos al gobierno de EE. UU. En determinadas circunstancias, y ni siquiera se les permite informarlo (yo no recuerde el nombre de la ley, pero tal vez alguien más lo sepa).

Supongo que todo esto hace que la mayoría de las "grandes" empresas no alojen su código en un service público (mi empresa es de tamaño medio, y nuestro código también es privado).

Por cierto, como mencionaste Google:
Estoy seguro de que especialmente Google no usa Bitbucket o GitHub. Tienen la infraestructura completa para el alojamiento de proyectos , así que supongo que también lo están usando internamente. ¿Por qué deberían usar un service externo? Está en la nube, sí … pero es su nube.

Respecto de 2 .: es poco probable que GitHub o Bitbucket quiebren mañana, pero nunca se sabe.
OMI es su responsabilidad realizar copys de security de su código usted mismo.
La naturaleza de DVCS asegura que usted tenga algunas copys locales de su código de todos modos, pero puede ser difícil search muchas máquinas de desarrollador para las versiones más recientes de todos sus proyectos.
Hago esto tirando todos mis repositorys a mi máquina local regularmente (escribí una herramienta que puede hacer esto para Bitbucket, que uso para mis proyectos privados)

Miré a GitHub hace un momento, y en comparación con nuestro alojamiento anterior de git (que estaba en nuestro propio server virtual de Linux), no estoy demasiado impresionado con la security. Lo usamos, pero solo para los proyectos se mantuvo el código fuente privado no es una gran preocupación.

A saber:

  1. No hay control de la compañía en absoluto sobre las counts de usuario. Controlamos qué usuarios tienen acceso a nuestro repository, pero no hay políticas de passwords, los usuarios eligen sus propias direcciones de correo electrónico, etc.
  2. No hay forma de limitar el acceso por dirección IP
  3. Las passwords solo pueden ser restablecidas por el usuario
  4. Comprometer la count de correo electrónico de los usuarios (que no podemos ver en qué count lo han configurado) también da como resultado un compromiso de su count de github, ya que usan un desafío por correo electrónico para restablecer las passwords olvidadas.
  5. No hay loggings de acceso (hay una pista de auditoría para la mayoría o posiblemente todos los cambios, pero no para el acceso)
  6. El acceso a la interfaz web solo está protegido con contraseña, por lo que es vulnerable a la reutilización de passwords de otros sitios y, en cierta medida, al forzamiento bruto (la statement de github sobre lo que hacen para los inicios de session fallidos es bastante incierta).

Uno o dos de estos podríamos vivir, pero en combinación básicamente hacen que Github sea completamente inadecuado.

Recientemente han agregado la authentication de 2 factores, y hay una API para que las organizaciones puedan al less verificar si los usuarios con acceso a sus repositorys tienen activada la authentication de dos factores. Aunque no creo que esta sea realmente la mejor solución, es probable que Github se convierta en algo suficientemente seguro como para considerarlo para repositorys privados.

En su lugar, puede ejecutar una installation empresarial, lo que presumiblemente mejora significativamente la security, pero la diferencia de costo entre eso y una count estándar de la compañía github es asombrosa, y probablemente signifique que se pierda todas las herramientas de terceros que se integran con github.

GitHub anunció recientemente nuevos planes de negocios con características adicionales , esto podría resolver '1' / '4' / '5'. (Aunque la 'garantía de time de actividad' que es parte es bastante ridícula, ni siquiera "cuatro nueve", y excluye el mantenimiento progtwigdo y cualquier cosa que consideren 'fuera de su control razonable') y no es una garantía real, es solo un pequeño crédito contra su próxima factura, que tiene un tope de no más de un tercio de su factura. Básicamente, palabras de comadreja de comercialización networkingactadas con mucho cuidado, en lugar de cualquier tipo de compromiso de ellas).

Para el logging: Primero, un repository es una copy de security, luego se trata de security.

Hasta la date, aún no hemos visto una violación de security que involucre a GitHub o Bitbucket. Entonces, empíricamente hablando, están a salvo.

Sin embargo, estamos mostrando nuestra información a una empresa privada, por lo que existe un riesgo, por ejemplo, un empleado de Github que decide copyr nuestras cosas.

Pero, debemos recordar que un repository es principalmente una copy de security. Tener un server privado está bien si posee los resources. Pero, también debemos considerar la location del server. Si está en el mismo lugar, entonces existe la posibilidad de que se pierda toda la información, por ejemplo, una inundación, un incendio, un rayo que frena todas nuestras máquinas, etc. Entonces, un repository remoto es realmente genial.

Si desea usar un repository remoto, no sea demasiado obvio. Digamos que usted es Cocaqueue Corp y desea administrar un proyecto importante, luego no cree una count con el nombre del negocio y no llame al proyecto como IMPORTANT_SECRET_VITAL_FOR_COCACOLA, simplemente llámelo PROJECT1 y si un pirata informático ataca, entonces él no me importará