Current Challenge
Customer Engineer responsible for provisioning cloud resources might not be aware or not well trained for how to use the best security configuration as part of their cloud implementation. If the security is not follow during the starting phase then it always become very difficult to address later during the the cloud go live and often it became the reactive approach. The proactive approach to address the security from starting were missing in many CSP providers.
Oracle is helping to shift more of the security responsibilities from the customer to the cloud provider.
Oracle OCI Gen2 Cloud built from ground level Built In Security Always On with Zero Trust Security Model
Oracle Security Zones
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.
Security Zones let you be confident that your resources in Oracle Cloud Infrastructure, including Compute, Networking, Object Storage, and Database resources, comply with Oracle security principles.
Access the Security Zone in OCI
Security zone An association between a compartment and a security zone recipe. Resource operations in a security zone are validated against all policies in the recipe.
Security zone recipe A collection of security zone policies.
Security zone policy A security requirement for resources in a security zone.
When you create and update resources in a security zone, OCI validates these operations against the list of policies defined in the security zone recipe.
High Level Proposed Architecture
Creating Security Zone
Your tenancy has a predefined recipe named “Maximum Security Recipe”, which includes all available security zone policies. Oracle manages this recipe and you can’t modify it.
In general, security zone policies align with these security principles:
- Resources can’t be moved from a security zone to a standard compartment because it might be less secure
- Data in a security zone can’t be copied to a standard compartment because it might be less secure.
- All the required components for a resource in a security zone must also be located in a security zone. Resources that are not in a security zone might be vulnerable. For example, a compute instance in a security zone can’t use a boot volume that is not in a security zone.
- Resources in a security zone must not be accessible from the public internet.
- Resources in a security zone must be encrypted using customer-managed keys.
- Resources in a security zone must be regularly and automatically backed up.
- Resources in a security zone must use only configurations and templates approved by Oracle.
A security zone policy differs from an IAM policy in the following ways:
- Administrators create IAM policies to grant users the ability to manage certain resources in a compartment.
- A security zone policy ensures that these management operations comply with the Oracle maximum security architecture and best practices.
- A security zone policy is validated regardless of which user is performing the operation.
- A security zone policy denies certain actions; it doesn’t grant capabilities.
- Administrators can’t create, modify, or disable security zone policies.
Verify the Security Zone
- You can’t create the bucket without customer managed keys.
It is suggesting you to follow the workflow to create secure bucket.
2. You can’t create the public bucket in security zone.
3. You can’t move the bucket from security zone to standard compartment.
4. You can’t add Internet Gateway in Security zone
Thank you for visiting this blog.
Disclaimer : The views expressed on this blog are my own and do not reflect the views of the companies I work, The opinions give by visitors on this site are there own opinions.
