Gobernanza de Lake Formation: Permisos, Seguridad por Filas/Columnas y Compartición de Datos

Las lecciones 01 to 11 construyeron la máquina: buckets, formatos, tablas Iceberg, crawlers, trabajos, un motor de consultas, un almacén y un orquestador. Cada una de esas capas produjo un nuevo lugar donde alguien tenía que responder la misma pregunta: ¿quién puede ver esto? Esta lección la responde una vez, de forma centralizada, con AWS Lake Formation. El servicio no es un reemplazo de IAM ni un catálogo; es una capa de permisos con forma de RDBMS que se apoya en el Glue Data Catalog y emite credenciales temporales con alcance a los motores integrados, de modo que una sola sentencia GRANT pueda significar algo a granularidad de base de datos, tabla, columna, fila y celda.

La regla didáctica de esta lección: Lake Formation decide la visibilidad, IAM decide la accesibilidad, y el motor hace el filtrado real. Confunde esas tres cosas y cada síntoma de esta lección se vuelve un misterio.

En esta lección:

• diagnostica lo que Lake Formation realmente reemplaza, la maraña de políticas de IAM más S3, y lo que deliberadamente no reemplaza;
• separa las ubicaciones registradas en LF del modo de acceso híbrido, y predice qué plano de permisos responde a una petición dada;
• escala la escalera de granularidad de permisos (base de datos → tabla → columna → filtro de fila → celda) y nombra el mecanismo en cada peldaño;
• construye la política de analista trabajada: SELECT sobre gold.sales, menos salary, filas limitadas a region = 'eu', como un solo filtro de datos a nivel de celda;
• aplica LF-Tags y TBAC: concesiones de etiquetas, herencia, y las reglas de coincidencia AND entre claves / OR dentro de una clave;
• comparte bases de datos de cuentas cruzadas a través de AWS RAM, con el conmutador de motor externo, llamadores de confianza, acceso gestionado y reglas de administradores del lago de datos;
• sitúa Athena, Redshift Spectrum, QuickSight, Glue y EMR en una matriz de soporte de motores y diagnostica qué se rompe en cada celda;
• elimina el predeterminado IAMAllowedPrincipals y ejecuta la migración documentada de seis pasos;
• lee el árbol de decisión de comprobación de permisos y escribe llamadas reales a GrantPermissions en JSON y CLI;
• estudia tres casos nombrados de clientes de AWS (Integral Ad Science, FanDuel, Morningstar), un recuadro de actualización de octubre de 2026 con fuentes, nueve ejemplos resueltos, cinco diagramas, tres comprobaciones interactivas y doce preguntas de estilo examen.

---

1. Lo que Lake Formation reemplaza: la maraña de IAM y S3

1.1 Tres superficies, una tabla, ninguna fila

Antes de Lake Formation, un lago gobernado en AWS se ensamblaba a partir de tres superficies de políticas superpuestas, y AWS lo dijo en su disponibilidad general el 2019-08-08:

"Antes tenías que usar políticas separadas para proteger el acceso a datos y metadatos, y estas políticas solo permitían acceso a nivel de tabla. Ahora puedes dar acceso a cada usuario, desde una ubicación central, solo a las columnas que necesita usar.", AWS News Blog, AWS Lake Formation, Now Generally Available (2019-08-08)

Lake Formation añade una cuarta superficie que está deliberadamente concesionada como un sistema de concesiones de bases de datos relacionales:

«Lake Formation proporciona un modelo de permisos de sistema de gestión de bases de datos relacionales (RDBMS) para conceder o revocar acceso a catálogos, bases de datos, tablas y columnas del Data Catalog con los datos subyacentes en Amazon S3.»: Guía del desarrollador de LF, Onboarding to Lake Formation permissions (consultado 2026-10-11)

Y amplía en lugar de reemplazar a IAM:

«Lake Formation proporciona su propio modelo de permisos que amplía el modelo de permisos de IAM.»: Guía del desarrollador de LF, Overview of data filtering (consultado 2026-10-11)

La división del trabajo queda así fijada para el resto de la lección: IAM autentica y controla el plano de control (GrantPermissions, GetDataAccess, glue:*), Lake Formation controla el plano de datos decidiendo qué metadatos y qué credenciales temporales con alcance recibe un motor integrado, y el motor realiza él mismo el filtrado por filas/columnas/celdas.

Dos hechos salen directamente de ese diagrama y ambos son examinables:

