ENHANCING SECURITY FOR SAP HANA IN THE CLOUD

Transcription

1 ENHANCING SECURITY FOR SAP HANA IN THE CLOUD A COLLABORATIVE SAP CO-INNOVATION LAB PROJECT WITH INTEL, VORMETRIC, AND VIRTUSTREAM Editors: Ashvin Kamaraju Sergio Pacheco-Sanchez September 2014 Version 1 White Paper SAP Co-Innovation Lab

2 Enhancing Security for SAP HANA in the Cloud 2 Acknowledgements This document is the work of a virtual project team at SAP Co- innovation Lab, whose members include: David Cruickshank (SAP SE), Tariq Ellahi (SAP), Roger Guedes (SAP), Mark Hourani (SAP), Heather Li (SAP), Kevin Liu* (SAP), Sergio Pacheco- Sanchez (SAP), Carmelo Ragusa (SAP), Jay Thoden van Velzen (SAP), Kathy Barboza (Intel Corporation), Todd Christ (Intel), Martin Guttmann (Intel), Bing Wang* (Intel), Ashvin Kamaraju* (Vormetric, Inc.), Sridharan Sudarsan (Vormetric), Carlos Wong (Vormetric), Michael Powell (Virtustream Inc.), Gregsie Leighton (Virtustream), Vince Lubsey* (Virtustream), Pete Nicoletti (Virtustream), and many colleagues from the participating companies who helped with this project. * project lead from each participating company

3 Enhancing Security for SAP HANA in the Cloud 3 1 Executive Summary With corporate and government data breaches in daily headlines, it is no longer sufficient to secure just the perimeter of data centers. Data, which is the most important asset of every enterprise, must be secured using a combination of access controls, mature key management, and encryption. This is even more pertinent when such data is stored in the cloud, where others are managing the customers systems and may have access to client data. However, the overhead of encrypting data often leads to tradeoffs between performance and security. Thanks to recent innovations in hardware to accelerate encryption at the processor level, such tradeoffs are no longer necessary. Intel introduced a set of six instructions, called AES- NI (Advanced Encryption Standard New Instructions) in its Xeon E7 processor family. These instructions accelerate encryption using the AES algorithms, thereby reducing the performance overhead associated with encryption. Since the introduction of AES- NI, Intel has been improving the AES- NI performance with better pipelining and other optimizations in its Xeon E7 V2 and Xeon E5 V3 processor family. Vormetric, a leader in encryption software, has been working closely with Intel to exploit the AES- NI hardware acceleration with a new multi- threaded encryption engine. This has led to significant performance breakthroughs for a variety of enterprise workloads required for mission- critical applications. The SAP HANA platform, which is used by enterprises both for transactional data operations as well as for real- time analytics, delivers high- performance throughput as well as low latency. SAP HANA stores and processes sensitive enterprise data that must be secured in order to meet industry- specific regulatory requirements, as well as offering real security in an age of porous perimeters. With SAP HANA deployed in the cloud and offered as a service, cloud security, especially data security, becomes even more important. With the recent AES- NI innovations in the Intel Xeon processor family and the Vormetric encryption software enhancements optimally exploiting AES NI, large data sets on SAP HANA can be encrypted or decrypted with virtually no performance overhead. SAP Co- innovation Lab has shown through a series of tests that we can: Secure customers data using a combination of access controls and encryption Lock cloud administrators out of access to the data without impeding their ability to perform administrative tasks (and even applying to root accounts) Leave the owner of the data in full control of the encryption keys

4 Enhancing Security for SAP HANA in the Cloud 4 Table of Contents 1 Executive Summary Introduction Project scope SAP HANA Vormetric Technology Performance Evaluation System Landscape System configurations Software configurations Experimentation Plan Performance Evaluation Results and Analysis OLTP-Bench workload SAP-OLTP workload SAP-OLAP workload Summary References... 19

5 Enhancing Security for SAP HANA in the Cloud 5 2 Introduction With several powerful trends playing out in the industry real- time data analytics, cloud computing, increasing regulatory requirements for data protection, and a daily stream of news of security breaches security becomes the catalyst for migrating enterprise workloads to the cloud. Many companies are using, or planning to perform, sophisticated predictive and prescriptive analytics on all their data using SAP HANA (Intel Real- Time Business Intelligence, 2014). Achieving full value from SAP HANA requires integrating and analyzing core business data, which typically includes both sensitive customer information as well as an enterprise s intellectual property. Data must be secured using encryption and access control in order to comply with regulatory requirements and to protect against data breaches. Security is even more important when hosting sensitive data in the cloud, in a service provider s data center. There is an inherent loss of control when using a cloud hosting provider as suddenly, others are administering the customers technology landscapes. While a partner relationship implies trust, this does not necessarily protect a customer against rogue employees at the cloud hosting provider. Nor does a trusted partner relationship protect against state actors who might compel such providers to hand over data, potentially even preventing them from informing the customer. We can dramatically increase the trust levels between cloud hosting providers and their customers if we can demonstrate that: Any cloud administrator managing customers applications and cloud infrastructure does not have access to customers sensitive data Such data is encrypted on disk with the customer as the owner of the data holding the encryption keys To address potential performance impact associated with data protection of large data sets and enterprise workloads on SAP HANA, SAP, Vormetric, Intel, and Virtustream collaborated at SAP Co- innovation Lab to address the following: 1. Secure SAP HANA data and log volumes using Vormetric Transparent Encryption and Data Security Manager technologies 2. Quantify the performance overhead required for the data encryption solution for SAP HANA The results derived of this project have demonstrated: Robust security enabling customers to become the custodians of their encryption keys Effective enablement of data- access control policies Minimal performance overhead required to encrypt large data sets for solutions running on SAP HANA Vormetric solutions not only complement cloud security best practices, but also provide security for the enterprise customers data, and help customers comply with regulatory requirements. Figure 1 illustrates a deployment model where the Vormetric Data Security Manager (DSM) resides on the customer s premises while the SAP HANA database and the related server and storage infrastructure resides in the data center of a service provider such as Virtustream. The DSM is used by the customer to define the policies that govern access to the SAP HANA database and encryption of data sets in SAP HANA. Because the DSM resides on the customer s premise, the customer becomes the custodian of the policies and encryption keys, and only the customer s security administrators are authorized to define the polices and the encryption keys used in these policies. The service provider s operational personnel can provision the necessary infrastructure and update all relevant software, but will

6 Enhancing Security for SAP HANA in the Cloud 6 not have access to the data. This separation of duties, which allows the customer to be the custodian of encryption keys, enhances the security of SAP HANA when it is deployed in the cloud. Figure 1. Vormetric Security Solution for SAP HANA in the cloud 2.1 Project scope The scope of this project executed by teams across SAP, Vormetric, Intel, and Virtustream at SAP Co- innovation Lab and SAP facilities has focused on: 1. Installation and configuration of Vormetric Data Security Transparent Encryption on SAP HANA database servers 2. Management of the Vormetric Data Security Manager by creating encryption keys and necessary security policies that define encryption settings and access to user s data 3. Measuring the performance overhead of the system while the Vormetric Data Security Transparent Encryption solution is enabled for a defined set of workloads The aforementioned performance overhead investigation accounts for two generations of the Intel Xeon Processor E product family.

7 Enhancing Security for SAP HANA in the Cloud 7 3 SAP HANA High- speed data analytics is changing the way companies compete, enabling them to generate real- time insights to support their most important business processes. The SAP HANA platform is a clear leader in this arena, providing not just a uniquely fast and adaptable platform for real- time business, but as well to ultimately coexist and integrate with other cloud technologies. Cloud computing provides game- changing capabilities for business computing. Yet many companies have been reluctant to deploy mission- critical applications such as SAP HANA in cloud environments. Customers today recognize the potential benefits and want nothing more than to run all applications from the cloud; yet they all have unique requirements regarding security and compliance. Virtustream answers those security and compliance concerns with a global cloud infrastructure designed specifically for hosting mission- critical workloads. Now Virtustream is taking cloud security to even higher levels by integrating Vormetric Data Security into its cloud infrastructure and utilizing a variety of security technologies that are built into the latest Intel Xeon processor E7 V2 family. Intel, Vormetric, Virtustream, and SAP have been working together in SAP Co- Innovation Lab to integrate and test this solution. With this enhanced security architecture, customers can implement even stronger data encryption and more granular access controls for SAP HANA. Most important, customers retain complete control over their data in this enhanced cloud environment. And with SAP HANA running on the latest Intel Xeon processor E7 V2 family, customers can experience real- time performance across very large data sets up to three times larger than could be supported using previous- generation platforms such as the ones configured with Xeon E7 family.

