In October 2022, the CTO of 37signals, David Heinemeier Hansson, published a piece on why hey.com was leaving the cloud. You can read the full article here, Why we’re leaving the cloud (hey.com); the gist of the post is that cloud is not cost effective. More recently, InfoWorld published a piece by David Linthicum, 2023 could be the year of public cloud repatriation | InfoWorld, hitting on why it may be more cost effective to move back to private data centers. You see the trend – cloud may not be providing the ROI that is expected, especially if your organization has just performed a bunch of lift-and-shift without application refactoring.
While the titles are attention grabbing, and the articles have valid points, they don’t really tell the full story. Folks in the industry may scan the headlines and believe that a mass cloud exodus is on the verge of happening, but we really need to look at what part of the cloud we are speaking to. We need to distinguish between IaaS, PaaS and SaaS, as well as related services and systems, such as IDaaS (identity as a service, aka Azure AD, Okta, and so on).
SaaS is king for business productivity
37signals is a SaaS application company – with basecamp.com, a project management platform, and hey.com, a cloud email service. Neither product offers a private hosted version, so while 37signals is leaving the cloud, the services they offer you, well, are still cloud services. Sure, they may not be hosted in AWS or GCP, but the organizations that consume these platforms will be accessing and using them as cloud services.
These days, nobody wants to manage a SharePoint farm, and certainly not Exchange Server. But it’s not just office suites such as Office 365 and Google Workspace (and hey.com). In recent years we have seen an explosion of growth with SaaS applications and platforms, and this is something that is continuing to trend upward.
VPN is an antiquated means of access
Whether it’s IaaS or PaaS, hosted in private data centers or in some form of cloud, needing to access applications from everywhere and anywhere is as important as ever. With COVID-19 and the remote workforce, it strained organizations trying to find ways to allow access to applications for the workforce. While VPN may have been the path of least resistance to allowing remote access, it’s certainly not well aligned to Zero Trust. Cloud platforms provide means for modern access, and modern authentication, to applications, regardless of where they exist. Products such as Azure AD Application Proxy can be that conduit, are easy to deploy, and can be used to supplant VPN access. Sure, there may be the edge cases where VPN still provides the necessary means of access, but organizations should realize that success is much easier when we are not picking one-size-fits-all solutions.
Cloud-native devices ease administrative burden
Closely tied to VPN access was the struggle of organizations trying to manage Windows devices that were Active Directory joined, or Hybrid Azure AD Joined. Concerns included patch management, group policy changes, and expired user passwords. The question of machine account password age and the relationship it has with Active Directory became a huge point and topic of confusion.
Microsoft has used the past few years to really push Azure AD Joined devices, making device identity cloud-native. Yes, we still have the issue of remote troubleshooting, which is regardless of how they device identity exists. Yes, we still need to use something like Intune to manage the devices, and the road has been bumpy in replacing group policy. And yes the ROI is not worth it for most organizations to redeploy Windows on existing Hybrid Azure AD Joined devices until those devices are due for a hardware refresh. But we should continue to build the path towards the cloud, away from Active Directory, for client devices.
For those in the Microsoft ecosystem with Active Directory and Azure AD, cloud-native devices can still access on-prem resources tied to Active Directory, either when on a corporate network or coming across the VPN (unfortunately).
Cloud applications need cloud identity
The benefits should be clear for cloud identity systems. While there have been a few major outages in the past three or so years with Azure AD, the level of complexity required to maintain a 99.99% SLA for a publicly connected directory services system just cannot compare.
If we look at what it takes to manage an AD FS farm with a high level of redundance – at least three sites with Active Directory replicated across, at least one AD FS server (but likely two) in each respective location. If more than one AD FS farm server is in each location, you need location-specific load balancing. For the public edge, you need at least three disparate DMZ networks, with a minimum of one WAP server (but likely two), and then to route the traffic between locations a global traffic management solution, which usually looks like a DNS-based load balancing solution, such as Azure Traffic Manager.
Organizations still need to harden and secure this environment, patch it monthly with orchestrated patch management to ensure availability, and monitor from a security and availability perspective. At the end of it all, this still pales in comparison to Azure AD. AD FS access control policies come nowhere near conditional access. Management and writing of claims policies are still harder for the average person to understand, and Solorigate has shown us what happens when AD FS is compromised.
A pretty surmised way of looking at it – cloud-native directory services are designed with identity security practitioners in mind. On-prem directory services are designed with infrastructure practitioners in mind. AD FS is still an “infrastructure” identity system.
While one can argue some pros of owning your own systems, that argument falls flat when you look at the realization that any of the major identity providers platform developers are investing in cloud-native identity first.
What about those on-prem servers
For as long as Windows server remains in your organization, it’s likely that Active Directory is not going anywhere. While we have had huge advancements with Windows clients and the cloud, server is another story. Sure, we have things like Azure Arc and Desired State Config (DSC), but many argue that DSC is too complex and not a replacement for group policy. It still makes sense to keep identity close to the servers, so even if you could Azure AD Join a Windows server, majority of use cases would not be well-served.
Until applications are refactored, the Windows servers they run on aren’t going anywhere. And the associated service accounts that run these services will likely still need to exist in Active Directory.
But what we may continue to see is a wide array of patterns emerge. Organizations that primarily need Active Directory for compute workloads may drive end-user identity into the cloud, and AD remains as the glue for server administration only. Others that are further behind on their application modernization journey may need to persist user identities in AD.
The way forward
One of the most important investments organizations can make with cloud identity is not just selecting the platform, but skilling the people. From experiences in performing security assessments of Azure AD, a lack of strong skilling leads to the majority of insecure and inefficient implementations of various components of cloud identity.
We also need to continue to push to transform identity from an infrastructure system to a security system. And this is much more than just transferring ownership and landing a complex identity system in the laps of folks completely unfamiliar with it all. Organizations will need to take a look at what it will take to properly staff identity under the security ecosystem within. This is its own ball of yarn, which I’ll save for another time.
One thing is for sure – cloud identity is here to stay.
About this posts featured image
The chosen photo is the work of Sendi Gibran, used under the Unsplash license.
