Post

[AWS-Security] 7.5. 데이터 접근 로깅

Posted Updated
By haksuperman
views 15 min read
[AWS-Security] 7.5. 데이터 접근 로깅

1. Amazon S3에 대한 접근 로깅

Amazon S3 접근 로그는 특정 S3 버킷에 대한 모든 요청(읽기, 쓰기, 삭제 등)을 추적하는 데 유용하다.

1.1. S3 접근 로깅 구성 및 활성화

  • 모범 사례 : 모든 로그를 수집할 새로운 전용 버킷(대상 버킷)을 별도로 생성하여 로그를 중앙 집중화하는 것이 좋다. 이렇게하면 로그 관리가 쉽게, 원본 데이터와 로그 데이터의 접근 권한을 분리할 수 있다.
  • 주의사항 : 접근 로그 전달은 ‘최선의 노력(best-effort)’로 처리되므로, 로그를 사용할 수 있을 때까지 몇 시간이 걸릴 수 있으며, 드물게 일부 로그 이벤트가 손실될 수도 있다.
  • 로그 전용 버킷 생성 및 기존 버킷의 로깅 활성화
    1
2
3
4
5
6
7
8
9
10

      # S3 버킷 생성 및 접근 로깅 활성화 명령어
	
  # 1. 신규 로그 전용 버킷 생성
  $ aws s3api create-bucket \
      --bucket MyAccessLogsBucket
	
  # 2. 기존 버킷을 업데이트하여 접근 로깅을 시작
  $ aws s3api put-bucket-logging \
      --bucket MyExistingBucket \
      --bucket-logging-status file://logging.json
  • logging.json
    1
2
3
4
5
6

      {
    "LoggingEnabled": {
      "TargetBucket": "MyAccessLogsBucket",
      "TargetPrefix": "MyExistingBucketLogs/"
    }
  }
    • TargetBucket : 접근 로그가 저장될 목적지 버킷의 이름
    • TargetPrefix : 저장되는 모든 접근 로그 파일 이름 앞에 붙을 접두사(폴더명 역할)

1.2. S3 접근 로그 파일의 형식과 내용

로그가 전달되면 설정한 TargetBucket에 파일이 생성된다. 로그 파일의 이름(키)은 2020-07-04-09-00-00-202D373E5200FEDD와 같은 형태로 구성되며, [날짜 및 시간] - [충돌 방지용 임의의 문자열] 로 구성된다.

  • 로그 파일 예시
    1
2

      # S3 접근 로그 항목의 예
  79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8 f8d5218e7cd47ef2be awsexamplebucket1 [06/Feb/2019:00:01:57 +0000] 192.0.2.3 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8d5218e7cd47ef2be DD6CC733AEXAMPLE REST.PUT.OBJECT s3-dg.pdf "PUT /awsexamplebucket1/s3-dg.pdf HTTP/1.1" 200 - - 4406583 41754 28 "-" "S3Console/0.4" - 10S62Zv81kBW7BB6SX4XJ48o6kpc16LPwEoizZQQxJd5qDSCTLX0TgS37kYUBKQW3+bPdrg1234 = SigV4 ECDHE-RSA-AES128-SHA AuthHeader awsexamplebucket1.s3.us-west-1.amazonaws.com TLSv1.1
    • 로그 분석 요약 : 192.0.2.3 IP에서(호출자 IP), 2019년 02월 06일에(타임스탬프), awsexamplebucekt1 버킷에(작동된 버킷), s3-dg.pdf라는 파일을(작동된 객체), 업로드(REST.PUT.OBJECT)하였으며, HTTP 200코드(성공)을 반환받았고, Amazon의 서명 버전 4(SigV4)를 사용해 인증되었다는 의미이다.

1.3. S3 접근 로그 검색 및 분석 방법

수많은 텍스트 파일로 쌓이는 S3 로그를 분석하는 데는 크게 두 가지 방법이 있다.

1.3.1. 방법 A: 로컬 동기화 후 grep 사용

가장 원초적인 방법으로, S3 내의 로그를 내 컴퓨터로 다운로드 후 Linux의 grep 명령어로 문자열을 검색하는 것이다.

1
2
3
4
5
6
7

# S3 접근 로그를 다운로드하고 검색하는 명령어

# 1. S3의 접근 로그를 로컬 컴퓨터 디렉터리에 동기화(다운로드)한다.
$ aws s3 sync s3://MyAccessLogsBucket/MyExistingBucketLogs/ access_logs

# 2. PutObject(업로드) 작업이 포함된 로그 이벤트를 로컬에서 검색한다.
$ grep -r "REST.PUT.OBJECT" access_logs
  • 단점 : 로그 파일이 대용량일 경우, 다운로드하는 데 시간이 오래 걸리며, 막대한 데이터 전송 요금(비용)이 발생할 수 있어 비효율적이다.

1.3.2. 방법 B: Amazon Athena 사용

가장 훌륭한 대안은 Amazon Athena를 사용하는 것이다. Athena는 데이터를 S3에 그대로 둔 상태에서, 표준 SQL 쿼리를 사용해 수기가바이트의 로그를 순식간에 분석할 수 있게 해주는 서버리스 서비스이다.

1
2
3
4
5
6
7
8
9
10
11
12

/* 삭제 이벤트 쿼리 */
-- 중요한 객체(picture.jpg)를 삭제(DELETE)한 IAM 사용자와 시간을 찾는다.
SELECT RequestDateTime, RemoteIP, Requester, Key
FROM s3_access_logs_db.mybucket_logs
WHERE key = 'images/picture.jpg' AND operation like '%DELETE%';


/* 특정 사용자가 버킷에서 삭제한 이벤트 쿼리 */
-- 의심스러운 특정 IAM 사용자(user_name)가 해당 버킷에서 어떤 파일들을 삭제했는지 모두 찾아낸다.
SELECT *
FROM s3_access_logs_db.mybucket_logs
WHERE requester='arn:aws:iam::123456789123:user/user_name';

2. AWS CloudTrail을 통한 API 호출 추적

S3 접근 로그가 특정 파일에 대한 읽기/쓰기를 기록한다면, CloudTrail은 AWS 계정 내에서 발생하는 모든 서비스에 대한 관리 작업(API 호출)을 기록한다.
(ex. 누군가 EC2 인스턴스를 종료했거나, Security Group 규칙을 변경한 기록 등)

2.1. 다중 리전 로깅 활성화

공격자가 관리자가 주로 사용하는 리전이 아닌, 다른 리전에서 악의적인 리소스를 생성할 수 있다. 따라서 모든 리전의 작업을 추적하도록 설정하는 것이 중요하다.

  • 모든 리전의 활ㄹ동을 캡처하는 새 로그 추적(Trail) 생성
    1
2
3
4
5

      # AWS CloudTrail에서 새로운 멀티 리전 로그 추적을 생성하는 명령어
  $ aws cloudtrail create-trail \
      --name "MyTrail" \
      --is-multi-region-trail \
      --s3-bucket-name "my-cloudtrail-bucket"
    • 핵심 옵션 : is-multi-region-trail 플래그를 추가하면 모든 리전에서 발생하는 이벤트를 지정된 하나의 S3 버킷으로 모아준다. 이 플래그가 없으면 추적(Trail)이 생성된 단일 리전의 이벤트만 캡처된다.

2.2. CloudTrail 로그 항목 분석

CloudTrail 로그는 JSON 형태로 저장된다.

  • 예시
    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
32
33
34

      {
    "eventVersion": "1.0",
    "userIdentity": {
      "type": "IAMUser",
      "principalId": "EX_PRINCIPAL_ID",
      "arn": "arn:aws:iam::123456789012:user/Alice",
      "accountId": "123456789012",
      "accessKeyId": "EXAMPLE_KEY_ID",
      "userName": "Alice"
    },
    "eventTime": "2014-03-06T21:01:59Z",
    "eventSource": "ec2.amazonaws.com",
    "eventName": "StopInstances",
    "awsRegion": "us-east-2",
    "sourceIPAddress": "205.251.233.176",
    "userAgent": "ec2-api-tools 1.6.12.2",
    "requestParameters": {
      "instancesSet": {"items": [{"instanceId": "i-ebeaf9e2"}]},
      "force": false
    },
    "responseElements": {
      "instancesSet": {"items": [{
        "instanceId": "i-ebeaf9e2",
        "currentState": {
          "code": 64,
          "name": "stopping"
        },
        "previousState": {
          "code": 16,
          "name": "running"
        }
      }]}
    }
  }
  • userIdentity.arn (누가 했는지) : 작업을 수행한 IAM 보안 주체를 고유하게 식별한다. 위 예시에서는 Alice라는 사용자가 실행했음을 알 수 있다.
  • eventName (무엇을 했는지) : 수행된 API 작업의 이름이다. 위 예시에서는 EC2 서비스의 StopInstance(인스턴스 중지) 작업을 실행했음을 알 수 있다.
  • requestParameters와 responseElements를 통해 어떤 특정 인스턴스(i-ebeaf9e2)가 타깃이 되었고, 상태가 어떻게 변했는지(Running->Stopping) 등의 세부 결과도 확인할 수 있다.

2.3. CloudTrail 로그 검색 방법

이렇게 쌓인 방대한 로그를 검색하는 방법은 크게 세가지가 있다.

  1. 로컬 검색
  2. Amazon Athena 사용
  3. AWS 관리 콘솔 사용

3. 네트워크 접근에 대한 VPC Flow Logs

