[AWS] AWS VPC 사용설명서 정리(6)

티스토리 뷰

Cloud/Concept

[AWS] AWS VPC 사용설명서 정리(6) - Security

ch4njun 2020. 12. 26. 01:58

VPC의 보안그룹

보안그룹은 연결된 Amazon EC2 인스턴스에 대한 방화벽 역할을 수행하여 인스턴스 수준에서 인바운드 트래픽과 아웃바운드 트래픽을 모두 제어한다. 인스턴스를 시작할 대 생산한 하나 이상의 보안그룹과 인스턴스를 연결할 수 있다.

인스턴스를 시작할 때 보안그룹을 지정하지 않을 경우 VPC에 대해 인스턴스는 기본 보안그룹과 자동으로 연결된다.

각 보안그룹에 대해 인스턴스에 대한 인바운드 트래픽을 제어하는 규칙과 아웃바운드 트래픽을 제어하는 규칙 Set을 추가한다.

보안그룹 기본 사항

허용 규칙을 지정할 수 있지만 거부 규칙은 지정할 수 없다.
인바운드 트래픽과 아웃바운드 트래픽에 별도의 규칙을 지정할 수 있다.
보안그룹 규칙을 사용하면 프로토콜과 포트 번호를 기준으로 트래픽을 필터링할 수 있다.
보안그룹은 상태가 저장된다. 사용자가 인스턴스에 요청을 전송하면 해당 요청의 응답 트래픽은 인바운드 보안그룹 규칙에 관계없이 허용된다. 또한 아웃바운드 규칙에 상관없이 허용된 인바운드 트래픽에 대한 반응으로 외부로 나가는 흐름을 수행한다.
새 보안그룹을 만드는 경우 인바운드 규칙이 별도로 없다. 따라서 추가하기 전에는 밖에서 오는 트래픽을 받을 수 없게된다.
기본적으로 보안그룹은 모든 아웃바운드 트래픽을 허용하는 규칙이 포함된다.
(이 규칙이 남아있는지도 체크를 해줘야될듯 싶긴하다)
VPC당 생성할 수 있는 보안그룹의 수, 각 보안그룹에 추가할 수 있는 규칙의 수, 그리고 네트워크 인터페이스에 연결할 수 있는 보안그룹의 수는 정해져 있다.
트래픽을 허용하는 규칙을 추가하지 않으면 보안그룹과 연결된 인스턴스가 서로 통신할 수 없다.
보안그룹은 네트워크 인터페이스와 연결된다. 인스턴스를 시작한 후 인스턴스에 연결된 보안그룹은 당연히 변경할 수 있다.

VPC의 기본 보안그룹

동일 보안그룹에 할당된 네트워크 인터페이스끼리의 통신만 허용되어있고 나머지는 못들어오도록 되어있다! 나가는건 일단 어디로든 다 나갈수있게 되어있다.

보안그룹 규칙

보안그룹의 규칙을 추가하거나 제거할 수 있다. 규칙은 인바운드 트래픽, 아웃바운드 트래픽에 적용되고 특정 CIDR 범위 또는 VPC나 다른 보안그룹에 대한 정보로 부여할 수 있다.

(InBound) 트래픽의 Source과 대상 포트 또는 포트 범위. Source는 다른 보안그룹, IPv4 CIDR 블록, 단일 IPv4 주소, 접두사 목록 ID일 수 있다.
(OutBound) 트래픽의 Destination과 대상 포트 또는 포트 범위. Destination은 다른 보안그룹, IPv4 CIDR 블록, 단일 IPv4 주소 또는 접두사 목록 ID일 수 있다.
표준 프로토콜 번호를 가진 모든 프로토콜이다.
나중에 쉽게 식별할 수 있도록 설명란이 제공된다.
AWS CLI, 콘솔 또는 API를 사용해 보안그룹 규칙이 추가되는 경우 Source 또는 Destination CIR 블록이 표준 양식으로 자동 설정된다. 100.68.0.18/18 하면 100.68.0.0/18 처럼 네트워크주소로 변경된다.

3-Tier 아키텍쳐에서 적용하는 EC2 Instance에 적용할 보안그룹의 예시이다. (어렵진 않은듯하다)

