Oracle Cloud Infrastructure Documentation

Enabling Instance Security

Enable Instance Security in Cloud Guard.

To enable Instance Security in your tenancy:

Applying an Instance Security Recipe to a New Cloud Guard Target

  1. Open the navigation menu and click Identity & Security. Under Cloud Guard, click Configuration.
  2. Under Targets click Create new target.
  3. On the Create target page, Basic information panel, enter a Target name and an optional Description for the target.
  4. Select the Compartment to assign to the target.
  5. Click Next.
  6. On the Configuration panel, under Instance Security recipe select All compute instances and choose one of the Oracle-managed Instance Security detector recipes:
    • OCI Instance Security Detector Recipe—Enterprise (Oracle managed)
    • OCI Instance Security Detector Recipe (Oracle managed)
    See Instance Security Detector Recipes.
  7. Review the new target, and click Create.
  8. On the Configuration page, click the Instance Security tab. You can see the Instance Security detector recipe you have applied to the new target. Scroll to the bottom and next to Logging, click Enable/Edit.
  9. For each region you want, click the Actions menu (actions menu) and select Enable Log.
    1. On the Enable log panel, the compartment the target is in is shown. You cannot change it.
    2. Choose an existing log group, or create a new one by clicking Create new group. See Log Group Management.
    3. Choose how long the log to keep the log, for values between 30 days and 180 days, or set a custom log retention value.
    4. Click Enable log.

The final step of enabling Instance Security is to add the policy statements in the Console.

Applying an Instance Security Recipe to a Cloud Guard Target

  1. Open the navigation menu and click Identity & Security. Under Cloud Guard, click Configuration.
  2. Locate the target that you want to use and click the target name.
  3. Under Configuration, click the Instance Security tab and click Add recipes and choose one of the Oracle-managed Instance Security detector recipes:
    • OCI Instance Security Detector Recipe—Enterprise (Oracle managed)
    • OCI Instance Security Detector Recipe (Oracle managed)
    See Instance Security Detector Recipes.
  4. Accept the prompt to add the Instance Security policies to your environment.
  5. In the Add detector recipes dialog, choose the Oracle-managed Instance Security detector recipe you want to use and click Add recipes.
  6. Scroll to the bottom and next to Logging, click Enable/Edit.
  7. For each region you want, click the Actions menu (actions menu) and select Enable Log.
    1. On the Enable log panel, the compartment the target is in is shown. You cannot change it.
    2. Choose an existing log group, or create a new one by clicking Create new group. See Log Group Management.
    3. Choose how long the log to keep the log, for values between 30 days and 180 days, or set a custom log retention value.
    4. Click Enable log.

The final step of enabling Instance Security is to add the policy statements in the Console.

Policy Statements for Instance Security

You must add these policies in the Console as part of enabling Instance Security.

The policies let the Instance Security agent access the required resources in the tenancy, and without these policies you won't get any results.

For information about how to enter the policy statements in the Console, see Creating a Policy.

User Policy Statements

These policies provide user permissions to use Instance Security for on-demand queries and scheduled queries. Add them to your user policies, replacing group with the name of an appropriate group of users.

Allow group <group> to { INSTANCE_READ } in compartment <compartment>
Allow group <group> to { WLP_ADHOC_QUERY_READ} in compartment <compartment>
Allow group <group> to { WLP_ADHOC_QUERY_CREATE} in compartment <compartment>
Allow group <group> to { WLP_ADHOC_QUERY_INSPECT } in compartment <compartment>
Allow group <group> to { WLP_ADHOC_QUERY_DELETE } in compartment <compartment>
Allow group <group> to { CG_ADHOC_QUERY_READ} in compartment <compartment>
Allow group <group> to { CG_ADHOC_QUERY_CREATE} in compartment <compartment>
Allow group <group> to { CG_ADHOC_QUERY_INSPECT } in compartment <compartment>
Allow group <group> to { CG_ADHOC_QUERY_DELETE } in compartment <compartment>
Allow group <group> to  { CG_DATA_SOURCE_INSPECT} in compartment <compartment>
Allow group <group> to  { CG_DATA_SOURCE_READ } in compartment <compartment>
Allow group <group> to  { CG_DATA_SOURCE_CREATE } in compartment <compartment>
Allow group <group> to  { CG_DATA_SOURCE_DELETE } in compartment <compartment>

