AWS 암호화

Siyun·2025년 3월 16일
aws

AWS

목록 보기
30/37

클라우드에서의 세 가지 암호화 메커니즘 정리

1. 전송 중 암호화 (Encryption in Transit)

  • TLS(Transport Layer Security) 또는 SSL(Secure Sockets Layer)을 사용하여 데이터 전송 시 암호화함.
  • HTTPS를 사용하면 클라이언트와 서버 간의 데이터가 TLS 인증서를 통해 암호화됨.
  • 목적: 네트워크 상에서 중간자 공격(Man-in-the-Middle Attack)을 방지하고, 데이터의 기밀성을 유지하기 위함.
  • 예시: 로그인 시 사용자명과 비밀번호를 TLS로 암호화하여 서버로 전송하면, 중간 서버는 내용을 해독할 수 없고 오직 대상 서버만 해독 가능.

2. 저장 중 암호화 (Encryption at Rest)

  • 서버가 받은 데이터를 저장하기 전에 암호화하여 보관하는 방식.
  • 데이터 키(Data Key)를 사용하여 암호화하며, 해독 시에도 동일한 키를 활용함.
  • 목적: 서버에 저장된 데이터가 유출되더라도 해독 키 없이는 읽을 수 없도록 보호하기 위함.
  • 예시:
    • Amazon S3에 데이터를 업로드할 때, 서버가 이를 암호화하여 저장함.
    • 서버가 데이터를 다시 제공할 때, 저장된 암호화된 데이터를 해독하여 클라이언트에게 전달.

3. 클라이언트 측 암호화 (Client-Side Encryption)

  • 데이터를 클라이언트가 직접 암호화하고 서버에 저장하는 방식.
  • 서버는 암호화된 데이터만 저장하며, 해독 키가 없으므로 내용을 확인할 수 없음.
  • 목적: 서버를 신뢰할 수 없거나, 데이터 보호 수준을 극대화하기 위함.
  • 예시:
    • 클라이언트가 데이터를 암호화한 후 Amazon S3, FTP 서버 등에 저장.
    • 이후 데이터를 가져올 때, 클라이언트가 자체적으로 해독하여 사용.

AWS KMS

1. KMS란?

  • AWS KMS(Key Management Service)는 암호화 키를 중앙에서 관리하는 서비스이다.
  • AWS의 다양한 서비스와 통합되어 있으며, 데이터를 암호화하는 데 사용된다.
  • IAM(Identity and Access Management)과 완벽하게 통합되어 접근 제어가 가능하다.
  • AWS CloudTrail과 연동하여 KMS 키 사용 내역을 감사할 수 있다.

2. KMS의 주요 특징

  • 대부분의 AWS 서비스에서 암호화 지원

    • EBS, S3, RDS, DynamoDB, SSM 등 다양한 서비스에서 KMS를 활용할 수 있다.
    • 해당 서비스에서 KMS 암호화를 활성화하면 자동으로 데이터가 암호화된다.

  • API를 통한 암호화 및 복호화 지원

    • AWS CLI 또는 SDK를 사용하여 API 호출을 통해 데이터를 암호화할 수 있다.
    • 암호화된 데이터를 환경 변수 또는 코드에서 안전하게 저장할 수 있다.

3. KMS 키 유형

KMS 키는 크게 두 가지 유형으로 나뉜다.

  • 대칭 키(Symmetric Key)

    • 하나의 키를 사용하여 암호화 및 복호화를 수행한다.
    • 대부분의 AWS 서비스에서 사용되는 기본적인 암호화 방식이다.
    • 사용자는 키 자체에 접근할 수 없으며, AWS API를 통해서만 사용 가능하다.

  • 비대칭 키(Asymmetric Key)

    • 퍼블릭 키와 프라이빗 키 한 쌍으로 구성된다.
    • 퍼블릭 키로 데이터를 암호화하고, 프라이빗 키로 복호화한다.
    • 외부 사용자가 KMS API에 접근할 수 없을 때 퍼블릭 키를 이용하여 암호화를 수행할 수 있다.
    • 프라이빗 키는 AWS 내부에서만 접근 가능하며, API를 통해서만 사용할 수 있다.

4. KMS 키의 종류

KMS 키는 AWS에서 제공하는 방식에 따라 세 가지로 나뉜다.

  1. AWS 소유 키(AWS-Owned Keys)

    • AWS에서 직접 관리하는 키로, 사용자는 키를 볼 수 없다.
    • SSE-S3(S3 자체 암호화), SSE-DynamoDB 등의 서비스에서 사용된다.
    • 무료로 제공된다.

  2. AWS 관리형 키(AWS-Managed Keys)

    • 특정 서비스 전용으로 AWS에서 관리하는 키이다.
    • 키 이름이 aws/service-name 형태로 지정된다.
    • 예: aws/rds, aws/ebs, aws/dynamodb
    • 무료로 제공되지만, 특정 서비스 내에서만 사용할 수 있다.

  3. 고객 관리형 키(Customer-Managed Keys)

    • 사용자가 직접 생성하고 관리하는 KMS 키이다.
    • 한 달에 1달러의 비용이 발생하며, API 호출 횟수에 따라 추가 요금이 부과된다.
    • 키 가져오기(import) 및 자동 키 순환(rotation) 기능을 지원한다.

KMS 키의 가격 : 대략 10,000회의 API 호출당 3센트

5. KMS 키의 자동 순환(Rotation)

  • AWS 관리형 키는 1년마다 자동으로 순환된다.
  • 고객 관리형 키는 사용자가 직접 자동 순환을 활성화해야 한다.
  • 임포트된 키는 자동 순환이 불가능하며, 수동으로 교체해야 한다.

6. KMS 키의 리전 제한

  • KMS 키는 리전 단위로 관리된다.
  • 다른 리전에서 동일한 KMS 키를 사용할 수 없으며, 리전 간 데이터 이동 시 새로운 KMS 키로 암호화를 수행해야 한다.
  • 예를 들어, EBS 볼륨의 스냅샷을 다른 리전으로 복사하려면 새로운 KMS 키를 사용하여 암호화해야 한다. 새로 암호화하는 부분은 AWS가 대신 해준다.

7. KMS 키 정책(Key Policy)

