fbpx

Entendendo os Principais do IAM

aws iam
Compartilhar no facebook
Compartilhar no linkedin
Compartilhar no twitter
Compartilhar no whatsapp

Principais do IAM

 

O primeiro conceito do IAM a entender é o de principal. Um principal é uma entidade do IAM que tem permissão para interagir com os recursos da AWS. Um principal pode ser permanente ou temporário e pode representar um ser humano ou um aplicativo. Existem três tipos de entidades: usuários raiz, usuários IAM e funções / tokens de segurança temporários.

 

Usuário raiz

Quando você cria uma conta da AWS pela primeira vez, começa com apenas uma entidade de login único que tem acesso completo a todos os serviços e recursos da nuvem da AWS na conta. Esse princípio é chamado de usuário root. Contanto que você tenha uma conta aberta na AWS, o usuário raiz desse relacionamento persistirá. O usuário root pode ser usado para o acesso do console e do programa aos recursos da AWS.

O usuário root é semelhante em conceito à raiz UNIX ou à conta de administrador do Windows – possui privilégios totais para fazer qualquer coisa na conta, incluindo o fechamento da conta.

É altamente recomendável que você não use o usuário root nas tarefas diárias, mesmo as administrativas. Em vez disso, siga as práticas recomendadas de usar o usuário raiz apenas para criar seu primeiro usuário do IAM e, em seguida, bloquear com segurança as credenciais do usuário raiz.

 

Usuários do IAM

Os usuários são identidades persistentes configuradas pelo serviço IAM para representar pessoas ou aplicativos individuais. Você pode criar usuários separados do IAM para cada membro da sua equipe de operações, para que eles possam interagir com o console e usar a CLI.

Você também pode criar usuários de desenvolvimento, teste e produção para aplicativos que precisam acessar os serviços em nuvem da AWS (embora você veja mais adiante neste capítulo que as funções do IAM podem ser uma solução melhor para esse caso de uso).

Os usuários do IAM podem ser criados por entidades com privilégios administrativos do IAM a qualquer momento, por meio do Console de Gerenciamento da AWS, CLI ou SDKs. Os usuários são persistentes, pois não há período de expiração; elas são entidades permanentes que existem até que um administrador do IAM faça uma ação para excluí-los.

Os usuários são uma excelente maneira de aplicar o princípio do menor privilégio, ou seja, o conceito de permitir que uma pessoa ou processo que interaja com os recursos da AWS execute exatamente as tarefas de que precisa, mas nada mais.

Os usuários podem ser associados a políticas muito granulares que definem essas permissões.

 

Funções / Tokens de Segurança Temporários

Funções e tokens de segurança temporários são muito importantes para o uso avançado do IAM, mas muitos usuários da AWS os consideram confusos.

As funções são usadas para conceder privilégios específicos a atores específicos por um período de tempo definido.

Esses atores podem ser autenticados pela AWS ou por algum sistema externo confiável. Quando um desses atores assume uma função, a AWS fornece ao agente um token de segurança temporário do AWS Security Token Service (STS) que o ator pode usar para acessar os serviços da AWS Cloud.

A solicitação de um token de segurança temporário requer a especificação de quanto tempo o token existirá antes de expirar. O intervalo de uma vida útil temporária do token de segurança é de 15 minutos a 36 horas.

As funções e os tokens de segurança temporários permitem vários casos de uso:

 

  • Funções do Amazon EC2 – concessão de permissões para aplicativos em execução em uma instância do Amazon EC2.
  • Acesso entre contas – conceder permissões a usuários de outras contas da AWS, independentemente de você controlar essas contas ou não.
  • Federação – Concedendo permissões a usuários autenticados por um sistema externo confiável.

 

 IntroToIAM_Diagram

Funções do Amazon EC2

A concessão de permissões para um aplicativo é sempre complicada, pois geralmente requer a configuração do aplicativo com algum tipo de credencial na instalação.

Isso leva a problemas relacionados ao armazenamento seguro da credencial antes do uso, como acessá-la com segurança durante a instalação e como protegê-la na configuração.

Suponha que um aplicativo em execução em uma instância do Amazon EC2 precise acessar um bucket do Amazon Simple Storage Service (Amazon S3). Uma política que concede permissão para ler e gravar esse bucket pode ser criada e atribuída a um usuário do IAM, e o aplicativo pode usar a chave de acesso desse usuário do IAM para acessar o bucket do Amazon S3.

O problema dessa abordagem é que a chave de acesso do usuário deve estar acessível ao aplicativo, provavelmente armazenando-a em algum tipo de arquivo de configuração. O processo para obter a chave de acesso e armazená-la criptografada na configuração geralmente é complicado e dificulta o desenvolvimento ágil.

Além disso, a chave de acesso corre risco ao ser distribuída. Finalmente, quando chega a hora de girar a tecla de acesso, a rotação envolve executar todo o processo novamente.

O uso de funções do IAM no Amazon EC2 elimina a necessidade de armazenar credenciais da AWS em um arquivo de configuração.

Uma alternativa é criar uma função do IAM que conceda o acesso necessário ao bucket do Amazon S3. Quando a instância do Amazon EC2 é iniciada, a função é atribuída à instância.

Quando o aplicativo em execução na instância usa a API (Interface de Programação de Aplicativos) para acessar o bucket do Amazon S3, ele assume a função atribuída à instância e obtém um token temporário que envia à API.

O processo de obter o token temporário e passá-lo para a API é tratado automaticamente pela maioria dos SDKs da AWS, permitindo o aplicativo para fazer uma chamada para acessar o bucket do Amazon S3 sem se preocupar com autenticação.

Além de ser fácil para o desenvolvedor, isso elimina a necessidade de armazenar uma chave de acesso em um arquivo de configuração. Além disso, como o acesso à API usa um token temporário, não há chave de acesso fixo que precise ser rotacionada.

 

Acesso entre contas (Cross Account)

Outro caso de uso comum para funções do IAM é conceder acesso aos recursos da AWS para usuários do IAM em outras contas da AWS.

Essas contas podem ser outras contas da AWS controladas por sua empresa ou agentes externos, como clientes ou fornecedores.

Você pode configurar uma função do IAM com as permissões que deseja conceder aos usuários da outra conta, para que os usuários da outra conta possam assumir essa função para acessar seus recursos.

Isso é altamente recomendado como uma prática recomendada, em vez de distribuir chaves de acesso fora da sua organização.

 

Federação

Muitas organizações já possuem um repositório de identidade fora da AWS e preferem aproveitar esse repositório a criar um repositório novo e amplamente duplicado de usuários do IAM.

Da mesma forma, os aplicativos baseados na Web podem querer aproveitar identidades baseadas na Web, como Facebook, Google ou Login com a Amazon.

Os provedores de identidade do IAM oferecem a capacidade de associar essas identidades externas ao IAM e atribuir privilégios aos usuários autenticados fora do IAM. O IAM pode integrar-se a dois tipos diferentes de Provedores de Identidade externos (IdP).

Para federar identidades da web como Facebook, Google ou Login com Amazon, o IAM oferece suporte à integração via OpenID Connect (OIDC).

Isso permite que o IAM conceda privilégios a usuários autenticados com alguns dos principais IdPs baseados na Web. Para federar identidades internas, como Active Directory ou LDAP, o IAM oferece suporte à integração via SAML (Security Assertion Markup Language 2.0).

Um IdP compatível com SAML, como os Serviços de Federação do Active Directory (ADFS), é usado para associar o diretório interno ao IAM. (Instruções para configurar muitos produtos compatíveis podem ser encontradas no site da AWS.)

Em cada caso, a federação funciona retornando um token temporário associado a uma função para o IdP para a identidade autenticada a ser usada nas chamadas para a API da AWS.

A função real retornada é determinada por meio de informações recebidas do IdP, atributos do usuário no armazenamento de identidade local ou o nome de usuário e o serviço de autenticação do armazenamento de identidade da web.

 

Autenticação

Existem três maneiras pelas quais o IAM autentica uma entidade:

 

  • Nome de usuário / senha – Quando um principal representa um humano que interage com o console, o humano fornecerá um par de nome de usuário / senha para verificar sua identidade. O IAM permite criar uma política de senha que imponha complexidade e expiração de senha.
  • Chave de acesso – Uma chave de acesso é uma combinação de um ID da chave de acesso (20 caracteres) e uma chave secreta de acesso (40 caracteres). Quando um programa está manipulando a infraestrutura da AWS por meio da API, ele usa esses valores para assinar as chamadas REST subjacentes aos serviços. Os SDKs e ferramentas da AWS lidam com todos os meandros da assinatura de chamadas REST. Portanto, usar uma chave de acesso quase sempre será uma questão de fornecer os valores ao SDK ou à ferramenta.
  • Chave de acesso / token de sessão – Quando um processo opera sob uma função assumida, o token de segurança temporário fornece uma chave de acesso para autenticação. Além da chave de acesso (lembre-se de que ela consiste em duas partes), o token também inclui um token de sessão.

As chamadas para a AWS devem incluir a chave de acesso em duas partes e o token da sessão para autenticação.

É importante observar que, quando um usuário do IAM é criado, ele não possui uma chave de acesso nem uma senha, e o administrador do IAM pode configurar um ou ambos.

Isso adiciona uma camada extra de segurança, pois os usuários do console não podem usar suas credenciais para executar um programa que acessa sua infraestrutura da AWS.

 

Autorização

Depois que o IAM autentica um principal, ele deve gerenciar o acesso desse principal para proteger sua infraestrutura da AWS.

O processo de especificar exatamente quais ações um diretor pode ou não executar é chamado de autorização.

A autorização é tratada no IAM, definindo privilégios específicos nas políticas e associando essas políticas aos principais.

 

Políticas

O entendimento de como o gerenciamento de acesso funciona no IAM começa com o entendimento de políticas. Uma política é um documento JSON que define completamente um conjunto de permissões para acessar e manipular os recursos da AWS.

Os documentos de política contêm uma ou mais permissões, com cada permissão definindo:

  • Efeito – uma única palavra: Permitir ou Negar.
  • Serviço – Para que serviço essa permissão se aplica? A maioria dos serviços em nuvem da AWS oferece suporte à concessão de acesso por meio do IAM, incluindo o próprio IAM.
  • Recurso – o valor do recurso especifica a infraestrutura específica da AWS à qual essa permissão se aplica.

Isso é especificado como um ARN (Amazon Resource Name). O formato para um ARN varia um pouco entre os serviços, mas o formato básico é: “arn: aws: service: region: account-id: [resourcetype:] resource”

Para alguns serviços, valores curinga são permitidos; por exemplo, um Amazon S3 ARN poderia ter um recurso de foldername \ * para indicar todos os objetos na pasta especificada

 

Associando Políticas a Principais (recursos demandantes)

 

Existem várias maneiras de associar uma política a um usuário do IAM; Esta seção cobrirá apenas os mais comuns. Uma política pode ser associada diretamente a um usuário do IAM de duas maneiras:

 

  • Política do usuário – Essas políticas existem apenas no contexto do usuário ao qual estão anexadas. No console, uma política de usuário é inserida na interface do usuário na página de usuário do IAM.
  • Políticas gerenciadas – Essas políticas são criadas na guia Políticas na página do IAM (ou através da CLI e assim por diante) e existem independentemente de qualquer usuário individual. Dessa maneira, a mesma política pode ser associada a muitos usuários ou grupos de usuários.

Há um grande número de políticas gerenciadas predefinidas que você pode revisar na guia Políticas da página IAM no AWS Management Console. Além disso, você pode escrever suas próprias políticas específicas para seus casos de uso.

O uso de políticas gerenciadas predefinidas garante que, quando novas permissões forem adicionadas para novos recursos, seus usuários ainda tenham o acesso correto.

O outro método comum para associar políticas a usuários é o recurso de grupos do IAM. Os grupos simplificam o gerenciamento de permissões para um grande número de usuários. Depois que uma política é atribuída a um grupo, qualquer usuário que seja membro desse grupo assume essas permissões.

Isso simplifica a atribuição de políticas a uma equipe inteira em sua organização.

Por exemplo, se você criar um grupo “Operações” com todos os usuários do IAM para sua equipe de operações atribuídos a esse grupo, é simples associar as permissões necessárias ao grupo, e todos os usuários do IAM da equipe assumirão essas permissões . Novos usuários do IAM podem ser atribuídos diretamente ao grupo.

Esse é um processo de gerenciamento muito mais simples do que ter que revisar quais políticas um novo usuário do IAM para a equipe de operações deve receber e adicionar manualmente essas políticas ao usuário.

Há duas maneiras de associar uma política a um grupo do IAM:

  • Política de Grupo – Essas políticas existem apenas no contexto do grupo ao qual estão anexadas. No AWS Management Console, uma política de grupo é inserida na interface do usuário na página Grupo do IAM.
  • Políticas gerenciadas – Da mesma maneira que as políticas gerenciadas (discutidas na seção “Autorização”) podem ser associadas aos usuários do IAM, elas também podem ser associadas aos grupos do IAM.

Uma boa primeira etapa é usar o usuário root para criar um novo grupo do IAM chamado “Administradores do IAM” e atribuir a política gerenciada, “IAMFullAccess”.

