Verificare gli eventi archiviati di Security posture rispetto ai risultati attuali
Una volta al giorno, confronta le attività di attestazione archiviate dal tuo SIEM con i risultati attuali dell’endpoint e decidi quali mancate corrispondenze richiedono l’intervento di una persona.
L’Activity Feed può consegnare un’attività in ritardo e l’endpoint non conserva alcuno storico, quindi ciascuna fonte può mostrare una modifica che l’altra non mostra. Un confronto giornaliero rileva ciò che manca al tuo archivio di “security information and event management” (gestione delle informazioni e degli eventi di sicurezza), o SIEM. Il feed non registra ogni modifica, quindi un’attestazione può essere precedente alla prima attività del feed per il suo controllo di sicurezza e, in rari casi, una modifica non ha alcuna attività. Se riporti solo i risultati attuali, non hai bisogno della verifica.
Ti serve una Compliance Access Key che copra l’organizzazione, con read:compliance_org_data per l’endpoint e read:compliance_activities per l’Activity Feed, oppure read:org_audit per entrambi.
Eseguire la verifica
Avvia ogni esecuzione dopo il completamento della rilettura giornaliera del giorno, in modo che le attività in ritardo risultino archiviate.
- Elenca le organizzazioni collegate con Elencare le organizzazioni. Ottieni l’
uuiddi ciascuna. - Chiama l’endpoint una volta per ogni organizzazione. Ottieni un 200, oppure un 404 a ogni esecuzione per un’organizzazione che l’endpoint non serve (vedi Disponibilità di Security posture). Un 404 significa che l’organizzazione non viene letta in questa esecuzione. Tieni un elenco delle organizzazioni che restituiscono un 200, ciascuna con l’
evaluated_atdel suo primo 200: la tua prima esecuzione per l’organizzazione. - Metti da parte ciò che elencano le regole di esclusione.
- Raggruppa per controllo di sicurezza le attività di attestazione archiviate rimanenti dell’organizzazione e prendi la più recente in base a
created_atper ciascun controllo. Ottieni un’attività per ogni controllo, oppure nessuna. - Per ogni controllo rimasto, trova la sua riga nella tabella decisionale. Ottieni Corrispondente, Atteso o Da approfondire.
- Intervieni su un elemento Da approfondire solo quando l’esecuzione successiva che legge l’organizzazione lo mostra di nuovo; intervieni subito sulla riga 6, e per le righe 10 e 11 segui invece le regole sui segnaposto. Un’esecuzione che non ha letto l’organizzazione non conta né fa ripartire l’attesa.
Distribuisci le tue chiamate nel tempo e gestisci un 429 come descritto in 429 Too Many Requests; un’organizzazione le cui chiamate non riescono dopo i tuoi nuovi tentativi non viene letta in questa esecuzione, e una chiamata non riuscita non è una modifica.
Abbinare i campi
Abbina una voce della risposta a un’attività archiviata con questi campi.
| Nella risposta | Nell’attività | Come si relazionano |
|---|---|---|
organization_id | organization_uuid | Lo stesso valore; l’organization_id proprio dell’attività ha il prefisso org_. |
controls[].id | control | Lo stesso identificatore, salvo quanto previsto dalla regola S2. |
attestation.attested_at | created_at dell’attività attested, changed o renewed più recente | Lo stesso istante dove la risposta mostra l’attestazione; confrontali come orari, non come stringhe. |
status | status | Finché l’attestazione è in vigore, attested_completed si abbina a completed, e attested_accepted_risk e failed_check_accepted_risk a accepted_risk; nulla si abbina a control_failed. |
Mettere da parte ciò che non si può confrontare
Prima di confrontare, metti da parte quanto segue.
| # | Cosa | Regola |
|---|---|---|
| S1 | Un’attività di attestazione archiviata il cui action non è attested, changed, renewed, cleared o lapsed | Escludila dall’intera verifica; segnala per la revisione ogni nuovo valore di action, una volta. |
| S2 | Un’attività di attestazione archiviata che nomina mdm_cowork_required_organization | Contala come attività per mdm_chat_required_organization. |
| S3 | Un’attività di attestazione archiviata il cui controllo non ha una voce nella risposta | Niente da confrontare; riporta il controllo come non presente nella risposta, mai come Superato (passed). |
| S4 | Una voce il cui status è descriptive, not_applicable o not_evaluated | Saltala; un’esecuzione in cui è not_evaluated non conta per quel controllo. |
Decidere cosa significa ogni mancata corrispondenza
Ogni controllo rimasto rientra esattamente in una riga.
| # | Attività archiviata più recente | Voce nella risposta | Giudizio | Cosa fare |
|---|---|---|---|---|
| 1 | attested, changed o renewed | attested_at è uguale al suo created_at; state è in_force; status si abbina al suo valore. | Corrispondente | Niente. |
| 2 | cleared | attestation è null, salvo quanto previsto dalla riga 11. | Corrispondente | Niente. |
| 3 | lapsed, con Rischio accettato (accepted_risk) | attestation è null, oppure ha l’orario dell’attività precedente con state check_passing o setting_changed. | Corrispondente | Niente. |
| 4 | lapsed, con completed o control_failed | attestation è null. | Corrispondente | Niente. |
| 5 | attested, changed o renewed | attested_at è uguale al suo created_at; state è review_due, check_passing o setting_changed. | Atteso | Non in vigore: intervieni una volta su ogni nuovo stato, senza attendere un’attività; un ritorno a in_force azzera questa condizione. |
| 6 | attested, changed o renewed, con Completato (completed), e un created_at successivo alla tua prima esecuzione | Alla prima esecuzione che confronta l’attività, attestation è null e status è failed con un current_value. | Da approfondire | La pagina Security posture può mostrare come Superato una verifica con esito negativo: segnalala per la revisione, senza attesa. |
| 7 | attested, changed o renewed, con completed | attestation è null; status non è né not_attested né failed con un current_value null; la riga 6 non si applica. | Atteso | Niente da confrontare; la risposta non la mostra mai. |
| 8 | attested, changed o renewed, come Non superato (control_failed) | attestation è null; status è uno dei tre: failed; qualsiasi stato fornito dalla verifica automatica; oppure, dalla data di fine (review_date, in UTC) in poi, not_attested. | Atteso | Niente da confrontare; intervieni una volta quando status lascia failed dalla data di fine in poi. |
| 9 | attested, changed o renewed, con accepted_risk | attestation è null e status è passed, matches_profile o exceeds_baseline. | Atteso | Archivia un segnaposto (regola 7 sui segnaposto). |
| 10 | Nessuna, oppure ogni attività archiviata è precedente a attested_at | attestation è presente. | Da approfondire | Segui le regole sui segnaposto. |
| 11 | Nessuna, oppure una il cui valore non è control_failed | current_value è null e status è failed. | Da approfondire | Al tuo archivio manca un’attestazione come Non superato (control_failed): segui le regole sui segnaposto e intervieni una volta quando status lascia failed. |
| 12 | attested, changed, renewed o cleared, più recente di attested_at, con un’altra attività quasi dello stesso istante | attestation è presente. | Atteso | Le modifiche apportate quasi nello stesso istante possono essere archiviate in qualsiasi ordine. |
| 13 | La stessa, senza tale seconda attività | attestation è presente. | Da approfondire | Contatta il supporto Anthropic, una sola volta. |
| 14 | attested, changed o renewed | attested_at è uguale al suo created_at; state è in_force; status non si abbina al suo valore. | Da approfondire | Contatta il supporto Anthropic, una sola volta. |
| 15 | attested, changed o renewed; nessuna riga precedente si applica | attestation è null. | Da approfondire | Molto probabilmente cancellata: archivia un segnaposto (regola 7 sui segnaposto) e segnala per la revisione una sola volta. |
| 16 | Nessuna | attestation è null e la riga 11 non si applica. | Corrispondente | Niente. |
| 17 | Qualsiasi altra | Qualsiasi altra. | Da approfondire | Segnala per la revisione una volta. |
Tenere un segnaposto dove le due fonti non possono essere abbinate
Un segnaposto sostituisce ciò che manca a una delle due fonti, e lo tieni separato dalle tue attività archiviate. Per le righe 10 e 11, rileggi il feed e archivia e segnala il segnaposto solo se non arriva nulla entro 15 giorni, l’intervallo coperto dalla rilettura giornaliera. Alla tua prima esecuzione, archivialo subito, senza revisione.
Segnaposto della riga 10, identificati dal controllo e da attested_at:
- Rileggi a partire dalla tua attività archiviata più recente per il controllo, oppure da
attested_atincluso se non ne hai archiviata nessuna; i 15 giorni decorrono daattested_at. Costruisci il segnaposto dalla voce, contrassegnato come privo di attività; nella tabella decisionale, consideralo come un’attivitàattesteda quell’attested_atil cui valore si abbina al suostatus, se presente. - A ogni esecuzione che mostra l’attestazione, aggiornane
statusestate. - Quando arriva un’attività il cui
created_atè uguale a quell’attested_at, sostituisci con essa il segnaposto. - Quando due esecuzioni consecutive non mostrano l’attestazione, risolvi il segnaposto; segnalalo per la revisione a meno che non lo spieghi un’attività archiviata più recente o una mancata corrispondenza della riga 10 non risolta per il controllo, oppure a meno che entrambe le esecuzioni mostrino
descriptive. - Un’esecuzione che non ha letto l’organizzazione, o che mostra
not_evaluated, non conta ai fini di quelle due esecuzioni né le fa ripartire. - Se l’attestazione viene mostrata di nuovo, riapri lo stesso segnaposto.
Segnaposto delle righe 9, 11 e 15, identificati dal solo controllo:
- Per la riga 11, i 15 giorni decorrono dalla prima esecuzione che mostra lo
status. Finché il segnaposto non è risolto, non segnalare nient’altro per quel controllo; risolvilo quando arriva un’attività più recente, la risposta mostra l’attestazione, o due esecuzioni consecutive rientrano in un’altra riga. - Quando un segnaposto della riga 9 si risolve perché l’attestazione viene mostrata come
failed_check_accepted_risk, segnalalo per la revisione una volta: il rischio è in vigore.
Esempio pratico
Queste due esecuzioni leggono l’organizzazione nell’esempio di risposta nel Riferimento per i risultati; l’esecuzione 1 è la tua prima esecuzione.
- Esecuzione 1,
directory_sync_enabled. Archiviato:attested,accepted_risk, creata alle2026-10-20T15:04:00.220114Z. Risposta:failed_check_accepted_risk,in_force, lo stessoattested_at. Riga 1: Corrispondente. - Esecuzione 1,
allowed_invite_domains. Archiviato: niente. Risposta:descriptive,attestationnull. Regola S4: messa da parte. - Esecuzione 1,
oauth_conditional_access. Archiviato: niente. Risposta: un’attestationconstatereview_due. Riga 10: Da approfondire. Alla tua prima esecuzione, archivia subito un segnaposto, senza revisione. - Esecuzione 2,
oauth_conditional_access. Segnaposto: quello dell’esecuzione 1. Risposta: la stessa. Riga 5: Atteso. Intervieni una volta sureview_due.
Cosa la verifica non può rilevare
La verifica giornaliera non può rilevare un’attività mancante per un’attestazione che la risposta omette su un controllo automatico. La risposta non dà alcun segno di tale attestazione, oppure fornisce solo lo status failed, che sembra lo stato fornito dalla verifica automatica.
Quando un’organizzazione smette di rispondere
Un’organizzazione che ha restituito un 200 e poi restituisce un 404 in diverse esecuzioni consecutive richiede l’intervento di una persona, una volta. Chiedi a qualcuno con accesso alla pagina Security posture se la pagina è stata disattivata per l’organizzazione (vedi Disponibilità di Security posture). Se la pagina non è stata disattivata, contatta il tuo referente Anthropic. L’organizzazione potrebbe essere stata eliminata, oppure il tuo accesso, Security posture o l’endpoint potrebbero essere terminati per l’organizzazione. Qualunque sia la causa, risolvi i segnaposto dell’organizzazione e le mancate corrispondenze non risolte senza revisione, continua a chiamare l’organizzazione e riaprili se l’organizzazione restituisce un 200.
Questa pagina ti è stata utile?