Cloud-Native Applications are Like Nuclear Submarines
Have you seen the movie Crimson Tide? Every person architecting a cloud-native application should see this movie. In it, a breakaway Russian government threatens a nuclear attack on the United States. A U.S. submarine, cut off from communications with Washington but well aware of the Armageddon-level threat, must decide whether they should launch their nuclear weapons against the rogue government to stop the threat. The two senior officers on the submarine (Gene Hackman and Denzel Washington) disagree on whether the weapons should be used. Still, both must agree and use their respective launch keys to activate the missiles. The simple act of disagreeing on the outcome keeps the missiles from being launched by either.
This is the philosophy behind a critical application security principle often ignored by companies building their internal infrastructure security architecture for their cloud-native applications. It is called the Principle of Separation of Duties, and it is critical not just for nuclear submarines but for the IT infrastructure of all applications and all businesses, large and small.
Why is it important?
Do you have “special people” in your company? These people have extra access to the operational IT infrastructure, application data and application itself that most people don’t have access to.
They have these permissions so they can fix things when they break. If a server goes haywire, someone needs to log in as a “superuser” to fix the problem, right? And you certainly don’t want to give superuser access to everyone. So, some people have these special permissions and can be called in when specific jobs need to be accomplished.
Especially in cloud-native applications, these employees have full access to the cloud dashboard, which gives them the ability to access any server in the application, change any cloud service permissions and access any data.
The people that have this access often have it for historical reasons. In a small company, the technical founder will often have this access. In larger companies, it may be the “tech wizard”—the one that people call on when things aren’t working quite right. It might be the senior developer that built a particular capability. In even larger companies, you may not even be aware of who the individuals are that have this extra access.
Often, these employees have access to raw data in the database. They can “fix up” data that isn’t right because of some unrelated application bug. Sometimes, you need to update some piece of data that the application needs but doesn’t yet have the capabilities of updating the data itself. Instead, your special privileged employee logs into the database and adjusts the data manually.
Once, in a company I worked with, the ability to access raw customer data in the database was given to someone working within the customer support team. They needed this permission to go in and adjust profile information for a customer at their request—this is because the application didn’t yet have the ability to make these changes for the customer themselves. Of course, this access gave this special customer support agent access to all customer data for all customers.
Having employees with special capabilities like this can give expediency to your application and business. But, universally, having employees who have this level of access is a bad security practice. This is because many things can go wrong with these individuals. They can have their own credentials compromised by a bad actor and compromise the entire application. Or they could leave the company under less-than-optimal conditions and leave your entire application suddenly vulnerable to retribution.
A single bad actor who gains access to these privileges can bring your entire application down, delete critical business data and steal customer secrets. (Or, in the case of the movie, launch nuclear missiles.)
What is the Principle of Separation of Duties?
The principle says that there should be no such “special” people with special permissions. No single person should have all the access required to perform business-dangerous activities. Instead, to perform any dangerous activities, multiple people are required—each with their own security access. Only by using the permissions from more than one person can access be granted to sensitive data, dangerous operations and business-critical activities.
This multi-person requirement means that no single bad actor can compromise your system. Whether the bad actor is a disgruntled employee or an external agent that compromises an employee’s access—one single problematic person does not compromise the integrity of your infrastructure, your application or your business.
Akin to the “two keys turned” for activating nuclear missiles on the submarine in Crimson Tide, the principle of least privilege keeps bad actors from causing severe problems. But it also keeps someone from making simple mistakes that can cause serious ramifications. Gene Hackman wasn’t a bad guy in the movie; he just was acting on bad information and assumptions. The check that Denzel Washington provided kept him from making a fatal mistake.
A simple check and balance keeps the system running smoothly.
In a cloud-native application, it’s relatively straightforward to design your security strategy to implement the principle of least privilege. Regardless of your company size—even if you are a two- or three-person startup—spend the time to implement the principle of least privilege now to keep your cloud-native application safe and your business alive and functional.
