Security

암호화 기본

• 전송 중 암호화

  • TLS/SSL 을 이용해 데이터를 보내는 시점에 암호화하고 받는 시점에 복호화하는 방식이다.

  • Man in the middle attack을 방지할 수 있다.

• Server-Side 암호화

  • 서버가 데이터를 받은 후 암호화하여 저장해두고, 서버가 데이터를 보내기 전 복호화하는 방식이다.

  • 암/복호화 키가 누군가에 의해 관리되어야 하며, 서버가 항상 접근할 수 있어야 한다.

• Client-Side 암호화

  • 클라이언트가 갖고 있는 암/복호화키를 이용해 데이터를 전송하기 전 암호화하고 데이터를 받은 후 복호화하는 방식이다.

  • 서버는 데이터를 항상 암호화된 상태로 관리하게 된다.

KMS

• 암호화 키를 관리해주는 서비스

• IAM과 통합 가능하며 데이터에 대한 접근을 쉽게 제어할 수 있다.

• CloudTrail을 통해 키를 사용하기 위해 이루어진 모든 API 호출을 감사할 수 있다.

• 대부분의 AWS 서비스와 통합 가능하다. 예를 들어 EBS 볼륨에 저장되어 있는 데이터를 암호화할 때 KMS 통합을 활성화하면 된다.

• 기밀 데이터는 절대로 평문 텍스트에 저장하면 안된다. 암호화된 형태로 코드나 환경 변수에서 사용해야 한다.

• AWS CLI, SDK를 통한 API 호출으로 KMS를 사용할 수 있다.

• KMS 키

  • 대칭 KMS 키

    • 데이터를 암호화하고 복호화하는 데 하나의 암호화 키만 사용한다.

    • KMS가 통합된 모든 AWS 서비스는 대칭 키를 사용한다. 이 때에는 KMS 키 자체에 절대로 액세스할 수 없다. AWS API 호출을 이용해서 그 키를 사용할 수만 있다.

  • 비대칭 키

    • 데이터를 암호화하는 데 사용되는 퍼블릭 키와 데이터를 복호화하는 데 사용되는 프라이빗 키가 사용된다.

    • 암호화/복호화 또는 서명/확인 형태의 작업을 할 때 사용할 수 있다.

    • KMS에서 퍼블릭 키는 다운로드할 수 있지만 프라이빗 키에는 액세스할 수 없다.

    • 프라이빗 키에 액세스하려면 API 호출만 사용할 수 있다.

    • AWS Cloud 외부에서 KMS API 키에 액세스할 수 없는 사용자가 암호화하려는 경우, 퍼블릭 키를 사용해 데이터를 암호화하여 전송한 후, AWS의 프라이빗 키를 써서 해당 데이터를 복호화할 수 있다.

• KMS 키의 종류

  • AWS가 소유한 키

    • 무료이며 SSE-S3, SSE DynamoDB, SSE-DDE 타입의 암호화를 사용할 때 쓴다.

  • AWS 관리형 키

    • 무료이며 앞에 aws/가 있고 서비스 이름이 나오기 때문에 식별 가능하다. 에를 들어 aws/rds, aws/ebs, aws/dynamodb 같은 이름을 가진다. 키가 지정된 서비스 안에서만 사용할 수 있다.

  • 고객 관리형 키

    • KMS에서 생성하거나 외부에서 임포트할 수 있으며 한달에 1달러의 비용이 발생한다.

  • 기본적으로 KMS API 호출에 대한 비용이 부과되는데, 대략 10,000회의 API 호출당 3센트 정도 발생한다.

• 자동 키 순환(Automatic Key Rotation)

  • AMS 관리형 KMS 키라면 자동으로 1년마다 순환된다.

  • KMS 안에서 생성한 고객 관리형 키라면 1년마다 순환되도록 자동 순환 옵션을 활성화할 수 있다. 기본적으로는 비활성화되어 있다.

  • 직접 임포트한 KMS 키라면 수작업으로만 순환시킬 수 있다. alias를 사용해 순환시켜야 한다.

• KMS 키는 리전 단위로 존재한다.