무효 보안그룹 규칙

VPC에 다른 VPC와의 VPC 피어링 연결이 있는 경우, 보안 그룹 규칙은 피어 VPC의 다른 보안 그룹을 참조할 수 있다. 이를 통해 참조된 보안 그룹과 연결된 인스턴스가 참조하는 보안 그룹과 연결된 인스턴스와 서로 통신할 수 있다.

피어 VPC의 소유자가 참조된 보안 그룹을 삭제하거나 피어 VPC의 소유자가 VPC 피어링 연결을 삭제하면, 보안 그룹 규칙은 stale로 표시된다.

(이런 보안그룹 규칙이 있는지 찾아보는 것도 괜찮을듯)

보안그룹 작업

다음 작업음 Amazon VPC 콘솔을 사용한 보안그룹 작업 방법이다.

기본 보안그룹 수정

기본 보안그룹은 삭제할 수는 없지만 그룹의 규칙을 변경하는 것은 가능하다.

보안그룹 생성

보안그룹 이름하고 VPC 지정하고 바로생성~

(aws ec2 create-security-group / aws ec2 describe-security-groups)

규칙 추가/제거/업데이트

그냥 하면된다...

(aws ec2 authorize-security-group-ingress / aws ec2 authorize-security-group-egress)

(aws ec2 revoke-security-group-ingress / aws ec2 revoke-security-group-egress)

(aws ec2 update-security-group-rule-descriptions-ingress / aws ec2 update-security-group-rule-descriptions-egress)

인스턴스의 보안그룹 변경

VPC에서 인스턴스를 시작한 후 해당 인스턴스와 연결된 보안그룹을 변경할 수 있다. 인스턴스가 running/stopped 상태에 있는 경우 해당 인스턴스의 보안그룹을 변경할 수 있다.

(aws ec2 modify-instance-attribute)

보안그룹 삭제

보안그룹에 할당된 인스턴스가 없는 경우에만 삭제할 수 있다. 기본 보안그룹은 삭제할 수 없다.

(aws ec2 delete-security-group)

AWS Firewall Manager를 사용해 VPC 보안그룹을 중앙에서 관리

AWS Firewall Manager은 여러 계정과 리소스에서의 VPC 보안그룹 관리 및 유지 관리 작업을 간소화한다. 단일 중앙 관리자 계정에서 조직의 보안그룹을 구성하고 감사할 수 있다. 새로 추가한 리소스를 포함한 모든 계정과 리소스에 자동으로 규칙과 보호를 적용한다

조직 전체에서 공통 기본 보안그룹 구성
조직의 기본 보안그룹 감사
규정 미준수 리소스에 대한 보고서 가져오기 및 문제 해결

네트워크 ACL(Access Control List)

네트워크 ACL은 1개 이상의 Subnet 내부와 외부의 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC를 위한 보안 계층이다. 보안그룹과 비슷한 규칙으로 네트워크 ACL을 설정하여 VPC에 보안 계층을 더할 수 있다.

네트워크 ACL 기본 사항

VPC는 수정 가능한 기본 네트워크 ACL을 제공한다. 기본적으로 인바운드 및 아웃바운드 IPv4 트래픽을 허용한다. 기본 네트워크 ACL을 사용하는지 여부 체크해줘야 겠는데?
사용자 지정 네트워크 ACL을 생성해 Subnet과 연결할 수 있다. 기본적으로 각 사용자 지정 네트워크 ACL은 규칙을 추가하기 전에는 모든 인바운드 및 아웃바운드 트래픽을 거부한다.
VPC에 있는 각 Subnet을 네트워크 ACL과 연결해야 한다. Subnet을 네트워크 ACL에 명시적으로 연결하지 않을 경우, 기본 네트워크 ACL에 자동적으로 연결된다.
네트워크 ACL에는 번호가 매겨진 규칙 목록이 포함되어 있다. 가장 낮은 번호가 지정된 규칙부터 시작해서 검사를 진행한다. 나중에 필요한 곳에 새 규칙을 삽입할 수 있도록 일정 공간을 비워두는것이 좋다.
네트워크 ACL에는 별개의 인바운드 및 아웃바운드 규칙이 있으며, 각 규칙은 트래픽을 허용하거나 거부할 수 있다.
네트워크 ACL은 상태 비저장입니다. 즉, 허용되는 인바운드 트래픽에 대한 응답은 아웃바운드 트래픽에 대한 규칙을 따르게 된다.

