Securing and Hardening SAP HANA

Panelist: Matt Lonstine, Symmetry

Sponsor: Cybersecurity for SAP Customers

Digital transformation has changed nearly all aspects of the modern enterprise, but one fact remains the same: data is a company’s most valuable asset. Join this interactive Q&A to learn how SAP HANA has changed how we use data, and learn how to secure SAP HANA from the bottom up.

Read the transcript with Symmetry’s Matt Lonstine, a speaker at the upcoming SAPinsider Cybersecurity for SAP Customers, to dive into important questions.

Kendall Hatch: Hi everyone, welcome back to our Live Q&A on securing and hardening SAP HANA. We’re joined by Symmetry’s Matt Lonstine, who will be speaking on this topic at the upcoming Cybersecurity for SAP Customers event, running 27-29 June in Prague. We’re looking forward to today’s discussion. To register for the conference or learn more, click here.

We already have a few questions in the queue, so thanks to those who asked questions ahead of time. Now, I’ll turn it over to Matt. Thanks for joining us, Matt!

Matt Lonstine: Good morning all! My name is Matt Lonstine (Director of Delivery at Symmetry). I’m responsible for delivery of SAP technical managed services, with a specialty in SAP HANA, Cloud migrations, and SAP cybersecurity. Thanks to all of you for joining today, and I look forward to some good questions!

Comment From Amy Sy: Can you share some of the native apps-related security aspects and isolation levels to harden SAP HANA and SAP S/4HANA both

Matt Lonstine: Native applications (like those developed for and facilitated by the XSA) can be secured through a number of mechanisms like space isolation, and it’s recommended that application processes be segregated and separated through the use of separate OS level users (adm) using the most restrictive permissions possible. Obviously, deploying applications in SAP space should be avoided if secure isolation is the goal.

Comment From Wariis: I understand that building the same level of security features as in with on-premise architecture is not cost effective. In that case, how is cloud architecture proposed to clients demanding high data security.

Matt Lonstine: Deploying SAP HANA in a cloud environment shouldn’t mean compromising on security. In many cases, choosing the right cloud service provider can mean a more secure environment than many companies can provision in their own data center. CSPs can and should provide robust protection of SAP landscapes and SAP HANA through the entire technology stack. All of the same SAP HANA hardening techniques you would deploy in an on-prem scenario are applicable, from OS security, to auditing, to secure application design/access. If a CSP is telling you that compromise on security is inherent to their design, that’s a huge red flag.

Comment From Atul: What’s the performance impact for enabling data volume encryption?

Matt Lonstine: Encrypted data read from disk does need to be decrypted, and as is the case in any compute technology, that incurs some slight performance overhead. Keep in mind however, that data residing in memory is not encrypted, meaning no performance hit. My personal experience is that the effect of SAP HANA persistence layer encryption on performance is negligible, and the benefits far outweigh any concerns.

Comment From Adnan: What are some of the most commonly overlooked security considerations for SAP HANA?

Matt Lonstine: It really comes down to the basics. So many customers underestimate the importance of securing SAP HANA at the OS layer, and it all starts there with minimal package selection, and other considerations that are inherent to running any enterprise DB or app on Linux. I also see a lot of customers late to the game on persistence encryption. I should point out that it’s important to enable encryption immediately as part of implementation/deployment. Doing so after that fact means that you can’t fully guarantee full encryption of the persistence layer.

Comment From John: What is available in SAP HANA to help with GDPR compliance?

Matt Lonstine: The auditing suite in SAP HANA is an obvious and excellent way to approach GDPR compliance. The mechanisms and policies available can range from simplistic to very complex, and it’s important to understand the desired outcome at policy design time. Architect your policies with a focused approach (specific to that ways in which GDPR is relevant to your business). If auditing is deployed intelligently and in a concerted manner, a “less is more” strategy can make things less complex, and still pay dividends.

Comment From Colleen: Can SAP HANA persistence layer encryption be enabled at any time?

Matt Lonstine: Persistence layer encryption can be enabled at any time, but enabling it on an operational SAP HANA database (as opposed to at installation time) is not as effective in that there’s theoretically no way to ensure that the complete database will ever be encrypted, and no easy way to see to what extent that has occurred. That said, I still recommend it even for currently operational instances.

