How Reliably Is the Data in a Multiple Client System Isolated? (SAP Library

How Reliably Is the Data in a Multiple Client System Isolated?

To guarantee exclusive access to the data of a client, you need to take extra data access logic precautions as well as categorizing the data correctly. A customer who logs on to his or her client in the system must have all activities restricted to his or her customer data, and be denied access to the data of other clients (the customer must be under the impression that the entire database is only open to him or her).

Data isolation is guaranteed if each time you access client-specific tables, you are implicitly restricted to the active logon client within the database interface, and unable to manipulate this access from the application program level or at runtime. Four questions arise from this:

Question 1: Is there a way to prevent the implicit selection of clients?

The logic of the database interface is a piece of fixed code and cannot be accessed from outside. Dynamic client selection is triggered only by the table attribute client-specific table, which is a fixed attribute of the table in the ABAP Dictionary. There is no way of temporarily removing this attribute.

Question 2: Is there a way to manipulate the active logon client from outside, so that you can access the data of another client?

During a session, a user addresses the client only once, when entering the client explicitly in the logon window (if Single Sign-On is used this is done implicitly using Central User Administration). You cannot log on to an SAP System without specifying a client.

Note: This does not apply to SAP BW.

Once you have logged on, the client field does not appear on the user interface again, and cannot be manipulated with application transactions. This means that the client cannot be changed during a session.
Technical Details: Once you have logged on to a client in a system, you remain in this client until the end of the session. You can use the system variable SY-MANDT to query the active logon client in ABAP programs, however, this variable is updated with the internally active logon client in each dialog step, making it impossible to be overwritten. This means that even an ingenious application of breakpoint and replace techniques cannot overwrite the active logon client from the outside.

Question 3: Are there generic tools in the SAP System that can be used to access any table?

There are generic tools that give you free access to table data, however, if multiple client operations are organized correctly, they do not place client data at risk. One of these tools is the Data Browser. To access the Data Browser, choose Tools → ABAP Workbench → Overview → Data Browser (or call Transaction SE16). This tool fixes the active logon client, which means that the client is filtered in the same way as at the database interface. Client comparison functions are also available, which are either included in the standard view maintenance functions or which can be accessed as a standalone transaction (Customizing Cross-System Viewer (Transaction SCU0) and View/Table Comparison (Transaction SCMP)). This functions are not functions that are permitted in production operation of the system. You can also lock them at the transaction level. Accessing a different client requires two additional authorizations S_TABU_CLI and S_TABU_CMP, neither of which may be assigned in a production system. All these utilities can be used to protect data in a sensitive client from being accessed. This can be controlled in the client settings in the client maintenance functions. To call this transaction, choose Tools → Administration → Administration → Client Administration → Client Maintenance (or call Transaction SCC4). The generic tools can be used to control access to different clients at several different levels of authorization. All tools also guarantee that access to other clients is read-only access. Write-access is only possible in the client where you are currently logged on.

Question 4: What is the technical basis of the data isolation?

Viewed technically, each time a client-specific table is accessed, the database interface implies an additional selection of the active logon client, meaning that the WHERE clause is added to the SQL statement.

"WHERE <client-field> = <login-client>".

This substitution is made dynamically in the database interface at runtime.

The following summary can be derived from these four questions:

Access to client-specific tables is carefully restricted to the currently active logon client, using the access concept described above.
This client filtering affects both read and write access.
This logic is realized as part of the database interface, which makes it inaccessible to both programmers and end users.

The answer to the fourth question also refers to the option of ignoring the client data isolation provided by the ABAP SQL. As well as the ABAP SQL in the programs, there are two other special language utilities that can be used to access data while avoiding the client filter:

Usage of language supplement CLIENT SPECIFIED in the context of the ABAP SQL call and
Usage of Native SQL instead of ABAP SQL

In both cases, you must formulate the client explicitly as a selection criterion. This is one potential approach when attempting to misuse programs. A client ID could be used directly by a non-privileged user to read or falsify the client data. The ASP is the only administrator of the repository and therefore has a special responsibility for checking the use of the language statements specified above when importing modified or additional programs. Normal application programs must only be allowed to use ABAP SQL; data buffering requirements make this mandatory.

In principle, this applies to all standard mySAP.com application programs. However, there are two exceptions:

Special functions: Upgrade utilities, comparison tools, and ALE communication functions use a range of special functions that access data in other clients. These, however, are individual technical service functions whose code must never be part of an application program.
Tuning the optimization of access to data In earlier database versions, you could influence the database optimizer positively by specifying the client field explicitly in the key selection list; this improved performance dramatically and immediately. The CLIENT SPECIFIED construction with an explicitly specified client was ideal for this. This improvement was achieved by the access optimizer of the database system. This is particularly true when using Native SQL ('EXEC SQL'), which lets you exploit special database system attributes to access mass data and avoid performance problems.

In both cases, the standard calling program must select the current logon client (SY-MANDT). If you selected a hard-coded client value, for example, you would get an incorrect logic and the wrong functions. This must be judged like any other serious programming error, and tested for in the acceptance tests before an SAP Release is shipped.

The provider can use the tool described under Checking the Multiclient Compliance of Add-On Products as support for checking modifications and additional programs. This tool checks each import for 'suspicious' program objects, including programs that contain one of the two constructions mentioned above.