네트워크 ACL 규칙

기본 네트워크 ACL에 규칙을 추가/제거 하거나, VPC에 대한 네트워크 ACL을 추가로 생성할 수 있다. 네트워크 ACL에 규칙을 추가하거나 제거할 때 네트워크 ACL이 연결되어 있는 Subnet에 변경사항이 자동으로 적용된다.

규칙 번호
유형
프로토콜
포트 범위
Source (출발지)
Destination (목적지)
허용/거부

기본 네트워크 ACL

기본 네트워크 ACL은 연결된 Subnet을 드나드는 트래픽 흐름을 모두 허용하도록 구성되어 있습니다. 각 네트워크 ACL에는 규칙 번호가 별표로 되어 있는 규칙도 포함되어 있다. 이 규칙은 패킷이 번호가 매겨진 다른 어떤 규칙과도 일치하지 않을 경우에는 거부하도록 하는 규칙이다. 이 규칙을 수정하거나 제거할 수 없다.

사용자 지정 네트워크 ACL

예상하는 흐름이니 예시만 확인하고 넘어가자.

광범위한 포트를 합법적으로 열어야 하지만 거부하려는 범위 내에 특정 포트가 있는 경우 거부규칙을 사용하면 된다. 광범위한 포트 트래픽을 허용하는 규칙보다 거부규칙을 먼저 테이블에 배치하면 된다.

(이런 경우도 잘못 구성되어있는걸 잡아주면 좋긴할듯)

여기서 휘발성 포트란 무엇일까?

요청을 보내는 클라이언트가 휘발성 포트를 통해 연결하고 이 휘발성 포트에게 응답을 줘야하기 때문에 휘발성 포트에 대한 아웃바운드 규칙을 생성해줘야 한다.

인바운드에 휘발성 포트 규칙을 추가하는건 좀 이해가안되네... (내가 외부로 요청을 보내는 경우에 대한거겠지, 즉, VPC 내부의 인스턴스가 외부로 요청을 보내는 클라이언트 입장일때!!!!) 이런거에 대한 정확한 영역을 잡고있는지, 아니면 잡혀있는지 등에 대한 정보를 체크는 가능할듯.

실제로 VPC에서 Public쪽 인스턴스로 향하는 트패기을 시작할 수도 있는 다양한 유형의 클라이언트를 포괄하기 위해, 휘발성 포트 1024-65535를 열 수 있다. 하지만 그 범위 내에 있는 악성 포트의 트래픽을 거부하기 위한 규칙을 ACL에 추가해줘야 한다. (배치 순서 위에서 이야기한거)

네트워크 ACL 작업

네트워크 ACL 연결 확인

(aws ec2 describe-network-acls)

네트워크 ACL 생성

(aws ec2 create-network-acl)

규칙 추가 및 삭제

(aws ec2 create-network-acl-entry / aws ec2 delete-network-acl-entry / aws ec2 replace-network-acl-entry)

Subnet을 네트워크 ACL과 연결

네트워크 ACL을 여러 Subnet과 연결할 수 있다. 하지만 Subnet은 하나의 네트워크 ACL만 사용할 수 있다. 기본적으로, 특정 ACL과 연결되지 않은 Subnet은 기본 네트워크 ACL과 연결된다.

Subnet에서 네트워크 ACL 연결 해제

Subent에서 사용자 지정 네트워크 ACL 연결을 해제할 수 있다. Subnet이 사용자 지정 네트워크 ACL과의 연결이 끊어지면 기본 네트워크 ACL에 자동적으로 연결된다.

(aws ec2 replace-network-acl-entry)

Subnet의 네트워크 ACL 변경

(aws ec2 replace-network-acl-entry)

네트워크 ACL 삭제

연결된 Subnet이 없는 경우에만 네트워크 ACL을 삭제할 수 있다. 기본 네트워크 ACL은 삭제할 수 없다.

(aws ec2 delete-network-acl)

VPC 흐름 로그

VPC 흐름 로그는 VPC의 네트워크 인터페이스에서 전송되고 수신되는 IP 트래픽에 대한 정보를 수집하는 기능이다. 흐름 로그 데이터는 Amazon CloudWatch Logs 또는 Amazon S3에 게시될 수 있다. 흐름 로그를 생성한 후 선택된 대상의 데이터를 가져와 확인할 수 있다.

지나치게 제한적인 보안그룹 규칙 진단
인스턴스에 도달하는 트래픽 모니터링
네트워크 인터페이스를 오가는 트래픽 방향 결정

흐름 로그 데이터는 네트워크 트래픽 경로 외부에서 수집되므로 네트워크 처리량이나 지연 시간에 영향을 주지 않는다.

흐름 로그 기본 사항

VPC, Subnet 또는 네트워크 인터페이스에 대한 흐름 로그를 생성할 수 있다. Subnet이나 VPC에 대한 흐름 로그를 생성할 경우, 각 네트워크 인터페이스가 모두 모니터링 된다.

모니터링된 네트워크 인터페이스를 위한 흐름 로그 데이터는 트래픽 흐름을 설명하는 필드로 구성된 흐름 로그 레코드로써 기록된다.

흐름 로그를 생성할 리소스
캡처할 트래픽 유형(허용된 트래픽, 거부된 트래픽 또는 모든 트래픽)
흐름 로그 데이터를 게시할 대상

Subnet이나 VPC에 대한 흐름 로그를 생성한 후 Subnet에서 더 많은 인스턴스를 시작할 경우, 해당 네트워크 인터페이스에 대한 새로운 로그 스트림 혹은 로그 파일 객체를 생성한다.

다음과 같은 AWS 서브스에서 생성한 네트워크 인터페이스에 대한 흐름 로그를 생성할 수 있다.

Elastic Load Balancing
Amazon RDS
Amazon ElastiCache
Amazon Resshift
Amazon WorkSpaces
NAT 게이트웨이
전송 게이트웨이

흐름 로그가 더 이상 필요하지 않을 경우 삭제할 수 있다. 흐름 로그를 삭제하면 리소스에 대한 흐름 로그 서비스가 비활성화된다. 흐름 로그를 삭제해도 네트워크 인터페이스에 대한 기존의 흐름 로그 레코드나 로그 스트림/로그 파일 객체는 삭제되지 않는다. (별도로 삭제해야 한다)

흐름 로그 레코드

흐름 로그 레코드는 VPC에 네트워크 흐름을 나타낸다. 기본적으로 각 레코드는 캡쳐 기간이라고 하는 집계 간격 내에 발생하는 네트워크 IP 트래픽 흐름을 캡쳐한다.

흐름 로그를 생성할 때 흐름 로그 레코드의 기본 형식을 사용하거나, 직접 사용자 지정 형식을 지정할 수 있다.

집계 간격

기본적으로 최대 집계 간격은 10분이다. 흐름 로그를 만들 때 선택적으로 최대 집계 간격을 1분으로 지정할 수 있다. 이렇게 하면 더 많은 양의 흐름 로그 레코드를 생성한다.

기본 형식

<version> <account-id> <interface-id> <srcaddr> <dstaddr> <srcport> <dstport> <protocol> <packets> <bytes> <start> <end> <action> <log-status>

사용자 지정 형식

흐름 로그 레코드의 사용자 정의 형식을 선택적으로 지정할 수 있다. 이를 통해 요구사항에 맞는 흐름 로그를 만들고 관련 없는 필드를 생략할 수 있다. 또한 사용자 지정 형식을 사용하면 게시 된 흐름 로그에서 특정 정보를 추출하기 위한 별도의 과정을 생략할 수 있다.

사용 가능한 필드

뭐 많긴한데 이건 설명서를 직접 참고하자.

docs.aws.amazon.com/ko_kr/vpc/latest/userguide/flow-logs.html#flow-logs-basics

VPC 흐름 로그 - Amazon Virtual Private Cloud

