# AWS - Informações Básicas {{#include ../../../banners/hacktricks-training.md}} ## Hierarquia da Organização ![](<../../../images/image (151).png>) ### 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. - As **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. - As contas membros **devem usar um endereço de e-mail válido** e podem ter um **nome**, em geral, elas não poderão gerenciar a cobrança (mas podem receber acesso a isso). ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` ### **Unidades Organizacionais** Contas podem ser agrupadas em **Unidades Organizacionais (OU)**. Dessa forma, você pode criar **políticas** para a Unidade Organizacional que serão **aplicadas a todas as contas filhas**. Observe que uma OU pode ter outras OUs como filhas. ```bash # 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, poderia ser usada para impedir que usuários desativem o CloudTrail ou excluam backups.\ A única maneira de contornar isso é comprometer também a **conta master** que configura as SCPs (a conta master não pode ser bloqueada). > [!WARNING] > 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 que o GuardDuty, CloudTrail e o Acesso Público do S3 sejam 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](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) ### Resource Control Policy (RCP) Uma **resource control policy (RCP)** é uma política que define as **permissões máximas para recursos dentro da sua organização AWS**. RCPs são semelhantes às políticas IAM em sintaxe, mas **não concedem permissões**—elas apenas limitam as permissões que podem ser aplicadas a recursos por outras políticas. Quando você anexa uma RCP à raiz da sua organização, a uma unidade organizacional (OU) ou a uma conta, a RCP limita as permissões de recursos em todos os recursos no escopo afetado. Esta é a ÚNICA maneira de garantir que **os recursos não possam exceder níveis de acesso predefinidos**—mesmo que uma política baseada em identidade ou baseada em recurso seja muito permissiva. A única maneira de contornar esses limites é também modificar a RCP configurada pela conta de gerenciamento da sua organização. > [!WARNING] > As RCPs apenas restringem as permissões que os recursos podem ter. Elas não controlam diretamente o que os principais podem fazer. Por exemplo, se uma RCP nega acesso externo a um bucket S3, ela garante que as permissões do bucket nunca permitam ações além do limite definido—mesmo que uma política baseada em recurso esteja mal configurada. Exemplos de RCP: - Restringir buckets S3 para que possam ser acessados apenas por principais dentro da sua organização - Limitar o uso de chaves KMS para permitir apenas operações de contas organizacionais confiáveis - Limitar permissões em filas SQS para evitar modificações não autorizadas - Impor limites de acesso em segredos do Secrets Manager para proteger dados sensíveis Encontre exemplos na [documentação de Políticas de Controle de Recursos da AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.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 - Identity and Access Management 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. ### [Usuário root da conta AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) Quando você cria uma conta da Amazon Web Services (AWS) pela primeira vez, você começa com uma identidade de login única 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. ### [Usuários IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) 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**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). #### 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 - Multi Factor Authentication É 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**. ```bash aws sts get-session-token --serial-number --token-code ``` Como [**afirmado aqui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), existem muitos casos diferentes onde **MFA não pode ser usado**. ### [Grupos de usuários IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) Um [grupo de usuários IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) é 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). ### [Funções IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 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 permissões diferentes para uma tarefa específica. Uma função pode ser **atribuída a um** [**usuário federado**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 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**. #### Serviço de Token de Segurança da AWS (STS) O Serviço de Token de Segurança da AWS (STS) é um serviço da web que facilita a **emissão de credenciais temporárias de privilégio limitado**. É especificamente adaptado para: ### [Credenciais temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) **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 em 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 **uma única "Negar" existir, ela irá sobrepor o "Permitir"**, exceto para solicitações que usam as credenciais de segurança raiz da conta AWS (que são permitidas por padrão). ```javascript { "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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\ Os [campos específicos que podem ser usados para condições por serviço estão documentados aqui](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html). #### Políticas Inline Esse tipo de políticas são **atribuídas 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.\ 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. #### 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 ele está autorizado. ### Limites do IAM Os limites do 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 do 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. ```bash aws sts assume-role \ --role-arn \ --role-session-name \ [--policy-arns ] [--policy ] ``` 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](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles), 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**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). 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 `.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 sendo dadas **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 granular** 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**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids), você pode encontrar os **prefixos de ID IAM** de chaves dependendo de sua natureza: | Código do Identificador | Descrição | | --------------- | ----------------------------------------------------------------------------------------------------------- | | ABIA | [Token portador do serviço AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | | 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)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) usam este prefixo, mas são únicos apenas em combinação com a chave de acesso secreta e o token de sessão. | ### 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 foi concedido 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-session-name sessname`) e configurar as credenciais. Você pode usar o arquivo `~/.aws/config` para [**indicar quais papéis assumir**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), 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:::role/ role_session_name = source_profile = sts_regional_endpoints = regional ``` Com este arquivo de configuração, você pode então usar aws cli como: ``` 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**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en). #### Automatizando credenciais temporárias Se você está explorando uma aplicação que gera credenciais temporárias, pode ser tedioso atualizá-las no seu terminal a cada poucos minutos quando elas expiram. Isso pode ser resolvido usando uma diretiva `credential_process` no arquivo de configuração. Por exemplo, se você tiver algum webapp vulnerável, você poderia fazer: ```toml [victim] credential_process = curl -d 'PAYLOAD' https://some-site.com ``` Observe que as credenciais _devem_ ser retornadas para STDOUT no seguinte formato: ```json { "Version": 1, "AccessKeyId": "an AWS access key", "SecretAccessKey": "your AWS secret access key", "SessionToken": "the AWS session token for temporary credentials", "Expiration": "ISO8601 timestamp when the credentials expire" } ``` ## Referências - [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) - [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/) - [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) - [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/) {{#include ../../../banners/hacktricks-training.md}}