Segregation of duties analysis in the RedRays Security Platform reads user, role and authorisation master data out of an SAP system over a remote function call (RFC) connection, using a read-only account, and reads no business documents of any kind.
Two questions come up before the first connection is opened: what will it read, and what will the account it uses be able to do. Both have short answers, and both are worth putting in writing before a security team is asked to approve anything.
Everything below is access administration data. None of it is business content.
| What is read | Why it is needed |
|---|---|
| Accounts and their attributes, including account type, lock status and last logon date | To know who exists, which accounts are technical rather than human, and which are locked |
| Role definitions | To know what exists to be assigned |
| User-to-role assignments with their validity dates | To know who holds what, and whether the grant is in force on the scan date |
| Composite role membership | Because access frequently arrives through a composite rather than directly |
| Profiles assigned straight to an account | Because these carry no role name and are invisible to role-based reviews |
| Reference user links | Because access inherited this way leaves no assignment row against the person |
| Authorisation values, object by object and field by field, including organisational values and the flag that marks a withdrawn authorisation | Because this is what SAP checks at runtime, and it is the only basis on which a duty can be evaluated honestly |
Withdrawn authorisations are read and then excluded, rather than ignored at the source, so the coverage report agrees with what SAP actually holds. A tool that skips the flag reports access the system already took away.
Organisational values are taken from where SAP checks them at runtime rather than from where they are maintained. Organisational levels maintained in the role editor are merged into the generated authorisations interactively, and that merge does not happen over a remote read, so reading the maintenance side would produce values SAP does not enforce.
A dedicated account for the connection, authorised to log on for RFC and to read the tables listed above through SAP's standard table-read interface. It needs no dialog logon, no write authorisation anywhere, and no administrative profile. Granting an unrestricted profile to a scanning account is a bad practice generally, and here it is also unnecessary.
Two practical points follow from that. The first is that the account's read authorisations should be scoped to the tables the analysis needs rather than to table access in general, because unrestricted table read is itself a finding this platform reports elsewhere. The second is that the connection details and the account are the customer's, held in a product installed on the customer's own infrastructure. See deployment and where data goes.
By checking before claiming, and by reading deterministically.
Before a scan does any real work, it probes every table it will read, with the same fields the real read will request. A scan that discovers on the last table that its account cannot read directly assigned profiles has already spent minutes on the largest one, and worse, it now has to decide whether to publish a result that is missing a grant path.
Determinism matters more than it sounds. A remote table read returns rows in no defined order, so paging by the last key seen skips rows silently and reports success every time. Losing a share of the authorisation rows produces a scan that finishes cleanly with fewer conflicts, which is the most flattering possible failure and the one nobody reports. The read partitions the key space and takes each partition whole, and two consecutive scans of an unchanged system stage the same row count.
No. The connection is used for reads. Remediation happens in the customer's own change process, and the next scan is what confirms it.
Then the same analysis can be run from an offline extract produced by your own team, with a per-rule statement of what the extract could and could not answer. See analysing an air-gapped SAP landscape.
It is dominated by the size of the authorisation data rather than by the number of users, and it is a batch read that runs comfortably in a scheduled window. Sizing for a specific landscape is measured during a proof of concept rather than promised in advance.