Security Essentials

Ao criar uma conta da AWS, você começa com o que é conhecido como usuário raiz. Esse é o primeiro usuário que existe em sua conta da AWS. A AWS recomenda que você não use essa conta para operações diárias, pois ela tem acesso e controle completos da conta e deve seguir as melhores práticas recomendadas para proteger o usuário raiz. Isso envolve bloquear suas chaves de acesso de usuário raiz, usar uma senha forte, habilitar a autenticação multifator da AWS e criar um usuário do IAM para acessar sua conta. Essa conta pode ter privilégios de administrador e deve ser usada para todas as tarefas administrativas futuras.

Em seguida, você deve atribuir contatos de segurança alternativos à sua conta. O contato alternativo de segurança receberá notificações relacionadas à segurança, incluindo notificações da equipe de confiança e segurança da AWS. Você pode aprender mais sobre a importância de definir essas informações de contato logo no início da configuração da sua conta na postagem do blog Atualize o contato alternativo de segurança em suas contas da AWS para receber notificações de segurança oportunas.

Depois de confirmar seus contatos de segurança, você deve considerar as regiões da AWS em que suas cargas de trabalho devem ser executadas e as regiões em que não devem. Em seguida, você pode bloquear as regiões não utilizadas para garantir que nenhuma carga de trabalho possa ser executada a partir dessas regiões. Embora isso ajude na otimização de custos, também se presta à segurança. Como assim? Ao bloquear as regiões nas quais você não espera executar workloads, você pode concentrar seus esforços de monitoramento nas regiões que usa ativamente.

Neste ponto, você protegeu o usuário raiz, criou um ou mais usuários do IAM, atribuiu contatos de segurança e bloqueou as regiões nas quais as cargas de trabalho podem ser executadas. Em seguida, vamos considerar como os usuários interagirão com os recursos da AWS. Há dois métodos principais de interação: a AWS CLI e o Console de Gerenciamento da AWS. É recomendável configurar um login único para a AWS CLI e o console. Consulte o artigo Configurando a CLI da AWS para usar o AWS IAM Identity Center (sucessor do AWS Single Sign-On) para obter detalhes sobre como gerenciar centralmente o acesso com o AWS IAM Identity Center.

A próxima etapa para proteger sua conta é configurar grupos de usuários do AWS IAM para controlar o acesso. Em vez de controlar o acesso de usuários individuais definindo políticas diretamente no usuário, é melhor criar um grupo, atribuir as permissões necessárias a ele e, em seguida, atribuir usuários ao grupo. Os usuários herdarão as permissões desse grupo. Isso oferece uma maneira mais escalável de fornecer controle de acesso a muitos usuários. É importante entender o IAM e os grupos do IAM porque eles abrangem vários serviços. O IAM é um serviço que interage de alguma forma com todos os serviços da AWS, então não deixe de se familiarizar com ele.

A adoção dessas práticas desde o início ajudará a fornecer acesso seguro aos recursos da AWS. A seguir, discutiremos como proteger a infraestrutura que você constrói na AWS.

Ao criar sua infraestrutura de nuvem, você começará criando uma Amazon Virtual Private Cloud (Amazon VPC). Essa é uma rede virtual que você define (uma rede padrão é criada em cada região quando você cria sua conta) que permite iniciar os recursos. Uma VPC se assemelha a uma rede tradicional, pois tem um intervalo de endereços IP CIDR atribuído a ela e é subdividida pela criação de sub-redes. As sub-redes podem ser usadas para fornecer isolamento para diferentes conjuntos de recursos. As sub-redes podem ser públicas ou privadas. As sub-redes públicas têm uma rota para um gateway da Internet, têm acesso à Internet por meio desse gateway e podem ser acessadas pela Internet se os controles de acesso relevantes permitirem. As sub-redes privadas também têm uma tabela de roteamento, mas não têm uma rota para um gateway da Internet, portanto, por padrão, não podem acessar a Internet e não podem ser acessadas pela Internet. Para permitir que recursos em uma sub-rede privada acessem a Internet, é necessário um gateway NAT. No nível da sub-rede, uma lista de controle de acesso à rede (ACL) permite ou nega tráfego específico de entrada ou saída. Você pode usar a ACL de rede padrão para a VPC ou criar uma ACL de rede personalizada para sua VPC. As ACLs de rede são listas numeradas, processadas em ordem decrescente e não têm estado. Isso significa que você precisará de uma regra de ACL de rede de entrada e saída para permitir o tráfego bidirecional.