• KMS 키 정책

  • KMS 키에 대한 액세스를 관리하기 위한 정책

  • S3 버킷 정책과 비슷하지만, 키에 KMS 키 정책이 없다면 아무도 키에 접근할 수 없다.

  • 기본 정책

    • 특정한 커스텀 KMS 키 정책을 제공하지 않았을 때 생성된다.

    • 계정에 있는 모든 사람이 이 키에 액세스하도록 허용한다.

    • 사용자 또는 역할이 키 정책에 액세스하도록 허용하는 IAM 정책이 있다면 문제가 없다.

  • 커스텀 KMS 키 정책

    • KMS 키에 액세스할 수 있는 사용자와 역할을 직접 정의하고 키를 누가 관리할 수 있는지 정의한다.

    • KMS 키에 대한 교차 계정 액세스를 하려는 경우 유용하다. 다른 계정이 현재 계정의 KMS 키를 사용하도록 승인할 수 있다.

• 암호화된 EBS 스냅샷을 리전 간 이동시키기

  • 암호화된 스냅샷을 만들고, 암호화된 스냅샷의 스냅샷을 만들어 동일한 KMS 키로 각각 암호화한다.

  • 스냅샷을 다른 리전에 복사하기 위해 다른 리전의 KMS 키를 사용해서 그 스냅샷을 다시 암호화한다. 이는 AWS에서 대신 수행해준다.

  • 다른 리전에서는 EBS 스냅샷을 받은 후 KMS를 이용해서 원래 암호화되어 있던 EBS 볼륨으로 복구한다.

  
• 암호화된 EBS 스냅샷을 계정 간 이동시키기

  • 고객 관리형 KMS 키로 암호화된 스냅샷을 생성하고, 교차 계정 액세스를 승인하기 위해 커스텀 키 정책을 첨부한다.

  • 암호화된 스냅샷을 다른 계정에 공유한다. 다른 계정은 자체적으로 스냅샷의 사본을 생성하고 다른 고객 관리형 키를 사용해서 암호화한다.

  • 다른 계정에서는 이 스냅샷으로부터 볼륨을 생성할 수 있다.

Multi-Region Keys

• AWS KMS에는 다중 리전 키를 둘 수 있다. 즉, 한 리전에 키를 두면, 다른 리전들에 복제시킬 수 있다. (Not Global)

  • 이를 통해 한 리전에서 데이터를 암호화하고 다른 리전에서 데이터를 복호화 할 수 있다.

  • 동일한 키 ID와 동일한 키 구성 요소를 갖는다.

  • 기본 키의 자동 교체를 활성화했다면 실제로 자동으로 교체된 키는 다른 리전에도 복제된다.

  • 한 리전에서 암호화하고 다른 리전에서 복호화해 다음 리전으로 복제할 때나 교차 리전 API 호출을 실행할 때 데이터를 재암호화하지 않아도 된다.

  • 기본 키가 있고 복제본이 있는 거예요

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

  • 일부 상황을 제외하고는 다중 리전 키 사용을 권장하지 않는다.

  • 사용 사례

    • 전역 클라이언트 측 암호화: 한 리전에서 클라이언트 측 암호화를 하고 다른 리전에서 클라이언트 측 복호화를 하는 방식

  • DynamoDB 전역 테이블과 KMS 다중 리전 키로 Client-Side 암호화하기

    

    • 전체 테이블을 암호화하는 대신 테이블의 속성을 클라이언트에서 암호화하므로 특정 클라이언트만 사용할 수 있다. 데이터베이스 관리자도 사용할 수 없다.

    • 이 때 클라이언트는 Amazon DynamoDB 암호화 클라이언트를 사용한다.

    • KMS 다중 리전 키는 다른 리전에 복제된다.

    • us-east-1 리전의 클라이언트 애플리케이션에서 DynamoDB에 데이터를 삽입할 때 다중 리전 키를 통해 속성을 암호화해 DynamoDB에 저장한다.

    • DynamoDB 테이블이 전역 테이블인 경우 해당 테이블의 데이터는 다른 리전으로 복제된다.

    • 다중 리전 키로 데이터 속성을 암호화하였으므로, ap-southeast-2 리전의 클라이언트 애플리케이션은 해당 속성을 복호화할 수 있다.

    • 이를 통해 데이터의 특정 필드나 속성을 보호할 수 있고, API 키 액세스 권한이 있는 클라이언트만 복호화하도록 할 수 있다.

  • Global Aurora

    • 두 리전에 걸쳐 복제된 KMS 다중 리전 키를 사용한다.

    • 특정 리전의 클라이언트 애플리케이션에서는 AWS Encryption SDK를 사용하여 특정 컬럼 값을 암호화하여 데이터를 Amazon Aurora DB에 보낸다.

    • 전역 데이터베이스이므로 테이블이 전역으로 복제된다.

    • 다른 리전의 클라이언트 애플리케이션에서는 다중 리전 키를 사용해 KMS에 로컬 API 호출을 보내 해당 속성을 복호화할 수 있다.

    • 이를 통해 지연 시간이 단축된다.

S3 암호화된 복제

• 한 버킷에서 다른 버킷으로 S3 복제를 활성화하면, 암호화되지 않은 객체와 SSE-S3로 암호화된 객체가 기본으로 복제된다.

• 고객 제공 키인 SSE-C로 암호화한 객체도 복제될 수 있다.

• SSE-KMS로 암호화한 객체를 복제하려면 별도 옵션을 활성화해주어야 한다.

  • 어떤 KMS 키로 대상 버킷 내 객체를 암호화하는지 지정해야 한다.

  • KMS 키 정책을 대상 키에 적용해야 한다.

  • S3 복제 서비스를 허용하는 IAM 역할을 생성해서 소스 버킷의 데이터를 먼저 복호화한 뒤 대상 KMS 키로 대상 버킷의 데이터를 다시 암호화한다.

  • 수많은 암호화와 복호화가 발생하여 KMS 스로틀링 오류가 발생한 경우는 서비스 할당량 증가를 요청해야 한다.

• S3 복제에 다중 리전 KMS 키를 사용할 수는 있지만 Amazon S3 서비스에서 독립 키로 취급하고 있다. 객체의 복호화와 암호화 모두 가능하다.

암호화된 AMI 공유 프로세스

• 소스 계정에서 KMS로 암호화된 AMI를 그대로 타겟 계정에서 사용해 EC2 인스턴스를 실행할 수 있도록 해야 한다.

• 다음 과정을 수행해야 한다.

  • 소스 계정에서 KMS 키로 암호화된 AMI를 준비한다.

  • 시작 권한(Launch Permission)을 추가해 타겟 계정에서 AMI를 시작할 수 있도록 AMI 속성을 수정한다.

  • KMS 키 정책을 통해 타겟 계정에서 KMS 키를 사용할 수 있도록 공유한다.

  • 타겟 계정에서는 KMS 키와 AMI를 모두 사용할 수 있는 충분한 권한을 가진 IAM 역할이나 IAM 사용자를 생성한다.

    • DescribeKey API 호출과 ReEncrypted API 호출, CreateGrant, Decrypt API 호출에 관한 KMS 측 액세스 권한이 있어야 한다.

  • 앞선 과정이 모두 완료된 후에는 타겟 계정에서 AMI를 이용해 EC2 인스턴스를 시작하면 된다.

    • 이 때 타겟 계정에서 자체 KMS 키를 이용해 볼륨을 재암호화할 수도 있다.

SSM 매개변수

• 설정 및 암호를 위한 보안 스토리지

• 설정에 대해 KMS 키로 암호화할지 선택할 수 있다. 기본적으로는 String, StringList 타입을 사용하고, 암호화를 하는 경우 SecureString 타입을 사용하게 된다.

• SSM Parameter Store는 서버리스이며 확장성과 내구성이 있고 SDK 사용이 용이하다.

• 설정과 암호의 버전을 추적할 수 있다.

• IAM을 통해 보안이 제공되며 Amazon EventBridge로 알림을 받을 수 있다.

• CloudFormation과 통합 가능하다. 즉, CloudFormation이 Parameter Store의 매개변수를 스택의 입력 매개변수로 활용할 수 있다.

• SSM Parameter Store에 평문을 저장하고자 한다면, 애플리케이션의 IAM 권한을 확인 후 저장한다.

• 암호화된 데이터를 저장하고자 한다면 SSM Parameter Store가 KMS로 암호화한다. 이 때 애플리케이션은 기본 KMS 키에 액세스할 수 있어야 한다.

• Parameter Store에 매개변수를 계층 구조로 저장할 수 있다.

  /my-department
    |--my-app
      |--dev
        |__db-url
        |__db-password
      |__prod
        |__db-url
        |__db-password
    |__other-app

• IAM 정책은 특정 경로에만 접근 가능하도록 설정할 수 있다.

• /aws/reference/secretsmanager/secret_ID_in_Secrets_Manager 위치의 값을 통해 Secrets Manager의 암호에 액세스할 수 있다.

• /aws/reference/secretsmanager/secret_ID_in_Secrets_Manager 위치의 값을 통해 특정 리전에서Amazon Linux 2의 최신 AMI를 찾을 수 있다.

• 매개변수 티어

  • 표준

    • 파라미터의 최대 크기는 4KB이다.

    • 무료로 사용 가능하다.

  • 고급

    • 파라미터의 최대 크기는 8KB이다.

    • 매개변수 정책을 적용하여 만료 기한을 설정하거나 만료에 따른 알람, 일정 기간동안 변화가 없을 때의 알람을 설정할 수 있다.

    • 월 0.05달러를 지불해야 한다.

AWS Secrets Manager

• 암호를 저장하는 최신 서비스

• 특정 기간마다 강제로 암호를 교체하는 기능이 있다. 이를 위해 새 암호를 생성할 Lambda 함수를 정의해야 한다.

• AWS가 제공하는 다양한 서비스(Amazon RDS, MySQL PostgreSQL, Aurora 등)와 통합이 잘된다.

• RDS, Aurora 등 데이터베이스에 접근하기 위한 사용자 이름과 비밀번호를 AWS Secrets Manager에 바로 저장하고 교체할 수 있다.

• KMS 서비스를 통해 암호화된다.

• 다중 리전 암호

  • 여러 AWS 리전에 암호를 복제할 수 있고 AWS Secrets Manager 서비스가 기본 암호와 동기화된 읽기 전용 복제본을 유지해준다.

  • 특정 리전에 문제가 발생하면 암호 복제본을 독립 실행형 암호로 승격할 수 있다.

  • 다중 리전 앱을 구축하고 재해 복구 전략도 짤 수 있다.

  • 동일한 암호로 여러 리전에 분포된 동일한 RDS 데이터베이스에 접근할 수 있다.

ACM

• AWS Certificate Manager

• TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포해주는 서비스

• 오토 스케일링 그룹에 연결된 ALB를 HTTPS 엔드 포인트로 노출하려 한다면 ALB를 AWS Certificate Manager와 통합해 ALB에서 직접 TLS 인증서를 프로비저닝 및 유지관리하도록 하면 된다.

• ACM은 퍼블릭과 프라이빗 TLS 인증서를 모두 지원한다. 퍼블릭 TLS 인증서 사용 시에는 무료로 이용할 수 있다.

• 인증서를 자동으로 갱신할 수 있다.

• CLB, ALB, NLB, CloudFront 배포나 API Gateway와 모두 통합 가능하다.

• 퍼블릭 인증서일 경우 추출이 불가능하므로 EC2 인스턴스에서는 사용 불가능하다.

• 다음 과정으로 퍼블릭 인증서를 요청할 수 있다.

  • 인증서에 포함할 도메인 이름을 나열한다.

    • 전체 주소 도메인 이름(FQDN)도 될 수 있고 *.example.com과 같은 와일드카드 도메인도 가능하다.

    • 도메인 개수는 제한이 없다.

  • 유효성 검증 방법을 거친다.

    • 자동화를 목적으로 SSL 인증서를 자동 갱신하려면 DNS 검증을 쓸 수 있다. 이 때 DNS 구성에서 CNAME 레코드를 생성해 도메인 소유권을 증명해야 한다. Route 53을 사용할 경우 자동으로 수행된다.

    • ACM이 도메인에 등록된 연락처로 이메일을 보내 해당 인증서를 요청했는지 여부를 확인하는 이메일 검증을 쓸 수 있다.

  • 몇 시간 후 유효성 검증이 완료되면 인증서가 발행된다.

  • 인증서는 자동 갱신 목록에 추가되어 만료 60일 전에 자동으로 갱신되도록 한다.

