AdministraçãoSecurity posture

Verificar eventos armazenados de Security posture em relação aos resultados atuais

Copy page



Uma vez por dia, compare as atividades de atestação que seu SIEM armazenou com os resultados atuais do endpoint e decida quais divergências precisam da atenção de uma pessoa.

O Activity Feed pode entregar uma atividade com atraso, e o endpoint não mantém histórico, então cada fonte pode mostrar uma alteração que a outra não mostra. Uma comparação diária encontra o que falta no armazenamento do seu sistema de gerenciamento de informações e eventos de segurança (SIEM). O feed não registra todas as alterações, então uma atestação pode ser mais antiga que a primeira atividade do feed para o seu controle de segurança e, em casos raros, uma alteração não tem nenhuma atividade. Se você relata apenas os resultados atuais, não precisa da verificação.

Você precisa de uma Compliance Access Key que abranja a organização, com read:compliance_org_data para o endpoint e read:compliance_activities para o Activity Feed, ou read:org_audit para ambos.

Executar a verificação

Inicie cada execução depois que a releitura diária do dia for concluída, para que as atividades atrasadas estejam armazenadas.

1. Liste as organizações vinculadas com Listar organizações. Você obtém o uuid de cada uma.
2. Chame o endpoint uma vez para cada organização. Você recebe um 200, ou um 404 em toda execução para uma organização que o endpoint não atende (veja Disponibilidade do Security posture). Um 404 significa que a organização não é lida nesta execução. Mantenha uma lista das organizações que retornam um 200, cada uma com o evaluated_at do seu primeiro 200: sua primeira execução para a organização.
3. Separe o que as regras de separação listam.
4. Agrupe as atividades de atestação armazenadas restantes da organização por controle de segurança e pegue a mais recente por created_at de cada um. Você obtém uma atividade para cada controle, ou nenhuma.
5. Para cada controle que resta, encontre sua linha na tabela de decisão. Você obtém Igual, Esperado ou A investigar.
6. Aja sobre uma linha A investigar somente quando a próxima execução que lê a organização a mostrar novamente; aja sobre a linha 6 imediatamente e, para as linhas 10 e 11, siga em vez disso as regras do registro substituto. Uma execução que não leu a organização não conta nem reinicia a espera.

Espace suas chamadas e trate um 429 conforme descrito em 429 Too Many Requests; uma organização cujas chamadas falham após suas novas tentativas não é lida nesta execução, e uma chamada com falha não é uma alteração.

Corresponder os campos

Faça corresponder uma entrada da resposta a uma atividade armazenada com estes campos.

Separar o que não pode ser comparado

Antes de comparar, separe estes itens.

Decidir o que cada divergência significa

Cada controle que resta se encaixa em exatamente uma linha.

Manter um registro substituto onde as duas fontes não podem ser correspondidas

Um registro substituto representa o que falta em uma das duas fontes, e você o mantém separado das suas atividades armazenadas. Para as linhas 10 e 11, leia o feed novamente e armazene e sinalize o registro substituto somente se nada chegar dentro de 15 dias, o alcance da releitura diária. Na sua primeira execução, armazene-o imediatamente, sem revisão.

Registros substitutos da linha 10, identificados pelo controle e por attested_at:

1. Leia novamente a partir da sua atividade armazenada mais recente para o controle, ou a partir de attested_at, inclusive, se você não armazenou nenhuma; os 15 dias contam a partir de attested_at. Construa o registro substituto a partir da entrada, marcado como sem atividade; na tabela de decisão, leia-o como uma atividade attested naquele attested_at cujo valor corresponde ao seu status, se houver.
2. Em cada execução que exibe a atestação, atualize seu status e state.
3. Quando chegar uma atividade cujo created_at seja igual àquele attested_at, substitua o registro substituto por ela.
4. Quando duas execuções seguidas não exibirem a atestação, resolva o registro substituto; sinalize isso para revisão, a menos que uma atividade armazenada mais recente ou uma divergência não resolvida da linha 10 para o controle explique isso, ou que ambas as execuções mostrem descriptive.
5. Uma execução que não leu a organização, ou que mostra not_evaluated, não conta para essas duas execuções nem as reinicia.
6. Se a atestação aparecer novamente, reabra o mesmo registro substituto.

Registros substitutos das linhas 9, 11 e 15, identificados apenas pelo controle:

7. Para a linha 11, os 15 dias contam a partir da primeira execução que exibe o status. Enquanto o registro substituto não estiver resolvido, não sinalize mais nada para esse controle; resolva-o quando chegar uma atividade mais recente, quando a atestação aparecer ou quando duas execuções seguidas se encaixarem em outra linha.
8. Quando um registro substituto da linha 9 for resolvido porque a atestação aparece como failed_check_accepted_risk, sinalize-o para revisão uma vez: o risco está em vigor.

Exemplo prático

Estas duas execuções leem a organização do exemplo de resposta na Referência de resultados; a execução 1 é a sua primeira execução.

• Execução 1, directory_sync_enabled. Armazenada: attested, accepted_risk, criada em 2026-10-20T15:04:00.220114Z. Resposta: failed_check_accepted_risk, in_force, o mesmo attested_at. Linha 1: Igual.
• Execução 1, allowed_invite_domains. Armazenada: nada. Resposta: descriptive, attestation null. Regra S4: separada.
• Execução 1, oauth_conditional_access. Armazenada: nada. Resposta: uma attestation com state review_due. Linha 10: A investigar. Na sua primeira execução, armazene um registro substituto imediatamente, sem revisão.
• Execução 2, oauth_conditional_access. Registro substituto: o da execução 1. Resposta: a mesma. Linha 5: Esperado. Aja uma vez sobre review_due.

O que a verificação não consegue encontrar

A verificação diária não consegue encontrar uma atividade ausente para uma atestação que a resposta omite em um controle automático. A resposta não dá nenhum sinal de tal atestação, ou apenas o status failed, que parece o status que a verificação automática atribui.

Quando uma organização para de responder

Uma organização que retornou um 200 e depois retorna um 404 em várias execuções seguidas precisa da atenção de uma pessoa, uma vez. Pergunte a alguém com acesso à página Security posture se a página foi desativada para a organização (consulte Disponibilidade do Security posture). Se a página não foi desativada, entre em contato com seu representante da Anthropic. A organização pode ter sido excluída, ou seu acesso, o Security posture ou o endpoint pode ter deixado de existir para a organização. Qualquer que seja a causa, resolva os registros substitutos e divergências não resolvidas da organização sem revisão, continue chamando a organização e reabra-os se a organização retornar um 200.