Child pages
  • Best Practices For AWS Security Groups

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Imported Korean translation from sag76 and removed bloated html
Sv translation
languageen

This document details best practices to configure Security Groups in AWS for ClustrixDB. Using the default Security Group Firewall Settings provided by Amazon can get customers up and running quickly, but these settings do not provide the best database network security. Before you put critical data into your ClustrixDB or use it in production, Clustrix strongly recommends that you understand and implement the network security guidelines described here.

Designing an AWS Security Group for maximum security will minimize risk with the following strategies:

  • Lock down network ports for intra-node communication
  • Limit external access to network ports for application access and administrative control

Table of Contents
maxLevel4

Configure a Locked Down Security Group 

Ports Required for ClustrixDB

Include Page
ClustrixDB Ports
ClustrixDB Ports

Using EC2 or VPC? 

The security group configuration described in this page will secure your cluster whether it is deployed in EC2 or a VPC. However, there are some important security differences between EC2 and VPC to consider:

  • In EC2, the servers are connected to the AWS public network, directly accessible from the internet. Thus it is very important to properly configure your security group to only allow access to the correct ports from known sources. Using a VPC, the nodes are on a private network behind a gateway, isolated from the public network, thus much more secure.
  • When using a load balancer in EC2, it is open to the world. You can not control the traffic allowed to  connect to the load balanced port with ACLs or a security group  (see  AWS docs on this ) . This makes the database ACLs the only security control to the DB access,  which is a high-security risk. In a VPC, load balancers have full security groups giving full control over  traffic allowed to connect. This is the main reason why we really recommend deploying ClustrixDB in a VPC and not in EC2. 
  • A VPC gives you more flexibility in your security settings with multiple subnets (front-end, back-end), network ACLs, security groups, internal and external load balancers.
  • A VPC allows you to use the ClustrixDB AMI with Enhanced Networking enabled.
Warning
For the security reasons above, we strongly recommend deploying ClustrixDB in a VPC.

Deploying within a Security Group

AWS EC2 Security Groups support securing these ports so they can only be accessed by members of the Security Group used by your ClustrixDB nodes. If you have successfully formed a ClustrixDB cluster in AWS you already have rules that refer to these ports in your Security Group, although they may not be restricted only to Security Group members.  

If you desire access to these ports for administrative or testing purposes, you can log into any of the database nodes with SSH first, then run commands that require access to any of these ports from there.

To secure these ports, simply replace your current Security Group rules that refer to the ports listed above with new rules that list the Security Group ID instead of a network range. The example below shows the steps to replace open rules for TCP port 2048 with self-referencing rules. Perform the same steps for each of the ports listed to complete the secure intra-node configuration.

In order to completely setup your security group, you will need to gather the following information: 

  • The security group ID for the group assigned to the nodes ( you can find your security group id in the security group page in the EC2 portal). For the purpose of the example below, we will use security group ID: sg-0d36b666
  • We recommend dedicating the security group to the ClustrixDB nodes. No other resource should be assigned to this security group. This allows for the group's self-referencing rules to only apply to ClustrixDB nodes. 
  • Whether multiport is enabled. If enabled, you need to know the number of nodes and number of cores per node. For the purpose of the example below, we will use 3 nodes, with 8 cores each. 
  • The application servers source IPs. For the purpose of the example below, we will use private IP range  10.0.0.1/24 and EC2 public IPs 54.144.155.202 and 54.144.155.211 (ie there is a private VPC subnet dedicated for app servers, as well as 2 individual servers in public space EC2) 
  • The administrative client source IPs. For the purpose of the example below, the administrative client IP is 198.100.10.204 (a normal public IP, like your outgoing office IP) 
  • The Load balancer's source security group.

To learn how to create and manage your security groups in either EC2 or VPC, visit the Amazon EC2 Security Groups for Linux Instances documentation. 

Securing ClustrixDB back-end TCP and UDP Ports for intra-node communication

ClustrixDB nodes use a series of ports for node-to-node communication. We call them the back-end ports as they only need to be opened between each node of the cluster. Back-end communication can be isolated to a dedicated network subnet, although not required. 

Back-end ports are listed above. For all nodes in the cluster, these ports need to be allowed access from all the other cluster nodes. Since the security group is dedicated to the nodes of the cluster, we can allow access to all resources assigned to that security group. This is described as a self-referencing rule: for group A, allow access to port X when source is group A. This allows for a much simpler security group configuration. 

Securing ClustrixDB front-end TCP ports for Application and Administrative Access

