Anotações sobre o AWS IAM para ajudar na preparação das certificações AWS.
Até o momento as anotações são para as certificações abaixo:
Anotações gerais
- Controle de acesso para recursos
- Serviço Global
- Analise de acesso
- Por padrão um usuário não tem permissões - tudo negado por padrão
Service Roles
Uma Service Role é uma Role que um serviço da AWS assume para executar ações em seu nome.
Referências
PassRole
PassRole é uma permissão concedida a usuários e recursos do IAM que permite que eles usem uma Roles do IAM.
- Não é possível utilizar a permissão
PassRolepara passar uma função entre contas.
Exemplo da PassRole
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::<account-id>:role/EC2-WordpressRole",
"arn:aws:iam::<account-id>:role/EC2-DatabaseRole"
]
}]
}
Referências
- Granting a user permissions to pass a role to an AWS service
- Understanding IAM PassRole
- Introdução a AWS AssumeRole, PassRole e Service-Linked Roles
Permission Boundary
A AWS oferece suporte a Permission Boundary para entidades (_Users ou Roles) do IAM. Um Permission Boundary é um recurso avançado para usar uma política gerenciada para definir as permissões máximas que uma política baseada em identidade pode conceder a uma entidade do IAM. O limite de Permission Boundary permite que a entidade execute somente as ações permitidas por ambas as políticas baseadas em identidade e seus limites de permissões._
- Permission Boundary sozinho não dá acesso a permissão, é necessário que ambas as permissões (Policies e Boundary) estejam configuradas
- Só pode ser configurado uma Police por vez, caso seja necessário mais, tem que criar uma Police customizada
MFA
- Virtual MFA Devices (Google Autenticator or Authy)
- Universal 2nd Factor (U2F) Security Key - Phisical Device
- Hardware Key Fob MFA Device
- Hardware Key Fob MFA Device for AWS GovCloud (US)
Exemplo Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:user/anika" },
"Action": "sts:AssumeRole",
**"Condition": { "Bool": { "aws:multifactorAuthPresent": true** } }
}
]
}
IAM Users
- Users
- Podemos ter um usuário em mais de um grupo
IAM Roles
Uma Role do IAM é uma identidade do IAM que você pode criar em sua conta com permissões específicas. Uma Role do IAM é semelhante a um usuário do IAM, pois é uma identidade da AWS com Policies de permissão que determinam o que a identidade pode e não pode fazer na AWS.
- Identidades que podem assumir
- Assumidas temporária
- Permissões associadas
- Não podem ser utilizadas por usuários, somente por AWS Services
- IAM Users, App e AWS Services podem assumir IAM Roles
- Use IAM Policy para permissões
Tipos de AssumeRole
AssumeRole
– Retorna um conjunto de credenciais de segurança temporárias que você pode usar para acessar recursos da AWS aos quais você normalmente não tem acesso.
- As credenciais temporárias consistem em Access Key, Secret Access, and Security Token.
- Normalmente, você usa AssumeRole em sua conta ou para acesso entre contas.
- Pode incluir informações de autenticação multifator (MFA) ao chamar AssumeRole .
- Isso é útil para cenários entre contas para garantir que o usuário que assume a função tenha sido autenticado com um dispositivo AWS MFA.
AssumeRoleWithSAML
- Retorna um conjunto de credenciais de segurança temporárias para usuários que foram autenticados por meio de uma resposta de autenticação SAML.
- Isso permite que você vincule seu armazenamento ou diretório de identidade corporativa ao acesso baseado em função da AWS sem credenciais ou configurações específicas do usuário.
AssumeRoleWithWebIdentity
- Retorna um conjunto de credenciais de segurança temporárias para usuários que foram autenticados em um aplicativo móvel ou da Web com um provedor de identidade da Web.
- Provedores de exemplo incluem Amazon Cognito, Login with Amazon, Facebook, Google ou qualquer provedor de identidade compatível com OpenID Connect.
IAM Groups
- Agrupamentos de usuários com permissões em comum
- Grupos só tem usuários e não pode ter outros Grupos
IAM Authorization
IAM Authentication
AWS Policy Evaluation Logic
- Deny explicito sobrepõe Allow
Resource-based policies
- A Resource-based policies permite anexar uma política diretamente ao recurso que você deseja compartilhar, em vez de usar uma função como proxy.
- A Resource-based policies especifica que o
Principal, na forma de uma lista de números de ID de conta da AWS, pode acessar esse recurso e o que eles podem acessar. - Usando o acesso entre contas com uma política baseada em recursos, o usuário ainda trabalha na conta confiável e não precisa abrir mão de suas permissões de usuário no lugar das permissões de função.
- Os usuários podem trabalhar nos recursos de ambas as contas ao mesmo tempo e isso pode ser útil para cenários como, por exemplo, copiar objetos de um bucket para outro
- As Resource-based policies precisam da conta confiável para criar usuários com permissões para poder acessar os recursos da conta confiável.
- Somente permissões equivalentes ou inferiores às permissões concedidas à sua conta pela conta proprietária do recurso podem ser delegadas
Os recursos que você deseja compartilhar são limitados a recursos que dão suporte a Resource-based policies
- O S3 permite definir a política do bucket para conceder acesso ao bucket e aos objetos
- Simple Notification Service (SNS)
- Simple Queue Service (SQS)
- Glacier Vaults
- OpsWorks stacks
- Lambda functions
Referências
- Jayendra Blog - AWS IAM Roles vs Resource Based Policies
- How IAM roles differ from resource-based policies
External ID
Por que usar um External ID?
O External ID permite que o usuário que está assumindo uma Role assegure as circunstâncias nas quais elas operam.
Também oferece uma forma para o proprietário da conta permitir que a Role seja assumida apenas em determinadas circunstâncias.
Às vezes, é necessário oferecer acesso a terceiros para os recursos da AWS (delegar acesso).
Um aspecto importante desse cenário é o External ID, informação opcional que você usa em uma trusted policy da Role do IAM para designar quem pode assumir a Role.
- Informar o --external-id "xxxx" via CLI ou API
- Quando criar uma Role do tipo "Another AWS Account" é opcional o ExternalId, porém é altamente recomendado e é uma boa pratica. Caso selecionado, deve-se informar o External ID.
Exemplo Policy
"Principal": {"AWS": "AWS Account ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "XXXX"}}
Referências
Top comments (0)