[AWS] AWS Security & Encryption: KMS, Encryption SDK, SSM Parameter Store

Gaeun·2023년 5월 23일
0

참고 자료

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는 리전에 따라 범위가 지정된다. 다른 리전으로 복사하려면 몇 가지 단계를 거쳐야 한다.

  1. EBS 볼륨 스냅샷 생성
  2. 암호화된 스냅샷에서 스냅샷을 생성하면 생성된 스냅샷 또한 동일한 KMS 키로 암호화 됨
  3. 다른 리전으로 스냅샷을 복사하기 위해 다른 KMS 키를 사용하여 스냅샷을 다시 암호화해야 하는데 이는 AWS에서 자동으로 처리함 - 동일한 KMS 키가 서로 다른 리전에 있을 수 없음
  4. KMS로 스냅샷을 자체 EBS 볼륨으로 복원하고, KMS 키를 다른 리전으로 복원함

KMS Key Policies

  • KMS 키에 대한 액세스를 제어하는데 사용되는 정책. S3 버킷 정책과 유사함
  • 차이점: KMS 키에 KMS 키 정책이 없으면 누구도 액세스할 수 없음
  • 기본 KMS 키 정책:
    • 사용자 지정 키 정책을 제공하지 않을 시 생성됨
    • 기본적으로 계정의 모든 사람이 키에 액세스하도록 허용하는 것
      • 루트 사용자(전체 AWS 계정)에 대한 키의 완전한 액세스 권한
  • 사용자 지정 KMS 키 정책
    • 사용자 및 역할 정의: KMS 키에 액세스할 수 있는 사용자, 역할 지정
    • 키를 관리할 수 있는 사용자 정의
    • KMS 키의 교차 계정 액세스에 유용함

Copying Snapshots across accounts

  1. 자체 KMS키로 암호화한 스냅샷 생성
  2. 교차 계정 액세스 권한 부여를 위해 KMS 키 정책을 연결
  3. 암호화된 스냅샷을 대상 계정에 공유
  4. (대상 계정에서) 스냅샷의 복사본을 생성하고, 계정 내 CMK로 암호화 함
  5. 스냅샷으로부터 볼륨을 생성함

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

  1. 소스 계정의 AMI는 소스 계정의 KMS 키로 암호화된다.
  2. 대상 AWS 계정에 해당하는 시작 권한을 추가하기 위해 이미지 속성을 수정해야 한다. - 특정 대상인 AWS 계정 ID 추가
  3. AMI가 참조하는 스냅샷을 암호화하는 데 사용된 KMS 키를 대상 계정 또는 IAM 역할과 공유해야 한다.
  4. 대상 계정의 IAM 역할/사용자는 DescribeKey, ReEncrypt, CreateGrant, Decrypt 권한을 갖고 있어야 한다.
  5. (선택 사항) 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

  1. 인증서에 포함할 도메인 이름 목록 작성
  • 완전한 도메인 이름 (FQDN): corp.example.com
  • 와일드카드 도메인: *.example.com
  1. 유효성 검증 방법 선택: DNS 유효성 검증 또는 이메일 유효성 검증
  • 자동화를 위해서는 DNS 유효성 검증이 선호됨
  • 이메일 유효성 검증은 WHOIS 데이터베이스의 연락처 이메일로 이메일을 발송
  • DNS 유효성 검증은 CNAME 레코드를 DNS 구성에 활용 (예: Route 53)
  1. 검증을 마치기 까지 몇 시간이 걸릴 수 있음
  2. 퍼블릭 인증서는 자동 갱신됨
  • 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는 반드시 같은 리전에 생성되어야 한다.
      • 위의 예시에서는 us-east-1
    • 이후 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)와 같은 민감한 데이터를 식별하고 경고하여 알려주어 데이터를 보호한다.

profile
🌱 새싹 개발자의 고군분투 코딩 일기

0개의 댓글