Data Isolation in Multiclient Systems

Use

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 user 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.

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). It is not possible to log on to an SAP system without selecting a client.

    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. Therefore, even overwriting this ABAP variable externally has no effect. 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 Start of the navigation pathTools Next navigation step ABAP Workbench Next navigation step Overview Next navigation step Data BrowserEnd of the navigation path (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. In this way, you can 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

    Start of the navigation pathTools Next navigation step Administration Next navigation step Administration Next navigation step Client Administration Next navigation step Client MaintenanceEnd of the navigation path (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.

Open SQL provides the language supplements CLIENT SPECIFIED and USING CLIENT (Basis 740, SP5), which can be used to specify the client explicitly. In CDS views as well, where the value false is specified in the annotation @ClientDependent, the client has to be specified in the selection condition. In contrast to Open SQL, Native SQL (EXEC SQL, ADBC, AMDP) does not have automatic client control, which means that the programmer is responsible for client handling in these cases as well.

Incorrect client handling could be a potential approach for anyone attempting to misuse programs.

For example, a non-privileged user could intentionally use a client ID to read, misuse, or falsify the client data. The service provider 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. You should adhere to the programming guideline that normal application programs should only be allowed to use Open SQL, without the language supplements CLIENT SPECIFIED and USING CLIENT. In fact, for data buffering reasons, this guideline should be obligatory.

In principle, this applies to all standard SAP application programs, except the following:

  • 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. Acceptance tests before shipment of an SAP Release ensure that even in these exceptions the current logon client (SY-MANDT) is used, and not hard-coded client values.

A prerequisite for the reliable client check is the correct classification of the database tables in the dictionary. The corresponding checks are described in section Checking the Multiclient Compliance of Add-On Products.