AWS 보안 및 암호화

시험에서 꽤 중요한 부분으로 다양한 보안 서비스가 통합된다

전송 중 암호화 (SSL)

• 민감한 내용을 사용할 때 패킷 단위 암호화가 필요하다.
  • 전송하는 클라이언트와 서버만 해석할 수 있다
• SSL 인증서가 암호화한다(HTTPS)
• AWS 서비스엔 HTTPS 엔드포인트가 지원되어 전송 중 암호화를 지원한다
• 네트워크가 중간자를 거쳐가기 때문에 중간자 공격으로부터 보호된다

 

서버사이드 암호화

• 데이터가 서버에 수신된 후 암호화
• 서버는 데이터를 디스크(EBS)에 저장해야하는데 암호화된 형태로 저장한다
• 클라이언트로 다시 전송되기전에 복호화
• 데이터 키를 통해 암호/복호화 되며 키는 KMS같은 곳에 따로 저장된다
• 따라서 서버는 KMS와 통신이 가능해야한다

 

AWS KMS(Key Management Service)

• AWS 서비스로 암호화하면 주로 KMS를 통한 암호화
• AWS에서 암호화 키를 관리
• IAM과 완전히 통합되고 암호화 데이터에 관한 엑세스를 더 쉽게 할 수 있도록 제어
• CloudTrail을 통해 키를 사용하기 위해 호출한 모든 API를 검사할 수 있다(중요)
• EBS, S3, RDS, SSM 등 원활하게 통합될 수 있다
• 암호 관련 데이터는 절대로 평문으로 남겨서는 안된다. 특히 코드
  • KMS를 사용하기 위해 API 호출할 수 있다(SDK, CLI)
  • KMS 키를 사용하면 어떤 파일이든 암호화 할 수 있고 암호화된 파일은 코드나 환경변수에 저장할 수 있다

 

KMS Keys Types

Symmetric(대칭키 AES-256)

• 단일 암호화키만 있기 때문에 대부분의 KMS와 통합되는 AWS 서비스에서 사용한다
• 생성하거나 사용하면 키 자체에는 절대로 엑세스 불가능하며 활용하거나 사용하려면 KMS API가 필요하다

 

Asymmetric(비대칭키 RSA&ECC)

• 퍼블릭과 프라이빗키로 구성
• 암호화 복호화 작업 할당 및 검증에 사용
• 퍼블릭키는 다운로드할 수 있지만 프라이빗키에는 엑세스가 불가능(API 호출하면 가능)
• AWS 클라우드 외부에서 암호화 할 때 사용한다

 

여러 유형의 KMS 키

AWS Managed Key(AWS 관리형 키)

• aws/rds 같이 저장되며 무료이다.
• AWS에서 완전 관리되며 특정 서비스에 관한 저장 데이터 암호화에 사용

 

Customer Managed Keys(CMK 고객 관리형 키)

• 매달 1달러
• 자체 키 구성 요소를 KMS로 가져올 수 있다(Key Import가 가능)

• KMS로 호출하는 모든 API도 비용을 지불해야함 ($0.03 / 10000(1만건) calls)

 

Automatic Key rotation

• AWS 자동 관리형 키를 사용하면 1년에 한 번씩 교체된다.
• 고객 관리형 키를 사용하더라도 키가 교체되도록 활성화해야하며 활성화되면 1년에 한번씩 자동으로 수정
• KMS Import key를 사용하면 수동으로만 키를 교체 가능 → 키 교체하려면 키 별칭을 사용해야함

 

Copying Snapshots across regions

• KMS는 리전에 따라 범위가 지정된다
• 동일한 키가 서로 다른 리전에 있을 수 없다
• 스냅샷을 위해 EBS 볼륨이 Key A를 통해 암호화되고 이후 Key B를 통해 암호화 된다(이 부분은 AWS가 자동 처리)
• KMS가 Key B를 통해 스냅샷을 자동으로 복원해서 리전간 복제를 시켜준다

 

