Notas de uso - Amazon Redshift
Notas de uso para el control de acceso de nivel de columnaNotas de uso para conceder el permiso ASSUMEROLENotas de uso para conceder permisos de machine learning

Notas de uso

Para conceder privilegios en un objeto, debe cumplir con uno de los siguientes criterios:

  • Ser el propietario del objeto.

  • Ser un superusuario.

  • Tener un privilegio concedido para ese objeto y privilegio.

Por ejemplo, el siguiente comando permite al usuario HR realizar comandos SELECT en la tabla de empleados y conceder y revocar el mismo privilegio para otros usuarios:

grant select on table employees to HR with grant option;

HR no puede conceder privilegios para ninguna operación que no sea SELECT o en ninguna tabla que no sea la de empleados.

Como otro ejemplo, el siguiente comando permite al usuario HR ejecutar comandos ALTER en la tabla de empleados y conceder y revocar el mismo privilegio para otros usuarios.

grant ALTER on table employees to HR with grant option;

HR no puede conceder privilegios para ninguna otra operación que no sea ALTER ni sobre ninguna otra tabla que no sea employees.

Tener privilegios concedidos de una vista no implica tener privilegios en las tablas subyacentes. De manera similar, tener privilegios concedidos de un esquema no implica tener privilegios en las tablas del esquema. En su lugar, debe conceder acceso a las tablas subyacentes de manera explícita.

Para otorgar privilegios a una tabla AWS Lake Formation, el rol IAM asociado con el esquema externo de la tabla debe tener permiso para otorgar privilegios en la tabla externa. El siguiente ejemplo crea un esquema externo con un rol IAM myGrantor asociado. El rol IAM myGrantor tiene el permiso para otorgar permisos a otros. El comando GRANT utiliza los permisos del rol myGrantor IAM que está asociado al esquema externo para otorgar permisos al rol IAM myGrantee.

create external schema mySchema
from data catalog
database 'spectrum_db'
iam_role 'arn:aws:iam::123456789012:role/myGrantor'
create external database if not exists;

grant select
on external table mySchema.mytable
to iam_role 'arn:aws:iam::123456789012:role/myGrantee';

Si concede privilegios GRANT ALL a un rol de IAM, los privilegios individuales se conceden en el catálogo de datos relacionado y habilitado para Lake Formation. Por ejemplo, el siguiente permiso GRANT ALL da lugar a los privilegios individuales concedidos (SELECT, ALTER, DROP, DELETE e INSERT) que se muestran en la consola de Lake Formation.

grant all
on external table mySchema.mytable
to iam_role 'arn:aws:iam::123456789012:role/myGrantee';

Los superusuarios pueden obtener acceso a todos los objetos independientemente de los comandos GRANT y REVOKE que establecen privilegios de objeto.

Notas de uso para el control de acceso de nivel de columna

Las siguientes notas de uso se aplican a los privilegios del nivel de la columna en tablas y vistas de Amazon Redshift. Estas notas describen tablas; las mismas notas se aplican a las vistas a menos que anotemos explícitamente una excepción.

  • En una tabla de Amazon Redshift, solo se pueden conceder los privilegios SELECT y UPDATE en el nivel de la columna. En una vista de Amazon Redshift, solo se puede conceder el privilegio SELECT en el nivel de la columna.

  • La palabra clave ALL es sinónimo de una combinación de los privilegios SELECT y UPDATE cuando se utiliza en el contexto de GRANT en el nivel de columna en una tabla.

  • Si no tiene el privilegio SELECT en todas las columnas de una tabla, al realizar una operación SELECT * solo se devolverán las columnas a las que tiene acceso. Cuando se utiliza una vista, la operación SELECT * intenta acceder a todas las columnas de la vista. Si no tiene permiso para acceder a todas las columnas, estas consultas producen un error de permiso denegado.

  • SELECT * no se expande solo a columnas accesibles en los siguientes casos:

    • No puede crear una vista normal solo con columnas accesibles mediante SELECT *.

    • No puede crear una vista materializada solo con columnas accesibles mediante SELECT *.

  • Si tiene privilegios SELECT o UPDATE en una tabla o vista y agrega una columna, seguirá teniendo los mismos privilegios en la tabla o vista y, por tanto, en todas sus columnas.

  • Sólo el propietario de una tabla o un superusuario pueden conceder privilegios de nivel de columna.

  • No se admite la cláusula WITH GRANT OPTION para privilegios de nivel de columna.

  • No puede mantener el mismo privilegio tanto en el nivel de tabla como en el nivel de columna. Por ejemplo, el usuario data_scientist no puede tener tanto el privilegio SELECT en la tabla employee como el privilegio SELECT en la columna employee.department. Tenga en cuenta los siguientes resultados al conceder el mismo privilegio a una tabla y a una columna dentro de la tabla:

    • Si un usuario tiene un privilegio de nivel de tabla en una tabla, conceder el mismo privilegio en el nivel de columna no tiene ningún efecto.

    • Si un usuario tiene un privilegio de nivel de tabla en una tabla, al revocar el mismo privilegio para una o varias columnas de la tabla se devuelve un error. En su lugar, revoque el privilegio en el nivel de tabla.

    • Si un usuario tiene un privilegio de nivel de columna, conceder el mismo privilegio en el nivel de tabla devuelve un error.

    • Si un usuario tiene un privilegio de nivel de columna, al revocar el mismo privilegio en el nivel de tabla se revocarán los privilegios de columna y tabla para todas las columnas de la tabla.

  • No se pueden conceder privilegios de nivel de columna en vistas de enlace en tiempo de ejecución.

  • Debe tener el privilegio SELECT de nivel de tabla en las tablas base para crear una vista materializada. Incluso si tiene privilegios de nivel de columna en columnas específicas, no puede crear una vista materializada solo en esas columnas. No obstante, puede conceder el privilegio SELECT a las columnas de una vista materializada, similar a las vistas normales.

  • Para buscar concesiones de privilegios de nivel de columna, utilice la vista PG_ATTRIBUTE_INFO .

