IAM: Políticas de Função IAM com Privilégios de Administrador Completo

Esta regra identifica IAM Roles que possuem privilégios administrativos amplos, caracterizados por:

• Ação *

• Recurso *

• Effect = Allow

• Ausência de Condition

Também detecta:

• Uso da policy gerenciada AdministratorAccess

• Policies customizadas com permissões equivalentes

• Policies inline com permissões administrativas

O objetivo é identificar papéis com alto risco de privilégio excessivo

---

Contexto da regra e impacto no negócio

Roles com privilégio administrativo irrestrito:

• Podem acessar qualquer recurso da conta

• Aumentam risco de escalonamento de privilégio

• Elevam impacto potencial de comprometimento

• Podem violar princípio de menor privilégio (Least Privilege)

Impacto:

• Risco de segurança crítico

• Risco regulatório

• Risco de movimentação lateral

• Exposição total da conta

Classificação: SEGURANÇA + GOVERNANÇA

---

Detalhamento técnico da regra

A regra executa análise global no IAM (não regional).

---

Como a regra é executada

1. Listagem de Roles

API:

iam:ListRoles

Exclui automaticamente:

Roles com Path iniciando em "/aws-service-role/"

(Service-Linked Roles)

---

2. Aplicação de filtros de tag

API adicional para cada role:

iam:ListRoleTags

---

3. Verificação de permissões administrativas

A regra avalia:

a) Policies gerenciadas anexadas

API:

iam:ListAttachedRolePolicies

Se detectar:

arn:aws:iam::aws:policy/AdministratorAccess

Role é sinalizada.

---

b) Policies gerenciadas customizadas

APIs:

iam:GetPolicy
iam:GetPolicyVersion

Avaliação do documento:

Um statement é considerado administrativo quando:

Effect = Allow
AND
Action = "*"
AND
Resource = "*"
AND
Não contém Condition

---

c) Policies inline

APIs:

iam:ListRolePolicies
iam:GetRolePolicy

Mesma lógica de validação do documento.

---

4. Permissions Boundary

Se a role possuir:

PermissionsBoundary

A regra reporta como:

POTENTIAL ADMIN (Boundary Found)

Indicando que permissões podem estar limitadas.

---

Lógica aplicada

Uma role será sinalizada quando existir ao menos uma policy que contenha:

Effect = Allow
AND Action = "*"
AND Resource = "*"
AND Sem Condition

Ou quando estiver anexada à policy:

AdministratorAccess

---

Campos analisados

Role IAM:

• RoleName

• Arn

• CreateDate

• Description

• Tags

• PermissionsBoundary

Policies:

• PolicyArn

• PolicyDocument

• Statement

• Effect

• Action

• Resource

• Condition

---

Parâmetros considerados na busca

APIs utilizadas:

• iam:ListRoles

• iam:ListRoleTags

• iam:ListAttachedRolePolicies

• iam:GetPolicy

• iam:GetPolicyVersion

• iam:ListRolePolicies

• iam:GetRolePolicy

Não há filtro temporal.

---

Período Avaliado (Filtro Temporal)

Não aplicável.

A regra avalia o estado atual das permissões.

---

Intervalo de Análise

Execução padrão: a cada 8 horas.

---

Impacto Financeiro

Esta regra não possui savings direto.

O objetivo é:

• Reduzir risco de comprometimento total da conta

• Garantir aderência ao princípio de menor privilégio

• Melhorar postura de segurança

Impacto financeiro indireto pode ser extremamente alto em caso de incidente.

---

Exemplo de Impacto

Cenário:

Role DevOps-Admin possui:

Action = "*"
Resource = "*"
Effect = Allow

Resultado:

Role sinalizada como privilégio administrativo irrestrito.

---

Outro cenário:

Role possui AdministratorAccess, mas com PermissionsBoundary.

Resultado:

POTENTIAL ADMIN (Boundary Found)

---

Dicas de uso e boas práticas para o usuário

Recomendações:

• Aplicar princípio de menor privilégio.

• Substituir * por ações específicas.

• Usar Conditions sempre que possível.

• Implementar Permission Boundaries.

• Revisar roles administrativas trimestralmente.

Boas práticas:

• Separar roles de automação e humanas.

• Monitorar uso via CloudTrail.

• Exigir MFA para acesso privilegiado.

• Implementar IAM Access Analyzer.

Exceções possíveis:

• Break-glass admin role controlada.

• Contas sandbox.

• Ambientes isolados de teste.