If system policies do not meet your requirements, you can configure custom policies to implement the principle of least privilege. You can use custom policies to achieve fine-grained control over permissions and improve resource access security. This topic describes the scenarios in which custom policies are used for Phone Number Verification Service.
What is a custom policy?
Resource Access Management (RAM) policies are classified into system policies and custom policies. You can manage custom policies based on your business requirements.
After you create a custom policy, you must attach the policy to a RAM user, RAM user group, or RAM role. This way, the permissions that are specified in the policy can be granted to the principal.
You can delete a RAM policy that is not attached to a principal. If the RAM policy is attached to a principal, you must detach the RAM policy from the principal before you can delete the RAM policy.
Custom policies support version control. You can manage custom policy versions based on the version management mechanism provided by RAM.
References
Common scenarios and sample policies
Example 1: Custom policy with permissions to call one or more API operations
If you want to call one API operation, configure the policy by using the following content:
{ "Version": "1", "Statement": [{ "Action": [ "dypns:StartVerification" ], "Resource": "*", "Effect": "Allow" }] }
If you want to call multiple API operations, configure the policy by using the following content:
{ "Version": "1", "Statement": [{ "Action": [ "dypns:StartVerification", "dypns:SearchVerification" ], "Resource": "*", "Effect": "Allow" }] }
The name of an API operation can contain the asterisk (*) wildcard character.
{ "Version": "1", "Statement": [{ "Action": [ "dypns:Check*" ], "Resource": "*", "Effect": "Allow" }] }
Example 2: Custom policy with permissions to call API operations of Phone Number Verification Service from a specified IP address or CIDR block
If the value of the
acs:SourceIp
field is a single IP address, you must specify the specific IP address rather than a CIDR block such as xx.xx.xx.xx/32. For example, you must specify the value of acs:SourceIp as 10.0.0.1 rather than 10.0.0.1/32.42.XXX.XX.XX is the IP address from which you are allowed to call API operations. /24 is the subnet mask. You can specify the IP address or CIDR block from which you can call API operations based on your business requirements.
The DateLessThan field specifies the time when the restrictions on the IP address or CIDR block become invalid. If the current time is later than the time specified by the DateLessThan field, the above restrictions on the IP address or CIDR block become invalid. Otherwise, the above restrictions on the IP address or CIDR block are valid.
The following sample code provides the configurations of the custom policy:
{ "Version": "1", "Statement": [{ "Action": "dypns:*", "Resource": "*", "Condition": { "IpAddress": { "acs:SourceIp": "42.XXX.XX.XX/24" }, "DateLessThan": { "acs:CurrentTime": "2016-12-16T15:00:00+08:00" } }, "Effect": "Allow" }] }
To make the above restrictions on the IP address or CIDR block valid all the time, you can delete the DateLessThan field. The following sample code shows the configurations:
{ "Version": "1", "Statement": [{ "Action": "dypns:*", "Resource": "*", "Condition": { "IpAddress": { "acs:SourceIp": "42.XXX.XX.XX/24" } }, "Effect": "Allow" }] }
Example 3: Combination of different policies. For example, you can use different policies together to only allow calls of StartVerification from 192.168.1.100. The following sample code shows the configurations:
{ "Version": "1", "Statement": [{ "Action": "dypns:StartVerification", "Resource": "*", "Condition": { "IpAddress": { "acs:SourceIp": "192.168.1.100" } }, "Effect": "Allow" }] }
Authorization information
Before you use custom policies, you must understand the permission control requirements of your business and the authorization information about Phone Number Verification Service.