1 of 1 people found this helpful
If you don't want to have multiple DBs the options to manage servers behind firewalls are:
- Open the RSCD port. Not an option? they might want to have a closer look at this: the flow is unidirectionnal on a single port and with an identified IP (the AppServer) Doesn't seem to me as a huge security hole.
- Socks proxies. Not satisfactory.
- Put an AppServer behind the firewall: the flows are point to point but they include the JDBC flow, which is not really secure...
- Put a DB cluster node and an AppServer behind the firewall. Never done this so I'm not quite sure this really works. Not that theoretically it should be OK, provided that the network is fast enough - the same remark applies to the 3rd solution - so this is not a remote site solution.
... So I suppose there are only little options left.
Olivier, thanks for your prompt answer.
Yeah, probably the best option is to have an application server for each data center.
This would let the platform to be "quite" centralized (although you have to know which server is where in order to be able to browse it, and for jobs it's still complex).
The issue about jdbc traffic can be solved with products such as s-tunnel, which the customer already uses for encrypting other data flows.
We have some customers using this type of config. The main problems here are:
- Which AppServer for which target servers. For Jobs you need to setup the affinity which is fairly easy now that it's in the GUI. Live interaction with the servers will require a separate "Configuration" AppServer for each datacenter and require to change your console connections, which might not be a problem if the datacenter segregation exists among the users of this platform. If anyone canmange any server it's going to be a pain in the butt.
- If the network between the AppServer and the DB is slow (less than 10Mbits say), the GUI is going to be pretty sluggish.
From an architectural point of view what might happen also is that one of the AppServers gets flooded by requests on a datacenter while the others are basically idle. The load balancing is going to function below it's normal level. This might ultimately drive you to oversize the AppServer hosts in order to absorb the peaks, which is generally speaking a poor design.
I'd also be concerned by the speed of the link between app server and db server.
Out of interest, why was the SOCKS proxy solution rejected - we are proposing this solution to a customer too and I have a meeting with the security team on Thursday?!
I could push socks proxies solution if I knew more about this technology.
Basically we are facing security concerns from the customer, which we are trying to push back.
Can you find out what the security concern is w/ the socks proxy? it is odd that they have a problem w/ something that makes the solution more secure.
I would not do appservers in each site - putting the database traffic across a WAN will result in many problems w/ your appservers.
I think your only real options are to use the socks proxy, open up 4750 from the appserver to all of the agents, or setup multiple bladelogic installs. (repeaters are only there for file caching)
Ultimately the SOCKS proxy functionality was added to allow handling of overlapping IP Address ranges in outsourced environemnts. The goal was not necessarily to provide secure communication across WAN links... though it could be used that way.
My preference would be to open the firewall ports on 4750, allowing only incoming connections from the authorized Appserver IP and furthermore use client-side certificates on the agents to ensure authorized connections and/or a VPN tunnel between sites.
nsh from command line won't work with socks either
so this will impair your command line administration capabilities
push as hard as you can to obtain direct connection from appserver itself
Nsh should work through the socks proxy if you are also using a nsh proxy.
The remote app server would also have to access the remote file server and have bidirectional communication through the firewall (app to rscd and jdbc). This seconds the never ever discussion about WAN lniks between DB and app. The customer will then also have to deal with routing rules, so the managing effort is higher by far.
The SOCKS proxy is sort of unsecure as the firewall is kind of tunneled. No firewall can log or drop any traffic as it is not informed about the real destination of the traffic. I can understand the concerns from a security perpective. It also increases the complexity and # of possible points of failure.
I must second Olivier that the most secure solution would be a well defined source IP (not port, as I beleive the customer is not filtering for source ports, but for dest ports - source port filtering is not doable for a multi machine communication). If they are not permitting lump firewall changes like one source to any:4750, then they have to find a way to adjust their processes. I would push back on anything else (except they implement a rule for every agent, if they can manage it). If you start the discussion, ask them how teh are doing: backup, monitoring, ... Let them compare their own answers to a direct connection from one machine to all.