Como acessar sua conta AWS

(Nicolo Marchesi) (3 de dezembro de 2020)

Como acessar sua conta da AWS

Olá. Você acabou de criar sua primeira conta da AWS e mal pode esperar para mergulhar em todos os serviços e tecnologias interessantes que a AWS tem a oferecer para começar a construir a próxima grande novidade. Mas, espere um segundo … você vai fazer o login com suas credenciais de conta root? Ou é melhor gerar um novo usuário? Ou talvez usar uma função?

Desacelere um minuto e, ao final da postagem do blog, prometo que você poderá escolher a melhor maneira para acessar sua conta AWS com segurança .

Cuidado, porém, consideraremos o acesso a uma única conta do aws, pois abordaremos estratégias de várias contas na próxima vez . Precisamos caminhar antes de podermos executar, certo?

Contas e recursos

Cada jornada incrível com a AWS começa com contas e recursos, e uma conta é como uma caixa vazia.

As coisas que você pode colocar dentro de sua conta podem ser qualquer coisa relacionada aos serviços da AWS, por exemplo, redes, máquinas virtuais, contêineres e assim por diante.

Mas a parte mais importante é que por padrão, nenhuma conta compartilha nenhum recurso, de modo que nada pode entrar ou sair entre duas contas AWS diferentes. E isso é ótimo para dividir suas cargas de trabalho e ter certeza de que apenas as pessoas certas acessam tudo.

IAM – Identidade & Gerenciamento de acesso

Em cada conta, o IAM existe para proteger os recursos dentro de sua conta, gerenciando quais entidades podem executar algumas ações nesses recursos:

  • QUEM – quais identidades
  • O QUE – pode fazer algumas ações
  • ONDE – em alguns recursos
  • COMO – e atendeu a algumas condições

Eu os defino como 4W e, por enquanto, precisaremos nos concentrar apenas no primeiro 3.

No início – o usuário root

Ao fazer login após criar a conta AWS, você usou essa conta usuário root .

Isso é diferente dos outros que você pode criar porque:

  • Criado no registro da conta
  • Você pode fazer login usando o endereço de e-mail e a senha que você usou para criar a conta
  • Você pode acessar as informações de faturamento
  • Tem acesso irrestrito a todos os recursos em sua conta

Este usuário é muito importante e você deve protegê-lo da melhor maneira possível. É um superadministrador que usa esteróides, pois pode ver as informações de faturamento e fazer tudo com todos os seus recursos.

Portanto, a primeira coisa a fazer deve ser:

  • Ative a autenticação multifator (MFA) e salve o código QR em um local seguro
  • Exclua todas as chaves de acesso relacionadas a este usuário para desativar o acesso programático (você não precisaria disso de qualquer maneira!)

E a próxima coisa deve ser decidir como você acessará essa conta a partir de agora.

De dentro da AWS

Vamos nos concentrar agora no que a AWS nos oferece sem depender de terceiros. Isso é especialmente útil se nos concentrarmos nesta única conta, porque precisamos dominar os três blocos de construção do IAM: usuário, grupos e funções.

Usuários

Você se lembra do usuário root? Os usuários IAM são do mesmo tipo de entidade, mas são diferentes do usuário root. Eles não têm permissões de faturamento padrão e acesso de administrador (a menos que você conceda a eles … o que você não deveria).

Com um usuário, podemos criar uma entidade que pode fazer login no console da web da AWS ou com acesso programático por meio de um conjunto de credenciais (uma chave de acesso e uma chave de acesso secreta) que são fixas e não mudarão com o tempo. Junto com chaves SSH / HTTPS para AWS CodeCommit ou Credentials for Amazon Keyspaces (para Apache Cassandra)

  • Credenciais de login para o console da web
  • Acesso e credenciais de chave secreta para acesso programático para APIs, CLI e SDK
  • chaves SSH / HTTPS para AWS CodeCommit
  • Credenciais para Amazon Keyspaces (para Apache Cassandra)

Acesso granular

É totalmente possível com um usuário IAM habilitar uma ou mais chaves de acesso, dependendo de como você deseja que o usuário se comporte.Por exemplo:

  • Um analista de dados que precisa verificar apenas as análises no console da web, mas sem precisar de acesso programático
  • Um DevOps sem servidor que precisa executar ações no console e usar a CLI para fornecer alguns recursos precisará de ambos os acessos
  • Um desenvolvedor trabalhando em um único repositório e não precisa interagir com recursos AWS terá chaves SSH / HTTPS para AWS CodeCommit.

Esteja ciente de que compartilhar credenciais de usuário IAM é uma grande proibição, , pois é o primeiro passo para perder credenciais e governança e se expor a ameaças de segurança.

Você não quer Você quer que sua conta de produção seja completamente apagada em favor de um conjunto completo de mineradores de bitcoin, não é?

Aplicar segurança

Outro recurso interessante dos usuários do AWS IAM é a capacidade de aplicar senha complexidade (que por padrão é muito alta com um comprimento entre 8-128 chara cters, um mínimo de 3 caracteres especiais, e para não ser idêntico ao seu nome de conta da AWS ou endereço de e-mail) e tempo de expiração de senha para garantir que após um certo tempo seus usuários mudarão a senha.

Além disso, você pode habilitar MFA com vários dispositivos:

  • Um dispositivo MFA virtual com um aplicativo autenticador instalado em seu dispositivo móvel ou computador
  • Uma chave de segurança U2F como uma YubiKey ou qualquer outro dispositivo compatível com U2F
  • Outro dispositivo MFA de hardware como o token Gemalto

Em geral, há uma abordagem granular, pois você pode ter meios específicos para cada usuário IAM .

Quando usar

Se você tiver muito poucos usuários (entre 1–5) com permissões precisas vinculadas a cada um, os usuários IAM podem economizar algum tempo na configuração inicial e no acesso ao console. Cuidado com as credenciais estáticas porque são problemas de segurança substanciais, portanto, manuseie com muito cuidado. Ou use o AWS CLI get-session-token para gerar credenciais temporárias fora das estáticas.

Grupos

Não é uma entidade em si, mas os grupos IAM existem para agrupar usuários IAM. e dar o mesmo conjunto de permissões a um grupo de usuários. Isso suaviza um pouco as arestas dos usuários IAM, mas no geral as mesmas coisas que vimos para usuários IAM se aplicam.

Uma coisa boa para se ter em mente é que um usuário IAM ainda pode ter políticas pessoais enquanto está associado com um grupo, com a permissão resultante igual à fusão do grupo e dos pessoais.

Isso deve ser mais uma exceção do que o fluxo de trabalho típico. Com muitas permissões individuais, criamos muitas políticas impossíveis de manter e perdemos a visão geral das permissões na conta.

Quando usar

Se você tiver poucos usuários (entre 5–15), os grupos IAM podem evitar alguns aborrecimentos de gerenciamento e configuração de cada usuário IAM. Mas se aplica a mesma consideração que os usuários do IAM, portanto, se possível, evite-os, a menos que você esteja apenas trabalhando em uma única conta.

Funções

E aqui estamos nós para as funções da AWS. As funções do IAM podem ter permissões (assim como usuários) e registrar no console (novamente como usuários …). Em vez de estar exclusivamente associado a uma pessoa, qualquer pessoa que precise pode assumir uma função.

Então uma pessoa usa o boné da função que deseja assumir e

O logotipo da função IAM acaba de ganhar muito mais sentido, certo?

Credenciais temporárias

Outra diferença importante dos usuários IAM é que as funções IAM não têm credenciais estáticas. Quando alguém assume as funções, um conjunto de credenciais temporárias é gerado e fornecido. É possível personalizar a duração dessas credenciais e restringir ainda mais o acesso, se necessário.

O tempo pode ser definido de 900 segundos (15 minutos) até 12 horas, mas na minha opinião, definir uma hora- expiração longa é a melhor troca entre segurança e desempenho.

Monitoramento do CloudTrail

Vou mencionar isso porque algumas pessoas não usam funções porque pensam que não podem auditar o que papéis podem fazer. A verdade é que você pode e deve. Ao habilitar o monitoramento do Cloudtrail, você pode ver todas as ações realizadas dentro da sua conta, para que possa sempre saber o que está acontecendo.

Conta cruzada

Isso será discutido com mais detalhes em outro blog postar, já que estamos nos concentrando em contas únicas, mas por agora, esteja ciente de que as funções IAM podem ser usadas para dar acesso a outras funções IAM ou usuários IAM.

E isso é incrivelmente útil.

Ponto de entrada necessário

E agora as desvantagens. Infelizmente, você não pode fornecer acesso direto ao console e credenciais temporárias para uma função IAM. Primeiro, você precisa configurar um usuário ou uma função federada (mais sobre isso em alguns parágrafos) para dar acesso a uma função IAM.

Quando usar

Sempre. O único fato de que as funções do IAM são não vinculado a credenciais estáticas os torna a melhor maneira de acessar sua nuvem. Combine-os com a capacidade de monitorar as ações das funções do IAM e reforçar a segurança mesmo com o MFA. A única desvantagem é que é um pouco mais de configuração, mas é um preço baixo a pagar na minha opinião.

De fora do AWS

E agora, vamos ver o que podemos fazer quando entrar no campo das identidades corporativas. Estou me referindo a usar um provedor de identidade como uma fonte de identidades e fazer login com nosso e-mail e senha corporativos.

Federação

