When connecting to the Internet, you need to protect your system from unauthorized access and other intruders. Although we refer to the Internet throughout this discussion, Intranet applications may also require a certain degree of protection, depending on your security policy. The following information also applies to Intranets.

All security considerations require that you have a clear security concept. You cannot make any application absolutely secure. Instead you need to lay down the components of your application, then try to consider all possible threats (for example, unauthorized access and denial-of-service intrusions), define the severity of these consequences, and classify which are acceptable and which are not. You must have this concept in written form and refer to it for every security measure.

The SAP Internet architecture has many built-in security features, such as being able to run the WGate and AGate on separate hosts. This is important because the WGate usually contains no sensitive information. The AGate, however, may contain information like SAP System passwords which need to be protected.

We strongly recommend setting up a network infrastructure that makes use of these features to control access from the Internet to sensitive application components and internal networks.

To do this, you can make use of specific security components, such as firewalls, packet filters and SAProuters to separate the individual parts of the network from each other. This ensures that unauthorized access is restricted to a small part of the system and cannot harm your internal network and the SAP System. The following graphic shows some of the components that you can use to build a secure network architecture when using ITS:

• Firewalls separate network segments from each other. Here, the term firewall is used in the broadest possible sense. It can mean anything from a commercial firewall product to an IP router configured with filtering rules.
• Cryptographic methods can be used on the whole route between the Web browser and the SAP System to protect the data from corruption and eavesdropping.
• To improve performance and reduce the amount of data available in a system opened for Internet access, you can use a separate system (coupled using Application Link Enabling, ALE) for your Internet system, instead of your productive system.

You may decide to implement some or all of these components depending on your security policy. You can find details about the components and a concrete example of a network setup in the sections below.

Our recommended network topology consists of three separate network segments that are connected by two firewall systems. The least secure network is the Internet itself. This is where the Web browser is located.

The Web server is protected by the first firewall system The Web server must be protected against any kind of network packets that are not needed for HTTP communication. To accomplish this, configure the router to pass packets to the corresponding TCP port only.

Usually a Web server requires one TCP service. Port number 80 is reserved for HTTP and used by default by all servers and browsers. HTTPS (HTTP plus the Secure Sockets Layer protocol), uses TCP port number 443 by default.

Configure the Web server operating system to be as closed and restrictive as possible. Disable any unnecessary network services.

We strongly recommend taking additional measures to separate the Web server from your internal corporate network, such as using a firewall system and/or SAProuter. This prevents additional damage if an intruder manages to gain control of the Web server. We recommend keeping the AGate in your internal network.

The connection between WGate and AGate can be relayed by a SAProuter. For a detailed description of the SAProuter functionality and administration, see the SAP Library under BC SAProuter (BC Basis Components – Client Server Technology). You can configure the SAProuter to relay only the WGate–AGate connection and deny all other connection attempts. See SAP Online documentation ITS Administration Guide on how to configure ITS with SAProuter (BC–Basis ® Frontend Services ® Internet Transaction Server).

You can use other firewall products to relay the TCP connection from the WGate to the AGate. See the documentation for your firewall for further information.

The following graphic shows an example network security infrastructure suitable for Internet access to SAP using the SAP Internet Transaction Server:

The security of the network zones increases from left to right. The first router/packet filter allows direct access from the Internet to the Web server's TCP ports only. It never routes any packet directly to the second router, so no packets get directly from the Internet into the internal network. This is why the Web server network is called the demilitarized zone. The second router/packet filter is configured to deny any direct access from the Web server network to any host in the corporate network except for the SAProuter (TCP port and host). Therefore, the connection from the WGate to the AGate can only be transmitted through the SAProuter. In the example, the AGate is located in the SAP server network. The server network is connected to the client network through a router that may also provide access restriction.

If you want, and as mentioned in the previous section, you can also place a router/packet filter between the AGate and the SAP application server. This provides additional protection if an intruder manages to exploit any security hole of the AGate or the operating system it is running on.

In the above example, we have displayed a setup using standard network and computer components. Many vendors offer specialized firewall products for these tasks. You may use such products; however, we do not describe them in more detail here in this guide.

You can use cryptographic methods to increase the security of all network connections involved in an ITS application.