KMS Key Policies

• KMS 키에 관한 엑세스를 제어하는 것
• KMS키에 KMS 키 정책이 없다면 누구도 엑세스는 불가능하다

 

Default KMS Key Policy

• 특정한 키 정책을 만들지 않으면 생성
• 기본적으로 계정의 모든 사람이 키에 엑세스하도록 허용
  • 사용자 또는 키 정책의 엑세스를 허용하는 IAM 정책이 있으면 된다

Custom KMS Key Policy

• KMS 키에 엑세스할 수 있는 사용자 또는 역할을 정의
• 키 관리자를 정의할 수 있는 사용자 지정 키 정책
• KSM 키에 관한 교차 계정 엑세스시 매우 유용
• 다른 계정이 KMS키를 사용하도록 권한을 부여
  • 계정간 스냅샷을 복사할 때 사용

 

Copying Snapshots across accounts(계정간 스냅샷 복사)

• 자체 KMS 키로 암호화한 스냅샷을 생성 → 고객 관리형 키
• 교차 계정 엑세스 권한 부여를 위해 KMS 키 정책을 연결
• 스냅샷을 대상 계정에 공유하면 대상 계정에서 스냅샷 복제본을 생성하고 기존과 다른 고객 관리형 키로 암호화
• 이후 자체 암호화 후 스냅샷에서 볼륨을 생성

 

KMS Multi Region Keys(다중 리전)

KMS에는 다중 리전 키를 둘 수 있고 선택된 한 리전이 기본키를 갖는다

• 기본키로부터 키 구성요소가 복제된다 → 다른 리전도 동일한 키를 갖는다
  • 키 ID가 완전히 똑같다
• 다른 AWS 리전에서 사용할 수 있는 KMS 키 세트로 서로 교차해서 사용 가능
• 한 리전에서 암호화한 다음 다른 리전에서 복호화가 가능
• 자동 교체 기능을 활성화하면 교체됐을 때 다른 리전에도 복제된다

핵심은 한 리전에서 암호화하고 다른 리전에서 복호화해 다음 리전으로 복제할 때나 교차리전 API 호출될 때 재암호화가 필요없다는 것이다.

 

또한 글로벌하게 사용할 수 있는게 아닌 기본키 + 복제본으로 구성됨

 

각 다중 리전 키는 자체 키 정책 등으로 각각 독립적으로 관리된다.

특정 사용 사례를 제외하곤 추천되지 않는다

→ 전역 클라이언트 측 암호화, Global DynamoDB, AuroraDB 암호시 필요

 

Aurora DB 전역 테이블과 DynamoDB 전역 테이블에서 클라이언트측 암호화 다중리전키를 사용하는 이유

• 저장된 데이터만 암호화하는게 아니라 테이블의 속성 까지 암호화하여 특정 클라이언트만 사용할 수 있게 한다(DB관리자도 사용 불가능) → Amazon DynamoDB 암호화 클라이언트를 사용한다 → 사회 보장 번호를 암호화 Social Security number
• 클라이언트 측 암호화를 사용하면 특정 필드나 속성을 보호할 수 있다
  • 이건 서버에서 권한이 없으면 암호화 데이터 접근이 불가능하며 이후 클라이언트 쪽에서 암호화된 데이터를 받아 복호화한다
• Aurora, Dynamo DB 구조도 똑같다

 

s3 암호화된 복제

• 한 버킷에서 다른 버킷으로 s3 복제를 활성화하면 암호화되지 않은 객체와 SSE-S3로 암호화된 객체가 기본으로 복제된다
  • SSE-C로 객체를 암호화하면 복제 되지 않음 → 항상 키를 제공해야함
• SSE-KMS로 암호화된 객체도 기본적으로 복제되지 않고 복제하려면 옵션 활성화 필요
  • 어떤 KMS키로 대상 버킷의 객체를 암호화할껀지 지정해야함
  • 대상이 되는 키(Target Key)를 위한 KMS key policy를 적용해야함
  • s3 복제 서비스를 허용하는 IAM Role을 활성화
  • 소스 버킷의 데이터를 먼저 복호화하도록 한 뒤 타겟 키로 다시 암호화
  • 이렇게 하면 복제가 활성화되지만 스로틀링 오류가 발생한 경우는 서비스 할당량을 요청해야 한다
• S3 복제에 다중 리전 키를 사용할 순 있으나 s3 서비스에서 독립 키로 취급하고 있으므로 객체는 여전히 복호화될 것이고, 다중 리전 키를 사용해 동일한 키로 암호화될 것이다..

 

KMS로 암호화된 AMI 공유 프로세스

• AMI를 다른 계정과 공유하려고 하는데 AMI는 KMS로 암호화되어 있다
• 어떻게 A 계정의 AMI에서 B 계정의 인스턴스로 시작할 수 있을까?
  • Launch Permission으로 AMI 속성을 수정 필요 → B 계정에서 AMI를 시작할 수 있도록 허용
  • 시작 권한을 수정하여 특정 대상인 AWS 계정 ID를 추가한다
  • 이후 KMS 키 또한 공유해야하는데, 일반적으로 키 정책을 통해 실행됨
  • 공유되면 B 계정에서 KMS키와 AMI를 모두 사용할 수 있는 충분한 권한을 가진 IAM 역할이나 IAM 사용자를 만든다
    • 이때 키 관련 API 호출 권한을 허용 권한을 설정
  • 이후 ec2를 시작하면 되고 자체 계정에서 볼륨을 재암호화 가능

 

SSM Parameter Store

• 구성 및 암호를 위한 보안 스토리지
• 구성을 암호화할지 선택할 수 있어 KMS 서비스를 이용해 암호를 만들 수 있다
• 서버리스 확장성 내구성 SDK또한 유용
• 파라미터를 업데이트 할 떄 구성과 암호의 버전을 추적 가능
• IAM을 통한 보안 제공
• EventBridge를 통한 알림을 받을 수 있다
• CloudFormation과 통합 가능
  • CloudFormation이 ParameterStore의 매개변수를 스택의 입력 매개변수로 활용 가능

 

SSM Parameter Store Hierarchy(계층구조가 있는 파라미터 스토어)

원하는 방식으로 매개변수를 구조화 구조화를 통해 IAM 정책을 간단화하여 특정 경로에만 엑세스할 수 있도록 만들 수 있다.

람다를 통해 /dev 혹은 /prod 계층별로 접근이 가능하다

• /my-department/
  • my-app/
    • dev/
      • db-url
      • db-password
    • prod
      • db-url
      • db-password

 

Tier

Standard / advanced → 용량 차이와 파라미터 정책 적용 여부

 

Parameter Policies (advanced 파라미터의 경우)

• 매개변수 정책을 통해 TTL을 할당 가능
• 비밀번호등의 민감한 정보를 업데이트 또는 삭제하도록 강제
• 한번에 여러 정책 적용 가능

만료, EventBridge와 결합하여 만료 알림, 변경이 없다는 알림도 가능

 

AWS Secrets Manager

• 암호를 저장하는 최신 서비스 → SSM Parameter와는 다르다
• X일마다 강제로 암호 교체하는 기능이 있어 암호관리를 더 효율적으로 가능
• 암호를 강제 생성 및 자동화 → 새 암호를 생성할 Lambda 함수를 정의해야한다
• 다양한 서비스와도 잘 통합됨(RDS, MySQL, Aurora)
  • AWS 서비스 외에도 여러 데이터베이스에도 즉시 통합 가능
• DB에 접근하는 암호가 알아서 저장되고 교체 등도 가능
• KMS를 통해 암호화

RDS와 Aurora의 통합 혹은 암호에 대한 내용이 나오면 AWS Secretes Manger를 알아야함

 

Secrets Manager - 다중 리전 암호