KMS 키에 대한 접근을 제어하는 정책으로, IAM 정책과 유사하다.
키 정책이 없으면 아무도 해당 키에 접근할 수 없다.

  • 기본 키 정책(Default Key Policy)

    • 특정 키 정책을 설정하지 않으면 자동으로 적용된다.
    • 기본적으로 계정 내의 모든 사용자가 키에 접근할 수 있다.
    • IAM 정책과 함께 사용하면 보다 세밀한 접근 제어가 가능하다.

  • 커스텀 키 정책(Custom Key Policy)

    • 특정 사용자 또는 역할(Role)만 키에 접근할 수 있도록 설정할 수 있다.
    • 교차 계정에서 액세스(Cross-Account Access) 하려고 할 때 유용하다.
    • 예를들어 암호화된 스냅샷을 타깃 계정과 공유한다. 그리고 타깃 계정에서 스냅샷의 사본을 생성하고 다른 고객 관리형 키를 사용해서 데이터를 암호화한다.

8. 교차 계정 KMS 키 사용

  • 암호화된 데이터를 다른 계정과 공유하려면 고객 관리형 키가 필요하다.
  • KMS 키 정책을 수정하여 특정 계정이 해당 키를 사용할 수 있도록 허용해야 한다.
  • 예를 들어, 암호화된 EBS 스냅샷을 다른 계정과 공유할 경우, KMS 키 정책에서 해당 계정에 대한 접근 권한을 추가해야 한다.

KMS 서비스 실습

KMS 콘솔에서 아래의 세가지 탭을 확인할 수 있다.

관리형 키(AWS managed keys)

  • AWS 서비스를 사용하며 생긴 관리형 키들을 확인할 수 있다.
  • Key policy에서는 해당 키에 액세스할 수 있는 항목을 정의한다.
  • Cryptographic configuration탭에서는 키가 대칭키인지 비대칭키인지, 오리진, 키 스펙, 키의 사용처(암복호화)를 확인할 수 있다.

사용자 지정 키 스토어(Custom key stores)

사용자 지정 키 스토어는 CloudHSM에서 사용된다.

고객 관리형 키(Customer managed keys)

  • KMS로 자체 키를 생성하고 싶을 때 사용한다.
  • 키를 생성하면 월 1달러의 비용이 발생한다.

고객 관리형 키 생성하기

  • 키 유형을 대칭, 비대칭 중 선택할 수 있다.
    • 비대칭 유형을 선택할 경우 용도를 '암호화 및 복호화'나 '서명 및 확인'중 선택할 수 있다.
  • 고급 옵션에서 키 구성 요소 오리진은 KMS로 선택한다. 키를 가져오려면 오리진을 외부(External)로 선택한다. Custom key store는 CloudHSM에서 사용한다.
  • 리전 구분은 '단일 리전 키'와 '다중 리전 키'로 나뉜다. 단일 리전 키가 가장 오래된 유형이면서 널리 사용된다.
  • 키 관리자를 정의할 수 있다. 정의하지 않으면 기본 KMS 키 정책을 사용하게 된다.
  • 키 사용자를 정의할 수 있다. 특정 유저만 사용할 수 있도록 할 수 있고 하단의 Other AWS accounts를 선택하면 다른 AWS 계정도 접근할 수 있도록 한다.

고객 관리형 키 확인하기

  • Key policy에서는 키에 대한 IAM 정책을 볼 수 있고 수정할 수 있다.
    키 관리자, 키를 삭제할 수 있는지, 키 사용자, 다른 AWS 계정 액세스 여부를 확인할 수 있다.
  • 자동 키 교체(Key rotation) 탭에서 자동 키 교체를 활성화할 수 있다. 활성화하면 키가 1년에 한번씩 교체된다.
  • 별칭을 설정하면 별칭 ARN에서 참조하기가 쉬워진다.
  • Key actions에서 키를 비활성화하거나 키 삭제 예약 설정을 할 수 있다.

KMS키로 평문 암복호화 예제

  • 암호화하기
aws kms encrypt \
    --key-id <KMS_KEY_ID> \
    --plaintext "Hello, KMS Encryption!" \
    --query CiphertextBlob \
    --region eu-west-2\
    --output text | base64 --decode > encrypted.txt

<KMS_KEY_ID> 부분에 앞서 생성한 키의 ID 혹은 별칭(alias/별칭 이런 식) 혹은 별칭ARN을 입력한다.
리전은 해당 키가 저장된 리전을 입력한다.
암호화된 데이터는 encrypted.txt 파일에 저장된다.

  • AWS KMS는 암호화된 데이터를 Base64로 인코딩해서 반환하기 때문에, 이를 원래의 이진(Binary) 형태로 저장하려면 base64 --decode를 사용해야 한다.
  • 디코딩을 하지 않고 저장하면 암호화된 데이터가 Base64 인코딩된 상태로 저장되므로,
    aws kms decrypt로 복호화할 때 --ciphertext-blob fileb://<(base64 --decode < encrypted.txt) 이러한 방식으로 base64 --decode를 추가로 수행해야 한다.
  • 복호화하기
aws kms decrypt \
    --ciphertext-blob fileb://encrypted.txt \
    --query Plaintext \
    --region eu-west-2\
    --output text | base64 --decode

base64로 암호화된 파일의 이름을 입력해 주고 리전을 지정한다.
암호화된 값에 관한 블롭이 포함됐기 때문에 KMS가 자동으로 설명에 맞는 키를 사용한다.

KMS 다중 리전 키

기본적으로 KMS는 한 리전에 기본 키(Primary Key)가 존재하며, 이를 다른 리전으로 복제 키(Replica Key) 형태로 복제할 수 있습니다.

복제된 키들은 동일한 키 ID와 동일한 키 구성 요소(Key Material)를 가지며, 전역적으로 동일한 키로 인식됩니다.

KMS 다중 리전 키의 동작 원리

  • 다중 리전 키는 한 리전에서 암호화한 데이터를 다른 리전에서 복호화할 수 있도록 한다.
  • 데이터가 다른 리전으로 복제될 때 재암호화(Re-encryption) 과정이 필요하지 않다.
  • 기본 키(Primary Key)의 자동 키 교체(Rotation) 가 활성화되면, 복제 키(Replica Key)도 자동으로 교체된다.
  • 키 정책(Key Policy) 는 각 리전의 키마다 개별적으로 관리된다.
  • 하지만 KMS 다중 리전 키는 완전히 전역(Global)으로 동작하지 않으며, 기본 키가 있고 복제본이 있는 방식으로 관리된다.

다중 리전 키의 사용 사례

✅ 전역 클라이언트 측 암호화(Client-side Encryption)

  • 한 리전에서 데이터를 암호화하고, 다른 리전에서 복호화하는 용도로 활용된다.
  • 클라이언트 측에서 특정 데이터 필드를 암호화하여, 데이터베이스 관리자(DBA) 도 접근할 수 없도록 보호할 수 있다.

✅ DynamoDB 전역 테이블(Global Tables) 암호화

  • DynamoDB 전역 테이블을 사용할 때, 해당 테이블의 데이터는 다른 리전으로 복제된다. 그리고 DynamoDB의 테이블 전체는 클라이언트 측 암호화를 할 수 없지만 특정 속성(Attribute)은 암호화할 수 있다.
  • 예를 들어, 사회 보장 번호(SSN)와 같은 민감한 정보를 암호화하면 DB 관리자도 이를 조회할 수 없도록 설정 가능하다.
  • 한 리전에서 암호화한 후 전역 테이블을 통해 다른 리전으로 복제되어도, 복제된 다중 리전 키를 이용해 그대로 복호화 가능하다.

✅ Amazon Aurora 글로벌 데이터베이스(Global Aurora) 암호화

  • AWS Encryption SDK와 KMS 다중 리전 키를 함께 사용하여 Amazon Aurora의 특정 열(Column)만 암호화할 수 있다.
  • 예를 들어, SSN 열만 암호화된 상태로 저장되면, DB 관리자가 접근하더라도 KMS 키가 없으면 해당 열의 값을 볼 수 없다.
  • 글로벌 데이터베이스 환경에서는 KMS 다중 리전 키를 사용하여 빠르게 복호화할 수 있으며, 지연 시간(Latency)도 줄일 수 있다.

KMS 다중 리전 키의 한계점 및 고려사항

  • AWS 전체에서 단일 키로 동작하지 않음 → 기본 키(Primary Key)와 복제 키(Replica Key)는 독립적인 리전 내에서 관리됨.
  • 각 리전의 KMS 키 정책이 독립적 → 특정 리전에서 키 정책을 변경하더라도, 다른 리전의 키 정책에는 영향을 주지 않음.
  • 일반적인 경우 단일 리전 키 사용을 권장 → 다중 리전 키는 특정 글로벌 워크로드에서만 사용되는 것이 바람직함.

S3 복제와 암호화된 객체의 연관성

S3 복제 시 암호화된 객체의 동작 방식

한 버킷에서 다른 버킷으로 S3복제를 활성화하면

  • 암호화되지 않은 객체와 SSE-S3(Server-Side Encryption with S3-Managed Keys)로 암호화된 객체는 기본적으로 복제됨.
  • 고객 제공 키(SSE-C, Server-Side Encryption with Customer-Provided Keys)로 암호화된 객체도 복제 가능.
  • SSE-KMS(Server-Side Encryption with AWS KMS)로 암호화된 객체는 기본적으로 복제되지 않음.
  • SSE-KMS로 암호화된 객체를 복제하려면 S3 복제 옵션을 활성화해야 하며, 이를 위해 대상 버킷의 KMS 키를 지정해야 함.

SSE-KMS 암호화된 객체 복제 과정

  1. 대상 버킷에서 사용할 KMS 키 지정
    • 복제된 객체가 저장될 때 사용할 KMS 키를 명시해야 함.
  2. 대상 KMS 키에 대한 정책 적용
    • 소스 버킷에서 온 데이터를 암호화할 KMS 키 정책을 설정해야 함.
  3. S3 복제 서비스를 위한 IAM 역할 생성
    • IAM 역할을 통해 소스 버킷의 데이터를 복호화(Decrypt) 한 후, 대상 버킷에서 재암호화(Encrypt) 하도록 설정.

이 과정에서 복호화 및 재암호화가 반복적으로 발생하며, 이로 인해 KMS 요청이 많아질 경우 스로틀링(Throttling) 오류가 발생할 수 있음.
이러한 오류를 방지하려면 AWS 서비스 할당량(Service Quota)을 조정하여 KMS 요청 한도를 늘려야 함.

다중 리전 키(Multi-Region Key, MRK)와 S3 복제의 관계

  • AWS 공식 문서에 따르면, S3 복제에 다중 리전 키를 사용할 수 있음.
  • 하지만 현재 Amazon S3에서는 다중 리전 키를 독립적인 KMS 키처럼 취급함.
  • 즉, 객체는 여전히 복호화된 후 다시 암호화되며, 다중 리전 키를 사용하더라도 동일한 키로 자동 암호화되지 않음.

암호화된 AMI 공유 프로세스

AMI 및 KMS 키 개요

  • A 계정에서 KMS 키로 암호화된 AMI를 소유하고 있음.
  • B 계정에서 해당 AMI를 사용하여 EC2 인스턴스를 시작하려면 AMI 및 KMS 키를 공유해야 함.

AMI 공유 절차

  1. AMI 시작 권한 수정

    • A 계정에서 AMI 속성을 수정하여 B 계정에 시작 권한(Start Permission) 부여.
    • 특정 대상 AWS 계정 ID를 추가하여 공유 설정 완료.

  2. KMS 키 공유

    • B 계정이 AMI를 사용하려면 KMS 키도 공유해야 함.
    • A 계정에서 KMS 키 정책을 수정하여 B 계정이 키를 사용할 수 있도록 설정.

  3. B 계정에서 IAM 역할 또는 사용자 생성

    • B 계정에서 KMS 키 및 AMI 사용 권한이 있는 IAM 역할 또는 사용자 생성.
    • 다음 KMS API 호출 권한이 필요함:
      • DescribeKey (키 설명)
      • ReEncrypt (재암호화)
      • CreateGrant (권한 부여)
      • Decrypt (복호화)

EC2 인스턴스 시작

  • B 계정에서 AMI를 이용해 EC2 인스턴스를 시작할 수 있음.
  • 선택적으로, 대상 계정의 KMS 키를 이용해 볼륨을 재암호화할 수도 있음.

SSM(Systems Manager) Parameter Store

  • 구성(Configuration) 및 암호(Credentials)를 저장하는 보안 스토리지
  • KMS를 이용한 암호화 가능
  • 서버리스, 확장성 및 내구성 보장
  • SDK 지원으로 간편한 사용
  • 구성과 암호의 버전 추적 가능
  • IAM 기반 보안 제공
  • Amazon EventBridge를 통한 알림 기능 지원
  • CloudFormation과 통합 가능
    즉 CloudFormation이 Parameter Store의 매개변수를 스택의 입력 매개변수로 활용할 수 있다

SSM Parameter Store 활용 방식

  • 평문 구성 저장:
    • 애플리케이션이 EC2 인스턴스 역할을 통해 접근
  • 암호화된 구성 저장:
    • KMS를 이용해 암호화 및 복호화 수행
    • 애플리케이션이 KMS 키에 액세스 할 수 있어야 함
  • 계층 구조 지원:
    • 예: /my-department/my-app/dev/db-url
    • /prod/ 경로에 다른 환경 변수 저장 가능
    • IAM 정책을 경로 단위로 설정하여 애플리케이션이 접근 할 수 있는 범위 설정 가능

Secrets Manager 연동 및 AWS 퍼블릭 매개변수 활용

  • Parameter Store에서 Secrets Manager의 암호 접근 가능
  • AWS 퍼블릭 매개변수 활용 가능
    • 예: 특정 리전의 Amazon Linux 2 최신 AMI 조회

표준(Standard) vs 고급(Advanced) 티어

구분표준(Standard)고급(Advanced)
최대 크기4KB8KB
매개변수 정책지원 안 함지원
비용무료월 0.05달러

고급 티어의 매개변수 정책

  • TTL(Time To Live) 정책 적용 가능
    • 민감한 정보(비밀번호 등)의 자동 업데이트 또는 삭제를 강제함
    • 특정 타임스탬프에 매개변수 삭제 가능
  • EventBridge 연동 가능
    • 매개변수 만료 15일 전 알림 수신 가능
    • 20일 동안 변경 없는 경우 알림 제공

SSM 실습

파라미터 스토어

SSM 콘솔 > Application Tools > Parameter store로 이동한다.
파라미터 스토어는 보안 및 구성 데이터를 관리하고 관련된 모든 매개변수를 AWS 계정 내에 중앙 집중화하는 방법이다.

작동 방식

1. 새로운 매개변수를 생성한다.

  • Create parameter를 클릭한다.
  • 원하는 이름으로 파라미터를 생성한다. 예를 들어 파라미터 이름을 계층적으로 /my-app/dev/db-url이라고 설정한다.

2. 매개변수의 유형과 값을 명시한다.

  • 파라미터의 유형을 설정한다. String은 모든 문자열, StringList는 쉼표가 있는 문자열 목록, SecureString은 암호화 된 값으로 데이터베이스 비밀번호와 같은 값을 암호화할 때 사용한다.
  • Value에 매개변수의 값을 넣는다. String일 경우 4096자 이하여야 한다.
    예시로 db의 url인 dev.database.siyun.com:3306 같은 값을 넣을 수 있다.
    SecureString을 선택한 경우 암호화 할 KMS 키 소스를 선택해야 한다.

3. 코드의 명령 내에서 그 매개변수를 참조하면 된다.
SDK나 CLI등으로 매개변수에 접근할 수 있다.

  • CLI 접근 예시 코드
aws ssm get-parameter --name "/my-app/dev/db-password"

일반 String 매개변수에 접근할 수 있다.

  • 암호화된 SecureString의 값을 복호화해서 얻으려면 --with-decryption을 쓰면 된다.
aws ssm get-parameter --name "/my-app/dev/db-password" --with-decryption

애플리케이션이나 접근자가 비밀번호를 보호하는 KMS에 액세스를 못할 경우에는 접근할 수 없다.

  • 특정 경로 내의 모든 파라미터(폴더 제외) 쿼리하기
get-parameters-by-path --path /my-app/dev/
  • 특정 경로 내의 모든 하위 경로를 포함해서 쿼리하기
aws ssm get-parameters-by-path --path "/my-app/" --recursive

Lambda와 SDK를 사용해 SSM 파라미터 액세스하기

1. 람다 함수 생성
런타임은 파이썬 3.~버전

2. Permission 설정
기본 람다 권한을 포함하는 새로운 Role을 생성한다.
람다 함수 생성 후 해당 Role에 아래 내용을 추가하여 수정

{
    "Effect": "Allow",
    "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters",
        "ssm:GetParametersByPath",
      	"kms:Decrypt"
    ],
    "Resource": "arn:aws:ssm:ap-northeast-2:123456789012:parameter/my-app/*"
}

SSM 접근과 암호화된 매개변수를 복호화하기 위한 kms 복호화 권한도 추가해준다.

3. 람다 함수 코드 수정
파이썬이니 boto를 사용해 SDK를 호출할 것임

import boto3

def lambda_handler(event, context):
    ssm = boto3.client("ssm", region_name="ap-northeast-2")

    parameter_names = ["/my-app/dev/db-url", "/my-app/dev/db-password"]
    response = ssm.get_parameters(Names=parameter_names, WithDecryption=True)

    parameters = {param["Name"]: param["Value"] for param in response["Parameters"]}

    return {
        "statusCode": 200,
        "body": parameters
    }

파라미터 경로(이름)을 하드코딩 하지 않고 람다함수의 환경변수에 저장해서 사용하면 더 편리하다.

import boto3
import os # 환경변수를 사용하기 위함

def lambda_handler(event, context):
    ssm = boto3.client("ssm", region_name="ap-northeast-2")

    db_url_param = os.environ["SSM_DB_URL"]
    db_password_param = os.environ["SSM_DB_PASSWORD"]

    response = ssm.get_parameters(Names=[db_url_param, db_password_param], WithDecryption=True)

    parameters = {param["Name"]: param["Value"] for param in response["Parameters"]}

    return {
        "statusCode": 200,
        "body": parameters
    }

AWS Secrets Manager

암호를 저장하고 관리하는 최신 서비스로, SSM Parameter Store와는 다른 서비스이다. 이 서비스는 다음과 같은 기능을 제공한다

  1. 암호 교체 기능
    일정 주기로 암호를 강제로 교체할 수 있어 암호 관리가 효율적이다. 암호 교체를 자동화하려면 새로운 암호를 생성하는 Lambda 함수를 정의해야 한다.

  2. 서비스 통합
    AWS Secrets Manager는 Amazon RDS, MySQL, PostgreSQL, Aurora와 같은 다양한 AWS 서비스와 통합된다. 이를 통해 데이터베이스 접근을 위한 사용자 이름과 비밀번호를 안전하게 저장하고 관리할 수 있다.

  3. KMS 암호화
    암호는 AWS KMS(Key Management Service)를 통해 암호화된다.

  4. 다중 리전 암호 복제
    암호를 여러 AWS 리전에 복제할 수 있다. 기존 리전에서 생성된 기본 암호가 있고, 다른 보조 리전으로 동일한 암호가 복제된다. 이 기능은 재해 복구 전략이나 다중 리전 앱 구축에 유용하다.
    예를 들어, us-east-1에 문제가 발생하면 복제된 암호를 독립 실행형 암호로 승격시켜 사용할 수 있다. 이를 통해 다양한 리전에서 동일한 RDS 데이터베이스에 액세스할 수 있다.

AWS Secrets Manager 실습

요금은 30일 무료 체험판을 사용한 후 암호 당 월0.40달러를 지불하거나 10,000 API 호출 당 0.05달러를 지불한다.
프리 티어만 사용하려면 암호를 생성했다가 지우면 된다.

1. Store a new secret을 눌러 새로운 암호를 생성한다.

암호 유형을 선택한다.

  • RDS를 선택하면 데이터베이스의 사용자 이름과 비밀번호 입력란이 뜬다.
  • 기타 유형을 선택하면 마음대로 Key/value나 json 형식으로 지정해 저장할 수 있다.

2. 암호화 키를 선택한다.
기본 키나 고유한 KMS 키를 선택한다.

3. 암호 이름을 입력한다.
경로 형식으로 예를들어 prod/my-secret 와 같이 입력한다.

4. Resource permissions으로 누가 암호에 액세스할지 제한하는 정책을 설정한다.
S3의 버킷 정책과 비슷하다.

5. 리전 간 암호를 복제하는 옵션도 있다.
복제할 리전과 암호키를 선택할 수 있다.

6. 비밀번호를 자동 교체할지 선택하고 교체 일정을 설정한다.
비밀번호 교체를 활성화하면 교체 함수로 사용할 Lambda 함수도 지정해야 한다.

AWS Certificate Manager(ACM)

AWS Certificate Manager는 TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포할 수 있도록 해주는 서비스이다. TLS/SSL 인증서는 웹사이트에서 전송 중 암호화를 제공하며, HTTPS 프로토콜을 통해 보안을 제공한다. ACM의 주요 기능과 특징은 다음과 같다.

1. TLS 인증서 프로비저닝 및 관리

  • 애플리케이션 로드 밸런서(ALB)를 HTTPS 엔드포인트로서 노출하려면, ALB를 ACM과 통합하고, ACM에서 직접 TLS 인증서를 프로비저닝하고 유지관리하도록 할 수 있다.
  • 이를 통해 사용자는 HTTPS 프로토콜을 사용하는 웹사이트나 API에 안전하게 액세스할 수 있다.

2. 퍼블릭 및 프라이빗 인증서 지원

  • ACM은 퍼블릭과 프라이빗 TLS 인증서를 모두 지원하며, 퍼블릭 인증서는 무료로 제공된다.
  • 인증서는 자동으로 갱신되며, 이를 통해 인증서 관리가 용이해진다.

3. ACM과 다른 AWS 서비스 통합

  • ACM은 Elastic Load Balancer(ELB), CloudFront, API Gateway 등 여러 AWS 서비스와 통합된다.
  • EC2 인스턴스에 대해서는 ACM을 통해 퍼블릭 인증서를 생성할 수 없어 지원되지 않는다.

4. 퍼블릭 인증서 요청 방법

  • 퍼블릭 인증서를 요청하려면 도메인 이름을 나열하고, DNS 검증 또는 이메일 검증을 통해 도메인 소유권을 증명해야 한다.
  • SSL인증서를 자동으로 갱신하려면 DNS 검증을 선택하는 편이 낫다. 그러면 CNAME 레코드를 생성하여 자동으로 소유권을 증명할 수 있다.
  • ACM에서 스스로 생성된 모든 인증서는 만료 60일 전에 자동으로 갱신된다.

5. 외부 인증서 가져오기

  • ACM 외부에서 생성된 인증서를 ACM으로 가져올 수 있다.
  • 하지만, 외부에서 생성된 인증서는 자동 갱신이 불가능하며, 만료되기 전에 새 인증서를 가져와야 한다.

6. 자동 인증서 만료 알림받기

  • 인증서 만료 45일 전부터 EventBridge를 통해 알림을 받을 수 있다.
  • 이를 통해 인증서 만료에 대비할 수 있으며, Lambda, SNS, SQS 등 다양한 서비스와 연동하여 자동 경고를 설정할 수 있다.
  • 또는 AWS Config을 사용하는 방법도 있다. acm-certificate-expiration-check라는 관리형 규칙이 있는데, 만료된 인증서를 확인하는 규칙이며 여기서 일수를 조정할 수도 있다.
  • 즉, Config 서비스에 규칙을 설정하면 Config 서비스가 ACM 서비스를 검사해서 규칙에 위배되는 인증서가 있을 경우 규정 비준수 이벤트가 EventBridge로 전송된다. 그리고 Lambda나 SNS, SQS를 트리거한다.

7. ALB와 ACM 통합

  • ALB는 HTTP에서 HTTPS로 리디렉션하는 규칙을 설정할 수 있다.
  • 사용자가 HTTP로 접속하면 ALB가 HTTPS로 리디렉션하고, ACM에서 발급한 TLS 인증서를 사용한다.
  • 이후 요청은 HTTPS로 ALB를 거쳐 오토 스케일링 그룹으로 전달된다.

8. API Gateway와 ACM 통합

  • API Gateway는 엣지 최적화, 리전, 프라이빗 API Gateway 엔드포인트를 지원하며, ACM 인증서를 API Gateway에 통합할 수 있다.
  • 특히 엣지 최적화 엔드포인트는 CloudFront와 통합되며, 인증서는 반드시 us-east-1 리전에 있어야 한다.(CloudFront가 us-east-1리전에 있기 때문이다) 그리고 Route 53에 CNAME이나 별칭(A-Alias) 레코드를 설정하면 끝이다.
  • 리전 엔드포인트는 같은 리전에 있는 API Gateway와 연결된다. 그리고 Route 53에서 CNAME이나 별칭 레코드가 나의 DNS를 가리키도록 설정하면 된다.

AWS 웹 애플리케이션 방화벽(WAF)

AWS 웹 애플리케이션 방화벽(WAF)은 계층 7에서 일어나는 웹 취약점 공격을 차단하는 서비스이다. 계층 7은 HTTP 프로토콜에 해당하므로, WAF는 주로 HTTP 취약점 공격을 막아준다. 반면, 계층 4는 TCP/UDP 프로토콜로, WAF는 이를 처리하지 않는다.

WAF 배포 위치

WAF는 다양한 AWS 서비스에 배포할 수 있다. 이들 서비스에는 애플리케이션 로드 밸런서(ALB), API Gateway, CloudFront, AppSync GraphQL API, Cognito 사용자 풀이 포함된다. 주의할 점은, ⭐NLB(네트워크 로드 밸런서)에는 WAF를 배포할 수 없다는 것이다.

웹 액세스 제어 목록(Web ACL) 및 규칙 정의

WAF를 배포한 후에는 웹 액세스 제어 목록(ACL)과 규칙을 정의해야 한다. 규칙은 주로 IP 주소나 HTTP 헤더, 본문 등을 기준으로 필터링한다. 예를 들어, IP 세트를 정의하여 최대 10,000개의 IP 주소를 필터링할 수 있으며, 이를 초과할 경우 규칙을 여러 개 두면 된다. 또한, URI 문자열을 조건으로 두어 SQL 주입이나 크로스 사이트 스크립팅(XSS) 같은 공격을 차단할 수 있는 규칙을 설정할 수 있다.

추가적인 필터링 조건

  • 용량 제한: 요청 크기가 최대 2MB를 넘지 않도록 제한할 수 있다.
  • 지역 일치(Geo-match): 특정 국가의 트래픽을 허용하거나 차단할 수 있다.
  • 속도 기반 규칙: IP당 초당 요청 수를 제한하여 DDoS 공격을 방어할 수 있다. 예를 들어, 특정 IP에서 초당 11개 이상의 요청을 보내지 못하게 설정할 수 있다.

웹 ACL의 리전 및 글로벌 정의

웹 ACL은 리전에만 적용되며, CloudFront는 글로벌로 정의된다. 또한, 규칙 그룹을 사용하면 여러 웹 ACL에 추가할 수 있는 재사용 가능한 규칙 모음을 만들 수 있다.

유용한 사용 사례

  • 애플리케이션 고정 IP와 ELB, WAF 사용: NLB는 L4에서만 작동하므로 WAF를 사용할 수 없기에 ALB를 사용한다. 그런데 ALB는 고정 IP가 없다. 대신 AWS Global Accelerator를 활용해 고정 IP를 할당받은 후, ALB에서 WAF를 활성화하면 해결된다.

아키텍처 예시

  • ALB + EC2 + Global Accelerator: ALB와 EC2 인스턴스가 있는 리전에서, Global Accelerator를 ALB 앞에 두고 고정 IP를 할당받는다. 이후 WAF와 웹 ACL을 ALB와 동일한 리전에 배치하면 원하는 아키텍처를 완성할 수 있다.

AWS Shield

디도스(DDoS) 공격으로부터 AWS 인프라를 보호하는 서비스이다. 디도스 공격은 여러 컴퓨터에서 동시에 대량의 트래픽을 보내어 인프라에 과부하를 일으켜 서비스를 방해하는 공격이다. 이 공격의 목적은 서비스의 가용성을 떨어뜨려 실제 사용자들이 서비스를 이용할 수 없게 만드는 것이다.

AWS Shield 서비스 종류

  1. AWS Shield Standard

    • 무료 서비스: 모든 AWS 고객에게 기본적으로 제공되며, SYN/UDP Flood와 반사 공격, L3/L4 공격으로부터 보호한다.
    • 기본 보호: 기본적으로 AWS의 인프라에서 발생하는 대부분의 디도스 공격을 방어할 수 있다.

  2. AWS Shield Advanced

    • 유료 서비스: 조직당 월 3,000달러의 비용이 발생하며, 고급 보호가 필요한 고객을 위한 서비스이다.
    • 정교한 공격 방어: Amazon EC2, ELB, Amazon CloudFront, AWS Global Accelerator, Route 53을 포함한 다양한 AWS 서비스에 대해 고급 디도스 완화 기능을 제공한다.
    • 디도스 대응 팀: AWS 디도스 대응 팀이 상시 대기하며, 공격 발생 시 즉시 지원을 받을 수 있다.
    • 비용 방지: 디도스 공격으로 인한 요금 상승을 방지할 수 있다.
    • 자동 애플리케이션 계층 디도스 완화: 웹 애플리케이션 방화벽(WAF)과 연동하여 L7 계층에서 발생하는 디도스 공격을 자동으로 완화하는 규칙을 생성, 평가, 배포한다. 이는 웹 애플리케이션을 더욱 안전하게 보호할 수 있게 해준다.

AWS Firewall Manager

AWS Firewall Manager는 AWS Organizations에 있는 모든 계정의 방화벽 규칙을 중앙에서 관리할 수 있는 서비스이다. 여러 계정에 걸쳐 보안 정책을 쉽게 적용하고, 이를 자동화하여 관리할 수 있다.

주요 기능:

  1. 보안 정책 설정:
    아래와 같은 규칙들의 집합인 보안 정책을 설정할 수 있다.

    • WAF 규칙: ALB, API Gateway, CloudFront 등에 적용되는 웹 애플리케이션 방화벽(WAF) 규칙.
    • Shield Advanced 규칙: ALB, CLB, NLB, Elastic IP, CloudFront를 위한 AWS Shield Advanced 규칙.
    • 보안 그룹: EC2, ALB, VPC의 ENI 리소스를 위한 보안 그룹 정책.
    • AWS Network Firewall: VPC 수준의 네트워크 방화벽.
    • Route 53 Resolver DNS Firewall: DNS 수준에서의 보호.

  2. 리전 수준 정책 생성:

    • 정책은 리전 수준에서 생성되며, 이를 조직에 등록된 모든 계정에 적용할 수 있다.

  3. 자동 적용:

    • 예를 들어, 조직에서 ALB에 대한 WAF 규칙을 생성하고 새 ALB를 만들면, AWS Firewall Manager가 자동으로 새 ALB에도 동일한 규칙을 적용한다.

