AWS[AWS Security & Encryption]

정지범·2024년 1월 23일
Encryption SDKKMSSSM Parameter Store
0

aws

목록 보기
22/26

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

2.유효성 검증 방법 선택: DNS 유효성 검증 또는 이메일 유효성 검증

  • 자동화를 위해서는 DNS 유효성 검증이 선호됨
  • 이메일 유효성 검증은 WHOIS 데이터베이스의 연락처 이메일로 이메일을 발송
  • DNS 유효성 검증은 CNAME 레코드를 DNS 구성에 활용 (예: Route 53)

3.검증을 마치기 까지 몇 시간이 걸릴 수 있음
4.퍼블릭 인증서는 자동 갱신됨

  • 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
정지범
안녕하세요
이전 포스트

AWS[IAM-고급]

다음 포스트

AWS[Virtual Private Cloud (VPC)]

0개의 댓글