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.