How do I identify which session performed a cloud action?¶
Identify the session by linking the cloud action to authentication, session, token, device and application records.
Evidential caution: that the nearest login in time must be the session responsible.
What this means¶
A session may have been created hours or days earlier and continue through token refresh.
Several sessions may be active on the same account at once.
Then locate matching session creation, refresh, access and revocation records.
Corroborate the session with device artefacts where possible.
Where event and session times differ slightly, preserve both and check whether provider processing delay or clock conversion explains the difference before treating them as unrelated.
What to check or do next¶
- Start with the action itself.
- Record the event ID, account, resource, time, application, IP address, device information and any session or correlation identifier.
- Check whether the action came through a browser, mobile app, sync client, API or service account.
Evidential limits¶
Do not assume a changed IP address means a changed session. Mobile networks, VPNs and roaming can alter the connection.
Equally, similar device information does not prove the same session.
Where the provider does not expose a session ID, compare the combination of account, application, device, IP address and timing cautiously.
Where several candidate sessions remain, rank them by the strength of the linkage and record why. Do not collapse uncertainty into one apparently precise answer merely because the provider view shows a single account name.
Operational takeaway
Link the cloud action to the relevant session using event, token, application, device and correlation records rather than assuming the closest login caused it.