Cuando se escribe una API y se conecta a la base de datos, ¿qué información es confidencial y debería protegerse?

Question

Cuando se escribe una API y se conecta a la base de datos, ¿qué información es confidencial y debería protegerse?

#1 de user52472 (2 votos)
#2 de John Deters (1 votos)

1

Estoy en un equipo que está escribiendo una API .NET Core para dar servicio a una aplicación de escritorio. Esta aplicación utilizada para administrar su propia conexión de base de datos a través de OracleConnection, y todos los valores utilizados para conectarse a la base de datos, incluida la contraseña, se incluyeron en el código (sí, lo sé).

Actualmente estamos moviendo estos valores a una ubicación segura, pero mi pregunta es, ¿qué valores debemos ocultar? Obviamente la contraseña debe estar en esta lista. ¿Pero también debemos ocultar el host, el nombre del servicio, los nombres de los paquetes, el puerto, el nombre del servicio o la ID de usuario? ¿Algo que no esté en esta lista que debería estar absolutamente oculto?

.net sensitive-data-exposure

pregunta kleineg 02.02.2017 - 23:01

fuente

2 respuestas

Lea otras preguntas en las etiquetas .net sensitive-data-exposure

Cómo el firewall de estado a nivel de aplicación afecta el rendimiento de la red ¿Cuáles son algunas tácticas para superar el problema de externalidad de los desarrolladores que no reciben suficiente capacitación en seguridad? [cerrado]

score 2 · Answer 1

La respuesta real es que dependerá de los requisitos de seguridad del cliente y su modelo de amenaza, pero le daré lo que creo que son las mejores prácticas.

Las credenciales reales de la base de datos nunca deben abandonar el servidor de la base de datos. La aplicación de escritorio llamaría al servicio y el servicio llamaría a la base de datos. Esto le permitirá colocar su servidor de base de datos en una parte aislada de la red y reducirá su superficie de ataque.
Cada usuario debe tener credenciales únicas para el servicio. Esto es absolutamente un requisito. No tiene sentido hacer nada de esto si no tiene inicios de sesión únicos.
La comunicación con el servidor también debe estar cifrada. Utilice SSL. Incluso si se trata de una aplicación de intranet.
Un sistema de inicio de sesión único (SSO) es ideal para administrar las credenciales únicas. Piense en Active Directory, si está en un entorno de Windows.
Si un sistema SSO no es posible, entonces las contraseñas deben cifrarse cuando estén en el disco. Hay múltiples formas de hacer esto. Si es posible, use un llavero integrado en el sistema operativo o alguna otra solución preexistente que haya sido probada profesionalmente. No recomendaría cifrar nada más que la contraseña, ya que potencialmente puede abrir más ataques en el sistema de cifrado. Todos los detalles del servidor (nombre de host, puerto, etc.) serán visibles para cualquier persona que tenga acceso a la red o pueda ejecutar netstat en la máquina de todos modos.

Espero que ayude.

score 1 · Answer 2

Para que una aplicación interna autentique una conexión de base de datos, el cliente obviamente necesitará saber el nombre y el puerto del servidor. Pero cualquier información que presente a los usuarios tiene el potencial de simplificar el trabajo de un atacante. Si sus usuarios no lo necesitan, intente no dárselos.

Vea qué tipos de mecanismos de autenticación están disponibles que no impliquen que su cliente tenga que almacenar o administrar nombres de usuario y contraseñas. Para una máquina Windows que se conecta a Oracle, intente agregar Integrated Security=yes en la cadena de conexión. Eso pasará la identidad y la autoridad de su usuario al servidor, y no tendrá que almacenar nada en el cliente. Por supuesto, deberá asegurarse de que sus usuarios sean miembros de grupos que tengan los derechos de acceso necesarios para conectarse a la base de datos y usarla. Pero puede administrar todo eso a través de Active Directory, y no debería necesitar ingresar nombres de usuario en su aplicación o en su base de datos Oracle.