Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Na AWS, existe uma conta root, que é o container pai para todas as contas da sua organização. No entanto, você não precisa usar essa conta para implantar recursos, pode criar outras contas para separar diferentes infraestruturas AWS entre elas.
Isso é muito interessante do ponto de vista de segurança, pois uma conta não poderá acessar recursos de outra conta (exceto se pontes forem especificamente criadas), assim você pode criar limites entre implantações.
Portanto, existem dois tipos de contas em uma organização (estamos falando de contas AWS e não de contas de usuário): uma única conta designada como a conta de gerenciamento e uma ou mais contas membros.
A conta de gerenciamento (a conta root) é a conta que você usa para criar a organização. A partir da conta de gerenciamento da organização, você pode fazer o seguinte:
Criar contas na organização
Convidar outras contas existentes para a organização
Remover contas da organização
Gerenciar convites
Aplicar políticas a entidades (roots, OUs ou contas) dentro da organização
Habilitar integração com serviços AWS suportados para fornecer funcionalidade de serviço em todas as contas da organização.
É possível fazer login como usuário root usando o e-mail e a senha usados para criar esta conta root/organização.
A conta de gerenciamento tem as responsabilidades de uma conta pagadora e é responsável por pagar todas as cobranças acumuladas pelas contas membros. Você não pode mudar a conta de gerenciamento de uma organização.
Contas membros compõem todas as outras contas em uma organização. Uma conta pode ser membro de apenas uma organização por vez. Você pode anexar uma política a uma conta para aplicar controles apenas a essa conta.
Contas membros devem usar um endereço de e-mail válido e podem ter um nome, em geral não poderão gerenciar a cobrança (mas podem ter acesso a ela).
As contas podem ser agrupadas em Unidades de Organização (OU). Dessa forma, você pode criar políticas para a Unidade de Organização que serão aplicadas a todas as contas filhas. Observe que uma OU pode ter outras OUs como filhas.
Uma política de controle de serviço (SCP) é uma política que especifica os serviços e ações que usuários e funções podem usar nas contas que a SCP afeta. SCPs são semelhantes às políticas de permissões do IAM, exceto que não concedem permissões. Em vez disso, as SCPs especificam as permissões máximas para uma organização, unidade organizacional (OU) ou conta. Quando você anexa uma SCP à raiz da sua organização ou a uma OU, a SCP limita as permissões para entidades em contas membros.
Esta é a ÚNICA maneira que até mesmo o usuário root pode ser impedido de fazer algo. Por exemplo, pode ser usada para impedir que usuários desativem o CloudTrail ou excluam backups. A única maneira de contornar isso é comprometer também a conta mestre que configura as SCPs (a conta mestre não pode ser bloqueada).
Observe que as SCPs apenas restringem os principais na conta, portanto, outras contas não são afetadas. Isso significa que ter uma SCP que nega s3:GetObject não impedirá as pessoas de acessar um bucket S3 público em sua conta.
Exemplos de SCP:
Negar completamente a conta root
Permitir apenas regiões específicas
Permitir apenas serviços na lista branca
Negar o GuardDuty, CloudTrail e o acesso público ao S3 de
serem desativados
Negar que funções de segurança/resposta a incidentes sejam excluídas ou
modificadas.
Negar que backups sejam excluídos.
Negar a criação de usuários IAM e chaves de acesso
Encontre exemplos JSON em https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Amazon Resource Name é o nome único que cada recurso dentro da AWS possui, é composto assim:
Note que existem 4 partições na AWS, mas apenas 3 maneiras de chamá-las:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM é o serviço que permitirá que você gerencie Autenticação, Autorização e Controle de Acesso dentro da sua conta AWS.
Autenticação - Processo de definição de uma identidade e a verificação dessa identidade. Este processo pode ser subdividido em: Identificação e verificação.
Autorização - Determina o que uma identidade pode acessar dentro de um sistema uma vez que foi autenticada.
Controle de Acesso - O método e processo de como o acesso é concedido a um recurso seguro.
IAM pode ser definido pela sua capacidade de gerenciar, controlar e governar mecanismos de autenticação, autorização e controle de acesso de identidades aos seus recursos dentro da sua conta AWS.
Quando você cria uma conta da Amazon Web Services (AWS) pela primeira vez, você começa com uma única identidade de login que tem acesso completo a todos os serviços e recursos da AWS na conta. Este é o usuário root da conta AWS e é acessado fazendo login com o endereço de e-mail e a senha que você usou para criar a conta.
Note que um novo usuário admin terá menos permissões que o usuário root.
Do ponto de vista de segurança, é recomendado criar outros usuários e evitar usar este.
Um usuário IAM é uma entidade que você cria na AWS para representar a pessoa ou aplicação que a utiliza para interagir com a AWS. Um usuário na AWS consiste em um nome e credenciais (senha e até duas chaves de acesso).
Quando você cria um usuário IAM, você concede permissões tornando-o um membro de um grupo de usuários que tem políticas de permissão apropriadas anexadas (recomendado), ou anexando políticas diretamente ao usuário.
Os usuários podem ter MFA habilitado para login através do console. Tokens de API de usuários com MFA habilitado não são protegidos por MFA. Se você quiser restringir o acesso das chaves de API de um usuário usando MFA, você precisa indicar na política que, para realizar certas ações, a MFA precisa estar presente (exemplo aqui).
ID da Chave de Acesso: 20 caracteres alfanuméricos aleatórios em maiúsculas como AKHDNAPO86BSHKDIRYT
ID da Chave de Acesso Secreta: 40 caracteres aleatórios em maiúsculas e minúsculas: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Não é possível recuperar IDs de chave de acesso secreta perdidos).
Sempre que você precisar mudar a Chave de Acesso, este é o processo que você deve seguir: Criar uma nova chave de acesso -> Aplicar a nova chave ao sistema/aplicação -> marcar a original como inativa -> Testar e verificar se a nova chave de acesso está funcionando -> Deletar a chave de acesso antiga
É usado para criar um fator adicional para autenticação além dos seus métodos existentes, como senha, criando assim um nível de autenticação multifatorial. Você pode usar um aplicativo virtual gratuito ou um dispositivo físico. Você pode usar aplicativos como o google authentication gratuitamente para ativar um MFA na AWS.
Políticas com condições de MFA podem ser anexadas aos seguintes:
Um usuário ou grupo IAM
Um recurso como um bucket Amazon S3, fila Amazon SQS ou tópico Amazon SNS
A política de confiança de um papel IAM que pode ser assumido por um usuário
Se você quiser acessar via CLI um recurso que verifica MFA, você precisa chamar GetSessionToken. Isso lhe dará um token com informações sobre MFA.
Note que as credenciais de AssumeRole não contêm essas informações.
Como afirmado aqui, existem muitos casos diferentes onde MFA não pode ser usado.
Um grupo de usuários IAM é uma maneira de anexar políticas a vários usuários ao mesmo tempo, o que pode facilitar a gestão das permissões para esses usuários. Funções e grupos não podem ser parte de um grupo.
Você pode anexar uma política baseada em identidade a um grupo de usuários para que todos os usuários no grupo de usuários recebam as permissões da política. Você não pode identificar um grupo de usuários como um Principal em uma política (como uma política baseada em recursos) porque grupos se relacionam a permissões, não a autenticação, e os principais são entidades IAM autenticadas.
Aqui estão algumas características importantes dos grupos de usuários:
Um grupo de usuários pode contém muitos usuários, e um usuário pode pertencer a vários grupos.
Grupos de usuários não podem ser aninhados; eles podem conter apenas usuários, não outros grupos de usuários.
Não há grupo de usuários padrão que inclua automaticamente todos os usuários na conta AWS. Se você quiser ter um grupo de usuários assim, deve criá-lo e atribuir cada novo usuário a ele.
O número e o tamanho dos recursos IAM em uma conta AWS, como o número de grupos e o número de grupos dos quais um usuário pode ser membro, são limitados. Para mais informações, veja cotas IAM e AWS STS.
Uma função IAM é muito semelhante a um usuário, na medida em que é uma identidade com políticas de permissão que determinam o que pode e não pode fazer na AWS. No entanto, uma função não tem credenciais (senha ou chaves de acesso) associadas a ela. Em vez de estar exclusivamente associada a uma pessoa, uma função é destinada a ser assumida por qualquer um que precise dela (e tenha permissões suficientes). Um usuário IAM pode assumir uma função para temporariamente assumir diferentes permissões para uma tarefa específica. Uma função pode ser atribuída a um usuário federado que faz login usando um provedor de identidade externo em vez de IAM.
Uma função IAM consiste em dois tipos de políticas: uma política de confiança, que não pode estar vazia, definindo quem pode assumir a função, e uma política de permissões, que não pode estar vazia, definindo o que pode acessar.
O AWS Security Token Service (STS) é um serviço web que facilita a emissão de credenciais temporárias e de privilégio limitado. É especificamente adaptado para:
Credenciais temporárias são usadas principalmente com funções IAM, mas também há outros usos. Você pode solicitar credenciais temporárias que têm um conjunto de permissões mais restrito do que seu usuário IAM padrão. Isso impede que você realize acidentalmente tarefas que não são permitidas pelas credenciais mais restritas. Um benefício das credenciais temporárias é que elas expiram automaticamente após um período definido. Você tem controle sobre a duração que as credenciais são válidas.
São usadas para atribuir permissões. Existem 2 tipos:
Políticas gerenciadas pela AWS (pré-configuradas pela AWS)
Políticas Gerenciadas pelo Cliente: Configuradas por você. Você pode criar políticas com base em políticas gerenciadas pela AWS (modificando uma delas e criando a sua própria), usando o gerador de políticas (uma visualização GUI que ajuda a conceder e negar permissões) ou escrevendo a sua própria.
Por padrão, o acesso é negado, o acesso será concedido se um papel explícito tiver sido especificado. Se um único "Negar" existir, ele substituirá o "Permitir", exceto para solicitações que usam as credenciais de segurança raiz da conta AWS (que são permitidas por padrão).
Os campos globais que podem ser usados para condições em qualquer serviço estão documentados aqui. Os campos específicos que podem ser usados para condições por serviço estão documentados aqui.
Esse tipo de políticas é atribuído diretamente a um usuário, grupo ou função. Assim, elas não aparecem na lista de Políticas, pois qualquer outra pode usá-las. As políticas inline são úteis se você deseja manter uma relação estrita um-para-um entre uma política e a identidade à qual ela é aplicada. Por exemplo, você quer ter certeza de que as permissões em uma política não são atribuídas inadvertidamente a uma identidade diferente daquela para a qual foram destinadas. Quando você usa uma política inline, as permissões na política não podem ser anexadas inadvertidamente à identidade errada. Além disso, quando você usa o AWS Management Console para excluir essa identidade, as políticas incorporadas na identidade também são excluídas. Isso ocorre porque elas fazem parte da entidade principal.
Essas são políticas que podem ser definidas em recursos. Nem todos os recursos da AWS as suportam.
Se um principal não tiver uma negação explícita sobre elas, e uma política de recurso conceder acesso, então eles são permitidos.
Os limites IAM podem ser usados para limitar as permissões que um usuário ou função deve ter acesso. Dessa forma, mesmo que um conjunto diferente de permissões seja concedido ao usuário por uma política diferente, a operação falhará se ele tentar usá-las.
Um limite é apenas uma política anexada a um usuário que indica o nível máximo de permissões que o usuário ou função pode ter. Portanto, mesmo que o usuário tenha acesso de Administrador, se o limite indicar que ele pode apenas ler buckets S·, esse é o máximo que ele pode fazer.
Isso, SCPs e seguir o princípio do menor privilégio são as maneiras de controlar que os usuários não tenham mais permissões do que as que precisam.
Uma política de sessão é uma política definida quando uma função é assumida de alguma forma. Isso será como um limite IAM para essa sessão: Isso significa que a política de sessão não concede permissões, mas as restringe às indicadas na política (sendo as permissões máximas aquelas que a função possui).
Isso é útil para medidas de segurança: Quando um administrador vai assumir uma função muito privilegiada, ele pode restringir a permissão apenas às indicadas na política de sessão, caso a sessão seja comprometida.
Note que, por padrão, a AWS pode adicionar políticas de sessão às sessões que estão prestes a ser geradas por razões de terceiros. Por exemplo, em funções assumidas do cognito não autenticadas por padrão (usando autenticação aprimorada), a AWS gerará credenciais de sessão com uma política de sessão que limita os serviços que a sessão pode acessar à seguinte lista.
Portanto, se em algum momento você enfrentar o erro "... porque nenhuma política de sessão permite o ...", e a função tem acesso para realizar a ação, é porque há uma política de sessão impedindo isso.
A federação de identidade permite que usuários de provedores de identidade que são externos à AWS acessem recursos da AWS de forma segura, sem precisar fornecer credenciais de usuário da AWS de uma conta IAM válida. Um exemplo de um provedor de identidade pode ser o seu próprio Microsoft Active Directory corporativo (via SAML) ou serviços OpenID (como Google). O acesso federado permitirá que os usuários dentro dele acessem a AWS.
Para configurar essa confiança, um Provedor de Identidade IAM é gerado (SAML ou OAuth) que confiará na outra plataforma. Em seguida, pelo menos uma função IAM é atribuída (confiando) ao Provedor de Identidade. Se um usuário da plataforma confiável acessar a AWS, ele estará acessando como a função mencionada.
No entanto, você geralmente desejará dar uma função diferente dependendo do grupo do usuário na plataforma de terceiros. Assim, várias funções IAM podem confiar no Provedor de Identidade de terceiros e a plataforma de terceiros será a responsável por permitir que os usuários assumam uma função ou outra.
O AWS IAM Identity Center (sucessor do AWS Single Sign-On) expande as capacidades do AWS Identity and Access Management (IAM) para fornecer um local central que reúne a administração de usuários e seu acesso às contas da AWS e aplicativos em nuvem.
O domínio de login será algo como <user_input>.awsapps.com.
Para fazer login dos usuários, existem 3 fontes de identidade que podem ser usadas:
Diretório do Identity Center: Usuários regulares da AWS
Active Directory: Suporta diferentes conectores
Provedor de Identidade Externo: Todos os usuários e grupos vêm de um Provedor de Identidade externo (IdP)
No caso mais simples do diretório do Identity Center, o Identity Center terá uma lista de usuários e grupos e será capaz de atribuir políticas a eles para qualquer uma das contas da organização.
Para dar acesso a um usuário/grupo do Identity Center a uma conta, um Provedor de Identidade SAML confiando no Identity Center será criado, e uma função confiando no Provedor de Identidade com as políticas indicadas será criada na conta de destino.
É possível dar permissões via políticas inline para funções criadas via IAM Identity Center. As funções criadas nas contas que estão recebendo políticas inline no AWS Identity Center terão essas permissões em uma política inline chamada AwsSSOInlinePolicy.
Portanto, mesmo que você veja 2 funções com uma política inline chamada AwsSSOInlinePolicy, isso não significa que elas têm as mesmas permissões.
Um usuário (confiando) pode criar uma Função entre Contas com algumas políticas e, em seguida, permitir que outro usuário (confiável) acesse sua conta, mas apenas tendo o acesso indicado nas novas políticas da função. Para criar isso, basta criar uma nova Função e selecionar Função entre Contas. Funções para Acesso entre Contas oferecem duas opções. Fornecendo acesso entre contas da AWS que você possui e fornecendo acesso entre uma conta que você possui e uma conta AWS de terceiros. É recomendado especificar o usuário que é confiável e não colocar algo genérico, porque, caso contrário, outros usuários autenticados, como usuários federados, também poderão abusar dessa confiança.
Não suportado:
Relações de Confiança
Centro de Administração do AD
Suporte completo à API PS
Lixeira do AD
Contas de Serviço Gerenciadas por Grupo
Extensões de Esquema
Sem acesso direto ao SO ou Instâncias
O aplicativo usa o AssumeRoleWithWebIdentity para criar credenciais temporárias. No entanto, isso não concede acesso ao console da AWS, apenas acesso a recursos dentro da AWS.
Você pode definir uma configuração de política de senha com opções como comprimento mínimo e requisitos de senha.
Você pode baixar o "Relatório de Credenciais" com informações sobre credenciais atuais (como tempo de criação do usuário, se a senha está habilitada...). Você pode gerar um relatório de credenciais com a frequência de uma vez a cada quatro horas.
O AWS Identity and Access Management (IAM) fornece controle de acesso detalhado em toda a AWS. Com o IAM, você pode especificar quem pode acessar quais serviços e recursos, e sob quais condições. Com as políticas IAM, você gerencia permissões para sua força de trabalho e sistemas para garantir permissões de menor privilégio.
Na esta página você pode encontrar os prefixos de ID IAM de chaves dependendo de sua natureza:
ABIA | |
ACCA | Credencial específica do contexto |
AGPA | Grupo de usuários |
AIDA | Usuário IAM |
AIPA | Perfil de instância do Amazon EC2 |
AKIA | Chave de acesso |
ANPA | Política gerenciada |
ANVA | Versão em uma política gerenciada |
APKA | Chave pública |
AROA | Função |
ASCA | Certificado |
ASIA | IDs de chaves de acesso temporárias (AWS STS) usam este prefixo, mas são únicas apenas em combinação com a chave de acesso secreta e o token de sessão. |
Os seguintes privilégios concedem vários acessos de leitura de metadados:
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
Para que um usuário regular se autentique na AWS via CLI, você precisa ter credenciais locais. Por padrão, você pode configurá-las manualmente em ~/.aws/credentials ou executando aws configure.
Nesse arquivo, você pode ter mais de um perfil; se nenhum perfil for especificado usando a aws cli, o chamado [default] nesse arquivo será usado.
Exemplo de arquivo de credenciais com mais de 1 perfil:
Se você precisar acessar diferentes contas AWS e seu perfil tiver acesso para assumir um papel dentro dessas contas, você não precisa chamar manualmente o STS toda vez (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) e configurar as credenciais.
Você pode usar o arquivo ~/.aws/config para indicar quais papéis assumir, e então usar o parâmetro --profile como de costume (o assume-role será realizado de forma transparente para o usuário).
Um exemplo de arquivo de configuração:
Com este arquivo de configuração, você pode usar aws cli assim:
Se você está procurando algo semelhante a isso, mas para o navegador, você pode conferir a extensão AWS Extend Switch Roles.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
