Em qualquer pipeline de dados, duas perguntas fundamentais sempre surgem: "Quem está tentando acessar isso?" e "O que essa pessoa ou serviço pode fazer?" Esses são os dois pilares da segurança na nuvem — autenticação e autorização. Pense nisso como a entrada em um prédio de escritórios seguro: passar seu crachá na porta é autenticação (prova quem você é), e o fato de que seu crachá só abre certas portas é autorização (define o que você pode acessar). Para o exame DEA-C01, dominar esses dois conceitos é essencial, pois quase toda questão de segurança remonta a um deles ou a ambos.
Autenticação — Provando Quem Você É
Em pipelines de dados, os serviços precisam se autenticar entre si constantemente. O Glue precisa ler do S3. O Lambda precisa escrever no DynamoDB. O EMR precisa processar arquivos no S3. Nada disso pode acontecer sem verificação de identidade. E na maioria dos casos, não é uma pessoa fazendo login — é um serviço AWS provando sua identidade para outro serviço.
Roles IAM — O Sistema de Delegação para Serviços
IAM (Identity and Access Management) é o sistema de identidade central da AWS. Enquanto os usuários IAM são contas para pessoas acessarem o console, os roles IAM são identidades temporárias que os serviços AWS tomam emprestadas para agir em seu nome. Pense em um role como uma carta de autorização assinada: "Este job do Glue está autorizado a acessar o bucket S3 X em nome da nossa equipe."
Quando um job ETL do Glue começa, ele assume um role IAM. Esse role declara "tenho permissão para ler do S3, escrever logs no CloudWatch e acessar o Catálogo de Dados do Glue." Sem o role, o Glue não pode fazer absolutamente nada — a AWS nega todo acesso por padrão.
Padrões comuns de roles IAM em engenharia de dados:
| Cenário | Tipo de Role | Propósito | |---------|-------------|-----------| | ETL do Glue lê/escreve S3 | Role de serviço do Glue | Glue assume este role para acessar S3 e o Catálogo Glue | | Lambda escreve no DynamoDB | Role de execução do Lambda | Lambda usa para interagir com o DynamoDB | | EMR processa dados do S3 | Perfil de instância EC2 | Anexado a cada nó EC2 no cluster | | Step Functions chama Lambda e Glue | Role de execução do Step Functions | O orquestrador precisa de permissão para acionar serviços filhos |
A conclusão mais importante: cada interação serviço-a-serviço na AWS requer um role IAM. Se um pipeline falha com "Access Denied", a primeira coisa a investigar é se o role IAM existe, está corretamente anexado e tem as permissões certas para o recurso específico.
Segurança de Rede VPC — Controlando por Quais Caminhos os Dados Trafegam
A autenticação responde "quem é você", mas a segurança de rede responde "por qual caminho você deve chegar aqui". Uma VPC (Virtual Private Cloud) é sua própria rede privada dentro da AWS — um espaço isolado, separado da internet pública.
Por padrão, quando uma instância EC2 ou função Lambda fala com o S3, esse tráfego viaja pela internet e retorna. Isso expõe sua transferência de dados e gera custos de transferência. Os VPC Endpoints resolvem isso roteando o tráfego completamente pela rede interna da AWS.
Dois tipos de VPC endpoints são essenciais para engenharia de dados:
Gateway Endpoints são gratuitos e servem para S3 e DynamoDB. Você adiciona uma entrada de rota na tabela de roteamento, e todo tráfego para S3 ou DynamoDB de dentro daquela VPC flui automaticamente pela rede interna da AWS.
Interface Endpoints (PrivateLink) funcionam para a maioria dos outros serviços, incluindo Glue, KMS, Secrets Manager, Kinesis, SQS e mais. Eles provisionam um endereço IP privado dentro da sua VPC que conecta diretamente ao serviço AWS. Há um pequeno custo por hora, mas o benefício de segurança é significativo.
Security Groups funcionam como firewalls virtuais em torno de recursos de computação como EC2, clusters EMR e clusters Redshift. Para um cluster Redshift, uma configuração típica permite apenas a porta 5439 de entrada do CIDR da VPC da equipe de análise, e apenas saída para o VPC endpoint do S3.
O AWS PrivateLink estende esse conceito para cenários entre contas. Se sua plataforma de dados precisa expor um serviço para uma conta consumidora, o PrivateLink cria um link privado entre elas — sem internet, sem VPN, sem exposição.
Gerenciamento de Credenciais — Nunca Coloque Senhas no Seu Código
Pipelines de dados frequentemente precisam se conectar a bancos de dados externos, APIs de terceiros ou sistemas locais. Codificar essas credenciais diretamente no código-fonte é um erro grave de segurança — elas acabam no histórico do Git, em arquivos de log ou em imagens de contêiner.
O AWS Secrets Manager é a solução correta para credenciais sensíveis que precisam ser rotacionadas regularmente. Sua característica mais importante é a rotação automática. Suponha que sua política de segurança exige que todas as senhas de banco de dados sejam trocadas a cada 90 dias. O Secrets Manager cuida disso completamente sozinho: invoca uma função Lambda que muda a senha no banco de dados (RDS, Redshift, DocumentDB), atualiza o segredo armazenado, e seu pipeline recupera automaticamente as credenciais atualizadas na próxima conexão.
O AWS Systems Manager Parameter Store é uma alternativa mais leve para configurações que não precisam de rotação automática. Armazena tanto valores em texto simples quanto valores criptografados usando o tipo SecureString, respaldado pelo KMS.
| Recurso | Secrets Manager | Parameter Store | |---------|----------------|----------------| | Rotação automática | Sim, via integração com Lambda | Não | | Custo | $0,40 por segredo por mês | Grátis para parâmetros padrão | | Melhor caso de uso | Senhas de BD, chaves de API | Config de apps, variáveis de ambiente | | Acesso entre contas | Sim | Sim |
!Autenticação vs autorização
Autorização — Decidindo o Que Você Tem Permissão para Fazer
Uma vez confirmada a identidade, a autorização determina quais ações essa identidade pode realizar. A AWS implementa a autorização por meio de políticas IAM e controles de acesso específicos de cada serviço.
Políticas IAM — As Regras Escritas das Permissões
Uma política IAM é um documento JSON que declara explicitamente "permitir ou negar estas ações nestes recursos." As políticas são anexadas a roles, usuários ou grupos.
Três padrões de políticas aparecem constantemente em engenharia de dados:
Políticas de role de serviço são anexadas aos roles IAM que os serviços assumem. Uma política de role de serviço do Glue tipicamente concede s3:GetObject e s3:PutObject em buckets S3 específicos, acesso de escrita ao CloudWatch Logs, e leitura do Catálogo de Dados do Glue.
Políticas de recursos são anexadas diretamente a um recurso em vez de a uma identidade. Uma política de bucket S3 pode dizer "este bucket só permite leituras do ARN de role X" ou "permite acesso da conta AWS 123456789012." As políticas de recursos são críticas para acesso entre contas.
O princípio do menor privilégio é a prática de segurança mais importante: conceder apenas as permissões absolutamente necessárias, com o escopo mais estreito possível. Em vez de conceder s3:GetObject em todos os buckets, limite ao bucket e prefixo específicos que o job realmente precisa.
Permissões do Lake Formation — Controle de Acesso Granular para o Data Lake
O AWS Lake Formation fornece governança centralizada para seu data lake. Ele se situa sobre o S3 e o Catálogo de Dados do Glue e adiciona controle de acesso a nível de coluna, linha e tabela — coisas que as políticas IAM simples não conseguem fazer.
Antes do Lake Formation, controlar o acesso a tabelas do data lake era complexo: era necessário configurar separadamente as políticas IAM, as políticas de bucket S3 e as políticas de recursos do Catálogo Glue. Uma inconsistência entre elas e um usuário poderia acessar dados que não deveria. O Lake Formation consolida tudo isso em um único modelo de permissões.
Níveis de permissões que o Lake Formation suporta:
Nível de banco de dados: conceder a uma equipe acesso a todas as tabelas dentro de um banco de dados Glue específico Nível de tabela: restringir um usuário apenas a tabelas específicas Nível de coluna: ocultar colunas sensíveis como credit_card_number ou ssn Nível de linha: usar filtros de dados para mostrar apenas linhas que atendam a uma condição — por exemplo, uma equipe regional vê apenas linhas onde region = 'us-west'
RBAC (Controle de Acesso Baseado em Roles) concede permissões com base no papel organizacional de uma pessoa. Você define roles como "analista de dados" ou "engenheiro de dados" e anexa permissões a esses roles. Quando um novo funcionário chega, você atribui o role apropriado e ele herda automaticamente todas as permissões.
TBAC (Controle de Acesso Baseado em Tags) usa tags de metadados para combinar recursos com usuários automaticamente. Você tagueia uma tabela com sensitivity=high e tagueia um usuário com clearance=high. O Lake Formation vê as tags correspondentes e concede acesso sem que você precise escrever entradas de permissão individuais para cada combinação tabela-usuário. Com centenas de tabelas e dezenas de equipes, o TBAC reduz drasticamente o trabalho de gerenciamento.
Controle de Acesso no Redshift — A Camada de Segurança do Data Warehouse
O Redshift opera seu próprio sistema de controle de acesso interno além do IAM.
Usuários e grupos do Redshift funcionam de forma similar ao PostgreSQL. Dentro do banco de dados, você cria usuários, os atribui a grupos e usa instruções SQL GRANT para dar aos grupos privilégios SELECT, INSERT ou UPDATE em esquemas ou tabelas específicas.
O Redshift Data Sharing permite que um cluster Redshift (produtor) compartilhe dados em tempo real com outro cluster ou conta AWS (consumidor) sem copiar os dados. O consumidor tem acesso somente leitura. Essa é a arquitetura preferida para separar o data warehouse de produção das cargas de trabalho analíticas.
Quando o Redshift Spectrum é usado para consultar dados no S3 via Catá