oracle - conexion - ojdbc7
¿Cómo evitar el almacenamiento de credenciales para conectarse a Oracle con JDBC? (11)
Además de las soluciones que ya se mencionaron (autenticación Kerberos, usando autenticación de proxy), existen otras dos soluciones que funcionan con el controlador delgado JDBC:
- Almacene la contraseña en una billetera SSO: se puede usar una billetera para almacenar la contraseña del usuario. Si usa una billetera SSO, la billetera no tiene una contraseña. Las billeteras SSO se usan comúnmente en el contexto de SSL, pero también se pueden usar para almacenar una contraseña.
- Use SSL con autenticación de usuario: configure SSL con un usuario que esté autenticado externamente por el nombre distinguido (DN). Este usuario no tiene una contraseña. Siempre que se conecte con SSL utilizando un certificado que tenga este DN, podrá crear una sesión utilizando este usuario.
¿Es posible configurar una conexión JDBC con Oracle sin proporcionar información de nombre de usuario / contraseña en un archivo de configuración (o en cualquier otra ubicación legible estándar)?
Normalmente, las aplicaciones tienen un archivo de configuración que contiene parámetros de configuración para conectarse a una base de datos. Algunos DBA tienen problemas con el hecho de que los nombres de usuario y las contraseñas están en texto claro en los archivos de configuración.
No creo que esto sea posible con Oracle y JDBC, pero necesito una confirmación ...
Un posible compromiso es cifrar la contraseña en el archivo de configuración y descifrarla antes de configurar la conexión. Por supuesto, la clave de descifrado no debe estar en el mismo archivo de configuración. Esto solo resolverá la apertura accidental del archivo de configuración por usuarios no autorizados.
Como no estoy del todo claro sobre su entorno, aparte de Java y JDBC hablando con Oracle, hablaré sobre eso.
Si está hablando de una aplicación Java EE, debería poder configurar grupos de conexiones y orígenes de datos en el servidor de la aplicación, luego su aplicación se comunica con el grupo de conexiones que maneja la conectividad en ese nivel.
El grupo de conexiones y la fuente de datos retiene y protege las credenciales.
Definitivamente no desea poder conectarse a la base de datos sin credenciales porque eso hace que la base de datos sea vulnerable.
Este es un problema general, ¿cómo almaceno las credenciales necesarias para acceder a los sistemas externos? WebLogic tiene un mapeador de credenciales para resolver este problema, en el que las credenciales (cifradas) se almacenan en LDAP incorporado. Muchos productos de Oracle usan una instalación de tienda de credenciales que almacena credenciales en la cartera de Oracle.
En la pregunta, usted proporcionó la respuesta. Almacene la contraseña encriptada y descifre cuando la necesite. Obviamente, debe usar un algoritmo de encriptación simétrico como 3DES para poder descifrarlo. Asegúrese de que la clave simétrica no sea algo que pueda adivinarse.
El truco es donde mantienes la clave simétrica necesaria para en / de-cryption. Puede colocarlo en un archivo que esté protegido a través del sistema operativo o puede guardarlo en el código, pero luego debe mantener el código seguro. También puede generar la clave si utiliza una técnica que producirá la misma clave y el algoritmo es razonablemente seguro.
Si puede mantener el código seguro también puede mantener la contraseña en el código. Sin embargo, desea la flexibilidad de poder cambiar las credenciales sin cambiar el código.
Puede agregar más capas a esta solución también. Puede encriptar el archivo de configuración (con una clave diferente) así como la contraseña dentro de él, haciendo que el hacker descubra 2 claves. Hay otros métodos aún más seguros que usan PKI, pero se vuelven difíciles de configurar.
Es posible que desee probar Kerberos, que puede usar las credenciales del usuario del sistema operativo y agregar el usuario del sistema operativo a la base de datos identificada externamente. Asegúrese de utilizar Kerberos y no la forma antigua de hacerlo, que tenía serios problemas de seguridad.
Para el soporte de Kerberos necesitará la opción de seguridad avanzada y un controlador JDBC reciente, probablemente la versión 11g. Antes de intentar hacer que funcione en Java, pruébelo en Sql * Plus usando ''/'' como nombre de usuario y contraseña vacía. "seleccionar usuario de dual" debería darle usuario @ dominio. También puede encontrar que hay una diferencia fundamental entre el uso de un controlador delgado o OCI cuando se trata de la configuración de Kerberos.
Hay dos enfoques clave y ambos tienen un impacto significativo en el diseño del sistema, de modo que no es fácil pasar de uno a otro sin una reescritura significativa. Debe comprender cuál es la política de gobierno de seguridad de su empresa antes de elegir.
1) Cada usuario tiene credenciales, que se transmiten a través de la aplicación, para el servicio que está siendo utilizado por la Aplicación; en su caso, la base de datos Oracle usa esas credenciales de usuario para conectarse a la base de datos. La desventaja es que cada usuario necesita credenciales para cada servicio seguro. Este es un enfoque de seguridad razonable, pero también requiere el trabajo adicional significativo para proporcionar y mantener las credenciales del usuario. Los administradores de su base de datos necesitarán administrar activamente las credenciales de los usuarios, lo que puede ir en contra de las políticas de gobierno de seguridad de su empresa.
2) Las credenciales de la base de datos de la aplicación se almacenan en un servicio de directorio seguro, por ejemplo, Secure LDAP. La aplicación accede al servicio de directorio con las credenciales de los usuarios. El servicio de directorio devuelve las credenciales apropiadas para el servicio al que se accede.
En ambos casos, las credenciales de la base de datos deben limitarse para realizar solo las operaciones apropiadas. Las credenciales deben reflejar los requisitos de los procesos comerciales, por ejemplo; permiten seleccionar de vistas / tablas definidas, insertar en otras, pero no crear, actualizar o eliminar tablas. En el segundo enfoque, use credenciales separadas para cada proceso comercial principal, por ejemplo, procesamiento de pedidos, contabilidad, recursos humanos, etc.
Sin embargo, recuerde que la seguridad es como las capas de una cebolla, si alguien ha eliminado las capas para acceder a la aplicación, de modo que puedan acceder al archivo de configuración del conjunto de contenido DB. Probablemente puedan troyar la aplicación para capturar las credenciales de los usuarios. Aquí es donde entra una buena política de gobernanza de seguridad.
La gobernanza de seguridad es un problema complejo que necesita el compromiso de la alta dirección, ya que si necesita este nivel de seguridad para su plataforma en vivo, cuesta. Debe separar las responsabilidades de desarrollo de la implementación, las operaciones y la administración de la autoridad del usuario. También es posible que necesite tener auditores de seguridad, que tengan acceso completo para ver los cambios, pero no capacidad para cambiar la configuración. Está lejos de ser simple y es una especialidad altamente remunerada.
Me he preguntado esto en el pasado.
La solución es ciertamente una que incluye seguridad de red adecuada a nivel de servidor y red para reducir realmente el número de personas que pueden acceder al sistema y que las credenciales de la base de datos solo den acceso a una cuenta de base de datos con el mínimo de permisos requerido para que se ejecute la aplicación.
El cifrado de los archivos de propiedades puede ser suficiente como un factor de disuasión en términos de "no se puede molestar en encontrar la clave o frase de contraseña" para que un atacante vaya a su siguiente servidor comprometido. Yo no confiaría en que "mi vecino es menos seguro, así que robale, por favor" ¡seguridad, sin embargo!
Puede almacenar las credenciales en cualquier lugar, incluso como cadenas cableadas en el programa o como entradas en el registro de Windows. Depende de usted recuperarlos si utiliza algo no estándar, sin embargo; No conozco ninguna solución pre-laminada que no sea de texto plano.
Puede probar la autenticación proxy de Oracle donde el cliente JDBC se autentica usando un certificado contra un componente / servicio conocido de nivel medio (el proxy) que es confiable para el servidor de la base de datos. Sin embargo, nunca lo intenté, así que no sé si es fácil de hacer.
Que yo sepa, los nombres de usuario y las contraseñas de jdbc deben almacenarse como texto sin formato. Una forma de limitar los posibles riesgos de esto es restringir los derechos del usuario para que solo se pueda usar la base de datos de aplicaciones dada y solo desde un host predefinido. OMI, esto limitaría mucho al atacante: solo podría usar el un / pw del mismo host donde reside la aplicación original y solo atacar la base de datos de la aplicación original.
Te sugiero que estudies la autenticación proxy. Esto está documentado en la Guía de seguridad de la base de datos Oracle® , así como en la Guía y referencia para desarrolladores de Oracle® Database JDBC . Esencialmente, lo que esto le permite hacer es tener un usuario en la base de datos que SÓLO tiene privilegios de conexión. Las cuentas de base de datos reales de los usuarios están configuradas para poder conectarse como el usuario proxy. Su aplicación que se conecta a través de JDBC luego almacena el nombre de usuario y la contraseña del proxy, y cuando la conexión proporciona estas credenciales, ADEMÁS del nombre de usuario del usuario real de la base de datos en la cadena de conexión. Oracle se conecta como el usuario proxy, y luego imita al usuario real de la base de datos, heredando los privilegios de la base de datos del usuario real.
Todos los contenedores J2EE ( JBOSS , Tomcat , BEA ) tienen grupos de conexiones. Ellos abrirán una serie de conexiones, las mantendrán con vida y se las darán en 1/100 del tiempo que lleva crearlas desde cero.
Además, también tienen funciones geniales, en JBOSS por ejemplo, toda la información de conexión se almacena en un archivo externo. Si cambia la información de conexión, es decir, cambia de una prueba a una base de datos de producción , su aplicación se alimentará dinámicamente de conexiones desde la nueva agrupación
La buena noticia es que no necesita ejecutar un contenedor J2EE completo solo para usar la agrupación de conexiones. El recurso externo permite que la contraseña se almacene en texto sin formato o en pseudocifrado.
Para obtener una guía sobre el uso de la agrupación de conexiones incorporada de Tomcat, consulte apache commons-dbcp: