Acesso seguro

Como entramos na tua conta

Dar acesso a um terceiro pede confiança. Lemos custos, o que está aberto e o gasto de IA. Só escrevemos se deres o papel dos agentes.

Cloud, segurança e IA. Ao ligar lemos; a escrita é um segundo papel, o dos agentes.

Exemplo ilustrativo

Cloud

Serviços de IA

Por predefinição

Lemos custos, inventário, gasto de IA e se algo ficou aberto. Nada se escreve.

Se concederes o papel

Os agentes aplicam o que aprovas: custos, exposição e gasto de IA.

Leitura por predefinição

Leitura por predefinição

O papel da AWS, Azure ou GCP, e as chaves dos serviços de IA, entram só em leitura. A escrita vive num segundo papel, o dos agentes: tu crias-o, tu aprovas cada ação. Sem esse papel não desligamos nem apagamos nada.

  • AWS: papel do CloudFormation com ViewOnlyAccess e SecurityAudit (lemos metadados e configuração, não dados das suas bases de dados nem valores do Secrets Manager ou do Parameter Store; não guardamos os valores das variáveis de ambiente das funções) e Cost Explorer; além disso, só a leitura da sua exportação FOCUS e a busca de traces nos logs se ativar os fluxos
  • Azure: Service Principal com Reader e Cost Management Reader (sem Contributor nem Owner)
  • GCP: Service Account com papéis de leitura (Viewer) e leitura do faturamento no BigQuery, sem Editor
  • O agente autónomo (plano Business) requer uma segunda função que concede voluntariamente
  • Se revogar a função, o AAA Sentinel perde o acesso imediatamente

Por predefinição

  • Custos e inventário
  • O que está aberto ou mal configurado
  • Gasto e uso de IA

Com o agente

  • Fechar exposição que aprovas
  • Ligar e desligar segundo o horário
  • Agir na cloud, segurança e IA
Criptografia KMS

Criptografia KMS de credenciais

As chaves da Azure, da GCP e dos serviços de IA ficam em um bucket privado do S3, criptografadas com AWS KMS e a nossa própria chave. Da AWS não guardamos chaves: só o ARN do papel.

  • Customer Master Key (CMK) rodada automaticamente todos os anos pela AWS
  • Criptografia do lado do servidor do S3 com KMS (SSE-KMS)
  • Criptografia simétrica AES-256
  • A chave mestra nunca sai dos HSM do AWS KMS
  • As funções que usam as credenciais recebem a permissão de descriptografar por IAM; o bucket bloqueia o acesso público
  1. Gera uma credencial cloud

    Client Secret da Azure, chave de Service Account da GCP ou chave de API de IA

  2. Fechamos o envelope

    O KMS cifra a credencial. A chave mestra não sai da AWS.

  3. Guardada criptografada no S3

    Bucket privado, versionado e só por HTTPS. A chave mestra nunca sai do KMS.

ExternalId

Um código único por organização

O ataque confused deputy permite que um terceiro malicioso assuma um papel IAM da sua conta se passando por um serviço legítimo. Para evitá-lo, sua organização tem um código aleatório de 128 bits que o seu papel da AWS exige como ExternalId.

  • Aleatório, de 128 bits: não deriva de nenhum dado da sua organização
  • Gerado uma vez e igual para todas as contas AWS da sua organização
  • Sem o ExternalId correto, a AWS rejeita qualquer AssumeRole
  • Previne ataques confused deputy mesmo que o ARN da função seja divulgado
  • Você o vê no assistente de conexão porque ele vai na política de confiança do seu papel

Com o teu código único

A AAA Sentinel pede acesso com o código da sua organização. O seu papel o reconhece e deixa entrar para ler.

Sem o teu código

Outra conta, mesmo que soubesse o nome do papel, não tem o teu código. A cloud recusa o acesso.

Sem este ExternalId exato, qualquer tentativa de AssumeRole é rejeitada pela AWS.

JWT + Cognito

JWT + Cognito

Autenticação com Amazon Cognito (User Pools + Hosted UI) para as pessoas e OAuth2 Client Credentials com JWT HS256 de 1 hora para a API. Os tokens de API levam a sua organização e os seus scopes.

  • Tokens de 1 hora com renovação automática
  • A organização e o papel são resolvidos no servidor a partir do seu usuário, não da requisição
  • A sessão viaja em um cookie httpOnly e é verificada por um autorizador Lambda do API Gateway
  • Os tokens de API (Client Credentials) são assinados com HS256 e um segredo guardado no Parameter Store (SecureString)
  • Rate limiting separado para tokens de API
  • Se a sua organização exige MFA, a API verifica-o em cada requisição, inclusive para o owner; quem entra com o Google ou com o SSO da empresa resolve-o no seu provedor de identidade
  • Restrição dos domínios de email permitidos para início de sessão e convites
  1. 01

    Inicias sessão

    Registo, acesso e recuperação passam pelo Cognito.

  2. 02

    Confirmamos quem és

    MFA e domínio de e-mail, se a tua organização os exigir.

  3. 03

    Recebes um token de sessão

    Assinado, de curta duração, com a tua organização lá dentro.

  4. 04

    Cada pedido leva essa organização

    A API nunca tira o tenant do corpo do pedido.

Isolamento tenant

Isolamento de tenant

Os dados de cada organização são guardados sob o seu identificador de organização. Esse identificador vem da sua sessão verificada, nunca do que a requisição envia.

  • DynamoDB: as tabelas são particionadas por organização; as de análises e achados, por conta, e a conta é verificada antes contra a sua organização
  • A organização vem do usuário autenticado, não do corpo da requisição
  • Sem uma sessão ou um token assinados e verificados, nenhuma organização é resolvida
  • Cada conta é buscada com a chave da sua organização; se algo não bater, o acesso é negado e registrado como incidente de segurança

A tua organização

Consulta achados e custos das tuas contas.

Vê só o que é seu

Outra organização

Tenta ler os mesmos dados.

Bloqueado: tenant diferente

Cada organização só vê as suas próprias linhas. A organização vem da sessão, nunca da requisição.

Registo de auditoria

Registro de auditoria

Cada ação relevante (análises, alterações de configuração, acessos e ações do agente) fica em uma tabela própria do DynamoDB, criptografada com KMS e guardada durante um ano. A aplicação apenas acrescenta entradas: nenhuma escrita sobrescreve outra.

  • DynamoDB criptografado com KMS e com recuperação para um ponto no tempo (PITR)
  • Retenção de 1 ano; depois cada entrada expira sozinha
  • Campos: data, organização, autor (pessoa, token, agente ou sistema), ação, recurso e resultado
  • As ações do agente ficam registradas com a sua proposta, aprovação e execução
  • Você consulta a sua atividade e a exporta em CSV a partir do seu perfil

Exemplo de registo de auditoria

Exemplo ilustrativo

  1. Hoje, 09:12

    Análise de postura de produção

    Agendado · só leitura

  2. Hoje, 11:40

    A Ana aprovou desligar staging-web-03

    Agente · com permissão de escrita

  3. Hoje, 16:05

    Alerta de exposição enviado para o canal

    Notificação · sem alteração na cloud

Segredos

Segredos

Os segredos da plataforma (assinatura de tokens de API, pagamentos, verificação anti-robôs) estão no AWS Systems Manager Parameter Store como SecureString e são lidos em tempo de execução. As chaves do Jira e do Linear que você configura ficam no DynamoDB, criptografado com a nossa chave do KMS, e a interface só as mostra mascaradas.

  • Rotação da chave mestra

    A AWS rotaciona a chave do KMS todo ano

  • Criptografia em repouso

    Parameter Store SecureString e tabelas criptografadas com KMS

  • Sem variáveis de env

    Carregadas em runtime via SDK

Liga a tua conta com as regras à vista

Leitura ao ligar. Escrita só se deres o papel dos agentes. Para ver o que está aberto nas tuas contas, está em Segurança.

Começar grátis agora

Sem cartão · Leitura ao ligar · Escrita se a concederes