Notice
Recent Posts
Recent Comments
Link
«   2025/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
Archives
Today
Total
관리 메뉴

벌꿀오소리가 되고싶은

AWS Certified Developer - Associate 정리 - KMS 본문

개발/AWS

AWS Certified Developer - Associate 정리 - KMS

허니배져 2023. 9. 24. 14:56

개요

  • 데이터는 클라이언트로(사용자의 서버)부터 암호화되고 절대로 AWS 서버에서 복호화되지 않는다
  • CloudTrail을 이용해서 키를 사용하는 모든 API 호출을 검사할 수 있음키 종류
    • 키 개요
      • Symmetric(AES-256): 대칭키. 암호화 복호화하는 데에 하나의 키만 이용함. KMS와 통합된 모든 서비스는 대칭키를 사용. KMS 대칭키를 사용하면 키 자체에 액세스 할 수 없게 됨. AWS API를 호출해야만 사용 가능.
      • Asymmetric(RSA & ECC Key pairs): 비대칭키. 데이터 암호화에 사용하는 공개키, 복호화에 사용하는 개인키가 있음. 공개키는 다운로드 가능하지만 개인키에는 엑세스할 수 없음. API를 이용해야함. KMS키에 액세스 할 수 없거나 권한이 없는 사용자가 클라우드 외부에서 암호화를 수행하려는 경우에 사용. 공개키를 사용하여 데이터를 암호화하여 사용자에게 전송하면 사용자는 개인키로 복호화하여 사용.
    • 키 종류
      • AWS 소유 키
        • 무료, SSE-S3, SSE-SQS, SSE-DDB(default)
      • AWS 관리 키 Managed Key
        • 무료, aws/rds, aws/ebs 이런 형태
        • 할당된 서비스 내에서만 사용 가능
        • 1년마다 자동으로 키 교체
      • 고객관리형키(CMK), 사용자 지정키
        • 월 1달러 비용
        • 고객관리형키: 1년마다 키 자동 교체 활성화 해야함(안 되어 있음)
        • 사용자 지정키: 수동교체만 가능, 별칭 사용해야함
        • SSE-C: HTTPS를 사용하지 않는 경우 요청이 거부되는 암호화 메커니즘
        • 고객 제공 암호화 키(SSE-C)로 서버 측 암호화를 사용하면 암호화 키를 설정할 수 있습니다.
    • SSE-S3 vs SSE-KMS vs SSE-C
      • SSE-S3
        • 완전한 aws 관리 키. 완전히 S3가 소유하고 관리함
        • AES-256
        • 서버에서 암호화하도록 만들기 위해서는 헤더에 "**x-amz-server-side-encryption": "AES256"**
        • 암호화하지 않은 파일을 버킷에 못올리게 하려면 버킷 설정을 해줄 수 있다
      • SSE-KMS
        • 미리 KMS 설정해놓은 CMK로 암호화함
        • SSE-S3보다 조금 더 사용자 단위의 컨트롤 가능
        • 헤더에 "**x-amz-server-side-encryption": "aws:kms"**
      • SSE-C
        • 키를 외부에서 사용자가 관리함
        • AWS는 고객의 키를 저장하지 않고, 사용 후 바로 폐기함
        • 키를 같이 전송해야하기 때문에 반드시 HTTPS를 사용해야함
        • x-amz-server-side-encryption-customer-algorithm
        • x-amz-server-side-encryption-customer-key
        • x-amz-server-side-encryption-customer-key-MD5
    • KMS는 리전별로 범위가 지정됨. 동일한 KMS키는 두 리전에 존재할 수 없음
    • ex)한 리전에서 암호화된 EBS는 복제되면 동일하게 암호화된 상태임. 이 ebs를 다른 리전으로 옮기면 그 리전에서 새로운 키를 만들어서 암호화해줘야함

KMS 키 정책

  • 키에 대한 KMS키 정책이 없으면 아무도 해당 키에 접근할 수 없음(마치 S3처럼)
  • 기본키정책
    • 기본적으로 계정의 모든 사람(서비스는 아님!!)이 이 키에 액세스 할수 있도록 허용
  • 커스텀정책
    • KMS키에 엑세스 할 수 있는 사용자, 역할을 정의하고 키를 관리할 수 있는 사람을 정의할 수 있음
    • 다른 계정에 KMS 키를 접근할 수 있는 권한을 부여하는 교차 사용을 가능하게 함
    • 교차사용 사례
    •  

봉투암호화

  • KMS 암호화 API는 사용할 때 암호화할 데이터 크기 제한이 4kb임
  • 4kb보다 더 큰 데이터를 암호화하려면 봉투암호화를 해야함
  • 관련 api: GenerateDataKey

 

시험에 나올만한 API

  • Encrypt: 4kb 이하의 데이터 암호화 할 때
  • Decrypt: 4kb 이하의 데이터를 복호화 할 때
  • GenerateDataKey: 대칭키(symentic) DEK 생성. 데이터키 평문과 암호화된 데이터키 보내줌
  • GenerateDataKeyWithoutPlainText: 바로 암호화를 실행할 필요가 없을 때 일단 암호화된 DEK만 전달받고, 나중에 실제로 암호화를 실행해야 할 때 KMS로부터 평문 DEK를 얻고 암호화를 실행함. 즉각적으로 암호화를 해야하는 경우가 시험에 나오면 GenerateDataKeyWithoutPlainText는 답이 아님
  • GenerateRandomNumber: 무작위 숫자 생성

할당량을 초과했을 때

  • KMS의 모든 API 호출은 할당량을 공유함. 암호화, 복호화, randomNumber도 마찬가지. 계정간, 리전간 모두 다 공유.
  • 기본적으로 리전마다 초당 호출 할당량 기본값이 다름
  • 초과했을 때 대처
    • 지수백오프 전략을 사용
    • DEK 캐시 사용
    • 할당량을 늘리는 api를 호출
    • 고객센터에 문의

S3 bucket key(SSE-KMS)

  • CMK를 이용해 S3 bucket key를 만들 수 있음
  • 이걸 이용하면 KMS API 호출을 줄일 수 있어서 비용을 절감할 수 있고 보안도 지킬 수 있음
  • S3 bucket key는 주기적으로 순환됨
  • KMS 관련 CloudTrail 이벤트도 줄어들게 됨
  • 추가지식
    • SSE-KMS에서는 AWS가 데이터 키를 관리, AWS KMS에서 고객 마스터 키(CMK) 관리
      • 표준 기능을 사용하여 데이터를 암호화하도록 선택한 경우 프로세스
        1. Amazon S3는 일반 텍스트 데이터 키와 지정된 CMK로 암호화된 키 사본을 요청합니다.
        2. AWS KMS는 데이터 키를 생성하고 CMK에서 암호화한 다음 일반 텍스트 데이터 키와 암호화된 데이터 키를 모두 Amazon S3로 보냅니다.
        3. Amazon S3는 데이터 키를 사용하여 데이터를 암호화하고 사용 후 최대한 빨리 메모리에서 일반 텍스트 키를 제거합니다.
        4. Amazon S3는 암호화된 데이터 키를 암호화된 데이터와 함께 메타데이터로 저장합니다.

키정책

  • KMS 키에 접근할 수 있는 사람을 정의할 때 사용
  • 페더레이션 사용자: 외부에서 인증된 사용자 (자격증명 내 조직 또는 서드파티 자격증명 공급자에서 페더레이션 사용자의 권한을 IAM 역할을 사용하여 지정할 수 있다.)
  • aws service: 해당 서비스가 여러분의 KMS키를 사용할 수 있다 → 즉 주체가 바뀜

CloudHSM

  • 키 저장소를 KMS를 사용 안 하고 고객이 직접 관리
  • 키 저장소 하드웨어는 AWS에서 제공(HSM)
  • 멀티 AZ에 저장되어 고가용성
  • KMS는 외부의 비대칭키를 가져올 수 없음. 만약 고객의 온프레미스 서버가 키저장소 역할을 한다면 CloudHSM은 가져올 수 있음

SSM Parameter Store

  • 구성값과 변수를 암호화해서 관리하고 싶을 때
  • 버전관리 가능
  • 계층구조로 관리
  • CloudFormation과 호환이 잘 됨
  • 앱에서 구성값을 SSM에서 가져오려면 앱이 KMS에 있는 key에 대한 접근권한을 가지고 있어야함
  • 고급 파라미터 정책을 사용하면 파라미터의 TTL을 지정할 수 있음 EventBridge와 연결하면 만료 며칠 전에 알림을 받거나 자동으로 갱신하는 등 연계할 수 잇음
  • 앱에서 SSM에 든 값을 가져다 쓸 때, SSM read 권한만 있어도 읽을 수 있지만 여기서 가져온 값이 암호화 되어 있고 이것을 복호화해서 써야한다면 이 값을 암호화하는 데 쓰인 key에 대한 접근권한도 있어야함
  • 언제 누가 어떻게 무엇을 했는지 알기 위해서는 ___를 사용할 수 있다

Secret Manager

  • 주로 암호를 저장하는 데에 사용
  • 주기적으로 키를 변경하고 자동생성할 수 있음
  • 자동생성 할 때는 주로 람다와 통합해서 사용
  • RDS의 암호와 동기화해서 주기적으로 변경할 수 있음
  • RDS 와 통합, 순환이 나오면 이거다!
  • cloudformation과 통합
    • 변수값 true로 주면 rds가 생성되면서 secret manager에 아이디 비번 저장함
    • 이렇게 안 하면 cloudformation에 secretmanager resource를 직접 만드는 방법도 있음
Comments