Governança com Lake Formation: Permissões, Segurança em Nível de Linha/Coluna e Data Sharing

As lições 01 to 11 construíram a máquina: buckets, formatos, tabelas Iceberg, crawlers, jobs, um motor de consulta, um warehouse e um orquestrador. Cada uma dessas camadas produziu um novo lugar onde alguém tinha que responder à mesma pergunta: quem pode ver isto? Esta lição responde uma vez, centralmente, com AWS Lake Formation. O serviço não é um substituto do IAM e não é um catálogo; é uma camada de permissões com formato de RDBMS que fica sobre o Glue Data Catalog e emite credenciais temporárias com escopo para motores integrados, de modo que um único statement GRANT signifique algo na granularidade de database, table, column, row e cell.

A regra de ensino desta lição: Lake Formation decide a visibilidade, IAM decide o alcance, e o motor faz a filtragem de fato. Confunda esses três e cada sintoma desta lição vira um mistério.

Nesta lição você vai:

• diagnosticar o que o Lake Formation realmente substitui, a dispersão de políticas de IAM-mais-S3, e o que ele deliberadamente não substitui;
• separar localizações registradas no LF do modo de acesso híbrido e prever qual plano de permissões responde a uma dada requisição;
• subir a escada de granularidade de permissões (database → table → column → row filter → cell) e nomear o mecanismo em cada degrau;
• construir a política de analista resolvida: SELECT em gold.sales, menos salary, linhas limitadas a region = 'eu', como um único data filter em nível de célula;
• aplicar LF-Tags e TBAC: grants de tag, herança e as regras de correspondência AND-entre-chaves / OR-dentro-de-uma-chave;
• compartilhar bancos de dados entre contas por meio do AWS RAM, com o toggle de motor externo, callers confiáveis, acesso gerenciado e regras de administrador de data lake;
• posicionar Athena, Redshift Spectrum, QuickSight, Glue e EMR em uma matriz de suporte de motores e dizer o que quebra em cada célula;
• remover o padrão IAMAllowedPrincipals e executar a migração documentada em seis etapas;
• ler a árvore de decisão de verificação de permissão e escrever chamadas reais de GrantPermissions em JSON e CLI;
• estudar três casos nomeados de clientes da AWS (Integral Ad Science, FanDuel, Morningstar), uma caixa de atualizações de outubro de 2026 com fontes, nove exemplos resolvidos, cinco diagramas, três verificações interativas e doze questões no estilo de exame.

---

1. O que o Lake Formation substitui: a dispersão de IAM e S3

1.1 Três superfícies, uma tabela, nenhuma linha

Antes do Lake Formation, um lake governado na AWS era montado a partir de três superfícies de política sobrepostas, e a AWS disse isso na disponibilidade geral em 2019-08-08:

"Antes você precisava usar políticas separadas para proteger o acesso a dados e metadados, e essas políticas só permitiam acesso em nível de tabela. Agora você pode dar acesso a cada usuário, de um local central, apenas às colunas que ele precisa usar.", AWS News Blog, AWS Lake Formation, Now Generally Available (2019-08-08)

O Lake Formation adiciona uma quarta superfície que é deliberadamente modelada como um sistema de grants de banco de dados relacional:

"Lake Formation fornece um modelo de permissões de sistema de gerenciamento de banco de dados relacional (RDBMS) para conceder ou revogar acesso a catálogos, databases, tabelas e colunas no Data Catalog com os dados subjacentes no Amazon S3.": Guia do Desenvolvedor do LF, Onboarding to Lake Formation permissions (acesso em 2026-10-11)

E ele complementa em vez de substituir o IAM:

"Lake Formation fornece seu próprio modelo de permissões que complementa o modelo de permissões do IAM.": Guia do Desenvolvedor do LF, Overview of data filtering (acesso em 2026-10-11)

A divisão de trabalho, portanto, fica fixa pelo resto da lição: IAM autentica e controla o plano de controle (GrantPermissions, GetDataAccess, glue:*), Lake Formation controla o plano de dados decidindo quais metadados e quais credenciais temporárias com escopo um motor integrado recebe, e o motor executa ele mesmo a filtragem de linha/coluna/célula.

Dois fatos caem direto desse diagrama e ambos são examináveis:

1. O registro é a única ponte entre os planos. "A emissão de credenciais do Lake Formation não está disponível, mesmo com opt-in, a menos que a localização de dados esteja registrada no Lake Formation." (Guia do Desenvolvedor do LF, Hybrid access workflow, acesso em 2026-10-11.)
2. Lake Formation não tranca o seu bucket. "O modelo de permissões do Lake Formation não impede o acesso a localizações do Amazon S3 pela API ou pelo console do Amazon S3 se você tem acesso a elas através de políticas de IAM ou do Amazon S3. Você pode anexar políticas de IAM a principais para bloquear esse acesso." (Guia do Desenvolvedor do LF, Underlying data access control, acesso em 2026-10-11.)

1.2 Exemplo resolvido E1: contando a dispersão, depois contando a substituição

Leitura: a primeira vitória do Lake Formation sobre o IAM cru não é menos statements: na granularidade de recurso nomeado você escreve o mesmo número. A primeira vitória é centralização mais auditabilidade (um único ListPermissions em vez de três famílias de política), e a segunda vitória, que chega na Seção 5, é reduzir a contagem com tags. A coluna de custo é a surpresa: a camada de governança em si é de graça, então a única pergunta de orçamento é quem a mantém.

• 📚 Você sabia? A cobrança do Lake Formation tem exatamente três itens cobráveis em out de 2026, e nenhum deles é uma permissão. A Storage API, o mecanismo server-side independente de filtragem usado quando nenhum serviço de analytics da AWS processa os dados, cobra "pelo número de bytes varridos pela Storage API, arredondado para o próximo megabyte, com um mínimo de 10MB"; as Governed Tables cobram por arquivo rastreado, por chamada de API de metadados e por byte processado pelo otimizador de storage; e o próprio otimizador de storage cobra por byte. Grants, revogações, LF-Tags, sharing entre contas e a aplicação por Athena, Redshift, Glue e EMR são todos $0 (página de preços do Lake Formation, acesso em 2026-10-11).

---

2. Registrado no LF versus híbrido: os dois modos de permissão

Um objeto do Data Catalog tem duas perguntas ortogonais, e a maior parte da confusão sobre Lake Formation vem de responder apenas uma delas:

2.1 Registro: para que serve a role

"Quando você registra uma localização, você especifica uma role do IAM que concede permissões de leitura/escrita naquela localização. O Lake Formation assume aquela role ao fornecer credenciais temporárias aos serviços AWS integrados.": Guia do Desenvolvedor do LF, Set up AWS Lake Formation (acesso em 2026-10-11)

Consequências práticas:

• a role de registro, não o chamador, detém as permissões duráveis de s3:*;
• os chamadores ainda precisam da permissão de IAM lakeformation:GetDataAccess, e "você deve definir o parâmetro Resource como *": qualquer outro valor de recurso não é suportado;
• registrar um prefixo cobre toda tabela sob esse caminho de uma vez, porque "várias tabelas podem compartilhar um prefixo S3. Quando você registra uma localização, todas as tabelas sob aquele caminho recebem emissão de credenciais de uma vez" (guia de melhores práticas do Lake Formation publicado pela AWS, acesso em 2026-10-11).

2.2 Modo de acesso híbrido: dois caminhos, principais com opt-in

"O modo de acesso híbrido do AWS Lake Formation suporta dois caminhos de permissão para os mesmos objetos do AWS Glue Data Catalog." … "O modo de acesso híbrido aplica apenas as permissões CREATE_TABLE, CREATE_PARTITION, UPDATE_TABLE por default." … "principais com opt-in exigirão tanto permissões do Lake Formation quanto permissões de IAM para acessar os dados, enquanto principais sem opt-in continuarão a acessar dados usando apenas permissões de IAM.": Guia do Desenvolvedor do LF, Hybrid access mode (acesso em 2026-10-11)

Aquela última frase é o modo inteiro: híbrido é um switch por principal, não por conta, e é a ferramenta de migração reversível que a AWS recomenda:

"Para facilitar a transição das permissões de data lake de um modelo de IAM e Amazon S3 para permissões do Lake Formation, recomendamos que você use o modo de acesso híbrido para o Data Catalog.": Guia do Desenvolvedor do LF, Set up AWS Lake Formation (acesso em 2026-10-11)

