섹션 26: AWS 보안 및 암호화 KMS, SSM Parameter Store, CloudHSM, Shield, WAF

암호화 101

• 전송 중 암호화
  • 매우 민감한 기밀 내용인 경우 전송 중 암호화를 사용
    • 예시) 신용카드로 온라인 결제
  • HTTPS 웹사이트라면 전송 중 암호화가 되는 것
    • 서버가 데이터를 받으면 복호화를 함
  • 전송하는 사람과 서버만이 암호화와 복호화를 하는 방법을 알고 있음
  • SSL 암호화와 복호화는 모든 라이브러리가 이 작업을 해주기 때문에 직접 처리 할 필요가 없었던 것
• 서버 측 저장 데이터 암호화
  • 데이터가 서버에 수신 된 후 암호화 하는 것
    • 그래서 그 전에는 서버가 데이터를 받아서 복호화를 하고, 암호 복호화된 형식에 사용
  • 서버는 데이터를 디스크에 저장한다.
    • 그래서 서버가 데이터를 암호화된 형태로 저장 함
  • 서버가 해킹당해도 데이터를 지킬수있음
  • 클라이언트로 다시 전송되기 전에 복호화를 한다.
  • 데이터 키라고 불리는 키 덕분에 암호화 된 형태로 저장
  • 암호 키와 해독 키는 주로 KMS에 저장 된다.
    • 서버는 KMS와 통신이 되어야한다.
  • 예시) EBS 볼륨에서 데이터 받아서 암호화 클라이언트에게 보낼때 복호화
• 클라이언트 측 암호화
  • 데이터를 클라이언트가 암호화 함
  • 서버는 그 데이터를 절대 복호화 할 수 없음
  • 데이터를 받는 클라이언트에 의해 복호화 됨
    • 즉 서버는 데이터를 저장 하지만 복호화를 못한다는 것
  • 이를 위해 봉투 암호화를 활용 할 수 있다.

---

KMS 개요

• AWS 서비스에서 암호화는 거의 KMS 암호화를 이야기 하는 것
• KMS는 승인에 관해 IAM과 통합되어 있음
  • KMS로 되어있으면 쉽게 제어를 할 수 있음
• 강점
  • CloudTrail을 통해 키를 사용하기 위해 이루어진 모든 API 호출을 감사 할 수 있다.
• 비밀 데이터가 있으면 평문 텍스트에 절대로 저장하면 안된다
  • 특히 코드 안에 두면 안된다.
• AWS CLI나 SDK를 사용해서 API 호출을 통해서 사용 가능
  • 모든 비밀을 KMS 키로 암호화 할 수 있음
  • 그걸로 코드나 환경 변수에 저장 할 수 있음
• KMS 키
  • 대칭 KMS 키
    • 데이터를 암호화, 복호화 하는데 한개의 키로 함
    • 대부분 서비스가 대칭 키를 사용
  • 비대칭 KMS 키
    • 키가 2개가 있음 암호화(퍼블릭 키), 복호화(프라이빗 키)
    • 퍼블릭 키를 다운로드 할 수 있지만
    • 복호화 키는 액세스가 불가능하고 API 호출로만 사용 가능
    • 1. 데이터를 퍼블릭 키를 사용해서 암호화
    • 2. 프라이빗 키로 데이터를 복호화
• 다양한 타입의 키
  • SSE-S3, SSE DynamoDB 타입
    • S3, DynamoDB 서비스 사용시 쓰는 키
  • AWS 관리형 키
    • 앞에 aws/가 있고 서비스 이름이 나온다.
    • 키가 지정된 서비스 안에서만 사용 가능
  • 고객 관리형 키
    • 한달에 1달러를 지불 해야하는 키
• 자동 키 순환
  • 자동으로 1년 마다 순환이 된다.
  • 임포트한 KMS 키면 수작업으로 순환 해야한다.
• 범위
  • KMS 키의 범위는 리전이다.
  • 다른 리전에 복사하기 위한 단계 예시) EBS 볼륨
    • 1. EBS 볼륨의 스냅샷을 찍는다.
    • 2. 스냅샷 자체도 동일한 KMS키로 암호화 됨
    • 3. 다른 KMS 키를 사용해서 그 스냅샷을 다시 암호화
    • 다시 암호화 하는건 AWS가 해준다.
  • 동일한 KMS 키가 두 리전에 있을 수 없음
• KMS 키 정책
  • KMS 키에 대한 액세스를 관리하기 위한 정책
  • 기본 정책
    • 특정한 커스텀 KMS 키 정책을 제공하지 않을 때 생성 됨
    • 기본값은 계정에 있는 모든 사람이 키에 액세스에 가능하다.
  • 커스텀 KMS 키 정책
    • 사용자와 역할을 정의해서 키를 누가 관리하는지 정의 할 수 있음
    • 교차 계정 액세스를 할려는 경우 유용함
    • 다른 계정이 우리의 KMS 키를 사용하도록 승인이 가능하기 때문

---

KMS - Mutil-Region Keys

• KMS에는 다중 리전 키를 둘 수 있음
• 선택 된 한 리전에 기본키를 갖고
  • 다른 리전에 복제를 하는 방식임
  • 키 ID가 완전히 똑같음
• 한 리전에서 암호화하고 다른 리전에서 복호화가 가능
• 다중 리전키의 핵심
  • 한 리전에서 암호화
  • 다른 리전에서 복호화
  • 다음 리전으로 복제, 교차 리전 API시 데이터를 재 암호화 하지 않아도 됨
• 전역(글로벌)로 사용 할 수 없음
  • 키본 키의 복제본이 있는 것임
• 다중 리전 키 사용은 권장하지 않음
• 사용 사례
  • 전역 클라이언트 측 암호화가 있는데
  • 한 리전에서 암호화 하고
  • 다른 리전에서 복호화 한다.
  • DyanmoDB Global
  • Aurora Global
• 왜 클라이언트 측 암호화하는지?
  • 중요한 건 전체 테이블만 암호화 하는게 아니라는 것
  • 저장 데이터 암호화 이므로 테이블의 속성을 암호화해서
  • 특정 클라이언트만 사용 할 수 있게 된다.
• 전역 테이블 덕분에 데이터뿐만 아니라 암호화 키도 함께 복제가 가능
• 데이터베이스에 액세스 할 수 있는 DB 관리자가
  • 암호화된 열에 액세스 할 때 KMS 키 액세스 권한이 없으면
  • 데이터를 읽을 수 없다.

---

S3 암호화된 복제

• 한 버킷에서 다른 버킷으로 S3 복제를 활성화 하면
• 암호화 되지 않은 객체와 SSE-S3로 암호화된 객체가 기본으로 복제 된다.
• 고객 제공 키인 SSE-C로 암호화한 객체도 복제가 가능
• SSE-KMS로 암호화된 객체도 있음
  • 기본적으로 복제 안됨, 옵션 활성화를 해야함
  • 어떤 KMS 키로 어떤 객체를 암호화 할 지 지정 필요
  • 1. KMS 키 정책을 대상 키에 적용
  • 2. S3 복제 서비스를 허용하는 IAM 역할 생성 필요
  • 3. 소스 버킷의 데이터를 먼저 복호화 하고
  • 4. 대상 KMS키로 대상 버킷을 다시 암호화 한다.

---

암호화된 AMI 공유 프로세스

• AMI를 다른 계정과 공유하는 과정에 관함
  • AMI가 KMS 키로 암호화가 되어있고
  • AMI는 소스 계정에 있고 KMS 키로 암호화 된 것
  • 어떻게 A계정의 AMI를 B계정의 EC2 인스턴스로 시작을 하는가?
    • 1. 시작 권한으로 AMI 속성 수정
      • B계정에서 AMI를 시작하도록 허용
    • 2. B계정에서 사용하게 KMS 키 공유 필요
      • 일반적으로 키 정책으로 실행됨
    • 3. B계정에서 KMS키와 AMI를 모두 사용하는 권한이나 역할을 가진 사용자 생성
    • 4. B계정에서 EC2 인스턴스 시작