VPC 흐름 로그 VPC 흐름 로그는 VPC의 네트워크 인터페이스에서 전송되고 수신되는 IP 트래픽에 대한 정보를 수집할 수 있는 기능입니다. 플로우 로그 데이터는 Amazon CloudWatch Logs 또는 Amazon S3에 게

docs.aws.amazon.com

흐름 로그 제한

흐름 로그를 만든 후에는 구성 또는 흐름 로그 레코드 형식을 변경할 수 없다.
네트워크 인터페이스에 IPv4 주소가 여러 개 있고 트래픽이 보조 Private IPv4 주소로 전송되는 경우, 흐름 로그는 dstaddr 필드에 주 Private IPv4 주소가 표시된다. 원래 대상 IP 주소를 캡쳐하려면 pkt-dstaddr 필드로 흐름 로그 레코드를 작성해야 한다.
네트워크 인터페이스가 NITRO 기반 인스턴스에 연결된 경우 집계 간격은 지정된 최대 집계 간격에 관계없이 항상 1분 이하이다.

다음 트래픽 유형은 기록되지 않는다.

인스턴스가 Amazon DNS 서버에 연결할 때 생성한 트래픽. (자체 DNS에 대한 트래픽은 기록)
Amazon Windows 라이선스 인증을 위해 Windows 인스턴스에서 생성한 트래픽.
인스턴스 메타데이터를 위해 169.254.169.254와 주고받는 트래픽.
Amazon Time Sync Service를 위해 169.254.169.123과 주고받는 트래픽.
DHCP 트래픽.
기본 VPC 라우터의 예약된 IP 주소로 보내는 트래픽.
엔드포인트 네트워크 인터페이스와 Network Load Balancer 네트워크 인터페이스 간의 트래픽.

흐름 로그 레코드의 예

허용 및 거부된 트래픽

2 123456789010 eni-1235b8ca123456789 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK

계정 12345678910에서 네트워크 인터페이스 eni-1235b8ca123456789에 대한 SSH 트래픽이 허용되었다.

2 123456789010 eni-1235b8ca123456789 172.31.9.69 172.31.9.12 49761 3389 6 20 4249 1418530010 1418530070 REJECT OK

계정 12345678910에서 네트워크 인터페이스 eni-1235b8ca123456789에 대한 RDP 트래픽이 거부되었다.

보안그룹 및 네트워크 ACL 규칙

너무 제한적이거나 허용된 보안그룹 규칙 또는 네트워크 ACL 규칙을 진단하기 위해 흐름 로그를 사용할 수 있다. 이럴 땐 리소스의 상태 저장 여부를 알아야 한다.

보안그룹은 상태가 저장된다. 보안그룹의 규칙에서 허용하지 않더라도 허용된 트래픽에 응답할 수 있다는 뜻이다. 반대로 네트워크 ACL은 상태를 저장하지 않으므로 허용된 트래픽에 대한 응답은 네트워크 ACL 규칙을 따른다.

예를 들어 홈 컴퓨터에서 인스턴스로 ping 명령어를 사용한다. 보안그룹의 인바운드 규칙은 ICMP 트래픽을 허용하지만 아웃바운드 규칙은 ICMP 트래픽을 허용하지 않는다. 보안그룹은 상태 저장을 하므로 인스턴스의 응답 ping이 허용된다. 네트워크 ACL은 인바운드 ICMP 트래픽을 허용하지만 아웃바운드 ICMP 트래픽은 허용하지 않는다. 왜냐하면 네트워크 ACL은 상태를 저장하지 않아서 응답 ping이 홈 컴퓨터에 도달하지 않기 때문이다.

2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027 1432917142 ACCEPT OK

2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094 1432917142 REJECT OK

CloudWatch Logs에 흐름 로그 게시

흐름 로그는 흐름 로그 데이터를 Amazon CloudWatch에 직접 게시할 수 있다.

CloudWatch Logs에 게시하는 경우 흐름 로그 데이터는 로그 그룹에 게시되고, 각 네트워크 인터페이스는 로그 그룹에 고유의 로그 스트림을 갖는다.

CloudWatch Logs에 흐름 로그를 게시하기 위한 IAM 역할