All data (including passwords) is usually transmitted through the Internet without being encrypted. To maintain confidentiality for this data, you can encrypt the connection between the Web server and browser. The SAP-supported Web servers and all modern browsers support the encryption of the HTTP data stream by using the Secure Sockets Layer protocol (SSL), also known as HTTPS. HTTPS data streams are completely transparent to the ITS. For more details regarding encryption techniques, see the documentation supplied by the Web server manufacturer.

To use SSL encryption, the Web server must obtain a certificate for its public key. This certificate is referred to in this section as the server certificate. It is used by the browser to authenticate the server, and is issued by a Certification Authority (CA). If the browser receives a server certificate issued by a trusted CA, then the browser can verify that it is connected to the intended server. This is the precondition for the secure connection to be established.

If you want to offer a service to all Internet users, this server certificate must have been issued by an official CA that is trusted by most browsers used in the Internet. For internal users, you can set up a corporate CA and configure the browsers to trust this CA.

By default, the data sent between WGate and the AGate is sent as clear text. You can choose a different connection type which encrypts the data with a DES algorithm using a static key. This key is not configurable; therefore, this encryption provides protection only against accidental reading of the data, but not against serious attacks.

The connection between AGate and SAP System can also be protected with SNC.

In the Internet scenario, you do not necessarily know which users want to access the application data in the SAP System. In addition, due to the large number of Internet users, you normally cannot set up a separate account for each user. Therefore, if you want to make certain Internet Application Components available to anonymous Internet users, you normally set up service users with predefined passwords in the SAP System. These users should have only the permissions necessary to access the application (for example, a product catalog). The corresponding ITS service is configured with this logon information to include the password. If you need to further authenticate the Internet user (for example, when an order is placed), the application itself must perform the additional authentication. (For example, the application verifies the customer number and password using corresponding function calls.)

For each application that is accessible over the Internet, you must create a service file, which is located on the AGate. This file contains information that is specific to the application (for example, the SAP transaction to start, the SAP client, the service user name and password to use). The ITS needs this information to run the application. The password does not appear as clear text in the service file, but is encrypted using a static key. Therefore, if you have service users with authorizations that are worth protecting, then take special care to protect the AGate service files from unauthorized access.

ITS does not store any security-relevant information on the WGate.

In an Intranet or Extranet scenario, users can log on to SAP over the ITS using their SAP user name and password. User names and passwords are not stored permanently in the ITS in this case. User authentication takes place entirely within the SAP System. Internet Application Components are subject to the usual SAP authorization concept, just like any other SAP transactions.

To maintain the integrity of the multi-step transactions when using IACs, the ITS issues a unique session ID number when the first request is made by the user. This session ID is sent to the browser with the first HTML page. It must be passed back to the ITS with every successive request. The session ID is used by the ITS to identify the correct session context. It also ensures that another user cannot easily take over a current session. If you need even stronger protection of user sessions, you can use HTTPS.

Old versions of ITS rely on HTTP cookies to store the session ID. In current ITS versions a cookie is needed only for user identification across multiple services. If you do not need this feature, you can disable the sending of cookies.

As an additional security feature, the ITS stores the client IP address along with the session ID. A possible eavesdropper, who listens in on the network connection and thus acquires the current session ID, cannot easily issue a fake reply. (Their IP address does not match that of the original user.)

You can configure the number of significant bytes used for the network address comparison. On the AGate, the following registry key specifies a mask of the significant network address bits:

The default value is 255.255.255.255, which specifies that the entire address should be compared. Enable this value for an Intranet solution. For Internet applications, we recommend entering a value of 255.255.0.0. In this case, only the leading figures of a network address are compared. This allows clients who use multiple Web proxy servers with load balancing to access the ITS.

Search engines are a valuable tool for every user of the Internet. They allow you to search a large portion of all existing Web pages for words or phrases to find some piece of information. In order to build their indexes, most search engines traverse the Web by following all links in all Web pages they find. A program that does this is called a "crawler", or more generally, a "robot". The crawling procedure is very effective, but there are some problems. If a link directs the robot into one of your Internet applications, the robot follows all links into the application. But since the information is dynamically generated, it is not suitable for inclusion in a static index. Also the robot's requests impose additional load on your server.

The Standard for Robot Exclusion (SRE) provides a method to exclude robots from certain parts or all of a servers resource space. There is no easy way to prevent a robot from disobeying this exclusion, but most robots adhere to the standard.