• 다중 AWS 리전에 암호를 복제할 수 있다
• Secrets Manager가 기본 암호와 동기화된 읽기 전용 복제본을 유지한다
  • 똑같은 암호가 복제됨
• 기본 리전에 문제가 생기면 복제본을 독립실행형 암호로 승격 가능
• 여러 리전에 암호가 저장되므로 다중 리전 앱을 구축하고 재해 복구 전략도 짤 수 있다
• 동일한 암호로 여러 리전 DB에 접근 가능

 

AWS Certificate Manager(ACM)

• TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포하게 해준다.
  • 웹사이트 전송 중 암호화 인증서(HTTPS)
• ALB를 ACM과 연결해 TLS 인증서를 ALB에서 직접 유지관리 하도록 할 수 있다.
• 퍼블릭/프라이빗 TLS 인증서를 모두 지원한다 (퍼블릭은 무료)
• 인증서를 자동 갱신하는 기능도 있다
• 여러 AWS와 통합되어있음
  • ELB에서 인증서를 불러올 수 있음
  • CloudFront 혹은 API Gateway에서도 사용 가능
• 주의해야할 점은 EC2 인스턴스에서는 사용이 불가능하다
  • 퍼블릭 인증서일 경우 추출이 불가(ec2에 대한 퍼블릭 인증서 생성 불가)

 

Requesting Public Certificates(퍼블릭 인증서가 요청되는 과정)

• 인증서에 포함할 도메인 이름을 리스트화
  • Fully Qualified Domain Name(FQDN): corp.example.com
  • Wildcard Domain: *.example.com
• 유효성 검증 방법
  • DNS 검증방법 → 자동화 가능
  • 이메일 검증방법 → ACM이 도메인에 등록된 연락처로 이메일을 보내서 인증서 요청 여부 확인
  • DNS 검증시 CNAME 레코드를 생성해 도메인 소유권을 증명해야함
    • Route53이 있다면 자동으로 ACM과 통합해 작업을 수행
• 유효성 검증이 완료되면 인증서 발행
• 퍼블릭 인증서가 자동 갱신으로 등록된다
  • ACM에서 스스로 생성된 모든 인증서를 만료 60일전에 자동 갱신

 

Importing Public Certificates(인증서 가져오기)

• 외부에서 생성된 인증서를 가져오는 옵션
• 자동 갱신은 불가능하기 때문에 만료되기 전에 인증서를 가져와야함
  • ACM 서비스가 만료 45일전부터 매일 만료 메시지를 EventBridge로 전송해준다
• Config로 만료된 인증서를 확인 후 규칙 위배되는 인증서를 이벤트로 똑같이 전송 가능
  • 만료기간이 얼마 안남았다는 자동 전송 기능이고 갱신해주지 않는다

 

ACM & ALB Integration

• HTTP → HTTPS로 리다이렉션 기능을 가진다

API Gateway - EndPoint Types

• Edge-optimized → 글로벌 클라이언트를 위함
  • CloudFront 엣지 로케이션으로 요청을 라우팅하여 지연을 줄인다
  • 이후 하나의 리전에 있는 게이트웨이로 전송
• Regional
  • 클라이언트와 같은 리전에 있는 경우 자체 CloudFront 배포를 생성하여 캐싱 및 배포 전략을 제어할 수 있다
• Private
  • VPC ENI를 통해서만 VPC 내부에만 엑세스, API Gateway 엑세스를 정의하는 리소스 정책이 필요하다

 

ACM & API Gateway Integration

• API Gateway에 사용자 지정 도메인이라는 리소스를 생성
• 엣지 최적화 엔드포인트
  • 요청이 CloudFront에서 라우팅
  • TLS 인증서가 CloudFront 배포에 연결되기 때문에 반드시 CloudFront 리전에 연결해야한다
  • 이후 CNAME 혹은 별칭(A-Alias)레코드를 설정하면 끝
• Regional
  • API Gateway와 리전이 같은 클라이언트를 위한 엔드포인트
  • TLS 인증서를 가져올땐 마찬가지로 같은 리전에 있어야함

 

AWS 리전 us-west-2에 메인 엣지 최적화 API Gateway를 생성했습니다. 이 엣지 최적화 API Gateway는 ap-southeast-1에 있는 하위 레벨 API Gateway로 트래픽을 전달합니다. 메인 API Gateway를 보호하기 위해 ACM 인증서를 연결하려고 합니다. 어느 AWS 리전에서 ACM 인증서를 생성해야 합니까?

 

us-west-2가 아닌 us--east-1이라고 한다

 

엣지 최적화 API Gateway는 배후에서 AWS가 관리하는 사용자 지정 CloudFront 배포를 사용하여 CloudFront 엣지 로케이션을 거쳐 전 세계로 요청을 라우팅하기 때문에 ACM 인증서는 us-east-1 리전에 생성해야 합니다.

 

 

AWS WAF - Web Application Firewall

• Layer 7에서 일어나는 일반적인 웹 취약점 공격으로부터 보호해준다
  • 7계층은 HTTP를 의미함
• 배포는 ALB, API Gateway, CloudFront, AppSync GraphQL API, Cognito User Pool에 할 수 있다
  • NLB 등엔 배포할 수 없다
• 웹 엑세스 제어 목록(ACL) 규칙을 정의해야한다
  • IP주소를 기반으로 필터링하는 규칙 - IP sets를 정의 가능하고 최대 10,000개의 IP주소 등록가능하다
  • HTTP 헤더와 body, URI 문자열을 조건으로 두어 SQL 주입, XSS 등의 공격 방어 가능
  • 용량에 제약을 걸 수 있다
  • Geo-match(특정 국가 허용/차단 리스트)
  • 속도 기반 규칙 → IP당 요청 횟수를 만들어 DDoS를 방지할 수 있다
• ACL은 리전에만 정의되며 CloudFront의 경우만 글로벌로 정의된다
• Rule Group이 있는데 여러 ACL에 추가할 수 있는 재사용 가능한 규칙 모음

 

적용 사례) 고정 IP + ALB + WAF

• WAF는 NLB를 지원하지 않는다 (NLB는 4계층에서만 작동)
• WAF를 제공하려면 ALB가 있어야한다
• Global Acclerator를 통해 고정 IP를 할당받아 ALB에서 WAF를 활성화
• ALB와 같은 리전에 적용시켜야한다

 

AWS Shield

• DDoS 공격으로부터 보호하기 위한 서비스
• Shield Standard
  • 무료 활성화
  • SYN/UDP Floods, Reflection Attacks, 다른 3/4계층 공격으로부터 보호해준다
• Advanced
  • 디도스 완화 서비스
  • 월 3,000달러로 정교한 디도스 공격을 막아준다
  • EC2, ELB, CloudFront, Global Accelerator, Route53을 막아줌
  • 디도스 대응 팀이 항시 대기하고 있어 공격받았을 때 지원을 받을 수 있다(DRP)
  • 디도스 공격으로 인한 요금 상승을 방지 가능
  • 자동 애플리케이션 계층 디도스 완화도 제공하며 자동으로 WAF 규칙을 생성, 평가, 배포하여 7계층 공격을 완화시킬 수 있다

 

AWS Firewall Manager

• AWS Organization에 있는 모든 계정간의 방화벽 규칙을 관리
  • 여러 계정의 규칙을 관리
• Security Policy → 보안 규칙에 대한 공용 셋을 정의 가능
  • ALB, API Gateway , CloudFront 등에 적용되는 WAF 규칙
  • Shield Advanced Rule(ALB, NLB Elastic IP, CloudFront)를 위한 규칙
  • EC2 애플리케이션 Load Balancer, ENI 리소스를 위한 VPC, 보안 그룹을 표준화 하는 보안 정책
  • AWS Network Firewall(VPC 레벨)
  • Route53 DNS Firewall
