Domínios personalizados no WorkSpaces Secure Browser
A AWS lançou um novo recurso para o Amazon WorkSpaces Secure Browser que permite configurar domínios personalizados nos portais de acesso. Ao invés de usar a URL padrão fornecida pela plataforma, as organizações agora podem rotear o acesso através de seu próprio domínio, criando uma experiência muito mais alinhada com a identidade corporativa.
Como funciona a configuração
O processo é relativamente simples para administradores. Basta adicionar o domínio personalizado diretamente no painel do WorkSpaces Secure Browser e configurar um proxy reverso (como o Amazon CloudFront, por exemplo). Uma vez em operação, o tráfego é direcionado através do proxy reverso até o endpoint do portal. Após a autenticação e autorização bem-sucedida, o WorkSpaces Secure Browser redireciona automaticamente os usuários para o domínio personalizado configurado.
Autenticação e integração com provedores de identidade
O serviço oferece flexibilidade quanto à autenticação. É possível usar o AWS Identity Center ou integrar com seu próprio Provedor de Identidade (IdP). O suporte inclui tanto fluxos iniciados pelo IdP quanto pelo provedor de serviço, oferecendo às empresas a liberdade de escolher o modelo de autenticação que melhor se adequa à sua infraestrutura existente.
Disponibilidade e custo
Este recurso está disponível sem nenhum custo adicional em 10 regiões AWS: US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt, London, Ireland) e Asia Pacific (Tokyo, Mumbai, Sydney, Singapore). O WorkSpaces Secure Browser continua operando com modelo de pagamento conforme o uso.
Próximos passos
Para começar a usar domínios personalizados, acesse o console do Amazon WorkSpaces Secure Browser e configure seu domínio no portal. Para detalhes técnicos completos sobre a implementação, consulte a documentação sobre domínios personalizados do WorkSpaces Secure Browser. Você também pode conferir informações sobre o modelo de preço do serviço.
Uma abordagem mais flexível para orquestração de trabalhos
A AWS anunciou uma expansão importante em suas capacidades de agendamento de trabalhos: o AWS Batch agora estende seu suporte para ambientes de computação não gerenciados no Amazon EKS. Essa evolução oferece aos usuários uma alternativa estratégica para quem precisa manter controle total sobre a infraestrutura Kubernetes, seja por razões de segurança, conformidade regulatória ou requisitos operacionais específicos.
O que mudou com os ambientes não gerenciados
Com essa nova capacidade, torna-se possível aproveitar a orquestração inteligente de trabalhos do AWS Batch enquanto mantém controle total sobre como o Kubernetes está configurado e gerenciado. A diferença fundamental é que, em ambientes não gerenciados, você permanece responsável pela infraestrutura de computação do seu cluster EKS, enquanto o AWS Batch cuida da orquestração e agendamento dos trabalhos.
Como configurar ambientes não gerenciados
O processo de configuração é direto. Você pode criar ambientes de computação não gerenciados por meio da API CreateComputeEnvironment ou através do console do AWS Batch. Para isso, é necessário indicar seu cluster EKS existente e especificar um namespace Kubernetes. Após essa configuração inicial, você associa seus nós EKS ao ambiente de computação utilizando rotulagem com kubectl.
Para quem essa funcionalidade é útil
O AWS Batch é projetado para apoiar desenvolvedores, cientistas e engenheiros que precisam executar processamento em lote eficiente em qualquer escala. Os casos de uso incluem treinamento de modelos de aprendizado de máquina, simulações complexas e análises de dados em larga escala. Com a adição de suporte para ambientes não gerenciados, esses profissionais ganham mais flexibilidade para adaptar a solução às suas necessidades específicas de infraestrutura.
Disponibilidade e próximos passos
Os ambientes de computação não gerenciados no Amazon EKS estão disponíveis a partir de agora em todas as regiões onde AWS Batch opera. Para aprofundar seus conhecimentos sobre implementação e melhores práticas, consulte o guia do usuário do AWS Batch.
A AWS anunciou em fevereiro de 2026 que o Lake Formation está agora disponível na região Ásia-Pacífico (Nova Zelândia). Esta expansão geográfica amplia as opções para organizações que precisam manter conformidade regional e reduzir latência ao trabalhar com dados em localidades específicas.
O que é AWS Lake Formation
O Lake Formation é um serviço que simplifica a governança de dados em larga escala. Sua principal função é permitir que você defina centralmente onde seus dados residem e quais políticas de acesso e segurança devem ser aplicadas a eles. Este é um ponto crucial para empresas que lidam com dados sensíveis ou que precisam cumprir regulamentações rigorosas sobre proteção de informações.
Funcionalidades Principais
Gestão Centralizada de Permissões
Uma das características diferenciais do Lake Formation é a capacidade de gerenciar permissões de acesso com granularidade refinada de forma centralizada. Isso significa que você pode controlar precisamente quem tem acesso a quais dados, sem necessidade de configurações complexas e distribuídas por múltiplos sistemas.
Compartilhamento Seguro de Dados
O serviço facilita o compartilhamento seguro de dados dentro e fora da organização. Esta é uma capacidade essencial para empresas que colaboram com parceiros, clientes ou outras unidades de negócio, garantindo que o compartilhamento ocorra dentro de políticas de segurança bem definidas.
Integração com o Catálogo de Dados AWS Glue
O Lake Formation trabalha em conjunto com o AWS Glue Data Catalog (Catálogo de Dados do AWS Glue), um repositório centralizado que descreve os conjuntos de dados disponíveis e suas políticas de uso apropriadas. Os usuários podem acessar este catálogo centralizado para descobrir quais dados estão disponíveis e como utilizá-los adequadamente.
Compatibilidade com Ferramentas Analíticas
Após acessar os dados através do Lake Formation e do catálogo centralizado, os usuários podem trabalhar com esses conjuntos de dados usando diversos serviços de análise e machine learning. A AWS oferece integração com ferramentas como Amazon EMR para Apache Spark, Amazon Redshift, AWS Glue, Amazon QuickSight e Amazon Athena, permitindo flexibilidade na escolha das plataformas analíticas mais adequadas para cada caso de uso.
Próximas Ações
Para aprofundar seus conhecimentos sobre o Lake Formation e suas capacidades, você pode consultar a documentação técnica disponível. Além disso, para verificar a disponibilidade completa do Lake Formation em todas as regiões da AWS, consulte a tabela de regiões e serviços, onde você encontrará informações atualizadas sobre em quais localidades geográficas cada serviço está disponível.
Tabelas Globais do DynamoDB Agora Suportam Multi-Contas
A AWS anunciou uma nova capacidade para as tabelas globais do DynamoDB: suporte a replicação entre múltiplas contas AWS. O DynamoDB global tables é um banco de dados totalmente gerenciado, sem servidor, com suporte multi-região e multi-ativo, utilizado por dezenas de milhares de clientes para potencializar aplicações críticas para seus negócios.
Esta nova funcionalidade permite que as organizações repliquem tabelas tanto entre contas AWS quanto entre regiões, abrindo possibilidades significativas para melhorar a resiliência, isolar cargas de trabalho no nível de conta e aplicar controles distintos de segurança e governança conforme as necessidades específicas de cada departamento ou projeto.
Como Funciona a Replicação Multi-Conta
Com as tabelas globais multi-conta, o DynamoDB replica automaticamente as tabelas entre contas AWS e regiões. Essa capacidade fortalece a tolerância a falhas e contribui para que as aplicações permaneçam altamente disponíveis mesmo durante interrupções no nível de conta.
Simultaneamente, a solução permite que as organizações alinhem a colocação de dados com seus requisitos de segurança e conformidade, respeitando a estrutura organizacional e facilitando a implementação de políticas de isolamento de dados específicas de cada unidade de negócio.
Casos de Uso Ideais
As tabelas globais multi-conta são particularmente relevantes para organizações que adotam estratégias multi-conta ou utilizam o AWS Organizations para:
Melhorar o isolamento de segurança entre ambientes
Aplicar guardrails de perímetro de dados
Implementar estratégias de recuperação de desastres (DR)
Nova capacidade de distribuição de custos no GovCloud (US)
A AWS Network Firewall agora oferece suporte à alocação flexível de custos por meio de anexos nativos do AWS Transit Gateway nas regiões AWS GovCloud (US). Essa funcionalidade permite que as organizações distribuam automaticamente os custos de processamento de dados entre diferentes contas da AWS, resolvendo um dos principais desafios na gestão centralizada de segurança de rede.
Como funciona a alocação flexível
Um dos principais obstáculos para implementar firewalls centralizados é a dificuldade em rastrear quem está usando os recursos e como alocar os custos de forma justa. Anteriormente, todas as despesas ficavam concentradas na conta proprietária do firewall, dificultando a visualização do custo real de cada unidade de negócio ou aplicação.
Com essa nova capacidade, os clientes podem criar políticas de medição para aplicar cobranças de processamento de dados com base nos requisitos de chargeback da organização. Isso significa que em vez de consolidar todas as despesas em uma única conta, as equipes agora conseguem distribuir os custos de inspeção do firewall diretamente para as equipes de aplicação responsáveis pelo consumo.
Benefícios para equipes de segurança e rede
Essa abordagem oferece vantagens significativas para organizações que mantêm controles de segurança centralizados. As equipes de segurança e rede podem agora gerenciar melhor os custos do firewall centralizado distribuindo as cobranças com base no uso real de cada proprietário de aplicação. Simultaneamente, as organizações conseguem manter a centralização dos controles de segurança sem perder a rastreabilidade de despesas.
Outro benefício importante é a eliminação da necessidade de soluções customizadas para gestão de custos. As organizações podem automatizar completamente a alocação de inspeção de custos para as unidades de negócio ou proprietários de aplicação apropriados, simplificando significativamente a operação.
Disponibilidade e como começar
A funcionalidade de alocação flexível de custos está disponível nas regiões AWS GovCloud (US-East) e AWS GovCloud (US-West). Os clientes podem ativar esses recursos através do Console de Gerenciamento da AWS, da Interface de Linha de Comando (CLI) ou do Kit de Desenvolvimento de Software (SDK) da AWS.
Uma informação importante para o planejamento: não há cobranças adicionais pelo uso desse tipo de anexo ou pela alocação flexível de custos, além dos preços padrão do AWS Network Firewall e do AWS Transit Gateway.
Para começar a utilizar a funcionalidade, a AWS disponibiliza documentação técnica completa sobre alocação flexível de custos no serviço Transit Gateway.
Validação Aprimorada de Reivindicações de Identidade
A AWS anunciou uma expansão significativa nas capacidades do Serviço de Token de Segurança (STS – Security Token Service). Agora, o STS suporta validação de reivindicações específicas selecionadas de provedores de identidade externos, incluindo Google, GitHub, CircleCI e Oracle Cloud Infrastructure (OCI).
Essa nova funcionalidade integra-se às políticas de confiança de funções IAM (Gerenciamento de Identidade e Acesso) e políticas de controle de recursos, permitindo federação OpenID Connect (OIDC) para dentro da AWS através da API AssumeRoleWithWebIdentity.
Como Funciona
Controle de Acesso Granular
Com essa capacidade expandida, é possível referenciar reivindicações customizadas como chaves de condição nas políticas de confiança de funções IAM e nas políticas de controle de recursos. Isso significa que arquitetos e administradores de segurança podem implementar controle de acesso muito mais fino para identidades federadas.
Estabelecimento de Perímetros de Dados
A validação granular dessas reivindicações facilita o estabelecimento de perímetros de dados — conceito importante em arquiteturas de segurança em nuvem que definem limites claros de acesso com base em contexto e origem das identidades.
Construindo sobre Fundações Sólidas
Essa melhoria expande as capacidades já existentes de federação OIDC do IAM. Anteriormente, a AWS já oferecia a possibilidade de conceder credenciais temporárias do AWS a usuários autenticados através de provedores de identidade externos compatíveis com OIDC. Agora, com suporte a validação de reivindicações específicas de cada provedor, a segurança e a flexibilidade dessa abordagem avançam consideravelmente.
Disponibilidade e Documentação
A AWS disponibilizou essa funcionalidade em todas as regiões comerciais. Para implementar essa capacidade, os administradores podem consultar a documentação sobre as chaves disponíveis para federação OIDC no Guia do Usuário IAM, que fornece a lista completa de reivindicações suportadas e orientações sobre como utilizá-las em políticas de confiança de funções IAM e políticas de controle de recursos.
Perspectiva para Arquitetos e Administradores
Essa melhoria é particularmente relevante para organizações que utilizam múltiplos provedores de identidade e buscam implementar modelos de acesso mais seguros e específicos por contexto. A capacidade de validar reivindicações específicas de cada provedor (Google, GitHub, CircleCI, OCI) reduz a necessidade de lógica customizada adicional e oferece um caminho mais direto para construir perímetros de segurança bem definidos em ambientes multi-provedor.
Uma Camada Adicional de Segurança para Distribuições CloudFront
A AWS anunciou o suporte para autenticação TLS Mútuo (mTLS) no Amazon CloudFront, um protocolo de segurança que permite aos clientes verificar se as requisições dirigidas aos seus servidores de origem provêm apenas de distribuições CloudFront autorizadas, usando certificados TLS. Esse mecanismo de autenticação baseado em certificados fornece verificação criptográfica da identidade do CloudFront, eliminando a necessidade de os clientes implementarem controles de segurança personalizados.
O Problema com Abordagens Tradicionais
Anteriormente, comprovar que as requisições vinham de distribuições CloudFront exigia que os clientes desenvolvessem e mantivessem soluções de autenticação customizadas. Exemplos dessas abordagens incluem headers de secret compartilhado ou listas de IP permitidas, particularmente quando as origens eram públicas ou hospedadas externamente.
Essas estratégias demandavam sobrecarga operacional contínua: rotação de secrets, atualização de listas de permissão e manutenção de código personalizado. Com o tempo, isso representava um custo significativo em termos de tempo e complexidade da infraestrutura.
Autenticação Padronizada com Certificados
Com o suporte ao mTLS em origens, as organizações podem implementar uma abordagem de autenticação padronizada e baseada em certificados, eliminando esse trabalho operacional. Isso possibilita reforçar uma autenticação rigorosa para conteúdo proprietário, garantindo que apenas distribuições CloudFront verificadas consigam estabelecer conexões com infraestrutura de backend.
Essa infraestrutura pode incluir origens AWS, servidores locais, provedores de nuvem terceirizados e CDNs externos.
A configuração do mTLS em origens pode ser feita através do AWS Management Console, CLI, SDK, CDK ou CloudFormation. O recurso é suportado para todas as origens compatíveis com TLS Mútuo na AWS, incluindo Application Load Balancer e API Gateway, assim como origens on-premises e customizadas.
Custo e Disponibilidade
Não há cobrança adicional pelo uso de mTLS em origens. O recurso também está disponível nos planos de preço fixo Business e Premium.
Conectividade segura entre sua VPC e SageMaker Unified Studio
A AWS anunciou uma nova capacidade que permite estabelecer conectividade entre sua Nuvem Privada Virtual (VPC) e o Amazon SageMaker Unified Studio sem que o tráfego de dados dos clientes seja roteado pela internet pública. Para organizações que precisam ir além do protocolo de transferência de dados padrão (HTTPS/TLS2), agora é possível configurar a VPC de forma que a transferência de dados permaneça completamente dentro da rede AWS.
Como funciona o isolamento de rede
Por meio do AWS PrivateLink, administradores de rede ganham a capacidade de integrar endpoints de serviço AWS à sua VPC, que são utilizados pelo Amazon SageMaker Unified Studio. Após o onboarding desses endpoints, as políticas IAM (Controle de Acesso por Identidade e Acesso) gerenciadas pelo Amazon SageMaker garantem que os dados dos clientes permaneçam confinados dentro da rede AWS, proporcionando segurança adicional e conformidade com requisitos de isolamento de rede.
Disponibilidade global
O acesso privado ao Amazon SageMaker usando AWS PrivateLink está disponível em todas as Regiões AWS onde o Amazon SageMaker Unified Studio é suportado, incluindo:
Ásia Pacífico (Tóquio)
Europa (Irlanda)
Leste dos EUA (N. Virgínia)
Leste dos EUA (Ohio)
Oeste dos EUA (Oregon)
Europa (Frankfurt)
América do Sul (São Paulo)
Ásia Pacífico (Seul)
Europa (Londres)
Ásia Pacífico (Singapura)
Ásia Pacífico (Sydney)
Canadá (Central)
Ásia Pacífico (Mumbai)
Europa (Paris)
Europa (Estocolmo)
Próximos passos
Para implementar essa configuração em seu ambiente, consulte a documentação de isolamento de rede do Amazon SageMaker Unified Studio, que fornece instruções detalhadas para configurar e gerenciar a conectividade privada.
Entendendo as capacidades do serviço gerenciado de Active Directory
O AWS Directory Service para Microsoft Active Directory oferece às organizações a possibilidade de utilizar um Active Directory gerenciado como floresta primária para hospedar identidades de usuários. Essa abordagem permite que os times de infraestrutura continuem utilizando suas competências e aplicações existentes, enquanto a organização se beneficia dos atributos de segurança, confiabilidade e escalabilidade próprios dos serviços gerenciados pela AWS.
O serviço também pode ser configurado como uma floresta de recursos. Nessa topologia, o Active Directory gerenciado funciona como intermediário para serviços AWS compatíveis, enquanto as identidades dos usuários permanecem sob controle exclusivo da organização em um Active Directory auto-gerenciado. Essa flexibilidade arquitetural permite que diferentes cenários de negócio sejam atendidos com segurança.
O desafio do crescimento e escalabilidade
À medida que as organizações expandem suas operações, também crescem as demandas sobre suas infraestruturas de diretório. Workflows mais complexos e um volume maior de usuários exigem que o serviço de Active Directory seja ajustado adequadamente para manter performance e confiabilidade.
A AWS simplifica esse processo de escalabilidade oferecendo duas estratégias principais: scale-up (também chamado de upgrade) e scale-out (expansão do número de instâncias). Compreender quando e como aplicar cada uma dessas estratégias é fundamental para otimizar custos e desempenho.
As duas estratégias de escalabilidade
Scale-up: Upgradando a edição do serviço
O scale-up consiste em atualizar a edição do AWS Managed Microsoft AD de Standard para Enterprise. A edição Enterprise fornece controladores de domínio com maior capacidade computacional e armazenamento ampliado para objetos do Active Directory. Durante um upgrade, o serviço mantém o mesmo número de instâncias de controlador de domínio que havia antes, mas com recursos maiores e quotas aumentadas.
As instâncias são substituídas uma por vez para minimizar interrupções nos workflows de produção. Algumas funcionalidades do serviço são exclusivas da edição Enterprise e requerem esse upgrade obrigatoriamente.
Considere realizar um scale-up quando enfrentar qualquer um destes cenários:
Quando há planos para replicar o diretório em múltiplas regiões AWS. Essa capacidade está disponível apenas na edição Enterprise.
Quando o número de objetos no Active Directory ultrapassará o limite recomendado de 30.000 para a edição Standard. A edição Enterprise suporta até 500.000 objetos.
Quando há necessidade de compartilhar o diretório com mais de 25 contas AWS diferentes. O limite padrão da Standard é 25 contas, enquanto a Enterprise permite 500 contas.
Importante: A atualização de Standard para Enterprise é irreversível e implica um custo horário maior. Por isso, essa decisão deve ser bem planejada.
Scale-out: Adicionando mais controladores de domínio
O scale-out refere-se ao lançamento de controladores de domínio adicionais para o AWS Managed Microsoft AD. Diferentemente do scale-up, essa estratégia pode ser aplicada tanto em diretórios Standard quanto Enterprise. Além disso, cada região pode ser escalada independentemente, não sendo necessário ampliar uniformemente todas as regiões.
Quando uma operação de scale-out ocorre, novas instâncias de controlador de domínio com os mesmos recursos computacionais e capacidade de armazenamento são iniciadas nas mesmas subnets existentes. A vantagem do scale-out é que essa operação pode ser revertida se necessário, ao contrário do scale-up.
Por esse motivo, recomenda-se privilegiar o scale-out como primeira opção, reservando o scale-up apenas para situações em que uma funcionalidade exclusiva da Enterprise seja absolutamente necessária.
Fluxo de decisão para escalabilidade de Active Directory — demonstrando como monitoramento contínuo via CloudWatch guia as decisões entre scale-out e scale-up. Fonte: Aws
Tomando decisões informadas com CloudWatch
Desde dezembro de 2021, o AWS Managed Microsoft AD integra métricas de diretório com Amazon CloudWatch, permitindo uma visão profunda do desempenho do serviço. As métricas do CloudWatch são conjuntos de dados ordenados no tempo que representam indicadores de desempenho e podem ser analisadas ao longo do período para identificar tendências.
Para entender adequadamente o desempenho do diretório, é essencial definir métricas-chave relevantes para sua carga de trabalho no momento da criação do diretório. Os valores iniciais dessas métricas devem ser registrados para estabelecer uma baseline de desempenho. Posteriormente, esses dados devem ser revisitados periodicamente para comparação, permitindo identificar tendências de crescimento e utilização de recursos.
Combinando essas informações — baseline inicial e comparações periódicas — é possível tomar decisões embasadas sobre quando escalar e qual estratégia aplicar. Esse processo cíclico de monitoramento, análise e planejamento é fundamental para manter a eficiência operacional.
Métricas críticas de infraestrutura
A perspectiva de infraestrutura revela três recursos mais comumente constrangidos:
Network Interface: Current Bandwidth — utilização da largura de banda disponível na rede
Processor: % Processor Time — percentual de tempo que o processador está ocupado
LogicalDisk: % Free Space — espaço livre disponível em volumes que armazenam dados do Active Directory
Métricas críticas do Active Directory
A perspectiva do serviço de diretório aponta para métricas como:
NTDS: LDAP Searches/sec — volume de buscas LDAP por segundo
NTDS: ATQ Estimated Queue Delay — atraso estimado na fila de processamento
Matriz de decisão por restrição identificada
Quando uma métrica revela constrangimento de recursos, essa informação orienta diretamente a estratégia de escalabilidade a ser adotada. Por exemplo:
Se % Processor Time estiver elevado → Scale-out
Se I/O Database Reads Average Latency estiver elevada → Scale-out
Se Committed Bytes in Use estiver elevado → Scale-out
Se % Free Space estiver baixo → Scale-up
Como exemplo prático: um alarme do CloudWatch pode ser configurado para disparar quando Processor: % Processor Time ultrapasse 80% por mais de 5 minutos. Disparos frequentes desse alarme indicam que os controladores de domínio têm dificuldade em processar o volume regular de requisições de autenticação de usuários. Nessa situação, um scale-out com um controlador de domínio adicional pode garantir que o Acordo de Nível de Serviço (SLA) seja mantido.
Por outro lado, se LogicalDisk: % Free Space cair abaixo de 10% com tendência de queda contínua, um scale-up para Enterprise Edition pode ser apropriado, já que oferece capacidade maior para objetos do diretório.
Criando um dashboard no CloudWatch
Para facilitar o acompanhamento e análise do desempenho do AWS Managed Microsoft AD, a AWS recomenda usar CloudWatch para construir um dashboard personalizado contendo as métricas mais relevantes.
No painel de navegação, selecione Dashboards e em seguida Criar dashboard.
Na caixa de diálogo de criação, insira um nome para o dashboard e selecione Criar dashboard.
Quando a janela Adicionar widget aparecer, configure como segue:
Em Tipos de fontes de dados, selecione CloudWatch
Em Tipo de dados, selecione Métricas
Em Tipo de widget, selecione Linha
Selecione Próximo
Na janela Adicionar gráfico de métrica, escolha DirectoryService.
Selecione Processor como categoria de métrica e % Processor Time como nome da métrica.
Selecione cada instância da métrica (representada pelo IP do controlador de domínio) para um Directory ID.
Selecione Criar widget.
Nota: Se houver múltiplos diretórios na mesma região, todas as instâncias (IPs dos controladores de domínio) estarão disponíveis para seleção. Recomenda-se criar um dashboard separado para cada diretório, facilitando o monitoramento e gerenciamento de alarmes.
Após criar o primeiro widget, selecione o símbolo de adição (+) no topo da janela para adicionar mais widgets. Repita o processo anterior para incluir as seguintes métricas adicionais:
Processor: % Processor Time
LogicalDisk: % Free Space
Memory: Committed Bytes in Use
Database: I/O Database Reads Average Latency
Network Interface: Current Bandwidth
DNS: Recursive Queries/Sec
Depois de adicionar todas as métricas desejadas, selecione Salvar.
A AWS fornece recomendações de limiares para guiar as decisões de escalabilidade. Estes são valores de referência baseados em casos de uso padrão e podem precisar de ajuste conforme as características específicas de cada organização:
Processor: % Processor Time — Configure alarmes em 80% para um período de 5 minutos. Valores persistentemente elevados sugerem problemas de dimensionamento que podem exigir scale-out.
LogicalDisk: % Free Space — Mantenha pelo menos 25% de espaço livre em volumes contendo dados do Active Directory. Configure alarmes para disparar quando o espaço livre cair abaixo de 20%, pois isso pode impactar severamente as operações do diretório.
Network Interface: Current Bandwidth — A utilização média de rede deve ficar abaixo de 50% da largura de banda disponível durante operações de pico. Configure alarmes em 70% para deixar espaço para picos de atividade. Valores consistentemente elevados sugerem restrições de rede que podem exigir scale-out.
Memory: Committed Bytes in Use — Monitore os níveis de memória comprometida para garantir recursos suficientes. Configure alarmes em 80% do limite de comprometimento. Valores persistentemente elevados podem levar a paginação excessiva, degradando significativamente o desempenho e causando atrasos em autenticações.
Database: I/O Database Reads Average Latency — Mantenha latências médias de leitura abaixo de 25 milissegundos. Configure alarmes em 50 milissegundos. Se latências estiverem consistentemente elevadas, considere um scale-out.
DNS: Recursive Queries/sec — Dada a integração profunda do Active Directory com DNS, use detecção de anomalias do CloudWatch em vez de limiares fixos para identificar comportamentos inesperados que possam indicar problemas de configuração ou preocupações de segurança.
Considerações após escalabilidade
Diferentes componentes da arquitetura podem manter referências aos endereços IP do AWS Managed Microsoft AD. Após uma operação de scale-out que implante controladores de domínio adicionais, essas referências devem ser atualizadas para manter a funcionalidade completa dos workloads.
Referências que podem conter IPs do diretório incluem:
Para manter a funcionalidade completa dos workloads após uma operação de escalabilidade, atualize:
Regras de firewall que permitam tráfego para e dos endereços IP dos controladores de domínio
Regras de endpoint do Route 53 Resolver e forwarders DNS condicionais que encaminhem queries para as instâncias do diretório
Dashboards CloudWatch que exibam dados de métricas do diretório para incluir dimensões dos novos endereços IP
Limpeza de recursos
Os componentes criados durante esse processo geram custos. Para evitar encargos adicionais quando não forem mais necessários:
Remova os endereços IP dos controladores de domínio adicionados das regras de firewall, regras de endpoint do resolver e forwarders DNS condicionais
Exclua os dashboards CloudWatch customizados que não planeja manter
Reverta diretórios escalados para o número anterior de instâncias de controladores de domínio
Conclusão
O monitoramento contínuo do desempenho usando CloudWatch é a base para decisões informadas sobre escalabilidade de diretórios. Combinando baselines de desempenho, análises periódicas e planejamento estruturado, as organizações podem escalar seus diretórios de forma segura e eficiente.
O scale-out do diretório é apropriado quando workflows de Active Directory cresceram ao longo do tempo e a solução necessita de instâncias adicionais de controladores de domínio para manter o SLA do serviço. O scale-up para Enterprise Edition é indicado quando funcionalidades exclusivas dessa edição — como replicação multi-region ou armazenamento ampliado para objetos do diretório — tornam-se necessárias.
A automação não é apenas para implementação de workloads. A AWS recomenda que as organizações também a utilizem para detectar e responder rapidamente a eventos de segurança dentro de seus ambientes. Quando você automatiza respostas, consegue não apenas aumentar a velocidade de detecção e resposta, mas também escalar suas operações de segurança proporcionalmente ao crescimento das suas cargas de trabalho.
Por essa razão, a automação de segurança está incluída como princípio-chave em documentos importantes como o Well-Architected Framework, o AWS Cloud Adoption Framework, e o AWS Security Incident Response Guide. Quando você implementa automação de resposta a eventos de segurança, consegue responder a ameaças em minutos ou até segundos, algo que seria impossível para um engenheiro de plantão.
Entendendo Automação de Resposta à Segurança
Automação de resposta à segurança refere-se a uma ação planejada e programada que busca atingir um estado desejado para uma aplicação ou recurso, baseada em uma condição ou evento específico. Ao implementar essa automação, é recomendado adotar uma abordagem que se baseia em frameworks de segurança estabelecidos.
A solução descrita neste guia utiliza o Framework de Cibersegurança (CSF) do NIST, que ajuda organizações a avaliar e aprimorar sua capacidade de prevenir, detectar e responder a eventos de segurança. Embora automação não seja um requisito do CSF, automatizar respostas a eventos que sabidamente não deveriam ocorrer oferece uma vantagem significativa: a automação consegue agir em segundos, enquanto processos manuais levariam muito mais tempo.
O CSF define cinco etapas principais: identificar, proteger, detectar, responder e recuperar. Para fins deste guia, expandimos as etapas de “detectar” e “responder” para incluir atividades de automação e investigação.
Identificar: Reconhecer e catalogar os recursos, aplicações e dados que existem em seu ambiente AWS.
Proteger: Desenvolver e implementar controles e salvaguardas adequadas para garantir a entrega segura de serviços.
Detectar: Implementar atividades e monitoramento para identificar quando um evento de segurança ocorre.
Automatizar: Criar e programar ações que alcançarão um estado desejado para recursos ou aplicações, baseadas em condições ou eventos.
Investigar: Analisar sistematicamente eventos de segurança para determinar sua causa raiz.
Responder: Tomar ações automáticas ou manuais apropriadas em relação a eventos de segurança detectados.
Recuperar: Manter planos de resiliência e restaurar capacidades que foram afetadas por eventos de segurança.
Como Funciona Automação de Resposta na AWS
A AWS oferece um conjunto de serviços que trabalham juntos para criar fluxos de automação de resposta. O AWS CloudTrail e o AWS Config registram continuamente detalhes sobre usuários, entidades de identidade, recursos com os quais interagiram e mudanças de configuração na sua conta. Quando combinados com o Amazon EventBridge, esses logs podem disparar automações baseadas em eventos, permitindo detecção automática de mudanças e reação a desvios do estado desejado.
Um fluxo de remediação automática na AWS ocorre em três estágios:
Monitorar: Ferramentas de monitoramento automatizado coletam informações sobre recursos e aplicações. Isso pode incluir dados do CloudTrail sobre atividades na conta, métricas de Amazon EC2, ou registros de fluxo sobre tráfego em interfaces de rede da Amazon Virtual Private Cloud (VPC).
Detectar: Quando uma ferramenta de monitoramento detecta uma condição predefinida — como um limite excedido, atividade anômala ou desvio de configuração — um alerta é disparado. Isso pode vir de uma detecção do Amazon GuardDuty, uma violação de regra do AWS Config, ou um alto número de requisições bloqueadas em um grupo de segurança VPC.
Responder: Quando uma condição é detectada, uma resposta automática é acionada para executar uma ação pré-definida. Exemplos incluem modificar um grupo de segurança VPC, fazer patch em uma instância EC2, rotacionar credenciais ou adicionar um endereço IP a uma lista de bloqueio.
Definindo Suas Automações de Resposta
Para começar, identifique requisitos de segurança em seu ambiente que você deseja implementar através de automação. Esses requisitos podem vir de melhores práticas gerais ou de frameworks de conformidade específicos para seu negócio.
Uma abordagem prática é começar pelos run-books que você já usa em seu Lifecycle de Resposta a Incidentes. Run-books simples, como responder a uma credencial exposta (desabilitá-la e notificar a equipe), podem rapidamente ser transformados em automações. Você também pode considerar automações baseadas em recursos — por exemplo, quando uma nova VPC é criada, dispará automação para implantar a configuração padrão de coleta de flow logs.
Seus objetivos devem ser quantitativos, não qualitativos. Por exemplo:
Acesso administrativo remoto a servidores deve ser limitado.
Volumes de armazenamento de servidores devem estar criptografados.
Logins no console AWS devem ser protegidos por autenticação multifator.
Uma técnica útil é expandir esses objetivos em user stories, que descrevem de forma informal a funcionalidade desejada. Por exemplo: “Acesso administrativo remoto deve ser limitado apenas a redes internas confiáveis. Se portas de acesso remoto (SSH porta 22 e RDP porta 3389) forem detectadas e acessíveis a recursos externos, elas devem ser automaticamente fechadas e o proprietário será notificado.”
User stories devem ser armazenadas em um local com controle de versão e devem referenciar o código de automação associado. Também é essencial considerar cuidadosamente o impacto de suas ações de remediação, pois ações como encerramento de instâncias, revogação de credenciais ou modificação de grupos de segurança podem afetar a disponibilidade de aplicações.
Exemplo Prático: Automação para CloudTrail Desabilitado
Para ilustrar esses conceitos, considere este cenário: detectar quando o CloudTrail é desabilitado (uma ação que atores maliciosos realizam para evitar auditoria) e reabilitá-lo automaticamente, notificando a equipe de segurança.
A user story seria: “CloudTrail deve estar habilitado em todas as contas e regiões AWS. Se CloudTrail for desabilitado, será automaticamente reabilitado e a equipe de operações de segurança será notificada.”
Implantando a Automação
Para este exemplo, você usará Amazon GuardDuty e AWS Security Hub — ambos oferecem avaliação gratuita de 30 dias. Quando CloudTrail é desabilitado, GuardDuty gera uma detecção denominada Stealth:IAMUser/CloudTrailLoggingDisabled, que é coletada pelo Security Hub.
A solução utiliza um template CloudFormation que contém uma regra do EventBridge, uma função AWS Lambda e as permissões necessárias. Quando o Security Hub detecta essa situação, publisha um evento no barramento padrão do EventBridge. A regra do EventBridge captura esse evento e invoca uma função Lambda que reabilita o CloudTrail e envia uma notificação via Amazon SNS (Serviço de Notificação Simples da Amazon).
Testando a Automação
Após implantar a solução, você pode testá-la criando um CloudTrail de teste, desabilitando-o propositalmente, e observando a automação reagir. Dentro de alguns segundos, o EventBridge detectará a ação, invocará a função Lambda, que reabilitará o CloudTrail automaticamente e enviará um email para o contato de segurança.
Enquanto isso, GuardDuty realiza uma investigação mais profunda, coletando dados adicionais sobre o endereço IP que executou a ação (verificando, por exemplo, se vem de uma lista de ameaças ou de uma rede incomum). Essa informação é importada no Security Hub, onde pode ser visualizada e correlacionada com outros eventos para análise mais profunda.
Componentes da Automação
O exemplo incorpora dois fluxos de resposta: um em tempo quase real e outro investigativo.
Fluxo em Tempo Quase Real: O Amazon EventBridge monitora atividades indesejadas. Quando um trail do CloudTrail é parado, o CloudTrail publica um evento no barramento do EventBridge. Uma regra do EventBridge detecta esse evento e invoca uma função Lambda para reabilitá-lo e notificar o contato de segurança via SNS.
Fluxo Investigativo: Os logs do CloudTrail são monitorados para atividades indesejadas. GuardDuty detecta quando um trail foi parado e recupera dados adicionais sobre o endereço IP que executou a ação. O Security Hub importa essa informação e a agrega com outras detecções para análise do analista. O Security Hub também publica seus achados no EventBridge, permitindo que outras ferramentas de orquestração de segurança, sistemas SIEM (Gerenciamento de Informações e Eventos de Segurança) e sistemas de ticketing recebam as informações.
Fase de Resposta com EventBridge e Lambda
O Amazon EventBridge é um serviço que fornece acesso em tempo real a mudanças em dados através de serviços AWS, aplicações próprias e aplicações de Software-as-a-Service (SaaS), sem necessidade de escrever código complexo. Neste exemplo, o EventBridge identifica um achado do Security Hub que requer ação e invoca uma função Lambda que realiza a remediação.
Quando o Security Hub publica um achado no EventBridge, a informação vem em formato JSON com detalhes completos. A função Lambda extrai campos relevantes desse JSON — como o ARN (Amazon Resource Name) do trail do CloudTrail — e realiza duas ações: notifica o operador de segurança via SNS e reinicia o CloudTrail para reabilitar o logging.
Um snippet do padrão de evento que o EventBridge procura é:
A função Lambda então extrai informações do achado e executa as ações de remediação. O código Python faz parsing dos campos JSON, notifica a equipe e reinicia o trail do CloudTrail usando a SDK boto3.
Ações Customizadas e Respostas Manuais
Se você preferir não automatizar completamente certas respostas, o Security Hub oferece ações customizadas. Uma ação customizada é um mecanismo do Security Hub para enviar achados específicos ao EventBridge, que pode então ser relacionada a uma regra do EventBridge para executar uma ação específica.
Você pode criar até 50 ações customizadas. Isso permite, por exemplo, que um analista de segurança visualize um achado no console do Security Hub e, com um clique, dispare uma função Lambda para investigação ou remediação manual.
Solução Pronta para Uso: Automated Security Response (ASR)
Para muitas organizações, construir automações de remediação do zero é uma tarefa complexa. Muitos times de operações não possuem recursos ou expertise em scripting e automação. Para isso, a AWS oferece a solução Automated Security Response (ASR) on AWS, que permite que clientes do Security Hub remediassem achados com um clique, utilizando um conjunto de ações predefinidas de resposta e remediação chamadas Playbooks.
As remediações são implementadas como documentos de automação do AWS Systems Manager. A solução inclui remediações para problemas comuns como chaves de acesso não utilizadas, grupos de segurança abertos, políticas de senha fracas em contas, configurações de VPC Flow Logging e buckets S3 públicos.
Os Playbooks incluem remediações para controles de segurança definidos em padrões como AWS Foundational Security Best Practices, Center for Internet Security (CIS) AWS Foundations Benchmark, Payment Card Industry (PCI) Data Security Standard, e NIST Special Publication 800-53.
A solução pode ser implementada e usada sem custos adicionais, porém há custos associados aos serviços AWS que ela utiliza. A biblioteca da solução inclui instruções sobre como criar novas automações em um Playbook existente.
Adicionalmente, a AWS oferece uma biblioteca de soluções com casos de uso e remediações prontas para implantação. O código utilizado neste exemplo também está disponível no GitHub.
Conclusão
Automação de resposta à segurança é um elemento crítico para escalar operações de segurança efetivamente. Ao combinar serviços como CloudTrail, EventBridge, GuardDuty, Security Hub e Lambda, as organizações podem criar fluxos de resposta que reagêm em segundos a eventos indesejados — algo que seria impossível com processos manuais.
O caminho para implementação pode começar com cenários simples baseados em run-books existentes, e evoluir para automações mais complexas conforme sua organização ganha experiência. O importante é começar, testar em ambientes não-produção, e expandir gradualmente o escopo de automações conforme for ganhar confiança.
