IP Whitelisting with a Pinch of SaaS
One of the simplest security measures we use is whitelisting a bunch of authorized source IP addresses so users can access required services securely. This security measure is so basic that in most cases the service itself does not need to be aware that only certain source IP addresses are able to access it — the network infrastructure around the service takes care of the same.
However, in the age of SaaS and multi-tenant cloud solutions, it is time to take a closer look at this popular security measure and review its relevance with respect to our developer platform and apps.
What is IP Whitelisting?
A web-service that provides business critical services needs to be secured such that unauthorized requests are blocked, as depicted in the picture above. This can be achieved simply by identifying all authorized users with the associated IP addresses and blocking all other requests from reaching the service. This list of authorized IP addresses is typically associated with the HTTP proxy used in an office network or the Network Address Translation (NAT) gateway used by Virtual Private Cloud (VPC). In either case, a range of clients behind the proxy or gateway can now access the service because the source IP address of outgoing requests from these clients is the same as the proxy or the gateway they are behind.
What are the shortcomings?
Some of the shortcomings of this approach are obvious, and indeed, they are acceptable in certain setups.
- As secure as your office network: If registering on your office network requires knowing a secret, your IP whitelisting is as secure as the secret. Alternatively, if registering just requires being physically present in your office, your IP whitelisting is subpar.
- Membership defines authorization: A client can access a service by way of belonging to a member group that is behind a proxy or NAT gateway. A new client can now unintentionally gain access simply because someone missed this fact when adding the client as a new member — think bringing up a new microservice in your VPC that does not need access to this service, but now has access.
- As secure as the IPs themselves: Depending on the value of your data, rogue agents might go as far as hijacking routing tables just to gain access to your data services. Of course, if your data is this valuable you certainly are not using IP whitelisting, are you?
SaaS and Multi-tenancy
SaaS is more than an architecture — it is a business model. It thrives on sharing as many resources as possible across thousands of tenants/users. Any web client running in a SaaS environment has to serve multiple tenants to justify its existence (or guarantee a ridiculously large value, otherwise).
IP whitelisting became popular way before we had multi-tenant services hosted in public clouds and serving most of our needs with infrastructure which could be shared with thousands of other customers. To belabor the obvious, when you give access to one or more IP addresses belonging to a NAT gateway associated with a VPC hosting SaaS, you trust and give access to every single possible web client that could originate from within that VPC. This is usually OK, unless your SaaS provider also supports a developer platform to build and run apps within that infrastructure. Now, any user could potentially write an app that could send requests to your secure web service, which would allow these requests as they originate from an IP you trust.
What was designed to be a productivity platform can suddenly become a platform to launch an attack against your data services. Like with all security measures, the simplest thing you can do is to add a layer — require that each request present a secret to be authorized.
You can refer our earlier post to add this additional layer and securely access your service from an app running on our platform.
What is still OK?
What we described above are situations where:
- You don’t control the membership to groups authorized to access your services.
- Traffic is headed into your network.
- No additional challenge is posed to incoming requests.
However, there are certain situations where IP Whitelisting is an acceptable measure of security.
- You completely control membership to groups authorized to access your services
- Traffic is headed out from your network.
For instance, you could ask your SaaS vendor to only allow one or more IP addresses (typically associated with the proxy for your office network) to access your account with the same vendor. If you have taken great pains to secure your office network (physically and over WiFi), only authorized employees will be able to access these accounts after presenting their login credentials. API requests to your account will also be authorized as long as they originate from a whitelisted IP address and use a valid access token.
IP Whitelisting is a straightforward tool to add the first layer of security around data services you host. With multi-tenant cloud services abounding, a little diligence will go a long way provided you only use IP whitelisting where you are in complete control of the authorization IP addresses carry with them.
Announcing support for whitelisting apps
We are announcing support for apps running on our platform to be able to securely work with any Freshworks account that uses IP whitelisting to restrict incoming requests. As long as an app uses our request proxy, the requests will originate from one of the source IP addresses documented here. This IP address must be added to your whitelist to ensure that your apps continue to work in your account.
Note: We recommend that you use IP whitelisting with an additional security challenge of a secret or access token.
Many thanks to Vignesh (vignesh.moorthy@freshworks.com) for crafting the images for this post!
If you have any questions you can reach us at marketplace@freshworks.com. Follow us on @FWMarketplace.