• 정책인 리전 수준에서 생성되며 조직에 등록된 모든 계정에 적용

모든 방화벽을 한 곳에서 관리할 수 있도록 도와준다

• 조직에서 ALB에 대한 WAF 규칙을 생성한 다음 새 ALB를 생성하는 경우 Firewall manager에서 자동으로 새 ALB에 기존 규칙을 넣어준다

 

WAF vs Firewall Manager vs Shield

• 세 가지 모두 포괄적인 계정 보호를 위한 서비스
• WAF에서는 웹 ACL 규칙을 생성하는데 리소스별 보호를 구성하는데 WAF가 적합
• 여러 계정간 WAF를 사용하고 WAF 구성을 가속화하고 새 리소스를 자동화하려면 Firewall Manager가 적합
• Shield 디도스 공격으로부터 보호, WAF 기능 외에도 더 많은 기능을 제공한다
  • 디도스 대응 팀, WAF 규칙 자동 생성 등의 기능을 추가로 이용 가능
• 디도스 공격을 자주 받는다면 Advanced가 선택지가 될 수 있고 이때 Firewall manager는 Shield Advanced 배포에도 도움을 준다

 

AWS에서 DDoS 보호와 모범사례

• BP1 - CloudFront
  • 엣지에서의 웹 애플리케이션 전송시
  • SYN Flood나 UDP 반사 공격과 같은 일반적인 DDoS공격을 Shield 설정으로 방어 가능
• BP1 - Global Accelerator
  • 전 세계에서 엣지를 통해 웹 엑세스할 수 있다
  • Shield와 통합되어 DDoS 보호 작업을 수행
  • CloudFront가 백엔드와 호환되지 않는 경우 DDoS 방어에 유용
  • 어떤 백엔드를 사용하든 CloudFront 혹은 Global Accelerator로 AWS 엣지에 완전 분산 가능
  • 엣지 로케이션을 디도스로부터 지킬 수 있다
• BP3 - Route 53
  • 엣지에 도메인 이름 변환을 글로벌로 설정하면 디도스 보호 메커니즘(Shield)를 활용 가능

 

디도스 완화 모범사례

• 인프라 계층 방어(BP1, BP3, BP6)
  • 높은 트래픽으로부터 ec2 보호 가능
  • Global Accelerator, Route 53, CloudFront, ELB 서비스 → 인스턴스에 도달하기전 트래픽 관리 가능
• 오토 스케일링(BP7)
  • 높은 트래픽이 도달한다고 해도 애플리케이션에서 도 큰 로드를 수용할 수 있도록 확장
• ELB
  • 여러 인스턴스간 트래픽 분산하여 관리 가능한 양만큼으로 처리할 수 있도록 한다

 

애플리케이션 계층 방어

• BP1, BP2로 악성 요청을 감지가 가능하다
  • CloudFront는 정적 컨텐츠 전송시 엣지 로케이션에서 전송함으로써 백엔드를 보호한다
  • ALB나 CloudFront에 WAF를 사용하여 요청 서명에 따라 요청을 필터링하거나 차단 가능
  • WAF 속도 기반 규칙을 사용하면 악성 사용자의 IP를 자동으로 차단 가능
  • 여러 관리형 규칙을 사용하면 추가적인 기능(익명 IP 차단)등을 사용 가능하다
  • CloudFront로는 특정 지역을 차단 가능하다
• CloudFront와 WAF는 관리형 서비스이기 때문에 사용자의 규칙에 따라 요청을 필터링 해준다
• Shield Advanced(BP1, BP2, BP6) → 자동으로 WAF 규칙을 생성하여 7계층 공격을 완화
• 악성 요청이 들어오지 못하도록 하거나 수를 최소화하는식으로 ec2 인스턴스를 보호

 

공격지점 줄이기(Attack surface reduction)

• 애플리케이션에서 사용되는 백엔드 AWS리소스는 사진 상 숨어있다(BP1, BP4, BP6)
• CloudFront, API Gateway, ELB를 사용
  • 백엔드 리소스를 숨길 수 있다
  • 해당 백엔드 리소스 앞에 다른 것들이 있기 때문에 람다함수인지, ECS, EC2인지 알 수 없다
• 보안그룹과 네트워크 ACL 등을 설정
  • 특정 IP의 트래픽을 필터링 가능하다
  • Elastic IP또한 AWS Shield Advanced로 보호가 가능하다
• API endpoints(BP4)
  • API Gateway를 통해 어떤 백엔드든 숨길 수 있다
  • 엣지 최적화를 사용한 경우 이미 글로벌로 설정되어 있고 CloudFront에 리전 모드를 더해 사용한다면 디도스 보호에 관한 제어 기능이 더 강화된다
  • API Gateway에 WAF를 사용하는 경우 모든 HTTP 요청을 필터링 가능하다(헤더 필터링, API Key 강제 등 가능하다)

 

AWS GuardDuty

• AWS 계정을 보호하는 지능형 위협 탐지 서비스
• 백엔드에서 머신러닝 알고리즘을 통한 이상탐지 수행하고 타사 데이터를 이용하여 계정에 대한 공격 감지
• 클릭한번으로 활성화되며 백엔드에서 작동된다
• 여러 소스에서 입력 데이터를 얻고 CloudTrail 이벤트 로그의 입력 데이터를 가지고 비정상적 API 호출과 무단 배포 등을 탐지
  • 입력 데이터 예시
    • CloudTrail Management Events: VPC 서브넷 생성, trail 생성 등등
    • CloudTrail S3 Data events: 버킷에서 발생하는 이벤트들
    • VPC 흐름 로그: 비정상적인 인터넷 트래픽과 IP주소 찾기
    • DNS 로그: DNS 쿼리에서 인코딩된 데이터를 전송할 ec2 인스턴스가 손상되었는지 확인할 수 있다
    • 쿠버네티스 감사 로그: 의심스러운 활동과 잠재적인 EKS 클러스터 손상을 감지
• 모든 작업이 내부적으로 동작하여 CloudWatch Event Rules를 통해 탐색 결과가 나타나면 알림을 받을 수 있다
• 암호화폐 공격을 보호할 수 있다 → 관련된 전용 탐지가 있음

 

Amazon Inspector

• 자동화된 보안 평가를 실행할 수 있는 서비스

ec2 인스턴스

• 인스턴스에서 시스템 관리자 에이전트를 활용하면 Inspector가 해당 인스턴스의 보안을 평가
• 의도하지 않은 네트워크 접근 가능성에 대해 분석하고 실행중인 운영체제에서 알려진 취약점을 분석

Amazon ECR

• Inspector는 컨테이너 이미지를 ECR로 푸시할 때 생성
• ECR로 푸시되면 Inspector가 취약점에 대해 검사

Lambda Functions

• 람다함수가 배포될 때 함수 코드 및 패키지 종속성에서 취약성을 다시 분석
• 함수가 배포될 때 평가

Inspector가 작업을 완료하면 결과를 AWS 보안 허브에 보고한다

이후 결과 및 결과 이벤트를 Amazon Event Bridge로 보낸다 → 취약점을 모아보고 자동화할 수 있다.

 

Amazon Macie

• 데이터 보안 및 데이터 프라이버시 서비스로 머신 러닝과 패턴일치를 사용하여 AWS의 민감한 정보를 검색하고 보호
• 구체적으로는 민감한 데이터를 찾아 경고하는 역할을 한다(개인 식별 정보, 주민등록번호 정보)
• 개인 식별 정보가 S3 버킷에 있는 경우 Macie가 이것을 분석하고 PII로 분류되는 데이터를 검색하여 EventBridge로 전달한다. 이후 SNS 토픽이나 람다함수에 통합 가능