Debunking the Top 3 Cloud-Native Security Myths

By 2023, over 500 million digital apps and services will be  developed and deployed using cloud native approaches.

To put that in perspective, more applications will be developed on the cloud in a four-year period (2019-2023) than the total number of apps produced in the past 40 years.

Clearly, organizations are buying into the cloud. But the question is: Do they fully understand it? And do they know how to secure the applications they built within it? Just like with any emerging technology, it’s natural for myths and misconceptions to emerge over time.

When it comes to security, even a small misstep could lead to a noncompliance breach or cyberattack that costs your organization thousands, if not millions. To minimize the likelihood of these repercussions, it’s important to understand the most common cloud-native security myths — and what to do instead — to ensure your organization avoids unnecessary risk.

The first step to developing a stronger security posture is education: Knowing what not to do in cloud-native environments is just as important as knowing what you should do.

I created this guide to help demystify the most common cloud-native security assumptions and provide actionable recommendations on what to do instead.

Many organizations assume that because they host their applications on a cloud service provider (CSP), the CSP covers all security measures, but that’s not the case. The truth is cloud service providers and organizations share responsibility for security.

In the simplest terms, CSPs secure the infrastructure an application runs on, but you are responsible for securing activities and data within the application. To expand, CSPs ensure that the computing, storage and database services they operate are secure. And because CSPs run on a multitenant model where many applications share the same servers, they also provide hard isolation between companies.

What cloud providers can’t do is implement security measures within your application. This is because each organization builds its apps, consumes storage and configures its systems in unique ways — meaning it’s impossible for CSPs to apply a one-size-fits-all solution to in-app security. While some providers offer out-of-the-box security capabilities, like AWS Control Tower, you’ll have to pay extra and still do quite a bit of customization.

You, and all organizations on the cloud, are responsible for the security of your application and its individual components, including the operating system, source code and data. One of the strongest security measures organizations can take is implementing access control via authorization. Authorization ensures users and other technologies only have access to the systems and data they need when it’s needed. We’ll discuss how to implement authorization in the next two myths.

Another common mistake organizations make is trying to use the same security measures from on-premises environments in the cloud. Perimeter-based security measures, like firewalls and browser isolation systems, don’t work in the cloud because the network is no longer a static environment that can be protected with barriers around it.

Instead, you must focus on keeping the data safe if hackers enter the network. Again, this is where access control and authorization come into play. However, like perimeter-based security, traditional on-premises access control measures won’t work for the cloud.

Because of microservices architecture, containerized applications and application programming interfaces (APIs), there are exponentially more individual components that require their own authorization policies and security configurations. Traditional technologies like single sign-on, SAML, OIDC and OAuth2 can help you solve identity verification and authentication for your apps, but not authorization — that’s still up to your developers.

You should instead use policy as code in cloud-native environments. Policy as code means that you apply standard software engineering practices to the rules and conditions that govern your systems (version control, code reviews, automated testing, continuous delivery, etc.). With policy as code, policies are decoupled from the app cloud platform, meaning they can be changed without altering the app’s code. The decoupled nature of policy as code makes it easier for teams to write, scale, monitor, audit and collaborate on policy.

This final myth is rooted in reality because at one point in time, creating bespoke, individual policies was the only way to control access. But this is no longer the case. Technologies are available that enable organizations to apply unified authorization policies across their cloud-native applications, services and platforms.

It’s understandable why organizations would still hold this belief. Typically, software development relies on creating one-off custom solutions to solve a given problem because every organization configures its systems and infrastructures differently. And for years this was also true of authorization policies. But in a cloud-native environment approaching policy enforcement this way is exponentially more time-consuming, tedious and error-prone because of the greater number of discrete components.

Instead of implementing a bespoke solution for each new set of policy requirements, consider decoupling policy decision-making from the rest of your business logic via policy as a code and relying on additional technologies that help you efficiently apply and scale uniformed authorization across the cloud-native stack.

Open Policy Agent, also known as OPA, is an open source, domain-agnostic policy engine that allows you to write and validate policy as code. Styra donated it to the Cloud Native Computing Foundation in 2018, and it reached graduation status in 2021. OPA simplifies policy creation and ongoing governance because organizations can use the same language and policy frameworks across their entire cloud-native tech stack. Policies are written in Rego, which is purpose-built for expressing policies over complex hierarchical data structures. And because it’s open source, there is a rich ecosystem of developer-friendly tools and integrations organizations can pull from, as well as a community of practitioners who can offer advice.

Cloud-native development is quickly becoming the default for application creation. While the cloud offers many benefits, hosting data over the internet is inherently riskier. To reap the benefits of cloud-native development while mitigating potential repercussions, it’s crucial to understand common security myths and know what to do instead. Implementing authorization via policy as code is one way to ensure your data, customers and technologies are secure in the cloud.

Sign up for the Styra Academy to learn more about OPA, or Styra DAS Free today to see OPA in action.

A version of this blog first appeared in The New Stack on January 11, 2022.