Security Zones enforce security posture on OCI cloud compartments and prevent actions that could weaken a customers’ security posture. Security Zone policies can be applied to various cloud infrastructure types (network, compute, storage, database, etc.) to ensure cloud resources stay secure and prevent security misconfigurations.
Security Zones extends the scope of security posture management beyond monitoring and visibility to active enforcement of resource-based security policy. Users determine which policies are appropriate for their needs by defining Custom Security Zone policy sets.
A Security Zones recipe is a collection of Security Zones policies defined as a template that can be applied to one or more compartments. A Security Zone recipe defines a security policy set which limits allowable actions on cloud resources. A policy set consists of one or more security policy statements which address the security posture of cloud resources.
Maximum Security Zone is a pre-defined recipe managed by Oracle. This recipe includes policies that maximize configuration for a strong security posture. While the Maximum Security Zone recipe includes a broad set of security policies, in practice, organizations typically adjust the scope of policies applied to reflect their specific needs.
Yes. The number of Security Zones that can be created is only limited by the Compartment limit in your tenancy.
Not necessarily, but Security Zones can be used to prevent configuration changes that lead to a weakened security posture.
Custom Security Zones provides the ability to select which Security Zone policies apply to a zone. In addition, you can remove or replace an existing Security Zone at any time.
Customers cannot create their own policies. Customers have access to an extensive list of policies provided by Oracle. New policies will be added over time.
Resources inside Security Zones are identical to their equivalents outside of a Security Zone. The only difference is the enforcement of the security policies for their settings and configuration. These resources can be accessed using the same methods, tools, and permissions as regular resources.
A Security Zone will override an identity access management policy that allows access. For instance, even if a user has permission to manage a bucket, they cannot set a bucket to public in a Security Zone when the policy statement “Deny public buckets” is applied.
Security Zones do not directly manage access restrictions to the resources that are in them. Resources within a Security Zone can still be accessed using any previous method used provided such access does not conflict with set Security Zone policy.
A secure method of connection is required to cross a Security Zone boundary and transfer data. Methods to create a secure connection include the use of a Bastion Server- which can be easily configured and deployed from the Console using OCI Bastion.
Security Zones enforce security policies on compartments. Cloud Guard monitors the security posture of infrastructure and applications. With Custom Security Zones, Cloud Guard and Security Zones have been integrated to provide automatic security posture monitoring of compartments when a Security Zone is applied. Problems that are detected within a Security Zone are reflected in both the Security Zones and Cloud Guard console UIs.
Yes, any type of resource can be created in a Security Zone. Security Zones will enforce policy only when a resource type within a zone is associated with the Security Zone policy applied to a compartment.
Security Zones is a free service; however, resources within a Security Zone will have their usual charges.
A Security Zone can be removed at any time using the OCI Console or API.
Security Zones is available across all commercial regions.
Security Zone policies are enforced on Autonomous Database, bare metal databases, VM Databases, and Exadata. Security Zone policies are not available for Exadata Cloud@Customer Databases.