Firewall in SAP landscape

[former_member195709]

Hello Folks,

I try to understand the risks, if we don't have a firewall between application and database server?

End users will never access database server as per the plan.Also do you recommend firewall between QAS and PRD systems?

Since we have a secured LAN, I wonder whether these firewall settings are mandatory.In our environment the system is not connected to internet. From DR perspective, we may deploy a parallel system in another data center.

I appreciate your replies.

Thanks

Bala 

[Former Member]

The only sensible segments are DMZ <-> corporate client networks <-> protected infrastructure network. More than that is just to be stuborn and not more secure... 😉

Even in these core segmentations you must still harden certain SAP internal components for which the ports must be open.

Cheers,

Julius

[former_member195709]

Thanks Julius. Regarding your comments on port, I would like to clarify bit.

Do you suggest to close the ports other than critical connections such as TMS/RFC/Printer/DB listener etc.? We don't have any plan to use web service as of now.

Bala

[Former Member]

If you are not using something then it is better to deactivate it or leave it inactive in front end component application gateways.

The trick is to limit the attack surface at the network port level and then use the application logic of the available ports to restrict what can be done with them if they must be open.

Opening DB ports from server LAN to Client LAN is not a good example of this. But you should harden your DBs anyway. Same goes for OS systems as they might trust each other beyond SAP and use other ports for that.

DR is always a tricky thing (how to automate securely). There are some clever ways of doing this if you accept that it is pushed from SAP and monitored by the SAP system.

You should only mirror to data centers whom you trust and in the SAP world it is not realistic to encrypt the DB.

Cheers,

Julius

[former_member195709]

Julius, I appreciate your details. I will have an internal discussion with the team regarding this and will come back if I have any questions.

[Former Member]

Hi Julius,

I would slightly disagree here. Usually you will have firewalls between different protection zones, this could be only the zones you listed, however it is not uncommon and sometimes even required that you also have firewalls to split networks for prod and dev/cons systems to better control the traffic and the access to the prod systems. Especially for systems holding credit card data, this may even be required by standards. Often you will also find similiar setups for sensitive systems like HR systems. I completely agree however, that for an SAP ABAP systems having a firewall between the R3 system and the DB systems is not very helpful from a security point of view.

BTW: there are some recommendations from SAP to this regards in the security guides. Especially with regards to the placement of firewalls there is also some info here.

Kind regards,

Patrick

[Former Member]

Hi Patrick,

I slightly agree with you that some control is gained by network zones for PROD / QAS / DEV systems, but the moment you have an STMS transport system, CTS+, SOLMAN monitoring, CUA / IDM, master data replication, central etc then the RFC / SAPGui / Gateway / http ports will be open between the zones anyway.

So you have a considerably slightly higher maintenance effort for the firewalls, networks and switches with only marginally slightly better control of segments (e.g. for "zoning" in gateway ACLs it is useful).

😉

Cheers,

Julius

[Former Member]

Hi Julius,

as alway with security, there is no one size fits all. It depends for instance on your workforce If you have a high number of consultants working on Dev and Q, in many cases you want them not to get onto your prod systems.

However this is not the only reason. Usually a system has not only the STMS connectivity for the chain but is interconnected to other systems as well. Just one (real life) example from the past. A customer did copy his prod system to Q and then did some testing in there. However they simply forgot to reconfigure the service connections to let thempoint to the other Q systems and left them pointing to the other prod systems. As there have not been any firewalls in place, thoses connections did work. You can now guess what happened.

The reason you may want to split the zones for prod and dev often is not for the single system but really to have no business connectivity between the systems of the different zones to avoid the above, be it intentionally or by accident.

I'm with you, that if you have only one DEV/Q/Prod line with no other connectivity requirements, setting up different network zones for this may be a bit of an overkill. However I have not seen a customer so far, that had such a setup.

Regards,

Patrick

[Former Member]

Normally the basis folks have a "cheat sheet" of things to do before and after system copies. Killing jobs, deactivating SCOT, etc should be on that list regardless of the network zoning, particularly if the ports for ALE and smpt are open.

Yes, I agree that whether or not the ports will be open at that point in time (still / again) depends on whether the effort and discipline involved fits the organization and possibly regulatory requirements (which I was not aware of).

Best rather not to have Credit Card data at all..  🙂

Cheers,

Julius

[former_member195709]

Interesting discussion. I agree with "cheat sheet" regarding refresh  to keep the systems out of jeopardy. Obviously I would like to minimize the impact on maintenance at the same time secure the systems as far as possible. I got your points regarding my original question. Thanks Patrick and Julius for your input.