8 Enhancing Security for SAP HANA in the Cloud 8 4 Vormetric Technology Overview: The Vormetric Data Security solution consists of two distinct components that work in tandem: Vormetric Data Security Manager (DSM), which is used by the security administrator(s) to define policies rules and encryption keys for each of the data servers where access to the data must be controlled and the data must be encrypted Transparent encryption, which resides on the data server and provides access control and encryption/decryption of data based on the policies defined by the security administrator The Vormetric DSM and the Transparent Encryption agent communicate with each other using secure communication protocols such as the Transport Layer Security (TLS). Both are certified for data security standards such as FIPS Vormetric Data Security transparent encryption exploits Intel Xeon Processor product family security features such as AES- NI to minimize the performance overhead associated with encryption. Privileged users *$^!@#)( - _}?$%- :>> Encrypted and controlled Clear Text Approved processes and users John Smith 401 Main Street Cloud provider Infrastructure and storage admins Figure 2. Vormetric security solution functionality Encrypted and controlled *$^!@#)( - _}?$%- :>> Figure 2. Vormetric security solution functionality Figure 2 illustrates the location of the transparent encryption component within the operating system stack at the data server. The transparent encryption software is an operating system level product that layers above the native file system, for example, EXT3 on SuSe Linux SLES 11, and intercepts all system calls related to file I/O and the file system. The policies defined by the security administrator are applied to each of the I/O access system calls to determine whether the data must be encrypted (write), decrypted (read), and whether access to the data must be allowed or denied. The transparent encryption software is a secure file system, with the exception that it does not

9 Enhancing Security for SAP HANA in the Cloud 9 have a disk layout of its own. It creates an overlay mount on the underlying file system. This overlay mount is called a guard point. A guard point can also be created on raw or logical volumes (similar to file systems). However, guard points on raw volumes are not used in the case of SAP HANA. Another important feature of the transparent encryption is its ability to prevent data access by privileged users. As illustrated in Figure 2, privileged users such as root user or other system administrators with privileged access can be denied access to the data. Denying privileged users access to the data is defined in a policy by the security administrator, using the DSM. The policy, which is made available to the transparent encryption software, is evaluated and enforced by the transparent encryption software running on a data server. Only authorized applications and authorized users can access the data. Vormetric Transparent Encryption secures SAP HANA data located in both the data and log volumes. Access to data sets in SAP HANA is enforced according to the security policies defined by the security administrator using the DSM. The DSM, with centralized key management and other important security administration features, provides separation of duties and enforces the security of the SAP HANA database regardless of whether SAP HANA is deployed in the cloud or in the enterprise.

10 Enhancing Security for SAP HANA in the Cloud 10 5 Performance Evaluation For performance evaluation purposes, we have chosen a set of representative application workloads running on SAP HANA. The following workloads have been selected: OLTP- Bench: This is a database management system (DBMS) test- bed framework for online transaction processing (OLTP) and Web- based workloads (OLTP- Bench, 2014). From the variety of tests available, we have chosen the TPC- C alike workload. This workload simulates an order- entry system environment where a population of users executes transactions against a database. There is a mix of five different types of transactions executing concurrently. Clearly, the throughput is measured in transactions per minute. In summary, this workload represents the activity of any industry that must manage, sell, or distribute a product or a service. SAP- OLTP: This is an SAP internal transactional workload representative of a sales and distribution scenario in the SAP ERP application. SAP- OLTP includes standard business transactions, as it essentially depicts the execution of a general sales cycle in an SAP system that refers to the creation of a sales order document followed by delivery and billing. The workload encompasses six transaction types: One transaction displays all sales orders relating to a particular customer or material. Another transaction creates a sales order. Another transaction displays a sales order given an order number. Another transaction creates a billing document, that is, sales invoice. Another transaction creates an outbound delivery with order reference number. Finally, another transaction changes the outbound delivery and posts goods issue. In general, workloads on SAP ERP include a large set of transaction types arranged in workflow sequences. SAP- OLTP throughput is typically measured in dialog steps per second, frequently normalized to hours. Dialog steps, that is, requests, are the basic units of work in SAP ERP that are served within work processes (enterprise resource planning, or ERP, software threads) non- preemptively. SAP- OLAP: This is a SAP internal online analytical processing (OLAP) workload customized for SAP systems. It is known that the OLAP data set is entirely loaded into memory before the execution of the system workload; thereafter, all operations are executed in- memory where no encryption/decryption is conducted. This fact clearly obviates the need to account for this workload into this work. However, aiming for performance evaluation completeness that encompasses both OLTP and OLAP worlds, we are showing experimental results that demonstrate no encryption overhead.