Comment From Frederic: What are some basic measures one can take to harden SAP HANA servers at the Linux level?

Matt Lonstine: Simple things like prohibiting root logon via SSH, modifying the default umask, and using a central syslog server to prevent log tampering can be quick wins. I also personally like to use tty auditing at the OS level in order to track user activity (even as users change identities and environments during a session). Some SAP HANA-certified distributions of Linux also deliver local SAP HANA-aware firewall implementations, and special security monitoring packages that are executed through cron.

Comment From Yolanda: How should OS level patching of SAP HANA servers be approached?

Matt Lonstine: It starts with Linux installation, and a minimal package footprint. Install nothing at the OS level that is not absolutely required to run and support SAP HANA. A minimal package surface area means fewer vulnerabilities and potential areas for concern. Use the distribution-specific patching utilities and notifications to stay on top of security patches, and deploy them in a regular cadence. The Linux kernel itself is frequently a big hitter in terms of OS level security patching.

Comment From Dillon: How can you activate tracing for security topics like authorization, authentication, and login?

Matt Lonstine: This is directly relevant to the SAP HANA audit suite which is disabled by default. To execute a specific SAP HANA audit trace, the auditing functionality needs to be turned on, which can be done through SAP HANA studio. You’ll also need the AUDIT ADMIN authorization.

Comment From Javier: What’s the best access rights model for SAP HANA?

Matt Lonstine: Decisions about access rights really come down to the way in which a SAP HANA system will be accessed based on the solution it supports. Will it be a back-end DB for a BI deployment that will require direct user access? Will it support XSA applications requiring access for both developers and end users? Or, will SAP HANA be used to support SAP NetWeaver-based systems where most of the direct DB access is proxied through sidadm, and Basis resources are typically the only ones active inside of SAP HANA. If the latter, the answer is that Basis and/or DBAs should have just enough access to do their jobs. Obviously, you want to avoid use of the SYSTEM user (which I still see happening frequently in the wild). If direct access scenarios are more complex, it requires a fulsome understanding of requirements, and how they can translated into the SAP HANA security model to achieve GRC and SoD objectives.

Comment From Nigel: Are there basic guidelines to consider when setting up SAP HANA audit policies?

Matt Lonstine: When setting up audit policies, avoid direct modifications of the SAP HANA .ini configuration files. I’ve seen a few blogs out there suggesting that this is the quickest means to an end. You can reduce performance impact by getting straight on your objectives, and creating the fewest possible policies to achieve them. Also, only audit DML actions if required as they have higher potential to impact performance.

Comment From Holly: Are there performance implications surrounding persistence layer encryption?

Matt Lonstine: This is a common question. When the SAP HANA persistence layer is encrypted, that data does need to be decrypted if read from disk and pulled into memory. That decryption process incurs resource overhead, but in most cases it should be almost transparent, and my personal experiences support that. Data that resides in memory (which is most) is un-encrypted and access to that incurs no performance impact at all.

Comment From Pradeep: Are there considerations around securing the XSA engine of SAP HANA?

Matt Lonstine: Securing the XSA (if used) is important, and requires an understanding of its underpinnings. Start with basics like reducing dependence on the XSA_ADMIN user, and grant required roles like XS_USER_ADMIN to alternative administrative users where possible. XSA security areas have different security management elements, and their relationship to pieces like the platform router need to be considered. I’ve referred many customers to note “2243019 – Providing SSL certificates for domains defined in SAP HANA extended application services, advanced model” as it relates to securing XSA communication.

Kendall Hatch: That about wraps up our time for today. Thanks to everyone who joined us today for your great questions. To learn more about the Cybersecurity for SAP Customers event this June in Prague, please click here. Thanks again to our expert Matt Lonstine for taking the time to join us today!

Matt Lonstine: Thanks for joining me today! I appreciate your questions and interest in the topic. If you are looking for additional information, or in-depth feedback that we didn’t cover here, please feel free to contact me at matt.lonstine@symmetrycorp.com.