The question comes six months later. Internal audit sits down and asks one thing: “how is this service protected?”
The worst possible answer is an adjective. The word “secure” tells an auditor nothing, because an auditor is looking for the name of the control, its scope and its owner. The best answer is a list of settings written in the half hour before go-live.
That half hour is exactly what gets skipped. The moment the service responds, the job feels finished, the controls get postponed, and postponed does not come back.
The pre-release access control list
Each item below closes a different risk, and none of them substitutes for another.
- A separate service user per integration. A shared user leaves “who made this call?” unanswered. User and system assignment are defined per service.
- Narrow the user scope. List the users allowed to reach the service; an “everyone for now” setting has a habit of becoming permanent.
- Allowed and blocked IP lists. If the consumer calls from a fixed egress IP, use it. If it does not, write down that this control is not in play.
- Per-minute and per-hour request limits. Size them from the first days of call records rather than from a guess. A limit set too tight produces one of the hardest failures to diagnose in production.
- Fixed parameters. Choose deliberately which parameters may change at call time; pinning fields such as company code or fiscal year is usually the right call.
- A name against the logs. Request and response records nobody reads are an archive, not a control.
- A closing date. Write the end date now for access opened for a temporary integration; the system will not remind you.
What Basic Authentication covers, and what an IP rule covers
Putting every control in one bag is the first thing that falls apart in an audit. A call to /app/api passes Basic Authentication and is accepted only for an active user of type SERVICE: that answers who is calling. The service user list and the SAP object authorization decide what that identity can reach. The IP rule limits where the call comes from, and the per-minute and per-hour limits how often it comes.
Build two boundaries in knowingly. The request limit is calculated from the last minute and hour of records in the log repository; it is not a distributed gateway algorithm. And when the IP cannot be determined, the controller may skip the IP check for backward compatibility.
There is a trial you can run in your own environment: call the service from an address that is not on the allow list, and watch the request get rejected in the records. You confirm a control by seeing it work, not by reading its setting.
A service user does not expire on its own
These controls are concrete and auditable. They are not a certification, a compliance statement or a claim of absolute security. Two points should stay explicit: the service GUID is not an authentication credential, and an API user does not expire by itself. Closing access stays on the task list of the team that opened it.
Run the list against a service already in production rather than a new one. Read the seven items one by one; whichever is the first you cannot answer, let us start by closing that one together.