AWS 보안 및 암호화

암호화

전송중 암호화 (SSL)

• 전송 중 암호화는 데이터가 전송되기 전 암호화되고 서버가 데이터를 받으면 복호화한다.
• SSL 인증서가 암호화를 해주고 다른 방법은 HTTPS가 있다.
• Amazon 서비스를 다룰 때마다 HTTPS 엔드포인트가 있어서 전송 중 암호화가 됐음을 보장한다.
• 기본적으로 전송 중 암호화를 활성화하면 '중간자' 공격으로부터 보호된다.

서버 측 저장 데이터 암호화

• 데이터가 서버에 수신된 후 암호화하는 것
• 서버가 데이터를 암호화된 형태로 저장하고 있다는 점이 중요하다.
• 데이터는 클라이언트로 다시 전송되기 전에 복호화된다.
• 즉, 데이터 키라고 불리는 키 덕분에 데이터는 암호화된 형태로 저장되고 암호 키와 해독 키는 주로 KMS(Key Management Service) 같은 곳에 따로 관리된다.
• 따라서 서버는 KMS와 통신할 수 있어야 한다.

클라이언트 측 암호화

• 이제 클라이언트 측 암호화입니다
• 클라이언트 측 암호화에서 데이터는 클라이언트가 암호화하고 여기서 클라이언트는 우리고 서버는 그 데이터를 절대 복호화할 수 없고 데이터를 받는 클라이언트에 의해 복호화됩니다
• 전체적으로 데이터는 서버에 저장되지만 서버는 데이터의 내용을 알 수 없습니다
• 서버는 최선의 방법으로도 데이터를 복호화할 수 없어야 합니다
• 이를 위해 봉투 암호화를 활용할 수 있지만 주제가 꽤 심화된 주제라서 이후에 이 주제로 강의가 따로 있습니다
• 시험에서 봉투 암호화에 대한 문제가 출제되긴 하지만 지금은 대략적으로만 살펴보겠습니다
• 여기 객체가 있고 클라이언트는 데이터 키를 사용해서 클라이언트 측의 데이터를 암호화할 겁니다
• 그 데이터 키로 암호화를 수행합니다
• 이제 해당 데이터를 원하는 데이터 저장소로 보냅니다
• FTP가 될 수도 있고 S3도 될 수 있고 무엇이든 상관 없습니다
• Amazon이나 여러분이 원하는 다른 곳에 데이터를 저장합니다
• 그리고 데이터를 받으면 클라이언트는 암호화된 객체를 받고 데이터 키에 액세스가 있거나 다른 곳으로부터 데이터 키를 찾을 수 있으면 받은 데이터를 복호화하여 복호화된 객체를 얻게 됩니다
• 보셨듯 암호화는 클라이언트 측에서 수행됩니다
• 서버 데이터 저장소는 데이터를 암호화하거나 복호화할 수 없고 그저 암호화된 데이터를 받기만 할 수 있습니다

KMS (Key Management Service)

• AWS 서비스로 암호화한다고 하면 KMS 암호화일 가능성이 크다.
• KMS 서비스를 사용하면 AWS에서 암호화 키를 관리한다.
• KMS는 권한 부여를 위해 IAM과 완전히 통합되고 KMS로 암호화한 데이터에 관한 액세스를 더 쉽게 제어하도록 한다.
• AWS KMS를 사용의 장점으로는 CloudTrail을 통해 키를 사용하기 위해 호출한 모든 API를 감사할 수 있다는 점이다. (중요)
• 저장 데이터를 EBS 볼륨에서 암호화하려면 KMS 통합을 활성화하면 된다. S3, RDS, SSM도 동일
• KMS을 직접 적용할 수도 있다. (API 호출, AWS CLI, SDK)
• 암호 데이터는 절대로 평문으로 저장하면 안 된다. 특히 코드에는 남기면 안된다.

대칭키

• 대칭 KMS 키에는 데이터 암호화와 복호화에 사용하는 단일 암호화 키만 있어서 KMS와 통합된 모든 AWS 서비스는 대칭 키를 사용
• KMS 대칭 키를 생성하거나 사용하면 키 자체에는 절대로 액세스할 수 없고 키를 활용 또는 사용하려면 KMS API를 호출해야 한다.

비대칭키, 공개키

• KMS에서 사용 가능한 두 번째 키는 바로 비대칭 키라고 한다. 2개의 키를 의미
• 데이터 암호화에 사용하는 퍼블릭 키와 데이터 복호화에 사용하는 프라이빗 키
• 따라서 암호화, 복호화와 작업 할당 및 검증에 사용
• 이 경우에는 KMS에서 퍼블릭 키를 다운로드 할 수 있지만 프라이빗 키에는 액세스할 수 없다.
• 프라이빗 키에 액세스하려면 API 호출로만 가능

KMS 키 타입

• KMS로 호출하는 모든 API도 비용을 지불해야 한다.
• API 호출 10,000건당 약 3센트

AWS 관리형 키

• 이 키는 aws/rds나 aws/ebs와 같이 이름이 지정된다.
• AWS 서비스와 통합되어 있으며 무료 서비스이므로 AWS에서 관리하며 특정 서비스에 관한 저장 데이터 암호화에 사용할 수 있다.

고객 관리형 키 (CMK)

• KMS를 사용해 생성 가능하고 키 하나에 매달 1달러의 비용이 든다.

외부에서 가져온 고객 관리형 키 

• 자체 키 구성 요소를 KMS에 가져올 수 있다.
• KMS에서 생성할 수 있고 동일하게 매달 1달러의 비용이 든다.

키 교체

• 보안을 위해서 자동으로 키를 교체하도록 설정할 수 있다.
• AWS 자동 관리형 키를 사용하면 자동으로 1년에 한 번씩 교체되며 고객 관리형 KMS 키를 사용하면 반드시 교체되도록 활성화해야 한다.
• 활성화한 후에는 자동으로 1년에 한 번씩 교체되며 교체 빈도를 변경할 수는 없다.
• 자체 키 구성 요소를 KMS로 보내려면 수동으로만 키를 교체할 수 있고 올바르게 키를 교체하려면 반드시 KMS 키 별칭을 사용해야 한다.

키 정책

• KMS 키에 관한 액세스를 제어하는 것으로 S3 버킷 정책과 비슷하지만 차이점이 있는데 KMS 키에 KMS 키 정책이 없으면 누구도 액세스할 수 없다.
• 이와 관련해 2가지 유형의 KMS 키 정책이 있다.

기본 정책

• 기본 정책은 사용자 지정 키 정책을 제공하지 않으면 생성된다.
• 기본적으로 계정의 모든 사람이 키에 액세스하도록 허용
• 즉, 사용자 또는 키 정책의 액세스를 허용하는 IAM 정책이 있으면 된다.

사용자 지정 키 정책

• 제어를 조금 더 특정하고자 할때 KMS 키에 액세스할 수 있는 사용자 또는 역할을 정의하고 키 관리자를 정의할 수 있는 정책
• KMS 키에 관한 교차 계정 액세스 시 매우 유용
• 다른 계정이 KMS 키를 사용하도록 권한을 부여하기 때문
• 사용 사례는 계정 간에 스냅샷을 복사할 때  자체 KMS 키로 암호화한 스냅샷을 생성하면 고객 키 정책을 연결해야 하므로 고객 관리형 키가 되며 교차 계정 액세스 권한 부여를 위해 KMS 키 정책을 연결
• 암호화된 스냅샷을 대상 계정에 공유하면 대상 계정에서는 스냅샷 복제본을 생성하고 해당 대상 계정에서 다른 고객 관리형 키로 암호화한다.
• 이렇게 대상 계정의 스냅샷에서 볼륨을 생성하면 끝이다.

KMS Multi Region Keys

• AWS KMS에는 다중 리전 키를 둘 수 있다.  선택된 한 리전에 기본 키를 갖는다는 의미
• 다른 리전도 동일한 키를 갖게 되는데 키 ID와 구성 요소가 완전히 똑같다.
• KMS 다중 리전 키는 다른 AWS 리전에서 사용할 수 있는 KMS 키 세트로 서로 교차해서 사용할 수 있다.
• 한 리전에서 암호화한 다음 다른 리전에서 복호화 할 수 있다.
• 핵심은 한 리전에서 암호화하고 다른 리전에서 복호화해 다음 리전으로 복제할 때나 교차 리전 API 호출을 실행할 때 데이터를 재암호화하지 않아도 된다는 점
• 하지만 KMS 다중 리전 키는 전역으로 사용할 수 없다.
• 기본 키가 있고 복제본이 있는 것
• 각 다중 리전 키는 자체 키 정책 등으로 각각 독립적으로 관리
• 따라서 특정 사용 사례를 제외하고는 다중 리전 키 사용을 권장하지 않는다.
• 다중 리전 키의 사용 사례에는 전역 클라이언트 측 암호화가 있다.