There are 3 TCP network ports that are used to access your ClustrixDB from your database application and for day-to-day administration: 

  • TCP Port 80 is used to access the ClustrixGUI Administration UI.
  • TCP Port 22 is used to access the command line for advanced management and configuration tasks.
  • TCP Port 3306 is used to access the ClustrixDB using the MySQL protocol, typically from your front-end application and by your Database Administrators for development and management purposes.

In a typical secure configuration, you will limit access to TCP Ports 80 and 22 to the network CIDR range that maps to the public IPs for your administrative clients (typically exposed through your firewall), and you will limit access to TCP Port 3306 to your administrative client CIDR range and also to the range of IPs used by your application servers (if they are outside your firewall).

Securing ClustrixDB Intra-Node TCP and UDP Ports

This example will walk you through security one of the ports used for ClustrixDB intra-node communication, namely TCP port 2048. Securing the other ports used for intra-node communication is done in a similar fashion.

For this example, assume that the Security Group rules used for your ClustrixDB AWS instances look similar to the following before modifying them for a secure configuration. Note that in this example, all of the required ports are open to all networks.The goal of this step is to limit this access. 

Image Modified

Step 1 - Identify the Security Group 

Find the Security Group ID of the Security Group being used by your ClustrixDB instances. In the EC2 Management Console, navigate to NETWORK & SECURITY -> Security Groups, and select the Security Group from the list. You will find the Security Group ID on the Details tab, as shown below.

Image Modified

Step 2 - Create a custom TCP Rule

Select the Inbound tab to view the Security Group rules, and delete the current rule referring to TCP port 2048 by clicking the Delete Action. The Action will now change to Undelete as shown below.

 

     Image Modified

Step 3 - Specify a self-referencing rule

Be sure Custom TCP rule is selected for "Create a new rule:", and specify the new self-referencing rule by specifying the Security Group ID for the Source, and 2048 for the port range. Then add it by clicking Add Rule as shown below.

Image Modified 

Step 4 - Apply Rule Changes

Your rule changes will now be reflected as in the highlighted rows below. Finally, click Apply Rule Changes to update the Security Group.

Image Modified

 

The Security Group Inbound rules will now look like the following.

Image Modified


If you have running EC2 instances that use the update Security Group, the changes will typically be applied to them within a few moments. There can be a momentary loss of connectivity between running instances when Security Group rules are changed, which may be noticeable within ClustrixGUI. 

Step 5 - Create more Custom Rules

Once you have completed the rule changes for TCP port 2048, continue to make the changes similarly for TCP ports 22, 80, 2424 and 24378 and for UDP ports 24378. Once you have made the changes for all of the intra-node communication ports, your Security Group rules will look similar to the following, with your Security Group ID substituted for the one in the example.

Image Modified

Limiting ClustrixDB Application and Administrative Access

There are 3 TCP network ports that are used to access your ClustrixDB from your database application and for day-to-day administration: 80, 22, and 3306.

TCP Port 80 is used to access the ClustrixGUI Administration UI.

TCP Port 22 is used to access the command line for advanced management and configuration tasks.

TCP Port 3306 is used to access the ClustrixDB using the MySQL protocol, typically from your front-end application and by your Database Administrators for development and management purposes.

In a typical secure configuration, you will limit access to TCP Ports 80 and 22 to the network CIDR range that maps to the public IPs for your administrative clients (typically exposed through your firewall), and you will limit access to TCP Port 3306 to your administrative client CIDR range and also to the range of IPs used by your application servers (if they are outside your firewall).

Limiting External Access to Your Administrative Clients and Application Servers

This example will walk you through locking down one of the ports used for administrative and application access, namely TCP port 3306, the MySQL protocol port. Locking down the other ports used for administrative access is done in a similar fashion. We chose port 3306 for the example to demonstrate locking down ports to both administrative clients and application servers. For the other ports, you will typically only need to lock down access to your administrative clients.

Assume that the Security Group rules used for your ClustrixDB AWS instances look similar to what was configured in the last example. Notice that all of the ports required for external access are open to all networks.

For this example, assume that your administrative clients are NAT'd to a single public IP defined by 66.211.103.164/32, and that your application servers all reside on a single public network defined by 99.114.137.0/27. You will substitute the appropriate network ranges for your administrative clients and application servers. Using the procedures described in the previous example, we will replace the rule for TCP port 3306 with 2 new rules to expose the ClustrixDB nodes only to clients on the two specified networks.

