Este escrito fue probado por expertos para que tengas la garantía de la exactitud de nuestra esta noticia.
Solución:
Solución 1:
Diría que solo hay dos razones válidas para usar la autenticación de SQL:
- Te estás conectando desde fuera del dominio, así que autenticación integrada.
- Está ejecutando un punto de referencia TPC-C y cada ciclo cuenta. La autenticación de SQL es un poco más rápida.
Para el escenario que está proponiendo (el host del servidor web está completamente comprometido), nada puede protegerlo. El hacker puede hacer en el servidor DB como mínimo todo lo que puede hacer el servidor web. Y diría que la defensa en profundidad puede enseñarle a minimizar la pérdida en tal caso: reduzca los derechos de base de datos de la cuenta utilizada por su servidor web al mínimo absolutamente necesario y nada más. En segundo lugar, asegúrese de que si el host del servidor web está comprometido, no se puede usar para elevar privilegios más altos que la cuenta del servidor web (es decir, no hay otro servicio en el host WWW que use credenciales con privilegios más altos en la base de datos que la cuenta WWW). Estos son principios básicos de seguridad y no tienen nada que ver con el esquema de autenticación utilizado.
Si bien la autenticación sql frente a la autenticación de Windows no brinda una clara ventaja en su escenario, hay otras cuestiones a considerar:
- Aplicación de políticas centralizadas: tiene un lugar para configurar sus políticas de contraseñas, incluida la vigencia y el vencimiento de la contraseña, la terminación de la cuenta, etc.
- Control de suplantaciones y delegación de confianza. Una vez que se usa sql auth en una cadena de delegación de confianza, todas las apuestas están canceladas ya que no es una ‘delegación’ real y, por lo tanto, ya no está bajo las restricciones que imponen sus políticas.
- Auditoría: su LSA ni siquiera ve la autenticación sql, por lo que toda su infraestructura de auditoría simplemente se omite. Debe agregar explícitamente los registros que SQL produce sobre los eventos de autenticación de sql, pero está mezclando manzanas y naranjas ya que esos eventos tienen una fuente, un proveedor y un esquema diferentes en el registro de eventos.
Una última nota: el protocolo TDS expone la contraseña de autenticación sql en texto claro sobre el tráfico, pero eso generalmente se mitiga al solicitar el cifrado SSL del tráfico.
Entonces, ¿por qué todavía ve hosts WWW de autenticación sql que almacenan la contraseña en claro en web.config? esos son los malo desarrolladores/administradores, no seas uno de ellos.
msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx
technet.microsoft.com/en-us/library/ms189067.aspx
Solución 2:
Si no usa SSPI, está codificando el nombre de usuario y la contraseña en los archivos de origen.
Si está codificando el nombre de usuario y la contraseña en los archivos de origen, todos sus empleados tendrán acceso a ellos.
Esto es relativamente inseguro. Un ex empleado descontento podría usar la información maliciosamente. Un visitante puede ver el código en una pantalla en alguna parte. O el código fuente podría salir a la luz accidentalmente.
La ventaja de SSPI es que la contraseña nunca se almacena en ningún lugar sin cifrar.
Solución 3:
Las otras respuestas hasta ahora han sido buenas, pero agregaré otra: administración.
Tarde o temprano, probablemente terminará con varios servidores SQL. Administrar la autenticación SQL entre su aplicación y varios servidores SQL puede ser un poco doloroso, especialmente cuando se encuentra con problemas de seguridad. Si cambia una contraseña de autenticación de Windows una vez, cambia de inmediato en todos sus servidores. Si necesita rotar sus contraseñas de autenticación de SQL, es más doloroso, hasta el punto en que probablemente no lo haga en absoluto. Eso es un riesgo de seguridad.
Solución 4:
No estoy 100% seguro aquí, pero creo que el punto principal es que la autenticación de SQL no es segura, por lo que es mejor usar la autenticación de Windows. Dependiendo de cómo esté configurada su aplicación, también puede almacenar las credenciales adecuadas en forma cifrada en la máquina mediante la autenticación de Windows. No creo que eso sea realmente posible con la autenticación de SQL. Puede ofuscarlo, pero en última instancia debe estar claro.
Además, el hecho de que un pirata informático pueda ingresar a un servidor no significa que se acabó el juego. Un pirata informático podría obtener el control de un proceso sin privilegios pero no hacer nada más en el servidor. Por eso es importante no ejecutar todo como administrador o sistema, sino usar cuentas de servicio con privilegios mínimos.
Reseñas y valoraciones
No se te olvide dar difusión a esta sección si si solucionó tu problema.