Seleccione sus preferencias de cookies

Usamos cookies esenciales y herramientas similares que son necesarias para proporcionar nuestro sitio y nuestros servicios. Usamos cookies de rendimiento para recopilar estadísticas anónimas para que podamos entender cómo los clientes usan nuestro sitio y hacer mejoras. Las cookies esenciales no se pueden desactivar, pero puede hacer clic en “Personalizar” o “Rechazar” para rechazar las cookies de rendimiento.

Si está de acuerdo, AWS y los terceros aprobados también utilizarán cookies para proporcionar características útiles del sitio, recordar sus preferencias y mostrar contenido relevante, incluida publicidad relevante. Para aceptar o rechazar todas las cookies no esenciales, haga clic en “Aceptar” o “Rechazar”. Para elegir opciones más detalladas, haga clic en “Personalizar”.

Consideraciones y limitaciones sobre el uso de las políticas de RLS - Amazon Redshift

Consideraciones y limitaciones sobre el uso de las políticas de RLS

Consideraciones

A continuación, se indican los aspectos que se deben tener en cuenta para trabajar con políticas de RLS:

  • Amazon Redshift aplica políticas de RLS a las instrucciones SELECT, UPDATE o DELETE.

  • Amazon Redshift no aplica políticas de RLS a las instrucciones INSERT, COPY, ALTER TABLE APPEND.

  • La seguridad de la fila funciona con la seguridad de la columna para proteger los datos.

  • Cuando el clúster de Amazon Redshift estaba en la última versión disponible de forma general que admite RLS, pero pasa a una versión anterior, Amazon Redshift devuelve un error al ejecutar una consulta en tablas base con políticas de RLS adjuntas. El rol sys:secadmin puede revocar el acceso de los usuarios a los que se les concedieron políticas restringidas, desactivar la RLS en las tablas y eliminar las políticas.

  • Cuando se activa RLS para la relación de origen, Amazon Redshift admite la instrucción ALTER TABLE APPEND para los superusuarios, los usuarios a los que se les otorgó de forma explícita el permiso del sistema IGNORE RLS o el rol sys:secadmin. En este caso, con la instrucción ALTER TABLE APPEND, puede mover datos de una tabla de origen existente para anexar filas en una tabla de destino. Amazon Redshift mueve todas las tuplas de la relación de origen a la relación de destino. El estado de RLS de la relación de destino no afecta a la instrucción ALTER TABLE APPEND.

  • Para facilitar la migración desde otros sistemas de almacenamiento de datos, puede configurar y recuperar variables de contexto de sesión personalizadas de una conexión especificando el nombre y el valor de la variable.

    En el siguiente ejemplo, se establecen variables de contexto de sesión para una política de seguridad de la fila (RLS).

    -- Set a customized context variable. SELECT set_config(‘app.category’, ‘Concerts’, FALSE); -- Create a RLS policy using current_setting() to get the value of a customized context variable. CREATE RLS POLICY policy_categories WITH (catgroup VARCHAR(10)) USING (catgroup = current_setting('app.category', FALSE)); -- Set correct roles and attach the policy on the target table to one or more roles. ATTACH RLS POLICY policy_categories ON tickit_category_redshift 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 RLS, 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 RLS.

  • El cambio de usuario de sesión mediante SET SESSION AUTHORIZATION entre DECLARE y FETCH o entre instrucciones FETCH posteriores no actualizará el plan ya preparado basado en las políticas de usuario en el momento de DECLARE. Evite cambiar de usuario de sesión cuando se utilicen cursores con tablas protegidas por RLS.

  • Cuando los objetos base que se encuentran en un objeto de vista están protegidos por RLS, las políticas asociadas al usuario que ejecuta la consulta se aplican a los objetos base respectivos. Esto es diferente de las comprobaciones de permisos en el nivel de objeto, donde los permisos del propietario de la vista se comprueban con los objetos base de la vista. Puede ver las relaciones protegidas por RLS de una consulta en su resultado del plan EXPLAIN.

  • Cuando se hace referencia a una función definida por el usuario (UDF) en una política de RLS de una relación adjunta a un usuario, el usuario debe tener el permiso EXECUTE sobre la UDF para consultar la relación.

  • La seguridad en el nivel de la fila puede limitar la optimización de las consultas. Recomendamos evaluar detenidamente el rendimiento de las consultas antes de implementar vistas protegidas por RLS en conjuntos de datos grandes.

  • Las políticas de seguridad en el nivel de la fila que se aplican a las vistas de enlace tardío podrían incorporarse en las tablas federadas. Estas políticas de RLS pueden estar visibles en los registros de los motores de procesamiento externos.

