Security Measures for Multiple Client Operations
In general, users and authorizations can be maintained only by the provider, and not by customers.
When looking at the ways in which multiple client systems differ from single client systems, we need to ask ourselves how hackers can exploit the transactional interface of the SAP System. This involves the implicit and automatic restriction of all access to the customer's own client at the database interface. You cannot break this restriction by modifying elements of the user interfaces of mySAP.com solutions. This means that access to data in other clients can be prevented reliably at the transaction user interface level.
The next questions is how to guarantee security at the database level. The setup must make sure that a user logged on to the system can only call SAP transactions, and cannot access database or operating system services. This is not a problem specific to multiple clients, however, the risks are particularly high when competitors save their data in the same database. In a single client solution, you can also access customer data once you have managed to access the database or operating system level, however, when multiple customers exists, the split databases make this much more difficult. ASP customers must not have authorization to access the database and operating system level. The standardized programming interface ODBC (Open Database Connectivity) can be used to regulate access to databases. mySAP.com solutions already contain these security precautions as standard.
Only the provider may customize and develop programs. If customers still need to access the development or test systems, a detailed authorization concept must prevent them from assigning additional authorizations in the production system. Customers must also not have programming authorizations, otherwise they could program their own evaluations for the production system. For more information on options for securing multiple clients with regard to modifications and the import of additional program objects, see the section
Checking the Multiclient Compliance of Add-On Products.As in single client systems, no authorizations for Customizing and development must be assigned in production systems. This usually affects the provider's employees. Particularly critical are authorizations for debugging transactions and runtime analyses. Access to external commands and file systems must also be refused. For more information on the security of production systems, see the SAP Security Guide, which is available free of charge in the SAP Service Marketplace.
In an ASP environment, ASP customers will only require access to background jobs in very rare cases. However, if access is required, background authorizations must be restricted to the individual clients (authorization object S_ADMI_FCD). Spool authorizations must be defined so that each customer is assigned his or her printer only, to avoid spool requests being printed on the wrong printers by mistake. For a better overview of authorizations, the ASP should choose a suitable naming convention for printers, such as <client><ID>. In this way you can easily and reliably use the authorization object S_SPO_DEV to restrict access to those printers assigned to a particular client. As of Release 4.6B, the authorization also restricts the search help of a customer to his or her printers only.