Category: aws

2020년 11월 10일 AWS에서 Gateway Load Balancer(GWLB)를 출시했다.

회사에서 온보딩 진행 중 ELB 를 정리하다 알게 되었다.

자세한 것은 AWS 뉴스 블로그에서 확인할 수 있다.

현재 AWS Gateway Load Balancer를 사용할 수 있는 AWS 리전은 미국 동부(북부 버지니아), 미국 서부(오레곤), EU(아일랜드), 남아메리카(상파울루), 아시아 태평양(시드니) 리전이다.

GWLB는 파트너 어플라이언스의 간단한 배포, 확장성, 고가용성을 제공하는 서비스이다.

반대로 AWS 파트너 네트워크 및 AWS Marketplace 파트너들의 측면에서는 GWLB가 가용성, 확장성과 같은 부분을 해결해 줄 수도 있을 듯. (가격이 더 저렴해질려나?)

기존에 AWS Marketplace 등에서 방화벽을 구축하는 경우 (나의 경우는 WAF) 설계에 고려해야 될 부분과 운영 측면에서도 이슈가 많은데 GWLB를 사용하면 이러한 부분을 많이 해결해 줄 수 있을 것 같다.

GWLB는 OSI 세 번째 계층인 네트워크 계층에서 동작한다.

모든 포트에서 모든 IP 패킷을 받아서, 규칙에 지정된 대상 그룹으로 트래픽을 전달한다.

VPC 내 라우팅 테이블에서 구성을 하면 GWLB로 트래픽을 보낼 수 있고, 고객은 가상 어플라이언스에서 트래픽을 분산하여 탄력적으로 확장/축소를 할 수 있다.

고가용성을 보장하기 위해 GWLB의 고급 라우팅 기능을 사용해 트래픽을 정상 어플라이언스로만 보낼 수 있다. 이건 ALB와 비슷한 것 같다.

GWLB는 모든 VPC와 사용자 계정에서 동작하고, 중앙에서 한 번에 가상 어플라이언스를 관리하는 옵션을 제공한다. 이렇게 하면 복잡성이 줄고 보안이 개선된다고 한다.

GWLB는 양방향의 트래픽 흐름을 동일한 어플라이언스로 보내고, 어플라이언스가 Stateful 하게 트래픽 처리를 하게 한다.

GWLB와 등록된 어플라이언스 인스턴스는 6081 포트의 GENEVE 프로토콜 (IETF가 만든 캡슐화 네트워크 프로토콜)을 사용하여 트래픽을 교환한다.

또 AWS PrivateLink로 구동되는 새로운 유형의 VPC 엔드포인트 – Gateway Load Balancer Endpoint(GWLBe) – 를 통해 어플라이언스를 쉽게 배포 할 수도 있다.

처음에는 API Gateway용인가? 싶었는데, 재미있는 서비스인 것 같다.

실습은 추후에 다시 포스팅 할 예정.

참고자료

https://aws.amazon.com/ko/blogs/aws/introducing-aws-gateway-load-balancer-easy-deployment-scalability-and-high-availability-for-partner-appliances/

https://aws.amazon.com/ko/blogs/korea/introducing-aws-gateway-load-balancer-easy-deployment-scalability-and-high-availability-for-partner-appliances/

2020년 11월 17일 AWS에서 Network Firewall을 출시했다.

자세한 것은 AWS 뉴스 블로그에서 확인 할 수 있다.

이미 NACL, Security Group, WAF, Shield 등이 있지만, 소개 문서에는 다음과 같이 이야기한다.

AWS Network Firewall은 Amazon VPC를 오가는 트래픽이나 Amazon VPC 사이의 트래픽을 검사하고 필터링하고자 하는 고객을 위한 서비스

현재 AWS Network Firewall을 사용할 수 있는 AWS 리전은 미국 동부(버지니아 북부), 미국 서부(오레곤) 및 유럽(아일랜드)이다.

AWS Network Firewall은 VPC에 대한 필수 네트워크 보호 기능을 쉽게 배포할 수 있도록 지원하는 관리형 서비스이다. 몇 번의 클릭으로 서비스를 설정하고, 자동으로 확장할 수 있어서 관리에 신경을 쓸 필요가 없다.

AWS Network Firewall의 유연한 규칙 엔진을 사용하면 네트워크 트래픽을 세부적으로 제어할 수 있는 Firewall policies를 정의하여 악의적인 활동을 방지할 수 있다.

VPC->AWS Network Firewall 카테고리 안에 Firewall policies와 Network Firewall rule groups이 있는데 policies와 groups가 있는 것은 WAF와 비슷한 것 같다.

그리고 이미 공통 오픈소스 규칙 형식으로 만들어진 규칙을 가져올 수 있고, AWS 파트너가 소싱한 인텔리전스 피드와 통합을 활성화 할 수도 있다.

AWS Network Firewall은 AWS Firewall Manager과 함께 작동해서 AWS Network Firewall policies을 VPC 및 계정에 중앙 집중식으로 적용할 수 있다.

가용 영역 별로 방화벽을 사용하며, 각 가용 영역에 대해 트래픽을 필터링 하는 방화벽 엔드포인트 용 서브넷을 선택하고, 각 엔드포인트는 엔드포인트용 서브넷을 제외한 나머지 서브넷을 보호할 수 있다.

AWS Network Firewall의 구성 요소

방화벽(Firewalls)

보호 대항 VPC를 방화벽 정책과 연결한다. 사용자는 보호할 각 가용 영역에 방화벽 엔트포인트 전용 서브넷을 연결한다. 그리고 방화벽 엔트포인트를 통해 트래픽을 전송하도록 라우팅 테이블을 업데이드 한다.

방화벽 정책(Firewall policies)

Stateful, Stateless 규칙 그룹 및 기타 설정을 정의한다.

규칙 그룹(Network Firewall rule groups)

방화벽 정책에 대한 모음이다. 또한 suricate 오픈 소스 규칙을 사용할 수도 있다.

AWS Network Firewall의 기능

1. 고가용성 및 자동 확장

모든 트래픽이 일관성 있게 검사 및 모니터링 되도록 기본으로 이중화 기능을 제공

99.99%의 가용성의 SLA을 제공하며, 트래픽 부하에 따라 방화벽 용량을 자동으로 스케일업/다운할 수 있다.

2. Stateful 방화벽

소스 주소 및 프로토콜 유형에 따라 세분화된 정책을 위해 트래픽의 흐름을 고려하며, 이 Stateful 방화벽의 일치 기준은 AWS Network Firewall Stateless 검사 기능과 동일하며, 트래픽의 방향에 대한 일치 설정이 추가된다. AWS Network Firewall은 TCP/UDP 트래픽 필터링뿐만 아니라 모든 포트를 필터링한다.

3. 웹 필터링

AWS Network Firewall은 암호화 되지 않은 웹 트래픽에 대한 인바운드/아웃바운드 웹 필터링을 지원한다. 암호화된 웹 트래픽은 SNI를 사용하여 FQDN(정규화된 도메인 이름)을 필터링 할 수 있다.

4. 칩입 방지

AWS Network Firewall의 칩입 방지 시스템은 취약성 공격 및 애플리케이션 계층 보호 기능으로 트래픽 흐름 검사를 제공한다.

5. 경고 및 Flow logs

경고 로그는 규칙 별로 상이하며, 트리거된 규칙과 특정 세션에 대한 추가 데이터를 제공한다.

Flow logs는 방화벽을 통과하는 모든 트래픽의 흐름에 대한 상태 정보를 제공하며, AWS S3, Amazon Kinesis, AWS CloudWatch에 저장할 수 있다.

6. 중앙 집중식 관리 및 가시성

AWS Firewall Manager은 AWS 조직의 서비스, VPC 및 계정 전반에 대한 보안 정책을 중앙에서 배포 및 관리 할 수 있다.

7. 규칙 관리 및 사용자 정의

AWS Network Firewall을 통해 고객은 사내 자제 규칙 및 써드 파티, 오픈 소스 플랫폼에서 조달한 Suricata 호환 규칙을 실행할 수 있다.

그렇다면 AWS Network Firewall은 AWS 기존 서비스들과 AWS 마켓 플레이스의 제품과 뭐가 다를까?

AWS Network Firewall 전체 VPC에 대한 3~7 계층의 네트워크 트래픽을 제어하고 가시성을 제공하여 기존 서비스 및 마켓플레이스 제품의 보안을 보완한다. 사용 사례에 따라 VPC 보안 그룹, WAF의 규칙, AWS 마켓플레이스 제품과 같은 기존 보안 규칙을 따라 AWS Network Firewall을 구축할 수 있다.

AWS Network Firewall을 언제 사용해야 될까?

URL, IP, 도메인 기반 트래픽을 제어할 수도 있지만 VPC to VPC, Transit Gateway를 통해 실행되는 AWS Direct Connect 및 AWS VPN 서비스를 보호 할 수 있어서 이런 케이스 때 사용하면 좋을 것 같다.

AWS Network Firewall의 배포 모델

다음에는 HOL을 작성할 예정.

참고 자료

https://aws.amazon.com/ko/blogs/korea/aws-network-firewall-new-managed-firewall-service-in-vpc/

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/

프리티어가 끝나서 새로운 계정을 만들어서 기존 도메인 이전을 했다.

도메인 이전은 AWS CLI로 할 수 있다

자세한 내용은 아래에서 확인할 수 있다.

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53domains/transfer-domain-to-another-aws-account.html

우선 구 계정에서 aws accout id를 확인해야 되는데,

웹 콘솔에서 계정 이름 하위 메뉴에서 확인할 수 있고

aws cli을 이용하면

aws sts get-caller-identity

으로 확인할 수 있다.

우선 기존 계정으로 route53domains transfer-domain-to-another-aws-account를 실행시킨다. 매개변수 –domain-name에는 도메인 명, –account-id에는 위에서 알아낸 AccountID를 입력한다.

aws route53domains transfer-domain-to-another-aws-account --domain-name 도메인명 --account-id AccountID

출력 결과로 아래와 같이 나오는데

{
    "OperationId": "xxx",
    "Password": "xxx"
}

OperationId와 Password는 새로운 계정에서 도메인 이전 승일 때 필요하니 잘 메모해두자.

이제 새로운 계정에서 route53domains accept-domain-transfer-from-another-aws-account을 통해 도메인 이전 승인을 해야한다.

aws route53domains accept-domain-transfer-from-another-aws-account --domain-name 도메인명 --password 위 명령어에서 얻은 패스워드

위와 같이 입력하면 아래와 같은 출력 결과를 볼 수 있다.

{
    "OperationId": "xxxxxxxx"
}

이제 route 53에서 확인을 하면 되는데, 바로 되지는 않고 대략 3~5분 정도가 소요된 것 같다.

route 53 대시보드에 알림 섹션에서 도메인 이전이 된 것을 확인할 수 있다.

이전 시, 기존 서버에서 작성한 호스팅 영역 정보는 자동으로 이전 되지 않는다.

aws cli을 사용해 route53 list-resource-record-sets으로 리스트를 받아와서 마이그레이션 할 수 있다. 이 내용은 차후에 다시 포스팅 할 예정.