Amazon Rede de computadores

Segurança em VPC com Network ACL e Security group

Após criar uma VPC na AWS, não podemos nos descuidar com relação a segurança dessa rede. Existem duas formas de garantir a segurança em VPC no nível de rede: com Network ACL e security groups.

há 3 anos 7 meses

Formação Administrador de redes
Conheça a formação em detalhes

Após criar uma VPC na AWS, não podemos nos descuidar com relação a segurança dessa rede. Existem duas formas de garantir a segurança em VPC no nível de rede: com Network ACL e security groups.

Nesse artigo vamos conhecer como funciona cada um deles e quais suas principais diferenças.

Amazon Web Services (AWS) - Fundamentos
Curso Amazon Web Services (AWS) - Fundamentos
Conhecer o curso

Network ACL

A primeira forma de implementar segurança na camada de rede da nossa VPC é através do Network ACL.

Com ele, você pode definir um conjunto de regras diretamente nas suas subnets, muito parecido com a configuração de um Firewall tradicional, o que acaba sendo uma boa opção para administradores de redes.

Essas regras são compostas pelas seguintes partes:

  • Uma numeração, que define a sequência que as regras são avaliadas;
  • Porta ou range de portas, ou um tipo de serviço tratado nessa regra, como por exemplo, HTTP é um tipo de serviço já conhecido que permite liberar a porta 80;
  • Qual o protocolo de comunicação, como TCP, UDP, entre outros. Essa configuração pode ser definida em conjunto pelo tipo de serviço;
  • Qual a origem ou destino desse tráfego, definido como um endereçamento de CIDR (182.168.0.1/24 por exemplo);
  • Uma ação, seja ela para permitir (ALLOW) ou negar (DENY) o tráfego;
  • Uma descrição amigável para essa regra.

É bom lembrar que o Network ACL funciona tanto para o tráfego de inbound como de outbound.

Entenda como inbound todo tráfego que vai entrar na sua subnet. Por exemplo, ao acessar um servidor web, é enviado uma requisição na porta 80, sendo possível você permitir ou negar essa requisição, dependendo do CIDR de origem. Já o outbound se refere a todo tráfego de saída, como por exemplo, uma requisição enviada para uma API externa, ou a resposta de uma query no banco de dados.

Exemplo de uma Network ACL

Logo abaixo temos um exemplo de configuração de um Network ACL. Ela abrange regras tanto de inbound como de outbound para serviços comuns, como HTTP, HTTPS, SSH e RDP. Além das portas convencionais, em alguns casos vai ser necessário liberar as portas efêmeras, como é o caso da regra 120 de outbound, necessária para utilizar SSH por exemplo.

Regras de Inbound

Regras de Outbound

As portas efêmeras, também conhecidas como portas dinâmicas ou portas altas, são portas utilizadas por um curto período de tempo para a continuação da conexão entre um cliente com um servidor para responder a conexões em uma porta comum (como a porta 22 de SSH). Portanto, tenha em mente que pode ser preciso permitir o tráfego nessas portas, caso seja necessário.

Security group

A segunda forma de implementar segurança na camada de rede na nossa VPC é através dos security group. Ao contrário do Network ACL, as regras de security group são associadas ao nível do recurso. Isso permite a construção de regras mais granulares e funciona de forma mais integrada com um ambiente Cloud, sendo uma forma igualmente segura e amplamente utilizada.

A definição de uma regra de security group é dividida pelas seguintes partes:

  • Um tipo de tráfego, seja um serviço, uma porta ou um range de portas;
  • Um protocolo, sendo os mais utilizados TCP ou UPD;
  • Qual a origem ou destino do tráfego, que pode ser tanto um endereçamento CIDR ou outro security group;
  • Uma descrição amigável.

O security group também funciona tanto para inbound como para outbound, sendo que é mais comum configurar somente o inbound pela forma que o security group funciona.

Exemplo de um security group

Podemos observar abaixo um exemplo de algumas regras em um security group, definindo regras bastante semelhantes das configuradas com Network ACL:

Regras de security group