Step 1 Delete default configuration

Select the Inbound tab to view the Security Group rules, and delete the current rule referring to TCP port 3306 by clicking the Delete Action. The Action will now change to Undelete as shown below.

Image Modified

Step 2 Create a new MySQL Rule

Be sure MySQL is selected for "Create a new rule:", and specify the new rule by specifying the first network range for the Source, and 3306 for the port range. Then add it by clicking Add Rule as shown below.

Image Modified

Your TCP rules will now look like the following.

Image Modified

Step 3 Configure additional network ranges for MySQL

Be sure MySQL is selected for "Create a new rule:", and specify the new rule by specifying the second network range for the Source, and 3306 for the port range. Then add it by clicking Add Rule, after which your rules will look like the following. 

Image Modified

Step 4 - Apply Rule Changes

Finally, click Apply Rule Changes to commit the new rules into the Security Group.

Step 5 - Review Final Security Group Configuration

In the previous section, ports 80, and 22 have already been opened to the Security Group. Now we need to add rules for HTTP and SSH with the CIDR range for your administrative clients, in this example assumed to be 66.211.103.164/32. When you are done, you will have Security Group rules that look similar to the following, with the changed rules highlighted.

Image Modified 


Now that you have created your security group, you can continue with ClustrixDB AWS Installation Guide.  

Questions? Please see Clustrix support offerings.

Sv translation
languageko

이 문서에서는 ClustrixDB용 AWS에서 보안 그룹을 구성하는 모범 사례에 대해 자세히 설명합니다. Amazon이 제공하는 기본 보안 그룹 방화벽 설정을 사용하면 고객이 신속하게 ClustrixDB를 가동할 수 있지만 이러한 설정은 최상의 데이터베이스 네트워크 보안을 제공하지 못합니다. 중요한 데이터를 ClustrixDB에 저장하거나 프로덕션 환경에서 사용하기 전에 Clustrix는 여기에 설명된 네트워크 보안 지침을 이해하고 구현할 것을 권장합니다.

최대한의 보안을 위해 AWS 보안 그룹(AWS Security Group)을 설계하면 다음과 같은 전략으로 위험을 최소화할 수 있습니다.

  • 내부 노드 통신을 위해 네트워크 포트 잠그기
  • 응용 프로그램 액세스 및 관리 제어를 위해 네트워크 포트에 대한 외부 액세스 제한

Table of Contents
maxLevel4

잠긴 보안 그룹 구성 

ClustrixDB에 필요한 포트

Include Page
ClustrixDB Ports
ClustrixDB Ports

EC2 또는 VPC 사용? 

이 페이지에서 설명하는 보안 그룹 구성은 EC2 또는 VPC에 배포되는지 여부에 관계없이 클러스터를 보호합니다. 그러나 EC2와 VPC간에 고려해야 할 몇 가지 중요한 보안상 차이점이 있습니다.

  • EC2에서 서버는 인터넷에서 직접 액세스할 수 있는 AWS 공용 네트워크에 연결됩니다. 따라서 알려진 소스에서 올바른 포트로만 액세스를 허용하도록 보안 그룹을 적절히 구성하는 것이 매우 중요합니다. VPC를 사용하면 노드는 공용 네트워크와 격리된 게이트웨이 뒤에 있는 프라이빗 네트워크에 있으므로 훨씬 안전합니다.
  • EC2에서 로드 밸런서를 사용할 때는 완전히 개방되어 있습니다. 로드 밸런싱된 포트에 연결되는 트래픽을 ACL 또는 보안 그룹을 사용하여 제어할 수 없습니다 ( 이에 대한 AWS 문서 참조). 이런 상황에서 데이터베이스 ACL이 DB 액세스에 대한 유일한 보안 수단이 되므로 보안상 위험할 수 있습니다. VPC에서 로드 밸런서는 연결할 수 있는 트래픽을 완벽하게 제어할 수 있는 전체 보안 그룹을 가지고 있습니다. 이것이 EC2가 아닌 VPC에 ClustrixDB를 배포하도록 권장하는 주된 이유입니다.
  • VPC를 사용하면 여러 서브넷 (프론트엔드, 백엔드), 네트워크 ACL, 보안 그룹, 내부 및 외부 로드 밸런서를 통해 보안 설정을 보다 융통성 있게 수행할 수 있습니다.
  • VPC를 사용하면 향상된 네트워킹(Enhanced Networking)이 활성화된 ClustrixDB AMI를 사용할 수 있습니다.