1. El registro es el único puente entre los planos. «La entrega de credenciales de Lake Formation no está disponible, incluso con opt-in, salvo que la ubicación de datos esté registrada en Lake Formation.» (Guía del desarrollador de LF, Hybrid access workflow, consultado 2026-10-11.)
2. Lake Formation no bloquea tu bucket. «El modelo de permisos de Lake Formation no impide el acceso a las ubicaciones de Amazon S3 a través de la API o la consola de Amazon S3 si tienes acceso a ellas a través de IAM o de políticas de Amazon S3. Puedes adjuntar políticas de IAM a los principales para bloquear este acceso.» (Guía del desarrollador de LF, Underlying data access control, consultado 2026-10-11.)

1.2 Ejemplo resuelto E1: contando la maraña, luego contando el reemplazo

Lectura: la primera ventaja de Lake Formation sobre IAM puro no son menos sentencias: a granularidad de recursos con nombre escribes el mismo número. Su primera ventaja es la centralización más la auditabilidad (un ListPermissions en lugar de tres familias de políticas), y su segunda ventaja, que llega en la Sección 5, es reducir la cuenta con etiquetas. La columna de coste es la sorpresa: la propia capa de gobernanza es gratuita, así que la única pregunta de presupuesto es quién la mantiene.

• 📚 ¿Sabías que…? La facturación de Lake Formation tiene exactamente tres conceptos facturables a oct 2026, y ninguno de ellos es un permiso. La Storage API, el motor de filtrado independiente del lado del servidor que se usa cuando ningún servicio analítico de AWS procesa los datos, factura «por el número de bytes escaneados por la Storage API, redondeado al megabyte siguiente, con un mínimo de 10 MB»; Governed Tables factura por archivo rastreado, por llamada a la API de metadatos y por byte procesado por el optimizador de almacenamiento; y el propio optimizador de almacenamiento factura por byte. Concesiones, revocaciones, LF-Tags, compartición entre cuentas y la aplicación por parte de Athena, Redshift, Glue y EMR son todas $0 (página de precios de Lake Formation, consultada 2026-10-11).

---

2. Registrado en LF frente a híbrido: los dos modos de permisos

Un objeto del Data Catalog tiene dos preguntas ortogonales, y la mayor confusión sobre Lake Formation viene de responder solo una de ellas:

2.1 Registro: para qué sirve el rol

«Cuando registras una ubicación, especificas un rol de IAM que concede permisos de lectura/escritura sobre esa ubicación. Lake Formation asume ese rol al suministrar credenciales temporales a los servicios de AWS integrados.»: Guía del desarrollador de LF, Set up AWS Lake Formation (consultado 2026-10-11)

Consecuencias prácticas:

• el rol de registro, no el llamador, posee los permisos duraderos de s3:*;
• los llamadores además necesitan el permiso de IAM lakeformation:GetDataAccess, y «debes fijar el parámetro Resource a *»: cualquier otro valor de recurso no está soportado;
• registrar un prefijo cubre todas las tablas bajo esa ruta de una vez, porque «varias tablas pueden compartir un prefijo S3. Cuando registras una ubicación, todas las tablas bajo esa ruta obtienen la entrega de credenciales de una vez» (guía de mejores prácticas de Lake Formation publicada por AWS, consultada 2026-10-11).

2.2 Modo de acceso híbrido: dos vías, principales con opt-in

«El modo de acceso híbrido de AWS Lake Formation admite dos vías de permisos hacia los mismos objetos de AWS Glue Data Catalog.» … «El modo de acceso híbrido aplica solo los permisos CREATE_TABLE, CREATE_PARTITION, UPDATE_TABLE por defecto.» … «los principales con opt-in necesitarán tanto permisos de Lake Formation como permisos de IAM para acceder a los datos, mientras que los principales sin opt-in seguirán accediendo a los datos usando solo permisos de IAM.»: Guía del desarrollador de LF, Hybrid access mode (consultado 2026-10-11)

Esa última frase es todo el modo: el híbrido es un conmutador por principal, no por cuenta, y es la herramienta de migración reversible que AWS recomienda:

«Para suavizar la transición de los permisos del lago de datos de un modelo de IAM y Amazon S3 a los permisos de Lake Formation, te recomendamos que uses el modo de acceso híbrido para el Data Catalog.»: Guía del desarrollador de LF, Set up AWS Lake Formation (consultado 2026-10-11)

