Secure configuration

Roles decide what authenticated users may do. Secure configuration decides how hard it is to become an authenticated user in the first place, and what powerful doors exist outside the role concept. On Contoso Motor Co.'s program, Sam's Basis team owns most of these settings and Nadia's security team defines the targets. Under RISE with SAP, some technical layers are operated by SAP; who sets and checks which parameter is part of the contract's responsibilities, so read it before assuming either side covers an area.

Start from a baseline

SAP recommends defining a security baseline: minimum requirements every SAP system must meet, regardless of its risk assessment, with stricter measures for critical systems on top. SAP provides a Security Baseline Template, prefilled with selected requirements and concrete values, as a starting point, and points to SAP Note 2253549 for current product-specific security recommendations. The baseline turns "secure" into a list of checkable settings, which is what makes it testable and auditable.

Logon and password settings

Password and logon rules are profile parameters, viewable in RZ11 or with report RSPFPAR. Key ones include login/min_password_lng (minimum length), the login/min_password_* family for digits, letters and special characters, login/password_expiration_time, login/fails_to_user_lock (failed attempts before a lock), and login/password_max_idle_initial and login/password_max_idle_productive (how long unused passwords stay valid). Prohibited passwords can be listed in table USR40. Where single sign-on is used, for example Fiori logon through the Identity Authentication service of SAP Cloud Identity Services (SAP's umbrella name for Identity Authentication, Identity Provisioning and related services) federated with Contoso's corporate identity provider, password rules still matter for users and situations that fall back to passwords, and the profile parameter login/disable_password_logon can restrict password logon for user groups that should only use SSO.

Security policies, maintained in SECPOL and assigned on the user's logon data, let you apply different rules to groups of users, for example stricter rules for administrators, without burdening every user. Report RSUSR_LOCK_USERS can lock users who have been inactive for a set period, which removes a common audit finding.

Standard users

RFC and interfaces

Remote function calls let other systems run functions in S/4HANA. Three settings matter most: the RFC users' roles (authorization object S_RFC for function groups, granted narrowly), the destinations that store credentials to log on to other systems (anyone who can use a destination with a stored powerful user can act as that user), and the gateway access control lists that decide which external programs may register or be started. Kenji's team documents each interface's user and the function groups it needs, so the interface roles can be built with the same least-privilege discipline as business roles.