Warning

위에 설명된 보안상의 이유로 VPC에 ClustrixDB를 배포하는 것이 좋습니다.

보안 그룹 내에 배포

AWS EC2 보안 그룹은 ClustrixDB 노드에서 사용하는 보안 그룹 구성원만 액세스할 수 있도록 이 포트의 보안을 지원합니다. AWS에서 ClustrixDB 클러스터를 성공적으로 구성한 경우 비록 이 규칙이 보안 그룹 구성원에게만 제한되지는 않지만, 보안 그룹에서 이 포트들을 참조하는 규칙이 이미 있습니다.

관리 또는 테스트 목적으로 이 포트에 대한 액세스를 원하는 경우 먼저 SSH를 사용하여 데이터베이스 노드에 로그인한 다음 이 포트 중 하나에 대해 액세스를 허용하는 명령을 실행하십시오.

이러한 포트를 보호하려면 위에 나열된 포트를 참조하는 현재 보안 그룹 규칙을 네트워크 범위 대신 보안 그룹 ID를 나열하는 새로운 규칙으로 바꾸기만 하면 됩니다. 아래 예제는 TCP 포트 2048의 열기 규칙을 자체 참조 규칙으로 바꾸는 단계를 보여줍니다. 나열된 각 포트에 대해 동일한 단계를 수행하여 보안 내부 노드 구성을 완료하십시오.

보안 그룹을 완전히 설정하려면 다음 정보를 수집해야 합니다.

  • 노드에 할당된 그룹의 보안 그룹 ID ( EC2 포털의 보안 그룹 페이지에서 보안 그룹 ID를 찾을 수 있음). 아래 예제의 경우 보안 그룹 ID sg-0d36b666를 사용합니다.
  • 보안 그룹을 ClustrixDB 노드 전용으로 설정하는 것이 좋습니다. 이 보안 그룹에 다른 리소스를 할당하면 안 됩니다. 이렇게 하면 그룹의 자체 참조 규칙을 ClustrixDB 노드에만 적용할 수 있습니다.
  • 멀티포트 사용 여부. 활성화된 경우 노드 수와 노드 당 코어 수를 알아야 합니다. 아래 예제의 경우 각각 8개의 코어가 있는 3개의 노드가 사용됩니다.
  • 응용 프로그램 서버 소스 IP. 아래 예제의 경우 프라이빗 IP 범위  10.0.0.1/24와 EC2 공용 IP 54.144.155.202 및 54.144.155.211이 사용됩니다 (즉, 응용 프로그램 서버 전용 프라이빗 VPC 서브넷과 공용 공간 EC2에 2개의 개별 서버가 있습니다).
  • 관리 클라이언트 소스 IP. 아래 예제의 경우 관리 클라이언트 IP는 198.100.10.204(발신 오피스 IP와 같은 일반 공용 IP)입니다. 
  • 로드 밸런서(LB) 소스 보안 그룹. 예제에서 LB 보안 그룹 이름은 amazon-elb/amazon-elb-sg입니다 (일반적으로 모든 ELB는 항상 보안 그룹 amazon-elb-sg에 있습니다).

EC2 또는 VPC에서 보안 그룹을 만들고 관리하는 방법을 배우려면 Linux 인스턴스용 Amazon EC2 보안 그룹 설명서를 참조하십시오.

내부 노드 통신을 위한 ClustrixDB 백엔드 TCP 및 UDP 포트 보안

ClustrixDB 노드는 노드 간 통신을 위해 일련의 포트를 사용합니다. 클러스터의 각 노드 사이에서 열어야 하므로 이를 백엔드 포트라고 부릅니다. 백엔드 통신은 필수는 아니지만, 전용 네트워크 서브넷으로 격리될 수 있습니다.

백엔드 포트는 위에 나열되어 있습니다. 클러스터의 모든 노드에 대해 이 포트들은 다른 모든 클러스터 노드에서 액세스할 수 있어야 합니다. 보안 그룹은 클러스터 노드 전용이므로 해당 보안 그룹에 할당된 모든 리소스에 대한 액세스를 허용할 수 있습니다. 이것은 자기 참조 규칙으로 설명됩니다. 그룹 A의 경우 소스가 그룹 A일 때 포트 X에 대한 액세스를 허용합니다. 이렇게 하면 훨씬 간단한 보안 그룹 구성이 가능합니다.

응용 프로그램과 관리 액세스를 위한 ClustrixDB 프론트 엔드 TCP 포트 보안

