Isolate Resources and Control Access

Resource isolation is a key consideration when organizing your cloud resources. Compartments enable you to logically organize your resources and control access to them in a manner that's meaningful to your business. For example, you can isolate the resources used by each department of your company in a separate compartment. You can also use virtual cloud networks (VCNs) to isolate resources at the network layer.

You should plan your compartments and VCNs carefully, keeping in mind the current and future security requirements of your organization. The recommendations in this article will help you to meet your requirements.

Organize Resources Using Compartments and Tags

Enterprise Architect, Security Architect, Application Architect

Compartments and tags are useful tools for organizing and isolationg resources for access control.
  • Create and designate compartments for specific categories of resources, and write IAM policies to allow access to the resources to only the groups of users that need access to them.
  • Separate production and non-production workloads into separate compartments.
  • Create and use child compartments to isolate resources for additional organizational layers. Write separate policies for each compartment level.
  • Allow only authorized users to move compartments to different parent compartments and to move resources from one compartment to another. Write suitable policies to enforce this restriction.
  • Limit the number of resources of each type that can be created in a compartment by setting compartment-level quotas.
  • Avoid writing IAM policies at the level of the root compartment.
  • Limit the resources that an instance principal can manage by specifying a compartment in the IAM policy.
  • Assign tags to resources to organize and identify them based on your business needs.

Implement Role-Based Access Control

Enterprise Architect, Security Architect, Application Architect

Restrict access by assigning privileges by role.
  • Limit the access privileges for users in each group to only the compartments that they need to access, by writing compartment-level policies.
  • Write policies that are as granular as possible in terms of the target resources and the required access privileges.
  • Create groups with permissions to do tasks that are common to all your deployed workloads (such as, network administration and volume administration), and assign appropriate admin users to these groups.

Don't Store User Credentials on Compute Instances

Enterprise Architect, Security Architect, Application Architect

When you want to authorize a compute instance to make calls to the Oracle Cloud Infrastructure APIs, don't store any user credentials on the instance. Instead, designate the instance as an instance principal.

The certificates required for the instance to authenticate itself are created automatically, assigned to the instance, and rotated. You can group such instances in logical sets, called dynamic groups, and write policies to allow the dynamic groups to perform specific actions on specific resources.

Harden Login Access to Compute Instances

Enterprise Architect, Security Architect, Application Architect

Ensure that only secure methods are used to log in to compute instances.
  • Disable password-based login.
  • Disable root login.
  • Use only SSH key-based authentication.
  • Leverage Security Groups and Security Lists to restrict access based on source IP address.
  • Disable unnecessary services.

Secure Cross-Resource Access

Enterprise Architect, Security Architect, Application Architect

If you designate any instances as principals, then review the users and groups that have access to such instances. Make sure that only the appropriate users and groups can access them.

Isolate Resources at the Network Layer

Enterprise Architect, Security Architect, Application Architect

Virtual cloud networks provide the first level of network isolation between resources in Oracle Cloud Infrastructure.
If you have multiple workloads or different departments/organizations, use different VCNs for each to isolate the resources at the network layer.
Use VCN-peering where required. In addition, use public and private subnets carefully, after evaluating which resources require public access.
  • Leverage Load Balancers to publicly expose services, and place backend targets on private subnets.
  • Leverage Security Groups to enforce application micro segmentation for each tier of the application.
  • Whitelist required east/west traffic inside a VCN, do not allow traffic flows unless they are required.

Define Maximum Security Zones

Enterprise Architect, Security Architect, Application Architect

Maximum Security Zones enforce security policies for compartments in Oracle Cloud Infrastructure. They include a policy library and embedded security best practices to enable cloud security posture management.
  • Enable Maximum Security Policy for production resources on private subnets in their own VCN and Compartment.
  • Separate Internet-facing components in a separate VCN with a public subnet, and link it to the Maximum Security Zone VCN with a Local Peering Gateway. Additionally, add a Web Application Firewall to protect the Internet-facing components, like Load Balancers.
  • Use Oracle Security Advisor to facilitate creation of resources in a Maximum Security Zone.