Oracle Security Zones is a service that helps ensures customers implement Oracle's best practices for security by enforcing them from the start and removing the chance of configuration drift or someone violating them later. This brings clarity regarding what is needed to meet their security needs and removes guesswork from the equation when it comes to implementation.
A Security Zones recipe is a curated collection of policies. A recipe defines a set of security best practices is enforced in a Security Zone.
Maximum Security Zone is a pre-defined recipe managed by Oracle. This recipe includes policies that maximize configuration for a strong security posture.
Yes. The number of Security Zones that can be created is only limited by the Compartment limit in your tenant.
Not necessarily, but Security Zones prevents configurations that lead to a weakened security posture.
Security Zones will be initially released supporting our most stringent recipe: Maximum Security Zone. While we recognize that this may not work in every instance, customization in the form of the ability to select which Security Zone policies apply to a zone will be a future release.
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 best practices policies for their settings and configuration. These resources can be accessed using the same methods, tools, and permissions as regular resources.
Security Zones do not directly manage access restrictions to the resources that are in them. These resources can still be accessed in any method that can be configured under the limitations set by the Security Zone recipe associated with that zone. Elaborating on this, some resources in Security Zones can access others in different Security Zones, and some cannot. This is depending on each resource settings and configuration.
A secure method of connection is required to cross the proverbial border of a Security Zone and transfer data. There are several methods to create a secure connection, such as a bastion.
Security Zones policies are enforced upon creation of the zone. Cloud Guard requires customer to enable the service and select compartments to be monitored. Cloud Guard looks for specific user activity or configuration state. Some detectors are the inverse of a Security Zone policy. For example, one cannot set a bucket to public in a Security Zone. Cloud Guard has a detector which can detect a bucket being set to public, and can then alert and remediate.
Yes, any type of resource can be created in a Security Zone, however Security Zones will take action only if a relevant recipe to that resource type is associated with the zone. It's important to note that the list of Security Zone recipes and policies will be updated with more added to allow more types of resources to be managed with security best practices.
No. Security Zones only work for Oracle Cloud Infrastructure resources.
Security Zones is a free service; however, resources within a Security Zone will have their usual charges.
A Security Zone cannot be disabled. An empty Security Zone can be deleted.
A Security Zone must have all resources removed before it can be deleted. An empty Security Zone can be deleted by pressing the ‘Delete’ button on the Security Zone details page.
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.
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.