The auditor’s question is rarely technical: who made the call that moved this data out on 14 March? The answer should be a name. In most organizations the answer is the name of a system — “the integration user”.
The question does not close there; it grows. How many integrations share that user, which one ran that day, which IP did it come from? Because the identities were never separated, a single call cannot be traced.
Four identities, four separate controls
Four identities move through an installation at the same time:
- The person using a screen.
- The job running in the background.
- The external system calling an API.
- The visitor arriving through a share link.
Each is controlled in a different layer, so “is access secure?” cannot be answered until they are separated.
On the screen side, session management is built on Spring Security, passwords are stored with BCrypt, and front-end routes are gated by a layer that checks authorization objects; module access is mapped to customer and module activation as well. Opening a screen and seeing SAP data on it are two different decisions: the first depends on the application role, the second on authorization in SAP.
On the service side, outbound API calls require Basic Authentication, only an active service-type user is accepted, and the customer and system assignment is verified. On top of that sit a per-service user list, allowed and blocked IP rules, per-minute and per-hour request limits, and request and response logs.
One misunderstanding is worth closing here: the identifier in a service URL is not a password. It resolves the service and system context. What controls access is authentication, the user list and the IP rule.
The boundary drawn by customer and system context
Data access is filtered by customer and system. Because development, quality and production system relationships can be defined, several contexts are managed inside one installation, and a test run in the quality system does not mix with production records.
We do not present that as absolute isolation. The claim is narrow and checkable: access is filtered by customer and system context, and getting the separation right depends on how the installation is configured.
The fourth identity surprises people most. A BI share link runs without a session, under a separate identity, and does not inherit the sharing user’s row-level authorizations. Good news for security, and behavior to watch operationally, because the scope can come back empty. Open the link in a browser without a session before you publish it.
What has to be closed at the network layer
To be straight about it, the list has a gap as well. Some internal and service endpoints are open at the application layer and need to be restricted by a network or firewall rule. An installation that leaves this off the go-live checklist is trusting a control that is not there.
These four layers are not a certificate or a compliance statement. What is concrete is narrower: which identity is limited by which control can be written down, and in an audit that writability is what helps.
We suggest starting with one question: how many integrations share the same service user today? Bring the list, and we will set up a separate user, IP rule and request limit for each one with you.