Contributed by: Frank Dickson, IDC, Program Vice President, Security & Trust
“Cloud-native security!” is the battle cry of the day. We all want it. But what is it? Everyone seems to define it differently. My suggestion is that any discussion of cloud-native security starts with the cloud. We move to the cloud for flexibility, choice, and ease of deployment, right? Public cloud vendors look to deliver on the promise of those benefits with an elastic IT environment where resources scale up or down on demand. These resources are highly virtualized implementations of the same technology enterprise organizations run in their on-premises datacenters, the key difference being many tenants versus one.
As we look to implement (cloud) security in this IT unique architecture, we want protections that are native to that environment, cloud native if you will. That is when the conversation can get complex quickly, turning into a discussion that may include loosely coupled containers, CI/CD delivery platforms, serverless security, and microservices. Surely, these capabilities allow developers to make changes frequently without affecting other components of a hosted application. The foundation is flexible, scalable, and oriented toward a new type of infrastructure. However, it does not sound easy. As a result, when it comes to a responsibilities conversation regarding the security of the cloud, as opposed to in the cloud, those measures of security and integrity should be provided by the cloud provider to deliver on the promise of flexibility, choice, and ease of deployment and not the application owner's responsibility.
My suggestion in our quest for "cloud native security" is to flip responsibility. Cloud native security should be security measures that are native to the cloud--an integral part of the cloud offering. Thus, cloud native security is something that the cloud provider offers to application developers seeking to realize the benefits of flexibility, choice, and ease of deployment, regardless of where the ownership lies in the shared responsibility model. Let me elaborate on some examples based on an IDC lab validation study of OCI.
Cloud, by default, means using someone else’s IT infrastructure; the hardware integrity of the infrastructure is the foundation upon which all future measures are built. If it's always the same organization using the basic compute elements, then any redeployment typically doesn't require a deep scrub right down to the firmware elements. Cloud native security requires refreshing all the way down to the firmware as, in a public cloud environment, there are no assurances that the boot code, the platform software, and any middleware are safe and secure for company B to use after company A reduces its current application-level demand.
If you were going to build your dream home, would you want to pour a brand-new foundation, or raze a house that was built in the 1930s and build on a foundation of unknown integrity? Remember, this is your dream home. The compute elements of a cloud-native architecture must be securely re-deployable. Cloud native security necessitates the ability to document and demonstrate the capability to wipe the firmware removing any traces of a previous use.
A second element of a cloud-native security involves a firewalling of the compute instances after the initial deployment. Given the sophistication of today's external attacks, it's possible that a software infection begun at the application level of a hosted service can travel all the way down to the bottom of its executable stack, and then begin an east-west attack on other discoverable cloud instances as it traverses the network fabric. It's rare that an initial breach occurs within a part of the environment that contains the ultimate paydirt in the form of sensitive data, credentials, and customer PI . IDC believes cloud providers that have isolated their network layers offer another important construct of a cloud-native infrastructure design.
Again, organizations moving to the cloud seek flexibility, choice, and ease of deployment, but they are often less skilled in the security exposures, the deployment requirements, and the maintenance activities. Helping customers with their portion of the shared responsibility model is another opportunity for cloud vendors to deliver cloud native security. Oracle Cloud Infrastructure (OCI) is designed to provide some grouping capabilities that help.
Compartments, for example, allow tenants to develop fine-grained, logical asset management boundaries and access policies — a basic capability that one really begins to appreciate when it's missing. It does for the cloud what virtualization does for servers, and just about no one gets these boundaries right the first time until there's more operational experience to review. IDC believes compartments are an elegant means for simplifying adjustments to a cloud-native solution deployment.
Compartments can be created in security zones with additional immutable security policies. A security zone is associated with a compartment of the same name, but you cannot add or move a standard compartment to a security zone compartment unless all policies are met. OCI security products provide several modifiable policy templates or "recipes" based on best-practice starting points for controlling compute, networking, object storage, and database resources, which in some cases must meet an Oracle-defined configuration. Changes or newly created resources that violate any policy within a zone will be denied. This is how OCI helps tenants avoid performing inadvertent misconfigurations.
Another helpful design characteristic is the Identity and Access Management (IAM) Group. Groups allow users to access resources within compartments via policies that are written for the group and not the user. It’s another element of cloud management flexibility that reduces the combinations of user permissions required to protect a tenant's data. Using groups and compartments, tenants can marry their physical organizational structure to available cloud resources adding, changing, and deleting instances and people along the way. IDC knows that authorizations and access policies can quickly become a quagmire when every tenant participant insists that he or she is a snowflake (i.e., unique).
Cloud-Native Security is Scrub-able, Adjustable, and Governed by Explicit Policies
Of course, Zones, Compartments, and Groups are all implemented on top of the servers and connected by the network. Within IDC's Lab Validation Study, “Putting Tenant Data Safety and Privacy First with Automated Operations,” we more closely examined how OCI isolates and protects its foundational elements.
In a previous blog, IDC also reviewed the role Oracle Cloud Guard plays in controlling and maintaining what OCI customers configure and implement within their compute, networking, and storage instances. The complexities of safely deploying cloud solutions simply require a posture management solution. Unable by design to see what its customers are doing in the cloud, Oracle built a management tool to help tenants enforce their own policies across all available resources.
Finally, cloud-native security discussions also tend to include things like artificial intelligence and machine learning, big data analytics, multi-vector threat detection, and threat intelligence, etc. Some public cloud providers can be more specific with such insights, tips, and recommendations because they have visibility into the customer’s tenant(s). Since OCI cannot, Oracle packaged similar AI/ML information as aforementioned recipes, cloud management tools, and operational insights that Oracle develops by running its own business within the cloud. They built it and they get it; they drink their own champagne, and they share it.
IDC believes a cloud-native architectural design is fundamentally different from the technology and practices organizations have long implemented within their on-premises environments. Organizational prospects who research and understand these differences will appreciate the added level of security that OCI presents and be more willing to migrate even sensitive workloads into a cloud environment knowing that help is available, and mistakes are avoidable.
Read about IDC’s lab validation of OCI Security to learn more.