Este artículo es compartido por VV Yixiao de la comunidad de nube de Huawei " Introducción a los principios de desensibilización de datos y métodos de uso de la gestión de seguridad de GaussDB (DWS) .
1. Introducción
- Versiones aplicables: 8.2.0 y superiores
La función de desensibilización de datos del producto GaussDB (DWS) es un avance tecnológico importante para que los productos de bases de datos internalicen y consoliden las capacidades de seguridad de los datos. Proporciona la función de desensibilización de datos confidenciales a nivel de columna dentro del alcance de los usuarios designados. Tiene las ventajas de flexibilidad, eficiencia, transparencia, amabilidad, etc. Mejora en gran medida las capacidades de seguridad de los datos del producto y logra una protección confiable de los datos confidenciales. .
La llegada de la era del big data ha subvertido el modelo operativo de las empresas tradicionales y ha estimulado nuevo potencial de producción. Los datos se han convertido en un importante factor de producción y un portador de información, y el flujo de datos también oculta información de valor de orden superior. Para los controladores y procesadores de datos, cómo maximizar el valor del flujo de datos es la intención original y la importancia de la minería de datos. Sin embargo, la exposición de una serie de incidentes de fuga de información ha provocado que la seguridad de los datos reciba una atención cada vez más generalizada. Los países y regiones están estableciendo y mejorando gradualmente leyes y regulaciones relacionadas con la seguridad de los datos y la protección de la privacidad para brindar protección legal a la privacidad del usuario. Cómo fortalecer la seguridad de los datos y la protección de la privacidad a nivel técnico y presentar requisitos más funcionales para el producto de almacenamiento de datos en sí es también la forma más efectiva de desarrollar la seguridad de los datos.
La versión 8.1.1 del producto GaussDB (DWS) lanza la función de desensibilización de datos, que proporciona la función de desensibilización para datos confidenciales a nivel de columna dentro del rango de usuario especificado. Tiene las ventajas de flexibilidad, eficiencia, transparencia y facilidad de uso, y mejora enormemente la funcionalidad. capacidades de seguridad de datos del producto.
2. El concepto de desensibilización de datos.
El enmascaramiento de datos, como su nombre indica, consiste en proteger datos confidenciales. Cualquier dato que pueda causar daños graves a la sociedad o a las personas si se filtra es información sensible común. Información de identificación personal, como nombre, número de identificación, dirección, número de teléfono móvil y dirección de correo electrónico. Las empresas no son aptas para divulgar información, como número de licencia comercial, certificado de registro fiscal, salario de los empleados, información del dispositivo como dirección IP, MAC. dirección, número de tarjeta bancaria, información protegida de su salud, derechos de propiedad intelectual, etc., son información confidencial. Esta información sensible se deforma mediante reglas de desensibilización para lograr una protección confiable de los datos privados. Las reglas de desensibilización comunes en la industria incluyen reemplazo, reorganización, cifrado, truncamiento y enmascaramiento. Los usuarios también pueden personalizar las reglas de desensibilización según el algoritmo de desensibilización deseado.
En general, una buena implementación de la desensibilización de datos debe seguir los dos principios siguientes: primero, intentar retener información significativa antes de la desensibilización para las aplicaciones después de la desensibilización; segundo, evitar en la mayor medida posible que los piratas informáticos pirateen.
La desensibilización de datos se divide en desensibilización de datos estática y desensibilización de datos dinámica. La desensibilización de datos estáticos es el "reemplazo por movimiento y simulación" de los datos. Una vez extraídos y desensibilizados, los datos se envían a enlaces descendentes para su libre acceso, lectura y escritura. Después de la desensibilización, los datos se aíslan del entorno de producción, lo que satisface. satisfacer las necesidades empresariales garantizando al mismo tiempo la seguridad de la base de datos de producción. La desensibilización de datos dinámica realiza el procesamiento de desensibilización en tiempo real mientras se accede a datos confidenciales. Puede implementar diferentes esquemas de desensibilización para diferentes roles, diferentes permisos y diferentes tipos de datos, garantizando así que los datos devueltos estén disponibles y sean seguros.
2.1 Desensibilización de datos dinámicos DWS
La función de desensibilización de datos de GaussDB (DWS) abandona los puntos débiles de la alta dependencia y el alto costo de la desensibilización en la capa de aplicación empresarial e internaliza la desensibilización de datos en las capacidades de seguridad del propio producto de base de datos, proporcionando una solución completa, segura, flexible y transparente. set of, una solución amigable de desensibilización de datos, que pertenece a la desensibilización dinámica de datos. Una vez que el usuario identifica los campos confidenciales, puede crear una política de enmascaramiento vinculando la función de enmascaramiento incorporada según el campo de destino. La política de redacción tiene una relación de muchos a uno con el objeto de tabla. Una estrategia de enmascaramiento contiene tres elementos clave: objeto de tabla, condición efectiva, par de función enmascarada y columna enmascarada. Según las diferentes características de los datos, diferentes campos pueden usar diferentes funciones de enmascaramiento. Las estrategias también se pueden establecer en la misma tabla dependiendo de las condiciones efectivas y los pares de funciones de desensibilización y columna de desensibilización. Si y solo si la condición efectiva es verdadera, la declaración de consulta desencadenará la desensibilización de datos confidenciales. El proceso de desensibilización está integrado en el motor SQL y es transparente e invisible para los usuarios del entorno de producción.
Herramienta de desensibilización de agentes de terceros versus motor de desensibilización DWS del almacén de datos
- La herramienta proxy de terceros es una estación de transferencia entre usuarios y clústeres de almacenamiento de datos. Es una herramienta de desensibilización de complementos fuera de la base que no puede participar directamente en el entorno de generación y es difícil de manejar en escenarios complejos.
- DWS es un motor de desensibilización basado en la interacción directa entre la base del almacén de datos y el motor de almacenamiento y el motor SQL. Realiza desensibilización en tiempo real durante el proceso de ejecución de la consulta y los resultados de la desensibilización se devuelven directamente al usuario.
- La herramienta de desensibilización del agente es la desensibilización estática y el motor de desensibilización DWS es la desensibilización dinámica.
Ventajas del motor de desensibilización dinámica DWS
- Buena sinergia base. El motor de desensibilización recorre muchos aspectos de la base del almacén de datos y participa en el análisis, reescritura, optimización y ejecución del motor SQL en función de estrategias de desensibilización preestablecidas. El proceso de desensibilización es invisible para el usuario.
- Las políticas son configurables. Los clientes pueden identificar datos confidenciales en función de sus propios escenarios comerciales y estrategias de desensibilización preestablecidas de manera flexible para columnas designadas de tablas comerciales.
- Las estrategias son escalables. El producto tiene una función de desensibilización incorporada que puede cubrir los efectos de desensibilización más comunes y admite funciones de desensibilización definidas por el usuario.
- Disponibilidad de datos. Los datos confidenciales originales en la base de datos participan en la operación y se desensibilizan solo en el momento de salir de la base de datos (cuando se devuelven los resultados).
-
El acceso a los datos está controlado. Los datos confidenciales originales no serán visibles para los usuarios bajo las condiciones para que la política de desensibilización entre en vigor.
-
No se filtrarán todos los datos de la escena. La interacción de la base puede reducir el riesgo potencial de fuga de enlaces de transmisión de datos confidenciales.
Es más seguro y confiable, identifica completamente varios posibles escenarios de phishing malicioso y brinda una protección efectiva.
3. Cómo utilizar la desensibilización de datos
La desensibilización dinámica de datos es un proceso de desensibilización en tiempo real basado en si se cumplen las condiciones efectivas durante la ejecución de la declaración de consulta. Las condiciones de validación generalmente se basan en el criterio del rol de usuario actual. El rango visible de datos confidenciales está preestablecido para diferentes usuarios. El administrador del sistema tiene la máxima autoridad y puede ver cualquier campo de cualquier tabla en cualquier momento. Identificar roles de usuario restringidos es el primer paso para crear una estrategia de desensibilización.
La información confidencial depende del escenario comercial real y las dimensiones de seguridad. Tomando como ejemplo a las personas físicas, los campos confidenciales de los usuarios individuales incluyen: nombre, número de identificación, número de teléfono móvil, dirección de correo electrónico, etc. en el sistema bancario, como cliente. , también puede involucrar el número de tarjeta bancaria, tiempo de vencimiento, contraseña de pago, etc., en el sistema de la empresa, como empleado, también puede involucrar salario, antecedentes educativos, etc., en el sistema médico, como paciente; también involucran información sobre tratamientos médicos, etc. Por lo tanto, identificar y clasificar campos sensibles en escenarios comerciales específicos es el segundo paso en la creación de una estrategia de desensibilización.
El producto tiene incorporadas una serie de interfaces de funciones de desensibilización comunes, que pueden especificar parámetros para diferentes tipos de datos y características de datos para lograr diferentes efectos de desensibilización. La función de desensibilización puede utilizar las siguientes tres interfaces integradas y también admite funciones de desensibilización personalizadas. Las tres funciones de desensibilización integradas pueden cubrir los efectos de desensibilización en la mayoría de los escenarios. No se recomienda utilizar funciones de desensibilización personalizadas.
-
MASK_NONE: Sin desensibilización, solo para pruebas internas.
-
MASK_FULL: Desensibilización total a un valor fijo.
-
MASK_PARTIAL: utilice los caracteres de enmascaramiento especificados para enmascarar parcialmente el contenido dentro del rango de enmascaramiento.
Diferentes columnas de desensibilización pueden utilizar diferentes funciones de desensibilización. Por ejemplo, los números de teléfonos móviles generalmente muestran los últimos cuatro dígitos y reemplazan los números anteriores con "*" y la cantidad se muestra uniformemente como un valor fijo de 0, etc. Determinar la función de desensibilización que debe estar unida a la columna de desensibilización es el tercer paso en la creación de una estrategia de desensibilización.
Tomando como ejemplo la tabla de empleados emp de una empresa, el usuario propietario de la tabla alice y los usuarios matu y july, presentaremos brevemente el proceso de uso de desensibilización de datos. Entre ellos, la tabla emp contiene los nombres de los empleados, números de teléfonos móviles, correos electrónicos, números de tarjetas de pago, salarios y otros datos privados. La usuaria Alice es la gerente de recursos humanos y los usuarios Matu y July son empleados comunes.
Se supone que los permisos de tabla, usuario y vista del usuario en la tabla emp están todos en su lugar.
1. Cree una política de desensibilización mask_emp, que solo permite a Alice ver toda la información de los empleados. Matu y July no son visibles para los números de tarjetas de nómina ni los salarios. El campo card_no es de tipo numérico y MASK_FULL se usa para desensibilizarlo completamente a un valor fijo de 0; el campo card_string es de tipo carácter y MASK_PARTIAL se usa para desensibilizar parcialmente los datos originales de acuerdo con el formato de entrada y salida especificado; el salario de campo es de tipo numérico y el número 9 se utiliza para insensibilizarlo parcialmente. Todos los valores de dígitos antes del penúltimo dígito.
postgres=# CREAR POLÍTICA DE REDACCIÓN mask_emp ON emp CUANDO (current_user!= 'alice') AÑADIR COLUMNA card_no CON máscara_full (card_no), AÑADIR COLUMNA cadena_tarjeta CON máscara_partial(cadena_tarjeta, 'VVVVFVVVVFVVVVFVVVV','VVVV-VVVV-VVVV-VVVV','#',1,12), AÑADIR COLUMNA salario CON máscara_partial(salario, '9', 1, longitud(salario) - 2);
Cambie a matu y julio y vea la tabla de empleados emp.
postgres=> ESTABLECER ROL matu CONTRASEÑA 'Gauss@123'; postgres=> SELECCIONAR * DESDE emp; identificación | nombre | número_teléfono | número_tarjeta | cadena_tarjeta | correo electrónico | salario | cumpleaños ----+------+-------------+---------+-------------- -------+----------------------+------------+------ --------------- 1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999,9990 | 1999-10-02 00:00:00 2 | bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999,9990 | 1989-12-12 00:00:00 3 | cici | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00 (3 filas) postgres=> ESTABLECER ROL julio CONTRASEÑA 'Gauss@123'; postgres=> SELECCIONAR * DESDE emp; identificación | nombre | número_teléfono | número_tarjeta | cadena_tarjeta | correo electrónico | salario | cumpleaños ----+------+-------------+---------+-------------- -------+----------------------+------------+------ --------------- 1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999,9990 | 1999-10-02 00:00:00 2 | bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999,9990 | 1989-12-12 00:00:00 3 | cici | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00 (3 filas)
2. Por ajuste laboral, matu ingresó al departamento de recursos humanos para participar en los asuntos de reclutamiento de la empresa, y también fue visible toda la información de los empleados, modificando las condiciones de vigencia de la póliza.
postgres=> ALTERAR LA POLÍTICA DE REDACCIÓN mask_emp ON emp CUANDO(current_user NO EN ('alice', 'matu'));
Cambie a los usuarios matu y julio y vuelva a ver la tabla de empleados emp.
postgres=> ESTABLECER ROL matu CONTRASEÑA 'Gauss@123'; postgres=> SELECCIONAR * DESDE emp; identificación | nombre | número_teléfono | número_tarjeta | cadena_tarjeta | correo electrónico | salario | cumpleaños ----+------+-------------+------------------+----- -++----------------------+---------- --+--------------------- 1 | anny | 13420002340 | 1234123412341234 | 1234-1234-1234-1234 | [email protected] | 10000.0000 | 1999-10-02 00:00:00 2 | bob | 18299023211 | 3456345634563456 | 3456-3456-3456-3456 | [email protected] | 9999.9900 | 1989-12-12 00:00:00 3 | cici | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00 (3 filas) postgres=> ESTABLECER ROL julio CONTRASEÑA 'Gauss@123'; postgres=> SELECCIONAR * DESDE emp; identificación | nombre | número_teléfono | número_tarjeta | cadena_tarjeta | correo electrónico | salario | cumpleaños ----+------+-------------+---------+-------------- -------+----------------------+------------+------ --------------- 1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999,9990 | 1999-10-02 00:00:00 2 | bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999,9990 | 1989-12-12 00:00:00 3 | cici | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00 (3 filas)
3. La información del empleado número de teléfono, correo electrónico y fecha de nacimiento también son datos privados. Actualice la política de enmascaramiento de mask_emp y agregue tres columnas de enmascaramiento.
postgres=> ALTERAR LA POLÍTICA DE REDACCIÓN mask_emp ON emp AÑADIR COLUMNA phone_no CON mask_partial(phone_no, '*', 4);
postgres=> ALTERAR LA POLÍTICA DE REDACCIÓN mask_emp ON emp AGREGAR COLUMNA correo electrónico CON máscara_partial(correo electrónico, '*', 1, posición('@' en correo electrónico));
postgres=> ALTERAR LA POLÍTICA DE REDACCIÓN mask_emp ON emp AGREGAR COLUMNA cumpleaños CON mask_full(cumpleaños);
Cambie al usuario julio y vea la tabla de empleados emp.
postgres=> ESTABLECER ROL julio CONTRASEÑA 'Gauss@123'; postgres=> SELECCIONAR * DESDE emp; identificación | nombre | número_teléfono | número_tarjeta | cadena_tarjeta | correo electrónico | salario | cumpleaños ----+------+-------------+---------+-------------- -------+----------------------+------------+------ --------------- 1 | anny | 134********* | 0 | ####-####-####-1234 | ********163.com | 99999,9990 | 1970-01-01 00:00:00 2 | bob | 182********* | 0 | ####-####-####-3456 | ***********qq.com | 9999,9990 | 1970-01-01 00:00:00 3 | cio | 155******** | | | ************sina.com | | 1970-01-01 00:00:00 (3 filas)
4. Teniendo en cuenta la facilidad de interacción del usuario, GaussDB (DWS) proporciona vistas del sistema redaction_policies y redaction_columns para facilitar que los usuarios vean directamente más información de desensibilización.
postgres=> SELECCIONAR * DE redacción_policies;
esquema_objeto | propietario_objeto | nombre_objeto | nombre_política | expresión | habilitar | descripción_política
---------------+--------------+-------------+----- --------+-----------------------------------+----- ---+--------------------
público | alicia | emp | máscara_emp | ("current_user"() = 'julio'::nombre) | t |
(1 fila)
postgres=> SELECCIONE nombre_objeto, nombre_columna, información_función DESDE columnas_redacción;
nombre_objeto | nombre_columna | información_función
-------------+-------------+---------------------- -------------------------------------------------- -------------------------------
emp | número_tarjeta | máscara_completa(número_tarjeta)
emp | cadena_tarjeta | máscara_partial(cadena_tarjeta, 'VVVVFVVVVFVVVVFVVVV'::texto, 'VVVV-VVVV-VVVV-VVVV'::texto, '#'::texto, 1, 12)
emp | correo electrónico | máscara_partial(correo electrónico, '*'::texto, 1, "posición"(correo electrónico, '@'::texto))
emp | salario | máscara_partial(salario, '9'::texto, 1, (longitud((salario::texto) - 2))
emp | cumpleaños | máscara_completa (cumpleaños)
emp | número_teléfono | máscara_partial(número_teléfono, '*'::texto, 4)
(6 filas)
5. De repente, un día, cuando la información de los empleados se pueda compartir dentro de la empresa, simplemente elimine la política de enmascaramiento mask_emp de la tabla emp.
postgres=> ELIMINAR POLÍTICA DE REDACCIÓN mask_emp ON emp;
Para obtener más detalles de uso, consulte la documentación del producto GaussDB (DWS).
4. Desensibilización de datos invisibles
Cuando se utiliza la función de desensibilización de datos, puede haber casos en los que los datos confidenciales se procesen y calculen antes de su salida. En este caso, si los datos desensibilizados se utilizan para cálculos en la base de datos, los datos desensibilizados en sí tendrán un impacto en los resultados de la consulta en condiciones tales como funciones agregadas y condiciones de filtro. Por lo tanto, los datos desensibilizados se utilizarán para abordar este fenómeno. Min introduce la capacidad de contar como invisible. Lo llamado invisible significa que los datos confidenciales originales se utilizan en la base de datos para participar en los cálculos de procesamiento, y los datos confidenciales solo se desensibilizan cuando se envían fuera de la base de datos. Para utilizar la función invisible computable, debe configurar el interruptor enable_redactcol_computable=on.
Actualmente, los escenarios que soportan la participación directa de datos sensibles en los cálculos de procesamiento son los siguientes:
-
SELECT nullif(salario, 1) FROM emp; expresión de columna de proyección nullif;
-
SELECCIONE el correo electrónico COMO '%.com' DESDE emp; columna proyectada COMO expresión
-
SELECCIONE to_days(nacimiento) FROM david.emp; Función de columna de proyección to_days;
-
SELECCIONE el recuento (*) DE la función agregada emp;
-
SELECCIONE * DESDE emp DONDE cardid NO ES NULO condiciones de filtro;
-
SELECCIONE nombre, promedio (salario) * 12 FROM emp GROUP BY nombre condición de agrupación (el nombre es un campo no sensible)
-
SELECT (SELECT salario+10 FROM emp ORDER BY id LIMIT 1 Expresión de columna de proyección de posición de subconsulta);
-
Las dos tablas utilizan campos confidenciales como condiciones de asociación.
-
Columna proyectada de expresión CTE
Los escenarios que desencadenan la desensibilización de los datos en el momento del envío son los siguientes:
-
consulta de tabla
-
Ver consulta
-
Cláusula de retorno DML
-
COPYExportar
-
Exportación de tablas GDS
-
CURSOR… BUSCAR
-
La definición del procedimiento almacenado utiliza la tabla enmascarada para consultar el procedimiento almacenado.
4.1 Herencia de la estrategia de desensibilización
Para las declaraciones INSERT/UPDATE/MERGE INTO/CREATE TABLE AS, cuando la subconsulta es una operación de proyección en un campo confidencial, se activará la herencia desensibilizada, de modo que la nueva tabla que contiene información confidencial contenga la misma información que la tabla de origen. La estrategia evita el problema de la filtración de datos confidenciales al insertar datos confidenciales de la tabla de origen en una nueva tabla y luego consultar la nueva tabla. Además, la herencia de la política de enmascaramiento pertenece a la actividad de dimensión de la tabla, y la actividad de herencia no presta atención a si la política de enmascaramiento surte efecto en la sesión actual o en las condiciones de rol en la parte de subconsulta.
El primer paso para heredar la estrategia de desensibilización es realizar un análisis de linaje sensible para que cualquier usuario ejecute una declaración DML, la parte de subconsulta de la tabla de origen y su columna de proyección de destino se recorrerán una vez que la estrategia de desensibilización exista en la tabla de origen. la columna de proyección de destino es un campo de desensibilización. Se considera que cuando se utiliza la tabla de origen para insertar/actualizar datos de la tabla de destino, existe el riesgo de exponer datos confidenciales de la tabla de origen.
Al heredar una estrategia de enmascaramiento, primero genere la información de la estrategia de enmascaramiento y la información del campo de enmascaramiento que se aplica a la tabla de destino a partir de la información confidencial de la tabla de origen marcada en el recorrido. Luego, el sistema integrado genera una declaración de creación de políticas y la escribe en la tabla del sistema pg_redaction_policy/pg_redaction_column. La política de desensibilización integrada se denomina "inherited_rp". Finalmente, establezca el campo de marca de herencia de metadatos de la tabla del sistema en verdadero.
Tenga en cuenta que si la sesión/usuario de ejecución INSERT cumple con las condiciones de activación, cuando el resultado de la inserción se imprima con la cláusula RETURNING, el resultado devuelto se desensibilizará y la información de registro "Políticas/columnas de redacción principal" registrará el origen de la herencia de políticas. .
Con la introducción del comportamiento de herencia de políticas de desensibilización, han surgido algunos escenarios de conflicto de políticas de desensibilización. Por ejemplo, la columna de destino de la consulta de la instrucción SELECT no es el campo sensible original, sino una expresión compleja del campo sensible. La expresión se calcula primero y luego se desensibiliza. ¿Cómo definir el comportamiento de desensibilización en este caso? Las dos subramas de la operación de conjunto SETOP utilizan diferentes efectos de desensibilización para la misma columna de destino. ¿Cómo definir el resultado de desensibilización de la columna de destino de la declaración externa en este momento? En el análisis de linaje sensible de múltiples operaciones INSERT/UPDATE, las columnas de proyección de la tabla fuente de la misma columna de destino adoptan diferentes efectos de desensibilización, y las condiciones efectivas de la política de la tabla fuente también pueden ser diferentes. ¿Cómo se debe heredar la política de desensibilización en este caso? ?
Para estos escenarios de conflicto, basándose en el principio de que proteger cualquier dato sensible del usuario para que no se filtre tiene prioridad sobre el efecto de desensibilización de los datos sensibles que no tienen características originales, cuando se encuentra un conflicto de efecto de desensibilización, se actualiza al general. efecto desensibilizante mask_full. mask_full es una función de enmascaramiento completa que puede cubrir cualquier tipo de datos. Solo se centra en el tipo de valor de retorno de la expresión, lo que puede garantizar que los datos enmascarados no se filtren. Sin embargo, el resultado enmascarado no podrá representar las características del. datos originales, lo que hace que el resultado enmascarado sea menos legible. Además, para expresiones de funciones como longitud y recuento, los resultados del cálculo no expondrán ninguna característica e información de datos originales, por lo que la sintaxis ALTER FUNCTION... [NOT] MASKED se proporciona para ayudar a los usuarios a configurar manualmente una función no desensibilizante. lista blanca.
4.2 Protección contra phishing malicioso
Se conoce cierta información confidencial y, a través de múltiples coincidencias heurísticas, la información visible del usuario se corrobora de manera inversa, robando así los datos privados del usuario. Haga coincidir heurísticamente información confidencial utilizando condiciones de filtro u operaciones de proyección que ayuden a las expresiones en forma de juicios de equivalencia. Estos comportamientos de extraer datos privados del usuario a través de valores constantes conocidos y expresiones de juicio de equivalencia/equivalencia similar son intentos maliciosos.
postgres=> SELECCIONAR nombre DESDE emp DONDE nombre en('张三');
INFORMACIÓN: El resultado de la columna de destino {"nombre"} está enmascarado.
nombre
------
abierto*
(1 fila)
Como se muestra en el ejemplo anterior, aunque la información del nombre del usuario ha sido desensibilizada, dado que la condición de consulta es para el usuario 'Zhang San', incluso si está desensibilizada para 'Zhang*', aún podemos determinar fácilmente la desensibilización aquí. La información confidencial es 'Zhang San', lo que conlleva el riesgo de fuga de información del usuario de Zhang San.
En respuesta a este problema, hemos adoptado un modelo de "pesimismo". Cualquier juicio de equivalencia constante puede tener el riesgo de un arbitraje malicioso y debería prohibirse. Los ejemplos son los siguientes:
postgres=> SELECCIONAR nombre DESDE emp DONDE nombre en('张三');
ERROR: No se puede hacer referencia a la columna de redacción "nombre" en condiciones de equivalencia con valor constante.
SUGERENCIA: utilice el comando EXPLICAR para ver más detalles.
Los escenarios en los que se prohíbe el arbitraje malicioso utilizando constantes se resumen a continuación:
1. Expresiones de juicio de equivalencia constante, expresiones compuestas y expresiones equivalentes para campos insensibilizados
2. Suponiendo que el campo de nombre es un campo insensibilizado y la sesión actual cumple con las condiciones de activación de la política, la declaración tiene las siguientes (pero no se limitan a) características, existe el riesgo de arbitraje malicioso y la ejecución está prohibida:
• nombre = 'Zhang San'
• nombre = 'Zhang San' O nombre = '李思'
• nombre en ('Zhang San', '李思')
• Nombre del CASO CUANDO '张三' ENTONCES verdadero...
• CASO CUANDO nombre en ('张三', '李思') ENTONCES…
• Paquete avanzado dbms_output.put_line
3. Se informará un error cuando se ejecute la declaración: ERROR: No se puede hacer referencia a la columna de redacción “nombre” en condiciones de equivalencia con valor constante.
5. Principio de implementación de la desensibilización de datos.
La función de desensibilización de datos de GaussDB (DWS) se basa en el marco de implementación existente del motor SQL y permite un procesamiento de desensibilización en tiempo real que es imperceptible para el mundo exterior durante la ejecución de declaraciones de consulta por parte de usuarios restringidos. En cuanto a su implementación interna, se muestra en la figura anterior. Consideramos la política de redacción como una regla vinculada al objeto de la tabla. Durante la fase de reescritura de la consulta del optimizador, se atraviesa cada TargetEntry de TargetList en el árbol de consulta si está involucrada una columna de redacción de la tabla base y el momento actual. la regla de desensibilización entra en vigor (es decir, se cumplen las condiciones efectivas de la política de desensibilización y se activa la habilitación), se concluye que el objeto Var que se va a desensibilizar está involucrado en este TargetEntry. En este momento, la tabla del sistema de columnas de desensibilización. Se recorre pg_redaction_column para encontrar el enlace de la columna de desensibilización correspondiente. Una determinada función de desensibilización se puede reemplazar por el FuncExpr correspondiente. Después de la reescritura anterior del árbol de consultas, el optimizador generará automáticamente un nuevo plan de ejecución, el ejecutor ejecutará de acuerdo con el nuevo plan y los resultados de la consulta quedarán insensibles a los datos confidenciales.
En comparación con la declaración original, la ejecución de la declaración con desensibilización de datos agrega un procesamiento lógico de desensibilización de datos, lo que inevitablemente traerá una sobrecarga adicional a la consulta. Este costo se ve afectado principalmente por tres factores: el tamaño de los datos de la tabla, el número de columnas enmascaradas involucradas en la consulta de la columna de destino y la función de enmascaramiento utilizada en la columna enmascarada.
Para una declaración de consulta simple, tome la tabla tpch cliente como ejemplo para probar los factores anteriores, como se muestra en la siguiente figura.
En las Figuras (a) y (b), el cliente de la tabla base utiliza la función de desensibilización MASK_FULL o la función de desensibilización MASK_PARTIAL según el tipo de campo y las características. MASK_FULL solo desensibiliza los datos originales de cualquier longitud y tipo a un valor fijo, por lo que el resultado de salida es muy diferente de los datos originales. La Figura (a) muestra el tiempo de ejecución de declaraciones de consulta simples en escenarios insensibilizados y no insensibilizados bajo diferentes escalas de datos. Los íconos sólidos representan escenarios sin desensibilización y los íconos huecos representan usuarios restringidos, es decir, escenarios de desensibilización. Se puede ver que cuanto mayor es el tamaño de los datos, mayor es la diferencia entre el tiempo de consulta con desensibilización y la declaración original. La Figura (b) muestra el impacto de diferentes números de columnas enmascaradas involucradas en la consulta en el rendimiento de ejecución de declaraciones en una escala de datos de 10x. Cuando se trata de una columna enmascarada, la consulta con enmascaramiento es más lenta que la declaración original. Se remonta a que esta columna utiliza la función de enmascaramiento parcial MASK_PARTIAL. El resultado de la consulta solo cambia el formato del resultado y la longitud del contenido del resultado. no cambia. Está en línea con la conjetura teórica de que "la ejecución de declaraciones con desensibilización tendrá la correspondiente degradación del rendimiento". A medida que aumentó el número de columnas enmascaradas involucradas en la consulta, descubrimos un fenómeno extraño. El escenario insensibilizado en realidad se ejecutó más rápido que la declaración original. Al rastrear más a fondo las funciones de enmascaramiento asociadas con las columnas enmascaradas en escenarios de varias columnas, descubrimos que es precisamente debido a que las columnas enmascaradas usan la función de enmascaramiento MASK_FULL que el conjunto de resultados de salida ahorra mucho tiempo en comparación con los datos originales, lo que hace que el conjunto de resultados de salida ahorre mucho tiempo en comparación con los datos originales. -Las consultas de columnas son más eficientes. Las consultas simples con enmascaramiento de datos son en realidad mucho más rápidas.
Para respaldar la especulación anterior, ajustamos la función de enmascaramiento. Todas las columnas enmascaradas usan MASK_PARTIAL para enmascarar parcialmente los datos originales, de modo que la legibilidad externa de los datos originales se pueda conservar en los resultados del enmascaramiento. Por lo tanto, como se muestra en la Figura ©, cuando todas las columnas enmascaradas están asociadas con funciones de enmascaramiento parcial, la declaración con enmascaramiento de datos es aproximadamente un 10% peor que la declaración original. En teoría, esta degradación está dentro del rango aceptable. La prueba anterior es solo para declaraciones de consulta simples. Cuando la declaración es lo suficientemente compleja como para incluir funciones agregadas u operaciones de expresión complejas, esta degradación del rendimiento puede ser más obvia.
6. Resumen
La función de desensibilización de datos del producto GaussDB (DWS) es un avance tecnológico importante para que los productos de bases de datos internalicen y consoliden las capacidades de seguridad de los datos. Cubre principalmente los siguientes tres aspectos:
Un conjunto de sintaxis simple y fácil de usar para estrategias de desensibilización de datos;
Una serie de funciones de desensibilización integradas configuradas de manera flexible que cubren efectos comunes de desensibilización de datos privados;
Una solución de aplicación de estrategia de desensibilización completa y conveniente permite la desensibilización transparente, eficiente y en tiempo real de las declaraciones originales durante la ejecución.
En general, esta función de desensibilización de datos puede cumplir plenamente con los requisitos de desensibilización de datos de los escenarios comerciales de los clientes, respaldar el efecto de desensibilización de datos privados comunes y lograr una protección confiable de datos confidenciales.
[Recordatorio] Si tiene alguna pregunta durante el uso, no dude en comunicarse y enviar comentarios en cualquier momento.
Haga clic para seguir y conocer las nuevas tecnologías de Huawei Cloud lo antes posible ~
Los estudiantes de secundaria crean su propio lenguaje de programación de código abierto como una ceremonia de mayoría de edad: comentarios agudos de los internautas: confiando en la defensa, Apple lanzó el chip M4 RustDesk Los servicios nacionales fueron suspendidos debido al fraude desenfrenado Yunfeng renunció a Alibaba. En el futuro, planea producir un juego independiente en la plataforma Windows Taobao (taobao.com). Reiniciar el trabajo de optimización de la versión web, destino de los programadores, Visual Studio Code 1.89 lanza Java 17, la versión Java LTS más utilizada, Windows 10 tiene un cuota de mercado del 70%, Windows 11 continúa disminuyendo Open Source Daily | Google apoya a Hongmeng para que se haga cargo; Rabbit R1 de código abierto respalda los teléfonos Android; Haier Electric ha cerrado la plataforma abierta;