흐름 로그와 연결된 IAM 역할에는 CloudWatch Logs의 지정된 로그 그룹에 흐름 로그를 게시할 권한이 있어야 한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}   

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAM 사용자가 역할을 전달할 수 있는 권한

사용자에게 해당 흐름 로그와 연결된 IAM 역할을 전달할 수 있는 iam:PassRole 작업의 권한이 있어야 한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["iam:PassRole"],
      "Resource": "arn:aws:iam::account-id:role/flow-log-role-name"
    }
  ]
}

CloudWatch Logs에 게시하는 흐름 로그 생성

VPC, 서브넷 또는 네트워크 인터페이스에 대한 플로우 로그를 생성할 수 있다. IAM 사용자로 이러한 단계를 수행하는 경우 iam:PassRole 작업을 사용할 수 있는 권한이 있는지 확인해야 한다.

흐름 로그를 생성하는 방법은 위를 따라하면되고 중요한 부분은 8번에 역할을 부여해줘야 한다는 것이고, 이 작업을 위해서 iam:PassRole 에 대한 권한이 있어야 한다는 것이다.

AWS CLI를 통해 이 작업을 수행하는 명령어는 다음과 같다.

aws ec2 create-flow-logs --resource-type Subnet --resource-ids subnet-1a2b3c4d --traffic-type ACCEPT --log-group-name my-flow-logs --deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs

CloudWatch Logs에서 흐름 로그 레코드 처리

흐름 로그 레코드는 CloudWatch Logs에서 수집한 다른 로그 이벤트처럼 사용할 수 있다.

예: 흐름 로그에 대한 CloudWatch 지표 필터 및 경보 만들기

TCP 포트 22를 거쳐 인스턴스에 연결하려는 시도가 한 시간 내에 10번 이상 거부된 경우 이를 알려주는 알림을 만들 수 있다. 우선 경보를 만들려는 트래픽의 패턴과 일치하는 지표 필터를 만들어야 한다.

Amazon S3에 흐름 로그 게시

흐름 로그는 흐름 로그 데이터를 Amazon S3에 저장할 수 있다.

Amazon S3에 게시하는 경우 흐름 로그 데이터가 지정해 놓은 기존 Amazon S3 Bucket에 저장된다. 모니터링된 모든 네트워크 인터페이스에 대한 흐름 로그 레코드는 Bucket에 젖아된 일련의 로그파일 객체에 저장된다. 흐름 로그가 VPC에 대한 데이터를 캡처하면, 흐름 로그가 모든 네트워크 인터페이스에 대한 흐름 로그 레코드를 선택된 VPC에 게시한다.

흐름 로그 파일

흐름 로그가 저장되는 각 로그 파일에는 이전 5분동안 기록된 IP 트래픽에 대한 흐름 로그 레코드가 포함된다. 로그 파일의 최대 크기는 75MB이고, 로그파일이 5분 내에 파일 크기 제한에 도달하면 흐름 로그가 레코드 추가를 중지한다. 그런 다음 흐름 로그를 Amazon S3 Bucket에 저장하고 새 로그 파일을 만든다.

Bucket의 폴더 구조는 다음 형식을 사용한다.

bucket_ARN/optional_folder/AWSLogs/aws_account_id/vpcflowlogs/region/year/month/day/log_file_name.log.gz

예시를 보면 다음과 같다.

arn:aws:s3:::my-flow-log-bucket/AWSLogs/123456789012/vpcflowlogs/us-east-1/2018/06/20/123456789012_vpcflowlogs_us-east-1_fl-1234abcd_20180620T1620Z_fe123456.log.gz

Amazon S3에 흐름 로그를 저장하는 IAM 보안 주체에 대한 IAM 정책

계정에 있는 IAM 사용자 같은 IAM 보안 주체에는 Amazon S3 Bucket에 흐름 로그를 저장할 충분한 권한이 필요하다. 그 권한은 다음과 같다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogDelivery",
        "logs:DeleteLogDelivery"
        ],
      "Resource": "*"
    }
  ]
}

Amazon S3 Bucket의 흐름 로그에 대한 권한

