Security Policy Examples

Create Service-level Admins for Least Privilege

To implement security principle of least privilege, you can create service-level admins in the tenancy to further scope down administrative access. This means that service-level administrators can only manage resources of a specific service. For instance, network administrators need administrative (manage) access only to VCN resources, and not to other resources. The following example shows how to create administrator groups for block storage (VolumeAdmins), VCN (NetworkAdmins), databases (DBAdmins), and object storage (StorageAdmins).

Allow group TenancyAdmins to manage all-resources in tenancy
Allow group VolumeAdmins to manage volume-family in tenancy
Allow group NetworkAdmins to manage virtual-network-family in tenancy
Allow group StorageAdmins to manage object-family in tenancy
Allow group DBAdmins to manage database-family in tenancy

You can further constrain the security policies to a specific compartment. For example, the HR department in an enterprise can create group HRAdmins to manage resources within its compartment, HR-compartment. The HRNetworkAdmins group has administrative access to VCN resources only within the HR-compartment compartment.

Allow group HRAdmins to manage all-resources in compartment HR-compartment
Allow group HRNetworkAdmins to manage virtual-network-family in compartment HR-compartment

Compliance auditors are tasked with examining cloud resources and verifying for policy violations. The following policy allows group InternalAuditors to inspect (list) all resources in a tenancy.

Allow group InternalAuditors to inspect all-resources in tenancy

If you want to limit auditors to only inspect users and groups in a tenancy, you can create a group UserAuditors with the following policy:

Allow group UserAuditors to inspect users in tenancy
Allow group UserAuditors to inspect groups in tenancy

If you want to create an auditor group that can only inspect VCN firewalls in the tenancy, use the following policy:

Allow group FirewallAuditors to inspect security-lists in tenancy

In all the policy examples, you can constrain the policies to a compartment by specifying Compartment <name> (where <name> is the compartment name) in the policy.

Restrict Ability to Change Tenancy Administrators Group Membership

Members in the group Administrators can manage all resources in a tenancy. Membership of the Administrators group is controlled by users in the group. Usually, it's convenient to have a group to create and add users in the tenancy, but restrict them from making changes to the Administrators group membership. The following example creates a group UserAdmins to do this.

Allow group UserAdmins to inspect users in tenancy
Allow group UserAdmins to inspect groups in tenancy
Allow group UserAdmins to use users in tenancy
 where target.group.name!='Administrators'
Allow group UserAdmins to use groups in tenancy
 where target.group.name!='Administrators'

Use verb with conditions (third and fourth policy statements) allows UserAdmins to add users and groups using APIs (UpdateUser, UpdateGroup) to all groups in the tenancy except the Administrators group. However, because target.group.name!='Administrators' is not related to the list and get APIs (ListUsers, GetUser, ListGroups, and GetGroup), these APIs will fail. So you must explicitly add the inspect verb (first and second policy statements) to allow UserAdmins to get user and group membership information.

Prevent Delete or Update of Security Policies

The following example creates a group PolicyAdmins to be able to create and list security policies created by tenancy administrators, but not delete or update them.

Allow group PolicyAdmins to use policies in tenancy
Allow group PolicyAdmins to manage policies in tenancy
 where request.permission='POLICY_CREATE'

This security policy statement explicitly only allows POLICY_CREATE permission, and not to POLICY_DELETE and POLICY_UPDATE.

Prevent Admins from Accessing or Altering User Credentials

Some compliance requirements need separation of duties, especially where user credential management functionality is separated from tenancy management. In this case, you can create two administration groups, TenancyAdmins and CredentialAdmins where TenancyAdmins can perform all tenancy management functions except user credential management, and CredentialAdmins can manage user credentials. TenancyAdmins can access all APIs except those that list, update, or delete user credentials. CredentialAdmins can only manage the user credentials.

Allow group TenancyAdmins to manage all resources in tenancy
 where all {request.operation!='ListApiKeys',
            request.operation!='ListAuthTokens',
            request.operation!='ListCustomerSecretKeys',
            request.operation!='UploadApiKey',
            request.operation!='DeleteApiKey',
            request.operation!='UpdateAuthToken',
            request.operation!='CreateAuthToken',
            request.operation!='DeleteAuthToken',
            request.operation!='CreateSecretKey',
            request.operation!='UpdateCustomerSecretKey',
            request.operation!='DeleteCustomerSecretKey'}
Allow group CredentialAdmins to manage users in tenancy
 where any {request.operation='ListApiKeys',
            request.operation='ListAuthTokens',
            request.operation='ListCustomerSecretKeys',
            request.operation='UploadApiKey',
            request.operation='DeleteApiKey',
            request.operation='UpdateAuthToken',
            request.operation='CreateAuthToken',
            request.operation='DeleteAuthToken',
            request.operation='CreateSecretKey',
            request.operation='UpdateCustomerSecretKey',
            request.operation='DeleteCustomerSecretKey'}