Em seguida, crie um novo usuário do IAM chamado “Administrador”, atribua uma senha e adicione-a ao grupo Administradores do IAM. Nesse ponto, você pode fazer logoff como usuário raiz e realizar toda a administração adicional com a conta de usuário do IAM.

A maneira final de um ator poder ser associado a uma política é assumindo um papel. Nesse caso, o ator pode ser:

  • Um usuário IAM autenticado (pessoa ou processo). Nesse caso, o usuário do IAM deve ter os direitos para assumir a função.
  • Uma pessoa ou processo autenticado por um serviço confiável fora da AWS, como um diretório LDAP exclusivo ou um serviço de autenticação da web. Nessa situação, um serviço da AWS Cloud assumirá a função em nome do ator e devolverá um token ao ator.

Depois que um ator assume uma função, ele recebe um token de segurança temporário associado às políticas dessa função. O token contém todas as informações necessárias para autenticar as chamadas de API.

Essas informações incluem uma chave de acesso padrão e um token de sessão adicional necessário para autenticar chamadas em uma função assumida.

 

Outros recursos principais

Além dos conceitos críticos de entidades, autenticação e autorização, existem vários outros recursos do serviço IAM que são importantes para entender para obter todos os benefícios do IAM.

 

Autenticação Multifator (MFA)

A autenticação multifator (MFA) pode adicionar uma camada extra de segurança à sua infraestrutura, adicionando um segundo método de autenticação além de apenas uma senha ou chave de acesso.

Com o MFA, a autenticação também exige a inserção de uma Senha de uso único (OTP) a partir de um dispositivo pequeno.

O dispositivo MFA pode ser um pequeno dispositivo de hardware que você carrega com você ou um dispositivo virtual por meio de um aplicativo no seu smartphone (por exemplo, o aplicativo AWS Virtual MFA). O MFA exige que você verifique sua identidade com algo que você conhece e algo que possui.

O MFA pode ser atribuído a qualquer conta de usuário do IAM, independentemente de representar uma pessoa ou aplicativo.

Quando uma pessoa que usa um usuário do IAM configurado com o MFA tenta acessar o Console de Gerenciamento da AWS, depois de fornecer sua senha, será solicitado a inserir o código atual exibido no dispositivo MFA antes de receber acesso.

Um aplicativo que usa um usuário do IAM configurado com o MFA deve consultar o usuário do aplicativo para fornecer o código atual, que o aplicativo passará para a API.

É altamente recomendável que os clientes da AWS adicionem proteção MFA ao usuário root.

 

Chaves Rotativas

O risco de segurança de qualquer credencial aumenta com a idade da credencial. Para esse fim, é uma prática recomendada de segurança girar as chaves de acesso associadas aos usuários do IAM.

O IAM facilita esse processo, permitindo duas chaves de acesso ativas por vez. O processo para girar as chaves pode ser conduzido por meio do console, CLI ou SDKs:

  1. Crie uma nova chave de acesso para o usuário.
  2. Reconfigure todos os aplicativos para usar a nova chave de acesso.
  3. Desabilite a chave de acesso original (a desativação em vez de excluir neste estágio é crítica, pois permite a reversão da chave original se houver problemas com a rotação).
  4. Verifique o funcionamento de todos os aplicativos.
  5. Exclua a chave de acesso original.

 

As teclas de acesso devem ser rotacionadas regularmente.

 

Resolvendo Várias Permissões

Ocasionalmente, várias permissões serão aplicáveis ​​ao determinar se um principal tem o privilégio de executar alguma ação.

Essas permissões podem vir de várias políticas associadas a uma política principal ou de recursos anexada ao recurso da AWS em questão. É importante saber como os conflitos entre essas permissões são resolvidos:

  1. Inicialmente, a solicitação é negada por padrão.
  2. Todas as políticas apropriadas são avaliadas; se houver uma “negação” explícita encontrada em qualquer política, a solicitação será negada e a avaliação será interrompida.
  3. Se nenhum “negar” explícito for encontrado e um “permitir” explícito for encontrado em qualquer política, a solicitação será permitida.
  4. Se não houver permissões explícitas de “permitir” ou “negar” encontradas, o padrão “negar” será mantido e a solicitação será negada.

A única exceção a essa regra é que, se uma chamada AssumeRole incluir uma função e uma política, a política não poderá expandir os privilégios da função (por exemplo, a política não poderá substituir nenhuma permissão negada por padrão na função).

Comentários do Facebook

Conteúdos relacionados