If you've started delving into the brave new world of Composable SaaS in recent times, you may have encountered a common issue when it comes to security and the typical existing Security Posture businesses have which doesn't quite align to the way in which Composable SaaS architectures need to work.
Traditionally, it's been common practice to route all traffic through a WAF/Security layer by default and be done with it. In order to do this, a classic Firewall will use IP based routing/networking to plumb traffic from point A to point B via the Firewall. You punch a hole for specific IP's to allow traffic in and out as required. A lot of businsses have also adopted Change Management practices whereby a change gets raised, reviewed and released on a specific cadence. Eg. once a day or week.
The problem
As trends move more towards composable SaaS, the problem which we encounter is that most SaaS products won't offer IPs which you can White List or route for their traditional offerings. This is becuase they are managing releases and upgrades for the software and the underlying infrastructure behind the scenes and likely moving your application around. Even if you had IP's and ranges, there's a high chance that things will change and you'll be forever raising emergency changes to update the rules in your firewall.
Note: It might be possible if you pay for Custom/Enterprise offerings you could get a privately hosted/secure arrangement but for me that defeats the purpose of SaaS which is... to offload responsiblity and the need to manage big portions of your Tech Stack.
In order for all this to work, SaaS providers generally utilise DNS based routing for everything. By doing this, they can repoint as they need and take care of what they need to but it means that they won't provide you IP addresses as they're likely changing regularly as they manage things for you behind the scenes. So you point a DNS record to the SaaS product and use that to access/communicate with it
Adapting to change
Given all of this, when making a move towards Composbale SaaS architecture, there is generally a need for businesses to re-evaluate their security posture and adapt it or ammend it to have an approach that supports DNS based routing.
This is where you generally need to work with the business SecOps/Networking teams to weigh up what your existing Security layer looks like and how it works and make a decision on whether you replace it, or add another SaaS/External Application posture that is specific to when using products/capabilities which are SaaS based.
Edge Network Solution
Edge networks are nothing new. Most SaaS providers are likely using one to underpin their own product. Examples being Vercel and Sitecore XM Cloud which we know both are backed by Edge networks. They use DNS based routing to middle-man/proxy requests and perform additional actions. Most are a combination of CDN capabilies as well as Security Capabilites.
By routing/proxying traffic through our own Edge network using DNS, we are able to utilise more SaaS based technology which lets us tackle multiple architectural (security and performance) problems with one solution and offload more responsiblity (nice!).
Whenever you add new SaaS based products to your stack, if you can put a custom DNS record on it, it means you can route it through your Edge Network and get it protected with WAF, DDOS Protection, added scurity headers, bot detection etc. (the list goes on).
Typically there will be a transition period where you have the old security mechanisms in place with the existing business systems/services behind it and as things are updated/replaced over time, the old security layer can likely be phased out or retained as required.
Comments