Rapid data center and infrastructure advancements have created endless new opportunities – especially for those who are now live on SAP HANA or SAP S/4HANA. However, now that you’re live, how do you protect your investment? Are you automating OS patch deployment and compliance across your SAP landscape? Are you looking to decrease total cost of ownership while securing enterprise systems and improving compliance and service quality?
Read the transcript of the chat with experts from Hitachi and SUSE on security best practices for your SAP HANA environment after go-live with SAP HANA. They answered questions on automated software, patch and configuration management, system monitoring capabilities, and more, including:
Meet the panelists:
Jason Delaune, SAP Solution Lead – America’s Solutions & Products Group, Hitachi
Jason has been working at Hitachi since September 2014. In his current role, he is responsible for helping customers with their digital transformation journey from classic SAP systems based on traditional RDBMS platforms to those based on SAP HANA.
José Betancourt, Senior Architect, SUSE
José Betancourt is a Sr. Architect with SUSE’s world-wide alliances organization where he works with global OEM partners to understand their business and technical requirements and make them successful with SUSE.
José has over 26 years of total experience with 15 of them as the actual ‘IT customer’ in the telecom and pharmaceutical environments.
If you haven't already, subscribe to SAPinsider Online for free today!
Matthew Shea: Welcome to today’s live Q&A on best practices for protecting your SAP HANA environment. I am very pleased to be joined by Jason Delaune, SAP Solution Lead – America’s Solutions & Products Group, Hitachi, and José Betancourt, Senior Architect, SUSE.
Matthew Shea: Thank you for joining us today Jason and José!
Jason Delaune: Thanks for having us!
Jose Betancourt: Thanks Matt.
Comment from Frank: What's delivered with SLES for SAP for Highly-available configurations?
Jose Betancourt: The SUSE Linux Enterprise Server for SAP applications product provides the High-Availability (HA) Extension as part of the product itself. Equally important though is the availability of the HANA resource agents to facilitate the configuration of HANA in an HA scenario. We provide the resource agent to configure three scale-up scenarios (performance, cost, and multi-tier), and the topology resource agent to gather information and status of all the members of the cluster
Comment From ruairi : Hello, this maybe off-topic, but we are interested in Cyber security for our HANA environment and the steps we can take to secure our environment. Can you shed some light on developments in this area? Thank you
There is a lot of good info in the SAP HANA Security Guide on the initial steps you should take when receiving your HANA hardware from your vendor. The guide then covers a lot of other areas that Security & Basis personnel should review to properly secure the HANA instance. So, I would give that document a look.
As far as new developments in the cyber-security arena, check out the following link:
It has a lot of useful information from SAP around securing HANA, and the site links to some of the new content resources available from SAP.
Comment From Guest: Does SAP HANA support data encryption?
Yes, HANA 1.0 supports data volume encryption ... I believe as of SPS 08. With HANA 2.0, administrators can now enable redo log encryption.
Comment From Sean: Are live patches only applicable to memory, or to disk as well?
When using the SUSE Linux live patching extension, you have the option of applying the live patch to just memory (in which case the system will have to be patched again after reboot), or to both memory and disk. It really depends on how you want to apply the live patch.
Comment From Josh: Where can one find good information about setting up and managing users for XSA applications
Here are a couple of links to help get you going:
Comment From Dennis: Can you provide HA protection in an SAP HANA Multitenant DB Containers scenario?
Yes, HA protection is available with a multi-tenant database container scenario. It can handle performance or cost-optimized fail-over scenarios. The way it work is via a take-over of the parent HANA database. Another item to take into account is that all tenant db containers and associated services are impacted by the take-over/migration.
Comment From Calvin: How can Hitachi support data encryption with SAP HANA?
So, HANA encryption by itself can protect both the data areas and the redo log areas (if using HANA 2.0); however, database traces and backups are not encrypted on disk (unless you have 3rd party backup software that encrypts the backup). So, this can lead to security vulnerabilities if someone were to get access to the server or storage array.
With Hitachi arrays, we offer the ability to encrypt the entire array. Each controller, disk, and back-end director (BED) has a key, so this increases security should one or more of these components finds their way into the wrong hands.
Also, there's no overhead on the controllers of the array, so performance is comparable to that of an unencrypted array. With HANA encryption, there is a performance penalty with reads / writes while the data is unencrypted / encrypted. However, the data is fully unencrypted in memory, so there's no performance impact during normal in-memory operations.
Comment From Abby: What impacts do multi-tenant database containers (MDC) have on my security approach?
For specifics on security and tenant databases on SAP HANA, I would refer to the "SAP HANA Tenant Databases Operations Guide". There is a security and tenant databases section that should assist. The link is: https://help.sap.com/viewer/78209c1d3a9b41cd8624338e42a12bf6/2.0.01/en-US
Comment From Hernando: On Windows platforms there is also high availability as in SuSE Linux?
I assume you're referring to the SAP app tier since HANA can't run on Windows. With the app tier running on Windows, yes, you can establish a MSCS cluster to protect the PAS / CI. This offers the capability to do an active / passive or active / active cluster for your application tier.
Comment From JON: How can I roll-back a system patch that it's not working 'as advertised'?
OS (SUSE) patches can be rolled-back thank to the implementation of the BTRFS filesystem and the snapper utility. In essence, executing a patch update triggers the generation of a 'snapshot' for the OS. Should the patch have a negative impact on the system, you can reboot the server (and since you're using SLES for SAP, you failed-over the application beforehand) and select the prior snapshot as your kernel to boot. As with all OS operations, I strongly recommend learning about BTRFS by trying it out first on a dev system or even on a virtual machine.
Comment From Drew: What are your best practices for SAP HANA database passwords?
I would certainly follow your corporate guidelines on password policies - minimum number of characters, upper / lower case, number, special characters, etc.
You can then configure both the SAP application tier and the HANA tier to adhere to the corporate policy, and it will make your life much easier come audit time!
Comment From Mo: What is an industry best practice for the use of FFight Accounts in HANA? -- and what is the BP for elevated developer activities?
I don't believe HANA has the concept of Firefighter accounts as the application does. So, you may need to develop a corporate policy / best practice around this. You could setup the privileged account and then disable it. Within HANA, setup access logging to monitor on disabling / enabling accounts, and then be prepared to justify why it was enabled / disabled. The justification may need to be logged outside of HANA.
Comment From Mike: How far back in time are live patches available for the 'current' kernel?
You can keep a system without reboot when using Live Patching for up to one year. For kernels older than one year, no live patches will be made available. There is an FAQ section for live patching on the SUSE Web-Site that cover this and other interesting questions at: https://www.suse.com/products/live-patching/frequently-asked-questions/
Comment From Ally: Should I disable the SYSTEM account within SAP HANA?
Yes, it's SAP's recommendation (and a best practice) to disable the SYSTEM account within HANA. This is the database super-user account. Upon standing up a new instance of HANA, I would create your regular admin accounts based off of the SYSTEM account, and then disable the SYSTEM account. It should never be used in a Production environment, and if there's ever an emergency, you can always re-enable the account. A user simply needs the USER ADMIN permission to be able to do this. Also, as a best practice, you may want to enable access logging to monitor for when that account gets re-enabled.
I'm guessing these links were the ones in regards to the XSA user management that I sent to Josh earlier. If not, please reach out to me and let me know which links you were looking for. If they were for XSA, then I apologize because I don't have the answer you're looking for. I'm not that familiar with the user management side of XSA applications. So, I would recommend that you reach out to SAP or your implementation partner for more details, or post a question in the Security forums. I can reach out to my colleagues at Hitachi Consulting or oXya, and they can provide you some best practices.
Comment From Josh: Are there any special considerations if I deploy SLES for SAP applications on HDS with Vmware?
The only additional security recommendation to consider with VMware are the security updates to the VMware software. Everything else with regards to securing HANA or the SAP app tier should be the same as if running on bare metal.
Nothing HDS specific. A good overall practice is to check the "Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMWARE VSPHERE" (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/sap_hana_on_vmware_vsphere_best_practices_guide-white-paper.pdf )
Comment From Rudi: Should I change OS-level permissions on the files/folders of the SAP HANA filesystem?
No, these permissions are established by the installer when HANA is installed. So, it is strongly recommended not to change those file level permissions. If you feel that you have a need to change them, I would open a message with SAP and / or your Linux provider to ask about the potential impact to adjusting the file level permissions.
Comment From Pat: How often should I be patching my firmware?
Firmware would normally be patched 1 - 2 times a year unless there is a critical security vulnerability that your hardware vendor has alerted you to. As a best practice, I would do them in their own maintenance window instead of trying to combine with other maintenance activities. This way if something goes wrong, it's easier to pinpoint the problem.
Comment From Molly: What is the patch selection criteria for live patches?
Fixes for SUSE CVSS (Common Vulnerability Scoring System) level 6 vulnerabilities and bug fixes related to system stability or data corruption are shipped via SUSE Live Patching. For more information on the SUSE CVSS ratings, see: http://nvd.nist.gov/cvss.cfm/
Comment From Abby: Do I need to use SSL for my SAP HANA connections?
If your network is unprotected with firewalls (which hopefully it isn't!), then I would strongly recommend that you encrypt your HANA connections with SSL. If you use firewalls to protect your HANA instance, and they are locked down according to SAP's best practices, it's up to you if you want enable SSL on the HANA connections. It certainly adds another layer of security, and with the increase in malicious users out there coming up with new ways to breach a company's systems, it's better to be safe than sorry!
Comment From Mike: Is the live patch channel also SAP-specific?
Although it is not SAP-specific, the CVSS 6 rating and system stability bug fixes drive the criticality. You can open a ticket with SAP and if the problem is related to a patch in live patching, it will be routed to the SUSE queue for resolution.
Comment From Chris: What tools do you recommend for monitoring security best practices for SAP HANA?
There were a few that I mentioned in our previous SAPinsider webcast. You can use your EarlyWatch Alerts to help detect when systems aren't adhering to SAP's best practices (in the Security sub-heading). You can also use SAP Solution Manager to help detect for missing SAP Security Notes (released the 2nd Tuesday of each month), and you can use the SAP HANA Cockpit, which has a Fiori feel to it, that has a Security section. This will show you a lot of good info that follows SAP's best practices for securing HANA, and it also has links to the SAP Security Guide in case you need to dig into a particular area. There's probably a number of 3rd party tools out there that can also provide recommendations / best practices, but the ones I mentioned above are included with your existing deployments, so they're free!
Comment From Guest: Are there options to mask sensitive information?
From an operating systems perspective (not application-specific), you can encrypt directories using cryptctl . This allows for the protection of data volumes and directories. Specifics can be found in Chapter 9 of the SUSE Linux Enterprise for SAP applications documentation at: https://www.suse.com/documentation/sles-for-sap-12/singlehtml/book_s4s/book_s4s.html#cha.s4s.configure.cryptctl
Comment From Randy: How does Hitachi architect SAP systems to increase uptime for security maintenance?
We have a number of ways to help you achieve uptime depending upon your HANA environment. I always recommend to customers to have local HA using SUSE HAE with HANA System Replication (HSR). This way you can patch one node while the other node is still running your Production environment. Then you can failover to the standby to do the work on the other node, and you can minimize downtime since everything will be running in a local, synchronized fashion.
I also recommend to customer to have a Production-like environment for a QA / Test system. You want to be able to test your failover / maintenance procedures before actually getting to the Production maintenance day. A cluster adds another layer of complexity to an environment, so you need to be able to test ahead of time to make sure Production maintenance goes smoothly for your end users.
Certainly with SUSE's new Live Patching feature, this helps us administrators with our monthly chores!
If you're running on VMware, you can use VMware's HA features to increase uptime. This is great for HANA environments given the new increases in VM sizes with vSphere 6.0 and 6.5, but keep in mind that there may be disconnects during failover. So you still may want to consider using SUSE HAE within VMware.
Comment From Guest: Do you know of anything within the apps that can help mask sensitive user info?
The only product that I'm aware of is Libelle's System Copy tool that has a data masking feature. There may be others, but I'm just not familiar with them. I think TDMS might also have this capability, but it's been awhile since I used that software.
With regards to Libelle, Hitachi does partner with them to fully automate your system copies end-to-end.
Comment From Guest: What tools are there to migrate from Sybase to SAP HANA?
I will defer to Jason, but it's either using the DB migration option under SAP HANA or going through third-party solutions. DMO information available at: https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=395285937
Thanks again Matt and everyone for joining the Q&A today! Hopefully you got answers to all of your questions, but if not, please feel free to reach out to me directly, and I will try to get your question answered! firstname.lastname@example.org
If there are any other questions around SUSE Linux Enterprise for SAP applications, SUSE live patching, or any SUSE product or solution, don't hesitate to contact me at: email@example.com.