11 Enhancing Security for SAP HANA in the Cloud 11 6 System Landscape 6.1 System configurations Table 1 reflects the system configurations that are relevant for setting our joint activities: Memory Storage Processor Cores 1TB 800GB (Intel SSD 910 Series PCIe 2.0 x8 Flash card) Intel Xeon E socket, GHz 800GB 1TB (Intel SSD 910 Series PCIe 2.0 x8 Flash card) Table 1. System configurations Intel Xeon E V2 4 socket, GHz NOTE: An additional server was used to act as the client system that executes the testing against the server running SAP HANA. The same client system has been consistently used for all the experiments. 6.2 Software configurations Table 2 shows the details of the software components used on the SAP HANA database servers: Software Component Description Version Operating system SuSe Linux Enterprise Server SLES 11 SP3 File system Ext3. File system storing SAP HANA data and log volumes Not applicable SAP HANA SAP HANA support package SPS 06 revision 63 1 stack (SPS) Stand- alone deployment Table 2. Software configurations The Vormetric Transparent Encryption software encrypted the SAP HANA data and log volumes using the American Encryption Standard (AES) algorithm. The symmetric key used for encryption had a key size of 256 bits. This key size (also known as key strength) provides the strongest level of security. 1 The SAP HANA revision used for conducting SAP-OLTP experimentation is The reason behind this decision is that the SAP-OLTP application used is shipped for SAP HANA The rest of the experimental plan has been executed while using the aforementioned SAP HANA revision 63.

12 Enhancing Security for SAP HANA in the Cloud 12 7 Experimentation Plan Table 3 accounts for the detailed system configurations and workloads while enabling/disabling the Vormetric encryption solution for the Intel Xeon Processor E and E v2 product family. Batch ID Experiment ID Performance Evaluation Without Encryption 1 2 CPU platform Encryption Workload Data set size (GB) Hyper- Threading CPU utilization 1 Intel Xeon E OLTP- Bench 365 OFF Entry midrange 2 Intel Xeon E OLTP- Bench 182 OFF Entry midrange 3 Intel Xeon E SAP- OLTP 4 OFF Midrange 4 Intel Xeon E NO SAP- OLTP 4 OFF High 5 Intel Xeon E SAP- OLTP 4 ON Midrange 6 Intel Xeon E SAP- OLTP 4 ON High 7 Intel Xeon E SAP- OLAP 21 ON High 8 Intel Xeon E V2 OLTP- Bench 365 OFF Entry midrange 9 Intel Xeon E V2 OLTP- Bench 182 OFF Entry midrange 10 Intel Xeon E V2 SAP- OLTP 4 OFF Midrange NO 11 Intel Xeon E V2 SAP- OLTP 4 OFF High 12 Intel Xeon E V2 SAP- OLTP 4 ON Midrange 13 Intel Xeon E V2 SAP- OLTP 4 ON High Performance Evaluation with Vormetric Solution 3 14 Intel Xeon E OLTP- Bench 365 OFF Entry midrange 15 Intel Xeon E OLTP- Bench 182 OFF Entry midrange 16 Intel Xeon E SAP- OLTP 4 OFF Midrange 17 Intel Xeon E YES SAP- OLTP 4 OFF High 18 Intel Xeon E SAP- OLTP 4 ON Midrange 19 Intel Xeon E SAP- OLTP 4 ON High 20 Intel Xeon E SAP- OLAP 21 ON High 4 21 Intel Xeon E V2 OLTP- Bench 365 OFF Entry midrange 22 Intel Xeon E V2 OLTP- Bench 182 OFF Entry midrange 23 Intel Xeon E V2 SAP- OLTP 4 OFF Midrange YES 24 Intel Xeon E V2 SAP- OLTP 4 OFF High 25 Intel Xeon E V2 SAP- OLTP 4 ON Midrange 26 Intel Xeon E V2 SAP- OLTP 4 ON High Table 3. Experimental Plan

