DBA es el guardián de los datos, y hay dos aspectos de ser un guardián. El primero es la integridad. Incluye tareas como comprobar la coherencia de la base de datos, crear copias de seguridad y, en caso de que surja algún problema, tener un plan de recuperación de base de datos completo y bien diseñado.
El segundo aspecto es la seguridad. Sugiere asegurarse de que solo los usuarios autorizados tengan acceso a los datos y solo a los datos que necesitan.
Puede encontrar numerosos recursos dedicados a la seguridad en la Web. Sin embargo, creo que algunas cosas importantes carecen de la atención adecuada. En este artículo, me gustaría centrarme en estas opciones y demostrar por qué es importante conocerlas y manejarlas correctamente.
Una misión para comprometer un servidor SQL
Hagamos un juego de rol en el que eres un agente secreto y tu misión, si la aceptas, es robar datos muy importantes de TargetDB base de datos alojada en un servidor SQL. Debe obtener estos datos y eliminarlos.
Es posible obtener un inicio de sesión para usted, pero cada inicio de sesión en el servidor tiene permisos explícitos DENIED en la base de datos y los datos de destino. La única información que nuestro agente puede brindarle es la generada para verificación por el protocolo de seguridad durante la creación de su inicio de sesión.
Información de la base de datos del servidor de destino.
Permisos del servidor:
Permisos de base de datos:
Como todo agente decente, hagamos los deberes y verifiquemos con qué estás tratando.
No puede simplemente iniciar sesión y conectarse a TargetDB , ya que se deniega cada uno de los permisos para su inicio de sesión y su usuario asignado explícitamente. Necesita ingresar desde otra base de datos.
Una puerta cerrada
Las acciones entre bases de datos no son cosas fáciles de hacer. Considéralo como una puerta cerrada con dos candados. No nos centraremos en los detalles técnicos aquí, pero puede consultar el artículo Ampliación de la suplantación de la base de datos mediante el uso de EXECUTE AS MSDN (lo recomiendo encarecidamente).
El primer bloqueo es Confiar en el autenticador y el segundo es Confiar en la base de datos .
Comencemos con el primer candado. Confiar en el autenticador significa que para acceder a otra base de datos B, al propietario de la base de datos A se le debe otorgar (explícita o implícitamente) la AUTENTICACIÓN permiso en la base de datos B.
¡Espera un minuto! El autenticador en el nivel de la base de datos es el propietario de la base de datos en sí (no lo mezcle con el db_owner rol de base de datos!).
Compruebe los propietarios de la base de datos:
Aunque siguen una práctica bastante buena al usar una cuenta por servidor, que no es SA , así han tenido la amabilidad de abrirte el primer candado.
Centrémonos en el segundo candado.
De alguna manera, debe tener una base de datos creada en el servidor con CONFIABLE propiedad ON . La mejor práctica aquí es establecer la propiedad de la base de datos TRUSTWORTHY en OFF .
Este es el momento en el que deberíamos decir:¿y si ya tiene una base de datos de este tipo?
Es la base de datos MSDB.
El segundo bloqueo está hecho. Ni siquiera necesitabas romper ninguna de las cerraduras.
La importancia del rol db_owner
En este momento, tienes que lidiar con un desafío. De alguna manera, debe ingresar a la base de datos MSDB con el db_owner función de base de datos porque tiene permiso implícito de suplantación.
Dado que MSDB no suele estar en el centro de atención de los administradores de bases de datos, esta misión ya no es imposible. Veamos qué puede hacer solo porque tiene un usuario con db_owner rol de base de datos en la base de datos MSDB:
Intenta conectarte a TargetDB :
Este es un error esperado. Recuerde el protocolo de seguridad aplicado en el inicio de sesión proporcionado. Comencemos.
Intenta conectarte a TargetDB y para seleccionar los datos de destino:
¡Funciona! Modifiquémoslo y luego verifiquemos la acción.
Eso es todo.
Misión cumplida.
Como vio, me enfoqué en una combinación particular de configuración de base de datos de seguridad. Eran el propietario de la base de datos y el CONFIABLE opción de base de datos prestando especial atención a MSDB. El escenario presentado era solo uno en el que los datos confidenciales pueden verse comprometidos de la misma manera. Revisemos otro posible escenario ahora.
Propietario de la base de datos + CONFIABLE
Verifiquemos los detalles de fondo comenzando con el problema bien conocido:la propiedad de la base de datos. ¿Qué detalles de inicio de sesión debe usar el propietario de su(s) base(s) de datos? Mucha gente dice que SA es una elección adecuada.
Hice una búsqueda rápida en Google y encontré respuestas como las siguientes:
“No recuerdo que esto haya sido una preocupación para mí nunca. Además de parecer molesto en los informes, o no poder eliminar al usuario si posee una base de datos, pero no creo que afecte las operaciones del servidor. Puedes elegir sa por consistencia.”
O
“No creo que ser propietario de una base de datos de SA o de cualquier otro usuario deba ser motivo de preocupación. Lo que importa es quién está realizando 'qué' en su base de datos. Por lo tanto, es una buena idea crear usuarios con privilegios válidos. Para simplificar, puede especificar el propietario como SA".
La situación actual es que usar la cuenta SA como propietario de la base de datos es la PEOR práctica . Personalmente, creo que esto debería destacarse en cada blog y en cada documentación relacionada con este tema.
Si creamos usuarios con solo privilegios válidos, eso sería suficiente, pero desafortunadamente, no es así como suelen funcionar las cosas. Debe estar preparado para los "posiblemente peores" escenarios. Solo piense, lo que podríamos hacer en nuestros ejemplos anteriores si el propietario de la base de datos predeterminado fuera SA !
Sigamos con la segunda opción, la CONFIABLE opción de base de datos. La situación es un poco mejor, pero todavía tiene un problema común. Como se considera comúnmente, la mejor práctica aquí es Desactivar la propiedad de la base de datos "Confiable" . Acabamos de ver por qué esta opción es mala .
Pero esto no es todo. Si intenta encontrar algunos scripts para verificar esta propiedad, probablemente encontrará un script similar a este:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'El sp_Blitz El script que verifica el estado de SQL Server también verifica la configuración predeterminada de las bases de datos (incluido TRUSTWORTHY como un valor predeterminado de 0) e informa cada base de datos que tiene una configuración no predeterminada. Sin embargo, el script omite las bases de datos del sistema.
Además, hay un artículo de MS KB que se centra en este tema. Consulte las pautas para usar la configuración de la base de datos TRUSTWORTHY en SQL Server:
Hay un ejemplo de código en el artículo, que enumera las bases de datos que tienen el bit TRUSTWORTHY activado y cuyos propietarios de bases de datos pertenecen a la función del servidor sysadmin:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
¿Qué es común en estos guiones? Cada secuencia de comandos excluye MSDB, pero como señala el artículo de MS KB, acaba de verlo en nuestra "misión":
Nota :De forma predeterminada, la configuración TRUSTWORTHY está activada para la base de datos MSDB. Alterar esta configuración de su valor predeterminado puede provocar un comportamiento inesperado de los componentes de SQL Server que utilizan la base de datos MSDB.
Me gustaría enfatizar que el enfoque principal de esta sección no es la opción de base de datos TRUSTWORTHY ni la propiedad del propietario de la base de datos en sí, sino la combinación de estas dos opciones. Me he concentrado principalmente en MSDB porque la configuración TRUSTWORTHY está activada para la base de datos MSDB de manera predeterminada.
Conclusión
Eso es todo por ahora. Revisamos y verificamos los escenarios prácticos relacionados con la seguridad de SQL Server. También revisamos opciones de bases de datos tan importantes como el propietario de la base de datos y la configuración de la base de datos CONFIABLE.
Solo quería destacar estas opciones ya que son críticas, especialmente cuando hablamos de ellas en combinación.
