NACL(Network Access Control List, 네트워크 액세스 제어 목록)
네트워크 ACL은 1개 이상의 서브넷에서 전송 및 송신되는 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC용 선택적 보안 계층입니다. 모든 VPC에는 기본 네트워크 ACL이 자동으로 제공됩니다. 이 ACL은 모든 인바운드 및 아웃바운드 IPv4 트래픽을 허용합니다. 사용자 정의 네트워크 ACL을 생성하여 서브넷과 연결할 수 있습니다. 기본적으로 사용자 정의 네트워크 ACL은 규칙을 추가하기 전에는 모든 인바운드 및 아웃바운드 트래픽을 거부합니다.
네트워크 ACL은 번호가 지정된 규칙 목록을 포함합니다. 번호가 가장 낮은 규칙부터 시작하여 이 목록의 규칙을 차례로 평가합니다. 규칙이 트래픽과 일치하면 번호가 높은 규칙과 상충하더라도 해당 규칙이 적용됩니다. 각 네트워크 ACL에는 번호가 별표인 규칙이 있습니다. 이 규칙은 규칙 번호가 지정되지 않은 모든 패킷을 뜻합니다. 이런 패킷은 기본적으로 거부로 설정하는 것이 바람직합니다.
예시
인바운드 규칙 번호 유형 프로토콜 포트 범위 소스 허용 또는 거부 100 HTTP TCP 80 0.0.0.0/0 허용 101 HTTPS TCP 443 0.0.0.0/0 허용 * 모든 트래픽 ALL ALL 0.0.0.0/0 거부
아웃바운드 규칙 번호 유형 프로토콜 포트 범위 소스 허용 또는 거부 100 사용자 정의
TCP 규칙TCP 1024-65535 0.0.0.0/0 허용 * 모든 트래픽 ALL ALL 0.0.0.0/0 거부
네트워크 ACL 규칙의 구성 요소에는 다음 항목이 포함됩니다.
- 규칙 번호 - 규칙은 번호가 가장 낮은 항목부터 시작하여 차례로 평가됩니다.
- 유형 - Secure Shell(SSH) 등의 트래픽 유형입니다. 모든 트래픽이나 사용자 정의 범위를 지정할 수 있습니다.
- 프로토콜 - 표준 프로토콜 번호가 지정된 어떤 프로토콜이든 지정할 수 있습니다.
- 포트 범위 - 트래픽용 수신 대기 포트 또는 포트 범위 입니다. 예를 들어 HTTP 트래픽에는 80이 사용됩니다.
- 소스 - 트래픽의 소스(CIDR 범위)입니다. 인바운드 규칙에만 적용됩니다.
- 대상 위치 - 트래픽 대상 위치(CIDR 범위)입니다. 아웃바운드 규칙에만 적용됩니다.
- 허용 또는 거부 - 지정된 트래픽을 허용할지 아니면 거부할지를 결정합니다.
네트워크 ACL은 상태 비저장입니다. 즉, 허용되는 인바운드 트래픽에 대한 응답은 아웃바운드 트래픽에 대한 규칙의 적용을 받습니다. 반대의 경우도 마찬가지입니다. 예를 들어, 인바운드 트래픽이 허용되는 경우, 아웃바운드 트래픽도 허용됩니다. 반대의 경우도 마찬가지입니다.
네트워크 ACL은 상태 비저장이기 때문에, 트래픽의 흐름을 보다 세밀하게 제어할 수 없습니다. 또한 트래픽에 규칙을 낮은 번호에서 높은 번호로 하나하나 대조하기 때문에 여러 규칙을 설정하면 속도가 느려질 수 있습니다. 그러나 네트워크 ACL은 간단하고 사용하기 쉽기 때문에, VPC의 리소스에 대한 액세스를 제어하는 데 유용한 도구입니다.
인바운드? 아웃바운드?
인바운드는 들어오는 것을 의미하고, 아웃바운드는 나가는 것을 의미합니다. 인바운드 보안 그룹 규칙은 인스턴스로 들어오는 트래픽을 제어하는 데 사용되는 규칙입니다. 아웃바운드 보안 그룹 규칙은 인스턴스에서 나가는 트래픽을 제어하는 데 사용되는 규칙입니다.
보안 그룹
NACL이 서브넷에 적용됐다면 보안 그룹은 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다. 또 다른 점은 NACL과 달리 거부 규칙이 지원되지 않습니다. 기본 그룹은 동인한 그룹 내의 다른 구성원으로부터의 인바운드 통신과 모든 대상에 대한 아웃바운드 통신을 허용합니다. 트래픽은 IP 프로토콜, 서비스 포트 및 소스 또는 대상 IP 주소를 기준으로 제한할 수 있습니다.
가정용 컴퓨터에서 인스턴스에 대해 ICMP(Internet Control Message Protocol) ping 명령을 실행한다고 가정해 봅시다. 인바운드 보안 그룹 규칙에서 ICMP 트래픽을 허용하는 경우 포트 정보를 포함한 연결 정보가 추적됩니다. ping 명령에 대한 인스턴스의 응답 트래픽은 새 요청으로 추적되지 않으며 설정된 연결로 추적됩니다. 즉, 컴퓨터가 핑에 응답하면 응답에 대한 새 레코드를 만들지 않고 기존 레코드에 응답 정보를 추가합니다. 그러므로 아웃바운드 보안 그룹 규칙에서 아웃바운드 ICMP 트래픽을 제한하더라도 해당 트래픽을 인스턴스 외부로 전송할 수 있습니다.
ICMP는 인터넷에서 에러 메시지를 전송하는 데 사용되는 프로토콜입니다. 그리고 ping 명령은 ICMP를 사용하여 다른 컴퓨터의 연결 상태를 확인하는 데 사용되는 명령입니다.
하지만 모든 트래픽 흐름이 추적되는 것은 아닙니다. 보안 그룹 규칙이 모든 트래픽(0.0.0.0/0)을 대상으로 TCP/UDP을 허용할 수 있습니다. 다른 방향에도 응답 트래픽을 허용하는 해당 규칙이 있으면 해당 트래픽 흐름은 추적되지 않습니다. 따라서 응답 트래픽은 응답 트래픽을 허용하는 인바운드 또는 아웃바운드 규칙을 기준으로 흐름이 허용되며, 추적 정보에 포함되지 않습니다.
예를 들어, 인바운드 보안 그룹 규칙에서 모든 트래픽(0.0.0.0/0)을 대상으로 TCP/UDP을 허용하는 경우, 인스턴스로 들어오는 모든 TCP/UDP 트래픽이 허용됩니다. 아웃바운드 보안 그룹 규칙에서 모든 트래픽(0.0.0.0/0)을 대상으로 TCP/UDP을 허용하는 경우, 인스턴스에서 나가는 모든 TCP/UDP 트래픽이 허용됩니다.
이러한 규칙이 모두 허용되는 경우, 인스턴스로 들어오는 모든 TCP/UDP 트래픽은 허용되고, 인스턴스에서 나가는 모든 TCP/UDP 트래픽은 허용됩니다. 그러나 인바운드 보안 그룹 규칙에서 모든 트래픽(0.0.0.0/0)을 대상으로 TCP/UDP을 허용하고, 아웃바운드 보안 그룹 규칙에서 특정 IP 주소에서 들어오는 TCP/UDP 트래픽만 허용하는 경우, 인스턴스로 들어오는 모든 TCP/UDP 트래픽은 허용되지만, 인스턴스에서 나가는 TCP/UDP 트래픽은 특정 IP 주소로만 허용됩니다.
이러한 규칙을 사용하여 인스턴스로 들어오는 트래픽과 인스턴스에서 나가는 트래픽을 보다 세밀하게 제어할 수 있습니다.
기본 VPC 보안 그룹 설정
기본 VPC를 사용하여 생성한 보안 그룹은 모든 아웃바운드 트래픽을 허용하는 아웃바운드 규칙이 포함돼 있습니다. 이 때 기본 VPC 보안 그룹 설정으로 들어가 해당 규칙을 제거하고 특정 아웃바운드 트래픽만 허용하는 아웃바운드 규칙을 추가할 수 있습니다. 보안 그룹에 아웃바운드 규칙이 없는 경우, 인스턴스에서 시작되는 아웃바운드 트래픽이 허용되지 않습니다. 프로토콜, 서비스 포트 및 소스 IP 주소 또는 보안 그룹을 기준으로 트래픽을 제한할 수 있습니다.
보안 그룹은 다른 클래스의 인스턴스에 대해 서로 다른 규칙을 설정하도록 구성할 수 있습니다. 기존 3 티어 웹 애플리케이션(WEB, WAS, DB)의 경우를 예로 들어 보겠습니다.
- 웹 서버 그룹: 포트 80(HTTP) 또는 443(HTTPS)이 인터넷에서 액세스 가능하도록 설정
- 애플리케이션 서버 그룹: 포트 8000(앱마다 차이가 있을 수 있습니다)이 웹 서버 그룹만 액세스 가능하도록 설정
- 데이터 베이스 서버 그룹: 포트 3306(MySQL)이 애플리케이션 서버 그룹만 액세스 가능하도록 설정
세 그룹 모두 포트 22(SSH)에 대한 관리 액세스는 허용하지만, 고객의 회사 네트워크에서만 이 포트에 액세스할 수 있습니다. 이러한 매커니즘을 통해 매우 안전한 애플리케이션을 배포할 수 있게 됩니다.
트래픽이 상위 티어에서 하위 티어로만 흐른 후 다시 반대로 흐를 수 있도록 인바운드와 아웃바운드 규칙이 설정되야 합니다. 보안 그룹은 특정 티어의 보안 위반 시 손상된 클라이언트가 서브넷 전체에서 모든 리소스에 자동으로 액세스할 수 있게 되는 현상을 방지하는 방화벽 역할을 합니다.
사용자 정의 보안 그룹 규칙
보안 그룹 규칙을 사용하면 프로토콜 및 포트 번호를 기준으로 트래픽을 필터링할 수 있습니다. 보안 그룹은 상태 저장 그룹입니다. 즉, 인스턴스에서 요청을 전송하면 인바운드 보안 그룹 규칙에 관계없이 해당 요청의 응답 트래픽 수신이 허용됩니다.
다중 방어 계층이 있는 인프라 설계
다중 방어 계층으로 인프라를 보호하는 것이 모범 사례라고 할 수 있습니다. 인터넷 게이트웨이와 라우팅 테이블이 적절하게 구성된 VPC에서 인프라를 실행하면서 인터넷에 노출되는 인스턴스를 제어할 수 있습니다. 또한 보안 그룹과 네트워크 ACL을 정의하여 인터페이스 및 서브넷 수준에서 인프라를 추가로 보호할 수도 있습니다. 뿐만 아니라 운영 체제 수준에서 방화벽으로 인스턴스를 보호하고 다른 보안 모범 사례도 준수해야 합니다.
AWS 고객은 대개 보안 그룹을 프라이머리 네트워크 패킷 필터링 방법으로 사용합니다. 보안 그룹은 네트워크 ACL에 비해 더욱 다양하게 활용할 수 있습니다. 상태 저장 패킷 필터링을 수행할 수 있으며, 다른 보안 그룹을 참조하는 규칙을 사용할 수 있기 때문입니다. 반면 네트워크 ACL은 특정 트래픽 하위 집합을 거부하거나 서브넷용으로 대략적인 가드레일을 제어하는 등의 보조 제어 기능으로 사용하면 효율적입니다.
네트워크 ACL과 보안 그룹을 모두 심층 방어 수단으로 구현하면 이러한 컨트롤 중 한가지를 잘못 구성하더라도 호스트가 예기치 못한 트래픽에 노출되지 않습니다.
프라이머리 네트워크 패킷 필터링?
프라이머리 네트워크 패킷 필터링 방법은 네트워크에서 전송되는 패킷을 필터링하는 방법 중 하나입니다. 프라이머리 네트워크 패킷 필터링 방법은 패킷의 소스 IP 주소, 목적지 IP 주소, 프로토콜, 포트 번호 등을 기준으로 패킷을 필터링합니다.
프라이머리 네트워크 패킷 필터링 방법은 네트워크의 보안을 강화하는 데 사용됩니다. 예를 들어, 프라이머리 네트워크 패킷 필터링 방법을 사용하여 특정 IP 주소에서 들어오는 패킷을 차단하거나 특정 프로토콜을 사용하는 패킷을 차단할 수 있습니다.
프라이머리 네트워크 패킷 필터링 방법은 네트워크의 성능을 저하시키는 단점이 있습니다. 프라이머리 네트워크 패킷 필터링 방법은 패킷을 하나하나 검사하기 때문에 네트워크의 트래픽이 많아지면 성능이 저하될 수 있습니다.
프라이머리 네트워크 패킷 필터링 방법은 네트워크의 보안을 강화하는 데 유용한 방법이지만, 네트워크의 성능을 저하시키는 단점이 있습니다. 따라서, 프라이머리 네트워크 패킷 필터링 방법을 사용할 때는 네트워크의 보안과 성능을 모두 고려해야 합니다.
상태 저장 패킷 필터링?
상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링의 한 종류입니다. 상태 저장 패킷 필터링은 패킷의 소스 IP 주소, 목적지 IP 주소, 프로토콜, 포트 번호뿐만 아니라 패킷의 흐름 상태를 고려하여 패킷을 필터링합니다.
상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링보다 보안이 뛰어납니다. 프라이머리 네트워크 패킷 필터링은 패킷의 흐름 상태를 고려하지 않기 때문에, 공격자가 패킷의 흐름 상태를 조작하여 보안을 우회할 수 있습니다.
상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링보다 성능이 좋은 만큼 네트워크의 성능을 더 저하시킨다는 단점이 있습니다. 상태 저장 패킷 필터링은 패킷의 흐름 상태를 저장하고 관리하기 때문에 네트워크의 트래픽이 많아지면 성능이 저하될 수 있습니다. 따라서, 상태 저장 패킷 필터링을 사용할 때는 네트워크의 보안과 성능을 모두 고려해야 합니다.
보안 그룹과 NACL 비교 정리
보안 그룹 | NACL |
탄력적 네트워크 인터페이스에 연결되며 하이퍼바이저에서 구현됨 | 서브넷에 연결되며 네트워크에서 구현됨 |
허용 규칙만 지원 | 허용/거부 규칙 지원 |
상태 저장 방화벽 | 상태 비저장 방화벽 |
트래픽 허용 여부를 결정하기 전에 모든 규칙이 평가됨 | 트래픽 허용 여부를 결정할 때 모든 규칙은 순서대로 평가됨 |
인스턴스와 연결된 경우 인스턴스에만 적용됨 | 연결된 서브넷에 배포된 모든 인스턴스에 적용됨 |
'자격증 > AWS SAA' 카테고리의 다른 글
[AWS SAA] 12. EC2(Elastic Compute Cloud) Part.01 (0) | 2023.07.03 |
---|---|
[AWS SAA] 11. AWS 컴퓨팅의 발전 과정 (0) | 2023.07.03 |
[AWS SAA] 9. VPC(Virtual Private Cloud) Part.02 (0) | 2023.07.02 |
[AWS SAA] 8. VPC(Virtual Private Cloud) Part.01 (0) | 2023.07.02 |
[AWS SAA] 7. IP와 CIDR (0) | 2023.07.02 |