2.3 Ejemplo resuelto E2: llevar un rol al modo híbrido

Comprobaciones: (a) el analista con opt-in que tiene una política de IAM pero sin concesión de LF ahora falla, prueba de que el doble control está activo; (b) el rol sin opt-in sigue leyendo solo con IAM, prueba de que el modo es por principal; (c) IsRegisteredWithLakeFormation en la tabla es true para la vista del principal con opt-in y sin cambios para los demás.

• 📚 ¿Sabías que…? Los ajustes a nivel de cuenta que mantienen una base de datos nueva en el plano antiguo tienen nombres exactos en la consola: Use only IAM access control for new databases y Use only IAM access control for new tables in new databases, respaldados en la API por CreateDatabaseDefaultPermissions y TableDefaultPermissions, cuyo valor predeterminado es [{"Principal":{"DataLakePrincipalIdentifier":"IAM_ALLOWED_PRINCIPALS"},"Permissions":["ALL"]}] (Guía del desarrollador de LF, Changing the default settings for your data lake y API DataLakeSettings, consultado 2026-10-11). AWS deliberadamente no denomina este estado "IAMOnly" en ninguna parte: enseña los nombres documentados.

---

3. La escalera de granularidad de permisos

3.1 El vocabulario

Tipos de recurso sobre los que puedes conceder: Catalog, Database, Table, View, DataLocation (solo aplica DATA_LOCATION_ACCESS), LF_Tag, LF_TagPolicy / LFTagExpression.

El enum de permisos, tal como lo devuelve ListPermissions (referencia de la API de LF, consultada 2026-10-11):

Tres reglas sobre esa lista:

• SELECT, INSERT y DELETE son a la vez permisos del Data Catalog y permisos de acceso a datos: son los que llegan a S3.
• Super es aditivo y sobrevive a una revocación parcial: «cuando revocas Super, los permisos SELECT e INSERT permanecen» (Guía del desarrollador de LF, Access control for metadata, consultado 2026-10-11).
• Conceder sobre todas las tablas de una base de datos concede implícitamente DESCRIBE sobre esa base de datos, pero «esta concesión automática de permiso DESCRIBE no se aplica cuando se usa control de acceso basado en atributos (ABAC)».

3.2 La escalera, dibujada

Todo lo que hay por debajo de TABLE se expresa a través de solo dos mecanismos: un filtro de columna en la propia concesión (TableWithColumns) o un objeto de filtro de datos (DataCellsFilter). Elige entre ellos con una pregunta: ¿necesito filas también?

3.3 Ejemplo resuelto E3: la escalera de cuatro concesiones sobre una tabla

Cifras a oct 2026: un filtro de datos necesita SELECT con la opción de concesión sobre todas las columnas de la tabla para crearse; no hay tope de filtros por tabla pero sí un límite de 100 filtros de datos por principal por una sola tabla; y la expresión de fila debe quedar por debajo de 2.048 caracteres (Guía del desarrollador de LF, Data filtering limitations y compatibilidad con PartiQL, consultado 2026-10-11).

• 📚 ¿Sabías que…? Tres techos merece memorizarse porque todos son pequeños: 30 administradores de lago de datos por cuenta por defecto, 1.000 expresiones de LF-Tag guardadas por cuenta, y 100 filtros de datos por principal por tabla (Guía del desarrollador de LF, Set up AWS Lake Formation, Managing LF-Tag expressions y Data filtering limitations, todos consultados 2026-10-11). Un cuarto, más blando: el ejemplo resuelto basado en etiquetas de la propia AWS llega a 17 permisos efectivos a partir de solo 5 asignaciones de etiqueta más 8 concesiones de etiqueta.

---

4. Seguridad a nivel de fila y de columna: la política de analista trabajada

4.1 La combinatoria: tres controles, un tipo de objeto

«Lake Formation usa el filtrado de datos para lograr seguridad a nivel de columna, a nivel de fila y a nivel de celda.» … «Cuando especificas el comodín de todas las columnas y proporcionas una expresión de filtro de fila, estás estableciendo solo seguridad a nivel de fila (filtrado por fila).» … «Cuando incluyes o excluyes columnas y columnas anidadas específicas, y especificas todas las filas … estás estableciendo seguridad a nivel de columna.» … «Cuando incluyes o excluyes columnas específicas y además proporcionas una expresión de filtro de fila, estás estableciendo seguridad a nivel de celda.»: Guía del desarrollador de LF, Data filtering and cell-level security (consultado 2026-10-11)

