Al otorgar a un usuario acceso a una base de datos, se deben hacer algunas consideraciones con ventajas y desventajas en términos de usabilidad y seguridad. Aquí tenemos dos opciones para autenticar y otorgar permisos a los usuarios. La primera es dar a todos el acceso a la cuenta sa (administrador de sistemas) y luego restringir los permisos manualmente al conservar una lista de los usuarios en los que puede otorgar o denegar permisos según sea necesario. Esto también se conoce como el método de autenticación SQL. Existen importantes fallas de seguridad en este método, como se indica a continuación. La segunda y mejor opción es hacer que Active Directory (AD) maneje toda la autenticación y autorización necesarias, también conocida como autenticación de Windows. Una vez que el usuario inicie sesión en su computadora, la aplicación se conectará a la base de datos utilizando esas credenciales de inicio de sesión de Windows en el sistema operativo.
El principal problema de seguridad con el uso de la opción SQL es que viola el principio de privilegio mínimo (POLP), que consiste en otorgar al usuario los permisos absolutamente necesarios que necesita y nada más. Al usar la cuenta sa presentas serias fallas de seguridad. Se viola el POLP porque cuando la aplicación utiliza la cuenta sa, tiene acceso a todo el servidor de la base de datos. La autenticación de Windows, por otro lado, sigue el POLP otorgando solo acceso a una base de datos en el servidor.
El segundo problema es que no es necesario que cada instancia de la aplicación tenga la contraseña de administrador. Esto significa que cualquier aplicación es un posible punto de ataque para todo el servidor. Windows solo usa las credenciales de Windows para iniciar sesión en el servidor SQL. Las contraseñas de Windows se almacenan en un repositorio en lugar de la propia instancia de la base de datos SQL y la autenticación se realiza internamente dentro de Windows sin tener que almacenar las contraseñas de sa en la aplicación.
Un tercer problema de seguridad surge al utilizar el método SQL que involucra contraseñas. Tal como se presenta en el sitio web de Microsoft y en varios foros de seguridad, el método SQL no impone el cambio de contraseña o el cifrado, sino que se envían como texto sin cifrar a través de la red. Y el método SQL no se bloquea después de los intentos fallidos, lo que permite un intento prolongado de ingreso. Sin embargo, Active Directory utiliza el protocolo Kerberos para cifrar las contraseñas al tiempo que emplea un sistema de cambio de contraseña y un bloqueo después de intentos fallidos.
También hay desventajas de eficiencia. Como requerirá que el usuario ingrese las credenciales cada vez que quiera acceder a la base de datos, los usuarios pueden olvidar sus credenciales.
Si se elimina un usuario, tendrá que eliminar sus credenciales de cada instancia de la aplicación. Si tiene que actualizar la contraseña de administrador de sa, tendrá que actualizar cada instancia del servidor SQL. Esto lleva mucho tiempo y es inseguro, deja abierta la posibilidad de que un usuario descartado retenga el acceso al SQL Server. Con el método de Windows no surge ninguna de estas preocupaciones. Todo está centralizado y manejado por el AD.
Las únicas ventajas de usar el método SQL se encuentran en su flexibilidad. Puede acceder a él desde cualquier sistema operativo y red, incluso de forma remota. Es posible que algunos sistemas antiguos, así como algunas aplicaciones basadas en la web, solo admitan un acceso.
El método AD también proporciona herramientas de ahorro de tiempo, como grupos para facilitar la adición y eliminación de usuarios, y la capacidad de seguimiento de usuarios.
Incluso si logras corregir estos defectos de seguridad en el método SQL, estarías reinventando la rueda. Al considerar las ventajas de seguridad proporcionadas por la autenticación de Windows, incluidas las políticas de contraseña y seguir el POLP, es una opción mucho mejor que la autenticación de SQL. Por lo tanto, es altamente recomendable utilizar la opción de autenticación de Windows.