SAP Best Practice Security

• Design roles for least privilege; avoid SAP_ALL for normal users.
• Enforce separation of duties (SoD), ideally with GRC.
• Secure integration: least-privilege RFC users, secured gateway, TLS.
• Keep systems patched (SAP Security Notes) and audited (Security Audit Log).
• Control powerful/emergency access (firefighter) tightly.

One practice that belongs on any list and is usually absent: write down who owns each control. Not the team, a person. Access reviews, patch assessment, the audit log, emergency access review and role ownership each need a name, because a control owned by a department is a control performed by nobody in particular.

Security discussions default to roles, and a practice that only covers roles leaves most of the surface untouched. The layers, roughly in the order they are neglected:

Authorisations. Least privilege roles, segregation of duties checked against a ruleset, and periodic access review. The best understood layer and the one most organisations do something about.

Users and credentials. Joiner, mover and leaver actually performed, technical account passwords rotated, emergency access that expires. The mover case is the one that quietly fails.

The platform. Default accounts changed, security notes applied on a schedule, gateway and message server access restricted, encryption configured for connections carrying credentials.

Change control. Production closed to direct configuration, transports approved, developer access absent from production. These are security controls even though they are usually filed under operations.

Data protection. Personal data in HR and customer records, who may see it, how long it is kept, and whether it can be erased on request. Increasingly a legal obligation with deadlines.

Monitoring. Security audit log switched on, and somebody reading it. A log nobody reads is storage.

One layer sits underneath all of these and is usually somebody else's job: the infrastructure. Operating system hardening, network segmentation, and who can reach the server at all. A perfectly configured SAP system on a host anybody can log into is not secure, and the boundary between the SAP team and the infrastructure team is exactly where that gets missed.

Not a full audit, and enough to know whether the basics are in place.

1. Default users. Check the delivered accounts exist with changed passwords and are locked where not needed.
2. Wide access. Use SUIM to list users holding SAP_ALL or a profile granting everything. Expect a short list with names against it.
3. Developer access in production. Search for users with developer keys or debug and change authorisation there.
4. Client settings. SCC4 for whether production allows configuration changes and cross-client changes.
5. Patch level. When security notes were last assessed and applied.
6. Audit log. Whether it is on, what it records, and whether anybody looks.

Six checks. If any of them cannot be answered, that is the finding, because a control nobody can evidence is a control nobody is operating.

SAP holds the enterprise’s crown-jewel data and can change access everywhere, so weak security risks breach, fraud and audit failure. Least privilege, SoD, secure integration and monitoring are both protection and compliance requirements (e.g. SOX).

The specific risks are worth naming rather than left abstract. A fabricated supplier with altered bank details is the most common financial fraud in an ERP, and it needs only create and pay authority in one person. Payroll data and customer records carry legal obligations rather than only commercial ones. And a system reachable from the internet with unpatched components is a target regardless of what it holds. See configuration practice and the practices overview.

• Small teams and segregation of duties. Where one person genuinely does two conflicting jobs, the answer is a documented compensating control rather than pretending the conflict is absent.
• Emergency access. Pre-approved and logged, or requested each time. The first is faster and depends entirely on the log being reviewed.
• Patch cadence against change freeze. Security notes arrive monthly and businesses freeze changes at period end, so the window has to be agreed rather than left to collide.
• Non-production systems. They usually hold a copy of production data with weaker controls, and deciding whether to scramble it is a real decision with a real cost.

Most SAP systems have the security audit log available and switched off, or switched on recording nothing useful, so it is worth knowing what it is for.

It records security relevant events at the application level: logons, failed logon attempts, transaction starts, report starts, changes to user master records, and RFC calls. That is a different thing from the change documents that record what a business object changed to.

What to record is a real decision, because recording everything produces volume nobody reads. Failed logons, particularly repeated ones for one account. Successful logons for privileged accounts, so use of an emergency or administrative account is visible. User master changes, since granting access is the action that enables everything else. Use of sensitive transactions, chosen deliberately rather than by category.

Retention matters too: an incident is usually discovered weeks after it happened, so a log rotated after seven days answers nothing.

The part that makes it worthwhile is somebody reading it, or better, alerting on the patterns that matter. A log switched on to satisfy an auditor and never opened is evidence that the control was designed and not that it operates.

Faced with a system where none of this has been done, the order matters, because some of it protects more per hour than the rest.

First, the platform. Default account passwords, locked where unused, and an assessment of outstanding security notes. This is a day's work and it closes the vulnerabilities that do not require anybody to be inside the organisation.

Second, privileged access. Who holds SAP_ALL, developer access in production, and user administration rights. A short list with justification, and everything else removed.

Third, leavers. A list of accounts belonging to people who have gone, locked and their roles removed. This is usually a surprisingly long list and it is quick to fix.

Fourth, the audit log, switched on and recording the events above, so from now on there is evidence.

Then role design, which is the largest piece and the one most likely to be started first because it is the most familiar. Doing it last is deliberate: it takes months, and the first four take days and close more risk.

• Skipping the discipline under delivery pressure.
• Not documenting decisions.
• Ignoring the clean-core principle.

• Security as a go-live task. Roles drift within a year and nothing revisits them.
• The audit log switched on and never read. It answers questions after an incident and prevents none.
• Sandbox and training systems ignored. They often hold real data with weaker access. See performance practice and naming conventions for the neighbouring disciplines.

• A finding list with no owner or date. Security assessments produce them routinely, and one nobody is accountable for is the same as not having done the assessment.

Knowing the layers is the start, and assessing a real system and building the remediation plan it needs is the part you do in the course.

If you inherit a system with none of this in place, resist starting with role design. The platform, privileged access, leavers and the audit log take days between them and close more risk than months of role work.