mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 19:11:41 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -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 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.
|
||||
|
||||
@@ -33,29 +33,29 @@ aws organizations create-account --account-name testingaccount --email testingac
|
||||
```
|
||||
### **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.
|
||||
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
|
||||
```
|
||||
### Service Control Policy (SCP)
|
||||
|
||||
Uma **política de controle de serviço (SCP)** é uma política que especifica os serviços e ações que usuários e funções podem usar nas contas que a SCP afeta. SCPs são **semelhantes às políticas de permissões do IAM**, exceto que **não concedem permissões**. Em vez disso, as SCPs especificam as **permissões máximas** para uma organização, unidade organizacional (OU) ou conta. Quando você anexa uma SCP à raiz da sua organização ou a uma OU, a **SCP limita as permissões para entidades em contas membros**.
|
||||
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).
|
||||
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.
|
||||
> Note que **as SCPs apenas restringem os principais na conta**, então 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 que GuardDuty, CloudTrail e S3 Public Block Access sejam
|
||||
- Negar o acesso ao GuardDuty, CloudTrail e S3 Public Block de
|
||||
|
||||
desativados
|
||||
ser desativado
|
||||
|
||||
- Negar que funções de segurança/resposta a incidentes sejam excluídas ou
|
||||
|
||||
@@ -96,7 +96,7 @@ Quando você cria uma conta da Amazon Web Services (AWS) pela primeira vez, voc
|
||||
|
||||
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.
|
||||
Do ponto de vista da 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) <a href="#id_iam-users" id="id_iam-users"></a>
|
||||
|
||||
@@ -104,11 +104,11 @@ Um _usuário_ IAM é uma entidade que você cria na AWS para **representar a pes
|
||||
|
||||
Quando você cria um usuário IAM, você concede **permissões** tornando-o um **membro de um grupo de usuários** que tem políticas de permissão apropriadas anexadas (recomendado), ou **anexando políticas diretamente** ao usuário.
|
||||
|
||||
Os usuários podem ter **MFA habilitado para login** através do console. Tokens de API de usuários com MFA habilitado não são protegidos por MFA. Se você quiser **restringir o acesso das chaves de API de um usuário usando MFA**, você precisa indicar na política que, para realizar certas ações, a MFA precisa estar presente (exemplo [**aqui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
|
||||
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**: 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:\
|
||||
@@ -117,7 +117,7 @@ Sempre que você precisar **mudar a Chave de Acesso**, este é o processo que vo
|
||||
### 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.
|
||||
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:
|
||||
|
||||
@@ -125,7 +125,7 @@ Políticas com condições de MFA podem ser anexadas aos seguintes:
|
||||
- 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 a MFA**, você precisa chamar **`GetSessionToken`**. Isso lhe dará um token com informações sobre a MFA.\
|
||||
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 <arn_device> --token-code <code>
|
||||
@@ -147,7 +147,7 @@ Aqui estão algumas características importantes dos grupos de usuários:
|
||||
|
||||
### [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 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**](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 diferentes permissões 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**.
|
||||
|
||||
@@ -155,9 +155,9 @@ Uma função IAM consiste em **dois tipos de políticas**: uma **política de co
|
||||
|
||||
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) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
### [Credenciais temporárias em 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 **previne** 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
|
||||
|
||||
@@ -169,7 +169,7 @@ São usadas para atribuir permissões. Existem 2 tipos:
|
||||
- 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
|
||||
@@ -197,8 +197,8 @@ 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ê 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 Console de Gerenciamento da AWS 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.
|
||||
Esse tipo de políticas é **atribuído diretamente** a um usuário, grupo ou função. Assim, elas não aparecem na lista de Políticas, pois qualquer outra pode usá-las.\
|
||||
As políticas inline são úteis se você deseja **manter uma relação estrita um-para-um entre uma política e a identidade** à qual ela é aplicada. Por exemplo, você quer ter certeza de que as permissões em uma política não são atribuídas inadvertidamente a uma identidade diferente daquela para a qual foram destinadas. Quando você usa uma política inline, as permissões na política não podem ser anexadas inadvertidamente à identidade errada. Além disso, quando você usa o AWS Management Console para excluir essa identidade, as políticas incorporadas na identidade também são excluídas. Isso ocorre porque elas fazem parte da entidade principal.
|
||||
|
||||
#### Políticas de Bucket de Recursos
|
||||
|
||||
@@ -206,17 +206,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 eles, e uma política de recurso conceder acesso, então eles são permitidos.
|
||||
|
||||
### Limites do IAM
|
||||
### Limites 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.
|
||||
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**. 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 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).
|
||||
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.
|
||||
```bash
|
||||
@@ -226,14 +226,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 outros motivos. 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 o seu próprio **Microsoft Active Directory** corporativo (via **SAML**) ou serviços de **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.
|
||||
|
||||
@@ -243,7 +243,7 @@ No entanto, você geralmente desejará dar uma **função diferente dependendo d
|
||||
|
||||
### 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 a **administração de usuários e seu acesso a contas** da AWS e aplicativos em nuvem.
|
||||
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`.
|
||||
|
||||
@@ -263,20 +263,20 @@ 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
|
||||
### Confiança 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.\
|
||||
É 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.
|
||||
**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.\
|
||||
É recomendável **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
|
||||
- AD Admin Center
|
||||
- Suporte total à API PS
|
||||
- Lixeira do AD
|
||||
- Contas de Serviço Gerenciadas por Grupo
|
||||
- Extensões de Esquema
|
||||
@@ -289,7 +289,7 @@ O aplicativo usa o AssumeRoleWithWebIdentity para criar credenciais temporárias
|
||||
### 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**.
|
||||
- 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 frequência de até 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**.
|
||||
|
||||
@@ -353,7 +353,7 @@ 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:
|
||||
Com este arquivo de configuração, você pode então usar aws cli como:
|
||||
```
|
||||
aws --profile acc2 ...
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user