Cloud Security Perspectives and Insights

Prevent a weak cloud security posture with Maximum Security Zones

Paul Toal
Distinguished Solution Engineer - Cyber Security

Back September 2019, Clay Magouyrk, Oracle’s Executive Vice President for Oracle Cloud Infrastructure (OCI) engineering stood on stage at Oracle OpenWorld and talked about how “Enterprise-grade security must be made simple” and how “Maximum Security can be Easy”. At the same time, he announced a number of new capabilities to deliver on that vision, including Oracle Cloud Guard and Maximum Security Zones. These new services are now available

These two new services are important milestones in delivering on Oracle’s vision to deliver the most secure cloud, ideal for running enterprise workloads. They work hand in hand to provide both preventative and detective security controls for your cloud environment. Maximum Security Zones is the preventative control, designed to stop you from making bad implementation choices that would weaken your security posture. When a problem cannot be prevented, Cloud Guard is the detective and remediation control, which identifies weak security posture and applies automatic remediation. I have already written a couple of articles covering Cloud Guard, which you can find here and here. So, within this article, I wanted to focus on Maximum Security Zones.

Let’s start by understanding the challenge. When you start a new project and build a new solution there is plenty of best practices guidance out there, from many different sources, such as:

  • Vendor recommendations
  • Organizational standards and policies
  • External frameworks
  • Regulatory compliance
  • Reference architectures

These best practices typically cover a range of different security topics, including authentication, encryption, storage, access control, etc. However, in many cases, best practices advice is ignored. We’ve all seen it many times: project timelines, budget constraints, knowledge gaps, and environments starting out as non-production, can all mean that the relevant best practices are not followed, leading to an insecure environment and a weak security posture.

The new Maximum Security Zones service within OCI aims to help you minimise this risk. A security zone is a preventative control, which, by nature of the fact that it contains sensitive data and resources, is restrictive by design. For example, Maximum Security Zones will release with a maximum security policy enabled. This takes the position that public access should not be allowed, and that sensitive data should be separated from the Internet as much as possible. The security policy enforces this position by preventing you, in real-time, from creating resources that would break this policy.

In case you aren’t familiar with Oracle Cloud Infrastructure, resources within OCI, such as compute instances, networks, storage etc., are logically grouped into compartments, which provide access control boundaries (as well as other things like budgeting and cost tracking). For example, I could be an administrator of compartment A and manage certain sets of resources in that compartment, but not have any access to resources in other compartments. This is relevant because a security zone is essentially a special compartment with the security zone policy attached to it. Once a security zone is created, operations are monitored in real-time against the control plane and blocked if they don’t meet the security policy.

Maximum Security Zones will come with a set of pre-defined policies, called recipes (the same term used by Cloud Guard). For its initial release, this recipe will enforce the maximum level of security protection. This will be the most restrictive policy and cannot be altered. In the future, you will be able to create customised versions of this policy if you have a need to adjust the maximum security. The following screenshot shows an example of some of the policies within the maximum security recipe.

Once you have your new security zone created, all policies will be enforced in-line, in real-time. You can see an example below where an attempt is made to create a new public subnet within the security zone.

Checks are not just done at resource creation time, but at any time when an action would weaken the security posture, as shown below when trying to unassign a customer-managed key from an object storage bucket.

In order to bring this to life, let’s take a simple example. Below, I have an internet-based application deployed. It has a load-balancer fronting two servers running my application, together with a back-end database and some object storage. As you can see, there are a number of issues with this basic design.

How would we build it differently with security zones? One example is shown below.

Here are some of the design decisions that have been taken, which are not specific to security zones.

  1. Separated the internet-facing components from the back-end, not just using subnets and security lists, but by separating the compartments completely into their own Virtual Cloud Networks, linked by a Local Peering Gateway
  2. Added Web Application Firewall to protect the load balancer, and ultimately the web application.
  3. Made the Autonomous Database and Object Storage only available over private IP addresses.
  4. Changed from using Oracle-managed keys to customer-managed encryption keys for all block, boot, and object storage.

So, what role does security zones play here?  Well, the security zone highlighted by the red box in the above diagram is enforcing that secure configuration. Some of the policy that is being enforced includes:

  1. All compute instances had to be created using a customer-managed key for encryption of the underlying storage.
  2. The object storage bucket had to be created using a customer-managed key for encryption.
  3. None of the customer-managed keys can be unassigned from any of the storage resources, i.e. you can’t go back to using Oracle-managed keys.
  4. The object storage buckets cannot be made public.
  5. The Autonomous Database had to be created with a private IP address and cannot be assigned a public IP address.
  6. All virtual machines had to be created with a private IP addresses and cannot be assigned public IP addresses.
  7. All virtual machines had to be created with an Oracle-provided platform image
  8. The subnet had to be private and no public subnets can be created.
  9. The block and boot volumes in the security zone cannot be attached to compute instances outside of the security zone

The above list is not exhaustive. You can refer to the Maximum Security Zones documentation for a complete list of out-of-the-box policies.

If you want to see security zones in action, click on the image below to see me demonstrating four simple use cases with security zones.

One thing you will notice about the above demonstration is that, due to the number of checks that Maximum Security Zones is doing, it can cause the administrator creating the resources to see a number of violation messages as different insecure operations are being checked and blocked. Not only can this lead to a less than ideal user experience, but for a less experienced administrator, these messages may cause confusion.

In order to address this and to further push towards Oracle’s vision to "Make security easier", alongside Maximum Security Zones, we have also released OCI Security Advisor, which is designed to provide you with a guided flow when creating resources such as compute resources, ensuring that they are created with a secure configuration the first time. 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.