When you create and update resources in a security zone, Oracle Cloud Infrastructure validates these operations against the policies in the security zone. If any policy is violated, then the operation is denied.
When you create a security zone you assign it a recipe, which is a collection of security zone
policies.
Your tenancy has a predefined recipe named Maximum Security Recipe, which includes a number of curated security zone policies. Oracle manages this recipe and you can't modify it. You can, however, create your own recipes that meet your specific security requirements.
Security Zones categorizes policies by security principle, such as Restrict Resource Movement. Each policy affects one or more cloud resources, such as Compute, Networking, Object Storage, and Database resources.
To ensure the integrity of your data, certain resources in a security zone can't be moved to a compartment that is outside of the security zone because it might be less secure. You also can't move an existing resource to a compartment in a security zone unless all policies in the securitry zone are met.
The following table describes the security zone
policies that restrict resource movement.
Database (Bare metal and virtual machine DB systems, Exadata DB
systems)
You can't move a database to the security zone if its Data Guard association isn't in the same security zone.
Restrict Resource Association 🔗
All the required components for a resource in a security zone must also be located in the same security zone. Resources that are not in
a security zone might be vulnerable, and resources in a different security zone might have a lower security posture.
The following table describes the security zone
policies that restrict resource association.
Exadata Infrastructure resources in the security zone can't be associated with Container Databases or VM clusters that
aren't in the same security zone.
Deny Public Access 🔗
Resources in a security zone must not be accessible from the public
internet.
When you create a private subnet , compute instances launched in that subnet can't
have public IP addresses. This restriction ensures that compute instances in the subnet have no internet access. For compute instances in
a private subnet, a service gateway enables private access to public services such as Object Storage. See Overview of Networking.
The following table describes the security zone
policies that restrict network access.
Policy
Resource Types
Description
deny public_subnets
Virtual Network (VCN)
Subnets in the security zone can't be public. They must be private.
deny internet_gateway
Virtual Network (VCN)
You can't add an internet gateway to a VCN (virtual cloud network) within the security zone.
deny public_buckets
Object Storage
Object Storage buckets in the security zone can't be public.
deny
db_instance_public_access
Database (all types)
Databases in the security zone can't be assigned to public subnets. They must use private subnets.
deny public_load_balancer
Load Balancer
Load balancers in a security zone can't be public. All load balancers must be private.
deny cloud_shell_public_network
Cloud Shell
Cloud Shell hosts in a security zone can't have public network access.
Require Encryption 🔗
Resources in a security zone must be encrypted using customer-managed keys. Data must
be encrypted while in transit and at rest.
Oracle Cloud Infrastructure Vault lets you manage
the master encryption keys that protect your data and the secret credentials that you
use to securely access resources. You can also regularly rotate encryption keys.
Many services integrate with the Vault service for encryption, including Object Storage
and Block Volume.
The following table describes the security zone
policies that enforce encryption.
Policy
Resource Types
Description
deny
block_volume_without_vault_key
Block Storage
Block volumes in the security zone must use a customer-managed master encryption key in
the Vault service. They can't use the default encryption key managed by Oracle.
deny
boot_volume_without_vault_key
Block Storage
Boot volumes in the security zone must use a customer-managed master encryption key in the Vault service. They can't use the default encryption key managed by Oracle.
deny
buckets_without_vault_key
Object Storage
Object Storage
buckets in the security zone must use a customer-managed master encryption key in the Vault service. They can't use the default encryption key managed by Oracle.
deny
file_system_without_vault_key
File Storage
File systems in the security zone must use a customer-managed master encryption
key in the Vault service. They can't use the default encryption key managed by
Oracle.
Ensure Data Durability 🔗
Automatic backups must be performed regularly for resources in a security
zone.
The following table describes the security zone
policy that enforces data durability.
Policy
Resource Types
Description
deny
database_without_backup
Database (Bare metal and virtual machine DB systems, Exadata DB
systems)
Databases in the security zone must be configured to perform automatic backups.
You can't clone a file system in a security zone to create a file system that isn't in the same security zone.
Use Only Configurations Approved by Oracle 🔗
Oracle requires certain security features to be enabled and configured for the resources within a security zone. One example is the
operating system configuration for a compute instance (Compute) .
The following table describes the security zone policies that require configurations that
are approved by Oracle.
Policy
Resource Types
Policy Description
deny
instance_without_sanctioned_image
Compute, Compute Management
You must create a compute instance in the security zone using a platform image.
You can't create a compute instance in the security zone from a custom
image.