How to properly plan and distinguish different security groups

The content of this article is about how to reasonably plan and distinguish different security groups. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

During the use of security groups, all cloud servers are usually placed in the same security group, which can reduce the initial configuration workload. But in the long run, the interaction of business system networks will become complex and uncontrollable. When performing security group changes, you will not be able to clearly define the scope of adding and removing rules.

Properly planning and distinguishing different security groups will make it easier to adjust your system, organize the services provided by applications, and layer different applications. It is recommended that you plan different security groups for different businesses and set different security group rules.

Distinguish between different security groups

The cloud server and intranet server of the public network service should belong to different security groups as much as possible

Whether public network services are provided to the outside world, including actively exposing certain ports for external access (such as 80, 443, etc.), or passively providing (such as cloud servers with public network IP, EIP, NAT port forwarding rules, etc.) port forwarding rules, will result in Your application may be accessed from the public network.

The security group rules to which the cloud server belongs in the second scenario should adopt the strictest rules. It is recommended to deny priority. By default, all ports and protocols should be closed, and only the ports that provide external services, such as 80, should be exposed. ,443. Since only servers with access to the external public network are grouped, it is easier to control when adjusting security group rules.

The responsibilities for providing server grouping to the outside world should be clear and simple, and avoid providing other services to the outside world on the same server. For example, MySQL, Redis, etc., it is recommended to install these services on a cloud server without public network access, and then access them through group authorization of the security group.

If there is currently a public cloud server that is already in the same security group SG_CURRENT as other applications. You can make changes using the following methods.

Sort out the ports and protocols exposed by the currently provided public network services, such as 80 and 443.

Create a new security group, such as SG_WEB, and then add the corresponding ports and rules.

Description: Authorization policy: Allow, Protocol type: ALL, Port: 80/80, Authorization object: 0.0.0.0/0, Authorization policy: Allow, Protocol type: ALL, Port: 443/443 Authorization object : 0.0.0.0/0.

Select the security group SG_CURRENT, and then add a security group rule to group authorization to allow resources in SG_WEB to access SG_CURRENT.

Description: Authorization policy: Allow, protocol type: ALL, port: -1/-1, authorization object: SG_WEB, priority: customized according to the actual situation [1-100].

Add an instance ECS_WEB_1 that needs to switch the security group to the new security group.

In the ECS console, select Security Group Management.

Select SG_WEB > Manage Instances > Add Instance, select instance ECS_WEB_1 to join the new security group SG_WEB, and confirm that the traffic and network of the ECS_WEB_1 instance are working properly.

Remove ECS_WEB_1 from the original security group.

In the ECS console, select Security Group Management.

Select SG_CURRENT > Manage Instance > Remove the instance, select ECS_WEB_1, remove from SG_CURRENT, test network connectivity, and confirm that the traffic and network are working properly.

If it does not work properly, add ECS_WEB_1 back to the security group SG_CURRENT, check whether the set SG_WEB exposed port is as expected, and then continue to change.

Perform other server security group changes.

Different applications use different security groups

In a production environment, different operating systems will not belong to the same application in most cases Grouped to provide load balancing services. Providing different services means that the ports that need to be exposed and the ports that are denied are different. It is recommended that different operating systems belong to different security groups as much as possible.

For example, for the Linux operating system, you may need to expose the TCP (22) port to implement SSH, and for Windows, you may need to open a TCP (3389) remote desktop connection.

In addition to different operating systems belonging to different security groups, even if the same image type provides different services, if they do not need to be accessed through the intranet, it is best to belong to different security groups. This facilitates decoupling and changes to future security group rules to achieve a single responsibility.

When planning and adding new applications, in addition to considering dividing different virtual switch configuration subnets, you should also plan security groups reasonably. Use network segment security groups to constrain yourself as a boundary between service providers and consumers.

For the specific change process, please refer to the above steps.

The production environment and the test environment use different security groups

In order to better isolate the system, during the actual development process, you Multiple sets of test environments and an online environment may be built. In order to achieve more reasonable network isolation, you need to use different security policies for different environment configurations to prevent changes in the test environment from being refreshed online and affecting online stability.

By creating different security groups, limit the access domain of the application to prevent the production environment and test environment from being connected. At the same time, different security groups can also be assigned to different test environments to avoid mutual interference between multiple test environments and improve development efficiency.

Only allocate public network IP to subnets or cloud servers that require public network access

Whether it is a classic network or a private network (VPC) Among them, reasonable allocation of public network IP can make the system more convenient for public network management and reduce the risk of system attacks. In a private network scenario, when creating a virtual switch, it is recommended that you try to put the IP ranges of the service areas that require public network access into several fixed switches (subnet CIDR) to facilitate auditing and differentiation and avoid accidental exposure. Public network access.

In distributed applications, most applications have different layers and groups. For cloud servers that do not provide public network access, try not to provide public network IP. If there are multiple servers providing public network access, , it is recommended that you configure the load balancing service for public network traffic distribution to serve the public network to improve system availability and avoid single points.

Try not to assign public IP addresses to cloud servers that do not require public network access. When your cloud server needs to access the public network in a private network, it is first recommended that you use a NAT gateway to provide proxy services for accessing the Internet for ECS instances that do not have a public IP in the VPC. You only need to configure the corresponding SNAT rules. It can provide public network access capabilities for specific CIDR network segments or subnets. For detailed configuration, see SNAT. Avoid exposing services to the public network after assigning a public IP (EIP) because you only need the ability to access the public network.

Minimum Principle

The security group should be whitelisted, so it is necessary to open and expose the least ports as much as possible, and at the same time as little as possible Assign a public IP. If you want to access online machines for task logs or error troubleshooting, it is simple to directly assign a public IP or mount an EIP, but after all, the entire machine will be exposed to the public network. A safer strategy is to manage it through a springboard machine. .

Using the springboard machine

The springboard machine has huge authority, in addition to making audit records through tools. In a private network, it is recommended to allocate the springboard machine to a dedicated virtual switch and provide it with the corresponding EIP or NAT port forwarding table.

First create a dedicated security group SG_BRIDGE, such as opening the corresponding port, such as Linux TCP (22) or Windows RDP (3389). In order to limit the network access rules of the security group, you can limit the authorized objects that can log in to the enterprise's public network exit range, reducing the probability of being logged in and scanned.

Then add the cloud server as the springboard machine to the security group. In order to allow this machine to access the corresponding cloud server, you can configure the corresponding group authorization. For example, add a rule in SG_CURRENT to allow SG_BRIDGE to access certain ports and protocols.

When using springboard SSH, it is recommended that you give priority to logging in using an SSH key pair instead of a password.

In short, reasonable security group planning will make it easier for you to expand your application and make your system more secure.

The above is the detailed content of How to properly plan and distinguish different security groups. For more information, please follow other related articles on the PHP Chinese website!