Consideraciones al utilizar el enmascaramiento dinámico de datos

PDFRSS

Cuando utilice el enmascaramiento dinámico de datos, tenga en cuenta lo siguiente:

• Al consultar objetos creados a partir de tablas, como las vistas, los usuarios verán los resultados según sus propias políticas de enmascaramiento, no las políticas del usuario que creó los objetos. Por ejemplo, un usuario con el rol de analista que consulte una vista creada por un administrador de seguridad (secadmin) vería resultados con políticas de enmascaramiento adjuntas al rol de analista.

• Para evitar que el comando EXPLAIN exponga potencialmente filtros confidenciales de políticas de enmascaramiento, solo los usuarios con el permiso SYS_EXPLAIN_DDM pueden ver las políticas de enmascaramiento aplicadas en los resultados de EXPLAIN. Los usuarios no tienen el permiso SYS_EXPLAIN_DDM de forma predeterminada.

  A continuación, se muestra la sintaxis para conceder el permiso a un rol.

  GRANT EXPLAIN MASKING TO ROLE rolename

  Para obtener más información sobre el comando EXPLAIN, consulte EXPLAIN.

• Los usuarios con distintos roles pueden ver resultados diferentes en función de las condiciones de filtrado o de combinación utilizadas. Por ejemplo, se producirá un error en la ejecución de un comando SELECT en una tabla mediante el valor de una columna específica si el usuario que ejecuta el comando tiene aplicada una política de enmascaramiento que ofusca esa columna.

• Las políticas de enmascaramiento dinámico de datos se deben aplicar antes de cualquier operación de predicado o proyección. Las políticas de enmascaramiento pueden incluir lo siguiente:

  • Operaciones constantes de bajo costo como convertir un valor en nulo

  • Operaciones de costo moderado, por ejemplo, creación de hash HMAC

  • Operaciones de costo elevado, como las llamadas a funciones Lambda externas definidas por el usuario

  Por lo tanto, le recomendamos que utilice expresiones de enmascaramiento simples siempre que sea posible.

• Puede utilizar políticas de enmascaramiento dinámico de datos para roles con políticas de seguridad a nivel de fila, pero tenga en cuenta que las políticas de RLS se aplican antes que las de enmascaramiento dinámico de datos. Una expresión de enmascaramiento dinámico de datos no podrá leer una fila protegida por RLS. Para obtener más información sobre RLS, consulte Seguridad de nivel básico.

• Cuando utilice el comando COPY para copiar de parquet a tablas de destino protegidas, deberá especificar explícitamente las columnas en la instrucción COPY. Para obtener más información sobre la asignación de columnas con COPY, consulte Opciones de mapeo de columnas.

• Las políticas de DDM no se pueden asociar a las siguientes relaciones:

  • Tablas y catálogos del sistema

  • tablas externas

  • Tablas de recursos compartidos de datos

  • Vistas materializadas

  • Relaciones entre bases de datos

  • Tablas temporales

  • Consultas correlacionadas

• Las políticas de DDM pueden incluir tablas de consulta. Las tablas de consulta pueden estar presentes en la cláusula USING. Los siguientes tipos de relaciones no se pueden usar como tablas de consulta:

  • Tablas y catálogos del sistema

  • tablas externas

  • Tablas de recursos compartidos de datos

  • Vistas, vistas materializadas y vistas de enlace tardío

  • Relaciones entre bases de datos

  • Tablas temporales

  • Consultas correlacionadas

  A continuación, se ofrece un ejemplo de una política de enmascaramiento a una tabla de búsqueda.

  --Create a masking policy referencing a lookup table
  CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
    CASE
      WHEN
        credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)      
      THEN '000000XXXX0000'
      ELSE REDACT_CREDIT_CARD(credit_card)
      END
    ); 
    
  --Provides access to the lookup table via a policy attached to a role
  GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;

• No puede adjuntar una política de enmascaramiento que produzca un resultado incompatible con el tipo y el tamaño de la columna de destino. Por ejemplo, no puede adjuntar una política de enmascaramiento que produzca una cadena de 12 caracteres de longitud para una columna VARCHAR(10). Amazon Redshift admite las siguientes excepciones:

  • Una política de enmascaramiento con el tipo de entrada INTN puede adjuntarse a una política con un tamaño INTM siempre que M < N. Por ejemplo, una política de entrada BIGINT (INT8) puede adjuntarse a una columna smallint (INT4).

  • Una política de enmascaramiento con el tipo de entrada NUMERIC o DECIMAL siempre puede adjuntarse a una columna FLOAT.

