6 conceptos básicos de seguridad de SQL Server que todo administrador de bases de datos debe conocer

Demasiadas violaciones de datos son causadas por servidores de bases de datos mal protegidos. Microsoft SQL Server es una solución empresarial popular, pero también es compleja de entender y configurar. Aquí hay 6 características de seguridad de SQL Server que debe conocer para mantener protegidos los datos de su servidor.

1. Autenticación de SQL Server versus autenticación de Windows

Microsoft SQL Server admite dos opciones de autenticación:

La Autenticación de Windows se basa en Active Directory (AD) para autenticar a los usuarios antes de que se conecten a SQL. Es el modo de autenticación recomendado porque AD es la mejor manera de administrar las políticas de contraseñas y el acceso de usuarios y grupos a las aplicaciones de su organización. .
La autenticación de SQL Server funciona almacenando nombres de usuario y contraseñas en el servidor de la base de datos. Se puede utilizar en situaciones en las que Active Directory no está disponible.

Puede utilizar SQL Server y la autenticación de Windows al mismo tiempo (modo mixto), pero, siempre que sea posible, utilice exclusivamente la autenticación de Windows.

Si debe utilizar la autenticación de SQL Server, asegúrese de que la cuenta sa predeterminada esté deshabilitada o tenga una contraseña segura que se cambie con frecuencia, porque esta cuenta suele ser el objetivo de los piratas informáticos. Las cuentas de SQL Server, incluido sa (si está habilitado), se pueden administrar mediante el servicio SQL Server Management Studio o el comando ALTER LOGIN Transact-SQL (T-SQL).

2. Inicios de sesión y funciones del servidor

Independientemente del método de autenticación que elija, hay dos tipos de inicio de sesión que puede configurar en instancias de SQL: inicios de sesión de usuario e inicios de sesión de servidor. Hablaré de los inicios de sesión de los usuarios en la siguiente sección. Los inicios de sesión del servidor permiten a los usuarios establecer una conexión a una instancia de SQL Server. A cada inicio de sesión del servidor se le asignan uno o más roles de servidor que le permiten realizar acciones específicas en la instancia. De forma predeterminada, a los inicios de sesión del servidor se les asigna la función de servidor público, que brinda acceso básico a la instancia. Otros roles disponibles incluyen bulkadmin, sercurityadmin, dbcreator y serveradmin.

Los inicios de sesión del servidor se pueden crear utilizando T-SQL o SQL Server Management Studio. Al crear un inicio de sesión en el servidor, debe especificar una base de datos predeterminada. Los inicios de sesión del servidor están asociados con un inicio de sesión de usuario en la base de datos predeterminada. Vale la pena señalar que no es necesario que coincidan el nombre de inicio de sesión del servidor y el nombre de inicio de sesión del usuario asociado. Si no hay ningún objeto de usuario asociado en la base de datos predeterminada, se le negará el acceso al inicio de sesión del servidor a menos que la función del servidor asignada al inicio de sesión tenga acceso a todas las bases de datos. Los inicios de sesión del servidor se pueden asignar a un usuario en una o más bases de datos, y usted puede crear usuarios al configurar los inicios de sesión del servidor.

3. Usuarios, esquemas y roles de la base de datos

Al crear un inicio de sesión de usuario, debe especificar la base de datos a la que se asociará, un nombre de usuario y un esquema predeterminado que se aplicará a todos los objetos que el usuario cree si no se especifica ningún otro esquema. Los esquemas de SQL Server son colecciones de objetos, como tablas y vistas, lógicamente separados de otros objetos de la base de datos, lo que facilita la administración del acceso y significa que no es necesario usar el nombre del esquema al ejecutar comandos T-SQL en una base de datos.

El esquema predeterminado para objetos definidos por el usuario es dbo. El otro esquema predeterminado es sys; posee todos los objetos del sistema.

