Implementación de controles de cumplimiento para datos confidenciales
La implementación de controles de cumplimiento después de migrar la base de datos es importante para asegurarse de que los datos siguen siendo seguros y conformes con las normativas pertinentes. La migración a un nuevo entorno, como Azure SQL, presenta nuevas características y funcionalidades de seguridad.
Exploración de la auditoría de servidor y base de datos
Las auditorías de Azure SQL realizan un seguimiento de los eventos de la base de datos y los escriben en un registro de auditoría en su cuenta de Azure Storage, el área de trabajo de Log Analytics o Event Hubs. Además, facilita el mantenimiento del cumplimiento normativo, el análisis de patrones de actividad y la detección de desviaciones que podrían indicar infracciones de seguridad.
Puede definir directivas de nivel de servidor y de nivel de base de datos. Las directivas de servidor abarcan automáticamente las bases de datos nuevas y existentes en Azure.
- Al habilitar la auditoría de servidor, se desencadena la auditoría de la base de datos, independientemente de su configuración de auditoría individual.
- Puede habilitar la auditoría en el nivel de base de datos, lo que permite que las directivas de servidor y de base de datos coexistan simultáneamente.
- La auditoría en las réplicas de solo lectura se habilita automáticamente.
Es mejor no habilitar la auditoría de servidor y la auditoría de base de datos juntas, excepto en los escenarios siguientes.
Necesita una cuenta de almacenamiento distinta, un período de retención o un área de trabajo de Log Analytics para una base de datos determinada.
Se necesita una auditoría para una base de datos específica con tipos de eventos o categorías únicos distintos de los demás en el servidor.
En todos los demás casos, se recomienda habilitar solo la auditoría de nivel de servidor y dejar la auditoría de nivel de base de datos deshabilitada para todas las bases de datos.
La directiva de auditoría predeterminada para SQL Database incluye el conjunto de grupos de acciones siguiente:
Grupo de acciones | Definición |
---|---|
BATCH_COMPLETED_GROUP | Audita todas las consultas y procedimientos almacenados que se ejecutan en la base de datos. |
SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP | Esto indica que una entidad de seguridad inició sesión correctamente en la base de datos. |
FAILED_DATABASE_AUTHENTICATION_GROUP | Esto indica que una entidad de seguridad no pudo iniciar sesión en la base de datos. |
Si desea habilitar la auditoría para todas las bases de datos de un servidor de Azure SQL, seleccione Auditoría en la sección Seguridad del panel principal del servidor.
La página Auditoría le permite establecer el destino del registro de auditoría y también elegir si desea realizar un seguimiento de las operaciones del ingeniero de Soporte técnico de Microsoft en el mismo destino de registro que la auditoría de Azure SQL, o bien seleccionar uno diferente.
Para revisar los registros de auditoría de las operaciones de Soporte técnico de Microsoft en el área de trabajo de Log Analytics, utilice la consulta siguiente:
AzureDiagnostics
| where Category == "DevOpsOperationsAudit"
Importante
Azure SQL Database y los servicios de auditoría de Azure SQL Managed Instance se han ajustado para lograr una disponibilidad y un rendimiento óptimos. Sin embargo, vale la pena tener en cuenta que, en condiciones de actividad excepcionalmente alta o congestión significativa de la red, es posible que ciertos eventos auditados no se registren.
Auditoría de etiquetas confidenciales
En combinación con la clasificación de datos, también puede supervisar el acceso a datos confidenciales. Auditoría de Azure SQL se ha mejorado para incluir un nuevo campo en el registro de auditoría denominado data_sensitivity_information
.
Al registrar las etiquetas de confidencialidad de los datos que devuelve una consulta, este campo proporciona una manera más sencilla de realizar un seguimiento del acceso a las columnas clasificadas.
La auditoría consta del seguimiento y registro de los eventos que se producen en el motor de base de datos. La auditoría de Azure SQL simplifica los pasos de configuración necesarios para su habilitación, lo que facilita el seguimiento de las actividades de base de datos para SQL Database y SQL Managed Instance.
Enmascaramiento de datos dinámicos
El enmascaramiento dinámico de datos funciona ofuscando datos para limitar su exposición. Permite a los usuarios que no requieren acceso a información confidencial ver la columna, pero no los datos reales. El enmascaramiento dinámico de datos funciona en la capa de presentación y los usuarios con privilegios elevados siempre verán los datos sin enmascarar.
El enmascaramiento dinámico de datos ofrece la ventaja de requerir una modificación mínima en la aplicación o la base de datos. Puede configurarlo cómodamente a través de Azure Portal o mediante T-SQL.
Las columnas PhoneNumber y EmailAddress están ocultas para el usuario DDMDemo que solo tiene el permiso SELECT
en la tabla. El usuario puede ver los cuatro últimos dígitos del número de teléfono, ya que se enmascara mediante una función parcial que reemplaza todo, excepto los últimos cuatro dígitos de la columna. Este enmascaramiento se considera una función personalizada. Además de T-SQL, si usa Azure SQL Database, puede crear reglas de enmascaramiento dinámico en Azure Portal.
Para agregar una regla de enmascaramiento, vaya a la base de datos en Azure Portal y seleccione Enmascaramiento dinámico de datos en la sección de seguridad de la hoja principal de la base de datos.
El enmascaramiento dinámico de datos admite los patrones de enmascaramiento siguientes que se pueden utilizar:
Función de enmascaramiento | Definición | Ejemplo de T-SQL |
---|---|---|
Valor predeterminado | Enmascara los datos de la columna sin exponer ninguna parte de los valores al usuario. El usuario verá XXXX para los valores de cadena, 0 para los números y 01.01.1900 para los valores de fecha. | ALTER TABLE [Customer] ALTER COLUMN Address ADD MASKED WITH (FUNCTION = 'default()') |
Tarjeta de crédito | Enmascara todos los caracteres excepto los cuatro finales, lo que permite a los usuarios ver los cuatro últimos dígitos. Este enmascaramiento puede ser útil para los agentes de servicio de atención al cliente que necesiten ver los cuatro últimos dígitos de un número de tarjeta de crédito, pero que no necesitan ver el número entero. Los datos se muestran en el formato habitual de un número de tarjeta de crédito, XXXX-XXXX-XXXX-1234. | ALTER TABLE [Customer] ALTER COLUMN Address ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)') |
Correo electrónico | Solo la primera letra y el sufijo final del dominio no están enmascarados; por ejemplo, "aXXX@XXXXXXX.com". | ALTER TABLE [Customer] ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()') |
Number | Este formato de enmascaramiento debe usarse en columnas numéricas. Muestra un número aleatorio como el valor enmascarado en lugar del valor real. Con cada consulta, se muestra un número diferente. | ALTER TABLE [Customer] ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)') |
Cadena personalizada | Esta opción permite enmascarar el texto con cualquier valor y mostrar un número personalizado de caracteres en cualquier extremo del valor enmascarado. Si la longitud del valor que se va a enmascarar es igual o menor que el número de caracteres que especifica la máscara, se mostrarán solo los caracteres enmascarados. | ALTER TABLE [Customer] ALTER COLUMN [PhoneNumber] ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') |
A fin de permitir que los usuarios recuperen datos no enmascarados de las columnas para las que se define el enmascaramiento, debe conceder el permiso UNMASK
de manera explícita.
Nota:
Es posible identificar datos enmascarados mediante la inferencia en función de los resultados. Si usa el enmascaramiento de datos, también debe limitar la capacidad del usuario de ejecutar consultas ad hoc.
Por ese motivo, se recomienda combinar el enmascaramiento dinámico de datos con otras características de seguridad, como la auditoría, el cifrado y la seguridad de nivel de fila para mejorar la protección de los datos confidenciales.
Caso de uso
El enmascaramiento de datos es una característica sencilla y ligera que resulta ideal para una serie de escenarios, entre los que se incluyen los siguientes:
Enmascarar los datos de los usuarios de la aplicación que no tienen acceso directo a la base de datos.
Restringir la información privada de un grupo de usuarios.
Proporcionar datos enmascarados a proveedores externos, donde es necesario proteger la información confidencial mientras se conservan las relaciones entre los elementos de los datos.
Exportar una copia de la base de datos de producción a un entorno inferior para fines de desarrollo con un usuario que no cuenta con el permiso
UNMASK
. Los datos exportados tienen un formato enmascarado.
Importar y exportar datos
Si se utiliza SELECT INTO
o INSERT INTO
para copiar datos de una columna enmascarada en otra tabla, se generarán datos enmascarados en la tabla de destino.
Cuando un usuario sin el privilegio UNMASK
ejecuta la importación y exportación de SQL Server, el archivo de datos exportado contendrá datos enmascarados y la base de datos importada contendrá datos enmascarados de manera inactiva.