WAF, Shield, Firewall Manager 비교

모두 포괄적인 계정 보호를 위한 서비스이다.

  • WAF:

    • 목적: 웹 애플리케이션에 대한 공격을 방어하는 데 사용된다.
    • 기능: 웹 ACL 규칙을 정의하고 리소스별 보호를 구성.
    • 적합: 개별 리소스 보호가 필요한 경우 적합.

  • AWS Shield:

    • 목적: 디도스(DDoS) 공격으로부터 보호.
    • 기능: Shield Standard와 Shield Advanced가 제공하는 디도스 방어 및 고급 기능(자동 규칙 생성, 디도스 대응 팀 지원 등).
    • 적합: 디도스 공격이 자주 발생하는 경우 사용.

  • AWS Firewall Manager:

    • 목적: 여러 계정과 리소스에서 방화벽 규칙을 자동으로 관리하고 적용.
    • 기능: WAF 규칙, Shield Advanced 규칙, 보안 그룹 및 네트워크 방화벽을 포함한 여러 보안 정책을 한 곳에서 관리.
    • 적합: 여러 계정과 리소스를 관리하고 보호 규칙을 자동화하려는 경우.

AWS WAF & Shield 실습

1. 웹 ACL 생성

  • WAF & Shield 콘솔로 가서 새로운 웹 ACL을 생성한다.
  • 리전 리소스인지, 즉 ALB, API Gateway 등의 리소스인지 선택하고, CloudFront 배포인 경우에는 CloudFront용 글로벌(us-east-1에서만 배포됨)로 설정한다.
  • 리전 리소스일 경우 리전을 설정한다.
  • 웹 ACL에 보호할 리소스를 연결하려면 Add AWS resources 버튼을 눌러 ALB나 API Gateway를 선택하여 추가한다.

2. 규칙 추가

  • 웹 ACL은 여러 규칙을 가질 수 있다. 규칙은 관리형 규칙 그룹을 추가하거나 직접 규칙을 생성할 수 있다.
  • 관리형 규칙을 선택하면 AWS나 파트너사가 제공하는 다양한 규칙 그룹을 볼 수 있다. 예시로 봇 제어(Bot Control) 규칙은 봇의 애플리케이션 액세스를 제한하고, Amazon IP 평판 목록은 평판이 좋은 IP만 애플리케이션에 액세스할 수 있게 한다.
    익명 IP 목록을 선택하면 VPN, 프록시 등에서 오는 IP는 차단할 수 있다. 이를 통해 VPN, 프록시 등에서 오는 IP를 차단할 수 있다.
    알려진 불량 입력 규칙을 추가하면 불량한 입력을 차단할 수 있다.

3. 규칙 용량과 기본 설정

  • 각 규칙의 용량을 확인할 수 있으며, 최대 용량은 1,500으로 제한된다. 너무 많은 규칙을 추가할 수 없도록 제한이 있다.
  • 기본적으로 규칙에 위반되는 경우에는 차단되고, 위반되지 않으면 허용된다.
  • 규칙의 우선순위를 설정할 수 있으며, 이를 통해 우선적으로 적용할 규칙을 지정한다.

4. 웹 ACL 생성 및 연결

  • 규칙 우선순위를 설정하고, 관련 지표를 만들어 Create web ACL을 클릭하여 웹 ACL을 생성한다.
  • 생성된 웹 ACL은 ALB나 API Gateway와 연결할 수 있다.

5. IP 세트 관리

  • IP sets에서는 차단하거나 허용할 IP 주소를 세팅할 수 있다. IP 주소는 한 줄에 하나씩 작성하여 설정한다.

6. Firewall Manager 정책 설정

  • 정책을 생성하면 해당 정책은 AWS WAF, Shield Advanced, 보안 그룹, Network Firewall 등에 적용될 수 있다.
  • 예를 들어 WAF 정책을 생성하여 아일랜드 리전의 모든 계정에 적용할 수 있다. 이 정책에서는 규칙 구성과 다양한 설정을 할 수 있다.

DDos 보호와 모범 사례

DDoS 공격에 대한 보호를 설정하고 모범 사례를 적용하는 방법을 알아보자.

1. 아키텍처 구성

  • EC2 인스턴스로 구성된 오토 스케일링 그룹과 엘라스틱 로드 밸런서(ELB)가 앞단에 위치한다.
  • 로드 밸런서는 Global Accelerator를 통해 고정 IP로 노출하거나 CloudFront를 앞단에 두어 WAF와 연결할 수 있다.
  • DNS 라우팅은 Route 53을 통해 관리할 수 있다.

2. Global Accelerator & CloudFront

  • Global Accelerator는 전 세계에서 엣지를 통해 애플리케이션에 접근하게 한다. Shield와 완전히 통합되어 DDoS 공격 방어가 가능하다.
  • CloudFront는 웹 애플리케이션 전송을 엣지 로케이션에서 처리하며, Shield 설정으로 DDoS 공격을 막는다.
  • Route 53을 사용하여 엣지에 도메인 이름 변환을 글로벌로 설정하면 DNS에 대한 DDoS 보호를 추가할 수 있다.

3. DDoS 완화 모범 사례

1) 인프라 계층 방어
  • CloudFront, Global Accelerator, Route 53, 엘라스틱 로드 밸런싱을 사용하여 높은 트래픽으로부터 EC2 인스턴스를 보호한다.
  • 이 서비스들은 트래픽이 EC2에 도달하기 전에 먼저 관리되므로, EC2 인스턴스의 부담을 줄일 수 있다.
  • 오토 스케일링을 활성화하면 EC2 인스턴스에서 트래픽을 처리하는 능력을 자동으로 확장할 수 있다.
2) 애플리케이션 계층 방어
  • CloudFront는 정적 콘텐츠를 엣지 로케이션에서 처리해 백엔드를 보호한다.
  • 애플리케이션 로드 밸런서(ALB)와 CloudFront에 WAF를 사용하여 요청을 필터링하고, 특정 IP나 요청 유형을 차단할 수 있다.
  • WAF의 속도 기반 규칙을 활용해 악성 사용자의 IP를 자동으로 차단할 수 있다.
  • 관리형 규칙을 사용해 IP 평판이나 익명 IP를 차단할 수 있다.
  • CloudFront와 WAF는 관리형 서비스로 자동으로 요청을 필터링하여 DDoS 공격을 완화한다.
