Sam - December 1, 2018
Proxy servers play an important role in cloud infrastructures. They aren’t the kind of proxy most people think of. They don’t hide clients from servers, but rather they stand in for servers on the Internet. That’s what is called a “reverse proxy.”
An SaaS setup usually provides more than one application to its users. Often, it makes sense to have specialized servers, each of which handles one or a few of the applications or otherwise divides up the work. Each server category could have its own domain and IP address, but that’s rather confusing to the user. A proxy is a more elegant solution for many cases.
You could think of a reverse proxy as an assistant who takes phone calls and talks to visitors outside the main office. Some of them are routine, and the assistant can handle them without wasting anyone else’s time. Some of them need to get an appointment or be brushed off. The boss in the main office can work more efficiently. A reverse proxy does the same for application servers.
A popular approach is to have a reverse proxy server for the entire service. It stands just behind the firewall. All Internet traffic goes through it, and it figures out where to dispatch each request. It forms part of a cloud distribution network (CDN) architecture, or it can be used in a standalone data center.
A reverse proxy has some similarities to forward proxies, load balancers, and edge servers, but it’s not the same. More than one of these functions can be combined in the same machine.
A forward proxy is what clients use to connect indirectly to Internet services. It includes local caching proxies as well as anonymizing services. A reverse proxy is a destination. Clients connect to it rather than directly to the machine running the application. They are connected to the proxy, but the functionality they get is from the application server.
A load balancer is simpler than a proxy server. It distributes requests among two or more homogeneous application servers so that each one gets a roughly equal amount of work. A reverse proxy server can include load balancing among its functions, but it also assigns requests to servers that run different applications.
An edge server stands geographically closer to the client than the application server does. It caches data for faster turnaround or passes requests on to the application server if it has to. It may or may not include proxy functionality beyond that.
Assigning requests to servers is the proxy’s basic function. A request’s URL indicates what application it’s intended for. The proxy parses it and determines which application server is able to service it. It can manage sticky sessions, where all requests from a logged-in user go to the same server in a load-balanced group.
Application servers might differ only in details such as the languages they handle. There might be one server for an application’s English-language requests and another for all other languages. The proxy can send requests to the appropriate server based on user preferences or URL parameters.
The server can standardize URLs before sending them to the application server. This includes applying rewriting rules, removing unnecessary parameters, or adding parameters for internal use.
Adding a new application and new hardware to support it is a simple matter. The proxy’s rules just need to be updated so that they dispatch the appropriate requests to it.
IPv4 addresses are scarce. Network address translation (NAT) gets around that problem, but the server is on the network perimeter where it’s vulnerable. A proxy just requires one public IP address, and the application servers don’t need one at all.
Computer security concept.
A server which is directly reachable over the Internet is constantly under attack. Hostile packets probe it for open ports, application bugs, and other weaknesses. A successful attack lets criminals steal confidential data or modify information. Data breaches that affect customers are very costly.
A reverse proxy keeps application servers off the front lines. It doesn’t hold a large amount of user data, except whatever is in its cache. If the proxy is compromised, the attacker still has to get through to the application servers. Administrators have more time to catch and remedy the problem. Keeping the network perimeter small lets edge protection systems work better. The internal network structure is hidden from potential intruders.
The proxy does application-specific request filtering, beyond what a general-purpose firewall can do. It blocks requests that match malicious URL or cookie patterns. The application server never sees them. It can limit requests from a given user or IP address, protecting against denial-of-service attacks. The term “application firewall” often appears for a proxy that serves this function.
Having a filtering layer which is separate from the application improves flexibility. Administrators can change the rules without touching the backend servers. In addition to blocking malicious requests, the proxy can detect suspicious behavior and issue an alert for further investigation.
The proxy examines outgoing as well as incoming data. It can detect abnormal data being sent from the application server, block them, and alert the administrators. That lets it catch, for example, malware reaching out to a command-and-control server.
Secure connections are necessary for any serious Web services. TLS (often still known by the older name of SSL) requires cryptographic signing and verification. That takes up significant computing time when processing many requests. A proxy can handle all the TLS work, removing the load from the application servers. As long as their connections are physically safe from outside snooping and tampering, they can use unencrypted HTTP. Only one TLS certificate is needed, rather than one for each application.
This advantage applies only if the proxy and application servers are parts of a LAN or a secure MPLS network. If the network is a software-defined WAN, HTTPS connections are necessary for backend connections. Anything that goes over the public Internet needs to be secure. The certificates can be self-signed, since no outside machines should ever access them. Each server can have its own certificate, and they can be replaced as often as necessary.
Keeping TLS software up to date is an important part of network security. Using proxies to reduce the number of Internet-facing devices makes the task easier.
Authenticating users and checking their authorizations should be a unified task. The application servers shouldn’t have to check logins separately. They should just get trusted information about the user’s identity and privileges.
The proxy server checks the session which a request belongs to. If it isn’t logged in and the request requires an authenticated user, it dispatches the request to the identity management system for logging in. If the user is logged in, the proxy server may be able to check if the user can perform the requested action. If it determines that it isn’t allowed, it sends an error message back. The proxy checks for session timeouts, limiting the risk to people who walk away without logging out.
Invalid login attempts waste an application server’s time, especially if a password-guessing bot is making repeated attempts. The proxy server can field them and limit the number of attempts from any given source. After too many failed attempts, it should lock the source out for a while. The application server doesn’t need to see them.
Compression of responses reduces bandwidth requirements and speeds up response times. This is a standard practice for decreasing the number of bytes sent. It’s not as demanding as encryption, but it does take some processing time. The proxy server handles all compression and decompression, relieving the application servers of one more task.
Some requests need to be redirected to a server in a different location. The proxy server can send redirect responses without touching the application server. It can handle upgrade redirects from HTTP to HTTPS, and it can send responses such as “not found” and “not available” in the appropriate cases.
Server logs are easiest to deal with when they don’t come from too many machines. A proxy server can log all requests for the application servers. This makes it a convenient base for analytics. The proxy can run the analysis itself, though usually, it will give the data to a separate cloud service to turn into statistics and graphs.
Using proxies simplifies network monitoring as well. Monitoring software can see how much traffic is going through the proxy server and what kind of requests are coming in. If unusual traffic patterns start showing up, it’s easier to catch them when there’s no need to combine data from multiple servers. That allows quicker detection of denial-of-service attacks.
A load balancer distributes jobs among multiple servers so that they share the processing burden. It can be a specialized device that does nothing else, or it can be one of a proxy server’s functions.
Some application architectures require all requests in a session to go to the same server, so it can hold session data locally. A proxy server can do this by holding onto session identifiers and dispatching requests appropriately. It may also be able to do smart load balancing. Some types of requests demand more resources than others, and the proxy can take this into account.
Keeping application servers off the network perimeter makes scaling them easier. There’s no need to add public IP addresses or reconfigure NAT for new machines. The proxy just needs to know about the new servers and have rules about what requests to send to them.
If the network adds a new SaaS category, the changes to the proxy are still fairly simple. It needs to have rules for the new service and for how to dispatch its requests. If it functions as an application firewall, it will need updating so it can protect the service.
A large network may need more than one proxy to keep up with the traffic. In this case, a load balancer can manage multiple proxy servers.
Not every request has to go to the application servers. A request that doesn’t trigger an action may just need to retrieve data that doesn’t change often. The headers in the server’s response indicate whether it can be cached and for how long. Everyone knows about how browsers use this information; a caching server does basically the same thing.
A server can send a purge request to a caching proxy when the content changes sooner than the expiration time. This allows longer expiration times than would otherwise be safe since it’s possible to override them. That’s a feature that isn’t available to browsers.
The sum and goal of these advantages is a SaaS system which delivers better performance without a huge increase in hardware costs. A proxy is like a skilled assistant who handles routine tasks for the boss. The boss isn’t constantly interrupted and can concentrate on the important work. People get to the inner office only after the assistant has verified that their business is legitimate and needs personal attention.
A proxy server’s work is qualitatively different from the backend server’s. It handles a huge number of requests but performs only simple actions with each one. Most of its work consists of handing off or dismissing requests. Its software is designed to handle many requests in parallel, where each one doesn’t need a lot of resources. A backend server handles fewer transactions, but they typically have heavier requirements for computing or looking up information.
At the same time, putting the application servers behind a proxy makes them more secure. Attacks over the Internet have to go through an extra layer to hit them. The proxies need strong edge protection, but there are fewer of them to protect, and they don’t hold a large amount of valuable information by themselves.
There’s a lot more to learn about the use of proxies with SaaS, but hopefully this introduction has helped to convince you of their value.