이 글의 내용은 다양한 보안 그룹을 합리적으로 계획하고 구별하는 방법에 대한 것입니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.
보안 그룹을 사용하는 동안 모든 클라우드 서버는 일반적으로 동일한 보안 그룹에 배치되므로 초기 구성 작업 부하를 줄일 수 있습니다. 그러나 장기적으로 보면 비즈니스 시스템 네트워크의 상호 작용은 복잡해지고 통제할 수 없게 될 것입니다. 보안 그룹 변경 시 규칙 추가 및 제거 범위를 명확하게 정의할 수 없습니다.
다양한 보안 그룹을 적절하게 계획하고 구별하면 시스템을 조정하고, 애플리케이션에서 제공하는 서비스를 구성하고, 다양한 애플리케이션을 계층화하는 것이 더 쉬워집니다. 비즈니스별로 서로 다른 보안 그룹을 계획하고 서로 다른 보안 그룹 규칙을 설정하는 것이 좋습니다.
다른 보안 그룹 구별
공용망 서비스의 클라우드 서버와 인트라넷 서버는 서로 다른 보안 그룹에 속하려고 합니다.
공용 네트워크 서비스를 외부에 제공할지 여부, 외부 액세스(예: 80, 443 등), 수동적으로 제공(예: 클라우드 서버에 공용 IP, EIP, NAT 포트 전달 규칙 등이 있음) 포트 전달 규칙을 사용하면 공용 네트워크에서 애플리케이션에 액세스할 수 있습니다. .
두 가지 시나리오에서 클라우드 서버가 속한 보안 그룹 규칙은 가장 엄격한 규칙을 채택해야 하며 기본적으로 모든 포트와 프로토콜을 닫고 필요한 서비스를 제공하는 포트만 거부하는 것이 좋습니다. 80, 443 등 외부에 노출되어야 합니다. 외부 공용망에 접속하는 서버만 그룹화하기 때문에 보안 그룹 규칙을 조정할 때 제어가 더 쉽습니다.
서버 그룹화를 외부에 제공하는 책임은 명확하고 단순해야 하며, 동일한 서버에서 외부에 다른 서비스를 제공하지 않아야 합니다. 예를 들어 MySQL, Redis 등의 경우 공용 네트워크 접속이 없는 클라우드 서버에 이러한 서비스를 설치한 후, 보안 그룹의 그룹 인증을 통해 접속하는 것이 좋습니다.
현재 다른 애플리케이션과 동일한 보안 그룹 SG_CURRENT에 퍼블릭 클라우드 서버가 있는 경우. 다음 방법을 사용하여 변경할 수 있습니다.
80, 443 등 현재 제공되는 공용 네트워크 서비스에서 노출되는 포트와 프로토콜을 정리합니다.
SG_WEB과 같은 새 보안 그룹을 생성한 다음 해당 포트와 규칙을 추가하세요.
설명: 권한 부여 정책: 허용, 프로토콜 유형: ALL, 포트: 80/80, 권한 부여 개체: 0.0.0.0/0, 권한 부여 정책: 허용, 프로토콜 유형: ALL, 포트: 443/443 권한 개체: 0.0.0.0 /0.
보안 그룹 SG_CURRENT를 선택한 다음 그룹 인증에 보안 그룹 규칙을 추가하여 SG_WEB의 리소스가 SG_CURRENT에 액세스할 수 있도록 허용합니다.
설명: 권한 부여 정책: 허용, 프로토콜 유형: ALL, 포트: -1/-1, 권한 개체: SG_WEB, 우선 순위: 실제 상황에 따라 사용자 정의[1-100].
보안 그룹을 새 보안 그룹으로 전환해야 하는 인스턴스 ECS_WEB_1을 추가합니다.
ECS 콘솔에서 보안 그룹 관리를 선택합니다.
SG_WEB > 인스턴스 관리 > 인스턴스 추가를 선택하고 ECS_WEB_1 인스턴스를 선택하여 새 보안 그룹 SG_WEB에 가입한 후 ECS_WEB_1 인스턴스의 트래픽과 네트워크가 정상적으로 작동하는지 확인합니다.
원래 보안 그룹에서 ECS_WEB_1을 제거하세요.
ECS 콘솔에서 보안 그룹 관리를 선택합니다.
SG_CURRENT 선택 > 인스턴스 관리 > 인스턴스 제거, ECS_WEB_1 선택, SG_CURRENT에서 제거, 네트워크 연결 테스트를 거쳐 트래픽과 네트워크가 제대로 작동하는지 확인합니다.
제대로 작동하지 않는다면 보안그룹 SG_CURRENT에 ECS_WEB_1을 다시 추가하고, 설정된 SG_WEB 노출 포트가 예상대로인지 확인한 후 계속 변경해 보세요.
다른 서버 보안 그룹 변경을 수행합니다.
다른 애플리케이션은 다른 보안 그룹을 사용합니다.
프로덕션 환경에서는 대부분의 경우 다른 운영 체제가 로드 밸런싱 서비스를 제공하는 동일한 애플리케이션 그룹에 속하지 않습니다. 서로 다른 서비스를 제공한다는 것은 노출해야 하는 포트와 거부되는 포트가 다르다는 것을 의미하며, 서로 다른 운영체제는 최대한 서로 다른 보안 그룹에 속해 있는 것이 좋습니다.
예를 들어 Linux 운영 체제의 경우 SSH를 구현하려면 TCP(22) 포트를 노출해야 할 수 있고, Windows의 경우 TCP(3389) 원격 데스크톱 연결을 열어야 할 수 있습니다.
다양한 운영체제가 서로 다른 보안그룹에 속해 있는 것 외에도, 동일한 이미지 종류가 서로 다른 서비스를 제공하더라도 인트라넷을 통해 접속할 필요가 없다면 서로 다른 보안그룹에 속해 있는 것이 가장 좋습니다. 이는 단일 책임을 달성하기 위해 향후 보안 그룹 규칙의 분리 및 변경을 용이하게 합니다.
새 애플리케이션을 계획하고 추가할 때는 서로 다른 가상 스위치 구성 서브넷을 나누는 것을 고려하는 것 외에도 보안 그룹도 합리적으로 계획해야 합니다. 네트워크 세그먼트 + 보안 그룹을 사용하여 자신을 서비스 공급자 및 소비자로 제한하세요.
구체적인 변경 과정은 위의 단계를 참고해주세요.
프로덕션 환경과 테스트 환경은 서로 다른 보안 그룹을 사용합니다
시스템을 더 효과적으로 격리하기 위해 실제 개발 프로세스 중에 여러 테스트 환경 세트와 하나의 온라인 환경 세트를 구축할 수 있습니다. 보다 합리적인 네트워크 격리를 달성하려면 다양한 환경 구성에 대해 다양한 보안 정책을 사용하여 테스트 환경의 변경 사항이 온라인으로 새로 고쳐지고 온라인 안정성에 영향을 미치는 것을 방지해야 합니다.
서로 다른 보안 그룹을 생성하여 애플리케이션의 액세스 도메인을 제한하고 프로덕션 환경과 테스트 환경 간의 연결을 방지합니다. 동시에 여러 테스트 환경 간의 상호 간섭을 방지하고 개발 효율성을 높이기 위해 다양한 보안 그룹을 다양한 테스트 환경에 할당할 수도 있습니다.
공용 네트워크 액세스가 필요한 서브넷이나 클라우드 서버에만 공용 네트워크 IP를 할당하세요
여부 a classic 네트워크가 사설망(VPC)이든 사설망(VPC)이든 공용 네트워크 IP를 합리적으로 할당하면 시스템의 공용 네트워크 관리가 더욱 편리해지고 시스템 공격 위험을 줄일 수 있습니다. 개인 네트워크 시나리오에서는 가상 스위치를 생성할 때 공용 네트워크 액세스가 필요한 서비스 영역의 IP 범위를 여러 고정 스위치(서브넷 CIDR)에 배치하여 감사 및 차별화를 촉진하고 우발적인 공개 노출을 방지하는 것이 좋습니다. 네트워크 액세스.
분산 애플리케이션에서는 대부분의 애플리케이션에 서로 다른 레이어와 그룹이 있습니다. 공용 네트워크 액세스를 제공하지 않는 클라우드 서버의 경우 네트워크 액세스를 위해 공용 네트워크 IP를 제공하지 마세요. , 시스템 가용성을 향상하고 단일 지점을 방지하기 위해 공용 네트워크에 서비스를 제공하도록 공용 네트워크 트래픽 분산을 위한 로드 밸런싱 서비스를 구성하는 것이 좋습니다.
공용 네트워크 액세스가 필요하지 않은 클라우드 서버에는 공용 IP를 할당하지 마십시오. 클라우드 서버가 프라이빗 네트워크의 퍼블릭 네트워크에 액세스해야 하는 경우 먼저 NAT 게이트웨이를 사용하여 VPC에 퍼블릭 IP 주소가 없는 ECS 인스턴스에 대한 인터넷 액세스를 위한 프록시 서비스를 제공하는 것이 좋습니다. 해당 SNAT 규칙은 특정 CIDR 네트워크 세그먼트 또는 서브넷에 대한 공용 네트워크 액세스 기능을 제공할 수 있습니다. 공용 네트워크에 액세스할 수 있는 기능만 필요하므로 공용 IP(EIP)를 할당한 후 공용 네트워크에 서비스가 노출되지 않도록 하세요.
최소 원칙
보안 그룹은 화이트리스트에 등록되어야 하므로 최대한 개방적이고 노출되어야 합니다. 가능한 한 적은 수의 공용 IP 주소를 할당하는 동시에 포트 수를 제한합니다. 작업 로그나 오류 문제 해결을 위해 온라인 머신에 접속하려면 공인 IP를 직접 할당하거나 EIP를 마운트하는 것이 간단하지만 결국 머신 전체가 공용 네트워크에 노출되므로 이를 관리하는 것이 더 안전한 전략입니다. 스프링보드 기계를 통해.
스프링보드 기계를 사용하세요
스프링보드 기계는 도구를 통해 감사를 하는 것 외에도 엄청난 권한을 가지고 있습니다. 기록. 사설망에서는 스프링보드 머신을 전용 가상 스위치에 할당하고 이에 해당하는 EIP 또는 NAT 포트 포워딩 테이블을 제공하는 것이 좋습니다.
먼저 Linux TCP(22) 또는 Windows RDP(3389) 등 해당 포트를 여는 등 전용 보안 그룹 SG_BRIDGE를 생성합니다. 보안그룹의 네트워크 접근 규칙을 제한하기 위해 로그인할 수 있는 인증된 개체를 기업의 공용 네트워크 출구 범위로 제한하여 로그인 및 검사 가능성을 줄일 수 있습니다.
그런 다음 클라우드 서버를 스프링보드 머신으로 보안 그룹에 추가합니다. 이 기기가 해당 클라우드 서버에 액세스할 수 있도록 해당 그룹 인증을 구성할 수 있습니다. 예를 들어 SG_BRIDGE가 특정 포트 및 프로토콜에 액세스할 수 있도록 허용하려면 SG_CURRENT에 규칙을 추가합니다.
Springboard SSH를 사용하는 경우 비밀번호 대신 SSH 키 쌍을 사용하여 로그인하는 것이 좋습니다.
간단히 말해서 합리적인 보안 그룹 계획을 세우면 애플리케이션을 더 쉽게 확장하고 시스템을 더욱 안전하게 만들 수 있습니다.
위 내용은 다양한 보안 그룹을 적절하게 계획하고 구별하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!