기본적으로 Amazon S3 Bucket과 포함된 객체는 비공개이다. Bucket 소유자만이 해당 Bucket과 그 안에 저장된 객체에 접근할 수 있다. 그러나 Bucket 소유자는 접근 정책을 작성해 다른 리소스 및 사용자에게 액세스 권하늘 부여할 수 있다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSLogDeliveryWrite",
            "Effect": "Allow",
            "Principal": {"Service": "delivery.logs.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::bucket_name/optional_folder/AWSLogs/account_id/*",
            "Condition": {"StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}}
        },
        {
            "Sid": "AWSLogDeliveryAclCheck",
            "Effect": "Allow",
            "Principal": {"Service": "delivery.logs.amazonaws.com"},
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::bucket_name"
        }
    ]
}

흐름 로그를 생성하는 사용자가 Bucket을 소유하지 않거나 해당 Bucket에 대한 GetBucketPolicy, PutBocketPolicy 권한이 없는 경우, 흐름 로그 생성이 실패한다. 이 경우 Bucket 소유자가 위 정책을 수동으로 추가하고 흐름 로그 생성자의 AWS 계정 ID를 지정해줘야 한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSLogDeliveryWrite",
            "Effect": "Allow",
            "Principal": {"Service": "delivery.logs.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": [
            	"arn:aws:s3:::log-bucket/flow-logs/AWSLogs/123123123123/*",
            	"arn:aws:s3:::log-bucket/flow-logs/AWSLogs/456456456456/*"
            	],
            "Condition": {"StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}}
        },
        {
            "Sid": "AWSLogDeliveryAclCheck",
            "Effect": "Allow",
            "Principal": {"Service": "delivery.logs.amazonaws.com"},
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::log-bucket"
        }
    ]
}

SSE-KMS Bucket에 사용할 경우 필요한 CMK 키 정책

SSE-KMS를 통해 Amazon S3 Bucket에 대하여 서버측 암호화를 활성화한 경우, 흐름 로그가 로그 파일을 Bucket에 쓸 수 있도록 CMK의 키정책에 다음을 추가해야 한다.

{
    "Sid": "Allow VPC Flow Logs to use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "delivery.logs.amazonaws.com"
        ]
    },
   "Action": [
       "kms:Encrypt",
       "kms:Decrypt",
       "kms:ReEncrypt*",
       "kms:GenerateDataKey*",
       "kms:DescribeKey"
    ],
    "Resource": "*"
}

Amazon S3에 저장하는 흐름 로그 생성

흐름 로그 작업

기본적으로 IAM 사용자에게는 흐름 로그 사용권한이 없다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DeleteFlowLogs",
        "ec2:CreateFlowLogs",
        "ec2:DescribeFlowLogs"
      ],
      "Resource": "*"
    }
  ]
}

흐름 로그를 생성하고, 확인하고, 레코드 확인, 삭제하는 등의 작업을 AWS CLI로 수행하는 명령어는 다음과 같다. 물론 AWS EC2 Console 화면에서도 수행할 수 있다.

VPC에 대한 보안 모범 사례

고가용성을 확보할 수 있도록 여러 가용 영역 배포를 사용한다.
보안그룹 및 네트워크 ACL을 사용한다.
IAM 정책을 사용해 액세스를 제어한다.
(체크할 권한들을 정해서 체크하는 방향으로..?)
Amazon CloudWatch를 사용해 VPC 구성 요소 및 VPN 연결을 모니터링한다.
흐름 로그를 사용해 VPC의 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보를 캡처한다.

저작자표시

'Cloud > Concept' 카테고리의 다른 글

[AWS] CloudFront에 대한 기본적인 정리 (0)	2021.02.01
[AWS] AWS Lambda 사용설명서 정리(1) - Security (0)	2021.01.22
[AWS] AWS VPC 사용설명서 정리(5) - Security (0)	2020.12.25
[AWS] AWS VPC 사용설명서 정리(4) - 기본 VPC 및 서브넷 (0)	2020.12.24
[AWS] AWS VPC 사용설명서 정리(3) - 서브넷 (0)	2020.12.22

공지사항

최근에 올라온 글

최근에 달린 댓글

Total

Today

Yesterday

링크

TAG more

« 2024/05 »
일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

글 보관함

ch4njun's blog

티스토리 뷰