What is Security Group

Security group is a network security protection mechanism that is used to prevent unauthorized access and protect computer networks from malicious attacks. It is a virtual firewall, used to restrict inbound and outbound network traffic. A security group operates at the network and transport layers, determining whether to allow traffic through by inspecting the data packet's source address, destination address, protocol type, and port numbers, among other information. After a security group is created, users can define various access rules within the security group. Once an elastic cloud server is added to the security group, it is protected by these access rules.

There are some differences in the security groups of different resource pools, as shown in Table 1:

Table 1 Differences between AZ Resource Pool and Regional Resource Pool

Default Security Group:

· For regional resource pools, the system creates a security group for each user by default, and multiple VPCs can share the same security group. For details about the default rules of default security group, see Table 2 Default Security Group Rules for Regional Resource Pools.

· For AZ resource pools, the system creates a security group for each VPC by default. Generally, different VPCs have different services, and VPCs are isolated from each other. The same services are usually deployed in one VPC. In most cases, different VPCs should use different security group rules due to different services. Each VPC automatically establishes a default security group, which can satisfy the scenarios where users need different security groups for different services. For details about the default rules of default security group, see Table 3 Default Security Group Rules for AZ Resource Pools.

Security Group Status:

· For regional resource pools, the outbound of security group is stateful. If you send an outbound request from an instance, and the outbound rule of the security group is released, the response traffic of the outbound request will be allowed to flow in regardless of its inbound rule.

· For AZ resource pools, both outbound and inbound of security group are stateful. If you send an outbound request from an instance, and the outbound rule of the security group is released, the response traffic of the outbound request will be allowed to flow in regardless of its inbound rule. Similarly, if the inbound rule of the security group is released, the response traffic of the inbound request will be allowed to flow out regardless of its outbound rule.

Custom Security Group:

· For regional resource pools, when you create a security group, you have two default rules for the security group with the template type of Custom, that is, the outbound data packets with all IP addresses (0.0.0.0/0, ::/0) will pass by default.

· For AZ resource pools, when you create a security group, there is no default rule for the security group with the template type of Custom, and if no rules are added, all access will be rejected in both outbound and inbound directions for the default security group.

For the list of different resource pools, see Product Description - Resource Pool Differences page. The actual situation depends on the display of the console.

Security Group Rule

In order to better manage the inbound and outbound direction of security groups, you can set security group rules to control the inbound and outbound traffic of cloud servers. Control and protect access to ECS that added to the security group by configuring appropriate rules.

· Security group rules can be divided into inbound rules and outbound rules. The inbound rule is used to control the traffic that flows into the server instance, while the outbound rule is used to control the traffic that flows out of the server instance. The default security group comes with some default rules, and you can also add custom security group rules.

· Security group rules follow the trustlist mechanism, as described below:

Inbound rule: The inbound refers to the specified port of the cloud server in the external access security group. If an external request matches the source address of an inbound rule in the security group and the authorization policy is Allow, the request is allowed to enter and all other requests are blocked. Generally, you don't need to configure a rule with the authorization policy of Reject in the inbound direction, because all requests that don't match the Allow rule will be blocked.

Outbound rule: The outbound refers to the specified port on which the cloud server in the security group access the external server. When all protocols and ports are released in the outbound direction, all zero IP addresses are configured, and the policy is Allow, all internal requests are allowed to go out. 0.0.0.0/0 represents all IPv4 addresses, and ::/0 represents all IPv6 addresses.

Regional Resource Pools:

For regional resource pools, the system creates a security group for each user by default, and the default security group contains a series of default rules, which release all data packets in the outbound direction and restrict access in the inbound direction. Cloud servers in a security group can access each other without adding rules.

The default security group rules are shown in Table 2:

Table 2 Default Security Group Rules for Regional Resource Pools

AZ Resource Pools:

For AZ resource pools, the system creates a security group for each VPC by default, and the default security group contains a series of default rules, which release all data packets in the outbound direction and restrict access in the inbound direction.

The default security group rules are shown in Table 3:

Table 3 Default Security Group Rules for AZ Resource Pools

Suggestions

Here are some suggestions and practical experiences about security groups to help ensure the security of your cloud environment. You can develop appropriate security group policies based on your specific needs and environment:

· In principle, security group rules adopt the principle of least privilege and restrict access to necessary IP addresses by setting the required ports and protocols. Allow only the minimum necessary traffic in and out of your resource instance.

· Regularly update security group rules to adapt to changes in your business needs. Rules that are no longer needed should be removed and new security group rules added based on business changes.

· According to the security requirements of resources, resource instances are divided into different security groups. Fine-grained security control can be achieved through multi-level security groups to ensure the balance between security and flexibility.

· Security group rules are consciously planned and managed through standardized naming, which are easy to find.

· Security groups should be used in conjunction with other security measures such as network ACLs and firewalls to provide more comprehensive security protection.

· It is recommended that you do not directly modify the security group used in the online environment. The modified security group will be automatically applied to all cloud servers within the security group. So you can clone a security group first, debug it in the test environment to ensure that the communication between the modified cloud servers is normal, and then synchronize the modified security group to the online environment.