Um dos erros mais comuns na AWS e "Access Denied". O IAM (Identity and Access Management) e o servico de seguranca central da AWS que decide "quem pode fazer o que em quais recursos". Este guia explica o IAM desde os basicos ate conceitos avancados de forma amigavel para iniciantes.
Componentes Basicos do IAM
Pense no sistema de controle de acesso de uma empresa. Funcionarios carregam seus crachas (usuarios). Diferentes departamentos podem acessar diferentes areas. O IAM segue a mesma estrutura.
Um Usuario e uma pessoa individual ou aplicacao que acessa a AWS. Cada usuario tem credenciais unicas: uma senha para acesso ao console ou uma chave de acesso para acesso programatico.
Um Grupo e uma colecao de usuarios que compartilham as mesmas permissoes. Crie um grupo "equipe de desenvolvimento" e todos os desenvolvedores nele automaticamente recebem as mesmas permissoes. Quando um novo desenvolvedor entra, basta adicioná-lo ao grupo. Importante: grupos nao podem conter outros grupos.
Um Role (funcao) concede permissoes temporarias a servicos AWS ou usuarios externos, nao credenciais de longo prazo. Quando uma instancia EC2 precisa acessar um bucket S3, voce anexa um role a instancia em vez de incorporar chaves de acesso. O role emite credenciais temporarias que expiram automaticamente.
Uma Politica e um documento JSON que diz "permitir ou negar essas acoes especificas nesses recursos especificos para esse servico especifico".
Tipos de Politicas
O IAM tem varios tipos de politicas, cada uma servindo a um proposito diferente.
Politicas baseadas em identidade sao anexadas a usuarios, grupos ou roles. Elas definem o que a identidade pode fazer. Existem em duas formas: AWS Managed Policies (criadas e mantidas pela AWS) e Customer Managed Policies (criadas por voce).
Politicas baseadas em recursos sao anexadas diretamente a recursos como buckets S3, filas SQS e chaves KMS. Elas definem quem pode acessar o recurso. Diferentemente das politicas baseadas em identidade, requerem um Principal (quem esta recebendo acesso). Isso e especialmente util para conceder acesso a usuarios de outras contas.
Permission Boundaries definem o maximo de permissoes que um usuario ou role pode ter. Pense como uma cerca que diz "voce so pode conceder permissoes dentro deste limite". Por exemplo, voce da ao lider de equipe permissao para criar usuarios IAM, mas adiciona um Permission Boundary para que nao possam criar usuarios com mais permissoes do que eles proprios tem.
SCPs sao as restricoes no nivel organizacional abordadas no artigo anterior.
| Tipo de Politica | Aplicada a | Caracteristica Principal | |-----------------|------------|------------------------| | Identity-based | Usuarios, grupos, roles | Define o que a identidade pode fazer | | Resource-based | S3, SQS, KMS etc. | Requer Principal, habilita entre contas | | Permission Boundary | Usuarios, roles | Teto de permissoes maximas | | SCP | OUs, contas | Restricao no nivel organizacional, nao aplicada a conta de gerenciamento |
Logica de Avaliacao de Politicas — Como a AWS Decide Permitir ou Negar
Esta e a parte mais dificil e importante do IAM. Quando uma solicitacao chega, a AWS examina multiplas politicas para determinar se permite ou nao.
A regra central tem tres etapas. Primeiro, se houver um Deny explicito em qualquer lugar, a solicitacao e negada incondicionalmente. Nenhuma outra politica Allow pode substituir um Deny. Segundo, se houver um Allow explicito e nenhum Deny, a solicitacao e permitida. Terceiro, se nao houver nenhum dos dois, o resultado e um Deny implicito. Na AWS, tudo e negado por padrao a menos que seja explicitamente permitido.
Regra de mesma conta: se a politica baseada em identidade ou a politica baseada em recursos permitir a acao, o acesso e permitido (uniao).
Regra de contas cruzadas: tanto a politica baseada em identidade na conta solicitante quanto a politica baseada em recursos no recurso de destino devem permitir a acao. Um Allow em apenas uma delas nao e suficiente (intersecao).
Um cenario real: o desenvolvedor A tem uma politica Allow para ler um bucket S3, mas o acesso e negado. Possiveis causas incluem: um SCP bloqueando o servico S3 para aquela conta, um Permission Boundary no usuario que exclui S3, um Deny explicito na politica baseada em recursos do bucket S3, ou uma politica de endpoint VPC bloqueando a solicitacao.
Dica de exame: "Existe uma politica Allow mas o acesso ainda e negado" — a resposta e verificar se ha um Deny explicito em algum lugar (SCP, Permission Boundary, politica baseada em recursos).
MFA — Protegendo Contas com Autenticacao de Dois Fatores
Proteger uma conta apenas com senha nao e suficiente. Se a senha for roubada, a conta fica imediatamente comprometida. O MFA (Multi-Factor Authentication) requer uma segunda forma de verificacao alem da senha, como um caixa eletronico que requer tanto seu cartao quanto seu PIN.
Ha tres tipos de MFA. Dispositivos MFA virtuais sao aplicativos de smartphone como Google Authenticator ou Authy que geram um codigo de seis digitos que muda a cada trinta segundos. Dispositivos MFA de hardware sao tokens fisicos como YubiKey. Chaves de seguranca U2F sao chaves de seguranca padrao FIDO baseadas em USB.
Voce pode impor MFA atraves de condicoes de politicas IAM. Usando a chave de condicao aws:MultiFactorAuthPresent, voce pode criar uma politica que nega acoes especificas a menos que MFA tenha sido usado para autenticacao. Por exemplo: "negar a terminacao de instancias EC2 a menos que o usuario tenha se autenticado com MFA".
A conta root deve ter MFA habilitado sem excecao. A conta root tem poder ilimitado sobre toda a conta AWS e deve ser protegida no nivel mais alto.
Dica de exame: "Bloquear chamadas de API de usuarios que nao se autenticaram com MFA" — a resposta e adicionar a condicao aws:MultiFactorAuthPresent a politica IAM.
Federacao — Fazendo Login na AWS com Contas Externas
Os funcionarios da sua empresa ja tem contas do Active Directory. Voce quer que acessem a AWS usando essas mesmas contas corporativas sem criar contas IAM da AWS separadas para cada pessoa. Isso e federacao.
A Federacao SAML 2.0 e a mais comum em ambientes empresariais. Ela conecta o Active Directory ou ADFS (Active Directory Federation Services) da sua empresa com a AWS. Os funcionarios fazem login no portal SSO da empresa, e atraves do STS AssumeRoleWithSAML recebem credenciais temporarias da AWS e acessam o console.
A Federacao OIDC e usada em aplicativos moveis ou web. Os usuarios fazem login com contas do Google, Facebook ou Apple e acessam recursos AWS atraves dessa identidade. O Amazon Cognito simplifica essa integracao.
O AWS IAM Identity Center (anteriormente AWS SSO) fornece SSO centralizado em multiplas contas AWS. Um unico login da acesso ao console de qualquer conta para a qual voce tem permissoes. Integra-se com o Organizations e gerencia permissoes por conta atraves de Permission Sets. Esta e a abordagem recomendada para ambientes multi-conta.
Dica de exame: "Usuarios do Active Directory corporativo precisam acessar o console AWS" — a resposta e federacao SAML 2.0 ou IAM Identity Center.
IAM Access Analyzer — Encontrando Recursos Expostos Externamente
Um dia voce descobre que um bucket S3 e publicamente acessivel para qualquer pessoa no mundo. Voce precisa saber quando isso aconteceu e se outros recursos tambem estao expostos. O IAM Access Analyzer encontra essas situacoes automaticamente.
O IAM Access Analyzer identifica automaticamente recursos que sao acessiveis de fora da sua conta, seja de outras contas AWS ou da internet publica. E como uma inspecao de seguranca que encontra portas destrancadas.
Os recursos analisados incluem: politicas de bucket S3, Trust Policies de roles IAM, politicas de chaves KMS, politicas de filas SQS, politicas de funcoes Lambda e politicas de segredos do Secrets Manager.
Quando recursos acessiveis externamente sao encontrados, o Access Analyzer cria um "Finding". Voce revisa cada Finding: se o acesso externo e intencional, marque como "Archive". Se for exposicao nao intencional, corrija a politica para remover o acesso.
O Access Analyzer tem dois recursos adicionais importantes. O recurso de geracao de politicas analisa seus logs do CloudTrail e gera automaticamente uma politica de menor privilegio com base nas acoes que foram realmente usadas. O recurso de validacao de politicas verifica a sintaxe de politicas IAM e sinaliza violacoes de boas praticas.
Dica de exame: "Detectar automaticamente se um bucket S3 e publicamente acessivel" — a resposta e IAM Access Analyzer.
Roles Vinculados a Servicos
Estes sao roles IAM especiais que os servicos AWS criam automaticamente para gerenciar outros recursos AWS em seu nome. O Auto Scaling precisa de permissoes para criar e encerrar instancias EC2: um role vinculado ao servico fornece essas permissoes automaticamente.
Os usuarios nao podem facilmente modificar ou excluir roles vinculados a servicos, e apenas o servico especifico que os criou pode usa-los. Auto Scaling, ElastiCache, RDS, CloudFormation e muitos outros servicos dependem de roles vinculados a servicos.
Gerenciamento de Chaves de Acesso
Quando um programa chama APIs da AWS diretamente, atraves da AWS CLI, um SDK ou codigo do lado do servidor, ele usa chaves de acesso (Access Key ID mais Secret Access Key) em vez de uma senha.
Melhores praticas para gerenciamento de chaves de acesso: cada usuario pode ter no maximo duas chaves de acesso ativas (util durante a rotacao de chaves para permitir sobreposicao). Rotacionar chaves regularmente. Nunca criar chaves de acesso para a conta root, ou exclui-las imediatamente se existirem. Gerar um Relatorio de Credenciais IAM para ver o uso de chaves de acesso e as datas de ultimo uso de todos os usuarios.
Credenciais Temporarias do STS
O AWS STS (Security Token Service) emite credenciais temporarias com um tempo de