인터넷에 공개된 HTTP 포트

HTTP용 TCP 80의 공개가 필요한지 확인하고 내부 서비스의 접근 범위를 제한하고 전송 데이터를 보호하세요.

설명

보안 그룹에서 HTTP에 통상 사용하는 TCP 80을 0.0.0.0/0에 허용하면 모든 IPv4 출발지가 해당 규칙의 허용 대상이 됩니다. 실제 서비스 접근에는 공개 주소, 라우팅과 서비스의 수신 설정 등도 필요합니다. 공개 웹 서비스나 HTTPS 리디렉션에는 의도된 구성이 될 수 있지만, 내부 API나 관리 페이지를 같은 범위로 열 필요는 없습니다.

HTTP는 전송 내용을 암호화하지 않습니다. 공개 여부와 별개로 민감한 정보에는 HTTPS를 사용해야 하며, 리디렉션만으로 최초 HTTP 요청이 보호되지는 않습니다.

잠재적 영향

  • 서비스에 도달할 수 있는 외부 클라이언트가 스캔과 접근을 시도할 수 있습니다.
  • 취약한 인증이나 서비스 결함과 결합하면 무단 접근이 발생할 수 있고, HTTP 통신 내용은 경로상에서 노출되거나 변조될 수 있습니다.

해결 방법

  • 공개가 필요하지 않다면 허용 대상을 실제 서비스 이용자나 관리 연결의 출발지로 제한하세요.
  • 공개 웹 서비스는 HTTPS를 적용하고 필요한 경우 로드 밸런서와 WAF를 사용하세요. 이 제어는 애플리케이션 인증과 권한 검사를 대신하지 않습니다.
  • 연결된 모든 보안 그룹과 넓은 포트 범위 규칙을 확인하고, 관리용 접근을 사용자 트래픽과 분리하세요.

예시

VPC와 CIDR은 실제 환경의 값으로 바꿔야 합니다. 보안 그룹을 서비스에 연결하는 설정은 생략했습니다.

변경 전

yaml
- name: 보안 그룹 생성
  amazon.aws.ec2_group:
    name: web-open
    description: open web security group
    vpc_id: vpc-12345
    rules:
      - proto: tcp
        ports: 80
        cidr_ip: 0.0.0.0/0

TCP 80을 모든 IPv4 출발지에 허용합니다.

변경 후

yaml
- name: 보안 그룹 생성
  amazon.aws.ec2_group:
    name: web-internal
    description: restricted web security group
    vpc_id: vpc-12345
    rules:
      - proto: tcp
        ports: 80
        cidr_ip: 10.0.0.0/16

허용 범위를 지정한 사설 CIDR로 줄입니다. 실제 필요한 클라이언트 범위인지 확인하고 HTTPS도 별도로 적용하세요. 그룹 이름이 다르므로 새 그룹을 연결하고 기존의 넓은 허용 규칙도 제거해야 합니다.

참조