728x90
반응형




암호화 종류

  • 전송중 암호화 (TLS/SSL)
  1. public network를 경유하게 되면 source-target사이의 중간 서버를 이용하게 되는데, 해당 서버를 통해 중간에 패킷이 탈취되어 정보가 유출되는 것을 방지하기 위해 활용
  2. 인증서를 통해 암호화/복호화 진행
  3. 전송중 암호화가 적용된 경우, HTTPS 프로토콜 활용




  • 저장중 암호화 (Server-Side 암호화)
  1. 서버가 데이터를 받은 후 어딘가로 저장되기 위해 암호화
  2. 저장된 암호화 데이터를 고객에게 응답으로 주기 위해 복호화
  3. 암호화/복호화는 특정 key를 통해 진행 (특정 key를 관리하는 방법은 다양함)




  • Client-side 암호화
  1. 서버는 해당 암호화 데이터를 복호화할 수 없음 (only client) -> 서버를 신뢰할 수 없는 경우에 활용
  2. 암호화 key도 client에서 관리




KMS (Key Management Service)

  • 특징
  1. KMS의 권한기능이 IAM과 통합되어 있음
  2. KMS Key를 이용한 API호출은 모두 CloudTrail에 의해 모니터링됨
  3. 활용이 간단함 (EBS에 KMS적용을 위해 활성화 체크만 하면 됨)
  4. API호출을 통해서도 KMS Key 활용 가능


  • KMS Keys Types
  1. Symmetric (대칭, AES-256 key)
    • 하나의 key로 암호화/복호화 모두 수행
    • key 자체에 직접 접근은 불가하나 key관련 AWS API를 이용할 수는 있음
  2. Asymmetric (비대칭, RSA & ECC key pairs)
    • key 2개, 하나는 암호화를 위한 public key, 하나는 복호화를 위한 private key
    • public key는 직접 접근 가능하나, private key는 API를 이용한 접근밖에 허용하지 않음
    • AWS Cloud 외부의 사용자가 KMS key를 이용해 암호화하려는 경우 주로 활용됨


  • KMS Key 종류 (서비스에 대한 API 호출 건당 비용 청구)
  1. AWS 소유 key
    • SSE-S3, SSE-SQS, SSE-DDB (DynamoDB) : SSE 타입의 암호화 사용
    • 사용자가 볼 수 없음
  2. AWS 관리형 key
    • aws/service-name
    • 자동 key rotation
  3. 고객 관리형 key
    • 한달에 1달러 이상의 비용
    • 수작업 key rotation -> alias 설정 필요


  • region단위의 KMS key 다른 region으로 이동 방법
  1. KMS key가 저장되어 있는 EBS 볼륨의 Snapshot 생성
  2. 생성된 Snapshot을 다른 region으로 옮길 때, 해당 region의 KMS key로 Snapshot 암호화
  3. EBS Volume을 생성할 때, 해당 region의 KMS key로 복호화




  • KMS Key Policies
  1. KMS Key에 대한 접근을 관리하기 위한 정책
  2. KMS Key에 대한 정책이 없을 경우, 아무도 해당 Key에 접근하지 못함
  3. Default Policy
    • 계정에 있는 모든 사람들이 KMS Key에 접근할 수 있음
  4. Custom Policy
    • KMS에 접근할 수 있는 사용자와 Role을 정의
    • Key를 누가 관리할 수 있는지 정의
    • 다른 계정에서 Key에 접근하려는 경우 유용한 정책 (ex. 암호화된 Snapshot을 계정간에 복사하고 싶을 때 사용)


  • 교차계정을 위한 KMS Key Policy




KMS Multi-Region Keys

  • 특정 Region에 기본키를 두고 다른 다수의 Region에 해당 키를 복제하는 방식 (key id가 모두 동일)

  • 특정 region에서 암호화 후, 다른 region에서 복호화 가능 -> not global

  • 각 region의 key는 각각 자체적인 정책으로 독립적으로 관리됨
  • 특정 사례를 제외하고 단일 region key 활용 권장




  • Use case : DynamoDB Global Tables and KMS Multi-Region Keys Client-Side Encryption
    : Client-Side Encryption 사용을 통해 데이터의 특정 필드(컬럼)나 속성을 DB관리자로부터 보호 (client에서만 복호화 가능), Multi-Region의 Global DynamoDB 데이터에 접근 가능




