Audit Log
What this screen is for
The Audit Log is your tenant's record of what happened: cryptographic operations performed with your keys, administrative changes to your tenant, and access events such as sign-ins. Events are signed when they are recorded, so tampering can be detected, and nothing on this screen changes or removes them.
Use it to answer who did what, to which key or object, when, and with what outcome. Operations that failed or were refused are recorded too, with their outcome.
Some administrative actions a platform administrator takes on your tenant are recorded on the platform side and do not appear in this trail.
What must exist first
Tenant administrators and key managers open this screen from their tenant's navigation. It is offered to SIMPLE and STANDARD tenants alike.
- The permission to read at least one audit trail, which is what shows this screen. Cryptographic operations, administrative changes and access events are each a separate permission, and one further permission reads all three. Each tab on the screen is a trail you are permitted to read; a trail you are not permitted to read has no tab.
- The permission to trace a request by its correlation identifier also puts this screen in your navigation, but on its own it opens no trail.
- The permission to read audit integrity, for the integrity status shown beside the title.
The built-in key manager role carries no audit permission, so a key manager needs a role that adds one. The tenant administrator role holds them all.
Decisions you make here
Choosing what to look at
All shows every trail you may read together, and Crypto, Admin and Access show one each. Narrow the list with the search box, a Date range and an outcome; on Crypto you can also filter by operation, and on Admin by action and entity type. Each filter offers only the values the trail actually records.
Events are listed newest first, and Load older fetches the next page.
The figures above the list summarize the cryptographic and administrative trails over the date range you set: Total Events, the events of Today or, once you set a range, In selected window, and Failed Operations. With no date range, Failed Operations covers the last 30 days counted in whole hours: from the start of the hour 30 days ago to the end of the current hour, so up to one hour more than 30 days. It counts failed operations and refused cryptographic operations, but selecting it narrows the list to failed outcomes only; use the outcome filter to list the refused ones.
Narrowing to one subject
The Subject control narrows the list to one object of your tenant: choose Application, Cryptographic actor, Exchange context or Capability grant and enter its identifier, and the list shows the cryptographic operations that name it together with the administrative changes made to it. Entity ID narrows to the administrative changes of any one entity instead, and needs an entity type, which the entity type filter beside it sets.
The subject combines with every other filter. Access events never name a subject, so the Access tab shows nothing while one is set. Clear subject removes it.
An identifier that cannot be one is stated under the field and nothing is read: the first four kinds take a UUID, and an entity ID is 1 to 100 characters with no control characters. An identifier of nothing in your tenant lists no events.
View in Audit Log, in the Activity of an application, actor, exchange context, constraint policy or capability grant, opens this screen already narrowed to that subject over the last 365 days.
When the audit service of this environment cannot filter by subject, the list shows no events and says so, because an unfiltered list would read as that subject's history. Exporting with a subject is refused the same way, and no file is saved.
Sharing what you see
Every filter on this screen — the tab, the search, the date range, the outcome, the operation, action and entity type, and the subject — is kept in the page address. Reloading the page, or opening a copy of its address, shows the same filtered list, so an address can be shared with another reader who holds the same audit permissions.
Reading an event
Selecting an event opens its details: when it happened, the actor and user behind it, and its outcome. Depending on the trail, they add the key, algorithm and material version a cryptographic operation used; the reason an operator gave and what an administrative change changed; or the principal, address and endpoint of an access event. An event that did not succeed also shows its error code.
The correlation identifier in the details is shared by the events one request produced.
A capability grant named in an event links to the grant's detail on the capability grants screen: the grant field of a cryptographic event's details, and the entity identifier of an administrative change to a grant, in the list and in the details.
The actor is named by the name its token carried when the operation ran, with its identifier underneath. Request origin states where the request came from — client address, user agent, request identifier, path and method — and appears only when the event had a request. A cryptographic event also lists Keys used, every key the operation used. When this screen shows an event a platform operator produced in your tenant, it does not show the operator's address.
The event is marked Platform-mediated when the operator acted inside your tenant through support access, and names the operator as the deployment decides: on an ANKA-hosted deployment as Platform operator with a short reference, never by name; where your organisation operates the platform, by login.
Exporting
With the same permissions that show the list, Export CSV downloads the events that match the tab, filters and date range on screen, as one CSV file. An export needs a date range of at most 365 days, so set one before you export.
The file has the same fixed set of columns whichever tab you export from, and it does not include the details column. An export stops at a row limit set for your installation; when it does, the console warns that the file is not the whole result, so narrow the date range or the filters and export in parts.
Checking integrity
With the permission to read audit integrity, the status beside the title says whether your tenant's audit records were last verified intact, which trails that verification covers, and whether older events were removed by the retention policy. A platform administrator starts the verification; this screen only shows its result.
How it relates to other screens
Operations are attributed to the cryptographic actor that performed them:
A key's lifecycle decisions, including the reason given for a suspension or a revocation, are recorded here, and each key's own history is also available from its detail, where the operations are separated by key when more than one key has held the same identifier. When destroying a key revokes exchanges and internal use cases, each revocation is recorded here as an administrative change carrying its cause and the destroyed key's identity:
An operation refused because no capability grant authorized it, or because a constraint policy condition was not met, is recorded here with its outcome. A grant named in an event opens its detail there:
An internal use case's own administrative history is also shown on its Activity tab:
View in Audit Log in the Activity of an application or an exchange context, as in that of an actor, a grant or a policy, opens this screen narrowed to it: