diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index c8c4d6f04..7185940f9 100644 --- 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 criadas especificamente), assim você pode criar limites entre 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 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. @@ -27,13 +27,13 @@ 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 **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). +- As 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 receber acesso a ela). ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` -### **Unidades de Organização** +### **Unidades Organizacionais** -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. +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. ```bash # You can get the root id from aws organizations list-roots aws organizations create-organizational-unit --parent-id r-lalala --name TestOU @@ -46,7 +46,7 @@ Esta é a ÚNICA maneira que **até mesmo o usuário root pode ser impedido** de 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** na 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 negando `s3:GetObject` não impedirá as pessoas de **acessar um bucket S3 público** na sua conta. Exemplos de SCP: @@ -150,26 +150,26 @@ 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) -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**. +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**. 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, 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) -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 é 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 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 da web que facilita a **emissão de credenciais temporárias de privilégio limitado**. É especificamente adaptado para: +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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) @@ -182,7 +182,7 @@ O AWS Security Token Service (STS) é um serviço da web que facilita a **emiss 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 "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). @@ -214,7 +214,7 @@ Os [campos específicos que podem ser usados para condições por serviço estã #### 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 inline são úteis se você deseja **manter uma relação estrita de 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 @@ -249,7 +249,7 @@ Portanto, se em algum momento você enfrentar o erro "... porque nenhuma políti ### 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 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. +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. @@ -279,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 elas têm as mesmas permissões**. +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**. ### 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** (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.\ +**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 @@ -307,27 +307,27 @@ O aplicativo usa o AssumeRoleWithWebIdentity para criar credenciais temporárias - 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**. +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) | +| 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 únicas apenas em combinação com a chave de acesso secreta e o token de sessão. | +| 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 @@ -347,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 a **aws cli**, o chamado **`[default]`** nesse arquivo será usado.\ +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.\ Exemplo de arquivo de credenciais com mais de 1 perfil: ``` [default]