Limitaciones

A continuación, se indican las limitaciones al trabajar con políticas de RLS:

  • Amazon Redshift admite las instrucciones SELECT para determinadas políticas de RLS con búsquedas que tienen uniones complejas, pero no admite las instrucciones UPDATE o DELETE. En los casos con instrucciones UPDATE o DELETE, Amazon Redshift devuelve el siguiente error:

    ERROR: One of the RLS policies on target relation is not supported in UPDATE/DELETE.
  • Siempre que se hace referencia a una función definida por el usuario (UDF) en una política de RLS de una relación adjunta a un usuario, el usuario debe tener el permiso EXECUTE sobre la UDF para consultar la relación.

  • No se admiten las subconsultas correlacionadas. Amazon Redshift devuelve el siguiente error:

    ERROR: RLS policy could not be rewritten.
  • Las políticas de RLS no se pueden adjuntar a tablas externas.

  • Amazon Redshift no admite el uso de recursos compartidos de datos con RLS. Si una relación no tiene el RLS desactivado para los recursos compartidos de datos, se produce un error en la consulta en el clúster de consumidores y se produce el siguiente error:

    RLS-protected relation "rls_protected_table" cannot be accessed via datasharing query.

    Puede desactivar el RLS para los recursos compartidos de datos mediante el comando ALTER TABLE con el parámetro ROW LEVEL SECURITY OFF FOR DATASHARES. Para obtener más información sobre el uso de ALTER TABLE para habilitar o deshabilitar RLS, vaya a ALTER TABLE.

  • En las consultas entre bases de datos, Amazon Redshift bloquea las lecturas en las relaciones protegidas por RLS. Los usuarios con el permiso IGNORE RLS pueden acceder a la relación protegida mediante consultas entre bases de datos. Cuando un usuario sin el permiso IGNORE RLS accede a una relación protegida por RLS a través de una consulta entre bases de datos, aparece el siguiente error:

    RLS-protected relation "rls_protected_table" cannot be accessed via cross-database query.
  • ALTER RLS POLICY solo admite la modificación de una política de RLS mediante la cláusula USING (using_predicate_exp). No puede modificar una política de RLS con una cláusula WITH al ejecutar ALTER RLS POLICY.

  • No puede consultar las relaciones que tienen activada la seguridad en el nivel de fila 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 la seguridad de nivel de fila activada y ve el mensaje “La relación protegida por RLS 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 políticas de seguridad en el nivel de fila, 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 RLS, le recomendamos que cambie las opciones de configuración predeterminadas para los usuarios normales 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.

  • Las vistas y las vistas de enlace tardío con políticas de seguridad en el nivel de la fila y no se pueden sustituir por usuarios normales 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 sys:secadmin permission pueden utilizar CREATE VIEW en vistas o LBV con políticas de RLS sin tener que separar las políticas.

  • Las vistas con políticas de seguridad en el nivel de la fila no pueden hacer referencia a las tablas y vistas del sistema.

  • Una vista de enlace tardío a la que hace referencia una vista normal no puede estar protegida por RLS.

  • No se puede acceder a las relaciones protegidas por RLS ni a los datos anidados de los lagos de datos en la misma consulta.

PrivacidadTérminos del sitioPreferencias de cookies
© 2025, Amazon Web Services, Inc o sus afiliados. Todos los derechos reservados.