S3 Replication Encryption

  • S3 복제가 생성될 때, 암호화되지 않는 객체와 SSE-S3로 암호화된 객체는 복제됨
  • SSE-KMS로 암호화된 객체를 복제할 때에는 target bucket에 대해서 어떤 KMS Key를 사용할 것인지 선택하고 활성화해야 함.
  • target KMS key에 KMS Policy 적용 필요
  • 복제 시, 암/복호화를 위해 IAM Role 생성 필요
  • S3에 Multi-Region key 적용은 가능하나 실질적인 효과는 없음


AMI Sharing Process Encrypted via KMS

  • A계정의 암호화된 AMI를 B계정의 EC2에서 실행하는 방법
  1. AMI는 KMS key로 암호화되어 있음
  2. B계정의 Launch Permission에서 실행하고자 하는 AMI를 허용
  3. KMS key 공유를 위해 default key policy 적용
  4. B계정에서 A계정의 key를 활용할 수 있도록 IAM Role 생성 (DescribeKey, ReEncrypted, CreateGrant, Decrypt API)




SSM Parameter Store (SSM)

  • SSM Parameter Store (SSM) : application의 설정을 KMS key를 통해 암호화하여 저장할 수 있는 store




  • 특징
  1. App의 설정이나 secret을 암호화하여 저장
  2. Serverless
  3. 확장성, 내구성
  4. 저장된 설정의 version을 추적할 수 있음
  5. IAM을 통한 보안설정 가능
  6. EventBridge를 통한 알림 기능 가능
  7. CloudFormation을 통해 SSM의 매개변수가 입력될 수 있음
  8. AWS 계정 내 모든 파라미터를 중앙에서 한번에 관리


  • SSM 계층 구조
    : SSM 저장소를 구조화할 수 있음, 디렉토리 접근 형태로 SSM저장소에 접근하여 원하는 파라미터 정보를 가져올 수 있음




  • Secret Manager Tier




  • 고급 tier에서만 사용할 수 있는 Parameter Policy
  1. TTL를 파라미터로 입력할 수 있음 -> 비밀번호와 같은 정보를 update하거나 삭제하도록 강제 -> SSM으로 TTL설정을 강제한 후에 EventBridge를 통해 TTL 만료여부를 확인하여 알림




AWS Secrets Manager

  • AWS Secrets Manager : AWS 암호 저장 서비스 (ex. DB 계정 비밀번호 등)


  • 특징

  1. 특정 주기마다 강제로 암호를 교체하는 기능이 있음
  2. 자동 암호 변경을 위해 Lambda Function 정의 필요
  3. RDS, Aurora 등과 호환 가능 -> 호환되는 서비스에 접근하기 위한 암호를 저장하고, 해당 암호가 변경되었을 때, RDS와 같은 서비스에도 동기화됨
  4. 암호는 KMS를 통해 암호화됨


  • Multi-Region Secrets
  1. 다른 Region에 암호 복사 -> 기존 암호를 다른 Region에 동기화하여 복사 진행
  2. 기존 암호에 문제가 생기면 다른 복제된 암호가 Primary로 승격됨
  3. 재해복구 전략 수립 가능