13 Enhancing Security for SAP HANA in the Cloud 13 The experimentation plan shown in the table above encompasses 4 batches of experiments, which in total account for 26 experiments, replicated at least 3 times. Clearly, experiment batches with ID 1 and 2 represent the experimental baseline whose results will be compared against the cases when system encryption is enabled. Note that SAP- OLAP is accounted for to accomplish a complete performance evaluation of both OLTP and OLAP schemes as discussed above in section 5; the experiments conducted for this purpose are experiments with ID 7 and 20. In total, OLTP- Bench is used in 8 system configurations, whereas SAP- OLTP is accounted for in 16 system configurations. The former considers 2 large data sets that are in the order of hundreds of gigabytes that drive CPU utilization of up 40% of usage, which can be classified as entry midrange system usage. The latter accounts for smaller data sets; however, it drives CPU utilization to midrange levels, 60% to 89%, and high usage levels, above 90%. Given the fact that only midrange system usage has been achieved by completing OLTP- Bench, it has been thought to enable the CPU Hyper- Threading (HT) feature only for higher- CPU utilization scenarios. This means that the HT feature has been enabled for SAP- OLTP workloads only as it drives CPU usage higher than OLTP- Bench, thus yielding system usage scenarios where the impact of HT is likely to be more visible. In summary, the workload variety used in this work exemplifies a real- world representative approach for stressing the system as a whole under different system load levels and data- set sizes.

14 Enhancing Security for SAP HANA in the Cloud 14 8 Performance Evaluation Results and Analysis 8.1 OLTP-Bench workload The evaluation methodology for this workload indicates to include the ramp- up and ramp- down phases. The former represents the system warm- up that eliminates the initialization overheads from system measurements. After the ramp- up, the system enters the steady- state phase, the one that is accounted for performance analysis; as the name suggests, during this phase the transactional throughput stabilizes. Thereafter, in the ramp- down phase, users progressively stop to send requests to the database server. Both the ramp- up and ramp- down phases each last for 20 minutes, and the workload steady- state phase is configured to last for two hours. Figure 3 depicts the performance overhead of encryption for the eight system configurations determined according to section 7. The plot shows the performance degradation, with respect to the baseline, in terms of throughput loss, quantified in transactions per minute, when encryption is enabled on the two different Intel hardware platforms while using two different data- set sizes. The throughput measurements are normalized by the throughput given by the E system baseline and data- set size of 182GB. 2-1% Normalized Throughput % - 7.4% 0% Baseline- 182GB Encrypwon- 182GB Baseline - 365GB Encrypwon- 365GB 0 Xeon E Intel Xeon Processors Xeon E V2 Figure 3. OLTP-Bench throughput We learn from Figure 3 above that for the same data- set sizes, the E V2 processor outperforms the E by approximately 75%. Moreover, when the data- set size is doubled, the E encrypted system is taxed only an additional 0.4%. In contrast, the E V2 system shows no encryption overhead while using the 182GB data set, and the encryption overhead is only 1% with the 365GB data set.

