Define and enforce config rules on your Key Protect instances.

With the IBM Cloud Security and Compliance Center, you can embed security checks into your everyday workflows to prevent and monitor for security and compliance. By creating config rules, IBM Cloud customers can enforce resource configuration across accounts and use monitoring results to prove compliance for your organization. Config rules are guardrails for resources on how they are provisioned and configured. For example, IBM Cloud administrators can disable public access to resources in production accounts but allow it in testing accounts. Through config rule enforcement, you can manage the resources in your account with confidence that they adhere to the guidelines that are in place for your organization, which can significantly decrease the likelihood of a misconfiguration that could leave you vulnerable.

In this tutorial, learn how to create and manage rules that govern the way that resources can be configured across accounts. The focus of this tutorial will be on enforcing the use of only private networks for your IBM Key Protect for IBM Cloud instances in the Dallas region. To use another region or work with another service, check out the docs to see the available configurations.

Before you begin

Before you get started, be sure that you have the following prerequisites:

• An IBM Cloud account. 
• The required level of access to view and manage rules. To create a rule, you need the editor platform role or higher. For more information, see Assigning access.
• An instance of Activity Tracker set up for the Dallas region in your account.

Step 1. Create a config rule

You can create rules by using the Security and Compliance Center UI.

1. Navigate to the Security and Compliance Center on IBM Cloud. 
2. Click Configure > Rules. 
3. Click Create.
4. Give your rule a meaningful name and description such as KP disable public endpoint and Rule to enforce private only network policy for Key Protect instances.
5. Click Next. Select the Key Protect service and instance resource kind. The available configuration properties for this resource kind are shown to the right of the JSON editor. 
6. Use the JSON editor to set the following properties:
   • property: allowed_network
   • operator: string_equals
   • value: private_only
7. Your final rule will look like this:

   {
     target: {
       service_name: 'kms',
       resource_kind: 'instance',
       additional_target_attributes: []
     },
     required_config: {
       description: '',
       and: [
         {
           property: 'allowed_network',
           operator: 'string_equals',
           value: 'private-only'
         }
       ]
     }
   }

8. Enable enforcement to prevent creation of a Key Protect instance with a public endpoint and click Next.
9. Click Create and attach.

Step 2. Attach a rule

A rule is not in effect until it is attached to a scope. You can choose to attach your rule to your entire enterprise, specific resource group(s) or you can choose to exclude resource groups. If you attach a rule to your entire enterprise, the rule is applied to the target resources that exist within the enterprise. Likewise, if you limit a rule to a specific account group, its properties are inherited by the accounts that exist in that group. You can choose to exclude scopes, such as accounts that are used for testing, so that your rule is applied only where you need it. To attach your rule to a scope, complete the following steps:

1. Click the Attach button.
2. Under Select scope, choose your Entire account or the Specific resource group where your Key Protect instances will be provisioned.
3. Click Attach.

Congrats! You have successfully created a rule and attached it to a scope.

Step 3. Seeing the rule in action

When a user makes a request to create a Key Protect service instance in your account, the request will be evaluated against the conditions that you defined in your config rule. If the account user creates the instance over a private network, Key Protect allows the action to complete because it is compliant with your rule. But, if the account user creates the instance over a public network, Key Protect blocks the request. To see it in action, try it out in the Key Protect UI or check out the following gif:

1. Navigate to the catalog and search for Key Protect.
2. Once on the Key Protect creation page, give your instance a meaningful service name, such as KP Private Endpoint.
3. Set the location to Dallas (us-south).
4. Under Allowed network policy, select Public and private.
5. Click Create.
6. You will see an error message indicating the requested action of creating a Key Protect instance with the public and private network policy is noncompliant with your config rules.
7. Dismiss the error message and change the Allowed Network Policy to Private only.
8. Click Create.
9. Your Key Protect instance was successfully created.

Now that you have created a rule and a Key Protect instance, you can use the Security and Compliance Center to continuously monitor your rule and any noncompliant resources. Results are generated every 24 hours and can be viewed on the results page. To learn more, visit Viewing evaluation results.

Step 4. Viewing audit events

Whenever a user attempts to make an update to a resource in your account that is governed by a config rule, an event is forwarded to the IBM Cloud Activity Tracker service instance that is available in the same location. The Activity Tracker logs can be used as part of your audit evidence to prove that you are compliant with the external regulations that are required for your industry. To view the events that are logged, you can use the Activity Tracker UI:

1. Open the Activity Tracker service instance that is available in Dallas (us-south). For help getting to the UI, see Launching the web UI through the IBM Cloud UI.
2. Filter for events based on specific fields by creating a query in Activity Tracker that takes the following form: action:compliance.configuration-governance-resource.eval <additional field>. Review the following additional fields and append the filter to create your query:
   • To see how often your config rules are compliant: compliance.isCompliant:true
   • To see how often your resources that are governed with config rules are allowed to be modified: compliance.isAllowed:true
   • To see how often resources are evaluated as noncompliant: compliance.isCompliant:false
   • To see how often a resource is prevented from being modified or provisioned due to an existing config rule: compliance.isAllowed:false

Tip: Filtering to see how often resources are evaluated as noncompliant is useful to see how big of an impact enabling enforcement on a config rule will have in your account.

In the following example, you can see the truncated result of a query for: action:compliance.configuration-governance-resource.eval compliance.isCompliant:true compliance.isAllowed:true

{
    "action": "compliance.configuration-governance-resource.eval",
    "compliance": {
        "complianceTraceId": "0074b9f4-5cfb-4f11-a79e-a8807c8rb587",
        "evaluationType": "enforcement",
        "isAllowed": true,
        "isCompliant": true,
        "requestedConfig": {
            "allowed_network": "private-only"
        },
        "resource": {
            "accountId": "41e15133687ece0e45sfg9234de172u1138d",
            "crn": "crn:v1:staging:public:kms:us-south:a/41e15133687ece0e45sfg9234de172u1138d:b3a34724-9e02-494a-ab4c-6d02a2df7aa7::",
            "id": "b3a34724-9e02-494a-ab4c-6d02a2df7aa7",
            "location": "us-south",
            "name": "",
            "resourceGroupId": "e9ea11d38d1f4405a98c57de67bfaa7d1",
            "resourceKind": "instance",
            "serviceName": "kms"
        },
        "rulesAllowedCount": 1,
        "rulesCompliantCount": 1,
        "rulesEvaluatedCount": 1,
        "subRequestId": "b7bc1b04-32d2-4612-b95a-807028e42593",
        "updatedConfig": {
            "allowed_network": "private-only"
        },
        "userId": "test"
    },
    "target": {
        "id": "crn:v1:staging:public:kms:us-south:a/41e15133687ece0e45sfg9234de172u1138d:b3a34724-9e02-494a-ab4c-6d02a2df7aa7::",
        "typeURI": "kms/instance"
    }
    "correlationId": "0024b91f-5cfb-4f11-a7d9-a8807c8ab548",
    <...truncated>
}

Because you attempted to create an instance of Key Protect twice, you will see two events: 

• A noncompliant event from the blocked action in step 3.5
• A compliant event from the allowed action in step 3.8.

Summary

By completing this tutorial, you performed the following tasks:

• Created a config rule and attached it to a scope
• Blocked creation of a Key Protect instance which was noncompliant with your newly created rule
• Viewed audit events for noncompliant and compliant resource configuration changes