2.3 Exemplo resolvido E2: levando uma role ao modo híbrido

Verificações: (a) o analista com opt-in que tem uma política de IAM mas sem grant de LF agora falha, prova de que a porta dupla está ativa; (b) a role sem opt-in continua lendo só com IAM, prova de que o modo é por principal; (c) IsRegisteredWithLakeFormation na tabela é true na visão do principal com opt-in e inalterado para todo mundo mais.

• 📚 Você sabia? Os knobs no nível da conta que mantêm um database novo no plano antigo têm nomes exatos no console: Use only IAM access control for new databases e Use only IAM access control for new tables in new databases, respaldados na API por CreateDatabaseDefaultPermissions e TableDefaultPermissions, cujo default entregue é [{"Principal":{"DataLakePrincipalIdentifier":"IAM_ALLOWED_PRINCIPALS"},"Permissions":["ALL"]}] (Guia do Desenvolvedor do LF, Changing the default settings for your data lake e a API DataLakeSettings, acesso em 2026-10-11). A AWS deliberadamente não chama esse estado de "IAMOnly" em lugar algum: ensine os nomes documentados.

---

3. A escada de granularidade de permissões

3.1 O vocabulário

Tipos de recurso nos quais você pode conceder: Catalog, Database, Table, View, DataLocation (apenas DATA_LOCATION_ACCESS se aplica), LF_Tag, LF_TagPolicy / LFTagExpression.

O enum de permissões, conforme retornado por ListPermissions (referência da API do LF, acesso em 2026-10-11):

Três regras sobre essa lista:

• SELECT, INSERT e DELETE são tanto permissões do Data Catalog quanto permissões de acesso a dados: são as que chegam ao S3.
• Super é aditivo e sobrevive a revogações parciais: "quando você revoga Super, as permissões SELECT e INSERT permanecem" (Guia do Desenvolvedor do LF, Access control for metadata, acesso em 2026-10-11).
• Conceder em todas as tabelas de um database concede implicitamente DESCRIBE nesse database, mas "essa concessão automática de permissão DESCRIBE não se aplica ao usar controle de acesso baseado em atributos (ABAC)".

3.2 A escada, desenhada

Tudo abaixo de TABLE é expresso por apenas dois mecanismos: um filtro de coluna no próprio grant (TableWithColumns) ou um objeto de data filter (DataCellsFilter). Escolha entre eles com uma pergunta: eu preciso de linhas também?

3.3 Exemplo resolvido E3: a escada de quatro grants em uma tabela

Números em out de 2026: um data filter precisa de SELECT com a grant option em todas as colunas da tabela para ser criado; não há teto de filtros por tabela, mas há um limite de 100 data filters por principal por uma única tabela; e a expressão de linha deve ter menos de 2.048 caracteres (Guia do Desenvolvedor do LF, Data filtering limitations e suporte a PartiQL, acesso em 2026-10-11).

• 📚 Você sabia? Três tetos valem a pena decorar porque são todos pequenos: 30 administradores de data lake por conta por default, 1.000 expressões de LF-Tag salvas por conta, e 100 data filters por principal por tabela (Guia do Desenvolvedor do LF, Set up AWS Lake Formation, Managing LF-Tag expressions e Data filtering limitations, todos com acesso em 2026-10-11). Um quarto, mais brando: o exemplo resolvido baseado em tags da própria AWS chega a 17 permissões efetivas a partir de apenas 5 atribuições de tag mais 8 grants de tag.

---

4. Segurança em nível de linha e de coluna: a política de analista resolvida

4.1 A combinatoria: três controles, um tipo de objeto

"Lake Formation usa filtragem de dados para alcançar segurança em nível de coluna, de linha e de célula." … "Quando você especifica o curinga 'todas as colunas' e fornece uma expressão de row filter, você está estabelecendo apenas segurança em nível de linha (filtragem de linha)." … "Quando você inclui ou exclui colunas e colunas aninhadas específicas e especifica 'todas as linhas' … você está estabelecendo segurança em nível de coluna." … "Quando você inclui ou exclui colunas específicas e também fornece uma expressão de row filter, você está estabelecendo segurança em nível de célula.": Guia do Desenvolvedor do LF, Data filtering and cell-level security (acesso em 2026-10-11)

