Segurança é um pilar fundamental na AWS e dados de HPC são, frequentemente, ativos de missão crítica. O ambiente de laboratório que acabou de criar está trabalhando em sua própria conta, o que significa que você tem o controle total e a propriedade de seus dados e aplicativos. Neste módulo, você analisará a abordagem da AWS para segurança e algumas das principais tecnologias que você pode usar para manter seus aplicativos HPC e dados seguros.
Tópicos abordados:
- O modelo de responsabilidade compartilhada da AWS
- Uso do AWS Identity and Access Management (IAM)
- Segurança de rede
- Autenticação
Ao avaliar a segurança de sua infraestrutura de HPC na nuvem, é importante compreender e fazer a distinção entre:
- As medidas de segurança que o provedor de serviços em nuvem (AWS) implementa e opera: "a segurança da nuvem"
- As medidas de segurança que o cliente implementa e opera, relacionadas à segurança do conteúdo e dos aplicativos do cliente que utilizam os serviços da AWS: "a segurança na nuvem"
Enquanto a AWS gerencia a segurança da nuvem, a segurança na nuvem é sua responsabilidade. Os clientes mantêm o controle do tipo de segurança que escolhem implementar para proteger seu próprio conteúdo, plataforma, aplicativos, sistemas e redes, da mesma maneira que eles fariam em um datacenter local.
É importante compreender que a segurança de laboratório é parte de sua responsabilidade, uma vez que é uma solução implantada em sua conta da AWS. Para saber mais, você pode participar de um treinamento on-line gratuito de 4 horas ou ler o whitepaper de segurança da AWS.
Para maior segurança e organização, você pode conceder acesso à sua conta da AWS para usuários específicos – identidades que você cria com permissões personalizadas. Para o ambiente de HPC que você executou no módulo anterior, você usou o usuário raiz da AWS, que é a única identidade com acesso completo a todos os serviços AWS e recursos na conta. Para sua carga de trabalho de produção, recomenda-se criar e utilizar um usuário alternativo (conhecido como um usuário IAM) com permissões suficientes para implantar o modelo do CloudFormation.
O laboratório inteiro está em uma recém-criada Virtual Private Cloud (VPC), que proporciona o isolamento de outros ambientes e aplicativos que você pode estar executando na mesma conta. Dentro dessa VPC, várias subnets são usadas para hospedar os serviços do EC2, incluindo as VMs e Load Balancers.
No modelo de laboratório, o intervalo CIDR fornecido por você como parâmetro é usado para restringir o acesso HTTPS ao Application Load Balancer e o acesso SSH ao nó central do cluster (s) usando Security Groups e outros componentes da VPC. Lembre-se de que os certificados HTTPS e SSH são diferentes, e o HTTPS é autoassinado e, portanto, não é recomendado para uso de produção.
Um security group atua como um firewall virtual para permitir e prevenir o tráfego para uma instância com base na origem CIDR, protocolo e porta. Um ou mais security groups são associados a uma instância. Regras são adicionadas a um security group para permitir o tráfego de ou para as instâncias associadas. Você pode modificar as regras de um security group a qualquer momento. As novas regras são aplicadas automaticamente a todas as instâncias associadas ao security group.
Os Security groups associados a uma instância são exibidos no console do EC2 com a descrição da instância, como mostra a imagem abaixo. Para obter mais informações, consulte o guia do usuário para Security Groups do Amazon EC2.
A imagem acima exibe o console do Amazon EC2 e destaca os security groups. A Caixa 1 destaca o security group de uma instância selecionada do Amazon EC2 e a Caixa 2 destaca uma maneira alternativa de acessar seus security groups por meio do console do EC2.
Como usuários gerenciados dentro do AWS Identity and Access Management só podem ser usados para serviços nativos da AWS, o laboratório implementa a autenticação do usuário por meio do AD Simples, uma oferta simples no AWS Directory Service, que oferece compatibilidade com o Microsoft Active Directory.
Esta solução de autenticação é usada para validar as credenciais do usuário no acesso a web do EnginFrame, que é executado no nó principal do cluster, bem como para propagar usuários em nós do cluster à medida que são criados dinamicamente e removidos, e fornece um espaço de nome uniforme para garantir o acesso consistente a arquivos no EFS.
À medida que você projeta e compila sua infraestrutura HPC, você pode considerar mudar para o Microsoft AD Directory Service product para melhorar a compatibilidade do Windows e estabelecer relações de confiança entre um diretório hospedado AWS e seus diretórios locais.
Amazon EC2 usa autenticação de chave pública para acesso privilegiado às instâncias Ec2. Autenticação de chave pública é mais segura do que a autenticação por senha, usando uma chave pública para criptografar dados transferidos ao mesmo tempo que o terminal destinatário usa a chave privada para descriptografar os dados. As chaves pública e privada são conhecidas como par de chaves.
O par de chaves associado às instâncias de computação e Master é inserido como um parâmetro durante a execução do laboratório. É necessário fazer login nas instâncias mestre e de computação como a conta de usuário EC2, que possui permissões sudo e não tem senha.
Use o endereço IP público e a chave ssh para acessar suas instâncias da seguinte forma:
ssh –i $YOUR_KEY_PAIR_FILE ec2-user@$MASTER_ELASTIC_IP