S3 암호화 복제

• 한 버킷에서 다른 버킷으로 S3 복제를 활성화하면 암호화되지 않은 객체와 SSE-S3로 암호화된 객체가 기본으로 복제
• 고객 제공 키인 SSE-C로 객체를 암호화하면 복제되지 않는다.
• SSE-KMS로 암호화된 객체도 있다.
• 기본적으로 복제되지 않지만 만약 객체를 복제하려면 옵션을 활성화해야 한다.
• 따라서 어떤 KMS 키로 대상 버킷 내 객체를 암호화하는지 지정해야 합니다
  • 그리고 이 KMS 키 정책을 대상 키에 적용해야 하고 S3 복제 서비스를 허용하는 IAM 역할을 생성해서 소스 버킷의 데이터를 먼저 복호화하도록 한 뒤 대상 KMS 키로 대상 버킷의 데이터를 다시 암호화한다.
  • 이렇게 하면 복제가 활성화되는데 이는 수많은 암호화와 복호화가 발생하기 때문
  • KMS 스로틀링 오류가 발생한 경우는 서비스 할당량을 요청해야 한다.
• 여기서 S3 복제에 다중 리전 키를 사용해야 할까?
• 공식 문서에 따르면 S3 복제에 다중 리전 키를 사용할 수 있으나 현재는 Amazon S3 서비스에서 독립 키로 취급하고 있으므로 객체는 여전히 복호화될 것이고 다중 리전 키인 경우에도 동일한 키로 암호화된다.

암호화된 AMI 공유 프로세스

• AMI는 KMS 키로 암호화 되어 있습니다
• AMI는 소스 계정에 있고 KMS 키로 암호화된 것
• 어떤 방식으로 A 계정의 AMI에서 B 계정의 EC2 인스턴스를 시작할 수 있을까?
• 먼저, 시작 권한으로 AMI 속성을 수정해야 하는데 이 시작 권한은 B 계정에서 AMI를 시작하도록 허용한다. 이렇게 AMI를 공유
• 시작 권한을 수정하고 특정 대상인 AWS 계정 ID를 추가하는 것
• 그런 다음 B 계정에서 사용하도록 KMS 키도 공유해야 하므로 일반적으로 키 정책으로 실행
• 이제 B 계정에서 KMS 키와 AMI를 모두 사용할 수 있는 충분한 권한을 가진 IAM 역할이나 IAM 사용자를 생성
• 따라서 DescribeKey API 호출과 ReEncrypted API 호출 CreateGrant, Decrypt API 호출에 관한 KMS 측 액세스 권한이 있어야 한다.
• 모두 완료된 후에는 AMI에서 EC2 인스턴스를 시작하면 되는데 선택 사항으로 대상 계정에서 자체 계정의 볼륨을 재암호화하는 KMS 키를 이용해 전체를 재암호화할 수 있다.
• 이제 EC2 인스턴스를 실행할 수 있다.

SSM 매개변수 저장소

• 구성 및 암호를 위한 보안 스토리지
• 구성을 암호화할지 선택할 수 있으므로 KMS 서비스를 이용해 암호를 만들 수 있다.
• SSM Parameter Store는 서버리스이며 확장성과 내구성이 있고 SDK도 사용이 용이
• 또한 매개변수를 업데이트할 때 구성과 암호의 버전을 추적할 수도 있다.
• IAM을 통해 보안이 제공되며 특정한 경우에는 Amazon EventBridge로 알림을 받을 수도 있다.
• CloudFormation이 Parameter Store의 매개변수를 스택의 입력 매개변수로 활용할 수 있다.

Paramters Policies

• 고급 매개변수에서만 사용할 수 있다.
• 매개변수 정책을 통해 만료 기한을 뜻하는 타임 투 리브(TTL)를 매개변수에 할당할 수 있다.
• 비밀번호 등의 민감한 정보를 업데이트 또는 삭제하도록 강제한다.
• 한 번에 여러 정책을 할당할 수도 있다.

AWS Secrets Manager