Duas clarificações que economizam tempo real de depuração:

• Filtrar coluna não é mascarar. Excluir salary remove dos resultados e dos metadados de catálogo daquele principal. Nunca retorna um valor mascarado. Se o requisito é "mostrar apenas os quatro últimos dígitos", isso é uma view, uma transformação em camada de aplicação, ou o dynamic data masking do Amazon Redshift: não Lake Formation.
• Disponibilidade: "Cell-level security is available in all regions when using Athena engine version 3 or Amazon Redshift Spectrum." (Guia do Desenvolvedor do LF, Data filtering limitations, acesso em 2026-10-11.)

4.2 A linguagem do row filter: subconjunto do PartiQL, com arestas duras

4.3 Exemplo resolvido E4, a política de analista: gold.sales menos salary, linhas = region='eu'

Isto é segurança em nível de célula em um único objeto de data filter, mais o grant de visibilidade que o torna utilizável.

Quatro verificações de aprendiz, e o que cada uma prova:

Contraste (mais barato, mais estreito): conceder TableWithColumns com ExcludedColumnNames = ["salary"] entrega as colunas e nenhuma linha: uma resposta legítima quando o requisito é apenas "esconder PII", e o padrão que a FanDuel usou no Caso B abaixo. Adicionar region = 'eu' é o que te força a um data filter.

---

5. LF-Tags e controle de acesso baseado em tags (LF-TBAC)

5.1 O que é uma tag

"Cada LF-Tag é um par chave-valor, como department=sales ou classification=restricted. Uma chave pode ter múltiplos valores definidos.": Guia do Desenvolvedor do LF, Tag-based access control (LF-TBAC) (acesso em 2026-10-11)

Tags se anexam a databases, tabelas e colunas. Elas devem ser pré-definidas (uma chave e seus valores são criados com CreateLFTag antes que qualquer coisa possa carregá-las), e são o único mecanismo desta lição que deixa você conceder em um atributo em vez de em um objeto nomeado.

5.2 Herança e as regras de correspondência

"Tabelas herdam LF-Tags de databases e colunas herdam LF-Tags de tabelas. Valores herdados podem ser sobrescritos" … "as chaves de tag são combinadas usando a operação AND, enquanto os valores são combinados usando a operação OR.": Guia do Desenvolvedor do LF, Tag-based access control (LF-TBAC) (acesso em 2026-10-11)

As duas regras de combinação, enunciadas uma vez e testadas para sempre:

• Chaves diferentes em um único grant são combinadas com AND: owner = data-platform AND class = internal corresponde apenas a recursos que carregam ambas.
• Múltiplos valores da mesma chave são combinados com OR: class = internal OR class = restricted corresponde a qualquer um.
• Exemplo dos docs: a expressão de tag content_type:Sales AND location:US "representa recursos relacionados a dados de vendas nos EUA"; expressões de LF-Tag salvas têm teto de 1.000 por conta.

5.3 Três coisas que o TBAC muda no granting

1. Você concede na tag, não na tabela. O recurso do grant do principal é uma LFTagPolicy (ou uma LFTagExpression), então tabelas criadas depois, incluindo tabelas criadas por crawler, são cobertas automaticamente uma vez que herdam a tag.
2. Você pode conceder a capacidade de taggear. ASSOCIATE deixa um principal anexar uma tag; DESCRIBE deixa-o vê-la; GRANT_WITH_LF_TAG_EXPRESSION deixa-o usá-la como recurso de grant. Esta é a primitiva de delegação por trás dos data meshes.
3. Permissões de todos os métodos são unidas. O próprio conselho de migração da AWS: "(Recomendado) Depois de verificar que os principais têm acesso aos recursos corretos pelo método LF-TBAC, revogue as permissões que foram concedidas usando o método de recurso nomeado." Verifique primeiro, revoke depois: nunca o inverso.

5.4 Exemplo resolvido E5: reconstruindo a compressão da IAS com três tags

