AWS - Security (1): Security Group, ACL, VPC Flow Log
이 포스트는 Security Group 과 Network ACL, 그리고 VPC Flow Log 에 대해 알아본 후 직접 구성하여 동작을 확인해본다.
아래는 이번 포스트에서 다뤄볼 범위 도식화이다.
1. Security Group 과 Network ACL
1.1. Access Control (접근 제어)
Access Control 은 식별(Identity) → 인증(Authentication) → 권한(Authorization) 의 절차로 수행된다.
여기서 대상을 식별하는 기준은 일반적으로 IP 주소나 프로토콜/포트 번호를 통해 서비스를 식별한다.
1.2. Security Group 과 Network ACL
AWS 에서 네트워크 인프라 보호를 위한 트래픽 제어 정책으로 Security Group 과 Network ACL 기능을 사용한다.
둘 다 IP 주소와 프로토콜/포트 번호를 통해 대상을 식별하고 제어 정책에 따라 대상의 허용 여부를 판단하며, 트래픽의 방향에 따라 Inbound rule 과 Outbound rule 로 나뉘어진다.
일반적으로 접근 제어 보안은 Security Group 을 통해 대부분 필터링한다.
하지만 IP 대역 레벨에서 차단이 필요할 경우엔 Network ACL 을 사용한다.
아무래도 Network ACL 은 Stateless 이기 때문에 Inbound/Outbound rule 설정에 민감하여 잘 사용하지 않는 편이다.
1.2.1. Security Group 과 Network ACL 차이
1) 트래픽 제어 대상
- Security Group
- Instance 레벨의 접근 제어
- EC2 Instance 나 ALB 등과 같은 특정 대상에 대한 접근 제어 정책
- Network ACL
- Subnet 레벨의 접근 제어
- VPC 내부에 생성한 Subnet Network 에 대한 접근 제어 정책
2) Stateful vs Stateless
Stateful
이전 상태 정보를 기억하고 있다가 다음 단계에서 그 상태 정보 활용
Stateless
이전 상태 정보를 기억하고 있지 않아 다음 단계에 관여하지 않음
- Security Group
- Stateful 접근 제어 동작
- Inbound 로 들어오는 트래픽에 대해 Inbound rule 에 따라 대상이 허용되면 그 상태 정보를 기억해서 Outbound 로 되돌아갈 때(=리턴 트래픽) Outbound rule 에 상관없이 허용
- Network ACL
- Stateless 접근 제어 동작
- Inbound 로 들어오는 트래픽에 대해 Inbound rule 에 따라 대상이 허용되어도 Outbound 로 되돌아갈 때 Outbound rule 에 따라 허용/거부가 결정됨
3) 허용/거부 규칙
- Security Group
- 허용 규칙만 존재하며 그 대상이 아닌 것은 자동으로 거부됨
- Network ACL
- 허용 규칙과 거부 규칙이 둘 다 존재
- 규칙을 순차적으로 확인하기 때문에 순서를 확인하기 위한 시퀀스 넘버가 존재하며 가장 작은 숫자부터 순차적으로 확인
- 각 규칙별로 대상의 허용/거부를 저장할 수 있으며, 매칭되는 대상이 있으면 하위 규칙은 더 이상 확인하지 않음
- 마지막 규칙은 모든 트래픽에 대해 거부하는 규칙을 자동으로 가짐
(규칙 번호:*, 모든 트래픽/모든 프로토콜/모든 포트번호/모든 소스 IP 는 DENY)
2. VPC Flow Log
VPC Flow Log 는 VPC 에 속한 ENI (네트워크 인터페이스, Elastic Network Interface) 에서 송수신되는 트래픽에 대한 정보를 수집하는 기능이다.
VPC Flow Log 를 통해 네트워크 연결 문제, 보안 문제, 네트워크 접근 제어 정책의 정상 동작 여부 등을 확인할 수 있으며, 특정 유형의 트래픽을 감지하여 알람을 만들거나 트래픽의 변화와 패턴을 파악하기 위한 통계 지표도 만들 수 있다.
위 그림처럼 Subnet A 의 Instance 하나만 대상으로 Flow Logs-A 그룹으로 생성하고, 발생한 Flow Log Record 를 S3 버킷에 쌓아둘 수 있다.
또는 Subnet B 의 Instance 2개를 Flow Logs-B 그룹으로 생성하고, 발생한 Flow Log Record 를 CloudWatch Logs 를 통해 게시할 수 있다.
VPC Flow Log 생성 후 데이터를 수집하여 Flow Log Record 를 제기하는데 1분 혹은 10분의 집계 기간에 따라 대기 시간이 소요될 수 있다. (=로그 정보를 실시간으로 게시하지 않음)
VPC 에서 Flow Log 를 활성화하면 대상 네트워크 인터페이스로 송수신되는 정보를 수집하는데 이 때의 정보 형태를 Flow Log Record 라 한다.
Flow Log Record 의 기본 형식은 아래와 같다.
<ver> <acco-id> <inf-id> <srcaddr> <dstaddr> <srcport> <estport> <prot> <pkts> <bytes> <start> <end> <act> <log-stat>
| Record | |
|---|---|
| ver Version | VPC Flow Log 버전, 기본 형식은 Version 2 |
| acco-id Account-ID | 소스 네트워크 인터페이스 소유자의 AWS 계정 ID |
| inf-id Interface-ID | 기록하는 네트워크 인터페이스 ID |
| srcaddr | 출발지 IP 주소 |
| destaddr | 목적지 IP 주소 |
| srcport | 출발지 포트 번호 |
| destport | 목적지 포트 번호 |
| prot Protocol | 대상 프로토콜 정보 |
| pkts Packets | 전송된 패킷 수 |
| bytes | 전송된 바이트 크기 |
| start | 첫 번째 패킷이 집계된 시간 |
| end | 마지막 패킷이 집계된 시간 |
| act Action | 패킷에 대한 Accept(허용) 과 Reject(거부) 를 구분 |
| log-stat | Flow Log 상태 (OK, NODATA, SKIPDATA) |
VPC Flow Log Record 의 버전을 2가 아닌 3 or 4 로 지정하면 VPC-ID, Subnet-ID, Instance-ID, TCP-Flag, Region, AZ-ID 등 추가적인 필드 사용 가능
2.1. VPC Flow Log 사용 권한
VPC Flow Log 를 통해 VPC 로그 정보를 수집하려면 IAM (Identity & Access Management) 정책과 역할을 생성해야 한다.
3. Security Group 과 Network ACL 차이와 VPC Flow Log 테스트 를 진행하기 전에 VPC Flow Log 에 대한 권한을 생성하는 작업을 해야 한다.
VPC Flow Log 에 대한 권한 생성의 좀 더 자세한 내용은 VPC Flow Log IAM 권한 설정 을 참고하세요.
2.1.1 IAM Policy 생성
[IAM] - [Policies] - [Create policy] - [JSON tab 진입]
아래 내용으로 policy 생성
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
2.1.2. IAM Role 생성
[IAM] - [Roles] - [Create role] 
2.1.3. IAM Role 에서 신뢰 관계 설정
[IAM] - [Roles] - [위에서 생성한 role 선택] - [Trust relationships tab 진입] - [Edit trust policy]
아래 내용으로 policy update
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "vpc-flow-logs.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
2.1.4. CloudWatch Log Group 생성
[CloudWatch] - [Logs] - [Log groups] - [Create log group] 
3. Security Group 과 Network ACL 차이와 VPC Flow Log 테스트
Security Group 과 Network ACL 을 생성하여 동작을 차이를 이해하고, VPC Flow Log 를 통해 Record 를 수집 후 접속 허용과 거부를 확인해본다.
- 기본 환경 구성
- CloudFormation 적용
- CloudFormation 을 통해 생성된 자원 확인
- Security Group 을 통한 Access Control
- Security Group - Inbound Stateful 검증
- Security Group - Outbound Stateful 검증
VPC Flow Log확인
- Network ACL 을 통한 Access Control
- Network ACL - Inbound Stateless 검증
- Network ACL - Outbound Stateless 검증
- Resource 삭제
3.1. 기본 환경 구성
- CloudFormation 적용
- CloudFormation 을 통해 생성된 자원 확인
3.1.1. CloudFormation 적용
[CloudFormation] - [Stacks]
CloudFormation Template Download CloudFormation Template (펼쳐보기)
Parameters:
KeyName:
Description: Name of an existing EC2 KeyPair to enable SSH access to the instances. Linked to AWS Parameter
Type: AWS::EC2::KeyPair::KeyName
ConstraintDescription: must be the name of an existing EC2 KeyPair.
LatestAmiId:
Description: (DO NOT CHANGE)
Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'
AllowedValues:
- /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2
Resources:
MyVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 20.0.0.0/16
Tags:
- Key: Name
Value: jhMy-VPC
MyIGW:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: jhMy-IGW
MyIGWAttachment:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
InternetGatewayId: !Ref MyIGW
VpcId: !Ref MyVPC
MyPublicRT:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref MyVPC
Tags:
- Key: Name
Value: jhMy-Public-RT
DefaultPublicRoute:
Type: AWS::EC2::Route
DependsOn: MyIGWAttachment
Properties:
RouteTableId: !Ref MyPublicRT
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref MyIGW
MyPublicSN:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref MyVPC
AvailabilityZone: !Select [0, !GetAZs '']
CidrBlock: 20.0.0.0/24
Tags:
- Key: Name
Value: jhMy-Public-SN
MyPublicSNRouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref MyPublicRT
SubnetId: !Ref MyPublicSN
ServerSG:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Server1 Security Group
VpcId: !Ref MyVPC
Tags:
- Key: Name
Value: jhServer-SG
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: '22'
ToPort: '22'
CidrIp: 0.0.0.0/0
ServerSG2:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Server2 Security Group
VpcId: !Ref MyVPC
Tags:
- Key: Name
Value: jhServer-SG-2
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: '22'
ToPort: '22'
CidrIp: 0.0.0.0/0
ServerEC2:
Type: AWS::EC2::Instance
Properties:
InstanceType: t2.micro
ImageId: !Ref LatestAmiId
KeyName: !Ref KeyName
Tags:
- Key: Name
Value: jhServer-EC2
NetworkInterfaces:
- DeviceIndex: 0
SubnetId: !Ref MyPublicSN
GroupSet:
- !Ref ServerSG
AssociatePublicIpAddress: true
PrivateIpAddress: 20.0.0.10
UserData:
Fn::Base64: !Sub |
#!/bin/bash
hostname Server-EC2
yum install httpd -y
service httpd start
chkconfig httpd on
echo "<h1>Security Group & Network ACL TEST 1</h1>" > /var/www/html/index.html
ServerEC22:
Type: AWS::EC2::Instance
Properties:
InstanceType: t2.micro
ImageId: !Ref LatestAmiId
KeyName: !Ref KeyName
Tags:
- Key: Name
Value: jhServer-EC2-2
NetworkInterfaces:
- DeviceIndex: 0
SubnetId: !Ref MyPublicSN
GroupSet:
- !Ref ServerSG2
AssociatePublicIpAddress: true
PrivateIpAddress: 20.0.0.20
UserData:
Fn::Base64: !Sub |
#!/bin/bash
hostname Server-EC2-2
yum install httpd -y
service httpd start
chkconfig httpd on
echo "<h1>Security Group & Network ACL TEST 2</h1>" > /var/www/html/index.html
key pair 생성은 AWS - Infra 의 3. 사전 준비 를 참고하세요.
3.1.2. CloudFormation 을 통해 생성된 자원 확인
- VPC
- jhMy-VPC
- IP CIDR: 20.0.0.0/16
- jhMy-VPC
- Public Subnet
- jhMy-Public-SN
- IP CIDR: 20.0.0.0/24
- AZ: ap-northeast-2a
- jhMy-Public-SN
- Public Routing Table
- jhMy-Public-RT
- 연결: jhMy-Public-SN
- 라우팅 정보: 대상: 0.0.0.0/0, 타깃: jhMy-IGW
- jhMy-Public-RT
- IGW
- jhMy-IGW
- 연결: jhMy-VPC
- jhMy-IGW
- Public EC2 Instance
- jhServer-EC2
- 연결: jhMy-Public-SN
- Private IP: 20.0.0.10 (Public IP 사용)
- 데몬: HTTP 구성
- jhServer-EC2-2
- 연결: jhMy-Public-SN
- Private IP: 20.0.0.20 (Public IP 사용)
- 데몬: HTTP 구성
- jhServer-EC2
- Security Group
- jhServer-SG
- 연결: jhServer-EC2
- inbound rule
- SSH(Source) - 0.0.0.0/0
- jhServer-SG-2
- 연결: jhServer-EC2-2
- inbound rule
- SSH(Source) - 0.0.0.0/0
- jhServer-SG
3.2. Security Group 을 통한 Access Control
- Security Group - Inbound Stateful 검증
- Security Group - Outbound Stateful 검증
VPC Flow Log확인
Security Group 은 Stateful 한 접근 제어 동작을 한다. 이 기능을 확인하기 위해 jhServer-SG 의 Security Group 에서 Outbound rule 를 먼저 삭제한다.
3.2.1. Security Group - Inbound Stateful 검증
jhServer-EC2 로 SSH 접속한다.
$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx
[ec2-user@Server-EC2 ~]$
왜 위처럼 정상 접근이 되는지 Security Group 의 Inbound rule 과 Outbound rule 을 대입해서 확인해보자. 
① jhServer-EC2 로 SSH 접근 시도 시 Security Group 의 Inbound rule 을 확인한다.
rule 에 매칭되는 대상이기 때문에 접근이 허용되고 jhServer-EC2 에 도달한다.
② 응답을 줄 때 Security Group 은 Stateful 하게 동작하므로 Inbound rule 에 허용된 대상은 Outbound rule 을 무시하고 전달한다.
3.2.2. Security Group - Outbound Stateful 검증
이제 jhServer-EC2 에서 외부 인터넷 구간의 HTTP 접근을 해본다.
$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx
[ec2-user@Server-EC2 ~]$ curl ifconfig.me --connect-timeout 3
curl: (28) Connection timeout after 3001 ms
외부 인터넷 구간으로 HTTP 접근 시도 시 실패하게 되는데 이는 Outbound rule 에 매핑되는 rule 이 없기 때문이다.
이제 Outbound rule 에 HTTP rule 을 추가해보자.
[EC2] - [Security Groups] - [jhServer-SG 선택] - [Outbound rules] - [Edit outbound rules] - [Add rule]
이제 jhServer-EC2 에서 다시 외부 인터넷으로 HTTP 접근을 하면 정상적으로 접근되는 것을 확인할 수 있다.
[ec2-user@Server-EC2 ~]$ curl ifconfig.me --connect-timeout 3
43.201.46.149
ifconfig.meURL 은 접근한 사용자의 공인 IP 를 출력해주는 외부 웹 서버 주소
① jhServer-EC2 로 SSH 접근 시도 시 Security Group 의 Outbound rule 을 확인한다.
rule 에 매칭되는 대상이기 때문에 접근이 허용되고 외부 웹 서버에 도달한다.
② 외부 웹 서버는 jhServer-EC2 로 응답을 주는데 Security Group 은 Stateful 하게 동작하므로 Outbound rule 에 허용된 대상은 Inbound rule 을 무시하고 전달한다.
즉, Security Group 는 최초 허용된 rule 의 대상이라면 반대 방향의 rule 은 상관없이 허용된다.
3.2.3. VPC Flow Log 확인
VPC Flow Log 를 활성화하여 Security Group 에 의해 허용/거부된 로그 정보들을 확인해본다.
3.2.3.1. VPC Flow Log 생성
[VPC] - [Virtual private cloud] - [jhMy-VPC 선택] - [Action] - [Create flow log]
[VPC] - [Virtual private cloud] - [jhMy-VPC 선택] - [Flow logs tab 진입]
위 메뉴에서 Destination name 을 클릭하면 CloudWatch 로 넘어가 생성된 로그 정보를 확인할 수 있다.
3.2.3.2. VPC Flow Log 확인 (거부 로그 레코드)
아직은 쌓인 로그가 없으므로 jhServer-EC2 로 HTTP 접근을 시도해본다.
현재 Inbound rule 에 SSH 규칙만 있고 HTTP 규칙은 없는 상태이므로 Security Group 에 의해 HTTP 접속은 불가하다.
접속이 거부된 것을 확인했으면 HTTP 접속 실패에 대한 Flow Log 를 확인해보자.
VPC Flow Log 는 VPC 내 Network Interface 별로 로그 정보를 수집한다. 확인할 대상은 jhServer-EC2 의 Network Interface 에 대한 정보이다.
[EC2] - [jhServer-EC2] - [Networking tab 진입] - [Network Interface ID 확인]
CloudWatch Log 에서 위에서 생성한 jh-Log-Group 에 들어가보면 바로 위에서 확인한 Network Interface ID 로 로그 스트림이 생성된 것을 확인할 수 있다. 
로그 스트림을 들어가보면 많은 로그가 나올텐데 본인의 공인 IP 로 필터링해서 보면 원하는 로그 레코드만 확인할 수 있다.
아이피를 통해 사용자 PC 에서 jhServer-EC2 로 접근하는 것을 알 수 있고, 443 6 에서 443 은 포트 번호, 6 은 프로토콜 번호인데 TCP 를 의미한다.
REJECT 를 통해 해당 트래픽이 거부된 것을 확인할 수 있다.
3.2.3.3. VPC Flow Log 확인 (허용 로그 레코드)
이제 본인 PC 에서 jhServer-EC2 로 HTTP 접근을 허용하기 위해 Inbound rule 에 새로운 규칙을 추가한다.
[EC2] - [jhServer-EC2 선택] - [Security tab 진입] - [Inbound rules 의 Security Group 클릭] - [Inbound rules tab 진입]
- Type: HTTP
- Source: Anywhere IPv4
이제 jhServer-EC2 의 공인 IP 로 접속이 정상적으로 되는 것을 확인할 수 있다.
CloudWatch Log 에서 위에서 생성한 jh-Log-Group 에 들어간 후 jhServer-EC2 의 Network Interface ID 로 로그 스트림에서 본인 공인 IP 로 필터링해보자.
3.3. Network ACL 을 통한 Access Control
- Network ACL - Inbound Stateless 검증
- Network ACL - Outbound Stateless 검증
Network ACL 테스트에 앞서 Security Group 이 Network ACL 기능 확인에 영향을 미치지 않도록 Security Group 의 Inbound/Outbound rule 모두 모든 트래픽 허용으로 변경한다.
[VPC] - [Security] - [Security groups] - [jhServer-SG, jhServer-SG-2]
위의 Inbound rule 을 수정한 것처럼 Outbound 도 수정한다.
현재의 Network ACL 은 Subnet 마다 기본 Network ACL 로 매핑되어 있고, 기본 Network ACL 은 Inbound/Outbound rule 모두 모든 트래픽을 허용하고 있다. 
3.3.1. Network ACL - Inbound Stateless 검증
- 신규 Network ACL 생성 (jhMy-NACL)
- Inbound rule 에 SSH 정책 추가
- Outbound rule 에 임시 포트 정책 추가
3.3.1.1. 신규 Network ACL 생성 (jhMy-NACL)
신규 Network ACL 을 생성하여 jhMy-VPC 의 Public Subnet 에 매핑한다.
[VPC] - [Security] - [Network ACLs] - [Create network ACL]
Network ACL 생성 후 클릭하여 들어간 후 Subnet associations 탭에 진입하여 jhMy-VPC 의 Public Subnet 을 추가한다.
생성한 Network ACL 의 Inbound/Outbound rules 를 보면 현재 모든 트래픽이 거부로 되어있다. 
3.3.1.2. Inbound rule 에 SSH 정책 추가
사용자 PC 에서 내부 인스턴스로 SSH 접속을 하기 위해 Inbound rule 에 SSH 접근을 허용하는 규칙을 추가한다. 
규칙 추가 후 사용자 PC 에서 jhServer-EC2 로 SSH 접속을 시도하면 접속이 되지 않는다.
① jhServer-EC2 로 SSH 접근 시도 시 Network ACL 의 Inbound rule 을 확인한다.
허용 규칙에 매칭되는 대상이므로 접근 허용이 되고 jhServer-EC2 에 도달한다.
② jhServer-EC2 는 사용자 PC 로 응답을 주는데 Network ACL 은 Stateless 하게 동작하므로 Outbound rule 을 확인한다.
거부 규칙에 매칭되는 대상이므로 해당 트래픽은 차단된다.
Network ACL Inbound rule 확인 후 Security Group Inbound rule 도 확인하며,
Security Group Outbound rule 확인 후 Network ACL Outbound rule 도 확인하는 절차를 따른다.
3.3.1.3. Outbound rule 에 임시 포트 정책 추가
사용자가 전달하는 타킷인 목적지 포트는 SSH 접근을 하기 위해 22번을 사용한다.
그럼 출발지 포트는 어떻게 될까? 출발지 포트는 임시 포트(Ephemeral port) 를 사용한다. 사용자의 OS 별로 사용하는 임시 포트 범위가 다르며 그 범위 내에서 랜덤하게 사용된다.
결국 Outbound rule 에서 허용한 포트 대상은 사용자의 출발지 포트 범위인 임시 포트 구간을 지정해야 하는데, 편의를 위해 Well-Known 포트 번호를 제외한 1024~65535 로 범위를 잡아보자.
이제 사용자 PC 에서 jhServer-EC2 로 SSH 접속 시도 시 정상적으로 접속이 된다.
$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx
[ec2-user@Server-EC2 ~]$
jhServer-EC2-2 도 SSH 접속이 되는데 Network ACL 은 Subnet 레벨에서 접근 제어를 수행하므로 동일 Subnet 에 속한 jhServer-EC2, jhServer-EC2-2 모두 동일한 영향을 받는다.
3.3.2. Network ACL - Outbound Stateless 검증
- Outbound rule 에 HTTP 규칙 추가
- Inbound rule 에 임시 포트 정책 추가
jhServer-EC2 에서 외부 인터넷 구간으로 통신하는 Outbound 트래픽을 확인해본다.
jhServer-EC2 에 SSH 접근 후 외부 인터넷 구간의 HTTP 로 접근을 시도하면 접근이 되지 않는다.
$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx
[ec2-user@Server-EC2-2 ~]$ curl ifconfig.me --connect-timeout 3
curl: (28) Connection timeout after 3001 ms
목적지 포트가 80 이므로 거부 규칙에 해당하여 통신이 거부된다.
3.3.2.1. Outbound rule 에 HTTP 규칙 추가
jhServer-EC2 에서 외부 웹 서버로 HTTP 접근을 하기 위해 Network ACL 의 Outbound rule 에 HTTP 규칙을 추가한다.
[VPC] - [Security] - [Network ACLs] - [jhMy-NACL 선택] - [Outbound rules tab 진입]
아직 jhServer-EC2 에서 외부 인터넷 구간의 HTTP 접근은 되지 않는다.
① jhServer-EC2 에서 외부 웹 서버로 HTTP 접근 시도 시 Network ACL 의 Outbound rule 을 확인한다.
허용 규칙에 매칭되는 대상이므로 접근 허용이 되고 외부 웹 서버에 도달한다.
② 외부 웹 서버는 jhServer-EC2 로 응답을 주는데 이 때 목적지 포트 번호는 jhServer-EC2 가 보낸 출발지 포트인 임시 포트 번호로 전달한다.
Network ACL 은 Stateless 하게 동작하므로 Inbound rule 을 확인한다.
거부 규칙에 매칭되는 대상이므로 해당 트래픽은 차단된다.
3.3.2.2. Inbound rule 에 임시 포트 정책 추가
이제 jhServer-EC2 에서 외부 웹 서버로 HTTP 접근이 정상적으로 되는 것을 확인할 수 잇다.
$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx
[ec2-user@Server-EC2-2 ~]$ curl ifconfig.me --connect-timeout 3
43.201.33.1
3.4. Resource 삭제
- Network ACL 삭제 ([VPC] - [Security] - [Network ACLs])
- Subnet associations tab 에서 연결된 subnet 삭제 후 Network ACLs 삭제
- CloudWatch Logs Group 삭제 ([CloudWatch] - [Logs] - [Log groups])
- IAM Role 삭제 ([IAM] - [Access management] - [Roles])
- IAM Policy 삭제 ([IAM] - [Access management] - [Policies])
- CloudFormation Stack 삭제 ([CloudFormation] - [Stacks] - [Delete])
CloudFormation Stack 이 삭제되면 위의 3.1.2. CloudFormation 을 통해 생성된 자원 확인 의 자원이 모두 삭제되었는지 확인한다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 김원일, 서종호 저자의 따라하며 배우는 AWS 네트워크 입문를 기반으로 스터디하며 정리한 내용들입니다.
