seguridad de control de versiones

7

Estamos buscando una herramienta de control de versiones. Personalmente creo que es genial usar Git. Sin embargo, mi jefe recomienda TFS. Me dijo que es mucho más seguro usar una herramienta basada en SQL Sever, como TFS y SourceAnywhere.

Además, mi jefe también me envió un link .

Mi pregunta es: ¿Es lo suficientemente seguro / fuerte para usar Git o SVN para uso comercial?

    
pregunta LYQ 13.08.2012 - 09:27

3 respuestas

9

no vayas con Git solo porque es "bastante bueno", úsalo porque resuelve tu problema de una manera que se adapta a tu flujo de trabajo.

En cuanto a TFS ... Martin Fowler tuvo una pequeña encuesta .

De todos modos, tiene que definir "seguridad": ¿desea proteger la fuente de usuarios no autorizados, poner una marca de solo lectura en algunas áreas o incluso evitar que algunas personas miren algunas áreas? Puede hacer esto en SVN fácilmente, usar VisualSvn Server y puede aplicar controles de seguridad r / rw en cualquier carpeta del árbol. TFS es el mismo. Git, por otro lado .. no está diseñado para esto. Git funciona según el principio de que todas las fuentes se "copian" a la estación de trabajo de cada desarrollador, para que obtengan todo el tiempo. Es parte de lo que hace que git sea especial, ya que una vez que tienes toda la fuente localmente, puedes combinar y ramificar de forma rápida y sencilla, pero significa que no puedes ponerle restricciones corporativas.

La elección del back-end no tiene sentido. Use un sistema basado en archivos, o un sistema basado en SQLServer. Es todo lo mismo, el nivel de acceso de seguridad depende de lo que permita la herramienta (y sus políticas de administración en los datos de back-end, un SQLServer con una contraseña de '' sa 'o incluso la autenticación de Windows sin restricciones permitiría a cualquier persona acceder a la base de datos).

    
respondido por el gbjbaanb 13.08.2012 - 11:29
7
  

Me dijo que es mucho más seguro usar una herramienta basada en SQL Sever

Defina (o haga que su jefe) "seguro": ¿seguridad contra pérdida de datos o control de acceso?

Este último es ciertamente más fácil en TFS (y sospecho que eso es lo que él / ella quiere). Entonces, la pregunta es: ¿a quién bloquearías el acceso?

El uso de múltiples repositorios Git con usuarios limitados que realizan extracciones de otros en el "maestro" designado (desde donde se tomarán las liberaciones) ofrecería gran parte del mismo control al mismo tiempo que ayuda a garantizar que se realicen las revisiones del código.

(He usado la seguridad TFS para bloquear el ingreso de algunos desarrolladores 1 . Esto fue una reacción a la extrema calidad 2 de su código. El uso de la seguridad TFS les permitió para obtener el código, modifíquelo pero no para verificar. En su lugar, tuvieron que enviar un conjunto de anaquel para que yo u otro lo revisen y registren (en su nombre a través de la línea de comando). La mayoría, especialmente al principio, las presentaciones fueron rechazadas.)

Update Puede haber una tercera forma. TFS en el servidor y Git en el cliente. Depende de TFS2012 (casi a RTM). Vea el anunciar la integración de Git con TFS .

1 Outsourcing anti-patrón: aquí hay 6 grandes desarrolladores, muchos reclamos en sus CV, por lo que deben ser buenos, no es necesario entrevistarlos / validarlos. Ahora harán la mayor parte del desarrollo.

2 Piensa en enlace candidatos a envío ...

    
respondido por el Richard 13.08.2012 - 10:42
3

Los proyectos de código abierto usan git para aceptar miles de contribuciones de desarrolladores completamente confiables. ¿Nadie en la administración se detiene a preguntarse cómo lo lograrán sin introducir constantemente malware? O ¿por qué las personas con los colaboradores más no confiables en realidad prefieren git?

Si no puede confiarle a sus propios desarrolladores el acceso de lectura, tiene otros problemas. Sin embargo, eso es fácil con git también. Simplemente ponga el código de acceso limitado en su propio servidor. Es incluso más fácil de proteger que los permisos en un solo servidor.

El siguiente argumento que hace la gente es: "Sí, pero con git copia todo el historial, no solo la última versión". Tengo noticias para ti. Si tiene acceso de lectura a cualquier VCS, tiene suficiente acceso para crear un repositorio git que nadie conoce. La gente hace esto todo el tiempo cuando la administración impone un VCS inferior a ellos. No lo sabes porque en realidad no crea los problemas de pesadilla que temes que haga.

Hay muchas razones por las que una empresa puede elegir otro VCS en lugar de git. La seguridad no es una de ellas. Probablemente la razón principal es que git es más un componente de un VCS que un sistema integrado. Debe agregar su propia autenticación y autorización, integración con CI y seguimiento de errores, etc. Además, git tiene mucha potencia, pero con eso viene la necesidad de bloquear los servidores para evitar el uso accidental de esa potencia y más capacitación. Si no conoce, o no quiere, flujos de trabajo más avanzados, git parece una versión innecesariamente complicada de svn.

    
respondido por el Karl Bielefeldt 13.08.2012 - 15:42

Lea otras preguntas en las etiquetas