database sql-server – Implicaciones de seguridad de habilitar CLR en una instancia compartida

Pregunta:

Mi base de datos está actualmente aislada en su propia instancia y VM. Mi cliente está retirando ese servidor y necesito migrar la base de datos a un nuevo entorno. Mi base de datos usa CLR, por lo que el nuevo entorno debe tener eso habilitado.

El cliente propuso utilizar un servidor existente con una instancia de SQLServer 2014 Standard que aloja bases de datos de otros proveedores de software. Me preocupa incurrir en una especie de responsabilidad de "lo rompes, lo compraste", ya que no puedo responder por la estrategia de seguridad de esos otros DB o sus interfaces. No quiero hacer algo que presente un riesgo significativo.

Me encuentro con escenarios similares con otros clientes de vez en cuando. Soy un desarrollador de bases de datos. Ocasionalmente proporciono servicios de DBA relacionados con mi propio producto para mis clientes de pequeñas y medianas empresas, pero de ninguna manera soy un DBA calificado. Cada cliente tiene diferentes presupuestos, prioridades, personal de TI y políticas de seguridad, pero en general ninguno de ellos tiene TI / DBA que puedan comprender y / o realizar evaluaciones de riesgos competentes a este nivel de detalle.

¿Cómo afectaría la habilitación de CLR en una instancia compartida a la seguridad de las otras bases de datos? (No estoy preguntando sobre los niveles de permisos de nivel de base de datos, solo habilitando CLR). Necesito comprender el riesgo (si lo hay) lo suficientemente bien como para poder recomendar una 'mejor práctica' y una alternativa 'suficientemente segura' específica para el cliente.

Respuesta:

Dado que estamos tratando con una instancia compartida, debería ser seguro asumir que ninguno de los inicios de sesión para las bases de datos del "cliente" tiene privilegios de sysadmin o se le ha otorgado el permiso CONTROL SERVER .

En tales condiciones, no debería haber ningún riesgo de seguridad al tener SQLCLR habilitado, independientemente de lo que muchas personas parezcan afirmar. Tener habilitada la opción "CLR habilitado" a nivel de instancia simplemente permite un inicio de sesión que tiene el permiso apropiado para cargar ensamblajes, y que cualquiera que tenga acceso a los objetos en esos ensamblajes puede usarlos.

Si los usuarios no pueden cargar ensamblados, entonces no puede haber riesgo de tener código desconocido en los ensamblados, porque no habrá ningún ensamblado. Luego, si a un usuario (como usted) se le otorga el permiso CREATE ASSEMBLY (que debe combinarse con el uso de Certificados para manejar la seguridad del ensamblaje), entonces solo usted puede cargar ensamblados.

Por supuesto, para SQL Server 2005 – 2016, y para SQL Server 2017 y más nuevo que tiene la opción de configuración a nivel de instancia "CLR estrictas medidas de seguridad" des activado, el propietario de la base (es decir, la dbo usuario) y cualquier usuario en el db_owner base de datos fija El rol puede crear ensamblados SAFE , pero esos no son un riesgo para la seguridad . Seguro, pueden ser un riesgo de rendimiento, pero lo mismo es cierto para el modelado de datos descuidado, T-SQL, disparadores, etc. Si los distintos proveedores no son dbo para sus bases de datos, entonces esto no es un problema. Si los proveedores son dbo para sus respectivas bases de datos y el deseo es evitar que creen ensamblados SAFE , es bastante fácil crear un disparador DDL en toda la instancia para la declaración CREATE ASSEMBLY y emitir un ROLLBACK si el usuario no es usted y / o no se ejecuta dentro de su base de datos.

Si alguien es miembro del rol de nivel de instancia de sysadmin o tiene el permiso de nivel de instancia de CONTROL SERVER , también puede cargar ensamblados. PERO, y esto es lo que la mayoría de las recomendaciones relacionadas con la "seguridad" pierden: tener "CLR habilitado" deshabilitado no protege contra alguien que es un sysadmin o tiene permiso de CONTROL SERVER porque tiene permiso para habilitar la opción "CLR habilitado" (y habilitar xp_cmdshell , etc. y hagan lo que quieran)!

No hay ningún riesgo inherente en tener esta opción habilitada porque tenerla habilitada no le da a nadie el permiso para cargar ensamblados que representan un riesgo de seguridad (en SQL Server 2005 – 2016, dbo y los usuarios en el db_owner pueden cargar ensamblados SAFE ). Y, una vez cargados, los ensamblados marcados como EXTERNAL_ACCESS o UNSAFE necesitan seguridad adicional (es decir, Certificados / nombres fuertes, no TRUSTWORTHY ) para que se ejecute su código. Y, a partir de SQL Server 2017, todos los ensamblados, de forma predeterminada, necesitan esa seguridad adicional solo para cargarse en primer lugar. Y esa seguridad adicional (para el funcionamiento del ensamblaje) requiere permisos de nivel de sysadmin :

  • En el desafortunado caso de que alguien configure la base de datos en TRUSTWORTHY ON , el inicio de sesión que posee la base de datos debe tener el permiso EXTERNAL ACCESS ASSEMBLY o UNSAFE ASSEMBLY (para SQL Server 2017+ con "CLR estricta seguridad" habilitada, el valor predeterminado, debe be UNSAFE ASSEMBLY ), que solo puede ser otorgado por un administrador de sistemas (estos permisos están obviamente implícitos si el inicio de sesión propietario es un sysadmin ). Con suerte, las bases de datos de los proveedores nunca tendrán TRUSTWORTHY habilitado.
  • Cuando se firman los ensamblajes, se debe crear un certificado o una clave asimétrica en la base de datos [master] , luego se debe crear un inicio de sesión a partir de eso, luego se debe otorgar el permiso de UNSAFE ASSEMBLY EXTERNAL ACCESS ASSEMBLY o UNSAFE ASSEMBLY (para SQL Server 2017+ con "seguridad estricta CLR" habilitada (el valor predeterminado) debe ser UNSAFE ASSEMBLY ).

Para ver algunos ejemplos de cómo manejar la seguridad SQLCLR, consulte:

Dicho esto, como señaló David Browne en un comentario sobre esta respuesta:

Otro punto importante tiene que ver con la confianza que presuntamente existe entre los interesados ​​por las distintas bases de datos. En un entorno corporativo, se espera que todos sean confiables y cooperativos. en un entorno de alojamiento de terceros, debe asumir que el propietario de la carga de trabajo adyacente es un actor completamente no confiable e incluso malintencionado. Muchas cosas que no son perfectamente seguras son lo suficientemente seguras como para hacerlas detrás de un firewall y entre amigos.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım