Post

[AWS-Security] 7.2. 데이터 보안 문제

Posted
By haksuperman
views 12 min read
[AWS-Security] 7.2. 데이터 보안 문제

1. 데이터 흐름 다이어그램

시스템을 겨냥하는 잠재적 공격에 대비하는 구조화된 브레인스토밍을 위협 모델링(Threat modeling)이라고 부른다. 여기서 가장 유용한 도구가 ‘데이터 흐름 다이어그램’이다. image

  • 개념 : 데이터가 저장되는 위치와 전송되는 경로를 시각적으로 보여주는 도표다.
  • 분석 방법 : 다이어그램의 각 지점마다 아래 세 가지를 확인한다.
    • 기밀성 : 비인가 접근을 어떻게 막을 것인가?
    • 무결성 : 악의적인 데이터 수정을 어떻게 방지하거나 탐지할 것인가?
    • 심층 방어 : 하나의 보안 조치가 뚫리면 어떻게 보호할 것인가?

2. 기밀성 확보 전략

기밀성(Confidentiality)은 승인된 사용자에게만 데이터 읽기 접근을 허용하는 것이다. AWS에서는 IAM(접근 제어)을 사용하거나 KMS(암호화)를 통해 이를 구현한다.

2.1. 지점 A: 저장 데이터의 기밀성 (S3 Bucket 정책 활용)

S3 Bucket에 저장된 데이터에 아무나 접근하지 못하게 하려면, 리소스 기반 정책인 버킷 정책(Bucket Policy)을 사용하여 접근 가능한 사용자를 엄격히 제한해야 한다.

  • 특정 IAM Role을 가진 사용자만 객체를 읽을 수 있도록 허용(나머지는 거부)하는 버킷 정책의 예시
    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

      // 특정 IAM 역할에 대한 GetObject 접근을 제한하는 S3 버킷 정책
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",                  // 조건과 일치하는 사용자에 대해 접근 거부
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::MyBucket/*", 
        "Condition": {
          "StringNotLike": {               // 지정된 IAM Role(ID)을 맡고 있지 않은 '모든 사용자'와 일치
            "aws:userId": [
              "AROAEXAMPLEID:*",           // GetObject를 호출하도록 허용돼야 하는 특정 IAM 역할의 보안 주체 ID
              "111111111111"
            ]
          }
        }
      }
    ]
  }
  • 동작 원리 : StringNotLike조건을 사용하여 접근하려는 사용자의 ID가 지정된 역할 ID와 ‘다를 경우(Not Like)’ 접근을 무조건 거부(Deny)한다. (지정된 역할을 맡은 경우에만 S3 객체를 읽을 수 있음)

2.2. 지점 B: 전송 중인 데이터의 기밀성 (HTTPS 강제 적용)

EC2 인스턴스와 S3 사이에서 데이터가 네트워크를 타고 이동할 때, 누군가 중간에서 데이터를 훔쳐보는 ‘중간자 공격(MiTM 공격)’을 막아야 한다.

전송 중인 데이터 조차 암호화 하는 것이 가장 좋다. 버킷 정책을 통해 S3와 통신할 때 반드시 HTTPS 프로토콜만 사용하도록 강제할 수 있다.

  • 예시 정책
    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

      // 모든 작업에 대한 보안 전송을 강제 적용하는 S3 버킷 정책
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "s3:*",
        "Effect": "Deny",                  // 조건을 충족하는 접근 거부
        "Principal": "*",
        "Resource": [
          "arn:aws:s3:::MyBucket",         // 버킷 자체에 대한 작업 (예: ListBucket)
          "arn:aws:s3:::MyBucket/*"        // 버킷 내 객체에 대한 작업 (예: GetObject)
        ],
        "Condition": {
          "Bool": {
            "aws:SecureTransport": "false" // 요청이 보안 전송 프로토콜(HTTPS)을 사용하지 '않은' 경우(false)와 일치시킴
          }
        }
      }
    ]
  }
  • 동작 원리 : 누군가 암호화되지 않은 안전하지 않은 HTTP 통신으로 S3에 접근하려고 하면("aws:SecureTransport": "false"), 이 정책이 작동하여 모든 S3 작업(s3:*)을 즉시 거부(Deny)한다.

3. 데이터 무결성 확보 전략

데이터 무결성(Data Integrity)을 유지한다는 것은 원치 않는 수정(변조)이나 삭제로부터 데이터를 안전하게 보호하는 것을 의미한다. 일반적으로 이를 위해 아래 세 가지 메커니즘을 함께 사용한다.

  1. 예방(Prevention) : 악의적인 새 데이터 삽입이나 기존 데이터의 수정을 사전에 차단한다.
  2. 탐지 (Detection) : 데이터 변조가 일어났을 때 이를 알아채는 프로세스를 갖춘다.
  3. 복원 (Remediation) : 변조나 삭제가 발생한 최악의 상황에서도 원래 상태로 되돌릴 수 있는 수단을 마련한다.

3.1. 지점 A: 저장 데이터의 무결성 (쓰기 권한 제한 및 버전 관리)

  1. 예방 : S3 쓰기(PutObject) 권한 제한
    • 권한이 없는 사용자가 S3 버킷의 데이터를 수정하지 못하게 하려면, 앞서 읽기 접근 권한을 제한했던 것과 동일한 방식으로 쓰기 접근을 IAM Role로 제한해야 한다.
      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

        // 특정 IAM 역할에 대한 PutObject 접근을 제한하는 S3 버킷 정책
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:PutObject",          // 쓰기(PutObject) 작업 제어
        "Resource": "arn:aws:s3:::MyBucket/*",
        "Condition": {
          "StringNotLike": {
            "aws:userId": [
              "AROAEXAMPLEID:*",           // PutObject 호출이 허용되어야 하는 승인된 IAM 역할의 ID
              "111111111111"
            ]
          }
        }
      }
    ]
  }
    • 이 정책을 적용하면 지정된 역할을 맡지 않은 사람은 데이터를 덮어쓰거나 수정할 수 없으므로 악의적인 변조를 예방할 수 있다.
  2. 복원 : S3 버전 관리(Versioning) 활성화
    • 방어막이 뚫려 데이터가 변조되거나 실수로 삭제하였다면 이를 복구할 수 있는 방법은 백업이다.
    • S3에서는 버전 관리 기능을 활성화하여 쉽게 해결할 수 있다.
    • 버전 관리를 켜면 같은 이름의 파일에 덮어쓰기를 해도 덮어써진 파일이 사라지지 않고 이전 버전으로 남는다.
    • 객체가 삭제되더라도 ‘삭제 마커’만 추가될 뿐 실제 데이터를 숨겨져 있어 언제든 이전 버전으로 복원할 수 있다.
      1
2
3
4

        # 버전 관리를 활성화하는 S3 명령어
  $ aws s3api put-bucket-versioning \
      --bucket my-bucket \                             # 버전 관리를 켤 버킷의 이름
      --versioning-configuration Status=Enabled        # 버킷에 대한 버전 관리 활성화(Enabled)

3.2. 지점 B: 전송 중인 데이터의 무결성 (HTTPS 활용)

EC2 인스턴스와 S3 사이를 이동하는 데이터가 네트워크 중간에서 악의적으로 수정되는 것을 방지하는 가장 쉽고 확실한 옵션은 HTTPS와 같은 보안 프로토콜을 사용하는 것이다.

  • HTTPS를 통해 S3와 통신하면 전송 중에 데이터가 변조되지 않았음을 암호학적으로 보증받을 수 있다.
  • 기본적으로 AWS SDK나 CLI는 HTTPS를 사용하도록 설정되어 있으며, 퍼블릭 객체를 호출할 때도 http:// 대신 https:// URL을 사용하면 된다.
  • 이를 강제적으로 통제하려면, "aws:SecureTransport": "false" 조건을 넣어 HTTPS를 사용하지 않는 모든 접근을 원천적으로 거부(Deny)하면 된다.

4. 심층 방어

심층 방어(Defense in Depth)란 보안 시스템에 문제가 발생할 경우를 대비해 중복 보안 제어(Redundant security control)를 구현하는 방법이다.

  • 목적 : 보안 메커니즘 중 하나가 실패하거나, 잘못 구성되거나, 교묘한 공격자가 이를 우회하더라도 여러 계층의 방어막을 통해 데이터를 계속해서 보호하는 것이다.

4.1. 지점 A: S3 저장 데이터

위 특정 IAM Role만 접근할 수 있도록 1차 방어선을 구축 했지만, 여기에 AWS KMS를 통해 암호화를 추가해 심층 방어선을 구축할 수 있다.

데이터 자체를 AWS KMS(Key Management Service)에 저장된 암호화 키를 사용하여 암호화하는 것이다.

  • 동작 방식 : 이를 적용하면 결과적으로 아래 두 가지 권한이 모두 필요하다.
    • S3 버킷 객체에 접근할 수 있는 IAM Role 권한
    • KMS에서 키를 가져와 데이터를 복호화할 수 있는 KMS 키 사용 권한
  • 효과: 버킷 정책이 뚫리더라도 공격자는 데이터를 복호화할 수 있는 KMS 키 권한이 없기 때문에 데이터는 여전히 알아볼 수 없는 암호화 상태로 남는다. 데이터의 기밀성이 완벽하게 유지되는 것이다.
CLOUD, AWS
cloud aws public cloud
This post is licensed under CC BY 4.0 by the author.