Dos aclaraciones que ahorran tiempo real de depuración:

• El filtrado de columnas no es enmascarado. Excluir salary la elimina de los resultados y de los metadatos del catálogo de ese principal. Nunca devuelve tres asteriscos. Si el requisito es "mostrar solo los últimos cuatro dígitos", eso es una vista, una transformación en la capa de aplicación, o el dynamic data masking de Amazon Redshift: no Lake Formation.
• Disponibilidad: «La seguridad a nivel de celda está disponible en todas las regiones al usar la versión 3 del motor de Athena o Amazon Redshift Spectrum.» (Guía del desarrollador de LF, Data filtering limitations, consultado 2026-10-11.)

4.2 El lenguaje del filtro de fila: subconjunto de PartiQL, con bordes duros

4.3 Ejemplo resuelto E4, la política de analista: gold.sales menos salary, filas = region='eu'

Esto es seguridad a nivel de celda en un solo objeto de filtro de datos, más la concesión de visibilidad que lo hace utilizable.

Cuatro comprobaciones de aprendizaje, y qué demuestra cada una:

Contraste (más barato, más estrecho): conceder TableWithColumns con ExcludedColumnNames = ["salary"] te da las columnas y ninguna fila: una respuesta legítima cuando el requisito es solo "ocultar PII", y el patrón que FanDuel usó en el Caso B de abajo. Añadir region = 'eu' es lo que te obliga a un filtro de datos.

---

5. LF-Tags y control de acceso basado en etiquetas (LF-TBAC)

5.1 Qué es una etiqueta

«Cada LF-Tag es un par clave-valor, como department=sales o classification=restricted. Una clave puede tener múltiples valores definidos.»: Guía del desarrollador de LF, Tag-based access control (LF-TBAC) (consultado 2026-10-11)

Las etiquetas se adhieren a bases de datos, tablas y columnas. Deben estar predefinidas (una clave y sus valores se crean con CreateLFTag antes de que nada pueda llevarlas), y son el único mecanismo de esta lección que te deja conceder sobre un atributo en lugar de sobre un objeto con nombre.

5.2 Herencia y las reglas de coincidencia

«Las tablas heredan LF-Tags de las bases de datos y las columnas heredan LF-Tags de las tablas. Los valores heredados pueden anularse» … «las claves de etiqueta se combinan con la operación AND, mientras que los valores se combinan con la operación OR»: Guía del desarrollador de LF, Tag-based access control (LF-TBAC) (consultado 2026-10-11)

Las dos reglas de combinación, enunciadas una vez y probadas para siempre:

• Claves distintas en una misma concesión van en AND: owner = data-platform AND class = internal solo coincide con recursos que llevan ambas.
• Múltiples valores de una misma clave van en OR: class = internal OR class = restricted coincide con cualquiera.
• Ejemplo de la documentación: la expresión de etiqueta content_type:Sales AND location:US «representa recursos relacionados con datos de ventas en EE. UU.»; las expresiones de LF-Tag guardadas tienen un tope de 1.000 por cuenta.

5.3 Tres cosas que TBAC cambia en las concesiones

1. Concedes sobre la etiqueta, no sobre la tabla. El recurso de la concesión del principal es un LFTagPolicy (o un LFTagExpression), así que las tablas creadas después, incluidas las creadas por crawlers, quedan cubiertas automáticamente en cuanto heredan la etiqueta.
2. Puedes conceder la capacidad de etiquetar. ASSOCIATE deja que un principal adhiera una etiqueta; DESCRIBE le deja verla; GRANT_WITH_LF_TAG_EXPRESSION le deja usarla como recurso de concesión. Esta es la primitiva de delegación detrás de las mallas de datos.
3. Los permisos de todos los métodos se unen. El propio consejo de migración de AWS: «(Recomendado) Tras verificar que los principales tienen acceso a los recursos correctos mediante el método LF-TBAC, revoca los permisos que se concedieron usando el método de recurso con nombre.» Verifica primero, revoca después: nunca al revés.

5.4 Ejemplo resuelto E5: reconstruir la compresión de IAS con tres etiquetas

