Integrações – Como adicionar uma integração com a AWS

A integração com a AWS é a que rende mais evidência automática na plataforma. Ela cobre uma parte substancial dos controles técnicos de qualquer norma de segurança, porque quase tudo que uma norma pede sobre infraestrutura está configurado ali.

O que ela monitora

A conexão sincroniza automaticamente políticas de acesso, configurações de armazenamento e registro de auditoria, e vai bastante além disso: identidade e permissões, rede, criptografia e gestão de chaves, banco de dados, detecção de ameaças e postura de segurança.

É a integração de maior alcance do catálogo, e é por isso que a permissão sugerida usa políticas gerenciadas em vez de uma lista manual de permissões.

O que criar do lado da AWS

Crie um usuário de acesso programático dedicado para a plataforma, e não use a chave de um administrador pessoal.

A permissão sugerida combina três coisas:

Sobre a terceira: essa é a única ação da integração que a AWS não classifica como leitura, porque ela dispara a geração de um relatório. Ela não altera nenhuma configuração do seu ambiente.

Por que não usar a permissão de leitura total

A AWS oferece uma política de leitura ampla que também funcionaria, e a recomendação é não usá-la.

O motivo é bom: aquela política concede leitura de dados, incluindo conteúdo de arquivos armazenados e registros de banco. A plataforma nunca usa isso, então conceder seria expor mais do que o necessário.

Há uma ironia útil aqui: a própria plataforma tem uma verificação que sinaliza como achado a concessão de leitura ampla de dados a terceiros. Ou seja, usar a permissão errada pioraria o seu resultado em uma das verificações.

Os campos a preencher

A região merece atenção: ela define onde as verificações regionais rodam. Se o seu ambiente é distribuído em várias regiões, a cobertura será apenas da região informada. Informe a região onde está a produção.

Uma limitação que vale conhecer antes

A integração aceita apenas chave estática de usuário. Ela não suporta o modelo de assumir função entre contas com identificador externo.

Se a política interna da sua empresa proíbe chaves de longa duração, esse é um impedimento real hoje, e vale tratar antes de planejar o projeto. A alternativa nesse caso é comprovar os controles de infraestrutura por evidência manual periódica.

Boas práticas com a credencial

Nomeie o usuário de forma reconhecível, do tipo *imara-compliance-readonly*. Isso torna óbvio no seu registro de auditoria de quem é aquele acesso.

Rotacione a chave periodicamente. Ao trocar, atualize na plataforma e teste a conexão. Lembre que o campo pode ficar em branco para manter o valor existente, então troque apenas o que mudou.

Revogar é simples. Desativar a chave do lado da AWS interrompe a coleta imediatamente, sem afetar mais nada.

Depois de conectar

Use Testar Conexão antes de salvar. Em seguida, aguarde o primeiro ciclo de sincronização e confira os testes.

Se muitas verificações aparecerem como não executadas, a causa mais provável é permissão: alguma das políticas não foi anexada, ou a política em linha do relatório de credenciais ficou de fora. Lembre que falta de permissão nunca vira reprovação, apenas perda de cobertura.

Problemas comuns

Teste de conexão falhou. Chave incorreta, desativada ou com as políticas ainda não propagadas. Aguarde um instante após anexar as políticas e tente de novo.

Verificações de credenciais não executam. Falta a política em linha que permite gerar o relatório de credenciais.

Verificações de serviços específicos não executam. Provavelmente falta a segunda política gerenciada, que cobre os serviços fora do alcance da primeira.

Recursos de outra região não aparecem. A cobertura é da região configurada. Para ambiente multi-região, priorize a região de produção.

A empresa não permite chave de longa duração. Hoje não há caminho alternativo nesta integração. Comprove esses controles por evidência manual.