OCI Security Zones are not a new feature, they have been available since 2020.  Security zones ensure that your OCI resources comply with your security policies, including Oracle Cloud Infrastructure Compute, Oracle Cloud Infrastructure Networking, Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure Block Volumes, and Database resources.  OCI provides a Maximum Security Zone recipe that can be customized by customers to meet their desired security level.  Customization does not mean customers can create their Security Zone policies.  Customization means that customers have the ability to select the delivered Security Zone policies to create a custom Security Zone recipe.  Customers can view the delivered policies in OCI Documentation.

There are some key factors that should be considered when designing the OCI tenancy compartment structure when combining Security Zones:

• Service Limit – Maximum of 50 Security Zones per region
• Security Zone member limit – A compartment can only be a member of one security zone and one security zone recipe

OCI accounts for these limits in the CIS Landing Zone terraform template.  The landing zone creates a top-level compartment under root.  The Security Zone is applied to the top-level compartment and all sub compartments under the top-level landing zone compartment are automatically included in the Security Zone.

With the Landing Zone, customers can define a custom recipe, based on CIS standards that can be mapped to other security standards like PCI, PII, Sox, etc.  The recipe can be applied to the top-level compartment and all of the sub compartments will inherit the recipe. 

What happens if application 1 requires additional security policies as the data being stored has changed?  The options are as follows:

1. Change the Security Zone Recipe for the Landing Zone – this option now applies the new security zone policies to all of the sub compartments
2. Remove the application from the security zone and apply a different security zone and recipe – this option limits the additional security controls to the specific compartment but the compartment is no longer logically organized win the security zone hierarchy
3. Migrate the application to another landing zone – move the application compartment to another landing zone with a security zone recipe that meets the new security requirements.  This option keeps the compartments organized by security zone but has the added overhead of migrating the compartment.

OCI does not currently allow customers to create their own security zone recipe policies but OCI will continue adding policies to the provided maximum security zone recipe.  Customers will need to review and update any custom recipes they create to take advantage of added policies. 

I have started to see more use cases for incorporating OCI Security Zones in the areas of Government Cloud, High Performance Compute (applying AI to sensitive data) and customers with decentralized cloud operations (provide application autonomy but ensuring security controls are in place).  I have now incorporated Security Zones as a discussion point when designing customer tenancy’s because as you have read, it can have an impact on the compartment design and if incorporated, needs to be accounted for as part of the operation (maintenance of recipes, number of recipes, how compartments are organized with recipes, etc) of an OCI tenancy.