데이터베이스 응용 프로그램에서 그리고 일상적 관리를 위해 ClustrixDB에 액세스하는 데 사용되는 3개의 TCP 네트워크 포트가 있습니다. (80, 22 및 3306)

TCP 포트 80은 ClustrixGUI 관리 UI에 액세스하는 데 사용됩니다.

TCP 포트 22는 고급 관리 및 구성 작업을 위해 명령줄에 액세스하는 데 사용됩니다.

TCP 포트 3306은 일반적으로 프론트엔드 응용 프로그램에서 MySQL 프로토콜을 사용하여 ClustrixDB에 액세스하는 데 사용되고 데이터베이스 관리자가 개발 및 관리 목적으로도 사용합니다.

일반적인 보안 구성에서는 TCP 포트 80 및 22에 대한 액세스를 관리 클라이언트(일반적으로 방화벽을 통해 노출)의 공개 IP에 매핑되는 네트워크 CIDR 범위로 제한하며 TCP 포트 3306에 대한 액세스를 관리 클라이언트 CIDR 범위 및 응용 프로그램 서버(방화벽 외부에 있는 경우)에서 사용되는 IP 범위로 제한합니다.

ClustrixDB 내부 노드 TCP 및 UDP 포트 보안

이 예제에서는 ClustrixDB 내부 노드 통신에 사용되는 포트 중 하나인 보안 포트, 즉 TCP 포트 2048을 안내합니다. 노드 내 통신에 사용되는 다른 포트를 확보하는 것도 비슷한 방식으로 수행됩니다.

이 예제에서는 보안 구성을 위해 수정하기 전에 ClustrixDB AWS 인스턴스에 사용되는 보안 그룹 규칙이 다음과 유사하다고 가정합니다. 이 예제에서 필요한 모든 포트는 모든 네트워크에 열려 있습니다. 이 단계의 목표는 이 액세스를 제한하는 것입니다.

Image Added

1 단계 - 보안 그룹 식별

ClustrixDB 인스턴스에서 사용 중인 보안 그룹의 보안 그룹 ID를 찾습니다. EC2 관리 콘솔에서 NETWORK & SECURITY -> Security Groups로 이동하여 목록에서 Security Group을 선택하십시오. 아래와 같이 Details 탭에서 Security Group ID를 찾을 수 있습니다.

Image Added

2 단계 - 사용자 지정 TCP 규칙 만들기

Inbound 탭을 선택하여 Security Group 규칙을 보고 Delete Action을 클릭하여 TCP 포트 2048을 참조하는 현재 규칙을 삭제하십시오. Action은 아래 그림과 같이 Undelete로 변경됩니다. 


Image Added

3 단계 - 자체 참조 규칙 지정

"Create a new rule:"에 대해 Custom TCP rule이 선택되어 있는지 확인하고 Source에 대한 Security Group ID를 지정하고 포트 범위에 대해 2048을 지정하여 새 자체 규칙을 지정하십시오. 그런 다음 아래와 같이 Add Rule을 클릭하여 추가하십시오.

Image Added

4 단계 - 규칙 변경 적용

규칙 변경 사항이 아래의 강조 표시된 행에 반영됩니다. 마지막으로 Apply Rule Changes를 클릭하여 Security Group을 업데이트하십시오.

Image Added


Security Group Inbound 규칙은 이제 다음과 같이 보입니다.

Image Added


업데이트 Security Group을 사용하는 EC2 인스턴스를 실행 중이면 일반적으로 변경 사항이 잠시 후에 적용됩니다. Security Group 규칙이 변경되면 실행 중인 인스턴스 간에 일시적으로 연결이 끊어질 수 있고 ClustrixGUI 내에서 알 수 있습니다.

5 단계 - 더 많은 맞춤 규칙 만들기

TCP 포트 2048에 대한 규칙 변경을 완료했으면 TCP 포트 22, 80, 2424 및 24378과 UDP 포트 24378에 대해 변경 사항을 비슷하게 계속 적용하십시오. 모든 노드 내 통신 포트에 대해 변경을 하면 Security Group 규칙이 예제와 비슷한 Security Group ID로 대체되어 다음과 유사하게 나타납니다.

Image Added

ClustrixDB 응용 프로그램 및 관리 액세스 제한

데이터베이스 응용 프로그램에서 그리고 일상적인 관리를 위해 ClustrixDB에 액세스하는 데 사용되는 3개의 TCP 네트워크 포트가 있습니다. (80, 22 및 3306)

TCP 포트 80은 ClustrixGUI 관리 UI에 액세스하는 데 사용됩니다.

TCP 포트 22는 고급 관리 및 구성 작업을 위해 명령줄에 액세스하는 데 사용됩니다.

TCP 포트 3306은 일반적으로 프론트엔드 응용 프로그램 및 데이터베이스 관리자가 개발 및 관리 목적으로 MySQL 프로토콜을 사용하여 ClustrixDB에 액세스하는 데 사용됩니다.

일반적인 보안 구성에서는 TCP 포트 80 및 22에 대한 액세스를 관리 클라이언트(일반적으로 방화벽을 통해 노출)의 공개 IP에 매핑되는 네트워크 CIDR 범위로 제한하며 TCP 포트 3306에 대한 액세스를 관리 클라이언트 CIDR 범위 및 응용 프로그램 서버(방화벽 외부에 있는 경우)에서 사용되는 IP 범위로 제한합니다.

관리 클라이언트 및 응용 프로그램 서버에 대한 외부 액세스 제한

이 예제는 관리 및 응용 프로그램 액세스에 사용되는 포트 중 하나, 즉 TCP 포트 3306인 MySQL 프로토콜 포트를 잠그는 방법을 안내합니다. 관리 액세스에 사용되는 다른 포트의 잠금은 비슷한 방식으로 수행됩니다. 관리 클라이언트와 응용 프로그램 서버 모두에 포트를 잠그는 예제를 위해 포트 3306을 선택했습니다. 다른 포트의 경우 일반적으로 관리 클라이언트에 대한 액세스를 잠그면 됩니다.

ClustrixDB AWS 인스턴스에 사용된 보안 그룹 규칙이 마지막 예제에서 구성한 것과 유사하다고 가정합니다. 외부 액세스에 필요한 모든 포트는 모든 네트워크에 개방되어 있습니다.

이 예제에서는 관리 클라이언트가 66.211.103.164/32로 정의된 단일 공용 IP에 대해 NAT가 되고 응용 프로그램 서버가 모두 99.114.137.0/27로 정의된 단일 공용 네트워크에 상주한다고 가정합니다. 관리 클라이언트 및 응용 프로그램 서버의 적절한 네트워크 범위를 대체합니다. 앞의 예제에서 설명한 절차를 사용하여 TCP 포트 3306에 대한 규칙을 2개의 새로운 규칙으로 바꿔 두 개의 지정된 네트워크에 있는 클라이언트에만 ClustrixDB 노드를 표시합니다.

1 단계 기본 구성 삭제

보안 그룹 규칙을 보려면 Inbound 탭을 선택하고 Delete Action을 클릭하여 TCP 포트 3306을 참조하는 현재 규칙을 삭제하십시오. Action은 아래 그림과 같이 Undelete로 변경됩니다.

Image Added

2 단계 새로운 MySQL 규칙 만들기

"Create a new rule:"에 MySQL이 선택되어 있는지 확인하고 Source에 대한 첫 번째 네트워크 범위를 지정하고 포트 범위에 대해 3306을 지정하여 새 규칙을 지정하십시오. 그런 다음 아래에 표시된 Add Rule을 클릭하여 추가하십시오.

Image Added

이제 TCP 규칙은 다음과 같이 보입니다.

Image Added

3 단계 MySQL의 추가 네트워크 범위 구성

"Create a new rule:"에 MySQL이 선택되어 있는지 확인하고 Source에 대한 두 번째 네트워크 범위를 지정하고 포트 범위에 대해 3306을 지정하여 새 규칙을 지정하십시오. 그런 다음 아래에 표시된 Add Rule을 클릭하여 추가하면 규칙이 다음과 같이 표시됩니다.

Image Added

4 단계 - 규칙 변경 적용

마지막으로 Apply Rule Changes를 클릭하여 새 규칙을 보안 그룹에 적용하십시오.

5 단계 - 최종 보안 그룹 구성 검토

이전 섹션에서 포트 80 및 22는 이미 보안 그룹에 열려 있습니다. 이제는 관리 클라이언트의 CIDR 범위(이 예제에서는 66.211.103.164/32)로 HTTP 및 SSH에 대한 규칙을 추가해야 합니다. 완료되면 변경된 규칙이 강조 표시된 다음과 비슷한 보안 그룹 규칙이 생깁니다.

Image Added

질문이 있으십니까? Clustrix 커뮤니티 지원 포럼 또는 기타  지원 서비스를 참조하십시오.