DocsSecurity
Staff access log
Each time INFRO staff open or change something of your organization in INFRO's operations console: what, when, the staff role, and the outcome, kept for 400 days.
On the roadmap — not available yet. The staff access log is built and in testing, and not deployed. This page describes what it will ship with.
INFRO's staff work in a separate operations console, with their own accounts. The staff access log lists, on your Security screen, each time one of them opened or changed something of your organization there: your organization's details, its members, keys, connections, subscription, a request, a Studio asset or a support ticket. It is on every plan.
What each entry says
| Field | What it is |
|---|---|
kind | read (something was opened) or action (something was changed). |
description | What it was, in words: "Viewed the organization's details", "Revoked a gateway key", "Placed an operator hold on the organization". A route without its own wording reads "Viewed in the operations console" or "Changed in the operations console". |
method, route | The operations-console request, with every id replaced by :id (DELETE /ops/organizations/:id/keys/:id). |
operator_role | The staff member's role: ops-admin, ops-engineer, finance or service. |
operator_ref | A reference to the staff member, the same on every entry they made for your organization and different in every other organization. It tells two people apart; it never names them. |
status | The HTTP status the operations console got. A refused attempt is listed too. |
count, first_at, last_at | Reads are folded into one entry per staff member, route and UTC hour, with how many times; an action is one entry each. |
Entries never carry the staff member's name or address, or what a request sent. They are kept for 400 days.
What is attributed to you
An entry is written when the operations-console request names your organization: a page of your organization (/ops/organizations/{id}, its subscription), a list narrowed to it (?organization_id=), or one of your records by its id (a request, a connection, a Studio asset or preservation, a support ticket). Opening a person's account is attributed to every organization they are a member of.
- Views across every customer at once (the unfiltered request log, traffic, operator alerts, the email log) are not listed per organization: they are staff's working views, and an entry per organization per page would say nothing about whose data was looked at closely.
- Staff pages keyed by something other than your records (announcements, provider applications, startup applications, sign-up grants) are not attributed.
- Entries are written after the request, in the background; an entry that fails to write is dropped rather than slowing staff down. An id that names no organization writes nothing.
Who sees it
Everyone who opens the Security screen organization-wide: owners, admins, Security members, developers, analysts and finance members. Members limited to some projects and creators do not. Staff access is also a stream of the SIEM export.
API
Through the console session: GET /console/security/staff-access with days (1 to 400, default 90), kind (read or action) and limit (1 to 1,000, default 200) returns {days, data}, newest first. Each entry has id, kind, method, route, description, operator_role, operator_ref, status, count, first_at and last_at. An unknown kind is 400 invalid_request; a member limited to projects is refused with 403 project_restricted.
With a management token holding security:read (the management API, on the Startup plan and up), the same list is GET /manage/v1/security/staff_access, as {object: "list", days, data}, with the same parameters. A project-restricted token is refused.