3) Shield Advanced 활용
  • Shield Advanced를 활성화하면 WAF 규칙이 자동으로 생성되어 계층 7 공격을 완화한다. 이는 애플리케이션 계층 방어에 매우 유용하다.

4. 공격 지점 줄이기

1) 백엔드 리소스 숨기기

  • CloudFront, API Gateway, 엘라스틱 로드 밸런서(ELB)를 사용하면 백엔드 리소스를 숨길 수 있다. 공격자는 백엔드가 Lambda 함수인지, EC2 인스턴스인지 알 수 없다.
  • 보안 그룹과 네트워크 ACL을 설정하여 특정 IP의 트래픽을 필터링할 수 있다.
  • Elastic IP는 AWS Shield Advanced로 보호 가능하다.

2) API 엔드포인트 보호

  • API Gateway를 사용하면 백엔드를 숨길 수 있다. API Gateway는 어떤 백엔드가 사용하는지 알 수 없도록 보호한다.
  • API Gateway의 WAF를 사용하면 모든 HTTP 요청을 필터링할 수 있다.
  • API Gateway에서는 버스트 제한과 헤더 필터링을 설정하여 DDoS 공격을 방어할 수 있다. 또한, API 키 사용을 강제하여 보안을 강화할 수 있다.

GuardDuty

GuardDuty는 AWS 계정을 보호하기 위한 지능형 위협 탐지 서비스로, 머신러닝 알고리즘을 사용하여 이상 탐지와 서드파티 데이터를 활용한 위협 탐지를 제공한다.

1. GuardDuty 활성화

  • 클릭 한 번으로 GuardDuty를 활성화하면 30일 무료 체험을 시작할 수 있다.
  • 별도로 소프트웨어를 설치할 필요 없이 자동으로 설정된다.

2. GuardDuty가 사용하는 입력 데이터

GuardDuty는 여러 데이터를 확인하여 비정상적인 활동을 탐지한다.

  • CloudTrail Event Logs: 비정상적인 API 호출이나 무단 배포를 검색한다.
  • VPC Flow Logs: 비정상적인 인터넷 트래픽과 IP 주소를 탐지한다.
  • S3 데이터 이벤트: GetObject, ListObject, DeleteObject 등의 요청을 확인한다.
  • DNS 로그: 인코딩된 데이터를 전송하는 EC2 인스턴스를 검색하여 문제가 있는지 확인한다.

3. 추가적인 입력 데이터

  • EKS 감사 로그, RDS 및 Aurora 로그인 이벤트, EBS, Lambda 등도 옵션 기능으로 검색할 수 있다.

4. EventBridge와 자동화

  • EventBridge 규칙을 설정하여 GuardDuty에서 탐지한 위협에 대해 자동으로 알림을 받을 수 있다.
  • EventBridge는 Lambda 함수나 SNS 알림 등을 자동화할 수 있다.

5. 암호화폐 공격 방어

  • GuardDuty는 암호화폐 공격을 방어하기 위한 전문적인 탐지 기능을 제공하며, 이를 통해 암호화폐 공격이 있는지 확인할 수 있다.

Amazon Inspector

Amazon Inspector는 보안 평가를 자동화하여 EC2 인스턴스, Amazon ECR의 컨테이너 이미지, Lambda 함수에서 보안 취약점을 점검하는 서비스이다.

1. 지원되는 인프라

  • EC2 인스턴스: 시스템 관리자 에이전트를 사용하여 EC2 인스턴스의 보안을 평가한다. 이는 의도되지 않은 네트워크 접근 가능성과 운영 체제의 알려진 취약점을 분석한다.
  • Amazon ECR (Elastic Container Registry): 도커 이미지 같은 컨테이너 이미지가 Amazon ECR로 푸시될 때, Amazon Inspector는 이미지 내의 알려진 취약점을 검사한다.
  • Lambda 함수: Lambda 함수가 배포될 때, 함수 코드와 패키지 종속성에서 소프트웨어 취약성을 분석한다.

2. 자동화된 보안 평가

  • Amazon Inspector는 연속적인 보안 평가를 수행하며, 새로운 취약점이 CVE (Common Vulnerabilities and Exposures) 데이터베이스에 업데이트될 때마다 자동으로 다시 실행된다.
  • 우선 순위를 정하기 위해 각 취약점에는 위험 점수가 할당된다.

3. 결과 보고 및 자동화

  • Amazon Inspector는 보안 평가가 완료되면 AWS 보안 허브에 결과를 보고한다.
  • 또한, 평가 결과는 Amazon EventBridge로 전달되어, 자동화된 알림 및 인프라의 취약점 관리를 할 수 있다.

4. 평가 항목

  • CVE 데이터베이스를 참조하여 EC2, ECR, Lambda에서 패키지의 취약성 및 EC2 인스턴스의 네트워크 도달성을 평가한다.

Amazon Macie

완전 관리형 데이터 보안 및 개인정보 보호 서비스이다. 이 서비스는 머신러닝과 패턴 매칭 기술을 활용하여, AWS에 있는 민감한 데이터를 자동으로 발견하고 보호한다. 특히 PII (Personally Identifiable Information)와 같은 개인 식별 정보를 탐지하고 경고를 제공한다.

Macie의 주요 기능

  1. PII 자동 탐지: Macie는 AWS S3 버킷에 저장된 민감한 데이터를 분석하여 PII로 분류할 수 있는지 알아낸다. 이를 통해 데이터를 실시간으로 모니터링하고 보호할 수 있다.

  2. 자동화된 경고: 민감한 정보가 발견되면, Macie는 EventBridge를 통해 결과를 알리고, 이를 SNS 토픽이나 Lambda 함수와 통합하여 자동화된 알림이나 후속 조치를 취할 수 있다.

  3. 간단한 설정: Macie는 클릭 한 번으로 활성화할 수 있다. 사용자는 분석할 S3 버킷을 지정하기만 하면 된다.

  4. 민감 정보 보호: Macie는 민감한 데이터가 저장된 위치를 식별하고, 이를 보호하는 방법을 자동으로 제공한다.

profile
Siyun
공부 기록
이전 포스트

AWS IAM 고급

다음 포스트

AWS 네트워크

0개의 댓글