AWS 보안 및 암호화

전송 중 암호화 encrytion in flight SSL

매우 민감한 기밀 내용인 경우 전송 중 암호화를 사용한다.

가령 신용카드로 온라인 결제를 하려고 할 때 네크워크 패킷이 가는 길에 다른 사람한테 신용카드 번호가 보여서는안된다.

이렇게 전송중 암호화 된 데이터를 서버가 받아서 복호화 한다.

전송하는 이와 서버만이 암호화와 복호화 하는 방법을 알고 있다.

이걸 사용하면 MITM ( man in the middle attack) 이 발생하는 걸 막을 수 있다.

 

server side encryprtion at rest 서버 측 저장 데이터 암호화

데이터가 서버에 수신된 후 암호화 하는 것이다. 서버는 데이터를 디스크에 저장한다.

서버가 데이터를 암호화 된 형태로 저장하고 있다는 것이다. 서버가 해킹당해도 복호화 안됨

클라이언트로 전송되기 전에 복호화 된다. 데이터 키라고 불리는 키 덕분에 데이터는 암호화 된 형태로 저장이 되고 암호 키와 해독 키는 주로 KMS Key Manager Service 같은 곳에 따로 관리 된다. 따라서 서버는 KMS와 통신할 수 있어야 한다.

 

Client side encryption 클라이언트 측 암호화

데이터는 클라이언트가 암호화 하고 여기서 클라이언트는 우리고 서버는 그 데이터를 절대 복호화 할 수 없다.

데이터를 받은 클라이언트에 의해 복호화 된다. 전체적으로 데이터는 서버에 저장되지만  서버는 데이터의 내용을 알 수 없습니다. 

 

AWS KMS 

AWS서비스로 암호화 한다고 하면 KMS 암호화일 가능성이 크다.

KMS서비스를 사용하면 AWS에서 암호화 키를 관리한다.  따라서 KMS는 권한 부여를 위해 IAM과 완전히 통합되고 

KMS로 암호화한 데이터에 관한 액세스를 더 쉽게 제어하도록 한다.

CloudTrail로 키를 사용하기 위해 호출한 모든API를 감사할 수 있다는 점이다.

ebs등에서 저장데이터를 암호화 하려면 KMS통합을 활성화 하면된다. 엄청 간편

 

KMS키에는 2가지 유형이 있다.

symmetric key (대칭키) 

대칭 KMS키에는 데이터 암호화와 복호화에 사용하는 단일 암호화 키만 있어서 KMS와 통합된 모든 AWS 서비스는 대칭 키를 사용합니다.  

키 자체에는 절대 접근할 수 없고 KMS API를 호출해야 사용 또는 활용이 가능하다.

 

Asymmetric key (비대칭키)

두번째 기는 바로 비대칭 키라고 한다. 2개의 키를 의미한다.

데이터 암호화에 사용하는 퍼블릭 키와 복호화에 사용하는 프라이빗 키이다.

이 경우에는 KMS에서 퍼블릭 키를 다운로드 할 수 있지만 프라이빗 키에는 액세스할 수 없다.

이 역시 액세스하려면 API호출로만 가능하다.

 

사용사례는 KMS API키에 액세스 할 수 없는 사용자가 AWS 클라우드 외부에서 암호화 할 때 사용하는 사례가 있다.

퍼블릭 키로 암호화 하고 데이터를 보내면 계정의 AWS프라이빗 키로 해당 데이터를 복호화 하는 것

 

AWS KMS ( key Mangement Service ) AWS관리형 키

이 키는 aws/rds, aws/ebs와 같이 이름이 지정된다. 무료로 사용할 수 있으며 aws에서 관리하기에 특정 서비스에 관한 저장데이터를 암호화 할 때 유용. 고객 관리형 키인 CMK도 생성할 수 있다.

고객 관리형 KMS 키를 사용하면 반드시 교체 되도록 활성화 해야한다. 활성화 한 후에는 자동으로 1년에 한 번씩 교체되며

교체빈도 변경 x

CMK에 대한 액세스를 제어하기 위해선

KMS키 정책을 사용해야함

Copying Snapshots across regions 

하나의 a리전의 EBS볼륨가 b KMS키로 암호화가 되어있다고하자.

이걸 스냅샷으로 복사하면 b KMS키로 암호화가 되어있다.

 

이건 다른 c 리전으로 복사를 하는 경우 

이 스냅샷이 d KMS키로 자동으로 암호화가 된다 ( 이건 aws가 알아서 해줌 동일한 키가 서로 다른 리전에 있을 수 없기에)

이걸 ebs로 복원하면 c 리전에 d키로 암호화 된 ebs가 생성된다.

 

KMS Key Policies

s3버킷 정책과 비슷하지만 차이점이 있다.

KMS키에 KMS키 정책이 없으면 누구도 액세스할 수 없다.

2가지 정책이 존재

기본정책은 사용자 지정 키 정책을 제공하지 않으면 디폴트 값으로 생성된다.

기본적으로 계정의 모든 사람이 키에 액세스 가능하도록 허용

 

하지만 KMS키에 액세스할 수 있는 사용자 또는 역할을 정의하고 키 관리자를 정의할 수 있는 사용자 지정 키 정책을 사용하면 된다. ( 자신의 계정에서 ebs볼륨 스냅샷을 찍어 다른 계정에서 생성한 후 자신의 KMS키로 접속할 수 있도록 허용하는 등 ) 

 

Multi Region Keys

AWS KMS에는 다중 리전 키를 둘 수 있다.

가령 east1에 기본키를 두면 다른 리전으로 복제가 된다.

다른 리전도 동일한 키를 갖게 된다. 키 ID가 완전히 똑같다.

한 리전에서 암호화 한 다음 다른 리전에서 복호화 할 수 있다.

자동 교체를 활성화 한 경우에 다른 리전에 복사된 키 또한 자동 활성화가 된다.

 

각 복제된 키는 독립적으로 각각다른 정책을 사용할 수 있다.

하나의 키로 글로벌에서 사용할 수 있는 것이 아니다.

단지 리전마다 복사를 해두어서 사용할 수 있는 것이다.

단일 리전에 제한되는 것을 선호한다.

 

S3 Replication Encryption Considerations

한 s3에서 다른 s3로 객체를 복사하는 경우

SSE-S3로 암호화 된 오브젝트와, 암호화 되지 않은 오브젝트는 기본적으로 복사가 되지만

SSE-C(클라이언트 측 암호화)로 암호화 된 오브젝트는 복사되지 않는다. 키는 클라이언트가 가지고 있기 때문이다.

SSE-KMS로 암호화 된 오브젝트는 기본적으로는 복제가 되지 않지만 옵션을 활성화 하면 가능하다.

따라서 어떤 KMS키로 대상 버킷 내 객체를 암호화 하는지 지정해야 한다.

 

AMI Sharing Process Encrypted via KMS

AMI를 다른 계정과 공유하는 과정에 관한 것으로

AMI는 KMS로 암호화 되어 있다.

복제하는 쪽의 어카운트에서 KMS키와 AMI를 모두 사용할 수 있는 충분한 권한을 가진 IAM역할이나 사용자를 생성한다.

이렇게 한 뒤 ami으로 ec2를 만들면 되는데

선택 사항으로 대상 계정에서 자체 계정의 볼륨을 재암호화 하는 KMS키를 이용해 전체를 재 암호화 할 수 있다.

 

SSM Parameter Store

구성 및 암호를 위한 보안 스토리지이다.

구성을 암호화 할 지 선택할 수 있다. 암호를 저장하는데 사용할 수 있으며 추적 기능이 내장되어있어 새 버전을 생성하면 기존의 버전을 보관한다.

일반 string option이면 KMS 키가 필요없지만

secure string으로 하려면 KMS 서비스를 이용해서만들 수 있다. ( 현재 계정에 있는 것과, 다른 계정에 있는 것 중에 선택 가능 )

db-url, db-password를 저장하여 람다에서 여기에 접근할 수 있는 iam역할을 가지고 있다면

여기에 있는 정보를 읽을 수 있다.

TTL을 설정하여 민감한 정보가 일정 시간이 지나면 사라지도록 설정할 수도 있다.

Lambda함수에 데이터 베이스 비밀번호에 대한 액세스를 부여하려면

암호화된 환경변수로 만들고 런타임에서 이를 복호화 하면된다/

 

애플리케이션이 주요 데이터베이스의 구성 값을 외부적으로 유지하여 그 값을 런타임 시 선택할 수 있고,

제어와 버전 내역을 유지하기 위해 사용가능

 

 

Secrets Manager

암호를 저장하는 최신 서비스

SSM parameter store(system manager parameter store)과는 다른 서비스이다.

secrets manager는 x일마다 강제로 암호를 교체하는 기능이 있어 효율적 관리가 가능 ( 자동 순환을 지원 )

교체할 암호를 강제 생성 및 자동화 할 수 있다. 이 과정이 매우 쉬움

이를 위해 새 암호를 생성할 Lambda 함수를 정의해야 한다.

AWS가 제공하는 다양한 서비스와도 아주 잘 통합된다 ( RDS,  Aurora ... )

데이터 베이스와의 긴밀한 통합도 지원한다.

데이터베이스에 접근하기 위한 사용자 이름과 비밀번호가 Secret manager에 바로 저장되고 교체도 가능하다.

암호는 KMS 서비스를 통해 암호화된다.

 

RDS와 Aurora의 통합 혹은 암호에 대한 내용이 시험에 나오면 AWS Secrets manager를 떠올리면 좋다.

RDS DB 비밀번호를 저장하는 데 가장 적합

다중 리전 암호의 개념도 알아두어야 한다. 복수 리전에 암호를 복제할 수 있다. 기본 암호화 동기화된 읽기 전용 복제본을 유지한다는 개념이다. 재해 복구 전략으로 기본 암호가 유실되어도 복제된 암호가 승격되어 사용할 수도 있다.

 

ACM AWS Certificate Manager

ACM은 TLS인증서를 AWS에서 프로비저닝, 관리 및 배포하게 해준다.

TLS/SSL 인증서는 어디에 사용될까요??

웹사이트에서 전송 중 암호화를 제공하는데 쓰인다.

오토스케일링 그룹에 연결된 ALB가 있다고 해보자

이 때 애플리케이션 로드 밸런서를 https엔드 포인트로서 노출하려 한다.

그 때 ALB를 AWS Certificate Manager와 통합해 ALB에서 직접 TLS인증서를 프로비저닝 및 유지관리하도록 하면 된다.

그럼 사용자가 https 프로토콜을 사용하는 웹사이트 또는 api에 엑세스 하게 된다.

다양한 aws서비스와 연결될 수 있지만 ec2에서는 사용할 수 없다.

 

다른곳에서 발행한 인증서를 ACM에서도 사용할 수 있다.

하지만 이 경우 자동 갱신은 불가하다.

만료일이 다가오면 설정헤둔 만료일에 따라 eventBridge에 이벤트가 밝생한다,.

그럼 그 이벤트가 람다 함수나 sns나 sqs로 전달할 수 있는 것이다.

 

또 AWS Config를 사용할 수 있다.

룰 체크를 하여 위반된 인증서가 있으면 이벤트브릿지에 이벤트를 발생시킬 수 있다.

자동 경고를 받는 방법은 이렇게 두 가지가 있다.

 

유저가 ALB로 http통신을 보내면 ALB는 https로 리다이렉트 시키고 , https프로토콜로 액세스 하면 ACM에서 인증서를 가져와 

암호화 하여 오토스캐일링 그룹으로 보낸다.

 

API Gateway에는 Edge-optimized라는 유형이 있는데

글로벌 클라이언트를 위한 유형으로 cloudfront 엣지 로케이션으로 요청을 라우팅하여 지연을 줄이는 방법으로

하나의 리전에만 있는 API Gateway로 보내지는 경우이다.

이 때에 ACL인증서는 cloudFront와 같은 리전에 존재해야한다.

클라우드프론트를 위한 인증서는 전부 us-east-1에 있다.

CloudFront와 ACM같은 리전

즉 ACM은 무조건 us-ease-1에 있어야한다.

 

Regional유형은 클라이언트가 API Gateway와 같은 리전에 있을 때 쓴다.

api게이트웨이와 acm이 같은 리적에 속해있어야 한다.

API Gateway와 ACM이 같은 리전

 

 이 경우 CloudFront는 사용할 수 없지만 자체 CloudFront를 배포하여 캐싱 및 배포 전략을 제어할 수 있다.

 

Private유형은 인터페이스 VPC 엔드포인트를 통해 VPC내부에만 액세스 할 수 있다.

 

WAF Web Application Firewall

WAF는 계층 7에서 일어나는 일반적인 웹 취약점 공격으로부터 웹 애플리케이션을 보호합니다.

http 취약점 공격을 막아준다. 

이건 ALB, API Gateway, CloudFront, AppSync, GraphQL API, Cognito 사용자풀 에 사용가능하다.

WAF의 배포가 어디에 되는지 기억해야한다. ( NLB에 배포된다 같은 내용으로 시험에 나올 수 있다. NLB가 아니라 ALB에 배포될 수 있다

)

 

이러한 서비스 들에 방화벽을 배포한 후에는

웹 액세서 제어목록 ACL과 규칙을 정의해야한다.

ALB에는 고정IP가 없으므로 Global Accelerator를 발급받아 ALB에 부착 시킨 뒤 ALB와 같은 리전에 WAF를 생성해 부착하면된다.

AWS WAF와 ALB는 같인 리전에 존재해야한다.

 

 

AWS Shield

DDoS공격으로 부터 스스로를 보호하기 위한 서비스이다.

인프라에 동시에 엄청난 양의 요청이 세계 곳곳의 여러 컴퓨터에서 유입되는 공격이다.

과부하를 일으켜 실제 사용자들에게 서비스를 제공할 수 없도록 하는 것이다.

무료로 사용가능하다.

SYN/UDP Floods나 반사 공격 및 L3/L4 공격으로 부터 고객을 보호해 준다.

 

AWS Firewall Manager

방화벽 규칙을 관리하는 서비스이다. 여러 계정의 규칙을 동시에 관리할 수 있다.

애플리케이션 로드 밸런서에ㅔ 대한WAF규칙을 생성한 다음 새 애플리케이션 로드 밸런서를 생성하는 경우

AWS firewall manager에서 자동으로 새ALB에도 같은 규칙을 적용해준다.

 

WAF, Firewall manager, shield

WAF에서는 웹 ACL규칙을 정의한다. 리소스별 보호를 구성하는데에는 WAF가 적합

하지만 여러 계정에서 WAF를 사용하고 새 리소스 보호를 자동화 하려면 Firewall manager로 WAF규칙을 관리하면 된다.

shield는 DDos공격을 보호해준다.  

firewall manager로 모든 계정에 shield를 배포해줄 수도 있다.

AWS Organizations에 있는 계정과 애플리케이션 간에서 방화벽 규칙을 구성하고 중앙 관리를 할 수 있게 해준다.

 

 

GuardDuty

AWS 계정을 보호하는 지능형 위협 탐지 서비스이다. 백엔드에서 머신 러닝 알고리즘을 사용하여 이상 탐지를 수행하고 

타사 데이터를 이용하여 계정에 대한 공격을 탐지한다.

VPC flow logs, CloudTrail Logs,DNS logs EKS audit logs를 모두 guard duty로 가져온다.

CloudWatch로그는 안가져옴

그리고 문제가 될 만한 것들을 cloudwatch 이벤트 규칙으로 람다나 sns로 보낸다.

시험에 나올만 한 것은 GuardDuty로 암호화폐 공격을 보호할 수 있다는 점이다.

 

Inspector

이건  몇 군데에서 자동화된 보안 평가를 실행할 수 있는 서비스이다.

먼저 ec2 인스턴스에서 시스템 관리자 에이전트를 사용하면 ( SSM Agent ) Amazon Inspector가 해당 EC2 인스턴스의 보안을 평가하기 시작할 것이다. 의도되지 않은 네트워크 접근 가능성에 대해 분석하고 실행중인 운영체제애서 알려진 취약점을 분석한다.

람다나, 도커로 생성한 ECR에서도 사용가능하다. 

 

Amazon Inspector가 작업을 완료하면 결과를 AWS 보안 허브에 보고한다. 또한 이러한 결과 및 결과 이벤트를

Event Bridge로 보내 인프라에 있는 취약점을 모아서 볼 수 있다. 

 

Macie

데이터 보안 및 데이터 프라이버스 서비스이며

머신러닝과 패턴 일치를 사용하여 AWS의 민감한 정보를 검색하고 보호한다.

예를 들면 개인 식별 정보 PII같은 정보이다. 

PII가 S3버킷에 있다면 macie가 이것을 분석한 후 PII로 분류되는 데이터를 검색하여 CloudWatch이벤트나 EventBridge

로 검색결과를 알려준다. 그럼 이걸 SNS나 람다 함수에 통합할 수 있다.

S3버킷에 저장된 민감한 데이터를 보호할 때 사용