2009-03-18 20 views
9

Tengo una aplicación Java simple que se supone que se conecta a la base de datos. No quiero almacenar URL de conexión a la base de datos y nombre de usuario/contraseña en un archivo de propiedades ni codificarlo en la aplicación. ¿Qué es una forma común para resolver este problema? ¿Cómo se puede conectar una aplicación Java a la base de datos sin revelar el nombre de usuario/contraseña?Conexión JDBC segura

Respuesta

3

Si no está dispuesto a almacenarla, usted tiene que solicitar para ello. Puede encriptar la contraseña, pero luego tiene que tener una clave para descifrarla y está atrapado en el mismo problema.

+0

derecha - que pueden ser una buena opción. Hay otra opción: almacenar el nombre de usuario/contraseña en una ubicación separada y permitir que mi aplicación Java obtenga esa combinación u/p sin revelarlos al usuario que la está ejecutando a través de algún tipo de biblioteca proxy. o JNDI? – Alex

5

Soy un desarrollador .NET, pero me he encontrado con la misma situación.

El año pasado estaba trabajando en una empresa que tenía que cumplir con PCI para almacenar datos de tarjetas de crédito, por lo que la seguridad era un gran problema. La URL/datos de inicio de sesión debe existir en alguna parte. El método más común que he visto para asegurarlo es con el cifrado. No sé sobre Java en particular, pero .NET tiene varios espacios de nombres de encriptación en el núcleo de Framework. Los usamos para encriptar los inicios de sesión de la base de datos.

todavía tiene una vulnerabilidad de seguridad potencial, que son las claves de cifrado utilizadas para cifrar/descifrar los datos. Utilizamos el método de "control de compensación" PCI aquí. El acceso a las claves está restringido al rol de "gestión de claves". También rastreamos el acceso de la clave en sí, de modo que haya un registro de todos los inicios iniciados por el usuario y el acceso iniciado por el sistema. Ningún usuario tenía acceso a estos registros, por lo que no podría haber cobertura de pistas por un único usuario. Estos métodos de seguridad superpuestos esencialmente crean una situación en la que se requiere nada menos que una conspiración coordinada entre múltiples administradores para poner los datos en peligro.

0

La mejor manera sería la de almacenar la información como fuente de datos configurada en el contexto JNDI del servidor de aplicaciones. A continuación, puede usar las funciones del servidor de aplicaciones para configurar las fuentes de datos en el momento del despliegue. Todo lo que la aplicación tiene que hacer es buscar el nombre JNDI apropiado en tiempo de ejecución y usarlo. Este es un patrón común para las aplicaciones web de Java.

+0

Derecha. Pero mi aplicación no se está ejecutando dentro del servidor de aplicaciones. Es una aplicación de Java independiente. sí, puedo conectarme a JNDI desde allí y puedo obtener una referencia de fuente de datos, pero no es una práctica recomendada. El origen de datos JNDI solo debe ser utilizado por aplicaciones que ejecuten el servidor de aplicaciones INSIDE. – Alex

+0

Sin embargo, todo lo que realmente hace aquí es eliminar el problema. Ahora debe preocuparse por cómo el servidor de la aplicación maneja esa información. De nuevo, o el servidor tiene acceso claro o tiene que proporcionar una clave para el servidor de la aplicación. –

2

Una de las soluciones comunes a este problema para aplicaciones basadas en servidor es almacenar el nombre de usuario y la contraseña en un archivo que tenga permisos de usuario configurados de tal manera que solo el usuario ejecutor de la aplicación/servicio pueda leer su contenido.

Por ejemplo, ejecuta su aplicación como usuario foo-service y hereda todos los privilegios de acceso del usuario de foo-service. El archivo que contiene el nombre de usuario y la contraseña solo es legible por ese usuario. Usted lee el valor del archivo y se conecta a la base de datos normalmente.

Posibles problemas con este enfoque:

  • El superusuario de esta máquina puede ser capaz de obtener la contraseña de la base de datos.
  • Un atacante que ha penetrado en la seguridad de su aplicación puede obtener acceso a las credenciales de la base de datos.

Los problemas anteriores se mitigan normalmente ajustando los privilegios de acceso para la aplicación a la base de datos y la red. Casi cualquier otra solución que surja lo llevará a un problema de huevo y gallina porque básicamente está tratando de esconder algo de sí mismo.

0

servicios de uso de Internet para separar su aplicación desde el servidor haciendo el acceso a la base de datos. Firme su aplicación web y luego solo permita que una aplicación debidamente firmada llame al servidor de servicios web.

0

Puede intentar cargar un archivo utilizando las propiedades del sistema. -Dapplication.configuration = application.properties.

Cuando no se pasa el archivo de propiedad, entonces debe usar el archivo predeterminado con la configuración predeterminada.

Cuando existe el archivo, anula los valores predeterminados con los valores proporcionados desde la configuración.

java -Dlog4j.configuration = file: /log4j.properties -Dapplication.configuration = file: /live-conf.conf-jar app.jar "applicationarg1" "applicationarg1"

más fuentes a seguir: https://docs.oracle.com/javase/tutorial/essential/environment/properties.html

Cómo reemplazar las propiedades del sistema:

-Dproperty = valor Establecer un valor de propiedad del sistema. Si el valor es una cadena que contiene espacios, debe encerrar la cadena entre comillas dobles:

http://docs.oracle.com/javase/6/docs/technotes/tools/windows/java.html

Cuestiones relacionadas