Ao implantar recursos do EC2 em sua VPC, você associará um grupo de segurança a eles. Um grupo de segurança controla o tráfego de entrada e saída que pode alcançar os recursos do EC2. Os grupos de segurança são semelhantes a um firewall, mas em vez de usar apenas uma lista ou um intervalo de endereços IP, eles podem apontar para uma referência de recurso. Uma referência de recurso é um grupo nomeado que mantém uma lista atualizada de endereços IP atribuídos a cada recurso do grupo. Por exemplo, se você criar um grupo de escalonamento automático para gerar instâncias do Amazon EC2, cada instância receberá um novo IP quando for inicializada. Ao adicionar um grupo de segurança a essas instâncias, você pode conceder acesso ao grupo de segurança do seu servidor de banco de dados por meio do ID do grupo de segurança das instâncias do EC2, e qualquer nova instância do EC2 lançada terá acesso ao banco de dados sem precisar adicionar seu endereço IP à lista permitida.

As regras do grupo de segurança são semelhantes às ACLs de rede porque, ao criá-las, você combina a porta, o protocolo e os endereços, porém elas têm estado reconhecido. Você pode considerá-las semelhantes a um firewall com estado. Quando você cria uma entrada para permitir um tipo específico de tráfego, não é necessário criar uma regra que corresponda ao tráfego de retorno. Como ela tem estado, o tráfego de retorno será permitido. Para entender melhor como os grupos de segurança e as ACLs interagem, essa comparação é útil.

Para adicionar uma camada adicional de segurança de infraestrutura, você pode implantar o AWS Network Firewall. O Network Firewall é um serviço gerenciado que implanta proteção para o Amazon VPC. Ele fornece proteção mais refinada do que os grupos de segurança, porque pode incorporar o contexto de fluxos de tráfego, como conexões de rastreamento e identificação de protocolos, para aplicar políticas como prevenção de acesso a domínios por suas VPCs por meio de um protocolo não autorizado. Isso é feito por meio da configuração de Regras Suricata personalizadas. Por exemplo, você pode configurar o Firewall de Rede para se proteger contra ataques de malware. Levando isso um passo adiante, você pode implantar outro serviço gerenciado, o AWS Shield Advanced, para se proteger contra ameaças de DDoS.

Ao criar recursos na AWS, você deverá seguir as melhores práticas de segurança recomendadas para o tipo de recurso com o qual você estiver trabalhando. Para instâncias do EC2, a segurança começa controlando o acesso à rede às suas instâncias, por exemplo, por meio da configuração da VPC e dos grupos de segurança. (Para obter mais informações, consulte “Segurança na Amazon VPC” na seção “Proteger a infraestrutura criada”).

Outro aspecto da segurança da instância é o gerenciamento das credenciais usadas para se conectar às instâncias. Isso começa com as permissões de usuário do IAM que você atribui, mas se estende ao grupo atribuído. Um nível de segurança para o usuário que trabalha com a instância do EC2 é fornecido, mas não para a instância em si. Você também deve configurar as funções do IAM que estão anexadas à instância e as permissões associadas a essas funções. Para acessar uma instância do EC2, em vez de abrir a porta para SSH ou configurar um host bastion/jump, você deve usar o EC2 Instance Connect.

Você deve garantir que o sistema operacional convidado e o software implantados na instância estejam atualizados com todas as atualizações e patches de segurança do sistema operacional. Para obter mais detalhes, visite Segurança no Amazon EC2.

Proteger seu banco de dados é um aspecto importante da sua abordagem de segurança. Conforme mencionado na seção de segurança do Amazon VPC, é recomendável implantar bancos de dados em uma sub-rede privada para impedir o acesso de terceiros pela Internet. A AWS oferece 15 bancos de dados criados especificamente. Cada um é protegido de forma diferente, mas todos compartilham o seguinte em comum.

Para acessar um banco de dados, alguma forma de autenticação é necessária. Isso pode assumir a forma de um nome de usuário e senha, que devem ser alternados regularmente. Como alternativa, você pode usar o Amazon RDS Proxy para aproveitar as funções do IAM para gerenciar o acesso ao banco de dados para você. Alguns dos serviços de banco de dados, como o Amazon DynamoDB, usam funções do IAM para fornecer acesso, então você não precisa gerenciar nenhuma credencial sozinho.

