Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Seguridad de base de datos La seguridad de la base de datos se administra al controlar los usuarios que pueden obtener acceso a determinados objetos de la base de datos. A los usuarios se les pueden asignar roles o grupos, y los permisos que concede a los usuarios, roles o grupos deciden a qué objetos de la base de datos pueden acceder. **Topics** + [Información general de la seguridad de Amazon Redshift](c_security-overview.md) + [Permisos de usuario de base de datos predeterminados](r_Privileges.md) + [superuser](r_superusers.md) + [Usuarios](r_Users.md) + [Grupos](r_Groups.md) + [Schemas](r_Schemas_and_tables.md) + [Control de acceso basado en roles (RBAC)](t_Roles.md) + [Seguridad de nivel básico](t_rls.md) + [Seguridad de los metadatos](t_metadata_security.md) + [Enmascaramiento de datos dinámico](t_ddm.md) + [Permisos acotados](t_scoped-permissions.md) El acceso a los objetos de la base de datos depende de los permisos que concede a usuarios o roles. Las siguientes directrices resumen cómo funciona la seguridad de las bases de datos: + De manera predeterminada, solo se conceden permisos al propietario del objeto. + Los usuarios de base de datos de Amazon Redshift son usuarios designados que pueden conectarse a una base de datos. Un usuario recibe permisos de dos formas: explícitamente, si esos permisos se le asignan directamente a la cuenta, o implícitamente, si pertenece a un grupo que tiene permisos concedidos. + Los grupos son conjuntos de usuarios a los que se les pueden asignar privilegios de forma colectiva con objeto de agilizar el mantenimiento de la seguridad. + Los esquemas son colecciones de tablas y otros objetos de la base de datos. Los esquemas son similares a los directorios del sistema de archivos, excepto que los esquemas no se pueden anidar. Los usuarios pueden recibir acceso a un único esquema o a varios. Además, Amazon Redshift emplea las siguientes características para ofrecerle un control más preciso sobre los usuarios que tienen acceso a los objetos de la base de datos: + El control de acceso basado en roles (RBAC) le permite asignar permisos a los roles que puede aplicar a los usuarios, lo que le permite controlar los permisos en grupos de usuarios grandes. A diferencia de los grupos, los roles pueden heredar permisos de otros roles. La seguridad a nivel de fila (RLS) le permite definir políticas que restringen el acceso a las filas que elija y, después, aplicarlas a usuarios o grupos. El enmascaramiento dinámico de datos (DDM) protege aún más los datos al transformarlos en el tiempo de ejecución de la consulta para que los usuarios puedan acceder a ellos sin exponer detalles confidenciales. Para ver ejemplos de implementaciones de seguridad, consulte [Ejemplo del control de acceso de usuarios y grupos](t_user_group_examples.md). Para obtener más información acerca de la protección de los datos, consulte [Seguridad en Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html) en la *Guía de administración de Amazon Redshift*. # Información general de la seguridad de Amazon Redshift La seguridad de base de datos de Amazon Redshift es distinta a otros tipos de seguridad de Amazon Redshift. Además de la seguridad de base de datos, que se describe en esta sección, Amazon Redshift proporciona estas características para administrar la seguridad: + **Credenciales de inicio de sesión**: el acceso a la consola de administración de AWS de Amazon Redshift se controla mediante los permisos de la cuenta de AWS. Para obtener más información, consulte [Credenciales de inicio de sesión](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html). + **Administración de acceso**: para controlar el acceso a recursos de Amazon Redshift específicos, debe definir las cuentas de AWS Identity and Access Management (IAM). Para obtener más información, consulte [Control de acceso a recursos de Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html). + **Grupos de seguridad de los clústeres**: para conceder a otros usuarios acceso de entrada a un clúster de Amazon Redshift, debe definir un grupo de seguridad de clúster y asociarlo con un clúster. Para obtener más información, consulte [Grupos de seguridad de clústeres de Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-security-groups.html). + **VPC**: para proteger el acceso al clúster mediante un entorno de redes virtuales, puede lanzar el clúster en una Amazon Virtual Private Cloud (VPC). Para obtener más información, consulte [Administración de clústeres en una Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html). + **Cifrado del clúster**: para cifrar los datos de todas las tablas creadas por el usuario, puede activar el cifrado del clúster cuando lance el clúster. Para obtener más información, consulte [Clústeres de Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). + **Conexiones SSL**: para cifrar la conexión entre el cliente SQL y el clúster, puede utilizar el cifrado de capa de conexión segura (SSL). Para obtener más información, consulte [Conexión a un clúster con SSL](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html). + **Cifrado de datos de carga**: para cifrar los archivos de datos de carga de las tablas al cargarlos en Amazon S3, puede usar el cifrado del lado del servidor o el cifrado del lado del cliente. Cuando realiza cargas a partir de datos cifrados del lado del servidor, Amazon S3 se ocupa del descifrado de manera transparente. Cuando realiza cargas a partir de datos cifrados del lado del cliente, el comando COPY de Amazon Redshift descifra los datos a medida que se cargan en la tabla. Para obtener más información, consulte [Carga de datos cifrados en Amazon S3](t_uploading-encrypted-data.md). + **Datos en tránsito**: para proteger los datos en tránsito en la nube de AWS, Amazon Redshift utiliza SSL con aceleración por hardware para comunicarse con Amazon S3, o Amazon DynamoDB en las operaciones COPY, UNLOAD, de copia de seguridad y de restauración. + **Control de acceso de nivel de columna**: para tener un control de acceso de nivel de columna para los datos en Amazon Redshift, utilice instrucciones de concesión y revocación de nivel de columna sin tener que implementar un control de acceso basado en vistas ni emplear otro sistema. + **Control de seguridad de nivel de fila**: para disponer de un control de seguridad de nivel de fila para los datos en Amazon Redshift, cree y asocie políticas a roles o usuarios que restrinjan el acceso a las filas definidas en la política. # Permisos de usuario de base de datos predeterminados Cuando crea un objeto de base de datos, usted es su propietario. De manera predeterminada, solo un superusuario o el propietario de un objeto pueden consultar, modificar o conceder permisos para el objeto. Para los usuarios que utilicen un objeto, debe conceder los permisos necesarios al usuario o grupo que contenga al usuario. Los superusuarios de bases de datos tienen los mismos permisos que los propietarios de bases de datos. Amazon Redshift admite los siguientes permisos: SELECT, INSERT, UPDATE, DELETE, REFERENCES, CREATE, TEMPORARY y USAGE. Se asocian diferentes permisos a diferentes tipos de objetos. Para obtener información acerca de los permisos de objetos de base de datos admitidos por Amazon Redshift, consulte el comando [GRANT](r_GRANT.md). Solo el propietario tiene permiso para modificar o destruir un objeto. De manera predeterminada, todos los usuarios tienen privilegios CREATE y USAGE para el esquema PUBLIC de una base de datos. Para dejar de permitir a los usuarios crear objetos en el esquema PUBLIC de una base de datos, utilice el comando REVOKE para eliminar ese permiso. Para revocar un permiso que se haya concedido previamente, utilice el comando [REVOKE](r_REVOKE.md). Los permisos del propietario del objeto, tales como los permisos DROP, GRANT y REVOKE, son implícitos y no se pueden conceder ni revocar. Los propietarios de objetos pueden revocar sus propios permisos ordinarios; por ejemplo, para hacer que una tabla sea de solo lectura para ellos mismos y para otras personas. Los superusuarios conservan todos los permisos, con independencia de los comandos GRANT y REVOKE. # Superusuarios Los superusuarios de bases de datos tienen los mismos permisos que los propietarios de bases de datos para todas las bases de datos. El usuario *admin* (administrador), que es el usuario que creó cuando lanzó el clúster, es un superusuario. Debe ser un superusuario para crear un superusuario. Las tablas y vistas de sistema de Amazon Redshift están visibles solo para superusuarios o están visibles para todos los usuarios. Solo los superusuarios pueden enviar consultas a las tablas y vistas de sistema que son “visibles a los superusuarios”. Para obtener más información, consulte [Vistas de monitoreo de SYS](serverless_views-monitoring.md). Los superusuarios pueden ver todas las tablas del catálogo. Para obtener más información, consulte [Tablas de catálogos de sistema](c_intro_catalog_views.md). Un superusuario de base de datos omite todas las comprobaciones de permisos. Los superusuarios conservan todos los permisos, con independencia de los comandos GRANT y REVOKE. Tenga cuidado cuando utilice un rol de superusuario. Le recomendamos que realice la mayor parte de su trabajo con un rol que no sea el de un superusuario. Puede crear un rol de administrador con permisos más restrictivos. Para obtener más información acerca de la creación de roles, consulte [Control de acceso basado en roles (RBAC)](t_Roles.md). Para crear un nuevo superusuario de base de datos, inicie sesión en la base de datos como superusuario y emita un comando CREATE USER o ALTER USER con el permiso CREATEUSER. ``` CREATE USER adminuser CREATEUSER PASSWORD '1234Admin'; ALTER USER adminuser CREATEUSER; ``` Para crear, modificar o eliminar un superusuario, utilice los mismos comandos para administrar usuarios. Para obtener más información, consulte [Creación, modificación y eliminación de usuarios](r_Users-creatingaltering-and-deleting-users.md). # Usuarios Puede crear y administrar usuarios de bases de datos mediante los comandos SQL de Amazon Redshift CREATE USER y ALTER USER. También puede configurar el cliente SQL con controladores JDBC u ODBC de Amazon Redshift personalizados. Estos se encargan de administrar el proceso de creación de usuarios de bases de datos y contraseñas temporales como parte del proceso de inicio de sesión en las bases de datos. Los controladores autentican a los usuarios de la base de datos en función de la autenticación de AWS Identity and Access Management (IAM). Si ya administra las identidades de los usuarios fuera de AWS, puede utilizar un proveedor de identidad (IdP) conforme con SAML 2.0 para administrar el acceso a los recursos de Amazon Redshift. Puede utilizar un rol de IAM para configurar el proveedor de identidad y AWS para permitir que los usuarios federados generen credenciales de base de datos temporales e inicien sesión en bases de datos de Amazon Redshift. Para obtener más información, consulte [Uso de la autenticación de IAM para generar credenciales de usuario de base de datos](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-user-credentials.html). Solo un superusuario de base de datos puede crear y eliminar usuarios de Amazon Redshift. Los usuarios se autentican cuando inician sesión en Amazon Redshift. Pueden ser propietarios de bases de datos y de objetos de bases de datos (por ejemplo, tablas). También pueden conceder permisos para esos objetos a usuarios, grupos y esquemas para controlar quién puede acceder a cada objeto. Los usuarios con derechos CREATE DATABASE pueden crear bases de datos y conceder permisos a esas bases de datos. Los superusuarios tienen permisos de propiedad de base de datos para todas las bases de datos. # Creación, modificación y eliminación de usuarios Los usuarios de base de datos se aplican globalmente en un clúster de almacenamiento de datos (no por base de datos individual). + Para crear un usuario, utilice el comando [CREATE USER](r_CREATE_USER.md). + Para crear un superusuario, utilice el comando [CREATE USER](r_CREATE_USER.md) con la opción CREATEUSER. + Para eliminar un usuario existente, use el comando [DROP USER](r_DROP_USER.md). + Para modificar un usuario, por ejemplo, con el fin de cambiar una contraseña, utilice el comando [ALTER USER](r_ALTER_USER.md). + Para ver una lista de usuarios, realice una consulta de la tabla de catálogo PG\$1USER. ``` select * from pg_user; usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig ------------+----------+-------------+----------+-----------+----------+----------+----------- rdsdb | 1 | t | t | t | ******** | | masteruser | 100 | t | t | f | ******** | | dwuser | 101 | f | f | f | ******** | | simpleuser | 102 | f | f | f | ******** | | poweruser | 103 | f | t | f | ******** | | dbuser | 104 | t | f | f | ******** | | (6 rows) ``` # Grupos Los grupos son conjuntos de usuarios que han recibido todos ellos los permisos correspondientes asociados al grupo. Puede utilizar grupos para asignar permisos. Por ejemplo, puede crear diferentes grupos para ventas, administración y asistencia, y concederles a los usuarios de cada grupo el acceso adecuado a los datos que necesitan para su trabajo. Puede conceder o revocar permisos en el nivel del grupo, y esos cambios se aplicarán a todos los miembros del grupo, excepto a los superusuarios. Consulte la tabla de catálogo del sistema PG\$1GROUP para ver una lista de todos los grupos de usuarios: ``` select * from pg_group; ``` Por ejemplo, para mostrar todos los usuarios de bases de datos por grupo, ejecute el siguiente SQL. ``` SELECT u.usesysid ,g.groname ,u.usename FROM pg_user u LEFT JOIN pg_group g ON u.usesysid = ANY (g.grolist) ``` # Creación, modificación y eliminación de grupos Solo un superusuario puede crear, modificar o eliminar grupos. Puede llevar a cabo las siguientes acciones: + Para crear un grupo, use el comando [CREATE GROUP](r_CREATE_GROUP.md). + Para agregar o eliminar usuarios de un grupo existente, use el comando [ALTER GROUP](r_ALTER_GROUP.md). + Para eliminar un grupo, use el comando [DROP GROUP](r_DROP_GROUP.md). Este comando solo elimina el grupo, no los usuarios miembros. # Ejemplo del control de acceso de usuarios y grupos Este ejemplo crea grupos y usuarios y, a continuación, les concede diversos permisos para una base de datos de Amazon Redshift que se conecta a un cliente de aplicación web. Este ejemplo supone tres grupos de usuarios: usuarios normales de una aplicación web, usuarios avanzados de una aplicación web y desarrolladores web. Para obtener información sobre cómo eliminar a un usuario de un grupo, consulte [ALTER GROUP](r_ALTER_GROUP.md). 1. Cree los grupos donde se asignarán los usuarios. El siguiente conjunto de comandos crea tres grupos de usuarios diferentes: ``` create group webappusers; create group webpowerusers; create group webdevusers; ``` 1. Cree varios usuarios de base de datos con diferentes permisos y agréguelos a los grupos. 1. Cree dos usuarios y agréguelos al grupo WEBAPPUSERS: ``` create user webappuser1 password 'webAppuser1pass' in group webappusers; create user webappuser2 password 'webAppuser2pass' in group webappusers; ``` 1. Cree un usuario desarrollador web y agréguelo al grupo WEBDEVUSERS: ``` create user webdevuser1 password 'webDevuser2pass' in group webdevusers; ``` 1. Cree un superusuario. Este usuario tendrá derechos administrativos para crear otros usuarios: ``` create user webappadmin password 'webAppadminpass1' createuser; ``` 1. Cree un esquema para asociarlo con las tablas de la base de datos que la aplicación web utiliza y conceda a diferentes grupos de usuarios acceso al siguiente esquema: 1. Cree el esquema WEBAPP: ``` create schema webapp; ``` 1. Conceda permisos USAGE al grupo WEBAPPUSERS: ``` grant usage on schema webapp to group webappusers; ``` 1. Conceda permisos USAGE al grupo WEBPOWERUSERS: ``` grant usage on schema webapp to group webpowerusers; ``` 1. Conceda permisos ALL al grupo WEBDEVUSERS: ``` grant all on schema webapp to group webdevusers; ``` Los usuarios y grupos básicos ya están configurados. Ahora puede modificar usuarios y grupos. 1. Por ejemplo, el siguiente comando modifica el parámetro search\$1path de WEBAPPUSER1. ``` alter user webappuser1 set search_path to webapp, public; ``` El comando SEARCH\$1PATH especifica el orden de búsqueda de esquemas para objetos de base de datos, como tablas y funciones, cuando un nombre simple que no tiene un esquema especificado hace referencia al objeto. 1. También puede agregar usuarios a un grupo después de crearlo; por ejemplo, agregar WEBAPPUSER2 al grupo WEBPOWERUSERS: ``` alter group webpowerusers add user webappuser2; ``` # Schemas Una base de datos contiene uno o más esquemas con nombre. Cada esquema de una base de datos contiene tablas u otros tipos de objetos con nombre. De manera predeterminada, una base de datos tiene un único esquema, que se denomina PUBLIC. Puede usar esquemas para agrupar objetos de la base de datos bajo un nombre común. Los esquemas son similares a los directorios del sistema de archivos, excepto que los esquemas no se pueden anidar. Se pueden usar nombres de objetos de base de datos idénticos en diferentes esquemas de la misma base de datos sin generar conflictos. Por ejemplo, MY\$1SCHEMA y YOUR\$1SCHEMA pueden contener una tabla denominada MYTABLE. Los usuarios con los permisos necesarios pueden acceder a objetos de varios esquemas de una base de datos. De manera predeterminada, se crea un objeto dentro del primer esquema en la ruta de búsqueda de la base de datos. Para obtener más información, consulte [Ruta de búsqueda](#c_Search_path) más adelante en esta sección. Los esquemas pueden ser de ayuda en los problemas de organización y simultaneidad en un entorno multiusuario de las siguientes maneras: + Para permitir que varios desarrolladores trabajen en la misma base de datos sin interferirse. + Organizan objetos de base de datos en grupos lógicos para poder administrarlos más fácilmente. + Les otorgan a las aplicaciones la capacidad de colocar sus objetos en esquemas separados para que sus nombres no colisionen con los nombres de los objetos utilizados por otras aplicaciones. ## Ruta de búsqueda La ruta de búsqueda se define en el parámetro search\$1path con una lista de nombres de esquemas separados por comas. La ruta de búsqueda especifica el orden en el que se buscan los esquemas cuando un nombre simple que no incluye un calificador de esquema hace referencia a un objeto, como una tabla o función. Si se crea un objeto sin especificar un esquema de destino, el objeto se agrega al primer esquema que aparece en la ruta de búsqueda. Cuando hay objetos con nombres idénticos en diferentes esquemas, un nombre de objeto que no especifica un esquema hará referencia al primer esquema de la ruta de búsqueda que contenga un objeto con ese nombre. Para cambiar el esquema predeterminado para la sesión actual, use el comando [SET](r_SET.md). Para obtener más información, consulte la descripción de [search\$1path](r_search_path.md) en la Referencia de configuración. # Creación, modificación y eliminación de esquemas Cualquier usuario puede crear o eliminar esquemas de los cuales es propietario. Puede llevar a cabo las siguientes acciones: + Para crear un esquema, use el comando [CREATE SCHEMA](r_CREATE_SCHEMA.md). + Para cambiar el propietario de un esquema, use el comando [ALTER SCHEMA](r_ALTER_SCHEMA.md). + Para eliminar un esquema y sus objetos, use el comando [DROP SCHEMA](r_DROP_SCHEMA.md). + Para crear una tabla dentro de un esquema, cree la tabla con el formato *nombre\$1de\$1esquema.nombre\$1de\$1tabla*. Consulte la tabla de catálogo del sistema PG\$1NAMESPACE para ver una lista de todos los esquemas: ``` select * from pg_namespace; ``` Consulte la tabla de catálogo del sistema PG\$1TABLE\$1DEF para ver una lista de las tablas que pertenecen a un esquema. Por ejemplo, la siguiente consulta devuelve una lista de tablas del esquema PG\$1CATALOG. ``` select distinct(tablename) from pg_table_def where schemaname = 'pg_catalog'; ``` # Permisos basados en esquemas Los permisos basados en esquemas son determinados por el propietario del esquema: + De manera predeterminada, todos los usuarios tienen privilegios CREATE y USAGE para el esquema PUBLIC de una base de datos. Para dejar de permitir a los usuarios crear objetos en el esquema PUBLIC de una base de datos, utilice el comando [REVOKE](r_REVOKE.md) con objeto de eliminar ese permiso. + A menos que el propietario del objeto les conceda el permiso USAGE, los usuarios no pueden acceder a ninguno de los objetos de los esquemas de los que no son propietarios. + Si los usuarios han recibido el permiso CREATE para un esquema que ha creado otro usuario, esos usuarios pueden crear objetos en ese esquema. # Control de acceso basado en roles (RBAC) Utilizando el control de acceso basado en roles (RBAC) para administrar los permisos de base de datos en Amazon Redshift, puede simplificar la administración de los permisos de seguridad en Amazon Redshift. Puede proteger el acceso a información confidencial controlando lo que los usuarios pueden hacer tanto en un nivel general como detallado. También puede controlar el acceso de los usuarios a tareas que normalmente solo se permiten a los superusuarios. Asignando permisos diferentes a roles diferentes y asignándolos a usuarios diferentes, puede tener un control más detallado del acceso de los usuarios. Los usuarios con un rol asignado solo pueden realizar las tareas que estén especificadas por el rol asignado para el que tengan autorización. Por ejemplo, un usuario con el rol asignado que tenga los permisos CREATE TABLE y DROP TABLE solo tiene autorización para realizar esas tareas. Puede controlar el acceso de los usuarios concediendo diferentes niveles de permisos de seguridad a usuarios diferentes para que accedan a los datos que necesitan para su trabajo. RBAC aplica el principio de permisos mínimos a los usuarios en función de sus requisitos de rol, con independencia de los tipos de objetos involucrados. La concesión y revocación de permisos se realiza en el nivel del rol, sin necesidad de actualizar los permisos en objetos de base de datos individuales. Con RBAC, puede crear roles con permisos para ejecutar comandos que antes necesitaban permisos de superusuario. Los usuarios pueden ejecutar estos comandos, siempre que hayan recibido autorización con un rol que incluya tales permisos. De manera similar, también puede crear roles para limitar el acceso a determinados comandos y asignar el rol a superusuarios o usuarios que hayan recibido autorización con ese rol. Para obtener información sobre cómo funciona Amazon Redshift RBAC, vea el siguiente video. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/IhHQ7mZ-tp4/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IhHQ7mZ-tp4) # Jerarquía de roles Los *roles* son conjuntos de permisos que se pueden asignar a un usuario o a otro rol. Puede asignar permisos del sistema o de base de datos a un rol. Un usuario hereda los permisos de un rol asignado. En RBAC, los usuarios pueden tener roles anidados. Puede conceder roles tanto a usuarios como a roles. Cuando se concede un rol a un usuario, se autoriza a ese usuario con todos los permisos que incluya este rol. Cuando se concede un rol r1 a un usuario, se autoriza a ese usuario con los permisos de r1. El usuario ahora tiene los permisos de r1, así como cualquier otro permiso que ya tuviera. Cuando se concede un rol (r1) a otro rol (r2), se autoriza a r2 con todos los permisos de r1. Además, cuando se concede r2 a otro rol (r3), los permisos de r3 son la combinación de los permisos de r1 y r2. La jerarquía de roles hace que r2 herede los permisos de r1. Amazon Redshift propaga los permisos con cada autorización de rol. Cuando se concede r1 a r2, y después r2 a r3, se autoriza a r3 con todos los permisos de los tres roles. Por lo tanto, si se concede r3 a un usuario, ese usuario tiene todos los permisos de los tres roles. Amazon Redshift no permite crear un ciclo de autorización de roles. Un ciclo de autorización de roles ocurre cuando se asigna un rol anidado a un rol anterior en la jerarquía de roles; por ejemplo, asignar r3 a r1. Para obtener más información sobre cómo crear roles y administrar la asignación de roles, consulte [Administración de roles en RBAC](r_roles-managing.md). # Asignación de roles Los superusuarios y los usuarios normales con los permisos CREATE ROLE pueden utilizar la instrucción CREATE ROLE para crear roles. Los superusuarios y los administradores de roles pueden utilizar la instrucción GRANT ROLE para conceder un rol a otros usuarios. Pueden utilizar la instrucción REVOKE ROLE para revocar un rol a otros usuarios, y la instrucción DROP ROLE para eliminar roles. Los administradores de roles incluyen a los propietarios de roles y a los usuarios a los que se les ha concedido el rol con el permiso ADMIN OPTION. Únicamente los superusuarios o administradores de roles pueden conceder y revocar roles. Se pueden conceder o revocar uno o varios roles a uno o varios roles o usuarios. Utilice la opción WITH ADMIN OPTION de la instrucción GRANT ROLE para proporcionar las opciones de administración de todos los roles concedidos a todos los concesionarios. Amazon Redshift admite diferentes combinaciones de asignaciones de roles, como conceder varios roles o tener varios concesionarios. WITH ADMIN OPTION solo se aplica a los usuarios, no a los roles. De manera similar, utilice la opción WITH ADMIN OPTION en la instrucción REVOKE ROLE para eliminar el rol y la autorización administrativa del concesionario. Cuando se utiliza con ADMIN OPTION, solo se revoca la autorización administrativa al rol. En el siguiente ejemplo, se revoca la autorización administrativa del rol `sample_role2` a `user2`. ``` REVOKE ADMIN OPTION FOR sample_role2 FROM user2; ``` Para obtener más información sobre cómo crear roles y administrar la asignación de roles, consulte [Administración de roles en RBAC](r_roles-managing.md). # Roles definidos por el sistema de Amazon Redshift Amazon Redshift proporciona algunos roles definidos por el sistema que se definen con permisos específicos. Los roles específicos del sistema van precedidos del prefijo `sys:`. Únicamente los usuarios con acceso adecuado pueden modificar los roles definidos por el sistema o crear roles definidos por el sistema personalizados. No se puede utilizar el prefijo `sys:` para un rol definido por el sistema personalizado. La tabla siguiente resume los roles y sus permisos. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/r_roles-default.html) ## Roles y usuarios definidos por el sistema para el intercambio de datos Amazon Redshift crea roles y usuarios para uso interno que corresponden a los recursos compartidos de datos y a sus consumidores. Cada nombre de rol y nombre de usuario internos tienen el prefijo de espacio de nombres reservado `ds:`. Tienen el siguiente formato: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/r_roles-default.html) Se crea un rol de intercambio de datos para cada recurso compartido de datos. Contiene todos los permisos concedidos actualmente al recurso compartido de datos. Se crea un usuario de intercambio de datos para cada consumidor de un recurso compartido de datos. Se le concede permiso para un único rol de intercambio de datos. Un consumidor agregado a varios conjuntos de datos tendrá un usuario de intercambio de datos creado para cada recurso compartido de datos. Estos usuarios y roles son necesarios para que el intercambio de datos funcione correctamente. No se pueden modificar ni eliminar, y no se puede acceder a ellos ni utilizarlos para ninguna tarea que realicen los clientes. Puede ignorarlos de forma segura. Para obtener más información sobre el uso compartido de datos, consulte [Compartir datos entre clústeres en Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html). **nota** No puede usar el prefijo `ds:` para crear roles o usuarios definidos por el usuario. # Permisos del sistema para RBAC A continuación se presenta una lista de permisos del sistema que puede conceder o revocar a un rol. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/r_roles-system-privileges.html) # Permisos de objetos de bases de datos Además de permisos del sistema, Amazon Redshift incluye permisos de objetos de base de datos que definen las opciones de acceso. Entre esas opciones se incluyen la capacidad de leer datos en tablas y vistas, escribir datos, crear tablas y eliminar tablas. Para obtener más información, consulte [GRANT](r_GRANT.md). Mediante RBAC, se pueden asignar permisos de objetos de base de datos a roles, de manera similar a como se puede hacer con los permisos del sistema. Después, se pueden asignar roles a los usuarios, autorizar a los usuarios con permisos del sistema, y autorizar a los usuarios con permisos de base de datos. # ALTER DEFAULT PRIVILEGES para RBAC Utilice la instrucción ALTER DEFAULT PRIVILEGES para definir el conjunto predeterminado de permisos de acceso que se deben aplicar a los objetos que el usuario especificado cree en el futuro. De manera predeterminada, los usuarios pueden cambiar solo sus propios permisos de acceso predeterminados. Con RBAC, se pueden establecer los permisos de acceso predeterminados para los roles. Para obtener más información, consulte el comando [ALTER DEFAULT PRIVILEGES](r_ALTER_DEFAULT_PRIVILEGES.md). RBAC permite asignar permisos de objetos de base de datos a los roles, de manera similar a los permisos del sistema. Después, se pueden asignar roles a los usuarios, y autorizar a los usuarios con permisos del sistema o de base de datos. # Consideraciones sobre el uso de roles en RBAC Cuando trabaje con roles de RBAC, tenga presente lo siguiente: + Amazon Redshift no permite ciclos de autorizaciones de roles. No se puede conceder r1 a r2 y luego conceder r2 a r1. + RBAC funciona tanto para objetos nativos de Amazon Redshift como para tablas de Amazon Redshift Spectrum. + Como administrador de Amazon Redshift, puede activar RBAC actualizando el clúster al último parche de mantenimiento para comenzar. + Únicamente los superusuarios y los usuarios con el permiso del sistema CREATE ROLE pueden crear roles. + Únicamente los superusuarios y administradores de roles pueden modificar o eliminar roles. + El nombre de un rol no puede ser el mismo que el nombre de un usuario. + El nombre de un rol no puede contener caracteres no válidos, como “:/\$1n.”. + El nombre de un rol no puede ser una palabra reservada, como PUBLIC. + El nombre del rol no puede comenzar con el prefijo reservado para los roles predeterminados, `sys:`. + No se puede eliminar un rol que tenga el parámetro RESTRICT cuando está concedido a otro rol. La configuración predeterminada es RESTRICT. Amazon Redshift genera un error cuando se intenta eliminar un rol que ha heredado otro rol. + Los usuarios que no tengan permisos de administración para un rol no pueden conceder ni revocar un rol. + RBAC no es totalmente compatible con tablas y vistas del sistema. Los permisos de RBAC para las tablas y vistas del sistema no se conservan durante las actualizaciones, las degradaciones o los cambios de tamaño. Recomendamos utilizar [Roles definidos por el sistema de Amazon RedshiftRoles y usuarios definidos por el sistema para el intercambio de datos](r_roles-default.md) para administrar los permisos de tablas y vistas del sistema. Para obtener más información sobre las tablas del sistema, vaya a [Referencia de las tablas y vistas de sistema](cm_chap_system-tables.md). # Administración de roles en RBAC Para realizar las siguientes acciones, utilice estos comandos: + Para crear un rol, utilice el comando [CREATE ROLE](r_CREATE_ROLE.md). + Para cambiar el nombre de un rol o el propietario del rol, utilice el comando [ALTER ROLE](r_ALTER_ROLE.md). + Para eliminar un rol, utilice el comando [DROP ROLE](r_DROP_ROLE.md). + Para conceder un rol a un usuario, utilice el comando [GRANT](r_GRANT.md). + Para revocar un rol a un usuario, utilice el comando [REVOKE](r_REVOKE.md). + Para conceder permisos del sistema a un rol, utilice el comando [GRANT](r_GRANT.md). + Para revocar permisos del sistema a un rol, utilice el comando [REVOKE](r_REVOKE.md). Para ver una lista de los roles de su clúster o grupo de trabajo, consulte [SVV\$1ROLES](r_SVV_ROLES.md). # Tutorial: creación de roles y realización de consultas con RBAC Con RBAC, puede crear roles con permisos para ejecutar comandos que antes necesitaban permisos de superusuario. Los usuarios pueden ejecutar estos comandos, siempre que hayan recibido autorización con un rol que incluya tales permisos. En este tutorial, utilizará el control de acceso basado en roles (RBAC) para administrar los permisos en una base de datos que ha creado. A continuación, se conectará a la base de datos y la consultará desde dos roles diferentes para probar la funcionalidad de RBAC. Los dos roles que se crean y utilizan para consultar la base de datos son `sales_ro` y `sales_rw`. Cree el rol `sales_ro` y consulte los datos como usuario con el rol `sales_ro`. El usuario `sales_ro` solo puede usar el comando SELECT y no puede usar el comando UPDATE. A continuación, cree el rol `sales_rw` y consulte los datos como usuario con el rol `sales_rw`. El usuario `sales_rw` puede usar el comando SELECT y el comando UPDATE. Además, puede crear roles para limitar el acceso a determinados comandos y asignar el rol a superusuarios o a usuarios. **Tareas** + [Requisitos previos](#tutorial-rbac-prereqs) + [Paso 1: cree un usuario administrador](#tutorial-rbac-step1) + [Paso 2: configure los esquemas](#tutorial-rbac-step2) + [Paso 3: cree un usuario de solo lectura.](#tutorial-rbac-step3) + [Paso 4: consulte los datos como usuario de solo lectura](#tutorial-rbac-step4) + [Paso 5: cree un usuario de solo escritura](#tutorial-rbac-step5) + [Paso 6: consulte los datos como el usuario con el rol heredado de solo lectura](#tutorial-rbac-step6) + [Paso 7: conceda permisos de actualización e inserción al rol de lectura/escritura](#tutorial-rbac-step7) + [Paso 8: consulte los datos como usuario de lectura/escritura](#tutorial-rbac-step8) + [Paso 9: analice y vacíe las tablas de una base de datos como usuario administrador](#tutorial-rbac-step9) + [Paso 10: trunque las tablas como usuario de lectura/escritura](#tutorial-rbac-step10) + [Funciones del sistema para RBAC (opcional)](#tutorial-rbac-system-functions) + [Vistas del sistema para RBAC (opcional)](#tutorial-rbac-system-views) + [Uso de seguridad a nivel de fila con RBAC (opcional)](#tutorial-rbac-rls) ## Requisitos previos + Cree un clúster de Amazon Redshift o un grupo de trabajo sin servidor que se cargue con la base de datos de ejemplo TICKIT. Para crear un grupo de trabajo sin servidor, consulte [Introducción a los almacenamientos de datos de Redshift sin servidor](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html). Para crear un clúster, consulte [Crear un clúster de Amazon Redshift de muestra](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-launch-sample-cluster.html). Para obtener más información acerca de la base de datos de ejemplo TICKIT, consulte [Base de datos de muestra](c_sampledb.md). + Tenga acceso a un usuario con permisos de superusuario o administrador de roles. Únicamente los superusuarios o administradores de roles pueden conceder o revocar roles. Para obtener más información acerca de los permisos requeridos para RBAC, consulte [Permisos del sistema para RBAC](r_roles-system-privileges.md). + Consulte el [Consideraciones sobre el uso de roles en RBAC](r_role-usage-notes.md). ## Paso 1: cree un usuario administrador Para prepararse para este tutorial, cree un rol de administrador de base de datos y asígnelo a un usuario administrador de bases de datos en este paso. Debe crear el administrador de la base de datos como superusuario o administrador de roles. Ejecute todas las consultas en el [editor de consultas v2 de Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html). 1. Para crear el rol de administrador db\$1admin, utilice el siguiente ejemplo. ``` CREATE ROLE db_admin; ``` 1. Para crear un usuario de base de datos llamado dbadmin, utilice el siguiente ejemplo. ``` CREATE USER dbadmin PASSWORD 'Test12345'; ``` 1. Para conceder el rol definido por el sistema denominado sys:dba al rol db\$1admin, utilice el siguiente ejemplo. Cuando se le concede el rol sys:dba, el usuario dbadmin puede crear esquemas y tablas. Para obtener más información, consulte [Roles definidos por el sistema de Amazon RedshiftRoles y usuarios definidos por el sistema para el intercambio de datos](r_roles-default.md). ## Paso 2: configure los esquemas En este paso, se conecta a la base de datos como administrador de bases de datos. A continuación, cree dos esquemas y agregue datos en ellos. 1. Conéctese a la base de datos dev como usuario dbadmin utilizando el editor de consultas v2. Para obtener más información sobre la conexión a una base de datos, consulte [Trabajo con el editor de consultas v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html). 1. Para crear los esquemas de las bases de datos de ventas y marketing, utilice el siguiente ejemplo. ``` CREATE SCHEMA sales; CREATE SCHEMA marketing; ``` 1. Para crear e insertar valores en las tablas del esquema de ventas, utilice el siguiente ejemplo. ``` CREATE TABLE sales.cat( catid smallint, catgroup varchar(10), catname varchar(10), catdesc varchar(50) ); INSERT INTO sales.cat(SELECT * FROM category); CREATE TABLE sales.dates( dateid smallint, caldate date, day char(3), week smallint, month char(5), qtr char(5), year smallint, holiday boolean ); INSERT INTO sales.dates(SELECT * FROM date); CREATE TABLE sales.events( eventid integer, venueid smallint, catid smallint, dateid smallint, eventname varchar(200), starttime timestamp ); INSERT INTO sales.events(SELECT * FROM event); CREATE TABLE sales.sale( salesid integer, listid integer, sellerid integer, buyerid integer, eventid integer, dateid smallint, qtysold smallint, pricepaid decimal(8,2), commission decimal(8,2), saletime timestamp ); INSERT INTO sales.sale(SELECT * FROM sales); ``` 1. Para crear e insertar valores en las tablas del esquema de marketing, utilice el siguiente ejemplo. ``` CREATE TABLE marketing.cat( catid smallint, catgroup varchar(10), catname varchar(10), catdesc varchar(50) ); INSERT INTO marketing.cat(SELECT * FROM category); CREATE TABLE marketing.dates( dateid smallint, caldate date, day char(3), week smallint, month char(5), qtr char(5), year smallint, holiday boolean ); INSERT INTO marketing.dates(SELECT * FROM date); CREATE TABLE marketing.events( eventid integer, venueid smallint, catid smallint, dateid smallint, eventname varchar(200), starttime timestamp ); INSERT INTO marketing.events(SELECT * FROM event); CREATE TABLE marketing.sale( marketingid integer, listid integer, sellerid integer, buyerid integer, eventid integer, dateid smallint, qtysold smallint, pricepaid decimal(8,2), commission decimal(8,2), saletime timestamp ); INSERT INTO marketing.sale(SELECT * FROM marketing); ``` ## Paso 3: cree un usuario de solo lectura. En este paso, creará un rol de solo lectura y un usuario salesanalyst para el rol de solo lectura. El analista de ventas solo necesita acceso de solo lectura a las tablas del esquema de ventas para llevar a cabo la tarea que se le ha asignado de encontrar los eventos que generaron las mayores comisiones. 1. Conéctese a la base de datos como usuario dbadmin. 1. Para crear el rol sales\$1ro, utilice el siguiente ejemplo. ``` CREATE ROLE sales_ro; ``` 1. Para crear el usuario salesanalyst, utilice el siguiente ejemplo. ``` CREATE USER salesanalyst PASSWORD 'Test12345'; ``` 1. Para conceder el uso del rol sales\$1ro y seleccionar el acceso a los objetos del esquema de ventas, utilice el siguiente ejemplo. ``` GRANT USAGE ON SCHEMA sales TO ROLE sales_ro; GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_ro; ``` 1. Para conceder al usuario salesanalyst el rol sales\$1ro, utilice el siguiente ejemplo. ``` GRANT ROLE sales_ro TO salesanalyst; ``` ## Paso 4: consulte los datos como usuario de solo lectura En este paso, el usuario salesanalyst consulta los datos del esquema de ventas. A continuación, el usuario salesanalyst intenta actualizar una tabla y leer las tablas del esquema de marketing. 1. Conéctese a la base de datos como usuario salesanalyst. 1. Para encontrar las diez ventas con las comisiones más altas, utilice el siguiente ejemplo. ``` SET SEARCH_PATH TO sales; SELECT DISTINCT events.dateid, sale.commission, cat.catname FROM sale, events, dates, cat WHERE events.dateid=dates.dateid AND events.dateid=sale.dateid AND events.catid = cat.catid ORDER BY 2 DESC LIMIT 10; +--------+------------+----------+ | dateid | commission | catname | +--------+------------+----------+ | 1880 | 1893.6 | Pop | | 1880 | 1893.6 | Opera | | 1880 | 1893.6 | Plays | | 1880 | 1893.6 | Musicals | | 1861 | 1500 | Plays | | 2003 | 1500 | Pop | | 1861 | 1500 | Opera | | 2003 | 1500 | Plays | | 1861 | 1500 | Musicals | | 1861 | 1500 | Pop | +--------+------------+----------+ ``` 1. Para seleccionar diez eventos de la tabla de eventos del esquema de ventas, utilice el siguiente ejemplo. ``` SELECT * FROM sales.events LIMIT 10; +---------+---------+-------+--------+--------------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+--------------------+---------------------+ | 4836 | 73 | 9 | 1871 | Soulfest | 2008-02-14 19:30:00 | | 5739 | 41 | 9 | 1871 | Fab Faux | 2008-02-14 19:30:00 | | 627 | 229 | 6 | 1872 | High Society | 2008-02-15 14:00:00 | | 2563 | 246 | 7 | 1872 | Hamlet | 2008-02-15 20:00:00 | | 7703 | 78 | 9 | 1872 | Feist | 2008-02-15 14:00:00 | | 7903 | 90 | 9 | 1872 | Little Big Town | 2008-02-15 19:30:00 | | 7925 | 101 | 9 | 1872 | Spoon | 2008-02-15 19:00:00 | | 8113 | 17 | 9 | 1872 | Santana | 2008-02-15 15:00:00 | | 463 | 303 | 8 | 1873 | Tristan und Isolde | 2008-02-16 19:00:00 | | 613 | 236 | 6 | 1873 | Pal Joey | 2008-02-16 15:00:00 | +---------+---------+-------+--------+--------------------+---------------------+ ``` 1. Para intentar actualizar el nombre del evento para el eventid 1, ejecute el siguiente ejemplo. Este ejemplo generará un error de permiso denegado porque el usuario salesanalyst solo tiene permisos SELECT en la tabla de eventos del esquema de ventas. Para actualizar la tabla de eventos, debe conceder al rol sales\$1ro permisos UPDATE. Para obtener más información sobre la concesión de permisos para actualizar una tabla, consulte el parámetro UPDATE para [GRANT](r_GRANT.md). Para obtener más información sobre el comando UPDATE, consulte [UPDATE](r_UPDATE.md). ``` UPDATE sales.events SET eventname = 'Comment event' WHERE eventid = 1; ERROR: permission denied for relation events ``` 1. Para intentar seleccionarlos todos en la tabla de eventos del esquema de marketing, use el siguiente ejemplo. Este ejemplo generará un error de permiso denegado porque el usuario salesanalyst solo tiene permisos SELECT en la tabla de eventos del esquema de ventas. Para seleccionar datos de la tabla de eventos del esquema de marketing, debe conceder al rol sales\$1ro permisos SELECT en la tabla de eventos del esquema de marketing. ``` SELECT * FROM marketing.events; ERROR: permission denied for schema marketing ``` ## Paso 5: cree un usuario de solo escritura En este paso, el ingeniero de ventas responsable de crear la canalización de extracción, transformación y carga (ETL) para el procesamiento de datos en el esquema de ventas tendrá acceso de solo lectura, pero más adelante se le dará acceso de lectura y escritura para realizar sus tareas. 1. Conéctese a la base de datos como usuario dbadmin. 1. Para crear el rol sales\$1rw en el esquema de ventas, utilice el siguiente ejemplo. ``` CREATE ROLE sales_rw; ``` 1. Para crear el usuario salesengineer, utilice el siguiente ejemplo. ``` CREATE USER salesengineer PASSWORD 'Test12345'; ``` 1. Para conceder al rol sales\$1rw acceso de uso y selección de los objetos del esquema de ventas asignándole el rol sales\$1ro, utilice el siguiente ejemplo. Para obtener más información sobre cómo los roles heredan los permisos en Amazon Redshift, consulte [Jerarquía de roles](t_role_hierarchy.md). ``` GRANT ROLE sales_ro TO ROLE sales_rw; ``` 1. Para asignar el rol sales\$1rw al usuario salesengineer, utilice el siguiente ejemplo. ``` GRANT ROLE sales_rw TO salesengineer; ``` ## Paso 6: consulte los datos como el usuario con el rol heredado de solo lectura En este paso, el usuario salesengineer intenta actualizar la tabla de eventos antes de que se le concedan los permisos de lectura. 1. Conéctese a la base de datos como usuario salesengineer. 1. El usuario salesengineer puede leer correctamente los datos de la tabla de eventos del esquema de ventas. Para seleccionar el evento con eventid 1 de la tabla de eventos del esquema de ventas, utilice el siguiente ejemplo. ``` SELECT * FROM sales.events where eventid=1; +---------+---------+-------+--------+-----------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+-----------------+---------------------+ | 1 | 305 | 8 | 1851 | Gotterdammerung | 2008-01-25 14:30:00 | +---------+---------+-------+--------+-----------------+---------------------+ ``` 1. Para intentar seleccionarlos todos en la tabla de eventos del esquema de marketing, use el siguiente ejemplo. El usuario salesengineer no tiene permisos para las tablas del esquema de marketing, por lo que esta consulta generará un error de permiso denegado. Para seleccionar datos de la tabla de eventos del esquema de marketing, debe conceder al rol sales\$1rw permisos SELECT en la tabla de eventos del esquema de marketing. ``` SELECT * FROM marketing.events; ERROR: permission denied for schema marketing ``` 1. Para intentar actualizar el nombre del evento para el eventid 1, ejecute el siguiente ejemplo. Este ejemplo generará un error de permiso denegado porque el usuario salesengineer solo tiene permisos de selección en la tabla de eventos del esquema de ventas. Para actualizar la tabla de eventos, debe conceder al rol sales\$1rw permisos UPDATE. ``` UPDATE sales.events SET eventname = 'Comment event' WHERE eventid = 1; ERROR: permission denied for relation events ``` ## Paso 7: conceda permisos de actualización e inserción al rol de lectura/escritura En este paso, se conceden permisos de actualización e inserción al rol sales\$1rw. 1. Conéctese a la base de datos como usuario dbadmin. 1. Para conceder los permisos UPDATE, INSERT y DELETE al rol sales\$1rw, utilice el siguiente ejemplo. ``` GRANT UPDATE, INSERT, ON ALL TABLES IN SCHEMA sales TO role sales_rw; ``` ## Paso 8: consulte los datos como usuario de lectura/escritura En este paso, salesengineer actualiza correctamente la tabla después de que a su rol se le concedan los permisos de inserción y actualización. A continuación, salesengineer intenta analizar y vaciar la tabla de eventos, pero no lo consigue. 1. Conéctese a la base de datos como usuario salesengineer. 1. Para actualizar el nombre del evento para el eventid 1, ejecute el siguiente ejemplo. ``` UPDATE sales.events SET eventname = 'Comment event' WHERE eventid = 1; ``` 1. Para ver el cambio realizado en la consulta anterior, utilice el siguiente ejemplo para seleccionar el evento con eventid 1 en la tabla de eventos del esquema de ventas. ``` SELECT * FROM sales.events WHERE eventid=1; +---------+---------+-------+--------+---------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+---------------+---------------------+ | 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 | +---------+---------+-------+--------+---------------+---------------------+ ``` 1. Para analizar la tabla de eventos actualizada en el esquema de ventas, utilice el siguiente ejemplo. Este ejemplo generará un error de permiso denegado porque el usuario salesengineer no tiene los permisos necesarios y no es el propietario de la tabla de eventos del esquema de ventas. Para analizar la tabla de eventos, debe conceder al rol sales\$1rw permisos ANALYZE mediante el comando GRANT. Para obtener más información acerca del comando ANALYZE, consulte [ANALYZE](r_ANALYZE.md). ``` ANALYZE sales.events; ERROR: skipping "events" --- only table or database owner can analyze ``` 1. Para vaciar la tabla de eventos actualizada, utilice el siguiente ejemplo. Este ejemplo generará un error de permiso denegado porque el usuario salesengineer no tiene los permisos necesarios y no es el propietario de la tabla de eventos del esquema de ventas. Para vaciar la tabla de eventos, debe conceder permisos VACUUM al rol sales\$1rw mediante el comando GRANT. Para obtener más información acerca del comando VACUUM, consulte [VACUUM](r_VACUUM_command.md). ``` VACUUM sales.events; ERROR: skipping "events" --- only table or database owner can vacuum it ``` ## Paso 9: analice y vacíe las tablas de una base de datos como usuario administrador En este paso, el usuario dbadmin analiza y vacía todas las tablas. El usuario tiene permisos de administrador en esta base de datos, por lo que puede ejecutar estos comandos. 1. Conéctese a la base de datos como usuario dbadmin. 1. Para analizar la tabla de eventos en el esquema de ventas, utilice el siguiente ejemplo. ``` ANALYZE sales.events; ``` 1. Para vaciar la tabla de eventos en el esquema de ventas, utilice el siguiente ejemplo. ``` VACUUM sales.events; ``` 1. Para analizar la tabla de eventos en el esquema de marketing, utilice el siguiente ejemplo. ``` ANALYZE marketing.events; ``` 1. Para vaciar la tabla de eventos en el esquema de marketing, utilice el siguiente ejemplo. ``` VACUUM marketing.events; ``` ## Paso 10: trunque las tablas como usuario de lectura/escritura En este paso, el usuario salesengineer intenta truncar la tabla de eventos en el esquema de ventas, pero solo lo consigue cuando el usuario dbadmin le concede los permisos de truncamiento. 1. Conéctese a la base de datos como usuario salesengineer. 1. Para intentar eliminar todas las filas de la tabla de eventos del esquema de ventas, utilice el siguiente ejemplo. Este ejemplo generará un error porque el usuario salesengineer no tiene los permisos necesarios y no es el propietario de la tabla de eventos del esquema de ventas. Para truncar la tabla de eventos, debe conceder al rol sales\$1rw permisos TRUNCATE mediante el comando GRANT. Para obtener más información sobre el comando TRUNCATE, consulte [TRUNCATE](r_TRUNCATE.md). ``` TRUNCATE sales.events; ERROR: must be owner of relation events ``` 1. Conéctese a la base de datos como usuario dbadmin. 1. Para conceder privilegios de truncado de tablas al rol sales\$1rw, utilice el siguiente ejemplo. ``` GRANT TRUNCATE TABLE TO role sales_rw; ``` 1. Conéctese a la base de datos como usuario salesengineer utilizando el editor de consultas v2. 1. Para leer los primeros diez eventos de la tabla de eventos del esquema de ventas, utilice el siguiente ejemplo. ``` SELECT * FROM sales.events ORDER BY eventid LIMIT 10; +---------+---------+-------+--------+-----------------------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+-----------------------------+---------------------+ | 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 | | 2 | 306 | 8 | 2114 | Boris Godunov | 2008-10-15 20:00:00 | | 3 | 302 | 8 | 1935 | Salome | 2008-04-19 14:30:00 | | 4 | 309 | 8 | 2090 | La Cenerentola (Cinderella) | 2008-09-21 14:30:00 | | 5 | 302 | 8 | 1982 | Il Trovatore | 2008-06-05 19:00:00 | | 6 | 308 | 8 | 2109 | L Elisir d Amore | 2008-10-10 19:30:00 | | 7 | 309 | 8 | 1891 | Doctor Atomic | 2008-03-06 14:00:00 | | 8 | 302 | 8 | 1832 | The Magic Flute | 2008-01-06 20:00:00 | | 9 | 308 | 8 | 2087 | The Fly | 2008-09-18 19:30:00 | | 10 | 305 | 8 | 2079 | Rigoletto | 2008-09-10 15:00:00 | +---------+---------+-------+--------+-----------------------------+---------------------+ ``` 1. Para truncar la tabla de eventos en el esquema de ventas, utilice el siguiente ejemplo. ``` TRUNCATE sales.events; ``` 1. Para leer los datos de la tabla de eventos del esquema de ventas, utilice el siguiente ejemplo. ``` SELECT * FROM sales.events ORDER BY eventid LIMIT 10; +---------+---------+-------+--------+-----------------------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+-----------------------------+---------------------+ ``` ### Creación de roles de solo lectura y de lectura/escritura para el esquema de marketing (opcional) En este paso, se crean roles de solo lectura y de lectura/escritura para el esquema de marketing. 1. Conéctese a la base de datos como usuario dbadmin. 1. Para crear roles de solo lectura y lectura/escritura para el esquema de marketing, utilice el siguiente ejemplo. ``` CREATE ROLE marketing_ro; CREATE ROLE marketing_rw; GRANT USAGE ON SCHEMA marketing TO ROLE marketing_ro, ROLE marketing_rw; GRANT SELECT ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_ro; GRANT ROLE marketing_ro TO ROLE marketing_rw; GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_rw; CREATE USER marketinganalyst PASSWORD 'Test12345'; CREATE USER marketingengineer PASSWORD 'Test12345'; GRANT ROLE marketing_ro TO marketinganalyst; GRANT ROLE marketing_rw TO marketingengineer; ``` ## Funciones del sistema para RBAC (opcional) Amazon Redshift tiene dos funciones para proporcionar información del sistema sobre la pertenencia de los usuarios y la pertenencia de los roles a grupos o roles adicionales: role\$1is\$1member\$1of y user\$1is\$1member\$1of. Estas funciones están disponibles para los superusuarios y los usuarios normales. Los superusuarios pueden comprobar todas las pertenencias de los roles. Los usuarios normales solo pueden comprobar la pertenencia de los roles a los que se les han concedido acceso. Para usar la función role\$1is\$1member\$1of 1. Conéctese a la base de datos como usuario salesengineer. 1. Para comprobar si el rol sales\$1rw es miembro del rol sales\$1ro, utilice el siguiente ejemplo. ``` SELECT role_is_member_of('sales_rw', 'sales_ro'); +-------------------+ | role_is_member_of | +-------------------+ | true | +-------------------+ ``` 1. Para comprobar si el rol sales\$1ro es miembro del rol sales\$1rw, utilice el siguiente ejemplo. ``` SELECT role_is_member_of('sales_ro', 'sales_rw'); +-------------------+ | role_is_member_of | +-------------------+ | false | +-------------------+ ``` Para usar la función user\$1is\$1member\$1of 1. Conéctese a la base de datos como usuario salesengineer. 1. En el siguiente ejemplo, se intenta comprobar la pertenencia del usuario salesanalyst. Esta consulta produce un error porque salesengineer no tiene acceso a salesanalyst. Para ejecutar este comando correctamente, conéctese a la base de datos como usuario salesanalyst y utilice el ejemplo. ``` SELECT user_is_member_of('salesanalyst', 'sales_ro'); ERROR ``` 1. Conéctese a la base de datos como superusuario. 1. Para comprobar la pertenencia del usuario salesanalyst cuando está conectado como superusuario, utilice el siguiente ejemplo. ``` SELECT user_is_member_of('salesanalyst', 'sales_ro'); +-------------------+ | user_is_member_of | +-------------------+ | true | +-------------------+ ``` 1. Conéctese a la base de datos como usuario dbadmin. 1. Para comprobar la pertenencia del usuario salesengineer, utilice el siguiente ejemplo. ``` SELECT user_is_member_of('salesengineer', 'sales_ro'); +-------------------+ | user_is_member_of | +-------------------+ | true | +-------------------+ SELECT user_is_member_of('salesengineer', 'marketing_ro'); +-------------------+ | user_is_member_of | +-------------------+ | false | +-------------------+ SELECT user_is_member_of('marketinganalyst', 'sales_ro'); +-------------------+ | user_is_member_of | +-------------------+ | false | +-------------------+ ``` ## Vistas del sistema para RBAC (opcional) Para ver los roles, la asignación de roles a los usuarios, la jerarquía de roles y los privilegios de los objetos de la base de datos a través de los roles, utilice las vistas del sistema de Amazon Redshift. Estas vistas están disponibles para los superusuarios y los usuarios normales. Los superusuarios pueden comprobar todos los detalles de los roles. Los usuarios normales solo pueden comprobar los detalles de los roles a los que se les ha concedido acceso. 1. Para ver una lista de los usuarios a los que se han concedido explícitamente roles en el clúster, utilice el siguiente ejemplo. ``` SELECT * FROM svv_user_grants; ``` 1. Para ver una lista de los roles a los que se han concedido explícitamente roles en el clúster, utilice el siguiente ejemplo. ``` SELECT * FROM svv_role_grants; ``` Para ver la lista completa de vistas del sistema, consulte [Vistas de metadatos SVV](svv_views.md). ## Uso de seguridad a nivel de fila con RBAC (opcional) Para tener un control de acceso detallado de los datos sensibles, utilice la seguridad a nivel de fila (RLS). Para obtener más información sobre RLS, consulte [Seguridad de nivel básico](t_rls.md). En esta sección, creará una política RLS que otorga al usuario `salesengineer` permisos para ver solo las filas de la tabla `cat` que tienen el valor `catdesc` de Major League Baseball. A continuación, consulte la base de datos como usuario `salesengineer`. 1. Conéctese a la base de datos como usuario `salesengineer`. 1. Para ver las cinco primeras entradas de la tabla `cat`, utilice el siguiente ejemplo. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+---------------------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+---------------------------------+ | 1 | Sports | MLB | Major League Baseball | | 2 | Sports | NHL | National Hockey League | | 3 | Sports | NFL | National Football League | | 4 | Sports | NBA | National Basketball Association | | 5 | Sports | MLS | Major League Soccer | +-------+----------+---------+---------------------------------+ ``` 1. Conéctese a la base de datos como usuario `dbadmin`. 1. Para crear una política de RLS para la columna `catdesc` de la tabla `cat`, utilice el siguiente ejemplo. ``` CREATE RLS POLICY policy_mlb_engineer WITH (catdesc VARCHAR(50)) USING (catdesc = 'Major League Baseball'); ``` 1. Para asociar la política de RLS al rol de `sales_rw`, utilice el siguiente ejemplo. ``` ATTACH RLS POLICY policy_mlb_engineer ON sales.cat TO ROLE sales_rw; ``` 1. Para modificar la tabla y activar RLS, utilice el siguiente ejemplo. ``` ALTER TABLE sales.cat ROW LEVEL SECURITY ON; ``` 1. Conéctese a la base de datos como usuario `salesengineer`. 1. Para intentar ver las cinco primeras entradas de la tabla `cat`, utilice el siguiente ejemplo. Tenga en cuenta que las entradas solo aparecen cuando la columna `catdesc` es `Major League Baseball`. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+-----------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+-----------------------+ | 1 | Sports | MLB | Major League Baseball | +-------+----------+---------+-----------------------+ ``` 1. Conéctese a la base de datos como usuario `salesanalyst`. 1. Para intentar ver las cinco primeras entradas de la tabla `cat`, utilice el siguiente ejemplo. Tenga en cuenta que no aparece ninguna entrada porque se aplica la política predeterminada de denegación total. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+-----------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+-----------------------+ ``` 1. Conéctese a la base de datos como usuario `dbadmin`. 1. Para conceder el permiso IGNORE de RLS al rol `sales_ro`, utilice el siguiente ejemplo. Aquí se conceden al usuario `salesanalyst` los permisos para ignorar las políticas de RLS, ya que es miembro del rol `sales_ro`. ``` GRANT IGNORE RLS TO ROLE sales_ro; ``` 1. Conéctese a la base de datos como usuario `salesanalyst`. 1. Para ver las cinco primeras entradas de la tabla `cat`, utilice el siguiente ejemplo. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+---------------------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+---------------------------------+ | 1 | Sports | MLB | Major League Baseball | | 2 | Sports | NHL | National Hockey League | | 3 | Sports | NFL | National Football League | | 4 | Sports | NBA | National Basketball Association | | 5 | Sports | MLS | Major League Soccer | +-------+----------+---------+---------------------------------+ ``` 1. Conéctese a la base de datos como usuario `dbadmin`. 1. Para revocar el permiso IGNORE de RLS del rol `sales_ro`, utilice el siguiente ejemplo. ``` REVOKE IGNORE RLS FROM ROLE sales_ro; ``` 1. Conéctese a la base de datos como usuario `salesanalyst`. 1. Para intentar ver las cinco primeras entradas de la tabla `cat`, utilice el siguiente ejemplo. Tenga en cuenta que no aparece ninguna entrada porque se aplica la política predeterminada de denegación total. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+-----------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+-----------------------+ ``` 1. Conéctese a la base de datos como usuario `dbadmin`. 1. Para desconectar la política de RLS de la tabla `cat`, utilice el siguiente ejemplo. ``` DETACH RLS POLICY policy_mlb_engineer ON cat FROM ROLE sales_rw; ``` 1. Conéctese a la base de datos como usuario `salesanalyst`. 1. Para intentar ver las cinco primeras entradas de la tabla `cat`, utilice el siguiente ejemplo. Tenga en cuenta que no aparece ninguna entrada porque se aplica la política predeterminada de denegación total. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+---------------------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+---------------------------------+ | 1 | Sports | MLB | Major League Baseball | | 2 | Sports | NHL | National Hockey League | | 3 | Sports | NFL | National Football League | | 4 | Sports | NBA | National Basketball Association | | 5 | Sports | MLS | Major League Soccer | +-------+----------+---------+---------------------------------+ ``` 1. Conéctese a la base de datos como usuario `dbadmin`. 1. Para eliminar la política de RLS, utilice el siguiente ejemplo. ``` DROP RLS POLICY policy_mlb_engineer; ``` 1. Para eliminar RLS, utilice el siguiente ejemplo. ``` ALTER TABLE cat ROW LEVEL SECURITY OFF; ``` ## Temas relacionados Para obtener más información sobre RBAC, consulte la siguiente documentación: + [Jerarquía de roles](t_role_hierarchy.md) + [Asignación de roles](t_role_assignment.md) + [Permisos de objetos de bases de datos](r_roles-database-privileges.md) + [ALTER DEFAULT PRIVILEGES para RBAC](r_roles-alter-default-privileges.md) # Seguridad de nivel básico Con la seguridad de la fila (RLS) en Amazon Redshift, puede tener un control de acceso pormenorizado de los datos confidenciales. Puede decidir qué usuarios o roles pueden acceder a registros de datos específicos dentro de los esquemas o tablas, según las políticas de seguridad que se definen en los objetos de la base de datos. Además de la seguridad de la columna, donde puede conceder permisos a los usuarios a un subconjunto de columnas, utilice políticas de RLS para restringir aún más el acceso a determinadas filas de las columnas visibles. Para obtener más información acerca de la seguridad de la columna, consulte [Notas de uso para el control de acceso de nivel de columna](r_GRANT-usage-notes.md#r_GRANT-usage-notes-clp). Al aplicar políticas de RLS en las tablas, puede restringir los conjuntos de los resultados devueltos cuando los usuarios ejecutan consultas. Al crear políticas de RLS, puede especificar expresiones que determinen si Amazon Redshift devuelve alguna fila existente en la tabla de una consulta. Cuando se crean políticas de RLS para limitar el acceso, no es necesario agregar ni externalizar condiciones adicionales en las consultas. Le recomendamos que, al crear políticas de RLS, cree políticas simples y evite instrucciones complejas. Al definir políticas de RLS, no utilice en la definición uniones de tablas excesivas que se basen en políticas. Cuando una política hace referencia a una tabla de búsqueda, Amazon Redshift analiza la tabla adicional, además de la tabla en la que se encuentra la política. Existirán diferencias de rendimiento en la misma consulta para un usuario con una política de RLS adjunta y un usuario sin ninguna política adjunta. # Uso de políticas de RLS en instrucciones SQL Al utilizar políticas de RLS en instrucciones SQL, Amazon Redshift aplica las siguientes reglas: + Amazon Redshift aplica políticas de RLS a las instrucciones SELECT, UPDATE y DELETE de forma predeterminada. + Con SELECT y UNLOAD, Amazon Redshift filtra las filas según la política definida. + Con UPDATE, Amazon Redshift actualiza solo las filas que puede ver. Si una política restringe un subconjunto de las filas de una tabla, no podrá actualizarlas. + Con DELETE, puede eliminar solo las filas que puede ver. Si una política restringe un subconjunto de filas de una tabla, no podrá eliminarlas. Con TRUNCATE, aún puede truncar la tabla. + Con CREATE TABLE LIKE, las tablas creadas con las opciones LIKE no heredarán la configuración de permisos de la tabla de origen. Del mismo modo, la tabla de destino no heredará las políticas de RLS de la tabla de origen. # Combinación de varias políticas por usuario RLS en Amazon Redshift permite asociar varias políticas por usuario y objeto. Si se han definido varias políticas para un usuario, Amazon Redshift aplica todas las políticas con la sintaxis AND u OR en función de la configuración de RLS CONJUNCTION TYPE para la tabla. Para obtener más información acerca del tipo de conjunción, consulte [ALTER TABLE](r_ALTER_TABLE.md). En una tabla, se pueden asociar varias políticas con el usuario. Puede suceder que varias políticas estén directamente asociadas al usuario o que este pertenezca a varios roles, y los roles tengan diferentes políticas asociadas a ellos. Cuando varias políticas deben restringir el acceso a las filas en una relación determinada, puede establecer el RLS CONJUNCTION TYPE de la relación en AND. Considere el siguiente ejemplo. Alice solo puede ver los eventos deportivos que tengan el catname NBA, tal como se especifica en la política. ``` -- Create an analyst role and grant it to a user named Alice. CREATE ROLE analyst; CREATE USER alice WITH PASSWORD 'Name_is_alice_1'; GRANT ROLE analyst TO alice; -- Create an RLS policy that only lets the user see sports. CREATE RLS POLICY policy_sports WITH (catgroup VARCHAR(10)) USING (catgroup = 'Sports'); -- Create an RLS policy that only lets the user see NBA. CREATE RLS POLICY policy_nba WITH (catname VARCHAR(10)) USING (catname = 'NBA'); -- Attach both to the analyst role. ATTACH RLS POLICY policy_sports ON category TO ROLE analyst; ATTACH RLS POLICY policy_nba ON category TO ROLE analyst; -- Activate RLS on the category table with AND CONJUNCTION TYPE. ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE AND; -- Change session to Alice. SET SESSION AUTHORIZATION alice; -- Select all from the category table. SELECT catgroup, catname FROM category; catgroup | catname ---------+--------- Sports | NBA (1 row) ``` Si las distintas políticas deben permitir a los usuarios ver más filas en una relación determinada, el usuario puede establecer el RLS CONJUNCTION TYPE de la relación en OR. Considere el siguiente ejemplo. Alice solo puede ver conciertos y deportes, según lo especificado en la política. ``` -- Create an analyst role and grant it to a user named Alice. CREATE ROLE analyst; CREATE USER alice WITH PASSWORD 'Name_is_alice_1'; GRANT ROLE analyst TO alice; -- Create an RLS policy that only lets the user see concerts. CREATE RLS POLICY policy_concerts WITH (catgroup VARCHAR(10)) USING (catgroup = 'Concerts'); -- Create an RLS policy that only lets the user see sports. CREATE RLS POLICY policy_sports WITH (catgroup VARCHAR(10)) USING (catgroup = 'Sports'); -- Attach both to the analyst role. ATTACH RLS POLICY policy_concerts ON category TO ROLE analyst; ATTACH RLS POLICY policy_sports ON category TO ROLE analyst; -- Activate RLS on the category table with OR CONJUNCTION TYPE. ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE OR; -- Change session to Alice. SET SESSION AUTHORIZATION alice; -- Select all from the category table. SELECT catgroup, count(*) FROM category GROUP BY catgroup ORDER BY catgroup; catgroup | count ---------+------- Concerts | 3 Sports | 5 (2 rows) ``` # Propiedad y administración de la política de RLS Como superusuario, administrador de seguridad o usuario que tiene el rol sys:secadmin, puede crear, modificar, asociar y desasociar políticas de RLS. Las políticas de RLS se pueden asociar a tablas, vistas, vistas de enlace tardío (LBV) y vistas materializadas (MV). En el objeto, puede activar o desactivar la seguridad de la fila sin modificar la definición de esquema de las tablas. Para comenzar con la seguridad de la fila, a continuación se indican las instrucciones SQL que puede utilizar: + Utilice la instrucción ALTER TABLE para activar o desactivar RLS en una tabla, vista o vista de enlace tardío. Para obtener más información, consulte [ALTER TABLE](r_ALTER_TABLE.md). + La instrucción ALTER MATERIALIZED VIEW se utiliza para activar o desactivar RLS en una vista materializada (MV). Para obtener más información, consulte [ALTER MATERIALIZED VIEW](r_ALTER_MATERIALIZED_VIEW.md). + La instrucción CREATE RLS POLICY se utiliza para crear una política de seguridad para una o más tablas y especificar uno o más usuarios o roles en la política. Para obtener más información, consulte [CREATE RLS POLICY](r_CREATE_RLS_POLICY.md). + Utilice la instrucción ALTER RLS POLICY para modificar la política, por ejemplo, cambiar la definición de la política. Puede utilizar la misma política para varias tablas o vistas. Para obtener más información, consulte [ALTER RLS POLICY](r_ALTER_RLS_POLICY.md). + La instrucción ATTACH RLS POLICY se utiliza para adjuntar una política a una o más relaciones, a uno o más usuarios, o a roles. Para obtener más información, consulte [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md). + La instrucción DETACH RLS POLICY se utiliza para desconectar una política de una o más relaciones, de uno o más usuarios o de roles. Para obtener más información, consulte [DETACH RLS POLICY](r_DETACH_RLS_POLICY.md). + La instrucción DROP RLS POLICY se utiliza para eliminar una política. Para obtener más información, consulte [DROP RLS POLICY](r_DROP_RLS_POLICY.md). + Las instrucciones GRANT y REVOKE se utilizan para conceder y revocar de manera explícita permisos SELECT a las políticas de RLS que hacen referencia a tablas de búsqueda. Para obtener más información, consulte [GRANT](r_GRANT.md) y [REVOKE](r_REVOKE.md). Para supervisar las políticas creadas, sys:secadmin puede ver la [SVV\$1RLS\$1POLICY](r_SVV_RLS_POLICY.md) y la [SVV\$1RLS\$1ATTACHED\$1POLICY](r_SVV_RLS_ATTACHED_POLICY.md). Para enumerar las relaciones protegidas por RLS, sys:secadmin puede ver [SVV\$1RLS\$1RELATION](r_SVV_RLS_RELATION.md). Para rastrear la aplicación de políticas de RLS en consultas que hacen referencia a relaciones protegidas por RLS, un superusuario, sys:operator, o cualquier usuario con el permiso del sistema ACCESS SYSTEM TABLE puede ver la [SVV\$1RLS\$1APPLIED\$1POLICY](r_SVV_RLS_APPLIED_POLICY.md). Tenga en cuenta que no se concede estos permisos a sys:secadmin de forma predeterminada. Para permitir a los usuarios el acceso completo a una relación protegida por RLS, puede conceder el permiso IGNORE RLS. A los superusuarios o sys:secadmin se les concede automáticamente IGNORE RLS. Para obtener más información, consulte [GRANT](r_GRANT.md). Para explicar los filtros de política de RLS de una consulta en el plan EXPLAIN a fin de solucionar problemas de consultas relacionadas con RLS, puede conceder el permiso EXPLAIN RLS a cualquier usuario. Para obtener más información, consulte [GRANT](r_GRANT.md) y [EXPLAIN](r_EXPLAIN.md). # Objetos y principios dependientes de políticas Para proporciona seguridad a las aplicaciones y evitar que los objetos de política queden obsoletos o no sean válidos, Amazon Redshift no permite eliminar ni alterar los objetos a los que hagan referencia las políticas de RLS. A continuación, se enumeran las dependencias de objetos de esquema de los que Amazon Redshift hace un seguimiento para las políticas de RLS. + Al realizar el seguimiento de la dependencia de objetos de esquema para la tabla de destino, Amazon Redshift sigue estas reglas: + Amazon Redshift desconecta la política de una relación, usuario, rol o público cuando se elimina una tabla de destino. + Si se cambia el nombre de una tabla de destino, no se produce ningún impacto en las políticas adjuntas. + Solo se pueden eliminar las columnas de la tabla de destino a la que se hace referencia dentro de la definición de política si se elimina o desconecta primero la política. Esto también se aplica cuando se especifica la opción CASCADE. Puede eliminar otras columnas de la tabla de destino. + No se puede cambiar el nombre de las columnas de la tabla de destino a las que se hace referencia. Para cambiar el nombre de las columnas a las que se hace referencia, desconecte primero la política. Esto también se aplica cuando se especifica la opción CASCADE. + No se puede cambiar el tipo de la columna a la que se hace referencia, aunque especifique la opción CASCADE. + Al realizar el seguimiento de la dependencia de objetos de esquema para la tabla de búsqueda, Amazon Redshift sigue estas reglas: + No se puede eliminar una tabla de búsqueda. Para eliminar una tabla de búsqueda, primero se debe eliminar la política en la que se hace referencia a la tabla de búsqueda. + No se puede cambiar el nombre de una tabla de búsqueda. Para cambiar el nombre de una tabla de búsqueda, primero se debe eliminar la política en la que se hace referencia a la tabla de búsqueda. Esto también se aplica cuando se especifica la opción CASCADE. + No se pueden eliminar las columnas de la tabla de búsqueda utilizadas en la definición de la política. Para eliminar las columnas de la tabla de búsqueda utilizadas en la definición de la política, primero se debe eliminar la política en la que se hace referencia a la tabla de búsqueda. Esto también se aplica cuando se especifica la opción CASCADE en la instrucción ALTER TABLE DROP COLUMN. Puede eliminar otras columnas de la tabla de búsqueda. + No se puede cambiar el nombre de las columnas de la tabla de búsqueda a las que se hace referencia. Para cambiar el nombre de las columnas referidas, primero se debe eliminar la política en la que se hace referencia a la tabla de búsqueda. Esto también se aplica cuando se especifica la opción CASCADE. + No puede cambiar el tipo de la columna a la que se hace referencia. + Cuando se elimina un usuario o rol, Amazon Redshift desconecta todas las políticas adjuntas al usuario o rol de manera automática. + Cuando se utiliza la opción CASCADE en la instrucción DROP SCHEMA, Amazon Redshift también elimina las relaciones en el esquema. Además, elimina las relaciones de otros esquemas que dependan de las relaciones del esquema eliminado. En caso de una relación de tabla de búsqueda en una política, Amazon Redshift no pasa el DDL DROP SCHEMA. Amazon Redshift desconecta todas las políticas que se adjuntan a las relaciones eliminadas por la instrucción DROP SCHEMA. + Solo se puede eliminar una función de búsqueda (una función a la que se hace referencia dentro de una definición de política) cuando también se elimina la política. Esto también se aplica cuando se especifica la opción CASCADE. + Cuando se adjunta una política a una tabla, Amazon Redshift comprueba si esta tabla es una tabla de búsqueda de una política diferente. En caso afirmativo, Amazon Redshift no permite adjuntar una política a esta tabla. + Al crear una política de RLS, Amazon Redshift comprueba si esta tabla es una tabla de destino de otra política de RLS. En caso afirmativo, Amazon Redshift no permite crear una política en esta tabla. ## Ejemplo En el siguiente ejemplo, se ilustra cómo se hace un seguimiento de la dependencia del esquema. ``` -- The CREATE and ATTACH policy statements for `policy_events` references some -- target and lookup tables. -- Target tables are tickit_event_redshift and target_schema.target_event_table. -- Lookup table is tickit_sales_redshift. -- Policy `policy_events` has following dependencies: -- table tickit_sales_redshift column eventid, qtysold -- table tickit_event_redshift column eventid -- table target_event_table column eventid -- schema public and target_schema CREATE RLS POLICY policy_events WITH (eventid INTEGER) USING ( eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3) ); ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst; ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer; ``` # 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. + Las políticas de RLS se pueden asociar a tablas, vistas, vistas de enlace tardío (LBV) y vistas materializadas (MV). + La seguridad de la fila funciona con la seguridad de la columna para proteger los datos. + 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](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [SHOW](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) y [RESET](r_RESET.md). 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](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings). **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: + Las políticas de RLS no se pueden asociar a tablas externas ni a muchos otros tipos de relaciones. Para obtener más información, consulte [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md). + 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. ``` + 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](r_ALTER_TABLE.md). + 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\$1predicate\$1exp). 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 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) en la *Guía de administración de Amazon Redshift*. Para obtener información sobre el comando ALTER USER, consulte [ALTER USER](r_ALTER_USER.md). + 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](r_CREATE_VIEW.md). 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. # Prácticas recomendadas para el rendimiento de RLS A continuación, se enumeran las prácticas recomendadas para garantizar un mejor rendimiento de Amazon Redshift en las tablas protegidas por RLS. ## Seguridad de los operadores y las funciones Al consultar tablas protegidas por RLS, el uso de determinados operadores o funciones puede conducir a un deterioro del rendimiento. Amazon Redshift clasifica a los operadores y las funciones como seguros o no seguros para consultar tablas protegidas por RLS. Una función u operador se clasifica como seguro para RLS cuando no tiene efectos secundarios observables en función de las entradas. Concretamente, una función u operador seguro para RLS no puede ser uno de los siguientes: + Muestra un valor de entrada, o un valor que depende del valor de entrada, con o sin un mensaje de error. + Falla o devuelve errores que dependen del valor de entrada. Entre los operadores no seguros para RLS se incluyen los siguientes: + Operadores aritméticos: \$1, -, /, \$1, %. + Operadores de texto: LIKE y SIMILAR TO. + Operadores cast. + UDF. Utilice la siguiente instrucción SELECT para comprobar la seguridad de los operadores y las funciones. ``` SELECT proname, proc_is_rls_safe(oid) FROM pg_proc; ``` Al planificar consultas en tablas protegidas por RLS, Amazon Redshift impone restricciones al orden de evaluación de los predicados de usuario que contienen operadores y funciones no seguros para RLS. Las consultas que hacen referencia a operadores o funciones no seguros para RLS pueden provocar un deterioro del rendimiento al consultar tablas protegidas por RLS. El rendimiento puede deteriorarse de manera significativa cuando Amazon Redshift no puede enviar predicados no seguros para RLS a los análisis de la tabla base para aprovechar las claves de clasificación. Para un mejor rendimiento, evite las consultas que utilizan predicados no seguros para RLS que aprovechan una clave de clasificación. Utilice las instrucciones EXPLAIN junto con el permiso del sistema EXPLAIN RLS para comprobar que Amazon Redshift puede enviar operadores y funciones. ## Almacenamiento en caché de los resultados Para reducir el tiempo de ejecución de las consultas y mejorar el rendimiento del sistema, Amazon Redshift almacena en caché los resultados de determinados tipos de consultas en la memoria del nodo principal. Amazon Redshift utiliza los resultados almacenados en caché para una consulta nueva que analiza tablas protegidas con RLS cuando se cumplen todas las condiciones de las tablas no protegidas y se cumplen todas las condiciones a continuación: + Las tablas o las vistas de la política no se han modificado. + La consulta no utiliza una función que debe evaluarse cada vez que se ejecuta, como GETDATE o CURRENT\$1USER. Para obtener un mejor rendimiento, evite utilizar predicados de políticas que no cumplan con las condiciones anteriores. Para obtener más información sobre el almacenamiento en caché de los resultados en Amazon Redshift, consulte [Almacenamiento en caché de los resultados](c_challenges_achieving_high_performance_queries.md#result-caching). ## Políticas complejas Para obtener un mejor rendimiento, evite el uso de políticas complejas con subconsultas que unan varias tablas. # Ejemplo completo de seguridad en el nivel de fila A continuación, se muestra un ejemplo completo para ilustrar cómo un superusuario crea algunos usuarios y roles. Luego, un usuario con el rol secadmin crea, adjunta, desconecta y elimina políticas de RLS. En este ejemplo, se utiliza la base de datos de ejemplo tickit. Para obtener más información, consulte [Cargar datos desde Amazon S3 en Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html) en la *Guía de introducción a Amazon Redshift*. ``` -- Create users and roles referenced in the policy statements. CREATE ROLE analyst; CREATE ROLE consumer; CREATE ROLE dbadmin; CREATE ROLE auditor; CREATE USER bob WITH PASSWORD 'Name_is_bob_1'; CREATE USER alice WITH PASSWORD 'Name_is_alice_1'; CREATE USER joe WITH PASSWORD 'Name_is_joe_1'; CREATE USER molly WITH PASSWORD 'Name_is_molly_1'; CREATE USER bruce WITH PASSWORD 'Name_is_bruce_1'; GRANT ROLE sys:secadmin TO bob; GRANT ROLE analyst TO alice; GRANT ROLE consumer TO joe; GRANT ROLE dbadmin TO molly; GRANT ROLE auditor TO bruce; GRANT ALL ON TABLE tickit_category_redshift TO PUBLIC; GRANT ALL ON TABLE tickit_sales_redshift TO PUBLIC; GRANT ALL ON TABLE tickit_event_redshift TO PUBLIC; -- Create table and schema referenced in the policy statements. CREATE SCHEMA target_schema; GRANT ALL ON SCHEMA target_schema TO PUBLIC; CREATE TABLE target_schema.target_event_table (LIKE tickit_event_redshift); GRANT ALL ON TABLE target_schema.target_event_table TO PUBLIC; -- Change session to analyst alice. SET SESSION AUTHORIZATION alice; -- Check the tuples visible to analyst alice. -- Should contain all 3 categories. SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup; -- Change session to security administrator bob. SET SESSION AUTHORIZATION bob; CREATE RLS POLICY policy_concerts WITH (catgroup VARCHAR(10)) USING (catgroup = 'Concerts'); SELECT poldb, polname, polalias, polatts, polqual, polenabled, polmodifiedby FROM svv_rls_policy WHERE poldb = CURRENT_DATABASE(); ATTACH RLS POLICY policy_concerts ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin; ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY ON; SELECT * FROM svv_rls_attached_policy; -- Change session to analyst alice. SET SESSION AUTHORIZATION alice; -- Check that tuples with only `Concert` category will be visible to analyst alice. SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup; -- Change session to consumer joe. SET SESSION AUTHORIZATION joe; -- Although the policy is attached to a different role, no tuples will be -- visible to consumer joe because the default deny all policy is applied. SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup; -- Change session to dbadmin molly. SET SESSION AUTHORIZATION molly; -- Check that tuples with only `Concert` category will be visible to dbadmin molly. SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup; -- Check that EXPLAIN output contains RLS SecureScan to prevent disclosure of -- sensitive information such as RLS filters. EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup; -- Change session to security administrator bob. SET SESSION AUTHORIZATION bob; -- Grant IGNORE RLS permission so that RLS policies do not get applicable to role dbadmin. GRANT IGNORE RLS TO ROLE dbadmin; -- Grant EXPLAIN RLS permission so that anyone in role auditor can view complete EXPLAIN output. GRANT EXPLAIN RLS TO ROLE auditor; -- Change session to dbadmin molly. SET SESSION AUTHORIZATION molly; -- Check that all tuples are visible to dbadmin molly because `IGNORE RLS` is granted to role dbadmin. SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup; -- Change session to auditor bruce. SET SESSION AUTHORIZATION bruce; -- Check explain plan is visible to auditor bruce because `EXPLAIN RLS` is granted to role auditor. EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup; -- Change session to security administrator bob. SET SESSION AUTHORIZATION bob; DETACH RLS POLICY policy_concerts ON tickit_category_redshift FROM ROLE analyst, ROLE dbadmin; -- Change session to analyst alice. SET SESSION AUTHORIZATION alice; -- Check that no tuples are visible to analyst alice. -- Although the policy is detached, no tuples will be visible to analyst alice -- because of default deny all policy is applied if the table has RLS on. SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup; -- Change session to security administrator bob. SET SESSION AUTHORIZATION bob; CREATE RLS POLICY policy_events WITH (eventid INTEGER) AS ev USING ( ev.eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3) ); ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst; ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer; RESET SESSION AUTHORIZATION; -- Can not cannot alter type of dependent column. ALTER TABLE target_schema.target_event_table ALTER COLUMN eventid TYPE float; ALTER TABLE tickit_event_redshift ALTER COLUMN eventid TYPE float; ALTER TABLE tickit_sales_redshift ALTER COLUMN eventid TYPE float; ALTER TABLE tickit_sales_redshift ALTER COLUMN qtysold TYPE float; -- Can not cannot rename dependent column. ALTER TABLE target_schema.target_event_table RENAME COLUMN eventid TO renamed_eventid; ALTER TABLE tickit_event_redshift RENAME COLUMN eventid TO renamed_eventid; ALTER TABLE tickit_sales_redshift RENAME COLUMN eventid TO renamed_eventid; ALTER TABLE tickit_sales_redshift RENAME COLUMN qtysold TO renamed_qtysold; -- Can not drop dependent column. ALTER TABLE target_schema.target_event_table DROP COLUMN eventid CASCADE; ALTER TABLE tickit_event_redshift DROP COLUMN eventid CASCADE; ALTER TABLE tickit_sales_redshift DROP COLUMN eventid CASCADE; ALTER TABLE tickit_sales_redshift DROP COLUMN qtysold CASCADE; -- Can not drop lookup table. DROP TABLE tickit_sales_redshift CASCADE; -- Change session to security administrator bob. SET SESSION AUTHORIZATION bob; DROP RLS POLICY policy_concerts; DROP RLS POLICY IF EXISTS policy_events; ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY OFF; RESET SESSION AUTHORIZATION; -- Drop users and roles. DROP USER bob; DROP USER alice; DROP USER joe; DROP USER molly; DROP USER bruce; DROP ROLE analyst; DROP ROLE consumer; DROP ROLE auditor FORCE; DROP ROLE dbadmin FORCE; ``` # Seguridad de los metadatos De igual modo que la seguridad en el nivel de la fila de Amazon Redshift, la seguridad de los metadatos le proporciona un mayor control sobre los metadatos. Si la seguridad de los metadatos está habilitada para el clúster aprovisionado o el grupo de trabajo sin servidor, los usuarios pueden ver los metadatos de los objetos a los que tienen acceso de visualización. La seguridad de los metadatos le permite separar la visibilidad en función de sus necesidades. Por ejemplo, puede usar un único almacenamiento de datos para centralizar todo su almacenamiento de datos. Sin embargo, si almacena datos de varios sectores, administrar la seguridad puede convertirse en una tarea compleja. Con la seguridad de los metadatos habilitada, puede configurar su visibilidad. Los usuarios de un sector pueden tener más visibilidad sobre sus objetos, mientras que usted restringe el acceso de visualización a los usuarios de otro sector. La seguridad de los metadatos admite todos los tipos de objetos, como los esquemas, las tablas, las vistas, las vistas materializadas, los procedimientos almacenados, las funciones definidas por el usuario y los modelos de machine learning. Los usuarios pueden ver los metadatos de los objetos en las siguientes circunstancias: + Si se concede acceso a los objetos al usuario. + Si el acceso al objeto se concede a un grupo o un rol al que pertenece el usuario. + El objeto es público. + El usuario es el propietario del objeto de base de datos. Para habilitar la seguridad de los metadatos, utilice el comando [ALTER SYSTEM](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_SYSTEM.html). La siguiente es la sintaxis de cómo utilizar el comando ALTER SYSTEM con la seguridad de los metadatos. ``` ALTER SYSTEM SET metadata_security=[true|t|on|false|f|off]; ``` Al habilitar la seguridad de los metadatos, todos los usuarios que tengan los permisos necesarios pueden ver los metadatos pertinentes de los objetos a los que tienen acceso. Si desea que solo determinados usuarios puedan ver la seguridad de los metadatos, conceda el permiso `ACCESS CATALOG` a un rol y, a continuación, asígnelo al usuario. Para obtener más información sobre el uso de los roles para controlar mejor la seguridad, consulte [Control de acceso basado en roles](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html). En el siguiente ejemplo se muestra cómo conceder el permiso `ACCESS CATALOG` a un rol y, a continuación, asignar el rol a un usuario. Para obtener más información sobre cómo conceder permisos, consulte el comando [GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html). ``` CREATE ROLE sample_metadata_viewer; GRANT ACCESS CATALOG TO ROLE sample_metadata_viewer; GRANT ROLE sample_metadata_viewer to salesadmin; ``` Si prefiere usar roles ya definidos, los [roles definidos por el sistema](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) `operator`, `secadmin`, `dba` y `superuser` tienen todos los permisos necesarios para ver los metadatos de los objetos. De forma predeterminada, los superusuarios pueden ver el catálogo completo. ``` GRANT ROLE operator to sample_user; ``` Si usa roles para controlar la seguridad de los metadatos, tendrá acceso a todas las vistas y funciones del sistema que incluyan el control de acceso basado en roles. Por ejemplo, puede consultar la vista de [SVV\$1ROLES](https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_ROLES.html) para ver todos los roles. Para ver si un usuario es miembro de un rol o grupo, utilice la función [USER\$1IS\$1MEMBER\$1OF](https://docs.aws.amazon.com/redshift/latest/dg/r_USER_IS_MEMBER_OF.html). Para obtener una lista completa de las vistas SVV, consulte las [vistas de metadatos SVV](https://docs.aws.amazon.com/redshift/latest/dg/svv_views.html). Para obtener una lista de las funciones de información del sistema, consulte [Funciones de información del sistema](https://docs.aws.amazon.com/redshift/latest/dg/r_System_information_functions.html). # Enmascaramiento de datos dinámico **nota** Amazon Redshift enmascara automáticamente determinadas columnas de las tablas del sistema al registrar información sobre las consultas realizadas en las vistas del catálogo de datos para evitar la exposición de metadatos confidenciales. Para obtener más información, consulte [Registro seguro](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html) en la *Guía de administración de Amazon Redshift*. 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)](t_Roles.md). 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](t_ddm-conditional.md). 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. # Comandos SQL para la administración de políticas de enmascaramiento de datos dinámico Puede realizar las siguientes acciones para crear, adjuntar, separar y eliminar políticas de enmascaramiento de datos dinámico: + Para crear una política de enmascaramiento dinámico de datos, utilice el comando [CREATE MASKING POLICY](r_CREATE_MASKING_POLICY.md). A continuación, se ofrece un ejemplo de cómo crear una política de enmascaramiento mediante una función de hash SHA-2. ``` CREATE MASKING POLICY hash_credit WITH (credit_card varchar(256)) USING (sha2(credit_card + 'testSalt', 256)); ``` + Para modificar una política DDM existente, utilice el comando [ALTER MASKING POLICY](r_ALTER_MASKING_POLICY.md). A continuación, se ofrece un ejemplo de modificación de una política de enmascaramiento existente. ``` ALTER MASKING POLICY hash_credit USING (sha2(credit_card + 'otherTestSalt', 256)); ``` + Para adjuntar una política de enmascaramiento dinámico de datos a una tabla para uno o varios usuarios o roles, utilice el comando [ATTACH MASKING POLICY](r_ATTACH_MASKING_POLICY.md). A continuación, se ofrece un ejemplo de una política de enmascaramiento en un par de columna-rol. ``` ATTACH MASKING POLICY hash_credit ON credit_cards (credit_card) TO ROLE science_role PRIORITY 30; ``` La cláusula PRIORITY determina qué política de enmascaramiento se aplica a una sesión de usuario cuando se adjuntan varias políticas a la misma columna. Por ejemplo, si el usuario del ejemplo anterior tiene otra política de enmascaramiento adjunta a la misma columna de tarjetas de crédito con una prioridad de 20, la política de science\$1role es la que se aplica, ya que tiene la prioridad más alta, es decir, 30. + Para desconectar una política de enmascaramiento dinámico de datos de una tabla de uno o varios usuarios o roles, utilice el comando [DETACH MASKING POLICY](r_DETACH_MASKING_POLICY.md). A continuación, se ofrece un ejemplo de desconexión de una política de enmascaramiento de un par de columna-rol. ``` DETACH MASKING POLICY hash_credit ON credit_cards(credit_card) FROM ROLE science_role; ``` + Para eliminar una política de enmascaramiento dinámico de datos de todas las bases de datos, utilice el comando [DROP MASKING POLICY](r_DROP_MASKING_POLICY.md). A continuación, se ofrece un ejemplo de cómo eliminar una política de enmascaramiento de todas las bases de datos. ``` DROP MASKING POLICY hash_credit; ``` # Jerarquía de políticas de enmascaramiento de datos dinámico Cuando asocie varias políticas de enmascaramiento, tenga en cuenta lo siguiente: + Se pueden adjuntar varias políticas de enmascaramiento a una sola columna. + Cuando se aplican varias políticas de enmascaramiento a una consulta, se aplica la política de mayor prioridad adjuntada a cada columna. Considere el siguiente ejemplo. ``` ATTACH MASKING POLICY partial_hash ON credit_cards(address, credit_card) TO ROLE analytics_role PRIORITY 20; ATTACH MASKING POLICY full_hash ON credit_cards(credit_card, ssn) TO ROLE auditor_role PRIORITY 30; SELECT address, credit_card, ssn FROM credit_cards; ``` Al ejecutar la instrucción SELECT, un usuario con los roles de analista y auditor ve la columna de direcciones con la política de enmascaramiento `partial_hash` aplicada. También ve las columnas de tarjetas de crédito y SSN con la política de enmascaramiento `full_hash` aplicada, porque la política `full_hash` tiene una mayor prioridad en la columna de tarjetas de crédito. + Si no especifica una prioridad al asociar una política de enmascaramiento, la prioridad predeterminada es 0. + No puede adjuntar dos políticas a la misma columna con la misma prioridad. + No puede adjuntar dos políticas a la misma combinación de usuario y columna o rol y columna. + Cuando se aplican varias políticas de enmascaramiento a lo largo de la misma ruta SUPER mientras estén asociadas al mismo usuario o rol, solo surtirá efecto la vinculación de mayor prioridad. Considere los siguientes ejemplos: El primer ejemplo muestra dos políticas de enmascaramiento asociadas en la misma ruta donde se aplica la política de mayor prioridad. ``` ATTACH MASKING POLICY hide_name ON employees(col_person.name) TO PUBLIC PRIORITY 20; ATTACH MASKING POLICY hide_last_name ON employees(col_person.name.last) TO PUBLIC PRIORITY 30; --Only the hide_last_name policy takes effect. SELECT employees.col_person.name FROM employees; ``` El segundo ejemplo muestra dos políticas de enmascaramiento asociadas a rutas diferentes en el mismo objeto SUPER, sin ningún conflicto entre las políticas. Ambos adjuntos se aplicarán de forma simultánea. ``` ATTACH MASKING POLICY hide_first_name ON employees(col_person.name.first) TO PUBLIC PRIORITY 20; ATTACH MASKING POLICY hide_last_name ON employees(col_person.name.last) TO PUBLIC PRIORITY 20; --Both col_person.name.first and col_person.name.last are masked. SELECT employees.col_person.name FROM employees; ``` Para confirmar qué política de enmascaramiento se aplica a una determinada combinación de usuario y columna o rol y columna, los usuarios con el rol [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) pueden buscar el par de columna y rol o columna y usuario en la vista del sistema [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md). Para obtener más información, consulte [Vistas del sistema de enmascaramiento de datos dinámico](r_ddm-svv.md). # Uso del enmascaramiento dinámico de datos con rutas de tipos de datos SUPER Amazon Redshift permite asociar políticas de enmascaramiento dinámico de datos a las rutas de las columnas de tipo SUPER. Para obtener más información acerca del tipo de datos SUPER, consulte [Datos semiestructurados en Amazon Redshift](super-overview.md). Al asociar políticas de enmascaramiento a las rutas de las columnas de tipo SUPER, tenga en cuenta lo siguiente. + Al asociar una política de enmascaramiento a una ruta de una columna, esa columna debe definirse como el tipo de datos SUPER. Solo puede aplicar políticas de enmascaramiento a los valores *escalares* de la ruta SUPER. No puede aplicar políticas de enmascaramiento a estructuras o matrices complejas. + Puede aplicar diferentes políticas de enmascaramiento a varios valores escalares de una sola columna SUPER, siempre que las rutas SUPER no entren en conflicto. Por ejemplo, las rutas SUPER `a.b` y `a.b.c` entran en conflicto porque están en la misma ruta. Además, `a.b` es el principal de `a.b.c`. Las rutas SUPER `a.b.c` y `a.b.d` no entran en conflicto. + Amazon Redshift no puede comprobar si las rutas asociadas a una política de enmascaramiento existen en los datos y son del tipo esperado hasta que la política se aplique en el tiempo de ejecución de las consultas de los usuarios. Por ejemplo, si asocia una política de enmascaramiento que enmascara valores TEXT a una ruta SUPER que contiene un valor INT, Amazon Redshift intenta convertir el tipo de valor en la ruta. En estas situaciones, el comportamiento de Amazon Redshift en el tiempo de ejecución depende de los ajustes de la configuración de la consulta de objetos SUPER. De forma predeterminada, Amazon Redshift está en modo laxo y resolverá las rutas que falten y las cadenas no válidas como `NULL` en la ruta SUPER dada. Para obtener más información acerca de los valores de configuración relacionados con SUPER, consulte [Configuraciones SUPER](super-configurations.md). + SUPER es un tipo sin esquema, lo que significa que Amazon Redshift no puede confirmar la existencia del valor en una ruta SUPER determinada. Si asocia una política de enmascaramiento a una ruta SUPER que no existe y Amazon Redshift está en modo laxo, Amazon Redshift resolverá la ruta hacia un valor `NULL`. Le recomendamos que tenga en cuenta el formato esperado de los objetos SUPER y la probabilidad de que tengan atributos inesperados al asociar políticas de enmascaramiento a las rutas de las columnas SUPER. Si cree que puede haber un esquema inesperado en su columna SUPER, considere asociar sus políticas de enmascaramiento directamente a la columna SUPER. Puede utilizar las funciones de información de tipo SUPER para comprobar los atributos y los tipos, y utilizar `OBJECT_TRANSFORM` para enmascarar los valores. Para obtener más información acerca de las funciones de información de tipo SUPER, consulte [Funciones de información acerca del tipo SUPER](c_Type_Info_Functions.md). ## Ejemplos **Asociación de políticas de enmascaramiento a las rutas SUPER** En el siguiente ejemplo, se asocian varias políticas de enmascaramiento a varias rutas de tipo SUPER en una columna. ``` CREATE TABLE employees ( col_person SUPER ); INSERT INTO employees VALUES ( json_parse(' { "name": { "first": "John", "last": "Doe" }, "age": 25, "ssn": "111-22-3333", "company": "Company Inc." } ') ), ( json_parse(' { "name": { "first": "Jane", "last": "Appleseed" }, "age": 34, "ssn": "444-55-7777", "company": "Organization Org." } ') ) ; GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC; -- Create the masking policies. -- This policy converts the given name to all uppercase letters. CREATE MASKING POLICY mask_first_name WITH(first_name TEXT) USING ( UPPER(first_name) ); -- This policy replaces the given name with the fixed string 'XXXX'. CREATE MASKING POLICY mask_last_name WITH(last_name TEXT) USING ( 'XXXX'::TEXT ); -- This policy rounds down the given age to the nearest 10. CREATE MASKING POLICY mask_age WITH(age INT) USING ( (FLOOR(age::FLOAT / 10) * 10)::INT ); -- This policy converts the first five digits of the given SSN to 'XXX-XX'. CREATE MASKING POLICY mask_ssn WITH(ssn TEXT) USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) ); -- Attach the masking policies to the employees table. ATTACH MASKING POLICY mask_first_name ON employees(col_person.name.first) TO PUBLIC; ATTACH MASKING POLICY mask_last_name ON employees(col_person.name.last) TO PUBLIC; ATTACH MASKING POLICY mask_age ON employees(col_person.age) TO PUBLIC; ATTACH MASKING POLICY mask_ssn ON employees(col_person.ssn) TO PUBLIC; -- Verify that your masking policies are attached. SELECT policy_name, TABLE_NAME, priority, input_columns, output_columns FROM svv_attached_masking_policy; policy_name | table_name | priority | input_columns | output_columns -----------------+------------+----------+-----------------------------------+----------------------------------- mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""] mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""] mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""] mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""] (4 rows) -- Observe the masking policies taking effect. SELECT col_person FROM employees ORDER BY col_person.age; -- This result is formatted for ease of reading. col_person -------------------------------- { "name": { "first": "JOHN", "last": "XXXX" }, "age": 20, "ssn": "XXX-XX-3333", "company": "Company Inc." } { "name": { "first": "JANE", "last": "XXXX" }, "age": 30, "ssn": "XXX-XX-7777", "company": "Organization Org." } ``` A continuación se muestran algunos ejemplos de asociaciones no válidas de políticas de enmascaramiento a rutas SUPER. ``` -- This attachment fails because there is already a policy -- with equal priority attached to employees.name.last, which is -- on the same SUPER path as employees.name. ATTACH MASKING POLICY mask_ssn ON employees(col_person.name) TO PUBLIC; ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority -- Create a masking policy that masks DATETIME objects. CREATE MASKING POLICY mask_date WITH(INPUT DATETIME) USING ( INPUT ); -- This attachment fails because SUPER type columns can't contain DATETIME objects. ATTACH MASKING POLICY mask_date ON employees(col_person.company) TO PUBLIC; ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super ``` A continuación, se ofrece un ejemplo de una política de enmascaramiento a una ruta SUPER que no existe. De forma predeterminada, Amazon Redshift resolverá la ruta hacia `NULL`. ``` ATTACH MASKING POLICY mask_first_name ON employees(col_person.not_exists) TO PUBLIC; SELECT col_person FROM employees LIMIT 1; -- This result is formatted for ease of reading. col_person ----------------------------------- { "name": { "first": "JOHN", "last": "XXXX" }, "age": 20, "ssn": "XXX-XX-3333", "company": "Company Inc.", "not_exists": null } ``` # Enmascaramiento dinámico y condicional de datos Puede enmascarar datos en el nivel de celda mediante la creación de políticas de enmascaramiento con expresiones condicionales en la expresión de enmascaramiento. Por ejemplo, puede crear una política de enmascaramiento que aplique diferentes máscaras a un valor, en función del valor de otra columna de esa fila. A continuación, se muestra un ejemplo de uso del enmascaramiento condicional de datos para crear y adjuntar una política de enmascaramiento que elabora parcialmente los números de tarjeta de crédito implicados en un fraude, al mismo tiempo que oculta completamente todos los demás números de tarjeta de crédito. Debe ser superusuario o tener el rol [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) para ejecutar este ejemplo. ``` --Create an analyst role. CREATE ROLE analyst; --Create a credit card table. The table contains an is_fraud boolean column, --which is TRUE if the credit card number in that row was involved in a fraudulent transaction. CREATE TABLE credit_cards (id INT, is_fraud BOOLEAN, credit_card_number VARCHAR(16)); --Create a function that partially redacts credit card numbers. CREATE FUNCTION REDACT_CREDIT_CARD (credit_card VARCHAR(16)) RETURNS VARCHAR(16) 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 partially redacts credit card numbers if the is_fraud value for that row is TRUE, --and otherwise blanks out the credit card number completely. CREATE MASKING POLICY card_number_conditional_mask WITH (fraudulent BOOLEAN, pan varchar(16)) USING (CASE WHEN fraudulent THEN REDACT_CREDIT_CARD(pan) ELSE Null END); --Attach the masking policy to the credit_cards/analyst table/role pair. ATTACH MASKING POLICY card_number_conditional_mask ON credit_cards (credit_card_number) USING (is_fraud, credit_card_number) TO ROLE analyst PRIORITY 100; ``` # Vistas del sistema de enmascaramiento de datos dinámico Los superusuarios, los usuarios con el rol `sys:operator` y los usuarios con el permiso ACCESS SYSTEM TABLE pueden acceder a las siguientes vistas del sistema relacionadas con DDM. + [SVV\$1MASKING\$1POLICY](r_SVV_MASKING_POLICY.md) Utilice SVV\$1MASKING\$1POLICY para ver todas las políticas de enmascaramiento creadas en el clúster o grupo de trabajo. + [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md) Utilice SVV\$1ATTACHED\$1MASKING\$1POLICY para ver todas las relaciones y los usuarios o los roles con políticas adjuntas a la base de datos conectada actualmente. + [SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG](SYS_APPLIED_MASKING_POLICY_LOG.md) Utilice SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG para rastrear la aplicación de políticas de enmascaramiento en consultas que hacen referencia a relaciones protegidas por DDM. A continuación, se muestran algunos ejemplos de la información que puede encontrar utilizando las vistas del sistema. ``` --Select all policies associated with specific users, as opposed to roles SELECT policy_name, schema_name, table_name, grantee FROM svv_attached_masking_policy WHERE grantee_type = 'user'; --Select all policies attached to a specific user SELECT policy_name, schema_name, table_name, grantee FROM svv_attached_masking_policy WHERE grantee = 'target_grantee_name' --Select all policies attached to a given table SELECT policy_name, schema_name, table_name, grantee FROM svv_attached_masking_policy WHERE table_name = 'target_table_name' AND schema_name = 'target_schema_name'; --Select the highest priority policy attachment for a given role SELECT samp.policy_name, samp.priority, samp.grantee, smp.policy_expression FROM svv_masking_policy AS smp JOIN svv_attached_masking_policy AS samp ON samp.policy_name = smp.policy_name WHERE samp.grantee_type = 'role' AND samp.policy_name = mask_get_policy_for_role_on_column( 'target_schema_name', 'target_table_name', 'target_column_name', 'target_role_name') ORDER BY samp.priority desc LIMIT 1; --See which policy a specific user will see on a specific column in a given relation SELECT samp.policy_name, samp.priority, samp.grantee, smp.policy_expression FROM svv_masking_policy AS smp JOIN svv_attached_masking_policy AS samp ON samp.policy_name = smp.policy_name WHERE samp.grantee_type = 'role' AND samp.policy_name = mask_get_policy_for_user_on_column( 'target_schema_name', 'target_table_name', 'target_column_name', 'target_user_name') ORDER BY samp.priority desc; --Select all policies attached to a given relation. SELECT policy_name, schema_name, relation_name, database_name FROM sys_applied_masking_policy_log WHERE relation_name = 'relation_name' AND schema_name = 'schema_name'; ``` # 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\$1EXPLAIN\$1DDM pueden ver las políticas de enmascaramiento aplicadas en los resultados de EXPLAIN. Los usuarios no tienen el permiso SYS\$1EXPLAIN\$1DDM 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](r_EXPLAIN.md). + 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](t_rls.md). + Cuando utilice el comando [COPY](r_COPY.md) 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](copy-parameters-column-mapping.md). + 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 + 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. + No puede utilizar políticas de enmascaramiento dinámico de datos 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. Al intentar agregar la relación a un recurso compartido de datos se producirá el siguiente error en el clúster o el espacio de nombres del productor: ``` or a relation dependent on it is protected by a masking policy and cannot be added to a datashare ``` Si adjunta una política de enmascaramiento a una relación del productor y la relación ya está incluida en un recurso compartido de datos, al intentar consultar la relación en el lado del consumidor, se producirá el siguiente error: ``` cross-cluster query of the masked relation is not supported. ``` Puede desactivar el DDM para los recursos compartidos de datos mediante el comando ALTER TABLE con el parámetro MASKING OFF FOR DATASHARES. Para obtener más información, consulte [ALTER TABLE](r_ALTER_TABLE.md). + 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 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) en la *Guía de administración de Amazon Redshift*. Para obtener información sobre el comando ALTER USER, consulte [ALTER USER](r_ALTER_USER.md). + 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](r_CREATE_VIEW.md). 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](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [SHOW](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) y [RESET](r_RESET.md). 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](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings). **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. # Ejemplo completo de enmascaramiento de datos dinámico 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 [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) 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; ``` # Permisos acotados Los permisos limitados le permiten conceder permisos a un usuario o rol en todos los objetos de un tipo dentro de una base de datos o un esquema. Los usuarios y roles con permisos limitados tienen los permisos especificados en todos los objetos actuales y futuros de la base de datos o del esquema. Puede ver el alcance de los permisos limitados en el nivel de base de datos en [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md). Puede ver el alcance de los permisos limitados en el nivel de esquema en [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md). Para obtener más información sobre la aplicación de permisos acotados, consulte [GRANT](r_GRANT.md) y [REVOKE](r_REVOKE.md). # Consideraciones para utilizar permisos acotados Cuando utilice permisos acotados, tenga en cuenta lo siguiente: + Puede utilizar permisos acotados para conceder o revocar permisos en el ámbito de una base de datos o un esquema a o desde un usuario o rol especificados. + No se puede conceder un permiso específico a grupos de usuarios. + Al conceder o revocar permisos acotados, se modifican los permisos de todos los objetos actuales y futuros del ámbito. + Los permisos limitados y lo permisos en el nivel de objeto operan de forma independiente. Por ejemplo, un usuario mantendrá los permisos en una tabla en los dos casos siguientes. + Al usuario se le concede el permiso SELECT en la tabla schema1.table1 y el permiso SELECT limitado en schema1. A continuación, el usuario revoca SELECT de todas las tablas del esquema schema1. El usuario retiene SELECT en schema1.table1. + Al usuario se le concede el permiso SELECT en la tabla schema1.table1 y el permiso SELECT limitado en schema1. A continuación, el usuario revoca SELECT de schema1.table1. El usuario retiene SELECT en schema1.table1. + Para conceder o revocar permisos acotados, debe cumplir uno de los siguientes criterios: + Superusuarios + Usuarios con la opción de conceder ese permiso Para obtener más información sobre las opciones de concesión, vaya al parámetro WITH GRANT OPTION en [GRANT](r_GRANT.md). + Los permisos acotados solo se pueden conceder o revocar a los objetos de la base de datos conectada o a las bases de datos importadas desde un recurso compartido de datos. + Puede usar los permisos acotados para establecer los permisos predeterminados en una base de datos creada a partir de un recurso compartido de datos. Un usuario de un recurso compartido de datos del lado del consumidor al que se le conceden permisos acotados en una base de datos compartida los recibirá automáticamente para cualquier objeto nuevo que se añada al recurso compartido de datos del lado del productor. + Los productores pueden conceder permisos específicos sobre los objetos dentro de un esquema a un recurso compartido de datos. (vista previa)