Updated on 2024-11-20 GMT+08:00

Controlling Changes

When changing resources, you can only use the service ticket-based privilege escalation method to execute scripts, jobs, or query accounts and passwords. This ensures that the operator and operation object of a change ticket match the actual resources you want to change, preventing excessive permissions of the operator and reducing security risks.

Scenarios

You can configure whether to enable privilege escalation using a service ticket based on application scenarios. Currently, privilege escalation using incidents, war rooms, and change tickets are supported.

Precautions

1. By default, the change control policy generated by COC can only be bound to user groups for further permissions granting. Do not use the policy for other purposes.

2. You can click the editing button of actions on the COC page to control whether to determine whether to control functions corresponding to the actions. Note that all operations must be performed on COC. Do not directly edit the policy.

3. If you enabled the feature of privilege escalation using service tickets, you also need to bind the policy to your account. To disable this policy, you need to unbind the policy from your user group first.

4. During service ticket privilege escalation, the system needs to verify the region, application, and service ticket status of the resources required. If a resource does not belong to any region or application, the system does not verify the resource but will display all service tickets of the user. Verification requirements on service tickets:

Incident ticket status verification:

(1) P1, P2, P3, and P4 incident tickets in the accepted state

(2) The privilege escalation application must be the same as the one in the incident ticket analysis and handling phase.

(3) The privilege escalation operator must be the same as the current owner in the incident analysis and handling phase.

(4) The privilege escalation region must be the same as the region specified in the incident ticket.

War room status verification:

(1) The war room must be in the started or fault demarcation status.

(2) The privilege escalation application must be in the list of applications affected by the war room.

(3) The privilege escalation operator must be the fault recovery owner, a fault recovery member, or the administrator of the war room.

Change ticket status verification:

(1) The region of the privilege escalation application must be the same as that specified in the change ticket.

(2) The privilege escalation operator must be the implementer of the change ticket.

(3) The current operation time must be within the planned implementation time window of the change ticket. (The current operation time must be later than the planned start time and earlier than the planned end time.)

(4) You must click Change Start for a change ticket.

After service ticket privilege escalation is enabled, the northbound interface becomes unavailable. For example, if a script is executed to enable service ticket privilege escalation, the northbound script interface cannot be used.

Procedure

  1. Log in to COC.
  2. In the navigation pane on the left, choose Change Ticket Management > Change Control. By default, the service ticket-based authorization feature is disabled. To enable it, toggle the feature on.
  3. After this feature is enabled, all actions of COC are displayed in the list. You can enable or disable the interconnected actions. If this feature is disabled, service ticket-based privilege escalation is not required for all account operations in this scenario. If this function is enabled, service ticket privilege escalation is required.

    Figure 1 Change control list

  4. After an action is enabled, you need to associate it with a policy: Add the autocratically generated COC policies to your user group. Then, you can use the service ticket to escalate privileges.

    Figure 2 Associating a policy with an action