• 암호를 저장하는 최신 서비스로 SSM Parameter Store와는 다른 서비스
• Secrets Manager는 X일마다 강제로 암호를 교체하는 기능이 있어 암호 관리를 더 효율적으로 할 수 있다.
• 또한 AWS Secrets Manager로 교체할 암호를 강제 생성 및 자동화할 수 있다.
• 이를 위해 새 암호를 생성할 Lambda 함수를 정의해야 한다.
• AWS Secrets Manager는 AWS가 제공하는 다양한 서비스와도 아주 잘 통합된다. (RDS, MySQL,PostgreSQL, Aurora 등)
• AWS 외 여러 서비스와 데이터베이스에도 즉시 통합할 수 다.
• 데이터베이스에 접근하기 위한 사용자 이름과 비밀번호가 AWS Secrets Manager에 바로 저장되고 교체 등도 가능하다.
• 암호는 KMS 서비스를 통해 암호화된다.
• RDS와 Aurora의 통합 혹은 암호에 대한 내용이 시험에 나오면AWS Secrets Manager를 떠올려야 한다.

다중 리전 암호

• 복수 AWS 리전에 암호를 복제할 수 있고 AWS Secrets Manager 서비스가 기본 암호와 동기화된 읽기 전용 복제본을 유지한다는 개념
• 이렇게 두 리전이 있을 때 기본 리전에 암호를 하나 만들면 보조 리전에 동일한 암호가 복제된다.
• 이렇게 하는 데에는 여러 이유가 있다.
  • 첫째, us-east-1에 문제가 발생하면 암호 복제본을 독립 실행형 암호로 승격할 수 있다.
  • 그리고 여러 리전에 암호가 복제되니 다중 리전 앱을 구축하고 재해 복구 전략도 짤 수 있다.
  • 한 리전에서 다음 리전으로 복제되는 RDS 데이터베이스가 있다면 동일한 암호로 동일한 RDS 데이터베이스즉 해당 리전의 해당 데이터베이스에 액세스할 수 있다.

AWS Certificate Manager 

• ACM은 TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포하게 해준다.
• ACM은 퍼블릭과 프라이빗 TLS 인증서를 모두 지원하며 퍼블릭 TLS 인증서 사용 시에는 무료로 이용할 수 있다.
• 인증서를 자동으로 갱신하는 기능도 있다.
• 그리고 여러 AWS 서비스와 통합되어 있어 Elastic Load Balancer(ELB)에 TLS 인증서를 불러올 수 있다. (ALB, NLB)
• CloudFront 배포나 API Gateway의 모든 API에서도 불러올 수 있다.
• 다만 ACM을 사용할 수 없는 곳이 하나 있는데 바로 EC2 인스턴스

엔드 포인트 유형

• 엣지 최적화(edge-optimized) 유형
  • 글로벌 클라이언트를 위한 유형으로 먼저 CloudFront 엣지 로케이션으로 요청을 라우팅하여 지연을 줄이는 방법으로 하나의 리전에만 있는 API Gateway로 보내지는 경우
• 리전(regional) 엔드 포인트 유형
  • 클라이언트가 API Gateway와 같은 리전에 있을 때를 쓰인다.
  • 이 경우 CloudFront는 사용할 수 없지만 자체 CloudFront 배포를 생성하여 캐싱 및 배포 전략을 제어할 수 있다
• 프라이빗(private) API Gateway 엔드포인트 유형
  • 인터페이스 VPC 엔드 포인트(ENI)를 통해 VPC 내부에만 액세스할 수 있다.
  • 또한 프라이빗 모드에서는 API Gateway에 대한 액세스를 정의하는 리소스 정책이 필요하다.
• ACM은 엣지 최적화 및 리전 엔드포인트에 적합하다.

웹 애플리케이션 방화벽 (WAF)

• WAF는 7계층에서 일어나는 일반적인 웹 취약점 공격으로부터 웹 애플리케이션을 보호한다.
• 계층 7은 HTTP이니 HTTP 취약점 공격을 막아주는 것
• 웹 애플리케이션 방화벽(WAF)의 배포는 애플리케이션 로드 밸런서, API Gateway CloudFront AppSync GraphQL API Cognito 사용자 풀에 할 수 있다.
• WAF의 배포가 어디에 되는 지 꼭 기억해야한다.
• WAF를 NLB에 배포한다는 것은 틀렸다. 이는 4계층
• 이러한 서비스에 방화벽을 배포한 후에는 웹 액세스 제어 목록(ACL)과 규칙을 정의해야 한다.
• 이 규칙이란 IP 주소를 기반으로 필터링하는 등의 규칙
• IP 세트를 정의할 수 있으며 각 IP 세트는 최대 10,000개의 IP 주소를 가질 수 있다.
• 또한 HTTP 헤더와 본문에 기반해 필터링할 수도 있고 URI 문자열을 조건으로 두어 SQL 주입, 크로스 사이트 스크립팅(XSS) 등의 일반적인 공격을 차단할 수도 있다
• 용량에 제약을 걸어 요청이 최대 2MB를 넘지 않게 하거나 지역 일치(Geo-match) 조건을 두어 특정 국가를 허용 또는 차단 가능
• 또 속도 기반 규칙을 설정하면 IP당 요청 수를 측정하여 디도스 공격을 막을 수도 있다
• 웹 ACL은 리전에만 적용되며 CloudFront는 글로벌로 정의됩니다
• 규칙 그룹은 여러 웹 ACL에 추가할 수 있는 재사용 가능한 규칙 모음

AWS Shield

• AWS Shield는 디도스 공격으로부터 스스로를 보호하기 위한 서비스
• 디도스란 분산 서비스 거부 공격이라는 뜻. 인프라에 동시에 엄청난 양의 요청이 세계 곳곳의 여러 컴퓨터에서 유입되는 공격
• 그 목적은 인프라에 과부하를 일으키는 것으로 실제 사용자들에게 서비스를 제공할 수 없게 만든다. 즉 분산 서비스 거부가 발생
• 디도스 공격을 방어하려면 AWS Shield 스탠다드 서비스를 이용하면 된다.
• 이 서비스는 모든 AWS 고객에게 무료로 활성화되어 있는 서비스로 SYN/UDP Floods나 반사 공격 및 L3/L4 공격으로부터 고객을 보호해 준다.
• 고급 보호가 필요한 고객을 위한 AWS Shield 어드밴스드 서비스도 있는데 어드밴스드는 선택적으로 제공되는 디도스 완화 서비스로 조직당 월 3,000달러를 지불해야 한다.
• 어드밴스드에서는 더욱 정교한 디도스 공격을 막아주며 Amazon EC2, ELB Amazon CloudFront AWS Global Accelerator 그리고 Route 53를 보호한다.
• 또한 AWS 디도스 대응 팀이 항시 대기하고 있어 공격을 받았을 때 지원을 받을 수 있다.
• 따라서 디도스 공격으로 인한 요금 상승을 AWS Shield 어드밴스드를 통해 방지할 수 있겠다.
• 또 Shield 어드밴스드는 자동 애플리케이션 계층 디도스 완화도 제공하여 자동으로 WAF 규칙을 생성, 평가, 배포함으로써 L7 공격을 완화할 수 있다.
• 즉 웹 애플리케이션 방화벽이 L7에서 일어나는 디도스 공격을 완화하는 규칙을 자동으로 갖게 된다는 뜻

AWS Firewall Manager

• AWS Organizations에 있는 모든 계정의 방화벽 규칙을 관리하는 서비스
• 여러 계정의 규칙을 동시에 관리할 수 있다.
• 또한 보안 규칙의 집합인 보안 정책을 설정할 수 있는데 여기에는 ALB, API Gateway CloudFront 등에 적용되는 웹 애플리케이션 방화벽(WAF) 규칙이나 ALB, CLB, NLB, 엘라스틱 IP CloudFront를 위한 AWS Shield 어드밴스드 규칙 등이 포함된다.
• 또 EC2, 애플리케이션 로드 밸런서 VPC의 ENI 리소스를 위한 보안 그룹을 표준화하는 보안 정책과 아직 다룬 적은 없지만 VPC 수준의 AWS Network Firewall도 해당된다.
• 그리고 Amazon Route 53 Resolver DNS Firewall도 포함된다.
• AWS Firewall Manager는 이와 같은 모든 방화벽을 한 곳에서 관리할 수 있도록 지원해 준다.
• 정책은 리전 수준에서 생성되며 조직에 등록된 모든 계정에 적용된다.

WAF, Firewall Manager, Shield 차이