Lectura: el coste de la ruta de etiquetas es plano en el número de tablas y lineal en el número de políticas; la ruta con nombre es lineal en tablas × principales. IAS informó de la versión real de esto: «Con los controles de acceso basados en etiquetas de Lake Formation, IAS redujo cientos de reglas de permiso a precisamente dos reglas» (AWS Big Data Blog, 2021-09-23). Observa dónde aterriza la lista de excepciones: los filtros de fila son exactamente la función que no puede dirigirse con etiquetas, así que un patrimonio TBAC siempre arrastra una cola corta y deliberada de recursos con nombre.

Pasa el cursor sobre un par de barras: las concesiones de recurso con nombre escalan como principales × tablas (derivado: 4 × 6 = 24 hasta 4 × 36 = 144), mientras que la ruta de etiquetas se queda en 6 asignaciones + 4 concesiones = 10 sin importar el número de tablas (derivado de la forma IAS de dos claves aplicadas a nivel de base de datos). El cruce es inmediato, la ruta de etiquetas ya es más pequeña con seis tablas, y por eso el ejemplo basado en etiquetas de AWS se cita como simplificación operativa y no como una función de seguridad.

---

6. Compartición de datos: bases de datos entre cuentas, motores externos, llamadores de confianza

6.1 Las bases de datos entre cuentas pasan por AWS RAM

«Lake Formation usa el servicio AWS Resource Access Manager (AWS RAM) para compartir el recurso. Si la cuenta receptora está en la misma organización que la cuenta cedente, el recurso compartido está disponible de inmediato; si la cuenta receptora no está en la misma organización, AWS RAM envía una invitación a la cuenta receptora para aceptar o rechazar la concesión del recurso.»: Guía del desarrollador de LF, Cross-account data sharing (consultado 2026-10-11)

Existen dos métodos de concesión, y AWS recomienda uno de ellos por su nombre: control de acceso basado en etiquetas de Lake Formation (LF-TBAC) (recommended) frente a recursos con nombre. El blog que documenta la compensación lo dice llanamente: TBAC «se recomienda cuando están implicados muchos recursos y entidades.»

Prerrequisitos que son fallos duros, no consejos (Guía del desarrollador de LF, Cross-account prerequisites, consultado 2026-10-11):

1. Revoca todos los permisos de Lake Formation de IAMAllowedPrincipals sobre el recurso primero: de lo contrario Lake Formation lanza AccessDeniedException.
2. El cedente debe poseer la política gestionada de AWS AWSLakeFormationCrossAccountManager.
3. Al menos un usuario de la cuenta consumidora debe ser administrador del lago de datos para ver los recursos compartidos; «otros principales no pueden acceder a los recursos compartidos hasta que el administrador del lago de datos les conceda permisos.»
4. Las concesiones entre cuentas deben llevar la opción de concesión, porque el administrador del lado consumidor re-concede en local. «El principal que recibe el resource share no puede compartir el recurso con otros principales.»