15 Enhancing Security for SAP HANA in the Cloud SAP-OLTP workload As previously described, SAP- OLTP is an internal transactional workload that encompasses standard business transactions. In our experiments, the workload placed on the system is equivalent to that generated by 40,000 users accessing the SAP HANA database for various ERP functions. Similar to the evaluation methodology of previous workload, testing this application also encompasses the ramp- up and ramp- down phases. In the ramp- up phase, all users log on one after another, and the number of concurrently working users is increased until reaching the 40,000 th user. The experimental run continues with the high load phase, that is, steady phase, which is the actual interval considered for performance analysis. This is very important because before entering the high load phase, it is necessary that the system has the buffers and cache already filled; this allows using representative measurements. In the ramp- down phase, all users log off one after another. Both the ramp- up and ramp- down phases last each for 10 minutes, and the workload high load phase is configured to last for 30 minutes. We have confirmed through a sensitivity analysis that a 30- minute period is representative of a phase with stable transactional throughput. That is, similar measurements would be obtained when running experiments for longer periods of time. Figure 4 depicts the performance overhead of encryption for 4 out of the 16 different system configurations defined according to section 7. The plot shows the performance degradation, with respect to the baseline, in terms of throughput loss when encryption is enabled on the two Intel hardware platforms evaluated. The throughput measurements are normalized by the throughput given by the E system baseline. We have chosen the system configurations of high CPU utilization when no HT is enabled. That is, in order to summarize the presentation of the experimental results, we show only the results of the four system configurations that stress the system the most. For instance the CPU utilization of the Intel Xeon E systems has been approximately 97%, whereas the same measurements for the Intel Xeon E V2 systems have been slightly lower, about 92% % Normalized Throughput % Baseline Encrypwon 0 Xeon E Xeon E V2 Intel Xeon Processors Figure 4. SAP-OLTP throughput We learn from Figure 4 above that when comparing the baselines, the E V2 system delivers an additional 126% of throughput compared to the E system. Regarding the performance overhead, when encryption is enabled

16 Enhancing Security for SAP HANA in the Cloud 16 compared to the baseline, the E system suffers a slight (negligible) throughput degradation of about 1.2%. In contrast, the E V2 system delivers consistently along all experiment replications a throughput that is slightly higher by approximately 5%. We surmise that this counterintuitive behavior of slightly higher throughput stems from the fact that Intel has made significant enhancements (pipelining) to the AES- NI instructions in the Intel Xeon E V2 processor family. Vormetric encryption software takes advantage of these enhancements in order to deliver faster encryption processing times. In addition, Vormetric encryption software parallelizes I/O requests into multiple encryption/decryption threads, which in effect leverages the multiple processor cores in the system more optimally. Together, these hardware and software enhancements result in very low overhead and consequently greater system performance. It is important to highlight that this counterintuitive behavior is observed only on the newer Intel Xeon E V2 based systems. Actually, during OLTP- Bench experimentation, a similar behavior has been observed while using the 182GB data set. Only until the data set of 365GB is used has this anomalous system behavior stopped, and we actually observed a transactional throughput loss of approximately 1% with encryption on. Clearly, this substantial increase in data- set size entails a system load increase. Based on these results, we could hypothesize that as the data- set size increases, the more likely that we continue observing a progressive performance degradation trend. In summary, the hypothesis formulated behind this counterintuitive behavior is that, given the fact that more resources are available on the Xeon E V2 platform, the Vormetric software is able to increase the parallelization of the encryption/decryption operations. This parallelization effort, which is witnessed by a significant increase in the system- context switching activity, seems to induce higher throughput related to a combination of factors. These factors include, as a possibility, better data locality and not a fine- tuned multi- threading level, which exceeds to a point for not only hiding the latencies, but also for delivering slightly higher transactional processing capability. In addition, Figure 5 illustrates the encryption performance improvements of the Intel Xeon E V2 processor versus the E CPU by showing memory- speed test results, quantified in megabytes per second, for different memory buffer sizes. Figure 5. Comparison of encryption performance: Xeon E7 vs. Xeon E7 V2 processor family