Nessas regras, estamos permitindo o tráfego de qualquer rede nas portas 80 e 443 (HTTP e HTTPS), além de portas para administração dessa máquina virtual com SSH ou RDP, a partir de um bastion host. Não é preciso definir o outbound dessas conexões em um security group pois se o tráfego de entrada é permitido, o seu retorno automaticamente é permitido. Isso inclui serviços que usam portas efêmeras também.

Além disso, as regras de outbound definidas permitem a conexão com banco de dados SQL Server ou MySQL que tenham um security group específico anexado a eles, limitando de forma bem granular o que aquele recurso pode de fato acessar.

Vale lembrar que, mesmo podendo associar um mesmo security group em vários recursos, você tem um limite de até 5 security groups em cada recurso. Então lembre-se que pode não ser uma boa ideia criar security groups muito granulares, contendo uma única regra para maximizar seu reaproveitamento. Prefira security groups descritivos e que tenham uma responsabilidade clara, mesmo que envolva duplicar algumas regras.

Rede de Computadores - Protocolo TCP/IP
Curso Rede de Computadores - Protocolo TCP/IP
Conhecer o curso

Comparação

Agora que conhecemos cada uma das formas de deixar nossa VPC mais segura, vamos a uma breve comparação de cada uma dessas:

Network ACL:

  • Aplicado na subnet: permite definir regras mais globais, que sejam efetivas em uma subnet completa;
  • Transparente para os recursos: todos os recursos dessa subnet tem seu tráfego filtrado, o que pode resultar em uma grande quantidade de regras;
  • Pode permitir ou negar tráfego: funciona de forma mais similar a um firewall convencional, podendo permitir (ALLOW) ou negar o tráfego (DENY);
  • Interpretado sequencialmente: cada regra é interpretada individualmente, onde a sequência que as regras são configuradas importa;
  • Stateless: necessário especificar tanto uma regra de inbound como outbound para liberar uma porta específica.

Security group:

  • Aplicado no recurso: permite definir regras granulares, que sejam efetivas em um único recurso;
  • Precisa ser aplicado em todos recursos: para funcionar corretamente, o security group precisa estar associado com todos os recursos necessários, sendo fácil esquecer de configurar em algum recurso;
  • Pode apenas permitir tráfego: não é possível criar uma regra para negar o tráfego (DENY) em um security group;
  • Interpretado de forma compilada: como ele funciona anexado a um recurso, todas as regras dos security groups associadas nesse recurso são combinadas e as regras com maior abrangência são consideradas;
  • Statefull: todo o tráfego liberado em um security group tem seu retorno previamente liberado, o que facilita a sua configuração.

Entretanto, nada impede que ambos sejam utilizados em conjunto. Você pode, por exemplo, permitir que os administradores de rede da sua empresa defina regras globais de acesso entre as subnets usando Network ACLs e criar regras mais granulares, para dividir ambientes de produção e desenvolvimento nas mesmas subnets usando security groups.

Conclusão

Conhecemos aqui as principais formas de deixar nossa VPC segura. Primeiramente vimos como funciona o Network ACL, em segundo lugar vimos o security group, ambos com regras de exemplos e uma comparação entre cada um deles.

Nas próximas semanas será lançado o curso AWS - Ferramentas de Rede e Distribuição de Conteúdo - Fundamentos que irá abordar com muito mais detalhes como funciona a configuração de cada um desses recursos.

Amazon Web Services (AWS) - S3 - Fundamentos
Curso Amazon Web Services (AWS) - S3 - Fundamentos
Conhecer o curso

Fiquem ligados e nos sigam nas nossas redes sociais, como Twitter, Instagram, Facebook e LinkedIn. Assim que esse curso for lançado você saberá em primeira mão!

Autor(a) do artigo

Gabriel Machado
Gabriel Machado

Autor dos cursos de cloud computing da TreinaWeb. Graduado em Gestão de TI pela FATEC e quase bacharel em Sistemas de Informação pela UFSCar. Tem experiência em desenvolvimento backend com PHP, mas se encontrou trabalhando com DevOps. Microsoft Certified: DevOps Engineer Expert, Azure Solutions Architect Expert e Azure Data Engineer Associate, AWS Certified Solutions Architect - Associate, e Zend Certified Engineer (ZCE). @gmsantos

Todos os artigos

Artigos relacionados Ver todos