Elastic Compute Service:Security group application guidance and cases

Security group application guidance

1. Identify business requirements and plan different security groups

Identify your business characteristics and specific security needs, such as distinguishing between publicly available services and those intended for internal use only.

• Public and Internal Network Services Should Use Separate Security Groups

  To prevent unauthorized access from the public network, it's crucial to adopt the strictest security group rules for cloud servers. By default, deny all access, closing all ports and protocols, and only expose those necessary for external services.

  Servers providing external services should have clear and simple security group responsibilities, avoiding the provision of other services on the same server. For services like MySQL or Redis, it is advisable to install them on servers without public network access and configure security group rules to authorize access from another security group.

• Assign Different Applications to Different Security Groups

  In a production environment, it's uncommon for different operating systems to be part of the same application group for load balancing purposes. Since various services require exposing different ports and restricting others, it is advisable to assign different operating systems to separate security groups whenever possible.

  For instance, on Linux operating systems, exposing TCP port 22 is necessary for SSH, while on Windows, opening TCP port 3389 is required for Remote Desktop Protocol (RDP) connections.

  Even when using the same image type across various operating systems, if the services provided do not require internal network access between them, it is advisable to place them in separate security groups. This approach promotes decoupling and simplifies future modifications to security group rules, adhering to the principle of single responsibility.

  When planning and adding applications, it's important to consider not only the segmentation of virtual switches for subnet configuration but also the careful planning of security groups. Employ a "CIDR block + security group" strategy to define clear boundaries between service providers and consumers.

• Use Separate Security Groups for Production and Testing Environments

  For improved system isolation, it's advisable to establish multiple testing environments alongside a single production environment during actual development. To ensure network isolation, configure distinct security strategies for each environment. This prevents changes in the testing environment from inadvertently being deployed to the production environment, thereby maintaining its stability.

  By establishing distinct security groups, you can limit the network access of applications, preventing interaction between production and testing environments. Assigning separate security groups to various testing environments also helps to eliminate cross-environment interference, thereby enhancing development productivity.

• Resources Not Requiring Public Network Access Should Not Have Public IPs

  For ECS instance connectivity without a public IP, use alternatives like Workbench, session management tools, or a jump server to reduce public exposure. To access services in non-public or private networks directly, consider using port forwarding. For more information, see the referenced document.

  In distributed applications, which often consist of various layers and groups, it's advisable for cloud servers without public network access to avoid assigning public IPs. When multiple servers require public network access, configuring a load balancing service is recommended to distribute public traffic, enhance system availability, and prevent single points of failure. For more information, see .

  In a VPC architecture, use a NAT Gateway to enable ECS instances without public IPs to access the Internet. Configure corresponding SNAT rules for specific CIDR blocks or subnets, avoiding service exposure after assigning a public IP (EIP) solely for public network access. For specific configurations, see Create and manage SNAT entries.

• Employ Security Groups as Whitelists

  Use security groups as whitelists, denying all access by default and adding allow rules for specific port ranges and authorization objects. Minimize the number of open and exposed ports and the assignment of public IPs. For tasks like log retrieval or troubleshooting, avoid directly assigning public IPs and mounting EIPs, as this exposes the entire machine to the public network.

2. Configure security group rules

A security group acts as a virtual firewall, controlling inbound and outbound traffic for ECS instances. Ensure that only necessary communication ports are open and restrict the source IP address range as much as possible.

• Basic and Enterprise Security Groups Have Different Default Policies

  Both basic and enterprise security groups deny all inbound access by default. Basic security groups allow all outbound access by default, while enterprise security groups deny all outbound access by default.

• Internal Network Connectivity Differs Between Security Groups and Types

  ECS instances under the same account but in different security groups are isolated on the internal network. Basic security groups have internal network connectivity by default, whereas enterprise security groups are isolated by default.

• Control Objects for Security Group Rules Vary by Network Architecture

  • In a VPC network, a security group rule can control both public and internal network access. A single rule can restrict or permit traffic from both networks.

  • In a classic network, public and internal networks share the same IP space, requiring separate security group rules to control access for each network.

• Adhere to the Principle of Least Privilege When Adding Security Group Rules

  For instance, when enabling port 22 on a Linux instance for remote login, limit access to specific IPs only.

  Warning

  Authorizing all IPs with 0.0.0.0/0 as an authorization object is insecure, as it exposes all ports to external access. Instead, deny all ports by default and only open common TCP ports like 80, 8080, and 443 for web services, keeping other ports closed.

  For enhanced security, it is advisable to specify IP addresses or CIDR blocks as authorization objects (sources or destinations of traffic) in line with your business needs and adhering to the principle of least privilege. Be cautious when allowing access from all IPv4 or IPv6 addresses by using 0.0.0.0/0 or ::/0 as authorization objects. For detailed information on the types of authorization objects supported by security groups, refer to Security group rules.

• Implement Internal Isolation Following the Principle of Least Privilege

  If intra-group connectivity is not required for ECS instances in a basic security group, switch the internal access control policy from connectivity to isolation.

• Maintain Uniform Rule Purposes Within a Single Security Group

  Add rules to security groups based on their intended purposes, then add ECS instances to these groups. Overloading a single security group with many rules increases management complexity.

• Select Authorization Objects for Security Group Rules Carefully

  Authorization objects for security group rules can be IP addresses, security groups, or CIDR blocks.

  To allow resources in different security groups to communicate, configure rules for mutual access. For example, in distributed applications, you may have separate security groups for Web and Database: sg-web and sg-database. In sg-database, add a rule to authorize all resources of the sg-web group to access the MySQL (3306) port.

  For internal network access, specify security groups as authorization objects, not CIDR blocks.

  For classic network ECS instances, Alibaba Cloud does not enable any default inbound rules for the internal network. For security, avoid enabling access based on CIDR blocks.

• Typical Applications Usually Use Default Ports for Services

  Applications communicate externally through specific server ports. For more information, see Common Ports.

3. Continuous optimization and adjustment

As your business evolves, the original security groups and rules may become outdated. Regularly review and adjust your architecture design based on the latest security landscape. When modifying security groups, clone one in the testing environment for debugging, confirm normal instance traffic after changes, and then update the production environment's security group rules to avoid business disruptions due to errors.

Security group application cases

Control inbound traffic of ECS instances

Manage external resource traffic accessing ECS instances by setting inbound rules. By default, security group inbound rules deny all access, and you only need to configure allowed rules. Examples include the following:

• Case 1: Deploying a website business on ECS instances to provide web services

• Case 2: Granting Specific Users Remote Access to ECS Instances

• Case 3: Security Policy for Deploying Database Services on ECS

• Case 4: Permit Access for Specific Protocol Services Only

• Case 5: Enabling Internal Network Communication Between Instances in Different Security Groups

Control outbound traffic of ECS instances

Manage ECS instance traffic accessing external resources by setting outbound rules. By default, security group outbound rules allow all access, and you only need to configure denied rules. Examples include the following:

• Case 6: Preventing ECS Instances from Accessing External Websites

Case 1: Website business deployed on ECS instances provides web services

Case 2: Specific users need remote access to ECS instances

Case 3: Database service deployment security policy on ECS

Case 4: Allow only specific protocol business access

Case 5: Instances of different security groups achieve internal network communication

• Scenario 1:

  When Security Group A and B are under the same Alibaba Cloud account, specify Security Group A's ID as the authorization object in Security Group B's rule to allow inbound access. The table below shows a sample rule.

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

  Note

  The security group ID in the table is for reference only. Replace it with the actual security group ID.

• Scenario 2:

  If Security Group A and B are from different Alibaba Cloud accounts, include both the ID of Security Group A and the account ID it belongs to as authorization objects in Security Group B's rule. The table below describes a sample security group rule.

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

  Note

  The Alibaba Cloud account ID and security group ID in the table are for reference. Replace them with actual IDs.

Case 6: Restrict ECS instances from accessing external websites