Custom policy reference
If system policies do not meet your requirements, you can create custom policies to achieve least privilege. Custom policies help you implement fine-grained permission control and improve the security of resource access. This topic describes scenarios and provides policy examples for using custom policies with Short Message Service.
What is a custom policy?
In Resource Access Management (RAM), custom policies are policies that you can create, update, and delete to supplement system policies. You are also responsible for managing the versions of your custom policies.
After you create a custom policy, you can attach it to a RAM user, user group, or RAM role. The RAM identity is then granted the access permissions specified in the policy.
You can delete a custom policy. Before you delete a policy, ensure that it is not referenced. If the policy is referenced, you must first revoke the permissions associated with its reference records.
Custom policies support versioning. You can manage the versions of your custom policies according to the version management rules of RAM.
Operation document
Custom policy examples
To create the custom policy used in the following examples, perform these steps:
Log on to the RAM console.
Click Create Policy.
Click the Script tab, and paste the policy document (JSON) of the example that you want to use.
Click OK.
Example 1: Configure an IP address whitelist policy
This example shows a policy document for an IP address whitelist. This policy allows access to the SendSms API method only from the 192.0.2.0/24 IP address range. The policy document is as follows:
If the value of acs:SourceIp is a single IP address, specify the exact IP address. Do not use the CIDR block format xx.xx.xx.xx/32. For example, use 10.0.0.1 instead of 10.0.0.1/32.
If you do not need to specify conditions, remove the "Condition{}" section and the , after "Resource": []. The condition does not support notations such as "*" or "0.0.0.0".
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": ["dysms:SendSms"],
"Resource": ["*"],
"Condition": {
"IpAddress": {
"acs:SourceIp": ["192.0.2.0/24"]
}
}
}
]
}Example 2: Configure an IP address blacklist policy
This example shows a policy document for an IP address blacklist. This policy denies access to the SendSms API method from the IP address 192.0.2.1. The policy document is as follows:
If the value of acs:SourceIp is an IP address range, use the CIDR block format xx.xx.xx.xx/32. For example, 10.0.0.1/32.
If you do not need to specify conditions, remove the “Condition{}” block and the trailing comma (,) after "Resource": []. Policy conditions do not support notations such as “*” or “0.0.0.0”.
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": ["dysms:SendSms"],
"Resource": ["*"],
"Condition": {
"NotIpAddress": {
"acs:SourceIp": ["192.0.2.1"]
}
}
}
]
}Example 3: Configure a secure channel (HTTPS) policy
This example shows a policy document that enforces the use of a secure channel (HTTPS). The policy document is as follows:
After you configure this security policy, requests made over non-secure channels (HTTP) are denied.
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "dysms:*",
"Resource": "*",
"Condition": {
"Bool": {
"acs:SecureTransport": ["true"]
}
}
}
]
}Example 4: Configure a policy for multiple API calls
This example shows a policy that grants permissions for multiple API calls. This policy allows access only to the SendSms and SendBatchSms API methods. The policy document is as follows:
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dysms:SendSms",
"dysms:SendBatchSms"
],
"Resource": "*"
}
]
}Authorization information reference
To create effective custom policies, you need to understand your permission control requirements and the authorization information for Short Message Service. For more information, see Authorization information.