Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Prácticas recomendadas, consideraciones y limitaciones de Lake Formation Utilice esta sección para encontrar rápidamente las prácticas recomendadas, las consideraciones y las limitaciones de AWS Lake Formation. Consulte [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/lake-formation.html#limits_lake-formation) para conocer el número máximo de recursos u operaciones de servicio de su Cuenta de AWS. **Topics** + [ # Prácticas recomendadas y consideraciones para uso compartido de datos entre cuentas ](cross-account-notes.md) + [ # Limitaciones de los roles vinculados a servicios ](service-linked-role-limitations.md) + [ # Limitaciones de acceso a datos entre regiones ](x-region-considerations.md) + [ # Vistas, consideraciones y limitaciones del catálogo de datos ](views-notes.md) + [ # Limitaciones de filtrado de datos ](data-filtering-notes.md) + [ # Consideraciones y limitaciones del modo de acceso híbrido ](notes-hybrid.md) + [ # Limitaciones para llevar los datos del almacén de datos de Amazon Redshift al AWS Glue Data Catalog ](notes-ns-catalog.md) + [ # Limitaciones de integración del catálogo de S3 Tables ](notes-s3-catalog.md) + [ # Consideraciones y limitaciones del uso compartido de datos del almacén de metadatos de Hive ](notes-hms.md) + [ # Limitaciones de uso compartido de datos de Amazon Redshift ](notes-rs-datashare.md) + [ # Limitaciones de la integración de IAM Identity Center ](identity-center-lf-notes.md) + [ # Prácticas recomendadas y consideraciones sobre el control de acceso basado en etiquetas de Lake Formation ](lf-tag-considerations.md) + [ # Consideraciones, limitaciones y regiones compatibles para el control de acceso basado en atributos ](abac-considerations.md) # Prácticas recomendadas y consideraciones para uso compartido de datos entre cuentas Las capacidades multicuenta de Lake Formation permiten a los usuarios compartir de forma segura lagos de datos distribuidos entre varias AWS organizaciones o directamente con los directores de IAM en otra cuenta Cuentas de AWS, lo que proporciona un acceso detallado a los metadatos del catálogo de datos y a los datos subyacentes. Tenga en cuenta las siguientes prácticas recomendadas en el uso compartido de datos entre cuentas de Lake Formation: + No hay límite en cuanto a la cantidad de permisos de Lake Formation que puede conceder a los directores por AWS cuenta propia. Sin embargo, Lake Formation usa la capacidad AWS Resource Access Manager (AWS RAM) para las concesiones entre cuentas que su cuenta puede realizar con el método de recurso indicado. Para maximizar la AWS RAM capacidad, sigue estas prácticas recomendadas para el método de recurso indicado: + Usa el nuevo modo de concesión multicuenta (**versión 3** y superior en la **configuración de la versión multicuenta**) para compartir un recurso con una persona externa Cuenta de AWS. Para obtener más información, consulte [Actualización de los ajustes de la versión entre cuentas para compartir datos](optimize-ram.md). + Organice las AWS cuentas en organizaciones y conceda permisos a las organizaciones o unidades organizativas. Una concesión a una organización o unidad organizativa cuenta como una concesión. La concesión a organizaciones o unidades organizativas también elimina la necesidad de aceptar una AWS Resource Access Manager (AWS RAM) invitación a compartir recursos para obtener la subvención. Para obtener más información, consulte [Acceso y visualización de tablas y bases de datos compartidas del Catálogo de datos](viewing-shared-resources.md). + En lugar de conceder permisos en muchas tablas individuales de una base de datos, utilice el comodín especial **Todas las tablas** para conceder permisos en todas las tablas de la base de datos. La concesión en **Todas las tablas** se considera una única concesión. Para obtener más información, consulte [Concesión de permisos sobre los recursos del Catálogo de datos](granting-catalog-permissions.md). **nota** Para obtener más información sobre cómo solicitar un límite superior para el número de recursos compartidos AWS RAM, consulte [las cuotas de AWS servicio](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) en el *Referencia general de AWS*. + Debe crear un enlace de recursos a una base de datos compartida para que dicha base de datos aparezca en los editores de consultas Amazon Athena y en Amazon Redshift Spectrum. Del mismo modo, para poder consultar tablas compartidas con Athena y Redshift Spectrum, debe crear enlaces de recursos a las tablas. Los enlaces de recursos aparecen entonces en la lista de tablas de los editores de consultas. En lugar de crear enlaces de recursos para hace consultas en muchas tablas por separado, puede utilizar el comodín **Todas las tablas** para conceder permisos en todas las tablas de una base de datos. A continuación, cuando cree un enlace de recursos para esa base de datos y lo seleccione en el editor de consultas, tendrá acceso a todas las tablas de esa base de datos para su consulta. Para obtener más información, consulte [Creación de enlaces de recursos](creating-resource-links.md). + Cuando comparte recursos directamente con entidades principales de otra cuenta, es posible que la entidad principal de IAM de la cuenta de destinatario no tenga permiso para crear enlaces de recursos para poder consultar las tablas compartidas mediante Athena y Amazon Redshift Spectrum. En lugar de crear un enlace de recursos para cada tabla compartida, el administrador del lago de datos puede crear una base de datos de marcadores de posición y conceder permisos de `CREATE_TABLE` al grupo `ALLIAMPrincipal`. A continuación, todas las entidades principales de IAM de la cuenta de destinatario pueden crear enlaces de recursos en la base de datos del marcador de posición y empezar a consultar las tablas compartidas. Consulte el comando CLI de ejemplo para conceder permisos a `ALLIAMPrincipals` en [Concesión de permisos de base de datos mediante el método de recurso con nombre](granting-database-permissions.md). + Cuando se otorgan permisos entre cuentas directamente a una entidad principal, solo el destinatario puede verlos. El administrador del lago de datos de la cuenta de AWS del destinatario no puede ver estos permisos concedidos directamente. + Athena y Redshift Spectrum admiten el control de acceso a nivel de columna, pero solo para la inclusión, no para la exclusión. Los trabajos de ETL de AWS Glue no admiten el control de acceso a nivel de columna. + Cuando se comparte un recurso con su AWS cuenta, solo puede conceder permisos sobre el recurso a los usuarios de su cuenta. No puedes conceder permisos sobre el recurso a otras AWS cuentas, a organizaciones (ni siquiera a la tuya) ni al `IAMAllowedPrincipals` grupo. + No puede conceder `DROP` ni `Super` sobre una base de datos a una cuenta externa. + Revoque los permisos entre cuentas antes de eliminar una base de datos o una tabla. De lo contrario, debe eliminar los recursos compartidos huérfanos en AWS Resource Access Manager. **Véase también** [Prácticas recomendadas y consideraciones sobre el control de acceso basado en etiquetas de Lake Formation](lf-tag-considerations.md) [`CREATE_TABLE`](lf-permissions-reference.md#perm-create-table) en [Referencia de permisos de Lake Formation](lf-permissions-reference.md) para más normas y limitaciones de acceso entre cuentas. # Limitaciones de los roles vinculados a servicios Un rol vinculado a un servicio es un tipo especial de rol de IAM al que se vincula directamente. AWS Lake Formation Esta función tiene permisos predefinidos que permiten a Lake Formation realizar acciones en su nombre en todos AWS los servicios. Las siguientes limitaciones se aplican cuando se utiliza un rol vinculado a un servicio (SLR) para registrar ubicaciones de datos en Lake Formation. + Las políticas de los roles vinculados a servicios no se pueden modificar una vez creadas. + Un rol vinculado a un servicio no admite el uso compartido de recursos de catálogo cifrados entre cuentas. Los recursos cifrados requieren permisos AWS KMS clave específicos. Los roles vinculados a servicios tienen permisos predefinidos que no incluyen la posibilidad de trabajar con recursos de catálogo cifrados en todas las cuentas. + Al registrar varias ubicaciones de Amazon S3, el uso de un rol vinculado al servicio puede hacer que se superen rápidamente los límites de la política de IAM. Esto se debe a que, en el caso de los roles vinculados a un servicio, AWS redacta la política por ti y se amplía en un bloque grande que incluye todos tus registros. Puede redactar políticas administradas por el cliente de manera más eficiente, distribuir los permisos entre varias políticas o usar diferentes roles para diferentes regiones. + Amazon EMR en EC2 no puede acceder a los datos cuando se registran las ubicaciones de datos con roles vinculados a servicios. + Las operaciones de roles vinculados al servicio eluden tus políticas de control de servicios. AWS + Cuando se registran ubicaciones de datos con un rol vinculado a un servicio, se actualizan las políticas de IAM con coherencia final. Para obtener más información, consulte la documentación sobre [Solución de problemas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html#troubleshoot_general_eventual-consistency) en la Guía del usuario de IAM. + No puede establecer `SET_CONTEXT = TRUE` en la configuración del lago de datos de Lake Formation cuando se utilizan roles vinculados a servicios e IAM Identity Center. La razón es que los roles vinculados a servicios tienen políticas de confianza inmutables que son incompatibles con la propagación de identidades de confianza que se requiere para la auditoría de `SetContext` con las entidades principales de IAM Identity Center. # Limitaciones de acceso a datos entre regiones Lake Formation admite las consultas a tablas de catálogo de datos entre Regiones de AWS. Puede acceder a los datos de una región desde otras regiones mediante Amazon Athena Amazon EMR y AWS Glue ETL creando enlaces de recursos en otras regiones que apunten a las bases de datos y tablas de origen. Con el acceso a las tablas entre regiones, puede acceder a los datos de todas las regiones sin copiar los datos subyacentes o los metadatos en el Catálogo de datos. Se aplican las siguientes limitaciones al acceso a las tablas entre regiones. + Lake Formation no admite la consulta de tablas del Catálogo de datos de otra región mediante Amazon Redshift Spectrum. + En la consola de Lake Formation, las vistas de bases de datos y tablas no muestran los nombres de las bases de datos o tablas de la región de origen. + Para ver la lista de tablas de una base de datos compartida de otra región, primero debe crear un enlace de recursos a la base de datos compartida, luego seleccionar el enlace de recursos y elegir **Ver tablas**. + Lake Formation no admite llamadas de enlaces de recursos entre regiones realizadas por usuarios de SAML. + La característica entre regiones de Lake Formation no implica cargos adicionales por la transferencia de datos. # Vistas, consideraciones y limitaciones del catálogo de datos Las siguientes consideraciones y limitaciones se aplican a las vistas del catálogo de datos. + No puede crear una vista del Catálogo de datos desde la consola de Lake Formation. Puede crear vistas mediante el SDK AWS CLI o el SDK. + Puede crear vistas del Catálogo de datos a partir de 10 tablas. Es un límite invariable. Las tablas de referencia subyacentes de una vista pueden pertenecer a la misma base de datos o a bases de datos diferentes dentro de la misma AWS cuenta. + Para conocer las consideraciones y limitaciones adicionales específicas de la creación de vistas del Catálogo de datos con Redshift, consulte la sección [Vistas, consideraciones y limitaciones del Catálogo de datos](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html#data-catalog-views-considerations) de la Guía para desarrolladores de bases de datos de Amazon Redshift. Para Athena, consulte la sección [Vistas, consideraciones y limitaciones del Catálogo de datos](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html#views-glue-limitations) de la Guía del usuario de Amazon Athena. + Puede crear vistas del Catálogo de datos en tablas registradas en Lake Formation tanto en el modo de acceso híbrido como en el modo Lake Formation. Cuando se utilicen las vistas del Catálogo de datos con el modo de acceso híbrido de Lake Formation, se recomienda asegurarse de que las entidades principales que consuman las vistas tengan habilitados permisos de Lake Formation para las tablas base a las que se hace referencia en la vista sin conceder acceso. Esto garantiza que las tablas base no se revelen a los consumidores mediante los permisos de AWS Glue IAM. + No hay restricciones en la versión para compartir vistas entre cuentas. + Las vistas se versionan de modo idéntico que las tablas del Catálogo de datos cuando se usa la instrucción `ALTER VIEW` para un dialecto de vista ya creado. No se puede restaurar una vista anterior porque la versión de la vista cambia con los cambios de datos subyacentes. Al eliminar una versión de vista, esta pasará de forma predeterminada a la siguiente versión más reciente disponible. Al cambiar la versión de la vista, asegúrese de que los datos estén sincronizados con el esquema de la versión de vista seleccionada. + No se introduce ningún catálogo de APIs datos nuevo. Los existentes `CreateTable` `DeleteTable` y `UpdateTable` `GetTable` APIs se actualizan. + Amazon Redshift siempre crea vistas con columnas varchar a partir de tablas con cadenas. Debe convertir columnas de cadenas en varchar con una longitud explícita al añadir dialectos de otros motores. + Al conceder permisos de lago de datos a `All tables` dentro de una base de datos, el beneficiario tendrá permisos en todas las tablas y vistas de la base de datos. + No se pueden crear vistas: + Que hagan referencia a otras vistas. + Cuando la tabla de referencia sea un enlace de recurso. + Cuando la tabla de referencia esté en otra cuenta. + De almacenes de metadatos externos de Hive. + Las funciones de definición multicuenta no son compatibles con las vistas de Redshift Spectrum Dialect. + No se admiten los enlaces de recursos para el dialecto de Athena en el editor de consultas de Athena. Para utilizar funciones de definición multicuenta para el dialecto de Atenea, añada la cuenta que aloja las tablas base como fuente de datos en Athena. # Limitaciones de filtrado de datos Al conceder permisos de Lake Formation en una tabla del Catálogo de datos, puede incluir especificaciones de filtrado de datos para restringir el acceso a determinados datos en los resultados de las consultas y en los motores integrados con Lake Formation. Lake Formation utiliza el filtrado de datos para ofrecer una seguridad a nivel de columna, fila y celda. Puede definir y aplicar filtros de datos en las columnas anidadas si los datos de origen contienen estructuras anidadas. ## Notas y restricciones para el filtrado a nivel de columna Hay tres formas de especificar el filtrado de columnas: + Mediante el uso de filtros de datos + Mediante el uso de un filtrado de columnas simple o un filtrado de columnas anidadas. + TAGsMediante el uso de. El filtrado de columnas simple solo especifica una lista de columnas para incluir o excluir. Tanto la consola Lake Formation como la API AWS CLI admiten un filtrado de columnas sencillo. Para ver un ejemplo, consulta [Grant with Simple Column Filtering](granting-table-permissions.md#simple-column-filter-example). Las siguientes notas y restricciones corresponden al filtrado de columnas: + AWS Glue La versión 5.0 o superior admite un control de acceso detallado a través de Lake Formation solo para las tablas Apache Hive y Apache Iceberg. + Para conceder `SELECT` con la opción de concesión y el filtrado de columnas, debe usar una lista de inclusión, no una lista de exclusiones. Sin la opción de conceder, puede utilizar listas de inclusión o exclusión. + Para conceder `SELECT` en una tabla con filtrado de columnas, debe haber obtenido la autorización `SELECT` en la tabla con la opción de concesión y sin restricciones de filas. Debe tener acceso a todas las filas. + Si concede `SELECT` con la opción de concesión y filtrado de columnas a una entidad principal de su cuenta, dicha entidad principal deberá especificar el filtrado de columnas para las mismas columnas o un subconjunto de las columnas beneficiarias cuando conceda a otra entidad principal. Si concede `SELECT` con la opción de concesión y filtrado de columnas a una cuenta externa, el administrador del lago de datos de la cuenta externa puede conceder `SELECT` en todas las columnas a otra entidad principal de su cuenta. Sin embargo, incluso con `SELECT` en todas las columnas, esa entidad principal tendrá visibilidad solo en las columnas concedidas a la cuenta externa. + No puede aplicar el filtrado de columnas a las claves de partición. + A una entidad principal con el permiso `SELECT` sobre un subconjunto de columnas de una tabla no se le puede conceder el permiso `ALTER`, `DROP`, `DELETE` o `INSERT` sobre esa tabla. Para una entidad principal con el permiso `ALTER`, `DROP`, `DELETE` o `INSERT` en una tabla, si concede el permiso `SELECT` con filtrado de columnas, no tiene ningún efecto. Las siguientes notas y restricciones se aplican al filtrado de columnas anidadas: + Puede incluir o excluir cinco niveles de campos anidados en un filtro de datos. **Example** Col1.Col1\$11.Col1\$11\$11.Col1\$11\$11\$11.Col1\$11\$11\$11\$11 + No puede aplicar el filtrado de columnas a los campos anidados dentro de las columnas de partición. + Si el esquema de la tabla contiene un nombre de columna de nivel superior («cliente»).» dirección») que tiene el mismo patrón de representación de un campo anidado dentro de un filtro de datos (una columna anidada con un nombre de columna de nivel superior `customer` y un nombre de campo anidado `address` se especifica como `"customer"."address"` en un filtro de datos), no puede especificar explícitamente el acceso a la columna de nivel superior o al campo anidado, ya que ambos se representan con el mismo patrón en las listas. inclusion/exclusion Esto es ambiguo y Lake Formation no puede resolverlo si especifica la columna de nivel superior o el campo anidado. + Si una columna de nivel superior o un campo anidado contiene comillas dobles dentro del nombre, debe incluir una segunda comilla doble cuando especifique el acceso a un campo anidado en la lista de inclusión y exclusión de un filtro de celdas de datos. **Example** Ejemplo de nombre de columna anidado con comillas dobles: `a.b.double"quote` **Example** Ejemplo de representación de columna anidada dentro de un filtro de datos: ` "a"."b"."double""quote"` ## Limitaciones de filtrado por celdas Tenga en cuenta las siguientes notas y restricciones para el filtrado a nivel de fila y a nivel de celda: + La seguridad a nivel de celda no se admite en las columnas, vistas y enlaces de recursos anidados. + Todas las expresiones que se admiten en las columnas de nivel superior también se admiten en las columnas anidadas. Sin embargo, **NO** se debe hacer referencia a los campos anidados de las columnas de partición al definir expresiones anidadas a nivel de fila. + La seguridad a nivel de celda está disponible en todas las regiones cuando se utiliza la versión 3 del motor Athena o Amazon Redshift Spectrum. Para otros servicios, la seguridad a nivel de celda solo está disponible en las regiones mencionadas en la [Regiones admitidas](supported-regions.md). + No se admiten las instrucciones `SELECT INTO`. + Los tipos de datos `array` y `map` no se admiten en las expresiones de filtro de filas. Solo se admite el tipo `struct`. + No hay ningún límite para el número de filtros de datos que se pueden definir en una tabla, pero existe un límite de 100 filtros de datos para una sola entidad principal en una tabla. + Para aplicar un filtro de datos con una expresión de filtro de filas, debe tener `SELECT` con la opción de conceder en todas las columnas de la tabla. Esta restricción no se aplica a los administradores de cuentas externas cuando la concesión se hizo a la cuenta externa. + Si una entidad principal es miembro de un grupo y tanto la entidad principal como el grupo tienen concedidos permisos sobre un subconjunto de filas, los permisos efectivos de fila de la entidad principal son la unión de los permisos de la entidad principal y los permisos del grupo. + Los siguientes nombres de columna están restringidos en una tabla para el filtrado a nivel de fila y de celda: + ctid + oid + xmin + cmin + xmax + cmax + tableoid + insertxid + deletexid + importoid + redcatuniqueid + Si aplica la expresión de filtro de todas las filas a una tabla de forma simultánea con otras expresiones de filtro con predicados, la expresión de todas las filas prevalecerá sobre todas las demás expresiones de filtro. + Cuando se conceden permisos en un subconjunto de filas a una AWS cuenta externa y el administrador del lago de datos de la cuenta externa concede esos permisos a un principal de esa cuenta, el predicado de filtro efectivo del principal es la intersección del predicado de la cuenta y cualquier predicado que se haya otorgado directamente al principal. Por ejemplo, si la cuenta tiene permisos de fila con el predicado `dept='hr'` y a la entidad principal se le concedió por separado permiso para `country='us'`, la entidad principal solo tiene acceso a las filas con `dept='hr'` y `country='us'`. Para obtener más información sobre el filtrado de celdas, consulte [Filtrado de datos y seguridad de celda en Lake Formation](data-filtering.md). Para conocer las consideraciones y limitaciones a la hora de consultar tablas con Amazon Redshift Spectrum con políticas de seguridad de filas, consulte [Consideraciones y limitaciones sobre el uso de las políticas de RLS](https://docs.aws.amazon.com/redshift/latest/dg/t_rls_usage.html) en la Guía para desarrolladores de bases de datos de Amazon Redshift. # Consideraciones y limitaciones del modo de acceso híbrido El modo de acceso híbrido proporciona la flexibilidad de habilitar selectivamente los permisos de Lake Formation para las bases de datos y tablas de su AWS Glue Data Catalog.
 Con el modo de acceso híbrido, ahora tiene una ruta incremental que le permite establecer los permisos de Lake Formation para un conjunto específico de usuarios sin interrumpir las políticas de permisos de otros usuarios o cargas de trabajo existentes. Las consideraciones y limitaciones indicadas a continuación se aplican al modo de acceso híbrido. **Limitaciones** + **Actualizar el registro de ubicaciones de Amazon S3**: no es posible editar los parámetros de una ubicación registrada en Lake Formation mediante un rol vinculado a un servicio. + **Opción de incluir al utilizar etiquetas LF**: cuando puede conceder permisos de Lake Formation utilizando etiquetas LF, puede incluir entidades principales para aplicar los permisos de Lake Formation como paso consecutivo eligiendo bases de datos y tablas que tengan etiquetas LF adjuntas. + **Acceso en modo de acceso híbrido**: el acceso en modo de acceso híbrido en Lake Formation está limitado a los usuarios con permisos de administrador de lago de datos o de administrador de solo lectura. + **Incluir entidades principales**: actualmente, solo un rol de administrador del lago de datos puede incluir a las entidades principales en los recursos. + **Incluir todas las tablas de una base de datos**: en concesiones entre cuentas, al conceder permisos e incluir todas las tablas de una base de datos, también es necesario incluir la base de datos para que los permisos funcionen. **Consideraciones** + **Actualización de la ubicación de Amazon S3 registrada en Lake Formation al modo de acceso híbrido**: no recomendamos convertir una ubicación de datos de Amazon S3 que ya esté registrada en Lake Formation a un modo de acceso híbrido, aunque se puede hacer. + **Comportamientos de la API cuando se registra una ubicación de datos en modo de acceso híbrido** + CreateTable — La ubicación se considera registrada en Lake Formation independientemente del indicador del modo de acceso híbrido y del estado de suscripción. Por lo tanto, el usuario necesita el permiso de ubicación de datos para crear una tabla. + CreatePartition/BatchCreatePartitions/UpdatePartitions(cuando la ubicación de la partición se actualiza para que apunte a la ubicación registrada en el modo híbrido): la ubicación de Amazon S3 se considera registrada en Lake Formation, independientemente del indicador del modo de acceso híbrido y del estado de activación. Así, el usuario necesita el permiso de localización de datos para crear o actualizar una base de datos. + CreateDatabase/UpdateDatabase (cuando la ubicación de la base de datos se actualiza para que apunte a la ubicación registrada en el modo de acceso híbrido): la ubicación se considera registrada en Lake Formation independientemente del indicador del modo de acceso híbrido y del estado de activación. Así, el usuario necesita el permiso de localización de datos para crear o actualizar una base de datos. + UpdateTable (cuando la ubicación de una tabla se actualiza para que apunte a la ubicación registrada en el modo de acceso híbrido): la ubicación se considera registrada en Lake Formation independientemente del indicador del modo de acceso híbrido y del estado de activación. Por lo tanto, el usuario necesita permiso de localización de datos para actualizar la tabla. Si la ubicación de la tabla no está actualizada o apunta a una ubicación que no está registrada en Lake Formation, el usuario no necesitará permiso de ubicación de datos para actualizar la tabla. # Limitaciones para llevar los datos del almacén de datos de Amazon Redshift al AWS Glue Data Catalog Puede catalogar y administrar el acceso a los datos analíticos en los almacenes de datos de Amazon Redshift mediante el AWS Glue Data Catalog. Se aplican las siguientes restricciones: + El uso compartido entre cuentas no es compatible con el nivel de catálogo federado. Sin embargo, puede compartir bases de datos y tablas individuales desde un catálogo federado entre s. Cuenta de AWS + Debe tener la **configuración de versión de Cross Account** versión 4 o superior para compartir bases de datos o tablas del catálogo federado entre s. Cuenta de AWS + El Catálogo de datos solo admite la creación de catálogos de nivel superior. + Solo puede actualizar la descripción de los catálogos de Redshift Managed Storage (RMS). + No se admite la configuración de permisos de catálogos federados, así como de las bases de datos y tablas de los catálogos federados, para el grupo `IAMAllowedPrincipals`. + No se admiten las operaciones de lenguaje de definición de datos (DDL) en el catálogo, incluido el establecimiento de las configuraciones del catálogo, desde motores como Athena, Amazon EMR Spark u otros. + No se admiten las operaciones de DDL en las tablas de RMS con Athena. + No se admite la creación de vistas materializadas, ya sea a través de Athena, Apache Spark, AWS Glue Data Catalog the o Amazon Redshift Consumer. + Athena no admite una experiencia con varios catálogos. No se puede conectar a más de un catálogo específico a la vez. Athena no puede acceder a varios catálogos ni realizar consultas en ellos simultáneamente. + No se admiten las operaciones de etiquetado y ramificación en tablas de Iceberg mediante Athena y Amazon Redshift. + No se admite Viaje en el tiempo en las tablas de RMS. + No se admiten los catálogos de varios niveles con tablas de lago de datos. Todos los datos almacenados en Amazon S3 para su uso con las tablas de lagos de datos deben residir en la configuración predeterminada AWS Glue Data Catalog y no pueden organizarse en catálogos de varios niveles. + En Amazon Redshift, los recursos compartidos de datos no se agregan al espacio de nombres registrado. Los clústeres y los espacios de nombres son sinónimos y, una vez que publique un clúster en ellos AWS Glue Data Catalog, no podrá añadir nuevos datos. + Amazon EMR en EC2 no admite la unión de tablas de RMS y tablas de Amazon S3. Solo EMR sin servidor admite esta capacidad. + No se admiten tablas y esquemas externos. + Solo se puede acceder a las tablas de RMS desde el punto de conexión de la extensión del catálogo de REST de Iceberg de AWS Glue . + No se puede acceder a las tablas de Hive desde motores de terceros conectados al catálogo REST de AWS Glue Iceberg. + Se admitirá el nivel de aislamiento read\$1committed en las tablas de RMS a través de Spark. + Los nombres de las bases de datos Redshift no distinguen entre mayúsculas y minúsculas AWS Glue Data Catalog, están restringidos a 128 caracteres y pueden ser alfanuméricos con guiones (-) y guiones bajos (\$1). + Los nombres de los catálogos no distinguen entre mayúsculas y minúsculas y están limitados a 50 caracteres, que pueden ser alfanuméricos e incluir guiones (-) y guiones bajos (\$1). + Amazon Redshift no admite el uso de los comandos GRANT y REVOKE al estilo de SQL de Lake Formation para administrar los permisos de acceso en las tablas publicadas en el AWS Glue Data Catalog. + No se aplicarán las políticas de enmascaramiento dinámico de datos y de seguridad de filas asociadas al clúster de Amazon Redshift productor (de origen). En su lugar, se aplicarán los permisos de acceso definidos en Lake Formation a los datos compartidos. + No se admiten las operaciones de lenguaje de definición de datos (DDL) y lenguaje de manipulación de datos (DML) en enlaces de tabla. + Si las palabras clave reservadas no se filtran correctamente con caracteres de escape, se producirán errores. + No se admite el cifrado de datos en escenarios de varios catálogos. # Limitaciones de integración del catálogo de S3 Tables Amazon S3 Tables se integra con AWS Glue Data Catalog (Data Catalog) y registra el catálogo como una ubicación de datos de Lake Formation. Puede configurar este registro desde la consola de Lake Formation o mediante el servicio APIs. **nota** Si tiene una política basada en recursos de IAM o S3 Tables que restringe los usuarios y las funciones de IAM en función de las etiquetas principales, debe adjuntar las mismas etiquetas principales a la función de IAM que Lake Formation utiliza para acceder a sus datos de S3 (por ejemplo LakeFormationDataAccessRole,) y conceder a esta función los permisos necesarios. Esto es necesario para que la política de control de acceso basada en etiquetas funcione correctamente con la integración de análisis de tablas de S3. Las siguientes limitaciones se aplican a la integración del catálogo de tablas S3 con Data Catalog y Lake Formation: + AWS Glue y Lake Formation no admiten nombres de columnas en mayúsculas y minúsculas y convierten todos los nombres de columnas a minúsculas. Debe comprobar que los nombres de las columnas de las tablas sean únicos al convertirse a minúsculas. Use `customer_id` en lugar de `customerId`. El uso de nombres de columna en mayúsculas y minúsculas solo estaba permitido en la versión preliminar. + La CreateCatalog API no puede crear buckets de tablas en Amazon S3. + La SearchTables API no puede buscar en las tablas de S3. # Consideraciones y limitaciones del uso compartido de datos del almacén de metadatos de Hive Con la federación de AWS Glue Data Catalog metadatos (federación de catálogos de datos), puede conectar el catálogo de datos a metaalmacenes externos que almacenan los metadatos de sus datos de Amazon S3 y administrar de forma segura los permisos de acceso a los datos mediante AWS Lake Formation. Las siguientes consideraciones y limitaciones se aplican a las bases de datos federadas que se crean a partir de bases de datos de Hive: **Consideraciones** + **AWS SAM soporte de aplicaciones**: usted es responsable de la disponibilidad de los recursos de la aplicación que se AWS SAM despliega (Amazon API Gateway y de la función Lambda). Asegúrese de que la conexión entre el metabastore de Hive AWS Glue Data Catalog y el metabastore de Hive funcione cuando los usuarios ejecuten consultas. + **Requisito de la versión de almacén de metadatos de Hive**: puede crear bases de datos federadas con Apache Hive versión 3 o posterior. + **Requisito de base de datos mapeada**: cada base de datos de Hive debe estar mapeada a una nueva base de datos en Lake Formation. + **Soporte de federación a nivel de base de datos**: puede conectarse al metaalmacén de Hive a nivel de base de datos. + **Permisos en bases de datos federadas**: los permisos aplicados a una base de datos federada o a las tablas de una base de datos federada persisten incluso cuando se elimina una tabla de origen o una base de datos. Cuando se vuelve a crear la base de datos o tabla de origen, no es necesario volver a conceder los permisos. Cuando se elimina una tabla federada con permisos de Lake Formation en el origen, los permisos de Lake Formation siguen siendo visibles y puede revocarlos si es necesario. Si un usuario elimina una base de datos federada, se pierden todos sus permisos correspondientes. Si se vuelve a crear la misma base de datos con el mismo nombre, no se recuperarán los permisos de Lake Formation. Los usuarios deberán volver a configurar los permisos nuevos. + **IAMAllowedPermisos de grupos principales** en bases de datos federadas: según la`DataLakeSettings`, Lake Formation podría establecer permisos para todas las bases de datos y tablas de un grupo virtual denominado`IAMAllowedPrincipal`. `IAMAllowedPrincipal`Se refiere a todos los directores de IAM que tienen acceso a los recursos del catálogo de datos a través de las políticas principales y las políticas de recursos de IAM. AWS Glue Si estos permisos existen en una base de datos o una tabla, todas las entidades principales tienen acceso a la base de datos o tabla. Sin embargo, Lake Formation no permite permisos `IAMAllowedPrincipal` en las tablas de bases de datos federadas. Al crear bases de datos federadas, asegúrese de pasar el parámetro `CreateTableDefaultPermissions` como una lista vacía. Para obtener más información, consulte [Cambiar la configuración predeterminada de su lago de datos](change-settings.md). + **Unir tablas en las consultas**: puede unir las tablas del metaalmacén de Hive con las tablas nativas del Catálogo de datos para ejecutar consultas. **Limitaciones** + **Limitación en la sincronización de metadatos entre el metabastore de Hive AWS Glue Data Catalog y el metabastore de Hive**: después de establecer la conexión con el metabastore de Hive, debe crear una base de datos federada para sincronizar los metadatos del metaalmacén de Hive con el. AWS Glue Data Catalog Las tablas de la base de datos federada se sincronizan en tiempo de ejecución cuando los usuarios ejecutan consultas. + **Limitación al crear tablas nuevas en una base de datos federada**: no podrá crear tablas nuevas en bases de datos federadas. + **Limitación de permisos de datos**: la compatibilidad con los permisos en las vistas de tabla del metaalmacén de Hive no está disponible. # Limitaciones de uso compartido de datos de Amazon Redshift AWS Lake Formation le permite gestionar de forma segura los datos de un recurso compartido de Amazon Redshift. Amazon Redshift es un servicio de almacenamiento de datos en la nube totalmente gestionado y a escala de petabytes. AWS Al utilizar la capacidad de compartir datos, Amazon Redshift le ayuda a compartir datos entre Cuentas de AWS. Para obtener más información sobre el uso compartido de datos, consulte [Información general del uso compartido de datos en Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/data_sharing_intro.html). Las notas y restricciones siguientes se aplican a las bases de datos federadas que se crean a partir de recursos compartidos de datos de Amazon Redshift: + **Requisito de base de datos mapeada**: cada recurso compartido de datos de Amazon Redshift debe estar mapeado a una nueva base de datos en Lake Formation. Esto es necesario para mantener nombres de tabla únicos cuando la representación de los objetos de recurso compartido de datos está aplanada en la base de datos del Catálogo de datos. + **Limitación al crear tablas nuevas en una base de datos federada**: no podrá crear tablas nuevas en bases de datos federadas. + **Permisos en bases de datos federadas**: los permisos aplicados a una base de datos federada o a las tablas de una base de datos federada persisten incluso cuando se elimina una tabla de origen o una base de datos. Cuando se vuelve a crear la base de datos o tabla de origen, no es necesario volver a conceder los permisos. Cuando se elimina una tabla federada con permisos de Lake Formation en el origen, los permisos de Lake Formation siguen siendo visibles y puede revocarlos si es necesario. Si un usuario elimina una base de datos federada, se pierden todos sus permisos correspondientes. Si se vuelve a crear la misma base de datos con el mismo nombre, no se recuperarán los permisos de Lake Formation. Los usuarios deberán volver a configurar los permisos nuevos. + **IAMAllowedPermisos de grupos principales en bases de datos federadas**: según la`DataLakeSettings`, Lake Formation podría establecer permisos para todas las bases de datos y tablas de un grupo virtual denominado`IAMAllowedPrincipal`. `IAMAllowedPrincipal`Se refiere a todos los directores de IAM que tienen acceso a los recursos del catálogo de datos a través de las políticas principales y las políticas de recursos de IAM. AWS Glue Si estos permisos existen en una base de datos o una tabla, todas las entidades principales tienen acceso a la base de datos o tabla. Sin embargo, Lake Formation no permite permisos `IAMAllowedPrincipal` en las tablas de bases de datos federadas. Al crear bases de datos federadas, asegúrese de pasar el parámetro `CreateTableDefaultPermissions` como una lista vacía. Para obtener más información, consulte [Cambiar la configuración predeterminada de su lago de datos](change-settings.md). + **Filtrado de datos**: en Lake Formation, puede conceder permisos en una tabla de una base de datos federada con filtrado a nivel de columna y de fila. Sin embargo, no puede combinar el filtrado a nivel de columna y de fila para restringir el acceso con una especificidad a nivel de celda a las tablas de bases de datos federadas. + **Identificador de distinción entre mayúsculas y minúsculas**: los objetos de recursos compartidos de datos de Amazon Redshift administrados por Lake Formation solo admitirán nombres de tablas y columnas en minúsculas. No active el identificador de distinción entre mayúsculas y minúsculas en las bases de datos, tablas y columnas de los recurso compartido de datos de Amazon Redshift, si se van a compartir y gestionar mediante Lake Formation. + **Compatibilidad con consultas**: puede consultar recursos compartidos de datos de Amazon Redshift administrados por Lake Formation con Amazon Redshift. Athena no admite la consulta de recursos compartidos de datos de Amazon Redshift administrados por Lake Formation. Para obtener más información acerca de las limitaciones de uso de los recursos compartidos de datos en Amazon Redshift, consulte [Limitaciones del uso compartido de datos](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html#limitations-datashare) en la Guía para desarrolladores de bases de datos Amazon Redshift. # Limitaciones de la integración de IAM Identity Center Con él AWS IAM Identity Center, puede conectarse a proveedores de identidad (IdPs) y administrar de forma centralizada el acceso de los usuarios y grupos a todos AWS los servicios de análisis. Puede configurarlo AWS Lake Formation como una aplicación habilitada en el Centro de identidades de IAM, y los administradores del lago de datos pueden conceder permisos detallados sobre los recursos a los usuarios y grupos autorizados. AWS Glue Data Catalog Se aplican las siguientes limitaciones a la integración de Lake Formation con IAM Identity Center: + No puede asignar usuarios y grupos de IAM Identity Center como administradores de lagos de datos o administradores de solo lectura en Lake Formation. Los usuarios y grupos del IAM Identity Center pueden consultar los recursos del catálogo de datos cifrados si utilizan una función de IAM que AWS Glue pueda asumir en su nombre el cifrado y descifrado del catálogo de datos. AWS las claves administradas no admiten la propagación de identidades de forma fiable. + Los usuarios y grupos de IAM Identity Center solo pueden invocar las operaciones de API que figuran en la política `AWSIAMIdentityCenterAllowListForIdentityContext` proporcionada por el IAM Identity Center. + Lake Formation permite que los roles de IAM de cuentas externas actúen como roles de operador en nombre de los usuarios y grupos de IAM Identity Center para acceder a los recursos del Catálogo de datos, pero solo se pueden conceder permisos a recursos del Catálogo de datos de la cuenta propietaria. Si intenta conceder permisos a usuarios y grupos de IAM Identity Center sobre recursos del Catálogo de datos de una cuenta externa, Lake Formation devuelve el siguiente error: “Cross-account grants are not supported for the principal”. + Cuando se utiliza Lake Formation con IAM Identity Center, la configuración de asignaciones de aplicaciones se establece en `false` de forma predeterminada. Si modifica esta configuración directamente a través de la [API de IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_PutApplicationAssignmentConfiguration.html), debe administrar todas las asignaciones de aplicaciones de forma manual mediante la API. Lake Formation no sincroniza ni administra automáticamente los cambios de asignación realizados fuera de sus flujos de trabajo estándar, lo que puede afectar a los patrones de acceso y los flujos de autorización en su entorno de lago de datos. # Prácticas recomendadas y consideraciones sobre el control de acceso basado en etiquetas de Lake Formation Puede crear, mantener y asignar etiquetas LF para controlar el acceso a las bases de datos, tablas y columnas del catálogo de datos. Tenga en cuenta las siguientes prácticas recomendadas al usar el control de acceso basado en etiquetas de Lake Formation: + Todas las etiquetas LF deben estar predefinidas antes de poder asignarlas a los recursos del Catálogo de datos o concederse a las entidades principales. El administrador del lago de datos puede delegar las tareas de administración de etiquetas generando *creadores de etiquetas LF* con los permisos de IAM necesarios. Los ingenieros y analistas de datos deciden las características y las relaciones de las etiquetas LF. Luego, los creadores de las etiquetas LF crean y mantienen las etiquetas LF en Lake Formation. + Puede asignar varias etiquetas LF a los recursos del Catálogo de datos. Solo se puede asignar un valor para una clave en particular a un recurso concreto. Por ejemplo, puede asignar `module=Orders`, `region=West`, `division=Consumer`, etc. a una base de datos, tabla o columna. No puede asignar `module=Orders,Customers`. + No puede asignar etiquetas LF a los recursos al crearlos. Solo puede añadir etiquetas LF a los recursos existentes. + Puede conceder expresiones de etiquetas LF, no solo etiquetas LF individuales, a una entidad principal. Una expresión LF-Tag tiene el aspecto siguiente (en pseudocódigo). ``` module=sales AND division=(consumer OR commercial) ``` Una entidad principal a la que se le conceda esta expresión de etiqueta LF solo puede acceder a los recursos del Catálogo de datos (bases de datos, tablas y columnas) que tienen asignado `module=sales` *y* `division=consumer` o `division=commercial`. Si desea que la entidad principal pueda acceder a los recursos que tienen `module=sales` *o* `division=commercial`, no incluya ambos en la misma concesión. Haga dos concesiones, una para `module=sales` y otra para `division=commercial`. La expresión de etiqueta LF más sencilla consiste en una sola etiqueta LF, como `module=sales`. + Una entidad principal que reciba permisos sobre una etiqueta LF con varios valores puede acceder a los recursos del Catálogo de datos con cualquiera de esos valores. Por ejemplo, si a un usuario se le concede una etiqueta LF con clave= `module` y valores= `orders,customers`, el usuario tiene acceso a los recursos que están asignados o bien a `module=orders` o `module=customers`. + Debe tener permiso `Grant with LF-Tag expressions` para conceder permisos de datos sobre los recursos del Catálogo de datos mediante el método LF-TBAC. El administrador del lago de datos y el creador de la etiqueta LF reciben este permiso de forma implícita. La entidad principal que tenga el permiso `Grant with LFTag expressions` puede conceder permisos de datos sobre los recursos mediante: + el método de recurso con nombre + el método LF-TBAC, pero solo usando la misma expresión de etiqueta LF Por ejemplo, supongamos que el administrador del lago de datos hace la siguiente concesión (en pseudocódigo). ``` GRANT (SELECT ON TABLES) ON TAGS module=customers, region=west,south TO user1 WITH GRANT OPTION ``` En este caso, el `user1` puede conceder `SELECT` en tablas a otras entidades principales mediante el método LF-TBAC, pero solo con la expresión de etiqueta `module=customers, region=west,south` LF completa. + Si a una entidad principal recibe permisos sobre un recurso con el método LF-TBAC y con el método de recurso con nombre, los permisos que dicha entidad tiene sobre el recurso son la unión de los permisos concedidos por ambos métodos. + Lake Formation admite conceder `DESCRIBE` y `ASSOCIATE` en etiquetas LF entre cuentas, y conceder permisos sobre los recursos del Catálogo de datos en todas las cuentas mediante el método LF-TBAC. En ambos casos, el principal es un identificador de AWS cuenta. **nota** Lake Formation ahora es compatible con la concesión de permisos entre cuentas a organizaciones y unidades organizativas utilizando el método LF-TBAC. Para utilizar esta prestación, debe actualizar la **configuración de la versión entre cuentas** a la **Versión 3**. Para obtener más información, consulte [Compartir datos entre cuentas en Lake Formation](cross-account-permissions.md). + Los recursos del Catálogo de datos creados en una cuenta solo se pueden etiquetar con etiquetas LF creadas en la misma cuenta. Las etiquetas LF creadas en una cuenta no se pueden asociar a los recursos compartidos de otra cuenta. + El uso del control de acceso basado en etiquetas (LF-TBAC) de Lake Formation para conceder acceso entre cuentas a los recursos del catálogo de datos requiere adiciones a la política de recursos del catálogo de datos de su cuenta. AWS Para obtener más información, consulte [Requisitos previos](cross-account-prereqs.md). + Las claves y los valores de las etiquetas LF no pueden superar los 50 caracteres. + La cantidad máxima de etiquetas LF que puede asignar a un recurso del Catálogo de datos es 50. + Los siguientes límites son flexibles: + El número máximo de etiquetas LF que se pueden crear es 1000. + El número máximo de valores que se pueden definir para una etiqueta LF es 1000. + Las etiquetas, las claves y los valores se convierten en minúsculas cuando se almacenan. + Solo se puede asignar un valor para una etiqueta LF a un recurso concreto. + Si se conceden varias etiquetas LF a una entidad principal con una sola concesión, la entidad principal solo podrá acceder a los recursos del Catálogo de datos que tengan todas las etiquetas LF. + Si la evaluación de una expresión de etiqueta LF da como resultado el acceso solo a un subconjunto de columnas de la tabla, pero el permiso Lake Formation que se concede cuando hay una coincidencia es uno de los permisos que requiere acceso completo a las columnas, es decir `Alter`, `Drop`, `Insert` o `Delete`, entonces no se concede ninguno de esos permisos. En su lugar, solo se concede `Describe`. Si el permiso concedido es `All` (`Super`), solo se conceden `Select` y `Describe`. + No se utilizan caracteres comodín con las etiquetas LF. Para asignar una etiqueta LF a todas las columnas de una tabla, debe asignar la etiqueta LF a la tabla y todas las columnas de la tabla heredarán la etiqueta LF. Para asignar una etiqueta LF a todas las tablas de una base de datos, debe asignar la etiqueta LF a la base de datos y todas las tablas de la base de datos heredarán esa etiqueta LF. + Puede crear hasta 1000 expresiones de etiquetas LF en una cuenta. + Puede usar hasta 50 expresiones de etiquetas LF para conceder permisos a una entidad principal en los recursos del Catálogo de datos. + Al conceder o revocar permisos en una expresión de etiqueta LF integrada, el tamaño de la expresión de etiqueta LF no puede superar los 900 bytes. Para conceder permisos en expresiones de etiquetas LF de mayor tamaño, utilice las expresiones de etiquetas LF guardadas. Para obtener más información, consulte [Creación de expresiones de etiquetas LF](TBAC-creating-tag-expressions.md). + Para añadir la etiqueta LF a los catálogos federados de Redshift existentes que se crearon antes de la versión de disponibilidad general de la compatibilidad con etiquetas LF para catálogos federados, debe ponerse en contacto con el equipo de soporte para obtener ayuda. AWS # Consideraciones, limitaciones y regiones compatibles para el control de acceso basado en atributos Las consideraciones y limitaciones indicadas a continuación se aplican al control de acceso basado en atributos (ABAC). + ABAC no admite la concesión de acceso mediante políticas de etiquetas LF. + Los permisos que se pueden conceder no están disponibles con ABAC. + ABAC no admite la concesión de permisos a los usuarios de IAM Identity Center. + Cuando se utilizan las concesiones de permisos de ABAC en una tabla de Lake Formation, Lake Formation no concede permisos `DESCRIBE` en la base de datos o catálogo principal. Esto difiere de los escenarios ajenos a ABAC, en los que Lake Formation proporciona permisos `DESCRIBE` implícitos a los recursos principales. + Todas las entidades principales con la clave de etiqueta `AmazonDataZoneProject` siempre se consideran parte de Lake Formation para todos los recursos del Catálogo de datos. + ABAC solo admite atributos de cadena.