Microsoft tiene una serie de características de seguridad en SQL Server 2017 que son útiles para diferentes propósitos, según lo que intente proteger y las amenazas contra las que intente protegerse. Algunas de estas funciones de seguridad pueden tener implicaciones en el rendimiento que debe tener en cuenta al decidir cuáles desea implementar. Como introducción, cubriré algunos aspectos destacados de varias de estas funciones de seguridad.
Cifrado de base de datos transparente (TDE)
El cifrado de datos transparente (TDE) es la forma de cifrado en reposo de SQL Server, lo que significa que sus archivos de datos, archivo de registro, archivos tempdb y sus copias de seguridad completas, diferenciales y de registro de SQL Server se cifrarán cuando habilite TDE en una base de datos de usuario. . Esto protege sus datos de alguien que obtenga acceso a esa base de datos o a los archivos de respaldo de la base de datos, siempre que esa persona no tenga acceso a sus certificados y claves de encriptación.
El escaneo de cifrado TDE inicial para una base de datos de usuario usará un subproceso de CPU en segundo plano por archivo de datos en la base de datos (si los archivos de datos están ubicados en unidades lógicas separadas), para leer lentamente todo el contenido del archivo de datos en la memoria a una velocidad de alrededor de 52 MB/segundo por archivo de datos (si los archivos de datos están ubicados en unidades lógicas separadas).
Luego, los datos se cifran con el algoritmo de cifrado elegido y luego se vuelven a escribir en el archivo de datos a aproximadamente 55 MB/por segundo (por archivo de datos, si están en unidades lógicas separadas). Estas velocidades de lectura y escritura secuenciales parecen estar limitadas deliberadamente y son consistentes en mis pruebas en múltiples sistemas con varios tipos de almacenamiento.
El proceso de cifrado inicial de TDE ocurre en el nivel de la página, debajo de SQL Server, por lo que no provoca el bloqueo ni genera actividad en el registro de transacciones como se vería al reconstruir un índice. Puede pausar un escaneo de encriptación TDE habilitando TF 5004 global y reactivarlo deshabilitando TF 5004 y ejecutando su comando ALTER DATABASE dbNAME SET ENCRYTION ON nuevamente, sin pérdida de progreso.
El impacto de la CPU del cifrado/descifrado se reduce considerablemente en SQL Server 2016 y versiones posteriores si tiene un procesador compatible con las instrucciones de hardware AES-NI. En el espacio de los servidores, se introdujeron en la familia de productos Intel Xeon 5600 (Westmere-EP) para servidores de dos sockets y la familia de productos Intel Xeon E7-4800/8800 (Westmere-EX) para servidores de cuatro y ocho sockets. Cualquier nueva familia de productos Intel también tendrá compatibilidad con AES-NI. Si tiene dudas sobre si su procesador es compatible con AES-NI, puede buscar "AES" en el campo de instrucciones de salida de CPU-Z, como se ve en la Figura 1.
Figura 1:Salida de CPU-Z que muestra compatibilidad con instrucciones AES
Después de cifrar una base de datos con TDE, el impacto del tiempo de ejecución de TDE es difícil de cuantificar de manera predecible porque depende absolutamente de su carga de trabajo. Si, por ejemplo, su carga de trabajo se ajusta por completo al grupo de búfer de SQL Server, TDE no tendría prácticamente ningún gasto adicional. Si, por otro lado, su carga de trabajo consistiera completamente en escaneos de tablas donde se lee la página y luego se vacían casi de inmediato, eso impondría la pena máxima. La penalización máxima por una carga de trabajo volátil de E/S suele ser inferior al 5 % con hardware moderno y con SQL Server 2016 o posterior.
El trabajo adicional del descifrado TDE ocurre cuando lee datos en el grupo de búfer desde el almacenamiento, y el trabajo adicional del cifrado TDE ocurre cuando vuelve a escribir los datos en el almacenamiento. Asegurarse de no estar bajo presión de memoria, tener un grupo de búfer lo suficientemente grande y hacer ajustes de índice y consulta obviamente reducirá el impacto en el rendimiento de TDE. TDE no cifra los datos de FILESTREAM y una base de datos cifrada con TDE no utilizará la inicialización instantánea de archivos para sus archivos de datos.
Antes de SQL Server 2016, TDE y la compresión de copia de seguridad nativa no funcionaban bien juntas. Con SQL Server 2016 y versiones posteriores, puede usar TDE y la compresión de copia de seguridad nativa juntas siempre que especifique un MAXTRANSFERSIZE mayor que 64K en el comando de copia de seguridad. También es muy importante que esté al día con las actualizaciones acumulativas, ya que ha habido varias revisiones importantes relacionadas con TDE tanto para SQL Server 2016 como para SQL Server 2017. Finalmente, TDE sigue siendo una característica exclusiva de Enterprise Edition, incluso después de SQL Server 2016. SP1 (que agregó muchas funciones exclusivas para empresas a la Edición estándar).
Seguridad de nivel de fila (RLS)
La seguridad de nivel de fila (RLS) limita el acceso de lectura y la mayoría de los accesos de nivel de escritura en función de los atributos del usuario. RLS utiliza lo que se denomina control de acceso basado en predicados. SQL Server aplica las restricciones de acceso en el nivel de la base de datos y se aplicarán cada vez que se intente acceder a los datos desde cualquier nivel.
RLS funciona mediante la creación de una función de predicado que limita las filas a las que un usuario puede acceder y luego usa una política de seguridad y un predicado de seguridad para aplicar esa función a una tabla.
Hay dos tipos de predicados de seguridad, que son predicados de filtro y predicados de bloque. Los predicados de filtro filtrarán silenciosamente las filas disponibles para operaciones de lectura (SELECCIONAR, ACTUALIZAR y ELIMINAR), esencialmente agregando una cláusula WHERE que evita que las filas filtradas aparezcan en el conjunto de resultados. Los predicados de filtro se aplican mientras se leen los datos de la tabla base, y el usuario o la aplicación no sabrán que las filas se están filtrando de los resultados. Es importante, desde una perspectiva de rendimiento, tener un índice de almacenamiento de filas que cubra su predicado de filtro RLS.
Bloquear predicados explícitamente (con un mensaje de error) bloquear operaciones de escritura (DESPUÉS DE INSERTAR, DESPUÉS DE ACTUALIZAR, ANTES DE ACTUALIZAR y ANTES DE ELIMINAR) que violarían el predicado de bloque.
Los predicados de filtro y bloque se crean como funciones con valores de tabla en línea. También necesitará usar la declaración CREATE SECURITY POLICY T-SQL para aplicar y habilitar la función de filtrado a la tabla base relevante
RLS se agregó en SQL Server 2016 y está disponible en todas las ediciones de SQL Server 2016 y posteriores. RLS no funcionará con Filestream, Polybase y vistas indexadas. RLS puede dañar el rendimiento de la búsqueda de texto completo y puede obligar a las consultas de índices de almacén de columnas a terminar usando el modo de fila en lugar del modo por lotes. Esta publicación de blog de Microsoft tiene más información sobre el impacto en el rendimiento de RLS. Un buen ejemplo de cómo usar Query Store para ajustar el rendimiento de RLS está aquí.
Enmascaramiento dinámico de datos (DDM)
El enmascaramiento dinámico de datos (DDM) puede ayudar a limitar la exposición de datos confidenciales al enmascararlos para usuarios sin privilegios. DDM se aplica a nivel de tabla, por lo que todas las consultas se ven afectadas por el enmascaramiento de datos, mientras que las reglas de enmascaramiento reales se aplican en columnas individuales de la tabla.
Hay cuatro tipos de máscaras de datos que puede usar, que incluyen predeterminadas, de correo electrónico, de cadena personalizada y aleatorias. Una máscara predeterminada proporciona un enmascaramiento predeterminado completo de los datos según el tipo de datos. Por ejemplo, un tipo de datos de cadena obtendría una máscara de 'XXXX' en lugar de los datos reales. Una máscara de correo electrónico devolverá la primera letra de la dirección de correo electrónico real, seguida de [email protected], independientemente del sufijo de dominio real. Una máscara de cadena personalizada mostrará la primera y la última letra de la cadena, con un relleno personalizado en el medio. Finalmente, se utiliza una máscara aleatoria para enmascarar datos numéricos y proporcionar un valor aleatorio en un rango definido. Las máscaras de datos se pueden crear en una instrucción CREATE TABLE o con una instrucción ALTER COLUMN.
El enmascaramiento dinámico de datos no proporciona enmascaramiento para los usuarios privilegiados que aún pueden consultar directamente sus tablas y ver los datos desenmascarados. Las reglas de enmascaramiento no se pueden usar con columnas cifradas (Always Encrypted), columnas calculadas o con datos de Filestream. Si hay índices existentes en una columna que desea enmascarar, deberá eliminar el índice, crear la máscara en la columna y luego volver a crear el índice. También es posible inferir los valores de las columnas de datos enmascarados escribiendo consultas que permitan al usuario adivinar eventualmente un valor para una columna enmascarada.
El enmascaramiento dinámico de datos se introdujo en SQL Server 2016 y está disponible en todas las ediciones de SQL Server. DDM no pretende ser una medida de seguridad fuerte como el cifrado real, pero por otro lado, su impacto en el rendimiento parece ser bastante insignificante.
