 |
Hoje, estamos anunciando controles de criptografia de nuvem privada digital (VPC), um novo recurso de Nuvem privada digital da Amazon (Amazon VPC) que ajuda você a auditar e aplicar a criptografia em trânsito para todo o tráfego dentro e entre VPCs em uma região.
As organizações de serviços financeiros, saúde, governo e varejo enfrentam uma complexidade operacional significativa para manter a conformidade da criptografia em sua infraestrutura de nuvem. As abordagens tradicionais exigem reunir diversas soluções e gerenciar infraestruturas de chaves públicas (PKI) complexas, ao mesmo tempo em que rastreiam manualmente a criptografia em diferentes caminhos de rede usando planilhas — um processo sujeito a erros humanos que se torna cada vez mais desafiador à medida que a infraestrutura é ampliada.
Embora AWS Nitro Como as instâncias baseadas em criptografia criptografam automaticamente o tráfego na camada de {hardware} sem afetar o desempenho, as organizações precisam de mecanismos simples para estender esses recursos por toda a infraestrutura VPC. Isto é particularmente importante para demonstrar a conformidade com estruturas regulatórias, como Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA), Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) e Programa Federal de Gerenciamento de Riscos e Autorizações (FedRAMP), que exigem prova de criptografia de ponta a ponta em todos os ambientes. As organizações precisam de visibilidade e controle centralizados sobre seu standing de criptografia, sem precisar gerenciar compensações de desempenho ou sistemas complexos de gerenciamento de chaves.
Os controles de criptografia de VPC abordam esses desafios fornecendo dois modos operacionais: monitorar e aplicar. No modo monitor, você pode auditar o standing de criptografia dos seus fluxos de tráfego e identificar recursos que permitem o tráfego de texto simples. O recurso adiciona um novo campo de standing de criptografia aos logs de fluxo de VPC, dando visibilidade se o tráfego é criptografado usando criptografia de {hardware} Nitro, criptografia de camada de aplicativo (TLS) ou ambos.
Depois de identificar os recursos que precisam de modificação, você poderá tomar medidas para implementar a criptografia. Serviços da AWS, como Balanceador de carga de rede, Balanceador de carga de aplicativose AWS Fargate tarefas, migrará de forma automática e transparente sua infraestrutura subjacente para o {hardware} Nitro, sem qualquer ação necessária de sua parte e sem interrupção do serviço. Para outros recursos, como a geração anterior de Amazon Elastic Compute Cloud (Amazon EC2) casos, você precisará mudar para moderno baseado em Nitro tipos de instância ou configure a criptografia TLS no nível do aplicativo.
Você pode alternar para o modo obrigatório depois que todos os recursos tiverem sido migrados para uma infraestrutura compatível com criptografia. Essa migração para protocolos de comunicação e {hardware} compatíveis com criptografia é um pré-requisito para ativar o modo de aplicação. Você pode configurar exclusões específicas para recursos como gateways de web ou Gateways NATque não oferecem suporte à criptografia (porque o tráfego flui para fora da rede AWS).
Outro recursos deve ser compatível com criptografia e não pode ser excluído. Após a ativação, o modo de aplicação garante que todos os recursos futuros sejam criados apenas em instâncias Nitro compatíveis e que o tráfego não criptografado seja descartado quando protocolos ou portas incorretos forem detectados.
Deixe-me mostrar como começar
Para esta demonstração, iniciei três instâncias do EC2. Eu uso um como servidor net com Nginx instalado na porta 80, servindo uma página HTML de texto não criptografado. Os outros dois estão continuamente fazendo solicitações HTTP GET ao servidor. Isso gera tráfego de texto não criptografado em minha VPC. eu uso o m7g.medium tipo de instância para o servidor net e um dos dois clientes. Este tipo de instância usa o {hardware} subjacente do Nitro System para criptografar automaticamente o tráfego em trânsito entre instâncias. Eu uso um t4g.medium instância para o outro cliente net. O tráfego de rede dessa instância não é criptografado no nível do {hardware}.
Para começar, habilito os controles de criptografia no modo monitor. No Console de gerenciamento da AWSeu seleciono Suas VPCs no painel de navegação esquerdo, então mudo para o Controles de criptografia VPC guia. eu escolho Criar controle de criptografia e selecione a VPC para a qual desejo criar o controle.
Cada VPC pode ter apenas um controle de criptografia de VPC associado a ela, criando um relacionamento um-para-um entre o ID de VPC e o ID de controle de criptografia de VPC. Ao criar controles de criptografia de VPC, você pode adicionar tags para ajudar na organização e no gerenciamento de recursos. Você também pode ativar o controle de criptografia de VPC ao criar uma nova VPC.
eu entro em um Nome para este controle. Eu seleciono o VPC Eu quero controlar. Para VPCs existentes, preciso começar em Modo monitor, e eu posso ligar Modo de aplicação quando tenho certeza de que não há tráfego não criptografado. Para novas VPCs, posso impor a criptografia no momento da criação.
Opcionalmente, posso definir tags ao criar controles de criptografia para uma VPC existente. No entanto, ao ativar controles de criptografia durante a criação da VPC, tags separadas não podem ser criadas para controles de criptografia de VPC, porque eles herdam automaticamente as mesmas tags da VPC. Quando estou pronto, eu escolho Crie controle de criptografia.
Alternativamente, posso usar o Interface de linha de comando da AWS (AWS CLI):
aws ec2 create-vpc-encryption-control --vpc-id vpc-123456789Em seguida, audito o standing de criptografia da minha VPC usando o console, a linha de comando ou os logs de fluxo:
aws ec2 create-flow-logs
--resource-type VPC
--resource-ids vpc-123456789
--traffic-type ALL
--log-destination-type s3
--log-destination arn:aws:s3:::vpc-flow-logs-012345678901/vpc-flow-logs/
--log-format '${flow-direction} ${traffic-path} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${encryption-status}'
{
"ClientToken": "F7xmLqTHgt9krTcFMBHrwHmAZHByyDXmA1J94PsxWiU=",
"FlowLogIds": (
"fl-0667848f2d19786ca"
),
"Unsuccessful": ()
}Depois de alguns minutos, vejo este tráfego em meus registros:
flow-direction traffic-path srcaddr dstaddr srcport dstport encryption-status
ingress - 10.0.133.8 10.0.128.55 43236 80 1 # <-- HTTP between net shopper and server. Encrypted at hardware-level
egress 1 10.0.128.55 10.0.133.8 80 43236 1
ingress - 10.0.133.8 10.0.128.55 36902 80 1
egress 1 10.0.128.55 10.0.133.8 80 36902 1
ingress - 10.0.130.104 10.0.128.55 55016 80 0 # <-- HTTP between net shopper and server. Not encrypted at hardware-level
egress 1 10.0.128.55 10.0.130.104 80 55016 0
ingress - 10.0.130.104 10.0.128.55 60276 80 0
egress 1 10.0.128.55 10.0.130.104 80 60276 010.0.128.55é o servidor net com tráfego criptografado por {hardware}, servindo tráfego de texto não criptografado no nível do aplicativo.10.0.133.8é o cliente net com tráfego criptografado por {hardware}.10.0.130.104é o cliente net sem criptografia no nível do {hardware}.
O encryption-status campo informa o standing da criptografia do tráfego entre o endereço de origem e de destino:
- 0 significa que o tráfego está em texto não criptografado
- 1 significa que o tráfego é criptografado na camada de rede (Nível 3) pelo sistema Nitro
- 2 significa que o tráfego é criptografado na camada de aplicação (Nível 7, Porta TCP 443 e TLS/SSL)
- 3 significa que o tráfego é criptografado tanto na camada de aplicação (TLS) quanto na camada de rede (Nitro)
- “-” significa que os controles de criptografia de VPC não estão habilitados ou que os AWS Movement Logs não possuem as informações de standing.
O tráfego originado do cliente net na instância que não é baseada em Nitro (10.0.130.104), é sinalizado como 0. O tráfego iniciado a partir do cliente net na instância Nitroased (10.0.133.8) é sinalizado como 1.
Também uso o console para identificar recursos que precisam de modificação. Ele relata dois recursos não criptografados: o gateway da Web e o interface de rede elástica (ENI) da instância que não é baseada no Nitro.
Também posso verificar recursos não criptografados usando a CLI:
aws ec2 get-vpc-resources-blocking-encryption-enforcement --vpc-id vpc-123456789Depois de atualizar meus recursos para oferecer suporte à criptografia, posso usar o console ou a CLI para alternar para o modo de aplicação.
No console, seleciono o controle de criptografia VPC. Então, eu seleciono Ações e Modo de mudança.
Ou a CLI equivalente:
aws ec2 modify-vpc-encryption-control --vpc-id vpc-123456789 --mode implementComo modificar os recursos identificados como não criptografados?
Todos os seus recursos VPC devem oferecer suporte à criptografia de tráfego, seja na camada de {hardware} ou na camada de aplicativo. Para a maioria dos recursos, você não precisa realizar nenhuma ação.
Serviços da AWS acessados por meio de AWS PrivateLink e pontos finais de gateway impor automaticamente a criptografia na camada de aplicativo. Esses serviços aceitam apenas tráfego criptografado por TLS. A AWS descartará automaticamente qualquer tráfego que não esteja criptografado na camada do aplicativo.
Quando você ativa o modo monitor, migramos automática e gradualmente seus Community Load Balancers, Software Load Balancers, AWS Fargate aglomerados, e Serviço Amazon Elastic Kubernetes (Amazon EKS) clusters para {hardware} que suporta criptografia inerentemente. Essa migração acontece de forma transparente, sem nenhuma ação exigida de sua parte.
Alguns recursos da VPC exigem que você selecione as instâncias subjacentes que oferecem suporte à criptografia moderna da camada de {hardware} Nitro. Isso inclui instâncias EC2, Grupos de Auto Scaling, Serviço de banco de dados relacional da Amazon (Amazon RDS) bancos de dados (incluindo Amazon DocumentDB), Clusters baseados em nós do Amazon ElastiCache, Clusters provisionados do Amazon Redshift, Clusters EKS, ECS com capacidade EC2, MSK provisionado, Serviço Amazon OpenSearche Amazon EMR. Para migrar seus clusters Redshift, você deve criar um novo cluster ou namespace a partir de um snapshot.
Se você usar instâncias de geração mais recente, provavelmente já terá uma infraestrutura compatível com criptografia porque todos os tipos de instância recentes oferecem suporte à criptografia. Para instâncias de geração mais antiga que não oferecem suporte à criptografia em trânsito, você precisará atualizar para tipos de instância compatíveis.
O que você deve saber ao usar o AWS Transit Gateway
Quando suas VPCs com controles de criptografia ativados estão conectadas por meio de um Portal de trânsitovocê precisará ativar manualmente os controles de criptografia no Transit Gateway para criptografar o tráfego entre as VPCs. Isso pode ser feito usando o console AWS, o modify-transit-gateway comando ou API. Ativar a criptografia em um Transit Gateway existente não interromperá o fluxo de tráfego entre VPCs anexados ao Transit Gateway.
Quando um Transit Gateway e suas VPCs anexadas têm controles de criptografia no modo forçado (sem exclusões), o tráfego é criptografado de ponta a ponta.
Ao criar um Portal de trânsito através AWS CloudFormation com suporte de criptografia ativado, você precisa de um adicional AWS Id and Entry Administration (IAM) permissão: ec2:ModifyTransitGateway. Essa permissão é necessária porque o CloudFormation usa um processo de duas etapas para criar um Transit Gateway. Primeiro ele cria o Transit Gateway com configuração básica e depois chama ModifyTransitGateway para ativar o suporte à criptografia. Sem essa permissão, sua pilha do CloudFormation falhará durante a criação ao tentar aplicar a configuração de criptografia, mesmo se você estiver executando apenas o que parece ser uma operação de criação.
Preço e disponibilidade
Você pode começar a usar controles de criptografia VPC hoje mesmo nestas regiões da AWS: Leste dos EUA (Ohio, Norte da Virgínia), Oeste dos EUA (Norte da Califórnia, Oregon), África (Cidade do Cabo), Ásia-Pacífico (Hong Kong, Hyderabad, Jacarta, Melbourne, Mumbai, Osaka, Cingapura, Sydney, Tóquio), Canadá (Central), Canadá Oeste (Calgary), Europa (Frankfurt, Irlanda, Londres, Milão, Paris, Estocolmo, Zurique), Oriente Médio (Bahrein, Emirados Árabes Unidos) e América do Sul (São Paulo).
Os controles de criptografia VPC são gratuitos até 1º de março de 2026. O Página de preços de VPC será atualizado com detalhes à medida que nos aproximamos dessa information.
Para saber mais, visite o Documentação de controles de criptografia VPC ou experimente em sua conta AWS. Estou ansioso para saber como você usa esse recurso para fortalecer sua postura de segurança e ajudá-lo a atender aos padrões de conformidade.