De la misma manera que a los inicios de sesión del servidor se les asignan roles de servidor, a los inicios de sesión de los usuarios se les asignan roles de base de datos, que asignan derechos en las bases de datos. Los roles de la base de datos del servidor incluyen public, db accessadmin, dbowner y db securityadmin.

4. Asegurables y permisos

Cuando los roles de servidor o base de datos le dan a un usuario demasiado o muy poco acceso, puede asignar uno o más elementos asegurables. Los elementos asegurables existen en los niveles de servidor, esquema y base de datos; son recursos de SQL Server a los que se puede acceder mediante inicios de sesión del servidor y del usuario. Por ejemplo, al utilizar elementos asegurables, podría otorgarle a un servidor acceso de inicio de sesión solo a una tabla o función específica, un nivel de granularidad que no es posible asignando una función a un inicio de sesión.

Los permisos se utilizan para otorgar acceso a los elementos asegurables de SQL Server. Puede otorgar permiso para ver datos o simplemente modificarlos. Las declaraciones GRANT, DENY y REVOKE T-SQL se utilizan para configurar permisos.

Sin embargo, los permisos pueden ser complicados. Por ejemplo, configurar DENEGAR permisos en un objeto asegurable evita la herencia de permisos en objetos de nivel inferior. Pero el permiso GRANT a nivel de columna anula DENY a nivel de objeto, por lo que el permiso GRANT sobre una columna anula el permiso DENY establecido en una tabla. Debido a que los permisos pueden ser complejos, siempre vale la pena verificar los permisos efectivos usando T-SQL. El siguiente comando determina los permisos otorgados a JoeB sobre un objeto, en este caso una tabla llamada "empleados".

SELECT * FROM fn_my_permissions('joeb', empleados);
IR

5. Cifrado de datos

SQL Server admite múltiples opciones de cifrado:

Secure Sockets Layer (SSL) cifra el tráfico a medida que viaja entre la instancia del servidor y la aplicación cliente, de forma muy similar a como se protege el tráfico de Internet entre el navegador y el servidor. Además, el cliente puede validar la identidad del servidor utilizando el certificado del servidor.
El Cifrado de datos transparente (TDE) cifra los datos en el disco. Más específicamente, cifra todos los datos y archivos de registro. No es necesario cambiar las aplicaciones cliente cuando TDE está habilitado
Cifrado de copia de seguridad es similar a TDE, pero cifra las copias de seguridad de SQL en lugar de los datos activos y los archivos de registro.
El Cifrado a nivel de columna/celda garantiza que datos específicos estén cifrados en la base de datos y permanezcan así incluso cuando se almacenen en la memoria. Los datos se descifran mediante una función y requieren cambios en las aplicaciones cliente para
Always Encrypted es una mejora del cifrado a nivel de columna/celda en el sentido de que no requiere ningún cambio en las aplicaciones cliente; los datos permanecen cifrados en la red, en la memoria y en el disco. También protege los datos confidenciales de las miradas indiscretas de los usuarios privilegiados de SQL Server. Pero puede encontrar algunos problemas con esta opción de cifrado: debido a que SQL Server no puede leer los datos, algunas indexaciones y funciones no funcionarán.

6. Seguridad a nivel de fila

La seguridad a nivel de fila (RLS) permite a las organizaciones controlar quién puede ver las filas en una base de datos. Por ejemplo, podría restringir a los usuarios para que vean solo filas que contengan información sobre sus clientes.

RLS consta de tres partes principales: una función de predicado, un predicado de seguridad y una política de seguridad. La función de predicado comprueba si el usuario que ejecuta la consulta de la base de datos puede acceder a una fila según la lógica. Por ejemplo, puede comprobar si el nombre de usuario del usuario que ejecuta la consulta coincide con un campo en una de las columnas de la fila. Una función de predicado y un predicado de seguridad se definen juntos en una función para filtrar silenciosamente los resultados de una consulta sin generar errores o para bloquear con un error si se deniega el acceso a la fila. Finalmente, una política de seguridad vincula la función a una tabla.