Português - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

AWS - Basic Information

Suporte ao HackTricks

Hierarquia da Organização

Contas

No 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/organização root.

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).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Unidades de Organização

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.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Service Control Policy (SCP)

Uma service control policy (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

ARN

Amazon Resource Name é o nome único que cada recurso dentro da AWS possui, é composto assim:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

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 - Gerenciamento de Identidade e Acesso

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 os mecanismos de autenticação, autorização e controle de acesso das identidades aos seus recursos dentro da sua conta AWS.

Usuário root da 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 da segurança, é recomendado criar outros usuários e evitar usar este.

Usuários IAM

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, o MFA precisa estar presente (exemplo aqui).

CLI

  • 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

MFA - Autenticação de Múltiplos Fatores

É 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 o MFA, você precisa chamar GetSessionToken. Isso lhe dará um token com informações sobre o MFA. Note que as credenciais de AssumeRole não contêm essas informações.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Como afirmado aqui, existem muitos casos diferentes onde MFA não pode ser usado.

Grupos de usuários IAM

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.

Funções IAM

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.

AWS Security Token Service (STS)

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 no IAM

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.

Políticas

Permissões de Política

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).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

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.

Políticas Inline

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ê quiser 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.

Políticas de Bucket de Recursos

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.

Limites IAM

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.

Políticas de Sessão

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.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

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.

Federação de Identidade

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 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.

Centro de Identidade IAM

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 administração de usuários e seu acesso a contas 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.

AwsSSOInlinePolicy

É 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.

Confianças e Funções entre Contas

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 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.

AWS Simple AD

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

Federação Web ou Autenticação OpenID

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.

Outras opções IAM

  • 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.

Prefixos de ID IAM

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

Permissões recomendadas para auditar contas

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

Diversos

Autenticação CLI

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:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

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:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Com este arquivo de configuração, você pode usar aws cli assim:

aws --profile acc2 ...

Se você está procurando algo semelhante a isso, mas para o navegador, você pode conferir a extensão AWS Extend Switch Roles.

Referências

Suporte ao HackTricks
PreviousAWS PentestingNextAWS - Federation Abuse

Last updated