• 다음 과정으로 이미 외부에서 생성된 퍼블릭 인증서를 ACM으로 가져올 수 있다.

  • 자동 갱신은 불가능하다. 따라서 인증서가 만료되기 전에 직접 새 인증서를 다시 가져와야 한다.

  • ACM 서비스는 기본적으로 만료 45일 전부터 매일매일 만료 이벤트를 EventBridge 서비스에 전송해준다. 며칠 전부터 알려줄지는 설정 가능하다.

  • AWS Config을 사용하여 acm-certificate-expiration-check라는 관리형 규칙을 관리할 수 있다. 이는 만료된 인증서를 확인하는 규칙이며 만료 일수를 조정할 수 있다. 규칙에 위배되는 인증서가 있을 경우 규정 비준수 이벤트가 EventBridge로 전송된다.

• ACM 서비스와 ALB 통합

  • 오토 스케일링 그룹과 매핑된 ALB와 ACM으로 프로비저닝 및 유지관리되는 TLS 인증서가 있을 때 HTTPS 요청을 받을 수 있다.

  • 만약 사용자가 HTTP 프로토콜로 액세스했다면, HTTPS로 리디렉션할 수 있다.

  • 사용자의 요청이 HTTPS 프로토콜을 통과하면 오토 스케일링 그룹으로 전달된다.

• API Gateway와 통합

  • ACM을 API Gateway와 통합하려면 API Gateway에 사용자 지정 도메인 이름이라는 리소스를 생성하고 설정해야 한다.

  • 다음 엔드포인트 유형 중 하나를 사용할 수 있다. ACM은 엣지 최적화 및 리전 엔드포인트에 적합하다.

    • 엣지 최적화(edge-optimized) 유형

      • 글로벌 클라이언트를 위한 유형으로 CloudFront 엣지 로케이션으로 요청을 라우팅하여 지연을 줄이는 방법이다.

      • 요청이 CloudFront에서 라우팅되고 TLS 인증서가 CloudFront 배포에 연결되기 때문에 TLS 인증서가 반드시 CloudFront와 같은 리전인 us-east-1에 생성되어야 한다.

      • Route 53에 CNAME이나 별칭(A-Alias) 레코드를 설정해야 한다.

    • 리전(regional) 엔드 포인트 유형

      • 클라이언트가 API Gateway와 같은 리전에 있을 때 자체 CloudFront 배포를 생성하여 캐싱 및 배포 전략을 제어할 수 있다.

      • TLS 인증서가 같은 리전에 속해 있어야 한다.

      • Route 53에 CNAME이나 별칭(A-Alias) 레코드를 설정해야 한다.

    • 프라이빗(private) API Gateway 엔드포인트

      • 인터페이스 VPC 엔드 포인트(ENI)를 통해 VPC 내부에만 액세스할 수 있다.

      • API Gateway에 대한 액세스를 정의하는 리소스 정책이 필요하다.

WAF

• Web Application Firewall

• 7계층에서 일어나는 일반적인 웹 취약점 공격으로부터 웹 애플리케이션을 보호한다.

• 웹 애플리케이션 방화벽(WAF)의 배포는 ALB, API Gateway, CloudFront, AppSync GraphQL API, Cognito 사용자 풀에 할 수 있다.

• 방화벽을 배포한 후 웹 액세스 제어 목록(ACL)과 규칙을 정의해야 한다.

  • IP 주소를 기반으로 필터링하기 위해 IP 세트를 정의할 수 있으며 최대 10,000개의 IP 주소를 가질 수 있다.

  • HTTP 헤더와 본문에 기반해 필터링할 수도 있고 URI 문자열을 조건으로 두어 SQL 주입, 크로스 사이트 스크립팅(XSS) 등의 일반적인 공격을 차단할 수 있다.

  • 용량에 제약을 걸어 요청이 최대 2MB를 넘지 않게 하거나 지역 일치(Geo-match) 조건을 두어 특정 국가를 허용 또는 차단할 수 있다.

  • 속도 기반 규칙을 설정하면 IP당 요청 수를 측정하여 디도스 공격을 막을 수 있다.

  • 웹 ACL은 리전에만 적용되며, CloudFront는 글로벌로 정의된다.

  • 규칙 그룹을 통해 여러 웹 ACL에 추가할 수 있는 재사용 가능한 규칙을 모아둘 수 있다.

• 애플리케이션에 고정 IP를 사용하면서 로드 밸런서와 함께 WAF를 사용하려 한다면, ALB가 필요하다. 하지만 ALB는 고정 IP 기능을 제공하지 않는다. 이 경우 AWS Global Accelerator와 통합해 고정 IP를 할당받은 다음 ALB에서 WAF를 활성화하면 된다.

Shield

• 디도스 공격으로부터 스스로를 보호하기 위한 서비스

• 스탠다드 서비스

  • 모든 AWS 고객에게 무료로 활성화되어 있는 서비스

  • SYN/UDP Floods나 반사 공격 및 L3/L4 공격으로부터 보호해준다.

• 어드밴스드 서비스

  • 선택적으로 제공되는 디도스 완화 서비스

  • 조직당 월 3,000달러를 지불해야 한다.

  • 더욱 정교한 디도스 공격을 막아주며 Amazon EC2, ELB Amazon CloudFront, AWS Global Accelerator, Route 53를 보호한다.

  • AWS 디도스 대응 팀이 항시 대기하고 있어 공격을 받았을 때 지원을 받을 수 있다.

  • 자동 애플리케이션 계층 디도스 완화 기능을 제공하여 자동으로 WAF 규칙을 생성, 평가, 배포함으로써 L7 공격을 완화할 수 있다.

Firewall Manager

• AWS Organizations에 있는 모든 계정의 방화벽 규칙을 관리하는 서비스

• 여러 계정의 규칙을 동시에 관리할 수 있다.

• 보안 정책을 설정할 수 있다. 정책은 리전 수준에서 생성되며, 조직에 있는 모든 계정에 적용된다.

  • 보안 정책이란 보안 규칙의 집합이다. 아래 규칙들이 추가될 수 있다.

  • ALB, API Gateway CloudFront 등에 적용되는 웹 애플리케이션 방화벽(WAF) 규칙

  • ALB, CLB, NLB, 엘라스틱 IP CloudFront를 위한 AWS Shield 어드밴스드 규칙

  • EC2, ALB, VPC의 ENI 리소스를 위한 보안 그룹

  • VPC 수준의 AWS Network Firewall

  • Amazon Route 53 Resolver DNS Firewall

• 모든 계정의 모든 지정된 리소스에 대해 규칙이 적용된다. 만약 조직에서 ALB에 대한 WAF 규칙을 생성한 다음 새 ALB를 생성하는 경우, AWS Firewall Manager에서 자동으로 새 ALB에도 같은 규칙을 적용해준다.

WAF vs FirewallManager vs Shield

• 리소스별 보호를 구성하는 데에는 WAF가 적절하다.

• 여러 계정에서 WAF를 사용하고 있으며 설정을 가속하고 새 리소스 보호를 자동화하려면 Firewall Manager로 WAF 규칙을 관리하면 된다.

• Shield Advanced는 디도스 공격으로부터 고객을 보호하고 WAF의 기능 외에도 더 많은 기능을 제공한다.

• Firewall Manager는 모든 계정에 Shield 어드밴스드를 배포할 때 도움이 된다.

• VPC 내부의 트래픽 흐름 검사 및 트래픽 필터링 같은 작업을 수행하려면 AWS 네트워크 방화벽을 사용해야 한다.

DDoS Protection

• CloudFront는 엣지 로케이션에서 사용한다. 웹 애플리케이션 전송도 엣지에서 일어나므로 SYN Flood나 UDP 반사 공격과 같은 DDoS 일반 공격은 Shield 설정으로 막을 수 있다.

• Global Accelerator를 사용하면 전 세계의 엣지를 통해 애플리케이션에 액세스할 수 있다. Shield와 완전히 통합되므로, CloudFront가 백엔드와 호환되지 않는 경우에도 DDoS 공격 방어를 할 수 있다.

• Route 53를 사용하는 경우 엣지에 도메인 이름 변환을 글로벌로 설정하여 DNS에도 DDoS 보호 메커니즘을 적용할 수 있다.

• 인프라 계층 방어

  • Global Accelerator, Route 53, ELB 를 통해 높은 트래픽으로부터 Amazon EC2 인스턴스를 보호할 수 있다.

  • 트래픽을 EC2 인스턴스에 도달하기 전에 관리할 수 있다. EC2 인스턴스에서 오토 스케일링 기능을 활성화하면 오토 스케일링 그룹에 트래픽이 도달한다고 해도 자동으로 확장하여 애플리케이션에서 더 큰 부하를 수용할 수 있다.