Service Logging Policy Statements

These policies let users access logs. Add them to your user policies, replacing group with the name of an appropriate group of users.

Allow group <group> to { CG_SERVICE_LOGGING_READ } in compartment <compartment>
Allow group <group> to { CG_SERVICE_LOGGING_CREATE } in compartment <compartment>
Allow group <group> to { CG_SERVICE_LOGGING_UPDATE } in compartment <compartment>
Allow group <group> to { CG_SERVICE_LOGGING_DELETE } in compartment <compartment>

Tenancy Policy Statements

These policies let Instance Security access the required resources in the tenancy.

Allow any-user to { WLP_BOM_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { WLP_CONFIG_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { WLP_ADHOC_QUERY_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { WLP_ADHOC_RESULTS_CREATE } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Endorse any-user to { WLP_LOG_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_METRICS_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_ADHOC_QUERY_READ } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_ADHOC_RESULTS_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }

Using Dynamic Groups to Control Access to On-Demand and Scheduled Queries

You must create dynamic groups to work with on-demand (ad hoc) and scheduled queries. The resource type is:

  • For on-demand queries, cloudguardadhocquery.
  • For scheduled queries, cloudguarddatasource.
Note

  • Each query is automatically linked to a dynamic group based on the resource type and optional tags.
  • Access is determined by the dynamic group that the query belongs to.
  • If no policies exist for a query then it gets an unauthorized exception when the query is run.

This example shows how to create a dynamic group for each type of query. For more information, see Managing Dynamic Groups.

  1. Create the dynamic groups:
    Dynamic Group Dynamic Group Statement
    adhoc_query_dg all { resource.type = 'cloudguardadhocquery', resource.compartment.id = 'my-compartment-id'}
    scheduled_query_dg all { resource.type = 'cloudguarddatasource', resource.compartment.id = 'my-compartment-id' }
  2. Next, write policies to grant the read instance access to the newly created dynamic groups.
    
allow dynamic-group adhoc_query_dg to read instances in compartment my-compartment where all { request.principal.type = 'cloudguardadhocquery' }
allow dynamic-group scheduled_query_dg to read instances in compartment my-compartment where all { request.principal.type = 'cloudguarddatasource' }
  3. Now, you can create queries:

Using Tags to Isolate Query Permissions

You can use tags to isolate and categorize scheduled queries you are running. For more information about using tags, see Tagging.

Note

To use tags, you must create the on-demand or scheduled queries using CLI or API.
  1. Create the dynamic groups with tags:
    Dynamic Group Dynamic Group Statement
    adhoc_query_dg all { resource.type = 'cloudguardadhocquery', resource.compartment.id = 'my-compartment-id', tag.namespace.tag-key.value = 'tag-value' }
    scheduled_query_dg all { resource.type = 'cloudguarddatasource', resource.compartment.id = 'my-compartment-id', tag.namespace.tag-key.value = 'tag-value' }

    For example, suppose you have a tag namespace called "Departments" and a tag in that namespace called "department_type" with a values list of ["hr", "finance", "marketing", "it"]. The dynamic group statement for a custom query would be

    all { resource.type = 'cloudguardadhocquery', resource.compartment.id = 'my-compartment-id', tag.department_type.tag-key.value = 'finance' }
  2. Write policies to grant the read instance access to the newly created dynamic groups.
    
allow dynamic-group adhoc_query_dg to read instances in compartment my-compartment where all { request.principal.type = 'cloudguardadhocquery' }
allow dynamic-group scheduled_query_dg to read instances in compartment my-compartment where all { request.principal.type = 'cloudguarddatasource' }
  3. Now, you can create queries using CLI or API with the tags you've defined: