Shulou(Shulou.com)06/02 Report--

I would like to share with you the methods of reasonable planning and distinguishing different security groups. I believe most people don't know much about it, so share this article for your reference. I hope you will learn a lot after reading this article. Let's take a look at it!

In the process of using a security group, all CVMs are usually placed in the same security group, thus reducing the workload of the initial configuration. But in the long run, the interaction of business system networks will become complex and uncontrollable. When you perform security group changes, you will not be able to explicitly add and remove the scope of influence of the rules.

Reasonable planning and differentiation of different security groups will make your system easier to adjust, comb the services provided by applications, and layer different applications. It is recommended that you plan different security groups and set different security group rules for different businesses.

Distinguish between different security groups

The CVM and private network server of public network service belong to different security groups as far as possible

Whether or not to provide public network services, including actively exposing external access to certain ports (such as 80,443, etc.), and passively providing port forwarding rules (such as CVM with public network IP, EIP, NAT port forwarding rules, etc.) will cause your applications to be accessed by the public network.

The security group rules to which the CVM in the two scenarios belong should adopt the strictest rules, and it is recommended that you reject them first. By default, all ports and protocols should be closed, exposing only the ports that need services, such as 80,443. Because only the servers that belong to the public network are grouped, it is also easier to control when adjusting the security group rules.

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

If a public network CVM is already in the same security group SG_CURRENT as other applications. You can make changes in the following ways.

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

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

Description: authorization Policy: allow, Protocol Type: ALL, Port: 80Accord80, Authorization object: 0.0.0.0Comp0, Authorization Policy: allow, Protocol Type: ALL, Port: 443Universe 443 Authorization object: 0.0.0.0amp0.

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

Description: authorization policy: allow, protocol type: ALL, port:-1Maxime 1, authorization object: SG_WEB, priority: customize according to the actual situation [1-100].

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

"in the ECS console, select Security Group Management."

Select SG_WEB-> manage instances-> add instances, select instance ECS_WEB_1 to join the new security group SG_WEB, and make sure that the traffic and network of ECS_WEB_1 instances are working properly.

Remove ECS_WEB_1 from the original security group.

"in the ECS console, select Security Group Management."

Select SG_CURRENT > manage instances > remove instances, select ECS_WEB_1, remove from SG_CURRENT, test network connectivity, and make sure that the traffic and network are working properly.

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

Perform other server security group changes.

Different applications use different security groups

In production environment, in most cases, different operating systems do not belong to the same application group to provide load balancing services. Providing different services means that the ports that need to be exposed and rejected are different, and it is recommended that different operating systems belong to different security groups as far 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 the fact that different operating systems belong to different security groups, even if the same image type provides different services, it is best to belong to different security groups if they do not need to be accessed through the private network. This makes it easy to decouple and change the future security group rules to make the responsibility single.

When planning and adding applications, we should not only consider subnetting different virtual switch configurations, but also reasonably plan security groups. Use network segments + security groups to constrain your boundaries as service providers and consumers.

See the above procedure for the specific change process.

Different security groups are used in production and test environments

In order to better isolate the system, you may build multiple sets of test environments and an online environment in the actual development process. In order to make network isolation more reasonable, you need to use unreasonable security policies for different environment configurations to avoid refreshing online stability due to changes in the test environment.

By creating different security groups, the access domain of the application is restricted, and the connection between the production environment and the test environment is avoided. At the same time, different security groups can be assigned to different test environments to avoid mutual interference between multiple test environments and improve development efficiency.

Only assign public network IP to subnets or CVMs that require public network access

Whether in classical network or proprietary network (VPC), reasonable allocation of public network IP can make the system more convenient to manage public network and reduce the risk of system attack. In the scenario of proprietary network, when creating a virtual switch, it is recommended that you try to place the IP of the service area that needs to be accessed by the public network in several fixed switches (subnet CIDR) to facilitate audit and differentiation, so as to avoid accidental exposure of public network access.

In distributed applications, most applications have different layering and grouping. For CVMs 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 public network traffic distribution load balancing service to provide public network services to improve system availability and avoid a single point of access.

Try not to assign public network IP to CVMs that do not need public network access. In a private network, when your CVM needs to access the public network, it is recommended that you use NAT gateway to provide Internet access proxy service for ECS instances without public network IP in VPC. You only need to configure appropriate SNAT rules to provide public network access for specific CIDR IP address ranges or subnets. For more information, please see SNAT. Avoid exposing services to the public network after the public network IP (EIP) is assigned because only the ability to access the public network is needed.

Minimum principle

The security group should be whitelisted, so it is necessary to open and expose as few ports as possible, and allocate public network IP as little as possible. If you want to access an online machine for task log or error troubleshooting, it is easy to assign a public network IP or mount an EIP directly, but it will expose the entire machine to the public network. A more secure strategy is to use a jump engine to manage it.

Use a springboard machine

Jumping machine because of its own huge authority, in addition to through the tool to make audit records. In the proprietary network, it is recommended to assign the springboard to the proprietary virtual switch and provide the corresponding EIP or NAT port forwarding table.

First create a proprietary security group SG_BRIDGE, such as opening the corresponding port, such as Linux TCP (22) or Windows RDP (3389). In order to limit the access rules of the security group, you can limit the scope of the public network exit of the enterprise that can be logged in, and reduce the probability of being logged in and scanned.

Then add the CVM as a springboard to the security group. In order to enable the machine to access the corresponding CVM, you can configure the appropriate group authorization. For example, add a rule to SG_CURRENT that allows SG_BRIDGE to access certain ports and protocols.

When using the springboard SSH, it is recommended that you log in with a SSH key pair rather than a password.

In short, reasonable security group planning makes you more comfortable in expanding your applications and makes your system more secure.

The above are all the contents of the method of reasonably planning and distinguishing different security groups. Thank you for your reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.