Mas o que queremos dizer com federação? De um lado, temos o provedor de identidade. Esses sistemas contêm um diretório de usuários e alguns softwares que podem se comunicar por meio de protocolos de federação específicos. Todos os dados de nossos usuários residem como Identidades .

Por outro lado, está o seu AWS Conta como um Consumidor de identidade . Ele mantém uma referência às identidades sem salvá-las. Nesse lado, geralmente temos níveis de autorização muito mais granulares (obrigado, IAM!).

Portanto, a federação é a relação de confiança que torna o consumidor de identidade capaz de fazer referência às identidades no provedor de identidade.

Federação SAML

A definição mais comum para linguagem de marcação para autorização de segurança (SAML ) é um padrão aberto para troca de dados de autenticação e autorização entre as partes. Isso significa que podemos usar nossas identidades para fazer login na AWS e até mesmo obter credenciais temporárias ao assumir funções. É uma abordagem generalística que você pode aplicar a quase todos os provedores de identidade.

A relação de confiança

Para configurar a federação entre as duas partes, precisamos criar e gerenciar um Provedor de identidade IAM . Isso é necessário porque representa o provedor de identidade real e contém o segredo compartilhado que permite que as duas partes se comuniquem. Além disso, dentro de cada função que queremos que nossos usuários assumam, definiremos uma política de confiança para permitir entidades relacionadas ao IAM Provedor de identidade para assumir a função:

Gerenciamento personalizado

O fato é que gerenciar a federação sozinho pode ser desafiador e demorado no início. Existem alguns conceitos para entender bem e você precisa criar um monte de entidades, relações e coisas personalizadas para fazer isso acontecer. Para se ter uma ideia, você pode encontrar um exemplo de tutorial completo aqui .

Quando usar

Em geral, esta é uma abordagem excelente e testada em batalha que funcionará em quase todos os casos. Ainda assim, o gerenciamento personalizado de identidades pode ser difícil e demorado para pessoas inexperientes.

Casos de uso típicos são se você quiser gerenciar isso sozinho para fins de segurança ou conformidade. Você não tem acesso à sua organização AWS ou o AWS SSO ainda não oferece suporte ao seu provedor de identidade.

AWS SSO

Este é o serviço de SSO gerenciado e baseado em nuvem que permite você conecta seu provedor de identidade com sua conta da AWS.

AWS Organization

Para configurar o AWS SSO, você precisará configurar AWS Organizations e, por agora, você pode pensar nisso para gerenciar várias contas AWS. Para ser breve, você precisa saber que a configuração de uma organização AWS precisa de permissões extensas (ou seja, o usuário raiz).

Armazenamento de identidade interno

Por padrão, o AWS SSO fornece um diretório para armazenar suas informações de usuário e credenciais para servir como provedor de identidade diretamente. É ótimo se você ainda não tem um provedor de identidade ou não quer se dar ao trabalho de configurá-lo.

Armazenamento externo de identidade

Mas suponha que sua organização já use algum Diretório do usuário, como o Microsoft Active Directory. Nesse caso, você pode conectá-lo ao AWS SSO, eliminando a necessidade de manter dois diretórios distintos com provisionamento automático .

Esteja ciente, porém, de que este recurso é compatível apenas com um conjunto limitado de provedores de identidade:

Autenticação multifator

Com AWS SSO, você pode configurar um dispositivo MFA para seus usuários dentro do serviço. No momento, ele oferece suporte a aplicativos do Authenticator, como o Google Authenticator, e a chaves de segurança, como o Yubikey. A solução interna é empolgante, mas carece de suporte de MFA se configurada em um provedor de identidade externo.

Quando usar

É o padrão sugerido pela AWS e pode ser o caminho padrão se não tiver certeza de como proceder. Ainda assim, há pelo menos alguns requisitos que você precisa para aproveitar ao máximo esta solução:

você já configurou sua organização AWS, e você tem acesso à conta root. Você deseja manter suas identidades dentro do AWS SSO ou usar um provedor de identidade com suporte de provisionamento automático.

Notas finais

Portanto, apresentamos as bases para acessar uma única conta da AWS, e agora você deve ter os elementos para escolher o melhor método para seu caso de uso específico. Usaremos isso para cobrir o terreno do gerenciamento de várias contas e Organizações AWS na próxima postagem do blog.

Leapp

Como última observação, recomendo fortemente que todos usem alguma ferramenta que os ajuda a armazenar todos os dados necessários para se conectar à sua conta AWS. Minha equipe e eu estamos desenvolvendo uma ferramenta de código aberto que oferece suporte a todos esses casos de uso, então sinta-se à vontade para verificar:

Noovolari / leapp

Leapp é seu companheiro diário para acessar sua nuvem; projetado para funcionar com APIs, CLIs e SDKs de provedores de nuvem. É…

github.com

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *