암호화

전송중 암호화 (SSL)
전송 중 암호화는 데이터가 전송되기 전 암호화되고 서버가 데이터를 받으면 복호화한다.
SSL 인증서가 암호화를 해주고 다른 방법은 HTTPS가 있다.
Amazon 서비스를 다룰 때마다 HTTPS 엔드포인트가 있어서 전송 중 암호화가 됐음을 보장한다.
기본적으로 전송 중 암호화를 활성화하면 '중간자' 공격으로부터 보호된다.

서버 측 저장 데이터 암호화

데이터가 서버에 수신된 후 암호화하는 것
서버가 데이터를 암호화된 형태로 저장하고 있다는 점이 중요하다.
데이터는 클라이언트로 다시 전송되기 전에 복호화된다.
즉, 데이터 키라고 불리는 키 덕분에 데이터는 암호화된 형태로 저장되고 암호 키와 해독 키는 주로 KMS(Key Management Service) 같은 곳에 따로 관리된다.
따라서 서버는 KMS와 통신할 수 있어야 한다.

클라이언트 측 암호화

클라이언트 측 암호화에서 데이터는 클라이언트가 암호화하고 여기서 클라이언트는 우리고 서버는 그 데이터를 절대 복호화할 수 없고 데이터를 받는 클라이언트에 의해 복호화된다.
전체적으로 데이터는 서버에 저장되지만 서버는 데이터의 내용을 알 수 없다.
서버는 데이터를 복호화할 수 없어야 한다.
봉투 암호화의 간단한 예시
여기 객체가 있고 클라이언트는 데이터 키를 사용해서 클라이언트 측의 데이터를 암호화한다.
이제 해당 데이터를 원하는 데이터 저장소로 보낸다.
FTP가 될 수도 있고 S3도 될 수 있고 무엇이든 상관 없다.
그리고 데이터를 받으면 클라이언트는 암호화된 객체를 받고 데이터 키에 액세스가 있거나 다른 곳으로부터 데이터 키를 찾을 수 있으면 받은 데이터를 복호화하여 복호화된 객체를 얻게 된다.
서버 데이터 저장소는 데이터를 암호화하거나 복호화할 수 없고 그저 암호화된 데이터를 받기만 할 수 있다.

KMS (Key Management Service)

AWS 서비스로 암호화한다고 하면 KMS 암호화일 가능성이 크다.
KMS 서비스를 사용하면 AWS에서 암호화 키를 관리한다.
KMS는 권한 부여를 위해 IAM과 완전히 통합되고 KMS로 암호화한 데이터에 관한 액세스를 더 쉽게 제어하도록 한다.
AWS KMS를 사용의 장점으로는 CloudTrail을 통해 키를 사용하기 위해 호출한 모든 API를 감사할 수 있다는 점이다. (중요)
저장 데이터를 EBS 볼륨에서 암호화하려면 KMS 통합을 활성화하면 된다. S3, RDS, SSM도 동일
KMS을 직접 적용할 수도 있다. (API 호출, AWS CLI, SDK)
암호 데이터는 절대로 평문으로 저장하면 안 된다. 특히 코드에는 남기면 안된다.

대칭키(Symmetric)

대칭 KMS 키에는 데이터 암호화와 복호화에 사용하는 단일 암호화 키만 있어서 KMS와 통합된 모든 AWS 서비스는 대칭 키를 사용
KMS 대칭 키를 생성하거나 사용하면 키 자체에는 절대로 액세스할 수 없고 키를 활용 또는 사용하려면 KMS API를 호출해야 한다.

비대칭키(Asymmetric), 공개키

KMS에서 사용 가능한 두 번째 키는 바로 비대칭 키라고 한다. 2개의 키를 의미
데이터 암호화에 사용하는 퍼블릭 키와 데이터 복호화에 사용하는 프라이빗 키
따라서 암호화, 복호화와 작업 할당 및 검증에 사용
이 경우에는 KMS에서 퍼블릭 키를 다운로드 할 수 있지만 프라이빗 키에는 액세스할 수 없다.
프라이빗 키에 액세스하려면 API 호출로만 가능

KMS 키 타입7

KMS로 호출하는 모든 API도 비용을 지불해야 한다.
API 호출 10,000건당 약 3센트

AWS 관리형 키

이 키는 aws/rds나 aws/ebs와 같이 이름이 지정된다.
AWS 서비스와 통합되어 있으며 무료 서비스이므로 AWS에서 관리하며 특정 서비스에 관한 저장 데이터 암호화에 사용할 수 있다.

고객 관리형 키 (CMK)

KMS를 사용해 생성 가능하고 키 하나에 매달 1달러의 비용이 든다.

외부에서 가져온 고객 관리형 키

자체 키 구성 요소를 KMS에 가져올 수 있다.
KMS에서 생성할 수 있고 동일하게 매달 1달러의 비용이 든다.

키 교체

보안을 위해서 자동으로 키를 교체하도록 설정할 수 있다.
AWS 자동 관리형 키를 사용하면 자동으로 1년에 한 번씩 교체되며 고객 관리형 KMS 키를 사용하면 반드시 교체되도록 활성화해야 한다.
활성화한 후에는 자동으로 1년에 한 번씩 교체되며 교체 빈도를 변경할 수는 없다.
자체 키 구성 요소를 KMS로 보내려면 수동으로만 키를 교체할 수 있고 올바르게 키를 교체하려면 반드시 KMS 키 별칭을 사용해야 한다.

키 정책

KMS 키에 관한 액세스를 제어하는 것으로 S3 버킷 정책과 비슷하지만 차이점이 있는데 KMS 키에 KMS 키 정책이 없으면 누구도 액세스할 수 없다.
이와 관련해 2가지 유형의 KMS 키 정책이 있다.

기본 정책

기본 정책은 사용자 지정 키 정책을 제공하지 않으면 생성된다.
기본적으로 계정의 모든 사람이 키에 액세스하도록 허용
즉, 사용자 또는 키 정책의 액세스를 허용하는 IAM 정책이 있으면 된다.

사용자 지정 키 정책

제어를 조금 더 특정하고자 할때 KMS 키에 액세스할 수 있는 사용자 또는 역할을 정의하고 키 관리자를 정의할 수 있는 정책
KMS 키에 관한 교차 계정 액세스 시 매우 유용
다른 계정이 KMS 키를 사용하도록 권한을 부여하기 때문
사용 사례는 계정 간에 스냅샷을 복사할 때 자체 KMS 키로 암호화한 스냅샷을 생성하면 고객 키 정책을 연결해야 하므로 고객 관리형 키가 되며 교차 계정 액세스 권한 부여를 위해 KMS 키 정책을 연결
암호화된 스냅샷을 대상 계정에 공유하면 대상 계정에서는 스냅샷 복제본을 생성하고 해당 대상 계정에서 다른 고객 관리형 키로 암호화한다.
이렇게 대상 계정의 스냅샷에서 볼륨을 생성하면 끝이다.

KMS Multi Region Keys

AWS KMS에는 다중 리전 키를 둘 수 있다. 선택된 한 리전에 기본 키를 갖는다는 의미
다른 리전도 동일한 키를 갖게 되는데 키 ID와 구성 요소가 완전히 똑같다.
KMS 다중 리전 키는 다른 AWS 리전에서 사용할 수 있는 KMS 키 세트로 서로 교차해서 사용할 수 있다.
한 리전에서 암호화한 다음 다른 리전에서 복호화 할 수 있다.
핵심은 한 리전에서 암호화하고 다른 리전에서 복호화해 다음 리전으로 복제할 때나 교차 리전 API 호출을 실행할 때 데이터를 재암호화하지 않아도 된다는 점
하지만 KMS 다중 리전 키는 전역으로 사용할 수 없다.
기본 키가 있고 복제본이 있는 것
각 다중 리전 키는 자체 키 정책 등으로 각각 독립적으로 관리
따라서 특정 사용 사례를 제외하고는 다중 리전 키 사용을 권장하지 않는다.
다중 리전 키의 사용 사례에는 전역 클라이언트 측 암호화가 있다.

S3 암호화 복제

한 버킷에서 다른 버킷으로 S3 복제를 활성화하면 암호화되지 않은 객체와 SSE-S3로 암호화된 객체가 기본으로 복제
고객 제공 키인 SSE-C로 객체를 암호화하면 복제되지 않는다.
SSE-KMS로 암호화된 객체도 있다.
기본적으로 복제되지 않지만 만약 객체를 복제하려면 옵션을 활성화해야 한다.
따라서 어떤 KMS 키로 대상 버킷 내 객체를 암호화하는지 지정해야 합니다
그리고 이 KMS 키 정책을 대상 키에 적용해야 하고 S3 복제 서비스를 허용하는 IAM 역할을 생성해서 소스 버킷의 데이터를 먼저 복호화하도록 한 뒤 대상 KMS 키로 대상 버킷의 데이터를 다시 암호화한다.
이렇게 하면 복제가 활성화되는데 이는 수많은 암호화와 복호화가 발생하기 때문
KMS 스로틀링 오류가 발생한 경우는 서비스 할당량을 요청해야 한다.
여기서 S3 복제에 다중 리전 키를 사용해야 할까?
공식 문서에 따르면 S3 복제에 다중 리전 키를 사용할 수 있으나 현재는 Amazon S3 서비스에서 독립 키로 취급하고 있으므로 객체는 여전히 복호화될 것이고 다중 리전 키인 경우에도 동일한 키로 암호화된다.

암호화된 AMI 공유 프로세스

AMI는 KMS 키로 암호화 되어 있습니다
AMI는 소스 계정에 있고 KMS 키로 암호화된 것
어떤 방식으로 A 계정의 AMI에서 B 계정의 EC2 인스턴스를 시작할 수 있을까?
먼저, 시작 권한으로 AMI 속성을 수정해야 하는데 이 시작 권한은 B 계정에서 AMI를 시작하도록 허용한다. 이렇게 AMI를 공유
시작 권한을 수정하고 특정 대상인 AWS 계정 ID를 추가하는 것
그런 다음 B 계정에서 사용하도록 KMS 키도 공유해야 하므로 일반적으로 키 정책으로 실행
이제 B 계정에서 KMS 키와 AMI를 모두 사용할 수 있는 충분한 권한을 가진 IAM 역할이나 IAM 사용자를 생성
따라서 DescribeKey API 호출과 ReEncrypted API 호출 CreateGrant, Decrypt API 호출에 관한 KMS 측 액세스 권한이 있어야 한다.
모두 완료된 후에는 AMI에서 EC2 인스턴스를 시작하면 되는데 선택 사항으로 대상 계정에서 자체 계정의 볼륨을 재암호화하는 KMS 키를 이용해 전체를 재암호화할 수 있다.
이제 EC2 인스턴스를 실행할 수 있다.

SSM 매개변수 저장소

구성 및 암호를 위한 보안 스토리지
구성을 암호화할지 선택할 수 있으므로 KMS 서비스를 이용해 암호를 만들 수 있다.
SSM Parameter Store는 서버리스이며 확장성과 내구성이 있고 SDK도 사용이 용이
또한 매개변수를 업데이트할 때 구성과 암호의 버전을 추적할 수도 있다.
IAM을 통해 보안이 제공되며 특정한 경우에는 Amazon EventBridge로 알림을 받을 수도 있다.
CloudFormation이 Parameter Store의 매개변수를 스택의 입력 매개변수로 활용할 수 있다.

Paramters Policies

고급 매개변수에서만 사용할 수 있다.
매개변수 정책을 통해 만료 기한을 뜻하는 타임 투 리브(TTL)를 매개변수에 할당할 수 있다.
비밀번호 등의 민감한 정보를 업데이트 또는 삭제하도록 강제한다.
한 번에 여러 정책을 할당할 수도 있다.

AWS Secrets Manager

암호를 저장하는 최신 서비스로 SSM Parameter Store와는 다른 서비스
Secrets Manager는 X일마다 강제로 암호를 교체하는 기능이 있어 암호 관리를 더 효율적으로 할 수 있다.
또한 AWS Secrets Manager로 교체할 암호를 강제 생성 및 자동화할 수 있다.
이를 위해 새 암호를 생성할 Lambda 함수를 정의해야 한다.
AWS Secrets Manager는 AWS가 제공하는 다양한 서비스와도 아주 잘 통합된다. (RDS, MySQL,PostgreSQL, Aurora 등)
AWS 외 여러 서비스와 데이터베이스에도 즉시 통합할 수 다.
데이터베이스에 접근하기 위한 사용자 이름과 비밀번호가 AWS Secrets Manager에 바로 저장되고 교체 등도 가능하다.
암호는 KMS 서비스를 통해 암호화된다.
RDS와 Aurora의 통합 혹은 암호에 대한 내용이 시험에 나오면AWS Secrets Manager를 떠올려야 한다.

다중 리전 암호

복수 AWS 리전에 암호를 복제할 수 있고 AWS Secrets Manager 서비스가 기본 암호와 동기화된 읽기 전용 복제본을 유지한다는 개념
이렇게 두 리전이 있을 때 기본 리전에 암호를 하나 만들면 보조 리전에 동일한 암호가 복제된다.
이렇게 하는 데에는 여러 이유가 있다.
첫째, us-east-1에 문제가 발생하면 암호 복제본을 독립 실행형 암호로 승격할 수 있다.
그리고 여러 리전에 암호가 복제되니 다중 리전 앱을 구축하고 재해 복구 전략도 짤 수 있다.
한 리전에서 다음 리전으로 복제되는 RDS 데이터베이스가 있다면 동일한 암호로 동일한 RDS 데이터베이스즉 해당 리전의 해당 데이터베이스에 액세스할 수 있다.

AWS Certificate Manager(ACM)

ACM은 TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포하게 해준다.
ACM은 퍼블릭과 프라이빗 TLS 인증서를 모두 지원하며 퍼블릭 TLS 인증서 사용 시에는 무료로 이용할 수 있다.
인증서를 자동으로 갱신하는 기능도 있다.
그리고 여러 AWS 서비스와 통합되어 있어 Elastic Load Balancer(ELB)에 TLS 인증서를 불러올 수 있다. (ALB, NLB)
CloudFront 배포나 API Gateway의 모든 API에서도 불러올 수 있다.
다만 ACM을 사용할 수 없는 곳이 하나 있는데 바로 EC2 인스턴스

엔드 포인트 유형

엣지 최적화(edge-optimized) 유형

글로벌 클라이언트를 위한 유형으로 먼저 CloudFront 엣지 로케이션으로 요청을 라우팅하여 지연을 줄이는 방법으로 하나의 리전에만 있는 API Gateway로 보내지는 경우

리전(regional) 엔드 포인트 유형

클라이언트가 API Gateway와 같은 리전에 있을 때를 쓰인다.
이 경우 CloudFront는 사용할 수 없지만 자체 CloudFront 배포를 생성하여 캐싱 및 배포 전략을 제어할 수 있다

프라이빗(private) API Gateway 엔드포인트 유형

인터페이스 VPC 엔드 포인트(ENI)를 통해 VPC 내부에만 액세스할 수 있다.
또한 프라이빗 모드에서는 API Gateway에 대한 액세스를 정의하는 리소스 정책이 필요하다.
ACM은 엣지 최적화 및 리전 엔드포인트에 적합하다.

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

WAF는 7계층에서 일어나는 일반적인 웹 취약점 공격으로부터 웹 애플리케이션을 보호한다.
계층 7은 HTTP이니 HTTP 취약점 공격을 막아주는 것
웹 애플리케이션 방화벽(WAF)의 배포는 애플리케이션 로드 밸런서, API Gateway CloudFront AppSync GraphQL API Cognito 사용자 풀에 할 수 있다.
WAF의 배포가 어디에 되는 지 꼭 기억해야한다.
WAF를 NLB에 배포한다는 것은 틀렸다. 이는 4계층
이러한 서비스에 방화벽을 배포한 후에는 웹 액세스 제어 목록(ACL)과 규칙을 정의해야 한다.
이 규칙이란 IP 주소를 기반으로 필터링하는 등의 규칙
IP 세트를 정의할 수 있으며 각 IP 세트는 최대 10,000개의 IP 주소를 가질 수 있다.
또한 HTTP 헤더와 본문에 기반해 필터링할 수도 있고 URI 문자열을 조건으로 두어 SQL 주입, 크로스 사이트 스크립팅(XSS) 등의 일반적인 공격을 차단할 수도 있다
용량에 제약을 걸어 요청이 최대 2MB를 넘지 않게 하거나 지역 일치(Geo-match) 조건을 두어 특정 국가를 허용 또는 차단 가능
또 속도 기반 규칙을 설정하면 IP당 요청 수를 측정하여 디도스 공격을 막을 수도 있다
웹 ACL은 리전에만 적용되며 CloudFront는 글로벌로 정의됩니다
규칙 그룹은 여러 웹 ACL에 추가할 수 있는 재사용 가능한 규칙 모음

AWS Shield

AWS Shield는 디도스 공격으로부터 스스로를 보호하기 위한 서비스
디도스란 분산 서비스 거부 공격이라는 뜻. 인프라에 동시에 엄청난 양의 요청이 세계 곳곳의 여러 컴퓨터에서 유입되는 공격
그 목적은 인프라에 과부하를 일으키는 것으로 실제 사용자들에게 서비스를 제공할 수 없게 만든다. 즉 분산 서비스 거부가 발생
디도스 공격을 방어하려면 AWS Shield 스탠다드 서비스를 이용하면 된다.
이 서비스는 모든 AWS 고객에게 무료로 활성화되어 있는 서비스로 SYN/UDP Floods나 반사 공격 및 L3/L4 공격으로부터 고객을 보호해 준다.
고급 보호가 필요한 고객을 위한 AWS Shield 어드밴스드 서비스도 있는데 어드밴스드는 선택적으로 제공되는 디도스 완화 서비스로 조직당 월 3,000달러를 지불해야 한다.
어드밴스드에서는 더욱 정교한 디도스 공격을 막아주며 Amazon EC2, ELB Amazon CloudFront AWS Global Accelerator 그리고 Route 53를 보호한다.
또한 AWS 디도스 대응 팀이 항시 대기하고 있어 공격을 받았을 때 지원을 받을 수 있다.
따라서 디도스 공격으로 인한 요금 상승을 AWS Shield 어드밴스드를 통해 방지할 수 있겠다.
또 Shield 어드밴스드는 자동 애플리케이션 계층 디도스 완화도 제공하여 자동으로 WAF 규칙을 생성, 평가, 배포함으로써 L7 공격을 완화할 수 있다.
즉 웹 애플리케이션 방화벽이 L7에서 일어나는 디도스 공격을 완화하는 규칙을 자동으로 갖게 된다는 뜻

AWS Firewall Manager

AWS Organizations에 있는 모든 계정의 방화벽 규칙을 관리하는 서비스
여러 계정의 규칙을 동시에 관리할 수 있다.
또한 보안 규칙의 집합인 보안 정책을 설정할 수 있는데 여기에는 ALB, API Gateway CloudFront 등에 적용되는 웹 애플리케이션 방화벽(WAF) 규칙이나 ALB, CLB, NLB, 엘라스틱 IP CloudFront를 위한 AWS Shield 어드밴스드 규칙 등이 포함된다.
또 EC2, 애플리케이션 로드 밸런서 VPC의 ENI 리소스를 위한 보안 그룹을 표준화하는 보안 정책과 아직 다룬 적은 없지만 VPC 수준의 AWS Network Firewall도 해당된다.
그리고 Amazon Route 53 Resolver DNS Firewall도 포함된다.
AWS Firewall Manager는 이와 같은 모든 방화벽을 한 곳에서 관리할 수 있도록 지원해 준다.
정책은 리전 수준에서 생성되며 조직에 등록된 모든 계정에 적용된다.

WAF, Firewall Manager, Shield 차이

WAF, Shield Firewall Manager는 모두 포괄적인 계정 보호를 위한 서비스
일단 WAF에서는 웹 ACL 규칙을 정의하는데 리소스별 보호를 구성하는 데에는 WAF가 적절합니다
여러 계정에서 WAF를 사용하고 WAF 구성을 가속하고 새 리소스 보호를 자동화하려면 Firewall Manager로 WAF 규칙을 관리
Firewall Manager는 이러한 규칙들을 모든 계정과 모든 리소스에 자동으로 적용해준다.
Shield 어드밴스드는 디도스 공격으로부터 고객을 보호하고 WAF의 기능 외에도 더 많은 기능을 제공
예를 들어 Shield 대응 팀 지원 고급 보고서 제공 그리고 WAF 규칙 자동 생성 등의 기능을 추가로 이용할 수 있다.
디도스 공격을 자주 받는다면 Shield 어드밴스드를 사용하는 것도 좋은 선택지가 될 수 있다.
또한 Firewall Manager는 모든 계정에 Shield 어드밴스드를 배포에도 도움을 준다.

GuardDuty

AWS 계정을 보호하는 지능형 위협 탐지 서비스
백엔드에서 머신 러닝 알고리즘을 사용하여 이상 탐지를 수행하고 타사 데이터를 이용하여 계정에 대한 공격을 탐지한다.
Amazon GuardDuty는 여러 소스에서 입력 데이터를 얻는다.
CloudTrail 이벤트 로그의 입력 데이터를 가지고 비정상적 API 호출과 무단 배포 등을 탐지한다.
관리 이벤트에서 사용하여 해당 이벤트가 VPC 서브넷을 만들 때 생기는지 API가 계정에 호출하는 추적 생성 시 생기는지 확인한다.
CloudTrail S3 데이터 이벤트를 확인한다. 예를 들어 버킷에서 발생하는 이벤트인 API 호출, 즉 get object, list objects delete object 등
VPC 흐름 로그를 통해 비정상적인 인터넷 트래픽과 IP 주소를 찾고 또한 DNS 로그는 DNS 쿼리에서 인코딩된 데이터를 전송할 EC2 인스턴스가 손상되었는지 확인할 수 있다.
Kubernetes 감사 로그를 확인하여 의심스러운 활동 및 잠재적인 EKS 클러스터 손상을 감지한다.
이 모든 작업이 내부적으로 이루어진다.
그리고 CloudWatch 이벤트 규칙을 설정하여 탐색 결과가 나타나면 알림을 받을 수 있다.
마지막으로 시험에 나올 수 있는 내용은 GuardDuty로 암호화폐 공격을 보호할 수 있다는 점
요약하면 GuardDuty는 VPC 흐름 로그, CloudTrail 로그 DNS 로그 및 EKS 감사 로그를 모두 GuardDuty로 가져온다.
그리고 CloudWatch 이벤트 규칙 덕분에 Lambda 함수나 SNS 주제 알림을 받을 수 있다.

Amazon Inspector

Amazon Inspector는 몇 군데에서 자동화된 보안 평가를 실행할 수 있는 서비스

EC2 인스턴스 경우

EC2 인스턴스에서 시스템 관리자 에이전트를 활용하면 Amazon Inspector가 해당 EC2 인스턴스의 보안을 평가하기 시작한다.
의도되지 않은 네트워크 접근 가능성에 대해 분석하고, 실행 중인 운영 체제에서 알려진 취약점을 분석한다.
이건 연속적으로 수행된다.

컨테이너 이미지를 Amazon ECR로 푸시할 때 실행

예를 들어 도커 이미지
컨테이너 이미지가 Amazon ECR로 푸시되면 Amazon Inspector가 알려진 취약점에 대해 검사
Lambda 함수에 대해서도 사용 가능한데요
Amazon Inspector는 Lambda 함수가 배포될 때 함수 코드 및 패키지 종속성에서 소프트웨어 취약성을 다시 분석
즉, 함수가 배포될 때 평가
Amazon Inspector가 작업을 완료하면 결과를 AWS 보안 허브에 보고한다.
또한 이러한 결과 및 결과 이벤트를 Amazon Event Bridge로 보낸다.
이를 통해 인프라에 있는 취약점을 모아서 볼 수 있다.
Inspector는 실행 중인 EC2 인스턴스, Amazon ECR의 컨테이너 이미지, Lambda 함수에만 사용된다

Macie

Macie는 완전 관리형의 데이터 보안 및 데이터 프라이버시 서비스이며 머신 러닝과 패턴 일치를 사용하여AWS의 민감한 정보를 검색하고 보호한다.
구체적으로 말하면 민감한 데이터를 경고하는데 예를 들면, 개인 식별 정보 즉, PII 같은 정보다.
ex) S3버킷에 PII가 있다면 Macie에 의해 분석되고 어떤 데이터를 PII로 분류할 수 있는지 알아낸 후 EventBridge를 통해 발견 결과를 알려준다.