Las mejores prácticas para la información confidencial en el control de fuentes

Sé que este tema se ha cubierto bastante pero no puedo encontrar una respuesta a mi situación específica.

Actualmente, estoy usando .gitignorepara excluir contenido confidencial y mantenerlo (archivos de configuración, etc.) por separado. A medida que mi código base se expande en más y más proyectos, esto se está volviendo bastante difícil de administrar y tampoco tengo una forma real de rastrear los cambios o hacer una copia de seguridad de los archivos correctamente.

Hay algunas herramientas para este problema, como git-secret, Hashicorp Vaulty git-cryptninguna de ellas funciona con Windows, donde realizo todo mi desarrollo (por varias razones).

Actualmente, soy el único desarrollador que trabaja en mi empresa sin planes de expansión. El control de fuente (Gitlab) se utiliza principalmente para mi propia referencia y capacidad para registrar cambios. ¿Insertar algunas cadenas de conexión o archivos de configuración en el control de origen sería un gran problema o riesgo? Esa información se encuentra actualmente en una unidad de red, no segura (excepto los permisos NTFS)

Tengo la idea de que la mejor práctica es no llevar estas cosas al control de la fuente, pero tengo una instancia de Gitlab alojada de forma privada que no es accesible fuera de la red local. ¿Significa esto que hay menos riesgo?

Pensando en esto de manera integral, hay varias cosas a considerar:

• ¿El servidor GitLab está alojado en la misma red que el entorno de destino?
• ¿Tiene nombres de usuario y contraseñas en sus archivos de configuración?
• ¿Se puede separar la configuración de seguridad de la configuración normal de la aplicación?

La primera preocupación tiene que ver con la política. Si el software se implementará en una red separada, es posible que tenga problemas de política, incluso si sus configuraciones están encriptadas.

Evitar información sensible

Sé específico sobre lo que es sensible. Por ejemplo, el nombre de dominio de un servidor puede no ser sensible, pero su dirección IP puede ser (o la asociación de los dos). Por lo general, los nombres de usuario y las contraseñas son confidenciales, así como las claves secretas y clientId (OAuth2).

Sus mejores opciones son:

• Utilice cadenas de conexión que no requieran nombre de usuario / contraseña (ver más abajo)
• Separe la información confidencial de la configuración principal de Web.
• Use el atributo de archivo en AppSettings para leer un archivo de configuración externo

Algunas bases de datos le permiten tener una cadena de conexión donde el nombre de usuario y la contraseña no forman parte del contenido. Por ejemplo, puede ejecutar su aplicación con una cuenta de servicio de dominio para conectarse a SQL Server utilizando seguridad integrada. O puede usar Oracle's Wallet para mantener el nombre de usuario / contraseña en secreto en la máquina de destino. Algunos servicios de OAuth2 le permiten usar un archivo .csv o .json almacenado en la máquina en una ubicación estándar.

En otras palabras, haga lo que pueda para evitar guardar información confidencial donde no pertenece. Si tiene que hacer modificaciones en su aplicación para buscar en una ubicación en el disco para leer los bits confidenciales, puede configurarlo una vez en cada servidor de destino y simplemente leerlo desde su aplicación.

Servidores de configuración

Steeltoe ha estado portando ciertas bibliotecas de integración de Spring a C #, e incluso tienen soporte para servidores Spring Cloud Config . El servidor Spring Cloud Config requiere un repositorio Git en la red de implementación , pero le permite personalizar la configuración donde debe estar. Si su aplicación es lo suficientemente compleja (es decir, microservicios), entonces sería algo que vale la pena considerar para mantener protegidos los nombres de los servidores en el mismo entorno en el que se encuentran los servidores.

Línea de fondo

Solo desea evitar la necesidad de la información confidencial tanto como sea posible, pero mantener las configuraciones no sensibles en el control de origen. Si no puede evitar el nombre de usuario / contraseña en su archivo de configuración (es decir, una base de datos diferente que no tiene un equivalente a la seguridad integrada), cargue ese pequeño bit desde un archivo externo.

El mejor lugar para almacenar información confidencial es una tienda especialmente diseñada, Hashicorp Vaultque es compatible con Windows.

Si (por alguna razón) no puede usar esto, también puede usarlo, git-secretque también es compatible con Windows. Se agregó soporte para Windows git-secreten este PR: https://github.com/sobolevn/git-secret/pull/123

git-crypt También tiene soporte experimental para Windows:

https://github.com/AGWA/git-crypt/wiki/Installation

/programming/43040370/how-to-install-git-crypt-in-windows