AWS 환경 내 일부 데이터는 AWS API 호출을 통해서만 접근되는 것이 아니다. 따라서 CloudTrail에 기록되지 않는 데이터가 존재한다. 대표적으로 VPC 내부에 위치한 RDS 리소스에 대한 직접적인 네트워크 접근 트래픽이 있다.

3.1. 시나리오: RDS 데이터베이스 무단 접근 탐지

  • 상황 : PostgreSQL로 만든 RDS 데이터베이스가 있다. 보안 설계 상 이 데이터베이스에는 IP 주소가 10.0.0.1과 10.0.0.2인 두 대의 EC2 인스턴스(웹 서버)만 접근해야 정상이다.
  • 문제 : 보안 사고가 의심될 때, 두 대의 EC2 인스턴스 외에 다른 누군가가 데이터베이스에 접근했는지 확인할 수 있어야 한다.
  • 해결책 : 데이터베이스가 위치한 서브넷이나 네트워크 인터페이스(ENI)에 VPC Flow Logs를 활성화하여 트래픽 기록을 살펴볼 수 있다.

3.1.1. VPC Flow Logs 활성화

VPC Flow Logs는 VPC 내의 네트워크 인터페이스에서 들어오고 나가는 IP 트래픽 정보를 기록하는 서비스다. 시작하려면 대상 VPC나 서브넷 등에 Flow Logs를 활성화해야 한다.

1
2
3
4

$ aws ec2 create-flow-logs \
    --resource-type VPC \
    --resource-ids vpc-123 \
    --traffic-type ALL
  • --resource-type : Flow Logs를 적용할 리소스 유형을 지정한다. (여기서는 VPC 전체)
  • --resource-ids : 대상 리소스의 ID(vpc-123)을 입력한다.
  • --traffic-type : 허용된 트래픽, 거부된 트래픽, 또는 모든 트래픽 중 어떤 것을 기록할 지 지정한다.

3.1.2. CloudWatch를 통한 로그 검색 및 분석

Flow Logs가 활성화되고 트래픽이 발생하면, 이 기록들은 기본적으로 Amazon CloudWatch Logs에 안전하게 저장된다.

  1. Log Group 접근 : AWS VPC 콘솔 하단의 Flow Logs 탭에서 연결된 CloudWatch Logs 그룹 링크를 클릭하여 이동한다.
  2. 필터링 : 로그 그룹 검색 필드에 조사하고자 하는 RDS 데이터베이스의 ENI ID를 입력하여 해당 DB를 향한 트래픽만 필터링한다.
  3. 로그 항목 분석 : Flow Logs의 각 줄은 띄어쓰기로 구분된 여러 요소로 구성된다.
    • 예시 로그 구조 : [버전] [계정ID] [ENI] [출발지 IP] [목적지 IP] [포트] ...
    • 핵심 확인 사항 : 4번째 요소인 SourceIP를 확인한다. 이 IP가 우리가 허용된 EC2 인스턴스의 IP가 아니라면, 누군가 데이터베이스에 무단으로 접근/시도한 것으로 판단할 수 있다.

CloudWatch에 표시되는 로그가 너무 방대하여 화면에서 직접 찾기 어려운 경우, S3로 내보낸 뒤 Amazon Athena를 사용해 SQL 쿼리로 빠르고 정교하게 검색할 수 있다.

3.2. AWS의 3가지 핵심 접근 로깅 옵션

서비스설명 (어떤 데이터를 기록하는가?)주요 접근 기록 (탐지 예시)
CloudTrailAWS 관리 콘솔, CLI, SDK를 통해 수행된 모든 AWS API 호출(제어 작업)을 기록한다.- 누군가 DynamoDB에서 데이터를 쿼리함
- 누군가 S3에서 새로운 버킷을 생성함
- 악의적 사용자가 RDS 데이터베이스 클러스터를 삭제함
S3 접근 로깅로깅이 활성화된 특정 S3 버킷 내부의 객체(파일)에 대한 모든 접근(읽기/쓰기/삭제)을 추적한다.- S3 API를 통해 특정 파일(GetObject)을 다운로드함
- 관리자가 S3 콘솔에서 버킷의 객체 목록을 조회함
- 누군가 퍼블릭 URL을 통해 브라우저에서 S3 이미지를 열어봄
VPC Flow Logs지정한 리소스(ENI, 서브넷, VPC)를 통과하는 네트워크 트래픽(IP, 포트, 프로토콜 등)을 기록한다.- EC2 인스턴스가 동일 서브넷의 다른 인스턴스로 정상적인 통신을 수행함
- 외부의 알 수 없는 해커 머신이 EC2 인스턴스의 22번(SSH) 포트로 연결을 시도했으나 방화벽에 거부(REJECT)됨
CLOUD, AWS
cloud aws public cloud
This post is licensed under CC BY 4.0 by the author.