Analisi delle anomalie delle richieste API

Disponibile in Salesforce Classic (non in tutte le organizzazioni) e Lightning Experience.

Disponibile in: Enterprise Edition, Unlimited Edition e Developer Edition Richiede l'abbonamento ai componenti aggiuntivi Salesforce Shield o Monitoraggio evento Salesforce.

Ai clienti di Shield gli eventi di Monitoraggio evento in tempo reale offrono le informazioni necessarie per svolgere l'analisi. In particolare:

• ApiAnomalyEvent e l'equivalente ApiAnomalyEventStore per l'archiviazione tengono traccia delle anomalie su come gli utenti effettuano le chiamate API. Questi oggetti sono il punto di partenza dell'analisi.
• ApiEventStream e l'equivalente ApiEvent per l'archiviazione tengono traccia delle chiamate API di sola lettura avviate dagli utenti. Utilizzare questi oggetti per visualizzare le esecuzioni delle API storiche o in tempo reale.
• LoginEventStream e l'equivalente LoginEvent per l'archiviazione tengono traccia di tutta l'attività di accesso nell'organizzazione.

Si supponga, ad esempio, che la propria organizzazione riceva un oggetto ApiAnomalyEvent che indica una potenziale anomalia nelle chiamate API di un utente. La prima cosa da fare è esaminare i campi pertinenti dell'evento per raccogliere informazioni di base sull'anomalia, ad esempio:

• Score: numero che rappresenta in che misura questa attività API dell'utente si differenzia dalla sua attività consueta. A un numero maggiore corrisponde una maggiore divergenza.
• UserId: ID univoco dell'utente.
• EventDate: ora in cui si è verificata la richiesta API.
• SecurityEventData: campo JSON che contiene le funzioni, ad esempio il conteggio delle righe o il giorno della settimana, che hanno contribuito maggiormente al rilevamento dell'anomalia.
• Summary: riepilogo testuale dell'evento.

Vedere la documentazione API per l'elenco completo dei campi.

Questa query SOQL di esempio restituisce questi valori dei campi.

SELECT Score, UserId, EventDate, SecurityEventData, Summary
FROM ApiAnomalyEventStore

Si osservi più attentamente il campo SecurityEventData, che contiene i fattori che contribuiscono all'attivazione del rilevamento dell'anomalia. Ecco i dati di esempio:

[
{
"featureName": "rowCount",
"featureValue": "1937568",
"featureContribution": “95.00 %"
},
{
"featureName": "autonomousSystem",
"featureValue": "Bigleaf Networks, Inc.",
"featureContribution": “1.62 %"
},
{
"featureName": "dayOfWeek",
"featureValue": "Sunday",
"featureContribution": “1.42 %"
},
{
"featureName": "userAgent",
"featureValue": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36}",
"featureContribution": “1.21 %"
},
{
"featureName": "periodOfDay",
"featureValue": “Evening”,
"featureContribution": “.09 %"
},
{
"featureName": "averageRowSize",
"featureValue": "744",
"featureContribution": “0.08 %"
},
{
"featureName": "screenResolution",
"featureValue": "900x1440",
"featureContribution": “0.07 %"
}
]

La funzione che ha contribuito maggiormente (95,00%) al rilevamento dell'anomalia è rowCount con un valore di 1.937.568. La funzione indica che l'utente ha visualizzato o esportato un rapporto con 1.937.568 righe. Ma in base ai dati storici, l'utente raramente visualizza o esporta così tanti dati. Le altre funzioni hanno contribuito molto meno al punteggio. Ad esempio, l'utente ha eseguito il rapporto la domenica, ma questa funzione ha contribuito solo con l'1,42% al punteggio complessivo.

Ora che sono disponibili i dati, è possibile approfondire l'analisi.