Notas de uso para conceder el permiso ASSUMEROLE

Las siguientes notas de uso se aplican cuando se concede el permiso ASSUMEROLE en Amazon Redshift.

El permiso ASSUMEROLE se utiliza para controlar los permisos de acceso de rol de IAM para usuarios, roles y grupos de base de datos en comandos como COPY, UNLOAD, EXTERNAL FUNCTION o CREATE MODEL. Después de conceder el permiso ASSUMEROLE a un usuario, un rol o un grupo para un rol de IAM, el usuario, el rol o el grupo puede asumir ese rol cuando se ejecute el comando. El permiso ASSUMEROLE permite conceder acceso a los comandos adecuados según sea necesario.

Solo un superusuario de base de datos puede conceder o revocar el permiso ASSUMEROLE para usuarios, roles y grupos. Un superusuario siempre retiene el permiso ASSUMEROLE.

Para habilitar el uso del permiso ASSUMEROLE por parte de usuarios, roles y grupos, un superusuario realiza las dos acciones siguientes:

  • Ejecuta una vez la siguiente instrucción en el clúster:

    revoke assumerole on all from public for all;

  • Concede el permiso ASSUMEROLE a usuarios, roles y grupos para los comandos adecuados.

Puede especificar el encadenamiento de roles en la cláusula ON cuando concede el permiso ASSUMEROLE. Utiliza comas para separar los roles en una cadena de roles; por ejemplo, Role1,Role2,Role3. Si se especificó el encadenamiento de roles durante la concesión del permiso ASSUMEROLE, deberá especificar la cadena de roles cuando realice operaciones concedidas por el permiso ASSUMEROLE. No se pueden especificar roles individuales en la cadena de roles cuando se realizan operaciones concedidas por el permiso ASSUMEROLE. Por ejemplo, si a un usuario, un rol o un grupo se le concede la cadena de roles Role1,Role2,Role3, no se puede especificar solo Role1 para realizar operaciones.

Si un usuario intenta realizar una operación COPY, UNLOAD, EXTERNAL FUNCTION o CREATE MODEL, y no se le ha concedido el permiso ASSUMEROLE, aparecerá un mensaje similar al siguiente.

ERROR:  User awsuser does not have ASSUMEROLE permission on IAM role "arn:aws:iam::123456789012:role/RoleA" for COPY

Para enumerar los usuarios a los que se les concedió acceso a roles de IAM y comandos a través del permiso ASSUMEROLE, consulte HAS_ASSUMEROLE_PRIVILEGE. Para enumerar los roles de IAM y los permisos de comando que se han concedido a un usuario que usted especifica, consulte PG_GET_IAM_ROLE_BY_USER. Para enumerar los usuarios, los roles y los grupos a los que se les concedió acceso a un rol de IAM que usted especificó, consulte PG_GET_GRANTEE_BY_IAM_ROLE.

Notas de uso para conceder permisos de machine learning

No puede conceder ni revocar directamente permisos relacionados con una función de ML. Una función de ML pertenece a un modelo de ML y los permisos se controlan mediante el modelo. En su lugar, puede conceder permisos relacionados con el modelo de ML. En el siguiente ejemplo, se muestra cómo conceder permisos a todos los usuarios para ejecutar la función de ML asociada al modelo customer_churn.

GRANT EXECUTE ON MODEL customer_churn TO PUBLIC;

También puede conceder todos los permisos a un usuario para el modelo de ML customer_churn.

GRANT ALL on MODEL customer_churn TO ml_user;

Se producirá un error en la concesión del permiso EXECUTE relacionado con una función de ML si existe una función de ML en el esquema, aunque dicha función de ML ya disponga del permiso EXECUTE mediante GRANT EXECUTE ON MODEL. Recomendamos utilizar un esquema independiente cuando utilice el comando CREATE MODEL para mantener las funciones de ML en un esquema independiente por sí mismas. En el siguiente ejemplo, se muestra cómo hacerlo.

CREATE MODEL ml_schema.customer_churn
FROM customer_data
TARGET churn
FUNCTION ml_schema.customer_churn_prediction
IAM_ROLE default
SETTINGS (
 S3_BUCKET 'amzn-s3-demo-bucket'
);