- What's New
- Function Overview
- Service Overview
- Billing
- Getting Started
-
User Guide
- Buying SecMaster
- Authorizing SecMaster
- Viewing Security Overview
- Workspaces
- Viewing Purchased Resources
- Security Situation
- Resource Manager
- Risk Prevention
- Threat Operations
- Security Orchestration
-
Playbook Overview
- Ransomware Incident Response Solution
- Attack Link Analysis Alert Notification
- HSS Isolation and Killing of Malware
- Automatic Renaming of Alert Names
- Auto High-Risk Vulnerability Notification
- Automatic Notification of High-Risk Alerts
- Auto Blocking for High-risk Alerts
- Real-time Notification of Critical Organization and Management Operations
-
Settings
- Data Integration
-
Log Data Collection
- Data Collection Overview
- Adding a Node
- Configuring a Component
- Adding a Connection
- Creating and Editing a Parser
- Adding and Editing a Collection Channel
- Managing Connections
- Managing Parsers
- Managing Collection Channels
- Viewing Collection Nodes
- Managing Nodes and Components
- Partitioning a Disk
- Logstash Configuration Description
- Connector Rules
- Parser Rules
- Upgrading the Component Controller
- Customizing Directories
- Permissions Management
- Key Operations Recorded by CTS
-
Best Practices
-
Log Access and Transfer Operation Guide
- Solution Overview
- Resource Planning
- Process Flow
-
Procedure
- (Optional) Step 1: Buy an ECS
- (Optional) Step 2: Buy a Data Disk
- (Optional) Step 3: Attach a Data Disk
- Step 4: Create a Non-administrator IAM User
- Step 5: Configure Network Connection
- Step 6: Install the Component Controller (isap-agent)
- Step 7: Install the Log Collection Component (Logstash)
- (Optional) Step 8: Creating a Log Storage Pipeline
- Step 9: Configure a Connector
- (Optional) Step 10: Configure a Log Parser
- Step 11: Configure a Log Collection Channel
- Step 12: Verify Log Access and Transfer
- Credential Leakage Response Solution
-
Log Access and Transfer Operation Guide
-
API Reference
- Before You Start
- API Overview
- Calling APIs
-
API
- Alert Management
- Incident Management
- Indicator Management
- Playbook Management
- Alert Rule Management
- Playbook Version Management
- Playbook Rule Management
- Playbook Instance Management
- Playbook Approval Management
- Playbook Action Management
- Incident Relationship Management
- Data Class Management
- Workflow Management
- Data Space Management
- Pipelines
- Workspace Management
- Metering and Billing
- Metric Query
- Baseline Inspection
- Appendix
- FAQs
Show all
SecMaster Custom Policies
Custom policies can be created to supplement the system-defined policies of SecMaster. For the actions that can be added to custom policies, see SecMaster Permissions and Supported Actions.
You can create custom policies in either of the following ways:
- Visual editor: Select cloud services, actions, resources, and request conditions. This does not require knowledge of policy syntax.
- JSON: Edit JSON policies from scratch or based on an existing policy.
For details, see Creating a Custom Policy. The following section contains examples of common SecMaster custom policies.
Example Custom Policies
- Example 1: Authorization for alert list search permission and permission execution analysis
1 2 3 4 5 6 7 8 9 10 11 12
{ "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "secmaster:alert:list", "secmaster:search:createAnalysis" ] } ] }
- Example 2: Preventing users from modifying alert configurations
A deny policy must be used together with other policies. If the policies assigned to a user contain both Allow and Deny actions, the Deny actions take precedence over the Allow actions.
The following method can be used to create a custom policy to disallow users who have the SecMaster FullAccess policy assigned to modify alert configurations. Assign both SecMaster FullAccess and the custom policies to the group to which the user belongs. Then the user can perform all operations except modifying alert configurations on SecMaster. The following is an example of a deny policy:
1 2 3 4 5 6 7 8 9 10 11
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "secmaster:alert:updateType" ] } ] }
- Example 3: Defining permissions for multiple services in a policy
A custom policy can contain the actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
{ "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "secmaster:alert:get", "secmaster:alert:update" ] }, { "Effect": "Allow", "Action": [ "hss:vuls:set", "hss:vuls:list" ] } ] }
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.