AWS Certificate Manager (ACM)

  • AWS Certificate Manager (ACM) : TLS인증서를 AWS에서 프로비저닝하고 관리 및 배포하게 해줌 -> HTTPS의 endpoint가 되는 ALB가 직접 ACM에 접근하여 TLS를 프로비저닝하고 관리 및 배포할 수 있게됨




  • 특징
  1. public/private TLS 모두 지원
  2. TLS 자동 갱신기능
  3. ELB에 TLS 인증서를 불러올 수 있음 (CLB/ALB/NLB)
  4. CloudFront, API Gateway, APIs 등에서도 통합 가능 (EC2와는 통합 불가)


  • Public 인증서가 요청되는 과정
  1. 인증서가 포함한 도메인의 목록 나열
  2. 유효성 검증방법 (DNS 검증, EMAIL 검증) 결정 -> 관리자 선택
    • DNS 검증의 경우, 해당 DNS 구성에서 CNAME 레코드를 생성하여 도메인 소유권을 증명해야 함 -> Route53 + ACM
  3. 유효성 검증이 완료되면 인증서가 발행됨
  4. 발행된 인증서는 자동 갱신 목록에 추가됨


  • ACM으로부터 public 인증서를 가져오는 방법
  1. ACM 외부에서 생성된 인증서를 ACM으로 가져올 수 있음 -> 자동갱신은 불가
  2. 인증서 만료 45일전부터 만료메일 발송에 대한 알림을 EventBridge에 전송 -> EventBridge는 SNS나 SQS, Lambda를 통해 트리거 발생
  3. AWS Config를 통해 인증서 만료 규칙을 설정 (acm-certificate-expiration-check) -> ACM 서비스를 검사하여 해당 규칙에 위배되는 인증서가 있을 경우, EventBridge에 이벤트 전송




  • ACM + ALB : HTTP요청이 오면 ALB가 HTTPS로 리다이렉트 해줌




  • ACM + API Gateway
  1. Endpoint 유형
    • Edge-Optimized (default) : for global client, 요청을 CrontFront Edge Location에 우선적으로 보내지게 하는 방법이고 이후 하나의 Region에 있는 API Gateway에 요청이 전달됨
    • Regional : client와 API Gateway가 같은 region에 있는 경우, CloudFront 사용은 불가하지만 자체 CloudFront 캐싱 및 배포전략을 사용할 수는 있음
    • Private : VPC endpoint인 ENI를 통해 VPC 내부에만 접속할 수 있음 -> API Gateway에 대한 리소스 정책 필요
  2. 통합 방법
    1. API Gateway에 사용자 지정 도메인을 정의함
    2. Edge-Optimized 유형의 경우, CloudFront로 먼저 요청이 전달되기 때문에 TLS 인증서(ACM)가 CloudFront와 같은 Region에 있어야 함
    3. Route53에 CNAME이나 A-Alias 레코드가 도메인을 가리키도록 설정
    4. Regional 유형의 경우, 요청이 바로 API Gateway로 가기 떄문에 TLS 인증서(ACM)가 API Gateway와 같은 Region에 있어야 함
    5. Route53에 CNAME이나 A-Alias 레코드가 도메인을 가리키도록 설정




Web Application Firewall (AWS WAF)

  • Web Application Firewall (AWS WAF) : 7번째 계층(HTTP)에서 일어나는 웹 취약점 공격으로부터 application을 보호


  • WAF 배포가 적용되는 서비스 (배포 후, ACL(Web Access Control List, IP주소기반 필터링하는 등의 규칙)이 적용되어야 함) -> ACL은 하나의 Region에만 적용되고 CloudFront는 Global로 적용됨)

  1. ALB
  2. API Gateway
  3. CloudFront
  4. AppSync GraphQL API
  5. Congnito User Pool


  • Use case : 고정IP가 지원되는 WAF적용된 Load Balancer -> 고정IP가 지원되는 NLB에는 WAF가 적용될 수 없음

  • ALB활용 후, Global Accelator를 통해 고정 IP를 할당받은 후 WAF를 활성화 -> WAF에는 고정ip에 대한 ACL 정의




AWS Sheild

  • AWS Sheild : DDoS 공격으로부터 보호하기 위한 서비스


  • 특징

  1. SYN/UDP 공격이나, layer3/layer4에서의 공격을 보호해줌 -> AWS Sheild Standard
  2. 조직당 월 3,000달러, 정교한 DDoS 공격 방지, 자동으로 WAF규칙 생성, AWS DDoS 대응팀 항시 대기, DDoS 공격으로 인한 요금상승 감면 -> AWS Sheild Advanced


AWS Firewall Manager

  • AWS Firewall Manager : AWS 조직내의 모든 게정에 대한 방화벽 규칙을 관리하는 서비스


  • 특징

  1. 보안규칙의 집합인 보안정책 설정 가능 -> WAF Rule, AWS Sheild Advanced, Security Groups, AWS Network Firewall (VPC Level), Route53 DNS Firewall 포함
  2. region level의 정책 생성
  3. 조직에 등록된 모든 게정에 적용
  4. 새로운 ALB 서비스를 런칭한다고 해도 기존에 생성되어 있는 보안 규칙을 자동으로 적용시켜줌


  • WAF vs Firewall Manager vs Sheild
  1. WAF : Web ACL Rule 설정 -> 리소스별 보호 구성에 적절
  2. Firewall Manager : 여러 계정에서 WAF를 사용하고 WAF 구성 적용 및 새로 생성된 리소스 보호를 자동화에 적절 -> 모든 계정과 모든 리소스를 기존 정책으로 자동 적용시켜줌
  3. Sheild Advanced : DDoS 공격으로부터 고객을 보호하고 대응팀 지원, WAF규칙 자동생성 등의 부가적인 기능 제공


Best Practice for DDoS Resiliency Edge Location Mitigation

  • Edge 유형에 따른 DDoS 보호 -> 어떤 백엔드를 활용하더라도 Edge에서 DDoS공격을 막을 수 있음
  1. CloudFront
    • Shield 설정을 통해 SYN floods, UDP reflection과 같은 DDoS 일반 공격은 방어 가능
  2. Global Accelerator
    • Shield와 완전히 통합되어 DDoS 공격 방어에 유용함
  3. Route53
    • 도메인 이름 변환을 global로 설정 -> DNS에도 DDoS 보호 메커니즘 적용 가능


  • 인프라 레벨의 DDoS 완화
  1. CloudFront, Global Accelerator, Route53, ELB를 활용하면 많은 트래픽으로부터 EC2를 보호할 수 있음
  2. ASG를 활용하면 많은 트래픽이 들어와도 스케일을 확장하여 방어할 수 있음 -> ELB가 여러 인스턴스에 부하를 자동으로 분산시킴


  • Application 계층 방어
  1. 악성 요청을 감지하고 필터링
  2. 정적 컨텐츠는 CloudFront에서 보냄으로써 백엔드를 보호
  3. ALB나 CloudFront + WAF를 사용 -> WAF에서 여러 관리 규칙을 설정하여 필터링
  4. Sheild Advanced을 통해 자동으로 WAF 규칙 생성


  • 공격 지점을 줄이는 방법
  1. CloudFront, API Gateway, ELB 활용하여 백엔드를 숨김
  2. 보안그룹과 네트워크 ACL 등 설정하여 특정 ip를 필터링


Amazon GuardDuty

  • Amazon GuardDuty : AWS 계정을 보호하기 위한 지능형 위협 탐지 서비스


  • 특징

  1. 머신러닝 알고리즘을 통한 이상 탐지
  2. 서드파티 데이터를 통한 이상 탐지
  3. CloudTrail Event logs, DNS logs 등과 같은 log 데이터를 확인하여 비정상적인 API 호출을 탐지
  4. EventBridge규칙을 설정하여 이상 탐지될 경우, 자동으로 알림을 발송할 수 있음 -> SNS, Lambda 활용
  5. 암호화폐 공격을 방어하기 위한 좋은 서비스




Amazon Inspector

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


  • EC2 예시

  1. EC2에 SSM Agent 설치
  2. Agent는 인스턴스 보안 평가 실시 (비정상 네트워크, 취약점 분석 등)


  • 특징
  1. EC2에 Agent를 설치하여 실행
  2. 컨테이너 이미지를 ECR로 푸시할 때 실행 -> 이미지에 대한 취약점 검사
  3. Lambda가 실행될 때 실행 -> 종속성 등에 대한 취약점 검사
  4. 검사가 완료되면 AWS 보안 허브에 보고
  5. 검사 결과를 Amazon EventBridge에 전송 -> 자동화 구현




Amazon Macie

  • Amazon Macie : 머신러닝을 통한 패턴 매칭을 이용해서 AWS에 있는 고객의 민감 데이터를 발견하고 보호

반응형

'개발 > AWS' 카테고리의 다른 글

[AWS] VPC (Virtual Private Cloud)  (0) 2024.07.06
[AWS] IAM 고급  (0) 2024.06.25
[AWS] CloudWatch and CloudTail  (1) 2024.06.11
[AWS] AWS Database  (0) 2024.06.08
[AWS] Serverless (Lambda/DynamoDB/API Gateway)  (1) 2024.06.08

+ Recent posts

티스토리툴바