• 애플리케이션 계층 방어

  • CloudFront는 정적 콘텐츠 전송 시 엣지 로케이션에서 전송하여 백엔드에 영향이 가지 않도록 한다.

  • ALB나 CloudFront에 WAF를 사용하여 요청 서명에 따라 악성 요청을 필터링 및 차단할 수 있다.

  • WAF rate-based 규칙을 사용하면 악성 사용자의 IP를 자동으로 차단할 수 있다.

  • CloudFront로는 특정 지역을 차단할 수 있다.

  • Shield Advanced 서비스를 활성화하여 자동으로 WAF 규칙을 생성하여 7계층 공격을 완화할 수 있다.

• 공격 지점 줄이기

  • CloudFront, API Gateway, ELB를 사용해 백엔드 리소스를 숨긴다.

  • 보안 그룹과 네트워크 ACL 등을 설정하여 특정 IP의 트래픽을 필터링할 수 있다.

  • Elastic IP도 AWS Shield Advanced로 보호할 수 있다.

  • API 엔드 포인트를 보호하려면 API Gateway를 사용하면서 엣지 최적화 모드, CloudFront와 통합하여 리전 모드를 사용한다면 DDoS 보호에 관한 제어 기능이 강화된다.

  • API Gateway에 WAF를 사용하는 경우 모든 HTTP 요청에 대해 버스트 제한과 헤더 필터링, 특정 API 키 사용 등 조건을 통해 필터링할 수 있다.

GuardDuty

• 머신러닝 기반의 지능형 위협 탐지를 이용해 AWS 계정을 보호할 수 있다.

• 서드파티 데이터를 사용해서 위협을 탐지한다.

• GuardDuty는 다음 데이터들을 감시한다.

  • CloudTrail Event Logs 데이터에서 비정상적인 API 호출이나 무단 배포 이력을 탐색한다.

    • CloudTrail Manatement Events: VPC 서브넷 생성 이벤트 등을 포함한다.

    • CloudTrail S3 Data Events: GetObject, ListObject, DeleteObject 이벤트 등을 포함한다.

  • VPC Flow Logs에서 비정상적인 인터넷 트래픽, IP 주소를 탐색한다.

  • DNS 로그에서 DNS 쿼리 안에서 인코딩된 데이터를 전송하는 EC2 인스턴스를 탐색한다.

  • EKS 감사 로그나 RDS 및 Aurora 로그인 이벤트, EBS, 람다, S3 데이터 이벤트 등 다른 입력 데이터 소스도 탐색할 수 있다.

• EventBridge 규칙을 설정해서, 발견된 결과에 대해 자동으로 알림을 받을 수 있다.

• 전문적인 탐지 기능이 제공되어 암호화폐 공격을 방어하기 좋다.

Inspector

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

• EC2 인스턴스를 평가하기 위해 시스템 관리자 에이전트(AWS SSM Agent)를 활용한다. Amazon Inspector는 의도되지 않은 네트워크 접근 가능성에 대해 분석하고, 실행 중인 운영 체제에서 알려진 취약점을 분석한다.

• 컨테이너 이미지가 Amazon ECR로 푸시되면 Amazon Inspector가 알려진 취약점에 대해 검사할 수 있다.

• Lambda 함수가 배포될 때 함수 코드 및 패키지 종속성에서 소프트웨어 취약성을 다시 분석한다.

• 작업이 완료되면 결과를 AWS 보안 허브에 보고하고, 결과 및 결과 이벤트를 Amazon Event Bridge로 보낸다. 이를 통해 인프라에 있는 취약점을 모아서 볼 수 있다.

• 패키지 취약성을 분석하기 위해 취약성 데이터베이스인 CVE를 참고한다.

• 만약 CVE 데이터베이스가 업데이트된다면 Amazon Inspector는 자동으로 다시 실행되어 모든 인프라를 한 번 더 테스트한다.

• 실행 시 우선 순위를 정하기 위해 risk score가 모든 취약성과 연관된다.

Macie

• 완전 관리형 데이터 보안 및 데이터 프라이버시 서비스

• 머신러닝과 패턴 매칭을 이용해 AWS 리소스에 개인식별정보, 즉 PII 같은 민감정보가 존재한다면 EventBridge로 알람을 보내는 기능을 제공한다.

• EventBridge에 들어온 이벤트는 SNS 토픽이나 람다 함수와 통합할 수 있다.

• 간단하게 원하는 S3 버킷만 지정하여 활성화할 수 있다.