Fidelidade de cobertura e atribuição

Uma ferramenta de segurança que exagera o que sabe e pior do que nenhuma ferramenta: entrega-lhe uma falsa sensação de segurança. Por isso, cada aresta no mapa de acesso transporta dois rotulos de fidelidade independentes, e o produto apresenta-os honestamente — nunca disfarcia uma aresta mal conhecida como se fosse provada.

Os dois eixos respondem a duas perguntas diferentes:

• Cobertura — quao bem a fonte consegue provar se este acesso foi uma leitura ou uma escrita.
• Atribuição — quao firmemente o acesso se liga a um único agente, versus uma identidade partilhada.

Movem-se de forma independente. Um armazém de dados com auditoria nativa oferece cobertura limpa; se cada agente partilha uma conta de serviço contra ele, a atribuição e ainda apenas aproximada. Nenhum eixo e inferido do outro.

Cobertura: leitura vs escrita

A cobertura descreve o que o armazém subjacente pode dizer-nos sobre a natureza leitura/escrita de um acesso. E uma propriedade da fonte, não do agente.

• clean — o armazém emite auditoria nativa e autoritativa, portanto leitura vs escrita e classificada verbatim. Isto inclui Postgres via pgAudit, armazenamento de objetos via CloudTrail (s3.readOnly), e os armazéns de dados e data lakes (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), além da verdade fundamental ao nível do kernel via eBPF.
• lossy — o armazém produz arestas, mas grosseiras. Armazéns de documentos (por exemplo MongoDB) enquadram-se aqui: existe uma aresta, mas a divisao leitura/escrita e aproximada.
• opaque — o armazém não oferece nenhum sinal passivo de leitura/escrita. Redis, SQLite e D1 não podem ser reconstruídos por observação, portanto o mode da aresta e marcado como unknown em vez de adivinhado.

Existe também um nível mixed para sinais cooperativos ou ao nível de ferramentas — ferramentas MCP, APIs HTTP, tarefas de agentes — que não estão ligados a uma classe de armazém.

A regra cardinal: onde um armazém e opaque, a classificação leitura/escrita e unknown, nunca inventada. E uma aresta ausente numa fonte lossy ou opaque não e prova de que um acesso não aconteceu — apenas de que a fonte não conseguiu provar que aconteceu. Essa e a diferença entre permitido e observado.

Atribuição: qual agente

A atribuição descreve quao firmemente um acesso observado se liga a um agente concreto. Os registos de auditoria atribuem atividade a uma credencial ou a um papel, não inerentemente a um agente — portanto este eixo e mais estrito do que a mera confiança no sinal, e e deny-closed: sem um sinal firme por agente, permanece baixo.

• firm — o acesso resolve-se inequivocamente para um agente. Isto requer um sinal real de identidade por agente: um SVID de carga de trabalho SPIFFE, uma conta de serviço federada por identidade de carga de trabalho, uma identidade não humana dedicada cunhada pela governança, ou uma credencial vinculada a exatamente um agente.
• approximate — uma identidade e conhecida, mas não se pode apontar para um único agente. Uma conta de serviço partilhada ou agrupada atrás de um pool de conexões, uma credencial ambigua, ou um vinculo por agente ainda pendente caem aqui.
• unknown — nenhuma atribuição por identidade e possível. Este e o piso para um armazém opaque visto por um backstop não cooperativo, ou um acesso que não se liga a nenhuma identidade. Nunca um agente fabricado.

Como a atribuição e deny-closed, um sinal posterior mais fraco nunca pode rebaixar uma aresta firmemente atribuída — mas um sinal forte pode elevar uma fraca. Os dois eixos também interagem em exatamente uma direcao: num armazém opaque, qualquer atribuição abaixo de firm e nivelada para unknown, em vez de ser apresentada como um palpite de conta partilhada disfaricado de approximate.

A identidade por agente e portanto uma dependência rígida para o mapa de alta fidelidade. Governar bem significa emitir identidade por agente — veja Identidade e o modelo de governança.

Porque isto importa

O objetivo de rotular ambos os eixos e contencao. O produto não destacara uma aresta lossy/approximate como uma violação da mesma forma que faria com uma clean/firm, e mostra unknown e approximate abertamente em vez de esconde-los. Um achado de desvio que o sistema ainda não consegue atribuir firmemente e marcado como pendente de reconciliação, não apresentado como uma violação confirmada.

E por isso que o mapa de acesso pode ser confiado como evidência e não como um palpite: cada aresta diz, em duas dimensoes, exatamente quanto sabe. Onde sabe pouco, di-lo.

Onde estes rotulos aparecem

Ambos os rotulos acompanham cada aresta na API do grafo e na sobreposição da interface, juntamente com a fonte de sinal que produziu a aresta. Ler o grafo de acesso e uma ação privilegiada, com escopo de inquilino e totalmente auditada.

As formas exatas ao nível de campo para o grafo do mapa de acesso e o desvio residem nas interfaces tipadas do produto e estão deliberadamente fora do contrato OpenAPI servido — veja os módulos de referência e a página de honestidade e limites para o limite completo do que é provado versus inferido.

Relacionado

• O mapa de acesso — o que é uma aresta e como é construída.
• Permitido vs observado — o desvio de menor privilégio que estes rotulos qualificam.
• Honestidade e limites — o contrato completo sobre o que funciona, o que é fase de design e o que o produto deliberadamente não faz.