O SSH é um dos métodos mais comuns de gerenciar as instâncias do EC2 e o Amazon EC2 Instance Connect permite que você use o SSH para se conectar às instâncias do EC2 usando chaves SSH únicas diretamente no console. Os artigos a seguir fornecem um passo a passo de como habilitar o Amazon EC2 Instance Connect e explicam o caso de uso típico. Você também pode gerar chaves SSH ao criar a instância do EC2, baixá-las localmente e usá-las para se conectar à sua instância. No entanto, isso significa que você deve proteger essas chaves, garantir que elas estejam armazenadas em algum lugar ao qual você não perca o acesso e só possa se conectar à sua instância de uma máquina que tenha essas chaves baixadas. O EC2 Instance Connect fornece o mesmo acesso SSH de forma segura, no console, em todas as máquinas, de uma forma simples de usar.

Restringir o acesso ao banco de dados somente aos serviços e à infraestrutura que exigem acesso é uma prática recomendada. Isso pode ser feito configurando grupos de segurança para suas instâncias do RDS, bancos de dados do Amazon Neptune ou para clusters do Amazon Redshift.

Fazer backup e testar as restaurações

Fazer backup dos dados e executar restaurações frequentes para confirmar se os backups estão funcionando corretamente deve ser uma prioridade. Com o AWS Backup, você pode facilmente configurar e gerenciar backups para serviços específicos da AWS, incluindo Amazon RDS, DynamoDB, Neptune e muito mais.

Para segurança sem servidor, você deve estar familiarizado com o AWS Lambda, o Amazon API Gateway, o Amazon DynamoDB, o Amazon SQS e o IAM. Com a segurança sem servidor, a AWS assume uma responsabilidade maior do que o modelo de responsabilidade compartilhada, mas ainda há uma responsabilidade do cliente a ser considerada. Em um ambiente sem servidor, a AWS gerencia a infraestrutura, a computação, o ambiente de execução e a linguagem do runtime. O cliente é responsável pelo código de função e pelas bibliotecas do cliente, pela configuração de recursos e pelo gerenciamento de identidade e acesso, conforme mostrado na imagem.

Nas seções a seguir, fornecemos os detalhes sobre as práticas de segurança que são de responsabilidade do cliente. Para obter detalhes adicionais, consulte Segurança no AWS Lambda.

O AWS Lambda fornece runtimes que executam o código de função em um ambiente baseado no Amazon Linux. No entanto, se você usar outras bibliotecas com a sua função, você será responsável por atualizar as bibliotecas. Garantir que as bibliotecas estejam atualizadas pode ajudar a manter seus procedimentos de segurança.

O AWS Lambda se integra a vários recursos da AWS, como Amazon DynamoDB, Amazon EventBridge e Amazon Simple Notification Service (Amazon SNS). A adoção das práticas de segurança recomendadas para cada serviço que você usa como parte da função ajudará a fortalecer seus procedimentos de segurança. A documentação de cada serviço fornece orientações adicionais.

A execução de funções do Lambda pode exigir permissões e perfis específicos do IAM. Mais detalhes podem ser encontrados na seção Permissões do Guia do desenvolvedor do AWS Lambda.

Sua estratégia de segurança também deve incluir monitoramento, registro e gerenciamento de configurações. Por exemplo, muitas organizações permitem a contabilização de seus dispositivos usando o protocolo TACACS+, RADIUS ou logs do Active Directory. Isso ajuda a garantir que uma trilha de auditoria seja criada para todas as atividades administrativas. Na Nuvem AWS, isso pode ser feito com o AWS CloudTrail. O CloudTrail permite fazer auditoria, monitoramento de segurança e solucionar problemas operacionais rastreando a atividade do usuário e o uso da API. O AWS Serverless Application Repository, que facilita que desenvolvedores e empresas encontrem, implantem e publiquem rapidamente aplicações sem servidor na Nuvem AWS, é integrado ao AWS CloudTrail. Para obter detalhes adicionais, consulte o Guia do desenvolvedor do AWS Serverless Application Repository.

