Security group guidelines and use cases

Security group guidelines

1. Plan security groups

Before you configure security groups, identify your service boundaries and security requirements, such as which services are exposed to the public internet and which are limited to internal access.

• Use different security groups for public-facing and internal services

  For public-facing services, open only necessary ports and keep all other ports and protocols closed to reduce the attack surface.

  Deploy internal services, such as databases and caches, on ECS instances without public internet access. You can then grant internal access by authorizing another security group.

• Use different security groups for different applications

  Different applications typically require different ports. Place them in separate security groups to prevent rules from interfering with each other.

  For example, a Linux instance might require TCP port 22 for SSH access, while a Windows instance might require TCP port 3389 for Remote Desktop access.

  Even if instances use the same image type, assign them to different security groups if they provide different services and do not need to communicate with each other over the internal network. This practice facilitates decoupling and future changes.

  When you plan your applications, you can use a combination of network segments and security groups to define service boundaries.

• Use separate security groups for production and test environments

  Use different security groups for production, testing, and development environments to prevent test rules from affecting production services.

  You can also assign different security groups to multiple test environments to reduce interference between them.

• Do not assign public IP addresses to resources that do not require public access

  To minimize public exposure, prioritize connecting to an ECS instance by using Workbench, Session Manager, or a jump server. If an instance does not have a public IP address, you can use the port forwarding feature to access its services. For more information, see Use the port forwarding feature of the Session Manager CLI to access an instance without a public IP address.

  In a distributed application, do not assign a public IP address to an ECS instance that does not provide public services. If multiple servers provide public services, we recommend that you use SLB to distribute traffic and avoid single points of failure.

  If an ECS instance requires only outbound access to the internet, use a NAT gateway and configure SNAT rules. This approach prevents service exposure that can occur when you assign a public IP address or an elastic IP address. For more information, see Create and manage SNAT entries.

• Use security groups as whitelists

  Treat a security group as a whitelist. This means it denies all access by default, and you add allow rules only for necessary ports and authorized sources. When you troubleshoot production issues, do not temporarily assign a public IP address or associate an elastic IP address, as this can increase the attack surface.

2. Configure security group rules

When you configure security group rules, open only the ports that your business requires and restrict the source IP address range as much as possible.

In a VPC, a single security group rule can control both public and internal network access.

• Default policies differ between basic and advanced security groups

  Both basic and advanced security groups deny all inbound traffic by default. However, their default outbound policies differ: a basic security group allows all outbound traffic, while an advanced security group denies it.

• Internal connectivity differs across security groups and security group types

  ECS instances in different security groups cannot communicate with each other over the internal network, even if they belong to the same account. By default, instances can communicate within the same basic security group but are isolated within the same advanced security group.

• Add security group rules based on the principle of least privilege

  For example, when you open port 22 on a Linux instance for remote login, allow access only from specific IP addresses.

  Warning

  Authorizing 0.0.0.0/0 or ::/0 allows access from all IP addresses, a high-risk configuration. Use this only for services that must be public, and open only the necessary ports.

  Configure rules with the most restrictive scope possible. For more information about the types of authorization objects that a security group supports, see Security group rules.

• Use the principle of least privilege to configure intra-group isolation

  If ECS instances within a basic security group do not need to communicate with each other, change the group's internal access policy to isolate them.

• Keep the purpose of rules within a single security group consistent

  Organize rules into multiple security groups based on their purpose and associate instances with the relevant security groups. A single security group with too many rules increases management complexity.

• Choose authorization objects carefully

  The authorization object for a security group rule can be an IP address, another security group, or a CIDR block.

  When instances in different security groups need to communicate over the internal network, grant access by referencing the security group ID. This method is more efficient than managing individual IP addresses or CIDR blocks. For example, if your web tier uses a security group named sg-web and your database tier uses sg-database, you can add a rule to sg-database that grants access from sg-web to the MySQL port (3306).

  For internal network access, we recommend that you authorize a source security group instead of a CIDR block.

• Common application ports

  Many applications communicate by using standard service ports. For more information, see Common ports.

  Note

  On the Self-service Problem Diagnosis Tool page, use the Check Security Group Rules tab to verify if a port is allowed or if a specific IP address can access an ECS network interface card (NIC). For more information, see Security Group Rule Check.

3. Review and optimize rules

As your business evolves, your existing security group rules may become outdated. Regularly review and adjust them. Before you modify rules in a production environment, clone the security group and verify the changes in a test environment. After you confirm that traffic flows correctly, apply the changes to the production environment to avoid service interruptions.

Use cases

Control inbound traffic to ECS instances

Inbound traffic is traffic from external resources to your ECS instances. By default, security groups deny all inbound traffic, so you only need to add rules to allow access. See the following use cases:

• Case 1: Allow public access to a web service on an ECS instance

• Case 2: Allow remote access for specific users to an ECS instance

• Case 3: Configure security policies for databases on ECS instances

• Case 4: Allow access only for specific protocols

• Case 5: Enable internal communication between instances in different security groups

Control outbound traffic from ECS instances

Outbound traffic is traffic from your ECS instances to external resources. By default, basic security group outbound rules allow all access. You can add deny rules to restrict instance access to specified external resources. See the following use case:

• Case 6: Restrict access from an ECS instance to external websites

Case 1: Allow public access to web services

Case 2: Allow remote access for specific users

Case 3: Configure database security policies

Case 4: Allow access only for specific protocols

Case 5: Enable internal communication between security groups

• Scenario 1: Security groups in the same account

  If security group A and security group B belong to the same account, set the authorization object to the ID of the source security group. The following table shows an example of this rule configuration.

  Rule direction	Action	Priority	Protocol type	Port range	Authorization object
  inbound	Allow	1	Custom TCP	Destination: 21/21	Source: sg-bp1hv6wvmegs036****

  Note

  Replace the example security group ID with your actual value.

• Scenario 2: Security groups in different accounts

  If security group A and security group B belong to different accounts, set the authorization object to the source Alibaba Cloud account ID and security group ID.

  Rule direction	Action	Priority	Protocol type	Port range	Authorization object
  inbound	Allow	1	Custom TCP	Destination: 21/21	Source: 160998252992****/sg-bp174yoe2ib1sqj5****

  Note

  Replace the example Alibaba Cloud account ID and security group ID with your actual values.

Case 6: Restrict access to external websites