Leitura: o custo da rota de tags é plano no número de tabelas e linear no número de políticas; a rota nomeada é linear em tabelas × principais. A IAS reportou a versão real disso: "Com os controles de acesso baseados em tags do Lake Formation, a IAS reduziu centenas de regras de permissão a precisamente duas regras" (AWS Big Data Blog, 2021-09-23). Observe onde a lista de exceções pousa: row filters são exatamente a funcionalidade que não pode ser dirigida por tags, então um patrimônio TBAC sempre carrega uma cauda curta e deliberada de recurso nomeado.

Passe o mouse sobre um par de barras: grants de recurso nomeado escalam como principais × tabelas (derivado: 4 × 6 = 24 até 4 × 36 = 144), enquanto a rota de tags permanece em 6 atribuições + 4 grants = 10 independentemente da contagem de tabelas (derivado da forma da IAS de duas chaves aplicadas no nível do database). A curva de cruce é imediata, a rota de tags já é menor com seis tabelas, e é por isso que o exemplo baseado em tags da AWS é citado como simplificação operacional e não como uma funcionalidade de segurança.

---

6. Data sharing: bancos de dados entre contas, motores externos, callers confiáveis

6.1 Bancos de dados entre contas passam pelo AWS RAM

"O Lake Formation usa o serviço AWS Resource Access Manager (AWS RAM) para compartilhar o recurso. Se a conta de grantee está na mesma organização que a conta de grantor, o recurso compartilhado fica disponível imediatamente; se a conta de grantee não está na mesma organização, o AWS RAM envia um convite para a conta de grantee aceitar ou rejeitar o grant do recurso.": Guia do Desenvolvedor do LF, Cross-account data sharing (acesso em 2026-10-11)

Existem dois métodos de grant, e a AWS recomenda um deles por nome: controle de acesso baseado em tags do Lake Formation (LF-TBAC) (recomendado) versus recursos nomeados. O blog que documenta o trade-off diz isso simplesmente: TBAC "é recomendado quando muitos recursos e entidades estão envolvidos."

Pré-requisitos que são falhas duras, não conselhos (Guia do Desenvolvedor do LF, Cross-account prerequisites, acesso em 2026-10-11):

1. Revogue todas as permissões do Lake Formation de IAMAllowedPrincipals no recurso primeiro: caso contrário o Lake Formation lança AccessDeniedException.
2. O grantor deve deter a política gerenciada pela AWS AWSLakeFormationCrossAccountManager.
3. Pelo menos um usuário na conta consumidora deve ser um administrador de data lake para ver os recursos compartilhados; "outros principais não podem acessar recursos compartilhados até que o administrador de data lake conceda permissões a eles."
4. Grants entre contas devem carregar a grant option, porque o admin do lado do consumidor re-concede localmente. "O principal que recebe o resource share não pode compartilhar o recurso com outros principais."

Configurações de versão de cross-account (DataLakeSettings.Parameters.CROSS_ACCOUNT_VERSION) decidem o que pode ser compartilhado: grants diretos para um principal IAM individual em outra conta precisam de versão ≥ 3; shares no modo híbrido precisam de ≥ 4; a versão 5 "melhora o sharing de recursos entre contas, permitindo que você compartilhe um número ilimitado de tabelas para outra conta, eliminando os limites anteriores de associação de recurso por tipo de recurso", está disponível "por meio do console ou da API do Lake Formation", e o downgrade não é suportado uma vez aplicada (AWS What's New, 2026-02-11; Guia do Desenvolvedor do LF, acesso em 2026-10-11).

6.2 Exemplo resolvido E6: compartilhando gold.sales para uma conta externa

Verificações: (a) um grant tentado enquanto IAMAllowedPrincipals ainda detém Super falha com AccessDeniedException; (b) um grant sem --permissions-with-grant-option deixa o admin do consumidor incapaz de conceder nada aos próprios analistas; (c) conceder apenas no link deixa a tabela invisível para as consultas: grant no link ≠ grant no alvo.

6.3 Callers confiáveis e o toggle de motor externo

Lake Formation emite credenciais temporárias apenas para callers confiáveis. "Cada um desses serviços AWS é um caller confiável para o Lake Formation, e o Lake Formation fornece acesso aos dados armazenados no Amazon S3 por meio de credenciais temporárias", o conjunto integrado sendo Athena, Redshift Spectrum, EMR e Glue (Guia do Desenvolvedor do LF, Working with services, acesso em 2026-10-11).

Qualquer outra coisa é opt-in, e o opt-in é um switch de três partes em DataLakeSettings:

"Se você pretende analisar … usando motores de consulta de terceiros, você deve dar opt-in para permitir que motores externos acessem dados gerenciados pelo Lake Formation.": Guia do Desenvolvedor do LF, Set up AWS Lake Formation (acesso em 2026-10-11)

Uma discrepância de documentação para ser honesto: a referência da API DataLakeSettings mostra um exemplo de chave de session tag LakeFormationTrustedCaller, enquanto o guia de motores de terceiros e o blog de aplicação personalizada ambos especificam LakeFormationAuthorizedCaller. Duas fontes dizem a segunda, então use-a, mas não trate nenhum dos dois nomes como incontestado.

6.4 Acesso gerenciado e os papéis de administrador

Duas assimetrias que valem a pena internalizar:

• Admin adicionado depois = zero acesso implícito a dados. "administradores de data lake adicionados depois da criação do database podem conceder permissões mas não recebem automaticamente permissões de acesso a dados como SELECT ou DESCRIBE. Administradores que criam databases recebem permissões SUPER naqueles databases."

• Acesso gerenciado é expresso como a grant option. O padrão, uma equipe de plataforma segurando PermissionsWithGrantOption e equipes de domínio re-concedendo dentro de um escopo, é como o self-service "grantable" funciona sem entregar o catálogo inteiro.

• 📚 Você sabia? A role de registro e a service-linked role são uma escolha real de design: o Lake Formation entrega uma service-linked role (ServiceRoleForLakeFormationDataAccess) para registro sem configuração, mas o guia de melhores práticas da AWS recomenda registrar com uma role de gestão do cliente quando você espera editar ou limitar o escopo dessa role depois. De qualquer forma o chamador ainda precisa de lakeformation:GetDataAccess com Resource: "*", e adicioná-la é "um no-op quando nenhuma localização está registrada, então é seguro (e recomendado) adicioná-la desde o início" (guia de melhores práticas do Lake Formation publicado pela AWS, acesso em 2026-10-11).

---

7. Matriz de suporte de motores: quem realmente aplica o quê

"a filtragem real de colunas nas respostas de consulta é responsabilidade do serviço integrado. Clientes do Lake Formation que suportam filtragem em nível de coluna, incluindo Amazon Athena, Amazon Redshift Spectrum e Amazon EMR, filtram os dados com base nas permissões de coluna registradas no Lake Formation": Guia do Desenvolvedor do LF, Limitations (acesso em 2026-10-11)

7.1 Exemplo resolvido E7: posicionando oito motores na matriz

Regra de bolso derivada da matriz: Lake Formation publica metadados filtrados e credenciais com escopo; o motor poda a resposta. Qualquer motor fora dessa lista ou recusa a consulta: ou, pior, retorna dados não filtrados se você concedeu o opt-in de motor externo.

• 📚 Você sabia? A integração do QuickSight tem um split de edição fácil de perder: a edição Enterprise deixa você "conceder permissões de controle de acesso fino (FGAC) a usuários e grupos individuais do QuickSight", enquanto os grants da edição Standard vão para roles de IAM, com a service role default chamada aws-quicksight-service-role-v0. Uma vez que o bucket de origem está registrado, "as configurações de acesso ao Amazon S3 no QuickSight são ignoradas, incluindo políticas de IAM de escopo reduzido para usuários e grupos": Lake Formation vira a fonte única de verdade (documentação do QuickSight e do AWS Big Data Blog, acesso em 2026-10-11).

---

8. O padrão IAMAllowedPrincipals, e a migração a partir dele

8.1 Por que seus grants parecem não fazer nada

"O Lake Formation define a permissão Super em todos os databases e tabelas do Data Catalog para um grupo chamado IAMAllowedPrincipals por default. Se essa permissão de grupo existir … todos os principais da sua conta terão acesso ao recurso através das políticas de principal do IAM para o AWS Glue.": Guia do Desenvolvedor do LF, Permissions reference (acesso em 2026-10-11)

E a consequência, enunciada igualmente diretamente:

"Essas configurações efetivamente fazem com que o acesso a recursos do Data Catalog e a localizações do Amazon S3 seja controlado exclusivamente por políticas do AWS Identity and Access Management (IAM). Permissões individuais do Lake Formation não estão em vigor.": Guia do Desenvolvedor do LF, Changing the default settings for your data lake (acesso em 2026-10-11)

Então o estado default de um lake novo ou longamente não modificado é: Lake Formation instalado, mas desligado. Os seus brilhantes grants são registrados, auditados e ignorados.

8.2 Exemplo resolvido E8: a migração documentada, ensaiada

---

9. O fluxo de verificação de permissão: uma árvore de decisão

Isto espelha o workflow de acesso híbrido documentado do Lake Formation e é a maneira mais rápida de transformar "não funciona" em uma única verificação.

Leia como uma ordem de diagnóstico: registro primeiro, IAMAllowedPrincipals segundo, método de grant terceiro, tipo de direito quarto. Pular direto para "está certo o meu SQL?" é a maneira mais cara de depurar Lake Formation.

---

10. Esboço trabalhado de API e CLI de Grant

10.1 As quatro formas de chamada que você realmente vai escrever

10.2 Exemplo resolvido E9: lendo de volta um grant corretamente

Nota de design: porque não existe statement de deny no Lake Formation, o menor privilégio significa não conceder nada por default e tratar cada novo grant como um evento de alargamento que deve ser reauditado. ColumnWildcard.ExcludedColumnNames apenas estreita o direito no qual é escrito.

---

Atualizações de 2026 (em outubro de 2026)

• 📚 Você sabia? Duas dessas atualizações são silenciosamente estruturais para esta lição. ABAC (controle de acesso baseado em atributos via tags) foi formalmente documentado em 2025-04-17, e é por isso que grants de expressão de tag agora aparecem ao lado de grants de recurso nomeado na mesma lista de permissões; e o pôr do sol das Governed Tables significa que qualquer requisito de "sharing ACID governado" deve agora ser respondido com Iceberg mais grants do Lake Formation, não com um tipo de tabela aposentado.

---

Casos Reais

A AWS publica como esses modelos de permissão se parecem em escala de produção. Todo número abaixo é afirmação do cliente ou da AWS e não auditado, com a fonte e a data nomeadas para que você possa verificar, o ponto examinável é o padrão, não o marketing.

Caso A, Integral Ad Science: centenas de regras de permissão reduzidas a duas

O padrão examinável: o ganho real do TBAC é operacional. Uma ontologia de um punhado de tags herdadas substitui uma matriz ingovernável de grants por tabela: a aritmética da Seção 5.4 em produção. Observe também o que a IAS não pulou: controles em nível de coluna mais tagging carregaram a resposta de conformidade, e o grant de tag ainda precisava coexistir com quaisquer exceções em nível de linha que o negócio exigisse.

Caso B, FanDuel: grants de coluna em vez de mascaramento baseado em cópia

O padrão examinável: grants em nível de coluna matam o mascaramento baseado em cópia. O requisito "esconder PII dos analistas em geral" é satisfeito por uma exclusão TableWithColumns em uma tabela catalogada: sem segunda cópia dos dados, sem ritual de tagging por fonte. Esta é a alternativa mais barata da Seção 4, e é por isso que a FanDuel nunca precisou de row filters para aquele problema em particular.

Caso C, Morningstar: uma ontologia de tags, dois planos de aplicação

O padrão examinável: a ontologia de tags é portátil, a aplicação não é. O Redshift suporta direitos baseados em recurso mas não baseados em tag, então uma equipe que quer um único modelo de governança deve construir a tradução: que é precisamente o limite que a matriz de motores da Seção 7 está desenhando.

• 📚 Você sabia? Todos os três casos datam de 2020 to 2023 e devem ser apresentados dessa forma: os 8,5 milhões de clientes da FanDuel e o "centenas → duas regras" da IAS são snapshots daquelas implantações na época em que a AWS os publicou, não estados atuais daquelas plataformas. As alegações de arquitetura deles, grants de coluna, tags herdadas, um workgroup por unidade de negócio, permanecem os padrões documentados; os números deles são históricos.

---

Perguntas de Prática (Practice Questions)