Você ainda precisará, de alguma forma, fornecer infraestrutura e proteção contra DoS para seus ambientes sem servidor, o que pode ser feito com o AWS Shield e o AWS Shield Avançado. O monitoramento e a detecção de ameaças são discutidos mais detalhadamente na seção “Monitoramento do ambiente”.

Na AWS, os dados são armazenados no Amazon S3, que tem vários controles para proteger os dados. O artigo As 10 melhores práticas de segurança para proteger dados no Amazon S3 aborda as técnicas mais fundamentais. Isso inclui o bloqueio de buckets públicos do S3 no nível da organização, o uso de políticas de bucket para verificar se todo o acesso concedido é restrito e específico e a criptografia e proteção de dados.

Para criptografia, o AWS Key Management Service (AWS KMS) permite criar e controlar chaves usadas para criptografar ou assinar digitalmente os dados. Se você quiser criptografar seus dados na AWS, você tem algumas opções. A primeira é usar criptografia do lado do servidor com chaves de criptografia gerenciadas pelo Amazon S3 (SSE-S3). Usando esse método, a criptografia acontece depois que os dados são enviados para a AWS usando chaves gerenciadas pela AWS.

A segunda opção é criptografar os dados quando estiverem na AWS, mas em vez de usar chaves criadas e gerenciadas pela AWS, você pode realizar a criptografia do lado do servidor com chaves mestras do cliente (CMKs) armazenadas no AWS KMS (SSE-KMS).

A terceira opção para armazenar os dados criptografados na AWS é usar a criptografia do lado do cliente. Com essa abordagem, os dados são criptografados antes de serem transferidos para a AWS.

Um exemplo de como a criptografia do lado do cliente e a criptografia do lado do servidor beneficiam os clientes pode ser visto na imagem.

As VPNs podem abranger várias tecnologias. A ideia por trás de uma VPN é que seus dados em trânsito mantenham sua integridade e possam ser trocados com segurança entre as duas partes. A AWS oferece várias tecnologias que ajudam a manter seus dados em trânsito seguros. Um deles é o AWS PrivateLink, que fornece conectividade criptografada e privada entre VPCs, serviços da AWS e suas redes locais. Isso é feito sem expor seu tráfego à Internet pública. Isso também pode ser considerado uma rede privada virtual.

No entanto, na maioria dos casos, uma discussão sobre VPN gira em torno do uso da criptografia de dados. Dependendo das circunstâncias, talvez seja necessário fornecer criptografia entre um cliente e seus recursos da Nuvem AWS. Essa situação exigiria o AWS Client VPN. Por outro lado, você pode estar passando dados entre o datacenter ou filial e seus recursos da AWS. Você pode fazer isso usando túneis IPsec entre os recursos on-premises e as Amazon VPCs ou AWS Transit Gateway. Essa conectividade segura é conhecida como VPN site a site.

Por fim, o gerenciamento dos recursos de nuvem usando o Console de Gerenciamento da AWS também oferece dados criptografados em trânsito. Embora você normalmente não se refira à conectividade com o console como uma VPN, sua sessão usa a criptografia TLS (Transport Layer Security). Assim, suas configurações são mantidas em sigilo à medida que você cria sua arquitetura segura. O TLS também é usado com a API da AWS.

A AWS oferece vários serviços gerenciados para auxiliar no monitoramento do seu ambiente, além de opções de autoatendimento. Por exemplo, você pode usar os VPC Flow Logs para registrar e visualizar fluxos de tráfego de rede, ou você pode usar o Amazon CloudWatch para analisar os registros do AWS WAF ou até mesmo criar alarmes para instâncias do EC2. Você pode aprender mais sobre o Amazon CloudWatch neste workshop.

Além disso, o AWS CloudTrail monitora e registra a atividade da conta em toda a sua infraestrutura da AWS, oferecendo controle sobre ações de armazenamento, análise e remediação. Isso é essencial para criar uma trilha de auditoria administrativa, identificar incidentes de segurança e solucionar problemas operacionais.

Por fim, o Amazon GuardDuty pode ser usado para detectar ameaças e até mesmo para dar um passo adiante, fazendo com que as descobertas publicadas iniciem ações de remediação automática em seu ambiente da AWS.

Ao abordar cada uma dessas áreas operacionais, você estará no caminho certo para estabelecer recursos de segurança essenciais para seu ambiente de nuvem.