sap-linuxlab / community.sap_install

Automation for SAP - Collection of Ansible Roles for various SAP software installation
Apache License 2.0
57 stars 57 forks source link

feat request: OS Security Hardening Ansible Playbook for SAP Workloads #567

Open PRELVAS94 opened 11 months ago

PRELVAS94 commented 11 months ago

Hi,

I'm currently developing an Ansible playbook that designs an OS Security Hardening based upon: https://access.redhat.com/articles/6892601 & the latest template from OpenSCAP.

I have previously discussed with Irina Guilina from Red Hat, that this could be a good starter point for implementing a OpenSource Security Playbook for SAP.

Currently I have variations with SELinux Permissive/Enforced for the SAP Workloads with exceptions given to the SAP directories.

Please reach out to understand if it's feasible and needed to be shared with the community.

PRELVAS94 commented 11 months ago

@rhmk @berndfinger

sean-freeman commented 11 months ago

Hi @PRELVAS94, the handling for SELinux on RHEL4SAP or SLES4SAP is already encapsulated by the sap_*_preconfigure Ansible Roles and can be seen in the vars file of the respective Ansible Roles. I imagine the full adherance to OpenSCAP will be near impossible for SAP Systems to function.

Before creating and contributing an Ansible Role (such as sap_hardened_os), you may wish to first evaluate an Ansible Role that was created by an SAP employee for various Linux OS distributions -- https://github.com/darkodrazovic/total-linux-hardening . You may find this a better starting point to help find the "sweet spot" between following all the rules desired by a Security Admin and the needs of an SAP Admin :)

PRELVAS94 commented 11 months ago

Hi @PRELVAS94, the handling for SELinux on RHEL4SAP or SLES4SAP is already encapsulated by the sap_*_preconfigure Ansible Roles and can be seen in the vars file of the respective Ansible Roles. I imagine the full adherance to OpenSCAP will be near impossible for SAP Systems to function.

Before creating and contributing an Ansible Role (such as sap_hardened_os), you may wish to first evaluate an Ansible Role that was created by an SAP employee for various Linux OS distributions -- https://github.com/darkodrazovic/total-linux-hardening . You may find this a better starting point to help find the "sweet spot" between following all the rules desired by a Security Admin and the needs of an SAP Admin :)

Hi,

I understand the perspective on the SELinux as I have myself used the sap_*_preconfigure. However there are many things like when it comes to Azure PAYG images, hence I had to do a new hardening from scratch based on the OpenSCAP and the document from Azure.

The playbook also takes in consideration the RHUI Certificates in Azure and many other features.

Would it be more wise to maybe approach Microsoft in this case?

kksat commented 11 months ago

@PRELVAS94 if your contribution is not accepted here, you are more than welcome to contribute to https://github.com/redhat-sap/rh_operations

berndfinger commented 11 months ago

@PRELVAS94 I like the idea of having additional functionality for security hardening for SAP systems as part of the sap*preconfigure roles, as the purpose and scope of these roles is to modify a default OS to be ready and optimized for the installation of SAP software. As mentioned by @sean-freeman above, some of the security related modifications are already part of the sap*preconfigure roles. Examples: SELinux, minimum package selection. And I agree that we also have to think about any possible overlap between existing code (e.g. in https://github.com/darkodrazovic/total-linux-hardening or in existing Azure roles) and the sap*preconfigure roles.

We could call another role from one of the sap*preconfigure roles. Or we could provide an alternative implementation which could then be more general. Or we could implement additional security modifications inside the sap*preconfigure roles and use separate roles or playbooks for implementing CCSP specific modifications. Maybe you have already grouped the desired operating system modifications according to similarity, scope, available code, or other criteria? I think such an overview (e.g. a table) can be very useful during the planning phase.

I'd also like to have a look at your current playbook and the additional security related documents you mentioned above. Can you please share these?