Skip to main content

Review integration access and activity

Outcome. You can show which people and systems may call Lattice, who may run the high-risk operations and open the database, and what was actually called in a period, and you have removed access that is no longer needed. Who takes part: Integration administrator, Database access administrator, Integration read-only (the reviewer or auditor). Stages that use standard pages (Assign users to roles, Security configuration, Microsoft Entra ID applications, Users) need System administrator or the access named on the role page; the Lattice roles do not open them. How often: on a schedule you set, for example every quarter, and whenever a person or an integration leaves.

1. Confirm what the logs keep (Integration administrator)​

The activity review is only as complete as the service call log. An operation can be set to log only errors or nothing, and rows are kept only for a retention window (90 days for calls, by default). Give the reviewer the logging settings before the review starts, and keep the high-risk operations at All.

Done when: the reviewer has the rows of Service operation logging configuration (an empty list means every operation logs at All), and the period under review is inside the retention of every operation in it.

2. List who holds each Lattice role (System administrator, Integration administrator)​

Lattice has no page that lists role holders, so work from the standard security pages, which need System administrator. List the users of each Lattice role and of each custom role built from Lattice duties. Then check that every integration client maps to its own dedicated user with the narrowest role its calls need, and that only the right client applications may submit to each recurring data job.

Done when: you have a list of users per role, each with a reason, and every Lattice client on Microsoft Entra ID applications is mapped to a dedicated user.

3. Review the high-risk operations (System administrator)​

The duty Integration service high-risk operations lets its holders cancel, reverse, post across legal entities, recover failed messages and change integration configuration. Find every role that contains it and every user in those roles. Review two administrator pages with them: the Service test console runs real operations, and File ingestion connections can replace a stored secret and run the connection with it. Holders of the duty also read the payloads of failed messages through the LatticeIntegrationDeadLetters entity, and those reads are not in the View payload audit; the operator and read-only roles get that entity without the payloads.

Done when: View related roles for the duty lists only Integration administrator and the custom roles you approved, and every user in those roles is on your approved list.

4. Review database access (System administrator, Database access administrator)​

Database access is outside every Finance and Operations security control, and nothing records what a holder did while connected (what is not controlled), so review it on its own. A System administrator checks who holds the Database access administrator role, and that role or a System administrator reads the grants: who requested each one, for which IP address, and when it was issued and expires. A holder can show the password only of a grant they requested themselves, so the role does not let one administrator read another's credential; any holder can revoke any grant.

Done when: Assign users to roles shows Database access administrator with no users or only named people, every grant in the period has a requester and a reason you can account for, and no grant is Active that should not be.

5. Review the activity for the period (Integration read-only)​

The reviewer reads what was called in the period and how often it failed. The calling user is not on any page: read it, and who acted on failed messages, from the OData entities. A reporting tool with the same role can read the logs in bulk.

Done when: for every high-risk operation called in the period, CalledBy in LatticeServiceCallLogs names a user you approved in stage 3, and LastActionedBy in LatticeIntegrationDeadLetters on items a person acted on names only administrators you expect (an item that only failed shows the user its failed run ran as).

6. Act on what you found (System administrator, Integration administrator, Database access administrator)​

Remove roles that are no longer needed, retire the client of an integration that has ended, disable client applications that should stop submitting, revoke database access that is still active without a reason, and raise the logging level of any operation you could not review. Keep the date and the findings of the review.

Done when: repeating stages 2 to 4 shows each change: the user is gone from the role on Assign users to roles, a retired client is gone from Microsoft Entra ID applications, the client application shows as disabled, and the grant shows as Revoked.

If something goes wrong​