Saltar para o conteúdo

Produto · Mapa de acessos

Veja o que cada agente consegue alcançar — leitura face a escrita

Para cada agente, sessão e identidade, o mapa de acessos mostra os recursos que toca, separa leituras de escritas e assinala o momento em que o acesso observado diverge daquilo que autorizou. Descoberto passivamente a partir de sinais que já possui — sem nenhum proxy no caminho dos dados.

No produto

O mapa, a partir da consola real

Uma captura de ecrã genuína da consola do Olivares, preenchida com dados de exemplo. Origens à esquerda, os recursos que tocam à direita, coloridos por leitura, escrita/RW, desconhecido e aproximado. Abrir o mapa é uma ação privilegiada e auditada — mostra relações, nunca SQL, payloads ou segredos.

Captura de ecrã real
Os agentes e as sessões à esquerda alcançam bases de dados, object stores, APIs e integrações à direita. A cor da ligação codifica leitura face a leitura/escrita; uma das ligações está assinalada como escrita inesperada — desvio do princípio de least-privilege.
Captura de ecrã real
Mude para «autorizado vs. observado» e o mapa compara as suas autorizações com o acesso real: o que foi observado mas nunca autorizado, e o que foi autorizado mas nunca utilizado.

O modelo

Leitura, escrita e o desconhecido honesto

O Olivares classifica cada acesso no conector, a partir da própria instrução ou verbo — o tipo de SQL, o método HTTP, a semântica da ferramenta MCP, o modo de abertura do ficheiro. Regista a relação, nunca a instrução: sem texto SQL, sem parâmetros, sem payloads, sem segredos.

Leitura

Um agente que apenas lê um recurso — um SELECT, um GET, uma chamada de ferramenta só de leitura. Desenhado calmo, em tom neutro.

Leitura / Escrita

Um agente que pode modificar um recurso — um INSERT ou UPDATE, uma ferramenta de escrita, uma chamada mutante. As ligações que determinam o seu raio de impacto.

Desconhecido – aproximado

Quando um repositório não oferece auditoria por identidade, ou o sinal é fraco, o Olivares assinala-o — uma ligação tracejada e atenuada — em vez de inventar uma certeza.

Desvio do princípio de least-privilege

Autorizado face a observado — a deteção que importa

O desvio é a diferença entre o acesso que concedeu e o acesso que está realmente a acontecer. O Olivares reconcilia uma observação atribuída a um agente com a identidade que esse agente realmente usa e expõe três estados honestos.

  • Acesso inesperado

    Observado, mas nunca autorizado. A deteção de maior prioridade — acesso que está a acontecer sem nenhuma autorização por trás.

  • Reconciliação pendente

    Observado sem uma autorização correspondente, mas a ligação entre agente e identidade ainda está por resolver. Apresentado como pendente, não como uma violação confirmada — incerteza honesta, não um alarme fabricado.

  • Autorizações não utilizadas

    Autorizado, mas nunca observado. Sobreprovisionamento a apertar — least-privilege, no sentido inverso.

Como funciona

Das autorizações e observações a um único veredicto

O Olivares pega no que autorizou e no que observou, reconcilia-os entre as origens e apresenta o resultado: uma correspondência, um desvio ou uma relação que apenas consegue declarar — nunca uma que finja ter visto.

Diagrama: as autorizações concedidas e o acesso observado são comparados; as correspondências são confirmadas, as divergências assinaladas como desvio a laranja e as relações declaradas mas nunca observadas desenhadas a tracejado.
Autorizado vs. observado, reconciliado entre as origens. Tracejado significa declarado, nunca observado — desenhado honestamente, não escondido.

Cobertura, declarada com honestidade

Dois eixos de fidelidade — e não falseamos nenhum dos dois

O grau de auditabilidade de um recurso e a firmeza com que um acesso se liga a um agente específico são duas coisas diferentes. O Olivares mostra ambos, por nó, e degrada-se graciosamente em vez de adivinhar.

Cobertura do recurso

Quão completamente o próprio recurso pode ser auditado.

Limpo
Auditoria nativa — Postgres pgAudit, AWS CloudTrail e semelhantes. Fidelidade total por acesso.
Com perdas
Repositórios de documentos e de vetores: sinal parcial, apresentado como parcial — sem arredondar para cima.
Opaco
Redis, SQLite, D1 e afins não oferecem auditoria por identidade. Marcados como opacos, nunca silenciosamente promovidos.

Atribuição de origem

Quão firmemente um acesso se liga de volta a um agente específico.

Firme
Uma identidade não humana dedicada — uma credencial SPIFFE/WIF emitida por agente. Desenhada a traço contínuo.
Aproximada
Uma conta partilhada ou em pool: o acesso é real, o agente é ambíguo. Desenhada tracejada, rotulada como aproximada.
Desconhecida
Nenhum sinal de identidade. Atenuada — e nunca promovida a um agente nomeado.

Os dois eixos são independentes: um acesso a um repositório opaco pode ainda assim ser atribuído com firmeza se um sinal cooperante nomear o agente. O que o Olivares não fará é apresentar o aproximado ou o desconhecido como se fosse firme.

O que é real

Construído e verificado — e honesto quanto aos limites

O mapa de acessos passou o seu marco técnico de prova de conceito e é o escritor do grafo. Duas notas honestas:

  • Abrir o mapa é uma ação privilegiada e auditada: cada consulta sela uma entrada no registo apenas de adição. Destina-se a revisão defensiva — relações, não conteúdos.
  • A fidelidade depende das suas fontes. Ligue a auditoria nativa (pgAudit, CloudTrail) e identidades por agente e o mapa fica no seu máximo de nitidez; sem elas, o Olivares mostra o nível de fidelidade inferior em vez de uma ficção confiante.

Mapa de acessos — perguntas

Precisa de um proxy ou de um agente em linha?

Não. O Olivares descobre os acessos passivamente a partir de sinais que já possui — auditoria nativa da base de dados, registos de auditoria da cloud, OpenTelemetry, eBPF e introspeção MCP. Não há nenhum proxy obrigatório no caminho dos dados e nada para andar a vigiar.

O mapa armazena SQL, payloads ou segredos?

Não. Cada acesso é classificado a partir do verbo — o tipo de SQL, o método HTTP, a semântica da ferramenta — e registado como uma relação: origem, recurso, leitura ou escrita. O texto da instrução, os parâmetros, os payloads e os segredos nunca são capturados.

E os repositórios sem auditoria por identidade, como o Redis?

São marcados com cobertura opaca. O Olivares mostra a relação na fidelidade que consegue efetivamente comprovar e rotula o limite, em vez de inventar uma atribuição por identidade que o repositório não consegue suportar.

Como distingue leitura de leitura/escrita?

A partir da própria instrução ou verbo, classificado no conector — um SELECT face a um INSERT ou UPDATE, um GET face a um método mutante, uma chamada de ferramenta só de leitura face a uma de escrita. A cor da ligação segue daí: leitura, escrita/RW ou desconhecido quando o sinal é fraco.

Veja o seu próprio mapa de acessos

Implemente o Olivares na sua própria infraestrutura, aponte-o às suas fontes de auditoria e obtenha o mapa de leitura/escrita que as suas equipas de plataforma e de segurança andam a pedir.