---

SSM 매개변수 저장소 개요

• 구성 및 암호를 위한 보안 스토리지
• 구성을 암호화 할지 선택 할 수 있다.
  • KMS 서비스를 이용해 암호를 만들 수 있다.
• 서버 리스 (확장성, 내구성)이 있음
• SDK 사용에도 좋다.
• 매개변수 업데이트 할 시 구성과 암호의 버전 추적 가능
• IAM을 통해 보안 제공
• EventBridge로 알람 받기 가능
• CloudFormation과 통합 가능
• 계층 구조로 매개변수를 저장 할 수 있음
  • 예시)
    • my-app
      • dev
      • prod
    • 사용시) my-app/dev/db-password
• 고급 매개변수
  • TTL
    • 만료 기한을 추가 가능
    • 업데이트나 삭제하도록 강제한다.
  • 한번에 여러 정책을 할당할 수도 있음

---

AWS Secrets Manager - 개요

• 암호를 저장하는 최신 서비스
• SSM과 다른 서비스 임
• X일마다 강제로 암호를 교체하는 기능이 있음
• 교체할 암호를 강제 생성 및 자동화 가능
  • Lambda 함수를 정의해서 새 암호를 만들 수 있다.
• Amazon RDS MySQL PostgreSQL Aurora 등 통합이 가능
  • 데이터베이스에 접근하기 위한 사용자 이름과 비밀번호 저장, 교체가 가능하다.
  • 암호는 KMS 서비스를 통해 암호화 됨
• 다중 리전 암호
  • 복수 AWS 리전에 암호를 복제 할 수 있음
  • 기본 암호와 동기화된 읽기 전용 복제본을 유지 하는 것
  • 기본키가 있는 리전에 문제가 생기면 다른 리전의 암호 복제본을 독립 실행형 암호로 승격이 가능

---

AWS Certificate Manager (ACM)

• TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포하게 해주는 서비스
• 예시
  • 1. ALB과 ACM을 통합
  • 2. ALB에서 직접 TLS 인증서를 프로비저닝, 유지관리
  • 3. 사용자가 HTTPS 프로토콜로 액세스 가능
• ACM은 퍼블릭, 프라이빗 TLS 인증서 모두 지원
• 인증서를 자동으로 갱신하는 기능도 있음
• 여러 AWS 서비스와 통합 되어 있음
  • ELB
  • ALB
  • NLB
  • CloudFront
  • API Gateway
• ACM을 사용할 수 없는 곳이 하나 있는데 EC2 인스턴스임
  • 퍼블릭 인증서일 때 추출이 안됨
  • ACM을 통해 EC2 인스턴스 퍼블릭 인증서 생성 할 수 없다는 것
• Route 53
  • ACM에서 CNAME을 주면은 레코드 생성해서 도메인 소유권 증명을 하면 ACM에서 인증서를 발행해준다.
• 퍼블릭 인증서는 어떻게 가져오나요?
  • 1. ACM 외부에서 생성된 인증서 (자동갱신 불가능)
  • 2. ACM에서 생성
• 인증서가 어떻게 만료되는지 아나요?
  • EventBridge에 만료 45일 전부터 이벤트를 전송함
  • AWS Config을 사용하면
    • 관리형 규칙을 사용해서 ACM 서비스 검사
    • 규칙에 위배된 인증서가 있을 때 EventBridge로 전송

웹 애플리케이션 방화벽

• 계층7(어플리케이션) 에서 일어나는 일반적인 웹 취약점 공격을 보호
  • 계층7은 HTTP
  • 계층4는 TCP/UDP 프로토콜