17 Enhancing Security for SAP HANA in the Cloud 17 The memory- speed tests were conducted by using Vormetric Transparent Encryption software that encrypts data in memory buffers of varying size. That is, there was no I/O related to storage accesses. These tests were conducted to measure the AES- NI related enhancements in the Xeon E7 V2 family of processors together with the code optimization in Vormetric encryption to increase the pipelining of the AES rounds. The results have demonstrated that the pure cost of encryption was significantly lower on the Xeon E7 V2 family of processors. Clearly, these enhancements could further explain the fact that the parallelization achieved with the Vormetric encryption engine could lead to better performance than the baseline for the same workload. 8.3 SAP-OLAP workload SAP has defined T- shirt sizes for SAP HANA appliances. These T- shirt sizes are based on the compressed data- set sizes that can be loaded into memory for processing. Sizing recommendations state that 50% of the system memory should be used for storing data, whereas the other 50% should be used for intermediate results, temporary data objects, and so on. Keeping these sizing guidelines in mind, the 1TB server should be able to hold 512GB of compressed data. In other words, in order to process 512GB of compressed data, 1TB of memory is required. The evaluation methodology for this workload indicates to warm up the system before the actual experimentation stage; the warm- up phase preloads the data set into memory. This implies that the data read from persistent storage is decrypted prior to caching it into memory. Therefore, there is no encryption or decryption of data associated to query answering during the execution of the experiments that take place after the warm- up phase. While this important point is well understood, and obviated the need for taking into account this workload, we decided to prove our hypothesis by setting a simple set of experiments. This has entailed using a data set smaller than 512GB; thus we have set the data- set size to 21GB, as shown above in section 7. Similar to the experimentation using the other two workloads, we have configured the system to hold both data and log volumes on the Intel SSD PCIe Flash card. However, even if both volumes had been placed on a slower device such as mechanical media, it would not affect the performance shown in Figure 6 below, except during the data- loading phase (loading from persistence to memory), which is not accounted for in this experiment. In our test bed, we have 100 users running on the client hardware sending queries to the server. In total, during each experimental run, 18,000 queries are sent to the server, which on average take about 49 minutes to execute. The SAP- OLAP experimentation showed that there is no overhead on the system when encryption is enabled. The system is actually saturated at approximately 97% of CPU usage, on average. It is also important to highlight that I/O activity is nonexistent at about 36 I/O operations per second (IOPS), on average. In contrast, during the execution of SAP- OLTP and OLTP- Bench, the system delivered approximately 10,000 IOPS on average, showing spikes of up to 19,000 IOPS. Figure 6 depicts system throughput, in terms of queries per hour, of both the baseline and the encryption experimental runs. The throughput measurements are normalized by the values of the baseline.

18 Enhancing Security for SAP HANA in the Cloud Normalized Throughput Baseline Encrypwon Experiment ReplicaQons Figure 6. SAP-OLAP throughput We can observe that, for the 16 replications of the experiment (that encompass baseline and encryption), the difference in throughput between the baseline and encrypted systems is minimal at 0.96%. This difference is a minor variance, possibly introduced by factors other than encryption. In the long run, on average, the system throughput of both the baseline and the encryption will converge.

19 Enhancing Security for SAP HANA in the Cloud 19 9 Summary Installing and configuring the SAP HANA application, the Vormetric Data Security appliance, and the physical SAP HANA database servers has been procedural and straightforward. Most of the project effort has been focused on measuring the performance overhead of encryption on the two Intel hardware platforms evaluated, namely the Intel Xeon E processor and the Intel Xeon E V2 processor. We have measured an encryption overhead of a single digit, overall. In particular, the experimentation on the Intel Xeon E platform shows an overhead of less than 8% while processing transactional workloads. In contrast, experimentation under transactional workloads on the Intel Xeon E V2 platform reveals a negligible performance overhead. However, we surmise that the counterintuitive behavior found in some system configurations might be attributed to the parallelization effort of Vormetric software running on the Intel Xeon E V2 platform. Evidence of this degree of parallelization is the increased context switching activity on encrypted systems, as it surges up to a 25% with respect to the baseline reference system. We also have provided results of testing that no performance overhead is placed on the system processing analytical workloads when encryption is enabled. We plan to evaluate the high- availability features of the Vormetric security software in combination with the scale- out deployment of SAP HANA. We also aim to evaluate the operational impact of the data transformation methods of Vormetric software as the size of data sets in data centers significantly increases. 10 References SAP Web site, (2014) Retrieved from: Vormetric Web site, (2014) Retrieved from: Intel Web site, (2014) Retrieved from: Intel Real-Time Business Intelligence. (2014). Intel white paper on Security in the Cloud for SAP HANA [White paper]. Retrieved from Virtustream Web site, (2014) Retrieved from: OLTP-Bench Web site, (2014) Retrieved from: Copyright/Trademark

20 Copyright 2014 SAP SE or an SAP SE affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE and its affiliated companies ( SAP SE Group ) for informational purposes only, without representation or warranty of any kind, and SAP SE Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP SE and other SAP SE products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries. Please see for additional trademark information and notices.