• WAF, Shield Firewall Manager는 모두 포괄적인 계정 보호를 위한 서비스
• 일단 WAF에서는 웹 ACL 규칙을 정의하는데 리소스별 보호를 구성하는 데에는 WAF가 적절합니다
• 여러 계정에서 WAF를 사용하고 WAF 구성을 가속하고 새 리소스 보호를 자동화하려면 Firewall Manager로 WAF 규칙을 관리
• Firewall Manager는 이러한 규칙들을 모든 계정과 모든 리소스에 자동으로 적용해준다.
• Shield 어드밴스드는 디도스 공격으로부터 고객을 보호하고 WAF의 기능 외에도 더 많은 기능을 제공
• 예를 들어 Shield 대응 팀 지원 고급 보고서 제공 그리고 WAF 규칙 자동 생성 등의 기능을 추가로 이용할 수 있다.
• 디도스 공격을 자주 받는다면 Shield 어드밴스드를 사용하는 것도 좋은 선택지가 될 수 있다.
• 또한 Firewall Manager는 모든 계정에 Shield 어드밴스드를 배포에도 도움을 준다.

GuardDuty

• AWS 계정을 보호하는 지능형 위협 탐지 서비스
• 백엔드에서 머신 러닝 알고리즘을 사용하여 이상 탐지를 수행하고 타사 데이터를 이용하여 계정에 대한 공격을 탐지한다.
• Amazon GuardDuty는 여러 소스에서 입력 데이터를 얻는다.
• CloudTrail 이벤트 로그의 입력 데이터를 가지고 비정상적 API 호출과 무단 배포 등을 탐지한다.
  • 관리 이벤트에서 사용하여 해당 이벤트가 VPC 서브넷을 만들 때 생기는지 API가 계정에 호출하는 추적 생성 시 생기는지 확인한다.
  • CloudTrail S3 데이터 이벤트를 확인한다. 예를 들어 버킷에서 발생하는 이벤트인 API 호출, 즉 get object, list objects delete object 등
• VPC 흐름 로그를 통해 비정상적인 인터넷 트래픽과 IP 주소를 찾고 또한 DNS 로그는 DNS 쿼리에서 인코딩된 데이터를 전송할 EC2 인스턴스가 손상되었는지 확인할 수 있다.
• Kubernetes 감사 로그를 확인하여 의심스러운 활동 및 잠재적인 EKS 클러스터 손상을 감지한다.
• 이 모든 작업이 내부적으로 이루어진다.
• 그리고 CloudWatch 이벤트 규칙을 설정하여 탐색 결과가 나타나면 알림을 받을 수 있다.
• 마지막으로 시험에 나올 수 있는 내용은 GuardDuty로 암호화폐 공격을 보호할 수 있다는 점
• 요약하면 GuardDuty는 VPC 흐름 로그, CloudTrail 로그 DNS 로그 및 EKS 감사 로그를 모두 GuardDuty로 가져온다.
• 그리고 CloudWatch 이벤트 규칙 덕분에 Lambda 함수나 SNS 주제 알림을 받을 수 있다.

Amazon Inspector

• Amazon Inspector는 몇 군데에서 자동화된 보안 평가를 실행할 수 있는 서비스
• EC2 인스턴스 경우
  • EC2 인스턴스에서 시스템 관리자 에이전트를 활용하면 Amazon Inspector가 해당 EC2 인스턴스의 보안을 평가하기 시작한다.
  • 의도되지 않은 네트워크 접근 가능성에 대해 분석하고, 실행 중인 운영 체제에서 알려진 취약점을 분석한다.
  • 이건 연속적으로 수행된다.
• 컨테이너 이미지를 Amazon ECR로 푸시할 때 실행
  • 예를 들어 도커 이미지
  • 컨테이너 이미지가 Amazon ECR로 푸시되면 Amazon Inspector가 알려진 취약점에 대해 검사
•  Lambda 함수에 대해서도 사용 가능한데요
  • Amazon Inspector는 Lambda 함수가 배포될 때 함수 코드 및 패키지 종속성에서 소프트웨어 취약성을 다시 분석
  • 즉, 함수가 배포될 때 평가
• Amazon Inspector가 작업을 완료하면 결과를 AWS 보안 허브에 보고한다.
• 또한 이러한 결과 및 결과 이벤트를 Amazon Event Bridge로 보낸다.
• 이를 통해 인프라에 있는 취약점을 모아서 볼 수 있다.
• Inspector는 실행 중인 EC2 인스턴스, Amazon ECR의 컨테이너 이미지, Lambda 함수에만 사용된다 

Macie

• Macie는 완전 관리형의 데이터 보안 및 데이터 프라이버시 서비스이며 머신 러닝과 패턴 일치를 사용하여AWS의 민감한 정보를 검색하고 보호한다.
• 구체적으로 말하면 민감한 데이터를 경고하는데 예를 들면, 개인 식별 정보 즉, PII 같은 정보다..