• ALB, API Gateway, CloudFront에서 사용이 가능
• 웹 액세스 제어 목록(ACL)과 규칙
  • SQL 주입, XSS 등 일반적인 공격 차단도 가능
  • IP세트 정의 가능
  • 헤더와 본문 필터링 가능
  • 용량에 제약 걸기 가능
  • 지역 일치 조건
  • 속도 기반 규칙으로 디도스 공격 방지
  • 리전에만 적용됨, CloudFront는 글로벌로 정의
• 규칙 그룹
  • 여러 웹 ACL에 추가 할 수 있는 재사용 가능한 규칙 모음
• 예시)
  • 애플리케이션에 고정 IP를 사용하며, 로드밸런서와 WAF 사용 시
  • WAF는 NLB(네트워크 로드 밸런서)지원을 안한다.
    • WAF는 7계층(HTTP)만 되기때문
    • NLB는 4계층(TCP/UDP)임
  • 1. 애플리케이션 로드 밸런서 고정 IP 할당
    • AWS Global Accelerator로 고정 IP 할당 받음
  • 2. ALB에서 WAF 활성화

---

실드 - DDoS 보호

• 디도스 공격으로 스스로를 보호하기 위한 서비스
• 스탠다드 서비스
  • AWS 고객에에게 무료로 활성화
  • SYN/UDP Floods, 반사 공격
  • L3/L4 공격으로 보호 해줌
• 어드밴스드 서비스
  • 조직당 월 3,000달러 지불 필요
  • 더욱 정교한 디도스 공격을 막아준다.
  • EC2, CloudFront, Global Accelerator, Route 53 보호
  • 디도스 대응 팀이 항시 대기 중
  • 자동으로 WAF 규칙을 생성, 평가 배포하여 L7 공격 완화 해줌

---

Firewall Manager

• AWS 조직(Organizations)에 있는 모든 계정의 방화벽 규칙을 관리하는 서비스
• 여러 계정의 규칙을 동시에 관리 할 수 있음
• 보안 규칙의 집합인 보안 정책
  • ALB, API Gateway, CloudFront 등에 적용되는 WAF 규칙
  • ALB , CLB, NLB, Elastic IP, CloudFront를 위한 AWS Shield 규칙 등이 포함
• 모든 방화벽을 한 곳에서 관리할 수 있다.
  • 정책은 리전 수준에서 생성
  • 조직에 등록된 모든 계정에 적용 됨
• 예시)
  • 새 ALB(애플리케이션 로드 밸런서)를 생성하면 자동으로 같은 규칙을 적용 해줌
• WAF, Firewall Manager, Shield 차이점
  • WAF
    • 리소스별 보호를 구성하는데 적절
  • Firewal Manager
    • 여러 계정에서 WAF를 사용 할 때 WAF 구성을 가속하고 새 리소스 보호 자동화때 적절
    • 모든 계정에 Shield 어드밴스드 배포에 도움 줌
  • Shield
    • 디도스를 받을 때 적절
    • WAF 규칙 자동 생성 할 수 있음

---

Amazon GuardDuty

• 지능형 위협 탐지를 이용해서 AWS 계정 보호
• CloudTrail, Event Logs 같은 입력 데이터를 확인해서 비정상적인 API 호출, 무단 배포를 검색하는 것
• EventBridge 규칙으로 자동으로 알림 받기 가능
• 암호화폐 공격을 방어하기 아주 좋은 도구

---

Amazon Inspector

• 몇 군데 자동화된 보안 평가를 실행하는 서비스
• 취약점을 분석을 하는 것
• 예시)
  • Lambda 소프트웨어 취약점 분석
  • 컨테이너 이미지 ECR로 푸시되면 취약점 분석
  • EC2 보안 평가
• 필요한 인프라만 지속적으로 스캔

---

Amazon Macie

• 데이터 보안 및 데이터 프라이버시 서비스, 머신러닝과 패턴 매칭으로 민감한 데이터를 발견하고 보호 한다.
• S3에 주민등록번호 있으면 Macie로 분석하고 Event Bridge로 결과를 알려주는것