• Las políticas de enmascaramiento dinámico de datos no pueden utilizarse con el uso compartido de datos. Si el productor de datos del recurso compartido de datos asocia una política de enmascaramiento dinámico de datos a una tabla del recurso compartido de datos, dicha tabla se convierte en inaccesible para los usuarios del consumidor de datos que intentan consultarla. Las tablas con políticas de enmascaramiento dinámico de datos asociadas no pueden agregarse a un recurso compartido de datos.

• No puede consultar las relaciones que tienen asociadas políticas de enmascaramiento dinámico de datos si los valores de alguna de las siguientes opciones de configuración no coinciden con el valor predeterminado de la sesión:

  • enable_case_sensitive_super_attribute

  • enable_case_sensitive_identifier

  • downcase_delimited_identifier

  Considere la posibilidad de restablecer las opciones de configuración de la sesión si intenta consultar una relación con una política de enmascaramiento dinámico de datos asociada y ve el mensaje “La relación protegida de enmascaramiento dinámico de datos no admite la configuración de nivel de sesión porque la distinción entre mayúsculas y minúsculas es diferente de su valor predeterminado”.

• Cuando el clúster o espacio de nombres sin servidor aprovisionado tiene alguna política de enmascaramiento de datos dinámica, los siguientes comandos están bloqueados para los usuarios habituales:

  ALTER <current_user> SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier

  Al crear políticas de enmascaramiento dinámico de datos, le recomendamos que cambie las opciones de configuración predeterminadas para los usuarios habituales para que coincidan con las opciones de configuración de la sesión en el momento en que se creó la política. Los superusuarios y los usuarios con el privilegio ALTER USER pueden hacerlo mediante la configuración del grupo de parámetros o el comando ALTER USER. Para obtener información sobre grupos de parámetros, consulte Grupos de parámetros de Amazon Redshift en la Guía de administración de Amazon Redshift. Para obtener información sobre el comando ALTER USER, consulte ALTER USER.

• Los usuarios habituales no pueden reemplazar las vistas y las vistas de enlace tardío con políticas de DDM asociadas que utilicen el comando CREATE VIEW. Para reemplazar las vistas o LBV por políticas de RLS, primero debe separar las políticas de RLS asociadas a ellas, sustituir las vistas o LBV y volver a adjuntar las políticas. Los superusuarios y los usuarios que dispongan del permiso sys:secadmin pueden utilizar CREATE VIEW en vistas o LBV con políticas de DDM sin tener que separar las políticas.

• Las vistas con políticas de DDM asociadas no pueden hacer referencia a las tablas y vistas del sistema. Las vistas de enlace tardío pueden hacer referencia a tablas y vistas del sistema.

• Las vistas de enlace tardío con políticas de DDM asociadas no pueden hacer referencia a los datos anidados de los lagos de datos, como los documentos JSON.

• Las vistas de enlace tardío no pueden tener políticas de DDM asociadas si alguna vista hace referencia a esa vista de enlace tardío.

• Las políticas de DDM asociadas a las vistas de enlace tardío se asocian por nombre de columna. En el momento de la consulta, Amazon Redshift valida que todas las políticas de enmascaramiento asociadas a la vista de enlace tardío se hayan aplicado correctamente y que el tipo de columna de salida de la vista de enlace tardío coincida con los tipos de las políticas de enmascaramiento asociadas. Si se produce un error en la validación, Amazon Redshift devuelve un error para la consulta.

• Puede utilizar variables de contexto de sesión personalizadas al crear políticas de DDM. En el ejemplo siguiente se establecen variables de contexto para una política de DDM.

  -- Set a customized context variable.
  SELECT set_config('app.city', 'XXXX', FALSE);
  
  -- Create a MASKING policy using current_setting() to get the value of a customized context variable.
  CREATE MASKING POLICY city_mask
  WITH (city VARCHAR(30))
  USING (current_setting('app.city')::VARCHAR(30));
  
  -- Attach the policy on the target table to one or more roles.
  ATTACH MASKING POLICY city_mask 
  ON tickit_users_redshift(city) 
  TO ROLE analyst, ROLE dbadmin;

  Para obtener más detalles sobre cómo configurar y recuperar variables de contexto de sesión personalizadas, vaya a SET, SET_CONFIG, SHOW, CURRENT_SETTING y RESET. Para obtener más información sobre la modificación de la configuración del servidor en general, vaya a Modificación de la configuración del servidor.

  importante

  Cuando se utilizan variables de contexto de sesión en las políticas de DDM, la política de seguridad depende del usuario o rol que la invoca. Tenga cuidado de evitar vulnerabilidades de seguridad al utilizar variables de contexto de sesión en las políticas de DDM.