## 10.6 Network Security
To integrate SAP HANA securely into your network environment, several general recommendations apply.
The components of an SAP HANA landscape communicate through different network communication channels. It is recommended security practice to have a well­defined network topology to control and limit network access to SAP HANA to only those communication channels needed for your scenario, and to apply appropriate additional security measures, such as encryption, where necessary. This can be achieved through different means, such as separate network zones and network firewalls, and through the configuration options provided by SAP HANA (for example, encryption). The exact setup depends on your environment, your implementation scenario, and your security requirements and policies.
The detailed network set-up and recommendations are described in network administration section of the SAP HANA Administration Guide . This section contains some additional security-relevant information.
##  Caution
It is strongly recommended that you apply the measures described in this section to protect access to the SAP HANA database's internal communication channels and to mitigate the risk of unauthorized access to these services.
## Network Zones
- We recommend that you operate the different components of the SAP HANA platform in separate network zones.
To prevent unauthorized access to the SAP HANA environment and the SAP HANA database through the network, use network firewall technology to create network zones for the different components and to restrictively filter the traffic between these zones implementing a "minimum required communication" approach. The relevant network zones depend on your specific application scenario and your network infrastructure. For more information about network zones, see the SAP HANA Administration Guide .
- We recommend that you operate SAP HANA in a protected data-center environment.Allow only dedicated authorized network traffic from other network zones (for example, user access from the client network zone) to follow these rules:
- Clients accessing external standard database functionality, for example by SQL, have only access to the database client access port.
- Clients (for example, browser applications) accessing the SAP HANA environment through the HTTP access feature of SAP HANA Extended Application Services, classic model (XS classic), for example SAP HANA UI Toolkit for Info Access, have only access to the SAP HANA XS ports.
- Some administrative functions (for example, starting and stopping the SAP HANA instance) have access to the administrative ports.
- XS classic exposes some administrative applications (for example, administration of Security Assertion Markup Language (SAML) for user authentication). We recommend using URL filtering (for example, reverse proxy) to control the exposure of different applications to different network zones.
## Internal Communication
Database internal communication channels are only used for the following:
- Communication within the database
- Communication between hosts in distributed (multiple-host) scenarios
- Communication between multiple sites in system replication (high-availability) scenarios
- Communication between the SAP HANA database and server components, such as extended storage (SAP HANA dynamic tiering)
Note the following network security considerations for single-host, multiple-host, and system replication (highavailability) scenarios.
## Single-Host Scenario
In a single-host scenario, access to the network ports for database internal communication from other network hosts is blocked by default. We recommend that you do not change this setting. The internal communication ports are bound to localhost .
##  Note
In single-host scenarios, the same communication channels are used for communication between the different processes on a single host, and the internal IP addresses/ports are by default bound to the localhost interface. Note that this does not apply to dynamic tiering. The dynamic tiering service is bound to all interfaces, although the internal communication between SAP HANA database and dynamic tiering uses the localhost interface.
## Multiple-Host Scenario
In a distributed scenario (that is, one instance of SAP HANA on multiple hosts), internal network communication takes place between the hosts at one site via internal. Certified SAP HANA hosts contain either dedicated or virtualized network interfaces that are configured as part of a private network using separate IP addresses and ports.
We recommend operating all hosts in a dedicated sub-network.
To prevent unauthorized access to the database via the internal communication channels in distributed systems, we recommend that you prevent access to these network channels and ports from outside the system. There are a number of ways to isolate internal network ports from the client network:
- Using the SAP HANA configuration option to route communication between the hosts of a distributed environment onto a specified network and binding those internal network services exclusively to the network interface ( recommended option )
For more information about configuring inter-service communication, see the SAP HANA Administration Guide.
##  Note
In system replication scenarios, you can use this feature in the presence of a secondary site. However, note that additional ports used for communication between primary and secondary sites are opened on the network interface. These ports need to be protected.
- Using operating system commands (for example, iptables ), and/or network device configuration
- Using network firewall functions to block access to internal ports in specific network zones
If your setup does not permit isolating internal network communication, consider using encryption to protect the internal communication. For more information, see the section on securing internal communication.
## System Replication Scenario
In a system replication scenario, you can protect the channels used in the following ways:
- Configuring SAP HANA to use exclusively a separate network dedicated to system replication for communication between primary and secondary site
- Configuring secure communication using the TLS/SSL protocol for encryption and mutual authentication between sites
- Specifying the IP addresses allowed to connect to system replication ports
## Additional Measures for Securing Internal Communication
We recommend that you protect internal communication further by applying additional mechanisms. This may include filtering access to the relevant ports and channels by firewalls, implementing network separation, or applying additional protection at the network level (for example, VPN, IPSec).
We recommend routing the connection between the sites over a special site-to-site high-speed network, which typically already implements security measures such as separation from other network access and encryption or authentication between sites. The details of security measures and additional network security measures needed will depend on your specific environment. For more information about network administration, see the SAP HANA Administration Guide
## SAP HANA Extended Application Services, Advanced Model
Security mechanisms are applied to protect the communication paths used by the SAP HANA XS advanced server infrastructure. SAP provides network topology recommendations to restrict access at the network level. For more information, see the section on SAP HANA XS advanced security.
## Data Replication Technologies
Additional network configurations may be required depending on the implemented data replication technology. For more information, see the section on security for SAP HANA replication technologies.
## Related Information
Secure Internal Communication [page 252]
Network Administration
Network Zones
Host Name Resolution for System Replication
Configuring SAP HANA Inter-Service Communication
Security for SAP HANA Extended Application Services, Advanced Model
Security for SAP HANA Replication Technologies