참고 자료
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/
Encryption 101
Encryption in flight (SSL)
- 데이터가 전송되기 전에 암호화되고 서버가 수신 후에 복호화한다.
- SSL 인증서를 통해 구현한다. (HTTPS)
- 중간자 공격 (MITM, Man in the middle attack)을 방지한다.
Server side encryption at rest
- 데이터는 서버에서 수신된 후 암호화
- 데이터는 클라이언트로 다시 전송되기 전에 복호화
- 데이터는 키(일반적으로 데이터 키라고 불림)를 통해 암호화된 형태로 저장된다.
- 암호화/복호화 키는 어딘가에서 꼭 관리되어야 하며 (주로 KMS같은 곳에서 관리됨), 서버는 이와 통신할 수 있어야 한다.
Client side encryption
- 데이터는 클라이언트에 의해 암호화되고 서버는 절대 복호화할 수 없다.
- 데이터는 수신 클라이언트에 의해 복호화된다.
- 서버는 데이터를 복화할 수 없어야 한다.
- 봉투 암호화(Envelope Encryption)을 활용할 수 있다.
AWS KMS (Key Management Service)
- AWS에서 "암호화"라는 용어는 대부분 KMS를 의미한다.
- KMS 서비스를 사용하면 AWS에서 암호화 키를 관리한다.
- KMS는 권한 부여를 위해 IAM과 완전히 통합된다.
- 암호화한 데이터에 관한 액세스를 쉽게 제어할 수 있는 방법을 제공한다.
- CloudTrail을 통해 키를 사용하기 위해 호출한 모든 API를 감사할 수 있다.
- 대부분의 AWS 서비스에 KMS를 원할하게 사용할 수 있다 (EBS, S3, RDS, SSM 등).
- 암호 데이터는 절대 평문으로 저장하면 안 된다. 특히 코드에는 절대 남기면 안 된다!
- KMS 키 암호화는 API 호출을 통해 사용할 수 있다. (SDK, CLI)
- 암호화된 데이터는 코드나 환경변수에 저장할 수 있다.
KMS KeysTypes
- KMS 키는 KMS 고객 마스터 키의 새로운 이름이다.
- **대칭(Symmetric)키 (AES-256 keys)
- 암호화 및 복호화에 사용하는 단일 암호화 키
- KMS와 통합된 AWS 서비스에서는 대칭 CMK를 사용함
- KMS 대칭 키를 생성하거나 사용하면 키 자체에는 절대 액세스할 수 없고, 키를 활용 또는 사용하기 위해서는 KMS API를 호출해야 한다.
- 비대칭(Asymmetric)키 (RSA & ECC key pairs)
- 퍼블릭 키(암호화에 사용)와 프라이빗 키(복호화에 사용) 쌍
- 암호화/복호화 또는 작업 할당(Sign)/검증 작업에 사용한다.
- KMS에서 퍼블릭 키를 다운로드할 수 있지만, 프라이빗 키에는 액세스할 수 없다.
- 사용 사례: KMS API를 호출할 수 없는 사용자에 의해 AWS 외부에서 암호화, 이후 AWS 프라이빗 키로 해당 데이터를 복호화
AWS KMS (Key Management Service)
- KMS 키 유형
- AWS 관리 키: aws/service-name, ex: aws/rds, aws/ebs - 무료
- KMS에서 생성한 고객 관리형 키 (CMS): 매달 1달러의 비용
- 자체 키 구성 요소를 KMS에 imported (256-bit 대칭키여야 함): 매달 1달러의 비용
- KMS API 호출에 대한 비용 추가 ($0.03 / 10,000 호출)
- 자동 키 로테이션
- AWS 자동 관리형 KMS 키: 1년에 한 번씩 자동 교체
- 고객 관리형 KMS 키: (활성화 필요) 1년에 한 번씩 자동 교체
- KMS에 가져온 자체 키: 별칭을 사용하여 수동으로만 교체 가능
Copying Snapshots across regions
KMS는 리전에 따라 범위가 지정된다. 다른 리전으로 복사하려면 몇 가지 단계를 거쳐야 한다.
- EBS 볼륨 스냅샷 생성
- 암호화된 스냅샷에서 스냅샷을 생성하면 생성된 스냅샷 또한 동일한 KMS 키로 암호화 됨
- 다른 리전으로 스냅샷을 복사하기 위해 다른 KMS 키를 사용하여 스냅샷을 다시 암호화해야 하는데 이는 AWS에서 자동으로 처리함 - 동일한 KMS 키가 서로 다른 리전에 있을 수 없음
- KMS로 스냅샷을 자체 EBS 볼륨으로 복원하고, KMS 키를 다른 리전으로 복원함
KMS Key Policies
- KMS 키에 대한 액세스를 제어하는데 사용되는 정책. S3 버킷 정책과 유사함
- 차이점: KMS 키에 KMS 키 정책이 없으면 누구도 액세스할 수 없음
- 기본 KMS 키 정책:
- 사용자 지정 키 정책을 제공하지 않을 시 생성됨
- 기본적으로 계정의 모든 사람이 키에 액세스하도록 허용하는 것
- 루트 사용자(전체 AWS 계정)에 대한 키의 완전한 액세스 권한
- 사용자 지정 KMS 키 정책
- 사용자 및 역할 정의: KMS 키에 액세스할 수 있는 사용자, 역할 지정
- 키를 관리할 수 있는 사용자 정의
- KMS 키의 교차 계정 액세스에 유용함
Copying Snapshots across accounts
- 자체 KMS키로 암호화한 스냅샷 생성
- 교차 계정 액세스 권한 부여를 위해 KMS 키 정책을 연결
- 암호화된 스냅샷을 대상 계정에 공유
- (대상 계정에서) 스냅샷의 복사본을 생성하고, 계정 내 CMK로 암호화 함
- 스냅샷으로부터 볼륨을 생성함
KMS Multi-Region Keys
KMS에는 다중 리전 키를 둘 수 있다. 선택된 한 리전에 기본 키를 갖는다는 의미이다.
예를 들어 us-east-1에 기본 키를 두고, 이는 다른 리전(us-west-2, eu-west-1 ap-southeast-2)으로 복제된다. 이 키들이 유사해 보이는 것은 키 구성 요소가 복제되기 때문이다.
다른 리전도 동일한 키를 갖게 되는데 키 ID가 완전히 똑같다. key/mrk 뒤에 붙은 문자들이 전체 리전에 걸쳐 동일하다. 이것이 KMS 다중 리전 키의 원리이다.
- 다른 AWS 리전에서 사용할 수 있는 상호 교환 가능한 KMS 키
- 다중 리전 키는 동일한 키 ID와 동일한 키 구성 요소를 갖는다.
- 기본 키의 자동 교체를 활성화한 뒤, 자동으로 교체된 경우 다른 리전에도 복제된다.
- 한 리전에서 암호화한 다음 다른 리전에서 복호화 가능
- 다음 리전으로 복제할 때나 교차 리전 API 호출을 실행할 때 데이터를 재암호화할 필요가 없다.
- KMS 다중 리전 키는 전역으로 사용할 수 없다. (기본 키가 있고, 복제본이 있을 뿐)
- 각각의 다중 리전 키는 독립적으로 관리되어야 한다.
- 사용 사례: 전역 클라이언트 측 암호화, DynamoDB 전역 테이블, Global Aurora에서의 암호화.
DynamoDB Global Tables and KMS Multi-Region Keys Client-Side encryption
- Amazon DynamoDB Encryption Client를 사용하여 DynamoDB 테이블의 특정 속성을 클라이언트 측에서 암호화할 수 있다.
- DynamoDB 전역 테이블과 결합하면, 클라이언트 측으로 암호화된 데이터가 다른 리전으로 복제된다.
- 다중 리전 키를 사용하고 DynamoDB 전역 테이블과 동일한 리전에 복제된 경우, 해당 리전의 클라이언트는 자신의 리전에서 다중 리전 키를 사용해 KMS에 로컬 API 호출을 보내 해당 속성을 복호화한다. 이는 지연 시간을 단축시킬 수 있다.
- 클라이언트 측 암호화를 사용하면 특정 필드를 보호하고, API 키 액세스 권한이 있는 클라이언트만 복호화할 수 있다.
Global Aurora and KMS Multi-Region Keys Client-Side encryption
- AWS Encryption SDK를 사용하여 Aurora 테이블에서 특정 속성을 클라이언트 측에서 암호화할 수 있다.
- Aurora Global Tables과 결합하면 클라이언트 측으로 암호화된 데이터가 다른 리전으로 복제된다.
- 다중 리전 키를 사용하고 Global Aurora DB와 동일한 리전에 복제된 경우, 해당 리전의 클라이언트는 자신의 리전에서 다중 리전 키를 사용해 KMS에 로컬 API 호출을 보내 해당 속성을 복호화한다. 이는 지연 시간을 단축시킬 수 있다.
- 클라이언트 측 암호화를 사용하면 특정 필드를 보호하고, API 키 액세스 권한이 있는 클라이언트만 복호화할 수 있다. 또한 DB 관리자로부터도 특정 필드를 보호할 수 있다.
S3 Replication Encryption Considerations
- 한 버킷에서 다른 버킷으로 S3 복제를 활성화하면 암호화되지 않은 객체와 SS3-S3로 암호화된 객체가 기본적으로 복제된다.
- SSE-C (고객 제공 키)로 암호화된 객체는 절대로 복제되지 않는다.
- SSE-KMS로 암호화된 객체의 경우 옵션을 활성화해야 한다.
- 대상 버킷 내에서 객체를 암호화할 KMS 키를 지정
- 대상 키를 위한 KMS 키 정책을 조정
- 소스 KMS 키에 대해
kms:Decrypt
및 대상 KMS 키에 대해 kms:Encrypt
를 사용하는 IAM 역할이 필요
- KMS 스로틀링 오류가 발생할 수 있으며, 이 경우 서비스 할당량을 늘리도록 요청
- 공식 문서에 따르면 S3 복제에 다중 리전 키를 사용할 수 있으나, 현재는 Amazon S3 서비스에서 독립 키로 취급하고 있으므로 객체는 여전히 복호화될 것이고 다중 리전 키인 경우에도 동일한 키로 암호화된다.
AMI Sharing Process Encrypted via KMS
- 소스 계정의 AMI는 소스 계정의 KMS 키로 암호화된다.
- 대상 AWS 계정에 해당하는 시작 권한을 추가하기 위해 이미지 속성을 수정해야 한다. - 특정 대상인 AWS 계정 ID 추가
- AMI가 참조하는 스냅샷을 암호화하는 데 사용된 KMS 키를 대상 계정 또는 IAM 역할과 공유해야 한다.
- 대상 계정의 IAM 역할/사용자는
DescribeKey
, ReEncrypt
, CreateGrant
, Decrypt
권한을 갖고 있어야 한다.
- (선택 사항) AMI에서 EC2 인스턴스를 시작할 때, 대상 계정은 볼륨을 다시 암호화하기 위해 자체 계정의 새로운 KMS 키를 지정할 수 있다.
SSM Parameter Store
- 구성(configuration) 및 암호를 위한 보안 스토리지
- 선택적으로 KMS 서비스를 사용하여 원할한 암호화 가능
- 서버리스, 확장성, 내구성이 뛰어나며 쉬운 SDK 제공
- 구성 및 암호의 버전 추적
- IAM을 통한 보안 기능
- Amazon EventBridge를 사용한 알림 기능
- CloudFormation과의 통합
SSM Parameter Store Hierarchy
아래의 예시를 보면 구조화를 통해 IAM 정책을 간소화하여 애플리케이션이 /my-department/ 혹은 my-app/ 전체 경로에, 혹은 my-department/ 혹은 my-app/의 특정 경로로만 액세스할 수 있도록 함.
- 레퍼런스를 사용해 Parameter Store로 Secret Manager의 암호에 액세스할 수 있음
- /aws/reference/secretsmanager/secret_ID_in_Secrets_Manager
- AWS에서 발행하는 퍼블릭 매개변수를 사용할 수 있음
- /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 (public)
- 특정 리전에서 Amazon Linux2의 최신 AMI를 찾으려고 할 때 API 호출 대신 Parameter Store를 사용할 수 있음
Standard and advanced parameter tiers
Parameters Policies (for advanced parameters)
- 파라미터 정책은 SSM 파라미터 스토어에서 고급 파라미터에 추가적인 제어와 권한을 할당하는 기능이다.
- TTL (만료 기한): 비밀번호와 같은 민감한 데이터를 자동으로 무효화하여 지정된 시간이 지난 후에 정기적으로 업데이트하거나 삭제할 수 있도록 한다.
- 다중 정책 할당: 파라미터에 여러 정책을 할당할 수 있다. 이를 통해 조직 내의 다른 사용자 또는 그룹에 대해 서로 다른 권한과 접근 제어를 정의할 수 있다.
AWS Secrets Manager
- 암호를 저장하는 최신 서비스
- X일마다 강제로 암호를 교체하는 기능이 있음
- 교체할 암호 강제 생성 및 자동화 기능 (Lambda 함수 사용)
- Amazon RDS와 통합 가능 (MySQL, PostgreSQL, Aurora)
- KMS를 사용한 암호화
AWS Secrets Manager는 주로 RDS와 같은 서비스와의 통합을 위해 설계되었으며, 비밀 정보의 안전한 저장과 교체를 간편하게 관리할 수 있는 강력한 도구이다.
Multi-Region Secrets
- 여러 리전간의 암호 복제
- Secret Manager 서비스가 기본 암호화와 동기화된 읽기 전용 복제본을 유지함
- 읽기 전용 복제본을 독립 실행형 암호로 승격할 수 있음
- 사용 사례: 다중 리전 애플리케이션, 재해 복구 전략, 다중 리전 데이터베이스 등
AWS Certificate Manager (ACM)
- TLS 인증서를 AWS에서 프로비저닝, 관리, 및 배포할 수 있는 서비스
- 웹사이트의 전송 중 암호화를 위한 인증서를 제공 (HTTPS)
- 퍼블릭 및 프라이빗 TSL 인증서 모두 지원
- 퍼블릭 TLS 인증서는 무료로 제공됨
- TLS 인증서 자동 갱신 기능
- 여러 AWS 서비스와 통합 가능
- Elastic Load Balancer (CLB, ALB, NLB)
- CloudFront 배포
- API Gateway의 모든 API
- EC2에서는 ACM 사용 불가 (인증서 추출 불가능)
ACM – Requesting Public Certificates
- 인증서에 포함할 도메인 이름 목록 작성
- 완전한 도메인 이름 (FQDN): corp.example.com
- 와일드카드 도메인: *.example.com
- 유효성 검증 방법 선택: DNS 유효성 검증 또는 이메일 유효성 검증
- 자동화를 위해서는 DNS 유효성 검증이 선호됨
- 이메일 유효성 검증은 WHOIS 데이터베이스의 연락처 이메일로 이메일을 발송
- DNS 유효성 검증은 CNAME 레코드를 DNS 구성에 활용 (예: Route 53)
- 검증을 마치기 까지 몇 시간이 걸릴 수 있음
- 퍼블릭 인증서는 자동 갱신됨
- ACM은 ACM에서 생성한 인증서를 만료 60일 전에 자동으로 갱신
ACM – Importing Public Certificates
- ACM 외부에서 인증서를 생성한 후 가져올 수 있는 옵션
- 자동 갱신이 불가능하므로 만료 전에 새로운 인증서를 가져와야 함
- ACM은 만료 45일 전부터 매일 만료 이벤트를 전송
- 며칠 전부터 알려줄지는 설정 가능
- 이벤트는 EventBridge에 표시됨
- AWS Config에는
acm-certificate-expiration-check
라는 관리되는 규칙이 있는데, 만료 예정인 인증서를 확인할 수 있음 (configurable number of days)
ACM – Integration with ALB
ACM – Integration with API Gateway
API Gateway Endpoint Types
- 엣지 최적화 (Edge-Optimized) - 기본값: 글로벌 클라이언트를 위한 유형
- CloudFront 엣지 로케이션으로 요청을 라우팅 (지연 시간 줄이는 방법)
- 하나의 리전에만 있는 API Gateway로 보내는 경우
- 리전(Regional):
- 클라이언트가 API Gateway와 같은 리전에 있는 경우
- CloudFront는 사용할 수 없지만 자체 CloudFront 배포를 생성하여 캐싱 및 배포 전략 제어
- 프라이빗:
- 인터페이스 VPC 엔드포인트 (ENI)를 통해 VPC 내부에만 액세스 가능
- 액세스를 정의하는 리소스 정책 필요
ACM은 엣지 최적화 및 리전 엔드포인트에 적합하다.
- ACM을 API Gateway와 통합하기 위해서는 API Gateway에 사용자 지정 도메인 이름(Custom Domain Name)이라는 리소스 생성
- 엣지 최적화 (기본값): 글로벌 클라이언트를 위한 유형
- TLS 인증서가 CloudFront 배포에 연결되기 때문에 TLS 인증서와 CloudFront는 반드시 같은 리전에 생성되어야 한다.
- 이후 CNAME이나 별칭(A-Alias) 레코드를 설정하여 사용자의 DNS를 가리키도록 설정한다.
- 리전:
- TLS 인증서를 API Gateway에 가져올 때에는 같은 리전에 있어야 한다.
- 이후 CNAME이나 별칭(A-Alias) 레코드를 설정하여 사용자의 DNS를 가리키도록 설정한다.
AWS WAF – Web Application Firewall
- 주로 7계층 (Layer 7)에서 일어나는 웹 취약점 공격으로부터 웹 애플리케이션을 보호한다.
- Layer 7는 HTTP를 의미한다. (Layer 4: TCP/UDP)
- 다양한 AWS 서비스에 배포 가능
- Application Load Balancer
- API Gateway
- CloudFront
- AppSync GraphQL API
- Cognito User Pool
- 웹 액세스 제어 목록 (Web Access Control List, Web ACL)은 다음과 같은 규칙들로 정의된다.
- IP Set: 최대 10,000개의 IP 주소 - 더 많은 IP 주소를 위해서는 여러개의 규칙 사용
- HTTP 헤더, HTTP 본문 또는 URI 문자열: 일반적인 공격인 SQL 인젝션(SQL injection)과 Cross-Site Scripting (XSS)로부터 보호하기 위해 HTTP 헤더, HTTP 본문 또는 URI 문자열을 기준으로 필터링하는 기능을 제공
- 용량 제약
- 지역 일치(geo-match): 특정 국가에서의 액세스 차단
- 속도 기반 규칙 (Rate-based rules): DDoS 공격으로부터 보호하기 위한 기능을 제공한다. 이를 통해 초당 요청 횟수 등의 제한을 설정하여 공격을 탐지하고 차단할 수 있습니다.
- 웹 ACL은 일반적으로 리전별로 적용되는데 CloudFront의 경우에는 전역적으로 적용된다.
- 규칙 그룹(Rule Group)은 재사용 가능한 규칙 세트로서 Web ACL에 추가할 수 있는 기능을 제공
WAF – Fixed IP while using WAF with a Load Balancer
- WAF는 네트워크 로드 밸런서(Network Load Balancer, Layer 4)를 지원하지 않음
- 따라서 WAF를 제공하려면 애플리케이션 로드 밸런서가 있어야 함
- 하지만 애플리케이션 로드밸런서는 고정 IP가 없음
- 이 문제는 AWS Global Accelerator로 고정 IP를 할당받은 다음 ALB에서 AWS를 활성화하면 됨
AWS Shield: protect from DDoS attack
- DDos: Distributed Denial of Service, 분산 서비스 거부 공격 - 인프라에 동시에 엄청난 양의 요청이 세계 곳곳의 여러 컴퓨터에서 유입되는 공격, 인프라에 과부하를 일으켜 사용자들에게 서비스를 제공할 수 없게 만드는 것이 목적
- AWS Shield Standard
- 모든 AWS 고객에게 자동으로 활성화되어있는 무료 서비스
- SYN/UDP Floods, 반사 공격 및 기타 3/4계층 공격과 같은 공격으로부터 보호 제공
- AWS Shield Advanced
- DDoS 완화 서비스 ($3,000/month/organization)
- Amazon EC2, Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, Route 53을 더 정교한 공격으로부터 보호
- AWS DDos 대응팀 (DDos response team, DRP) 항시 대기
- DDoS로 인한 사용량 급증 시 요금 상승 방지
- Shield Advanced는 자동 애플리케이션 계층 DDoS 완화를 제공하여 자동으로 AWS WAF 규칙을 생성, 평가 및 배포하여 7계층 공격을 완화함
AWS Firewall Manager
- AWS 조직에 있는 모든 계정의 방화벽 규칙을 관리하는 서비스
- 보안 정책: 공통 보안 규칙의 집합
- WAF 규칙: Application Load Balancer, API Gateways, CloudFront
- AWS Shield Advanced: ALB, CLB, NLB, Elastic IP, CloudFront
- EC2, Application Load Balancer 및 VPC의 ENI 리소스를 위한 보안 그룹
- AWS Network Firewall (VPC 수준)
- Amazon Route 53 Resolver DNS Firewall
- 정책은 리전 수준에서 생성
- AWS Firewall Manager에서 정의한 규칙은 새로운 리소스가 생성될 때 자동으로 적용된다. 이를 통해 규정 준수를 위한 모든 계정 및 미래의 계정에서 일관된 보안 규칙을 유지할 수 있다.
WAF vs. Firewall Manager vs. Shield
WAF, Shield, Firewall Manager는 모두 포괄적인 계정 보호를 위한 서비스이다.
- WAF에서는 웹 ACL 규칙을 정의
- 리소스에 대한 세분화된 보호를 위해 WAF 단독으로 사용하는 것이 올바른 선택
- 여러 계정에서 WAF를 사용하고, WAF 구성을 가속하고, 새로운 리소스의 보호를 자동화하려면 Firewall Manager로 WAF 규칙 관리
- Firewall Manager는 이러한 규칙들을 모든 계정과 모든 리소스에 자동으로 적용해주기 때문
- Shield Advanced는 AWS WAF 기능 외에도 더 많은 기능을 제공 - Shield Response Team (SRT)로부터 전용 지원 및 고급 보고서 제공, WAF 규칙 자동 생성 등
- 디도스 공격을 자주 받는다면 Shield Advanced를 사용하는 것이 좋음
- Firewall Manager는 모든 계정에 Shield Advanced를 배포하는데 도움
DDos Protection Best Practice
Edge Location Mitigation
- BP1 - CloudFront
- CloudFront를 사용하여 웹 애플리케이션을 엣지에서 제공
- SYN Flood나 UDP 반사 등의 일반적인 DDoS 공격은 Shield 설정으로 막을 수 있음
- BP1 - Global Accelerator
- Global Accelerator를 통해 전 세계의 엣지에서 애플리케이션에 접근
- DDoS 보호를 위해 AWS Shield와 통합
- CloudFront가 백엔드와 호환되지 않는 경우 유용함
- BP3 - Route 53
- 엣지에 도메인 이름 변환을 글로벌로 설정
- DNS에도 DDos 보호 매커니즘을 적용할 수 있음
Best pratices for DDoS mitigation
- 인프라 레이어 방어 (BP1, BP3, BP6)
- CloudFront, Global Accelerator, Route 53, Elastic Load Balancing은 높은 트래픽으로부터 Amazon EC2를 보호
- 이 서비스들을 사용하면 EC2 인스턴스에 도달하기도 전에 트래필을 관리할 수 있음
- Amazon EC2와 오토 스케일링 (BP7)
- 플래시 크라우드 또는 DDos와 같은 급격한 트래픽 급증 시 확장을 지원함
- Elastic Load Balancing (BP6)
- Elastic Load Balancing은 트래픽이 증가함에 따라 확장되며, 트래픽을 여러 EC2 인스턴스에 분산
Application Layer Defense
- 악성 웹 요청 감지 및 필터링 (BP1, BP2)
- CloudFront는 정적 콘텐츠를 캐시하고 엣지 위치에서 제공함으로써 백엔드를 보호
- AWS WAF는 CloudFront와 Application Load Balancer 위에서 사용되며, 요청 서명에 기반하여 요청을 필터링하고 차단
- WAF의 속도 기반 규칙은 악성 사용자의 IP를 자동으로 차단
- WAF에서 관리되는 규칙을 사용하여 IP 평판에 기반한 공격을 차단하거나 익명 IP를 차단
- CloudFront는 특정 지리적 위치를 차단
- Shield Advanced (BP1, BP2, BP6)
- Shield Advanced를 활성화하면 자동으로 WAF 규칙을 자동으로 생성, 평가 및 배포하여 7계층 공격을 완화함
Attack surface reduction
- AWS 리소스 Obfuscating (BP1, BP4, BP6)
- CloudFront, API Gateway, Elastic Load Balancing을 사용하여 백엔드 리소스 (Lambda 함수, EC2 인스턴스) 숨기기
- 보안 그룹 및 네트워크 ACL (BP5)
- 보안 그룹과 네트워크 ACL등을 사용하여 서브넷이나 ENI 수준에서 특정 IP를 기반으로 트래픽을 필터링
- Elastic IP는 AWS Shield Advanced로 보호할 수 있음
- API 엔드포인트 보호 (BP4)
- API Gateway를 사용하여 EC2, Lambda 및 기타 리소스 숨기기
- 엣지 최적화 모드 또는 CloudFront에 리전 모드를 더하여 사용 (DDoS에 대한 제어 기능 강화)
- WAF + API Gateway: 버스트 제한, 헤더 필터링, API 키 사용 등을 활용
Amazon GuardDuty
- AWS 계정을 보호하기 위한 지능형 위협 탐지 서비스
- 머신 러닝 알고리즘을 사용하여 이상 탐지를 수행하고 타사 테이터를 활용하여 위협을 탐지함
- 소프트웨어 설치 필요 없이 클릭 한 번으로 활성화할 수 있음 (30일 무료 평가판 제공)
- 입력 데이터는 다음과 같은 정보를 포함함:
- CloudTrail 이벤트 로그: 비정상적인 API 호출, 무단 배포 탐지
- CloudTrail 관리 이벤트: VPC 서브넷 생성, 트레일 생성 등
- CloudTrail S3 데이터 이벤트: get object, list objects, delete object 등
- VPC 플로우 로그: 비정상적인 인터넷 트래픽, 비정상적인 IP 주소 등
- DNS 로그: 인코딩된 데이터를 전송할 EC2 인스턴스가 손상되었는지 확인
- Kubernetes 감사 로그: 수상한 활동 및 잠재적인 EKS 클러스터 손상 감지
- 이벤트 발견 시 알림을 받기 위해 CloudWatch 이벤트 규칙을 설정할 수 있음
- 작업을 수행할 AWS Lambda 또는 이메일을 보낼 SNS를 대상으로 CloudWatch 이벤트 규칙 설정 가능
- 암호화폐 공격에 대한 보호 제공
Amazon Inspector
- 자동화된 보안 평가 도구
- EC2 인스턴스를 대상으로 자동 보안 평가 수행
- AWS Systems Manager (SSM) 에이전트를 활용하여 실행
- 의도하지 않은 네트워크 접근 가능성에 대해 분석
- 실행중인 운영체제에서 알려진 취약점을 분석
- Amazon ECR로 컨테이너 이미지를 푸시할 때
- Lambda 함수가 배포될 때
- 함수 코드 및 패키지 종속성에서 소프트웨어 취약성 분석
- Amazon Inspector가 작업을 완료하면 AWS Security Hub에 보고
- 발견된 이슈는 Amazon EventBridge로 전송할 수 있음
What does Amazon Inspector evaluate?
- Remember: Amazon Inspector는 실행중인 EC2 인스턴스, Amazon ECR의 컨테이너 이미지, Lambda 함수에만 사용된다.
- 지속적으로 스캔을 수행하고, 필요한 경우에만 평가를 진행
- 패키지 취약점 (EC2, ECR & Lambda): EC2 인스턴스, Amazon ECR에 저장된 컨테이너 이미지, Lambda 함수에 설치된 패키지의 취약점을 스캔하여 취약성 데이터베이스 (CVE)와 비교한다.
- 네트워크 접근성 (EC2): Amazon Inspector는 EC2 인스턴스의 네트워크 접근성을 평가하며, 의도치 않게 노출된 서비스나 보안 위험이 있는 접근성을 확인
- Amazon Inspector는 모든 취약점에 대해 위험 점수를 할당하여 우선순위를 정한다.
AWS Macie
- 완전 관리형의 데이터 보안 및 개인 정보 보호 서비스
- 머신 러닝과 패턴 일치를 사용하여 AWS의 민감한 데이터를 검색하고 보호한다.
- 개인 식별 정보 (PII)와 같은 민감한 데이터를 식별하고 경고하여 알려주어 데이터를 보호한다.