Información general Ejemplo completo Consideraciones al utilizar el enmascaramiento dinámico de datos

Enmascaramiento de datos dinámico

Información general

Mediante el enmascaramiento dinámico de datos (DDM) en Amazon Redshift, puede proteger los datos confidenciales de su almacenamiento de datos. Puede manipular la forma en que Amazon Redshift muestra los datos confidenciales al usuario en el momento de la consulta, sin transformarlos en la base de datos. El acceso a los datos se controla mediante políticas de enmascaramiento que aplican reglas de ofuscación personalizadas a un usuario o rol determinados. De este modo, puede responder a los cambiantes requisitos de privacidad sin alterar los datos subyacentes ni editar las consultas SQL.

Las políticas de enmascaramiento dinámico de datos ocultan, ofuscan o seudonimizan los datos que coinciden con un formato determinado. Cuando se adjunta a una tabla, la expresión de enmascaramiento se aplica a una o varias de sus columnas. Puede modificar aún más las políticas de enmascaramiento para aplicarlas solo a determinados usuarios o a roles definidos por el usuario que puede crear con Control de acceso basado en roles (RBAC). Además, puede aplicar el enmascaramiento dinámico de datos en el nivel de celda mediante el uso de columnas condicionales al crear la política de enmascaramiento. Para obtener más información sobre el enmascaramiento condicional, consulte Enmascaramiento dinámico y condicional de datos.

Puede aplicar varias políticas de enmascaramiento con diferentes niveles de ofuscación a la misma columna de una tabla y asignarlas a diferentes roles. Para evitar conflictos cuando tiene diferentes roles con distintas políticas que se aplican a una columna, puede establecer prioridades para cada aplicación. De este modo, puede controlar a qué datos puede acceder un determinado usuario o rol. Las políticas de enmascaramiento dinámico de datos pueden elaborar parcial o totalmente los datos, o crear un hash de ellos utilizando funciones definidas por el usuario escritas en SQL o Python, o con AWS Lambda. Al enmascarar los datos mediante hashes, puede aplicar combinaciones en estos datos sin acceder a información potencialmente confidencial.

Ejemplo completo

A continuación, se presenta un ejemplo completo en el que se muestra cómo puede crear y adjuntar políticas de enmascaramiento a una columna. Estas políticas permiten a los usuarios acceder a una columna y ver diferentes valores, según el grado de ofuscación de las políticas asociadas a sus roles. Debe ser superusuario o tener el rol sys:secadmin para ejecutar este ejemplo.

Creación de una política de enmascaramiento

En primer lugar, cree una tabla y rellénela con los valores de tarjeta de crédito.


--create the table         
CREATE TABLE credit_cards (
  customer_id INT,
  credit_card TEXT
);

--populate the table with sample values
INSERT INTO credit_cards
VALUES
  (100, '4532993817514842'),
  (100, '4716002041425888'),
  (102, '5243112427642649'),
  (102, '6011720771834675'),
  (102, '6011378662059710'),
  (103, '373611968625635')
;

--run GRANT to grant permission to use the SELECT statement on the table
GRANT SELECT ON credit_cards TO PUBLIC;

--create two users
CREATE USER regular_user WITH PASSWORD '1234Test!';

CREATE USER analytics_user WITH PASSWORD '1234Test!';

--create the analytics_role role and grant it to analytics_user
--regular_user does not have a role
CREATE ROLE analytics_role;

GRANT ROLE analytics_role TO analytics_user;

A continuación, cree una política de enmascaramiento para aplicarla al rol de análisis.


--create a masking policy that fully masks the credit card number
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);

--create a user-defined function that partially obfuscates credit card data
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT)
RETURNS TEXT IMMUTABLE
AS $$
    import re
    regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
 
    match = regexp.search(credit_card)
    if match != None:
        first = match.group(1)
        last = match.group(2)
    else:
        first = "000000"
        last = "0000"
    
    return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;

--create a masking policy that applies the REDACT_CREDIT_CARD function
CREATE MASKING POLICY mask_credit_card_partial
WITH (credit_card VARCHAR(256))
USING (REDACT_CREDIT_CARD(credit_card));

--confirm the masking policies using the associated system views
SELECT * FROM svv_masking_policy;

SELECT * FROM svv_attached_masking_policy;

Asociación de una política de enmascaramiento

Adjunte las políticas de enmascaramiento a la tabla de tarjetas de crédito.


--attach mask_credit_card_full to the credit card table as the default policy
--all users will see this masking policy unless a higher priority masking policy is attached to them or their role
ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO PUBLIC;

--attach mask_credit_card_partial to the analytics role
--users with the analytics role can see partial credit card information
ATTACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
TO ROLE analytics_role
PRIORITY 10;

--confirm the masking policies are applied to the table and role in the associated system view
SELECT * FROM svv_attached_masking_policy;

--confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user
SET SESSION AUTHORIZATION regular_user;

SELECT * FROM credit_cards;

--confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user
SET SESSION AUTHORIZATION analytics_user;

SELECT * FROM credit_cards;

Creación de una política de enmascaramiento

En la siguiente sección, se muestra cómo modificar una política de enmascaramiento de datos dinámico.


--reset session authorization to the default
RESET SESSION AUTHORIZATION;

--alter the mask_credit_card_full policy
ALTER MASKING POLICY mask_credit_card_full
USING ('00000000000000'::TEXT);	
	
--confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000'
SELECT * FROM credit_cards;

Desconexión y eliminación de una política de enmascaramiento

En la siguiente sección se muestra cómo desconectar y eliminar las políticas de enmascaramiento mediante la eliminación de todas las políticas de enmascaramiento de datos dinámicos de la tabla.


--reset session authorization to the default
RESET SESSION AUTHORIZATION;

--detach both masking policies from the credit_cards table
DETACH MASKING POLICY mask_credit_card_full 
ON credit_cards(credit_card) 
FROM PUBLIC;

DETACH MASKING POLICY mask_credit_card_partial 
ON credit_cards(credit_card) 
FROM ROLE analytics_role;

--drop both masking policies
DROP MASKING POLICY mask_credit_card_full;

DROP MASKING POLICY mask_credit_card_partial;

Consideraciones al utilizar el enmascaramiento dinámico de datos

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.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Seguridad de los metadatos

Administración de políticas de enmascaramiento dinámico de datos