Ajustes de versión entre cuentas (DataLakeSettings.Parameters.CROSS_ACCOUNT_VERSION) deciden qué puede compartirse: las concesiones directas a un principal IAM individual en otra cuenta necesitan versión ≥ 3; los shares en modo híbrido necesitan ≥ 4; la versión 5 «mejora la compartición de recursos entre cuentas, permitiéndote compartir un número ilimitado de tablas con otra cuenta, eliminando los límites anteriores de asociación de recursos por tipo de recurso», está disponible «a través de la consola o la API de Lake Formation», y la degradación no está soportada una vez aplicada (AWS What's New, 2026-02-11; Guía del desarrollador de LF, consultado 2026-10-11).

6.2 Ejemplo resuelto E6: compartir gold.sales con una cuenta externa

Comprobaciones: (a) un intento de concesión mientras IAMAllowedPrincipals aún posee Super falla con AccessDeniedException; (b) una concesión sin --permissions-with-grant-option deja al administrador consumidor sin poder conceder nada a sus propios analistas; (c) conceder solo sobre el enlace deja la tabla invisible para las consultas: concesión de enlace ≠ concesión de destino.

6.3 Llamadores de confianza y el conmutador de motor externo

Lake Formation entrega credenciales temporales solo a llamadores de confianza. «Cada uno de estos servicios de AWS es un llamador de confianza para Lake Formation, y Lake Formation proporciona acceso a los datos almacenados en Amazon S3 a través de credenciales temporales»: el conjunto integrado siendo Athena, Redshift Spectrum, EMR y Glue (Guía del desarrollador de LF, Working with services, consultado 2026-10-11).

Cualquier otra cosa es opt-in, y el opt-in es un conmutador de tres partes en DataLakeSettings:

«Si pretendes analizar … usando motores de consulta de terceros, debes optar por permitir que los motores externos accedan a los datos gestionados por Lake Formation.»: Guía del desarrollador de LF, Set up AWS Lake Formation (consultado 2026-10-11)

Una discrepancia documental de la que ser honesto: la referencia de la API DataLakeSettings muestra un ejemplo de clave de etiqueta de sesión LakeFormationTrustedCaller, mientras que la guía de motores de terceros y el blog de aplicaciones a medida especifican LakeFormationAuthorizedCaller. Dos fuentes dicen la segunda, así que úsala, pero no trates ninguno de los dos nombres como incuestionable.

6.4 Acceso gestionado y los roles de administrador

Dos asimetrías que merece interiorizar:

• Administrador añadido después = cero acceso implícito a los datos. «los administradores del lago de datos añadidos después de la creación de la base de datos pueden conceder permisos pero no obtienen automáticamente permisos de acceso a datos como SELECT o DESCRIBE. Los administradores que crean bases de datos reciben permisos SUPER sobre esas bases de datos.»

• El acceso gestionado se expresa como la opción de concesión. El patrón, un equipo de plataforma que retiene PermissionsWithGrantOption y equipos de dominio que re-conceden dentro de un alcance, es cómo funciona el autoservicio "grantable" sin entregar el catálogo completo.

• 📚 ¿Sabías que…? El rol de registro y el rol vinculado al servicio son una decisión de diseño real: Lake Formation trae un rol vinculado al servicio (ServiceRoleForLakeFormationDataAccess) para un registro sin configuración, pero la guía de mejores prácticas de AWS recomienda registrar con un rol gestionado por el cliente cuando esperas editar o acotar ese rol más adelante. En cualquier caso el llamador sigue necesitando lakeformation:GetDataAccess con Resource: "*", y añadirlo es «una operación sin efecto cuando no hay ubicaciones registradas, así que es seguro (y recomendable) añadirlo de antemano» (guía de mejores prácticas de Lake Formation publicada por AWS, consultada 2026-10-11).

---

7. Matriz de soporte de motores: quién aplica realmente qué

«el filtrado real de columnas en las respuestas de consulta es responsabilidad del servicio integrado. Los clientes de Lake Formation que admiten filtrado por columna, incluidos Amazon Athena, Amazon Redshift Spectrum y Amazon EMR, filtran los datos según los permisos de columna registrados con Lake Formation»: Guía del desarrollador de LF, Limitations (consultado 2026-10-11)

7.1 Ejemplo resuelto E7: situando ocho motores en la matriz

Regla práctica derivada de la matriz: Lake Formation publica metadatos filtrados y credenciales con alcance; el motor poda la respuesta. Cualquier motor fuera de esa lista o bien rechaza la consulta, o, peor, devuelve datos sin filtrar si concediste el opt-in de motor externo.

• 📚 ¿Sabías que…? La integración de QuickSight tiene una división por ediciones que es fácil pasar por alto: la edición Enterprise te deja «conceder permisos de control de acceso de granularidad fina (FGAC) a usuarios y grupos individuales de QuickSight», mientras que las concesiones de la edición Standard van a roles de IAM, con el rol de servicio predeterminado llamado aws-quicksight-service-role-v0. Una vez registrado el bucket de origen, «los ajustes de acceso a Amazon S3 en QuickSight se ignoran, incluidas las políticas de IAM de alcance reducido para usuarios y grupos»: Lake Formation se convierte en la única fuente de verdad (documentación de QuickSight y del AWS Big Data Blog, consultada 2026-10-11).

---

8. El predeterminado IAMAllowedPrincipals, y la migración para dejarlo

8.1 Por qué tus concesiones parecen no hacer nada

«Lake Formation establece por defecto el permiso Super a un grupo llamado IAMAllowedPrincipals en todas las bases de datos y tablas del Data Catalog. Si este permiso de grupo existe … todos los principales de tu cuenta tendrán acceso al recurso a través de las políticas de principal de IAM para AWS Glue.»: Guía del desarrollador de LF, Permissions reference (consultado 2026-10-11)

Y la consecuencia, enunciada con la misma directez:

«Estos ajustes hacen que efectivamente el acceso a los recursos del Data Catalog y a las ubicaciones de Amazon S3 quede controlado únicamente por políticas de AWS Identity and Access Management (IAM). Los permisos individuales de Lake Formation no están en vigor.»: Guía del desarrollador de LF, Changing the default settings for your data lake (consultado 2026-10-11)

Así que el estado predeterminado de un lago recién creado o llevado mucho tiempo sin modificar es: Lake Formation instalado, pero apagado. Tus relucientes concesiones quedan registradas, auditadas e ignoradas.

8.2 Ejemplo resuelto E8: la migración documentada, ensayada

---

9. El flujo de comprobación de permisos: un árbol de decisión

Esto refleja el flujo de trabajo de acceso híbrido documentado de Lake Formation y es la forma más rápida de convertir "no funciona" en una sola comprobación.

Léelo como un orden de diagnóstico: registro primero, IAMAllowedPrincipals segundo, método de concesión tercero, tipo de atribución cuarto. Ir directo a "¿mi SQL está bien?" es la forma más cara de depurar Lake Formation.

---

10. Esbozo trabajado de la API y CLI de Grant

10.1 Las cuatro formas de llamada que realmente escribirás

10.2 Ejemplo resuelto E9: leer correctamente de vuelta una concesión

Nota de diseño: como no hay sentencia de denegación en Lake Formation, el privilegio mínimo significa no conceder nada por defecto y tratar cada nueva concesión como un evento de ampliación que debe re-auditarse. ColumnWildcard.ExcludedColumnNames solo estrecha la atribución en la que se escribe.

---

Actualizaciones de 2026 (en octubre de 2026)

• 📚 ¿Sabías que…? Dos de estas actualizaciones soportan en silencio el peso de esta lección. El ABAC (control de acceso basado en atributos vía etiquetas) se documentó formalmente el 2025-04-17, y por eso las concesiones de expresión de etiqueta aparecen ahora junto a las concesiones de recurso con nombre en la misma lista de permisos; y el ocaso de las Governed Tables significa que cualquier requisito de "compartición ACID gobernada" debe responderse ahora con Iceberg más concesiones de Lake Formation, no con un tipo de tabla retirado.

---

Casos Reales

AWS publica cómo se ven estos modelos de permisos a escala de producción. Cada cifra de abajo es declarada por el cliente o por AWS y sin auditoría, con la fuente y la fecha nombradas para que puedas comprobarla: el punto examinable es el patrón, no el marketing.

Caso A, Integral Ad Science: cientos de reglas de permiso reducidas a dos

El patrón examinable: el verdadero rendimiento del TBAC es operativo. Una ontología de unas pocas etiquetas heredadas reemplaza una matriz ingobernable de concesiones por tabla: la aritmética de la Sección 5.4 en producción. Observa también lo que IAS no omitió: los controles a nivel de columna más el etiquetado llevaron la respuesta de cumplimiento, y la concesión de etiqueta aún tenía que coexistir con las excepciones de nivel de fila que el negocio necesitara.

Caso B, FanDuel: concesiones de columna en lugar de enmascarado por copia

El patrón examinable: las concesiones a nivel de columna matan el enmascarado por copia. El requisito "ocultar los PII a los analistas generales" se satisface con una exclusión TableWithColumns sobre una tabla catalogada; sin una segunda copia de los datos, sin un ritual de etiquetado por fuente. Esta es la alternativa más barata de la Sección 4, y por eso FanDuel nunca necesitó filtros de fila para ese problema en particular.

Caso C, Morningstar: una ontología de etiquetas, dos planos de aplicación

El patrón examinable: la ontología de etiquetas es portable, la aplicación no lo es. Redshift admite atribuciones basadas en recursos pero no las basadas en etiquetas, así que un equipo que quiera un modelo de gobernanza único debe construir la traducción: que es exactamente el límite que la matriz de motores de la Sección 7 está dibujando.

• 📚 ¿Sabías que…? Los tres casos datan de 2020 to 2023 y deben presentarse así: los 8,5 millones de clientes de FanDuel y el "cientos → dos reglas" de IAS son instantáneas de esas implementaciones en el momento en que AWS las publicó, no los estados actuales de esas plataformas. Sus afirmaciones arquitectónicas, concesiones de columna, etiquetas heredadas, un grupo de trabajo por unidad de negocio, siguen siendo los patrones documentados; sus cifras son históricas.

---

Preguntas de Práctica (Practice Questions)