목차
암호화 101
- 전송 중 암호화
- 매우 민감한 기밀 내용인 경우 전송 중 암호화를 사용
- 예시) 신용카드로 온라인 결제
- HTTPS 웹사이트라면 전송 중 암호화가 되는 것
- 서버가 데이터를 받으면 복호화를 함
- 전송하는 사람과 서버만이 암호화와 복호화를 하는 방법을 알고 있음
- SSL 암호화와 복호화는 모든 라이브러리가 이 작업을 해주기 때문에 직접 처리 할 필요가 없었던 것
- 매우 민감한 기밀 내용인 경우 전송 중 암호화를 사용
- 서버 측 저장 데이터 암호화
- 데이터가 서버에 수신 된 후 암호화 하는 것
- 그래서 그 전에는 서버가 데이터를 받아서 복호화를 하고, 암호 복호화된 형식에 사용
- 서버는 데이터를 디스크에 저장한다.
- 그래서 서버가 데이터를 암호화된 형태로 저장 함
- 서버가 해킹당해도 데이터를 지킬수있음
- 클라이언트로 다시 전송되기 전에 복호화를 한다.
- 데이터 키라고 불리는 키 덕분에 암호화 된 형태로 저장
- 암호 키와 해독 키는 주로 KMS에 저장 된다.
- 서버는 KMS와 통신이 되어야한다.
- 예시) EBS 볼륨에서 데이터 받아서 암호화 클라이언트에게 보낼때 복호화
- 데이터가 서버에 수신 된 후 암호화 하는 것
- 클라이언트 측 암호화
- 데이터를 클라이언트가 암호화 함
- 서버는 그 데이터를 절대 복호화 할 수 없음
- 데이터를 받는 클라이언트에 의해 복호화 됨
- 즉 서버는 데이터를 저장 하지만 복호화를 못한다는 것
- 이를 위해 봉투 암호화를 활용 할 수 있다.
KMS 개요
- AWS 서비스에서 암호화는 거의 KMS 암호화를 이야기 하는 것
- KMS는 승인에 관해 IAM과 통합되어 있음
- KMS로 되어있으면 쉽게 제어를 할 수 있음
- 강점
- CloudTrail을 통해 키를 사용하기 위해 이루어진 모든 API 호출을 감사 할 수 있다.
- 비밀 데이터가 있으면 평문 텍스트에 절대로 저장하면 안된다
- 특히 코드 안에 두면 안된다.
- AWS CLI나 SDK를 사용해서 API 호출을 통해서 사용 가능
- 모든 비밀을 KMS 키로 암호화 할 수 있음
- 그걸로 코드나 환경 변수에 저장 할 수 있음
- KMS 키
- 대칭 KMS 키
- 데이터를 암호화, 복호화 하는데 한개의 키로 함
- 대부분 서비스가 대칭 키를 사용
- 비대칭 KMS 키
- 키가 2개가 있음 암호화(퍼블릭 키), 복호화(프라이빗 키)
- 퍼블릭 키를 다운로드 할 수 있지만
- 복호화 키는 액세스가 불가능하고 API 호출로만 사용 가능
-
- 데이터를 퍼블릭 키를 사용해서 암호화
-
- 프라이빗 키로 데이터를 복호화
- 대칭 KMS 키
- 다양한 타입의 키
- SSE-S3, SSE DynamoDB 타입
- S3, DynamoDB 서비스 사용시 쓰는 키
- AWS 관리형 키
- 앞에 aws/가 있고 서비스 이름이 나온다.
- 키가 지정된 서비스 안에서만 사용 가능
- 고객 관리형 키
- 한달에 1달러를 지불 해야하는 키
- SSE-S3, SSE DynamoDB 타입
- 자동 키 순환
- 자동으로 1년 마다 순환이 된다.
- 임포트한 KMS 키면 수작업으로 순환 해야한다.
- 범위
- KMS 키의 범위는 리전이다.
- 다른 리전에 복사하기 위한 단계 예시) EBS 볼륨
-
- EBS 볼륨의 스냅샷을 찍는다.
-
- 스냅샷 자체도 동일한 KMS키로 암호화 됨
-
- 다른 KMS 키를 사용해서 그 스냅샷을 다시 암호화
- 다시 암호화 하는건 AWS가 해준다.
-
- 동일한 KMS 키가 두 리전에 있을 수 없음
- KMS 키 정책
- KMS 키에 대한 액세스를 관리하기 위한 정책
- 기본 정책
- 특정한 커스텀 KMS 키 정책을 제공하지 않을 때 생성 됨
- 기본값은 계정에 있는 모든 사람이 키에 액세스에 가능하다.
- 커스텀 KMS 키 정책
- 사용자와 역할을 정의해서 키를 누가 관리하는지 정의 할 수 있음
- 교차 계정 액세스를 할려는 경우 유용함
- 다른 계정이 우리의 KMS 키를 사용하도록 승인이 가능하기 때문
KMS - Mutil-Region Keys
- KMS에는 다중 리전 키를 둘 수 있음
- 선택 된 한 리전에 기본키를 갖고
- 다른 리전에 복제를 하는 방식임
- 키 ID가 완전히 똑같음
- 한 리전에서 암호화하고 다른 리전에서 복호화가 가능
- 다중 리전키의 핵심
- 한 리전에서 암호화
- 다른 리전에서 복호화
- 다음 리전으로 복제, 교차 리전 API시 데이터를 재 암호화 하지 않아도 됨
- 전역(글로벌)로 사용 할 수 없음
- 키본 키의 복제본이 있는 것임
- 다중 리전 키 사용은 권장하지 않음
- 사용 사례
- 전역 클라이언트 측 암호화가 있는데
- 한 리전에서 암호화 하고
- 다른 리전에서 복호화 한다.
- DyanmoDB Global
- Aurora Global
- 왜 클라이언트 측 암호화하는지?
- 중요한 건 전체 테이블만 암호화 하는게 아니라는 것
- 저장 데이터 암호화 이므로 테이블의 속성을 암호화해서
- 특정 클라이언트만 사용 할 수 있게 된다.
- 전역 테이블 덕분에 데이터뿐만 아니라 암호화 키도 함께 복제가 가능
- 데이터베이스에 액세스 할 수 있는 DB 관리자가
- 암호화된 열에 액세스 할 때 KMS 키 액세스 권한이 없으면
- 데이터를 읽을 수 없다.
S3 암호화된 복제
- 한 버킷에서 다른 버킷으로 S3 복제를 활성화 하면
- 암호화 되지 않은 객체와 SSE-S3로 암호화된 객체가 기본으로 복제 된다.
- 고객 제공 키인 SSE-C로 암호화한 객체도 복제가 가능
- SSE-KMS로 암호화된 객체도 있음
- 기본적으로 복제 안됨, 옵션 활성화를 해야함
- 어떤 KMS 키로 어떤 객체를 암호화 할 지 지정 필요
-
- KMS 키 정책을 대상 키에 적용
-
- S3 복제 서비스를 허용하는 IAM 역할 생성 필요
-
- 소스 버킷의 데이터를 먼저 복호화 하고
-
- 대상 KMS키로 대상 버킷을 다시 암호화 한다.
암호화된 AMI 공유 프로세스
- AMI를 다른 계정과 공유하는 과정에 관함
- AMI가 KMS 키로 암호화가 되어있고
- AMI는 소스 계정에 있고 KMS 키로 암호화 된 것
- 어떻게 A계정의 AMI를 B계정의 EC2 인스턴스로 시작을 하는가?
-
- 시작 권한으로 AMI 속성 수정
- B계정에서 AMI를 시작하도록 허용
-
- B계정에서 사용하게 KMS 키 공유 필요
- 일반적으로 키 정책으로 실행됨
-
- B계정에서 KMS키와 AMI를 모두 사용하는 권한이나 역할을 가진 사용자 생성
-
- B계정에서 EC2 인스턴스 시작
-
SSM 매개변수 저장소 개요
- 구성 및 암호를 위한 보안 스토리지
- 구성을 암호화 할지 선택 할 수 있다.
- KMS 서비스를 이용해 암호를 만들 수 있다.
- 서버 리스 (확장성, 내구성)이 있음
- SDK 사용에도 좋다.
- 매개변수 업데이트 할 시 구성과 암호의 버전 추적 가능
- IAM을 통해 보안 제공
- EventBridge로 알람 받기 가능
- CloudFormation과 통합 가능
- 계층 구조로 매개변수를 저장 할 수 있음
- 예시)
- my-app
- dev
- prod
- 사용시) my-app/dev/db-password
- my-app
- 예시)
- 고급 매개변수
- TTL
- 만료 기한을 추가 가능
- 업데이트나 삭제하도록 강제한다.
- 한번에 여러 정책을 할당할 수도 있음
- TTL
AWS Secrets Manager - 개요
- 암호를 저장하는 최신 서비스
- SSM과 다른 서비스 임
- X일마다 강제로 암호를 교체하는 기능이 있음
- 교체할 암호를 강제 생성 및 자동화 가능
- Lambda 함수를 정의해서 새 암호를 만들 수 있다.
- Amazon RDS MySQL PostgreSQL Aurora 등 통합이 가능
- 데이터베이스에 접근하기 위한 사용자 이름과 비밀번호 저장, 교체가 가능하다.
- 암호는 KMS 서비스를 통해 암호화 됨
- 다중 리전 암호
- 복수 AWS 리전에 암호를 복제 할 수 있음
- 기본 암호와 동기화된 읽기 전용 복제본을 유지 하는 것
- 기본키가 있는 리전에 문제가 생기면 다른 리전의 암호 복제본을 독립 실행형 암호로 승격이 가능
AWS Certificate Manager (ACM)
- TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포하게 해주는 서비스
- 예시
-
- ALB과 ACM을 통합
-
- ALB에서 직접 TLS 인증서를 프로비저닝, 유지관리
-
- 사용자가 HTTPS 프로토콜로 액세스 가능
-
- ACM은 퍼블릭, 프라이빗 TLS 인증서 모두 지원
- 인증서를 자동으로 갱신하는 기능도 있음
- 여러 AWS 서비스와 통합 되어 있음
- ELB
- ALB
- NLB
- CloudFront
- API Gateway
- ACM을 사용할 수 없는 곳이 하나 있는데 EC2 인스턴스임
- 퍼블릭 인증서일 때 추출이 안됨
- ACM을 통해 EC2 인스턴스 퍼블릭 인증서 생성 할 수 없다는 것
- Route 53
- ACM에서 CNAME을 주면은 레코드 생성해서 도메인 소유권 증명을 하면 ACM에서 인증서를 발행해준다.
- 퍼블릭 인증서는 어떻게 가져오나요?
-
- ACM 외부에서 생성된 인증서 (자동갱신 불가능)
-
- ACM에서 생성
-
- 인증서가 어떻게 만료되는지 아나요?
- EventBridge에 만료 45일 전부터 이벤트를 전송함
- AWS Config을 사용하면
- 관리형 규칙을 사용해서 ACM 서비스 검사
- 규칙에 위배된 인증서가 있을 때 EventBridge로 전송
웹 애플리케이션 방화벽
- 계층7(어플리케이션) 에서 일어나는 일반적인 웹 취약점 공격을 보호
- 계층7은 HTTP
- 계층4는 TCP/UDP 프로토콜
- ALB, API Gateway, CloudFront에서 사용이 가능
- 웹 액세스 제어 목록(ACL)과 규칙
- SQL 주입, XSS 등 일반적인 공격 차단도 가능
- IP세트 정의 가능
- 헤더와 본문 필터링 가능
- 용량에 제약 걸기 가능
- 지역 일치 조건
- 속도 기반 규칙으로 디도스 공격 방지
- 리전에만 적용됨, CloudFront는 글로벌로 정의
- 규칙 그룹
- 여러 웹 ACL에 추가 할 수 있는 재사용 가능한 규칙 모음
- 예시)
- 애플리케이션에 고정 IP를 사용하며, 로드밸런서와 WAF 사용 시
- WAF는 NLB(네트워크 로드 밸런서)지원을 안한다.
- WAF는 7계층(HTTP)만 되기때문
- NLB는 4계층(TCP/UDP)임
-
- 애플리케이션 로드 밸런서 고정 IP 할당
- AWS Global Accelerator로 고정 IP 할당 받음
-
- ALB에서 WAF 활성화
실드 - DDoS 보호
- 디도스 공격으로 스스로를 보호하기 위한 서비스
- 스탠다드 서비스
- AWS 고객에에게 무료로 활성화
- SYN/UDP Floods, 반사 공격
- L3/L4 공격으로 보호 해줌
- 어드밴스드 서비스
- 조직당 월 3,000달러 지불 필요
- 더욱 정교한 디도스 공격을 막아준다.
- EC2, CloudFront, Global Accelerator, Route 53 보호
- 디도스 대응 팀이 항시 대기 중
- 자동으로 WAF 규칙을 생성, 평가 배포하여 L7 공격 완화 해줌
Firewall Manager
- AWS 조직(Organizations)에 있는 모든 계정의 방화벽 규칙을 관리하는 서비스
- 여러 계정의 규칙을 동시에 관리 할 수 있음
- 보안 규칙의 집합인 보안 정책
- ALB, API Gateway, CloudFront 등에 적용되는 WAF 규칙
- ALB , CLB, NLB, Elastic IP, CloudFront를 위한 AWS Shield 규칙 등이 포함
- 모든 방화벽을 한 곳에서 관리할 수 있다.
- 정책은 리전 수준에서 생성
- 조직에 등록된 모든 계정에 적용 됨
- 예시)
- 새 ALB(애플리케이션 로드 밸런서)를 생성하면 자동으로 같은 규칙을 적용 해줌
- WAF, Firewall Manager, Shield 차이점
- WAF
- 리소스별 보호를 구성하는데 적절
- Firewal Manager
- 여러 계정에서 WAF를 사용 할 때 WAF 구성을 가속하고 새 리소스 보호 자동화때 적절
- 모든 계정에 Shield 어드밴스드 배포에 도움 줌
- Shield
- 디도스를 받을 때 적절
- WAF 규칙 자동 생성 할 수 있음
- WAF
Amazon GuardDuty
- 지능형 위협 탐지를 이용해서 AWS 계정 보호
- CloudTrail, Event Logs 같은 입력 데이터를 확인해서 비정상적인 API 호출, 무단 배포를 검색하는 것
- EventBridge 규칙으로 자동으로 알림 받기 가능
- 암호화폐 공격을 방어하기 아주 좋은 도구
Amazon Inspector
- 몇 군데 자동화된 보안 평가를 실행하는 서비스
- 취약점을 분석을 하는 것
- 예시)
- Lambda 소프트웨어 취약점 분석
- 컨테이너 이미지 ECR로 푸시되면 취약점 분석
- EC2 보안 평가
- 필요한 인프라만 지속적으로 스캔
Amazon Macie
- 데이터 보안 및 데이터 프라이버시 서비스, 머신러닝과 패턴 매칭으로 민감한 데이터를 발견하고 보호 한다.
- S3에 주민등록번호 있으면 Macie로 분석하고 Event Bridge로 결과를 알려주는것
'스터디 > AWS SAA' 카테고리의 다른 글
| 섹션 27: 네트워킹 - VPC (하) (0) | 2024.01.27 |
|---|---|
| 섹션 27: 네트워킹 - VPC (상) (0) | 2024.01.20 |
| 섹션 25: Identity and Access Management (IAM) - 고급 (0) | 2024.01.17 |
| 섹션 24: AWS 모니터링 및 감사: CloudWatch, CloudTrail 및 Config (0) | 2024.01.17 |
| 섹션 23: 머신 러닝 (0) | 2024.01.15 |
암호화 101
- 전송 중 암호화
- 매우 민감한 기밀 내용인 경우 전송 중 암호화를 사용
- 예시) 신용카드로 온라인 결제
- HTTPS 웹사이트라면 전송 중 암호화가 되는 것
- 서버가 데이터를 받으면 복호화를 함
- 전송하는 사람과 서버만이 암호화와 복호화를 하는 방법을 알고 있음
- SSL 암호화와 복호화는 모든 라이브러리가 이 작업을 해주기 때문에 직접 처리 할 필요가 없었던 것
- 매우 민감한 기밀 내용인 경우 전송 중 암호화를 사용
- 서버 측 저장 데이터 암호화
- 데이터가 서버에 수신 된 후 암호화 하는 것
- 그래서 그 전에는 서버가 데이터를 받아서 복호화를 하고, 암호 복호화된 형식에 사용
- 서버는 데이터를 디스크에 저장한다.
- 그래서 서버가 데이터를 암호화된 형태로 저장 함
- 서버가 해킹당해도 데이터를 지킬수있음
- 클라이언트로 다시 전송되기 전에 복호화를 한다.
- 데이터 키라고 불리는 키 덕분에 암호화 된 형태로 저장
- 암호 키와 해독 키는 주로 KMS에 저장 된다.
- 서버는 KMS와 통신이 되어야한다.
- 예시) EBS 볼륨에서 데이터 받아서 암호화 클라이언트에게 보낼때 복호화
- 데이터가 서버에 수신 된 후 암호화 하는 것
- 클라이언트 측 암호화
- 데이터를 클라이언트가 암호화 함
- 서버는 그 데이터를 절대 복호화 할 수 없음
- 데이터를 받는 클라이언트에 의해 복호화 됨
- 즉 서버는 데이터를 저장 하지만 복호화를 못한다는 것
- 이를 위해 봉투 암호화를 활용 할 수 있다.
KMS 개요
- AWS 서비스에서 암호화는 거의 KMS 암호화를 이야기 하는 것
- KMS는 승인에 관해 IAM과 통합되어 있음
- KMS로 되어있으면 쉽게 제어를 할 수 있음
- 강점
- CloudTrail을 통해 키를 사용하기 위해 이루어진 모든 API 호출을 감사 할 수 있다.
- 비밀 데이터가 있으면 평문 텍스트에 절대로 저장하면 안된다
- 특히 코드 안에 두면 안된다.
- AWS CLI나 SDK를 사용해서 API 호출을 통해서 사용 가능
- 모든 비밀을 KMS 키로 암호화 할 수 있음
- 그걸로 코드나 환경 변수에 저장 할 수 있음
- KMS 키
- 대칭 KMS 키
- 데이터를 암호화, 복호화 하는데 한개의 키로 함
- 대부분 서비스가 대칭 키를 사용
- 비대칭 KMS 키
- 키가 2개가 있음 암호화(퍼블릭 키), 복호화(프라이빗 키)
- 퍼블릭 키를 다운로드 할 수 있지만
- 복호화 키는 액세스가 불가능하고 API 호출로만 사용 가능
-
- 데이터를 퍼블릭 키를 사용해서 암호화
-
- 프라이빗 키로 데이터를 복호화
- 대칭 KMS 키
- 다양한 타입의 키
- SSE-S3, SSE DynamoDB 타입
- S3, DynamoDB 서비스 사용시 쓰는 키
- AWS 관리형 키
- 앞에 aws/가 있고 서비스 이름이 나온다.
- 키가 지정된 서비스 안에서만 사용 가능
- 고객 관리형 키
- 한달에 1달러를 지불 해야하는 키
- SSE-S3, SSE DynamoDB 타입
- 자동 키 순환
- 자동으로 1년 마다 순환이 된다.
- 임포트한 KMS 키면 수작업으로 순환 해야한다.
- 범위
- KMS 키의 범위는 리전이다.
- 다른 리전에 복사하기 위한 단계 예시) EBS 볼륨
-
- EBS 볼륨의 스냅샷을 찍는다.
-
- 스냅샷 자체도 동일한 KMS키로 암호화 됨
-
- 다른 KMS 키를 사용해서 그 스냅샷을 다시 암호화
- 다시 암호화 하는건 AWS가 해준다.
-
- 동일한 KMS 키가 두 리전에 있을 수 없음
- KMS 키 정책
- KMS 키에 대한 액세스를 관리하기 위한 정책
- 기본 정책
- 특정한 커스텀 KMS 키 정책을 제공하지 않을 때 생성 됨
- 기본값은 계정에 있는 모든 사람이 키에 액세스에 가능하다.
- 커스텀 KMS 키 정책
- 사용자와 역할을 정의해서 키를 누가 관리하는지 정의 할 수 있음
- 교차 계정 액세스를 할려는 경우 유용함
- 다른 계정이 우리의 KMS 키를 사용하도록 승인이 가능하기 때문
KMS - Mutil-Region Keys
- KMS에는 다중 리전 키를 둘 수 있음
- 선택 된 한 리전에 기본키를 갖고
- 다른 리전에 복제를 하는 방식임
- 키 ID가 완전히 똑같음
- 한 리전에서 암호화하고 다른 리전에서 복호화가 가능
- 다중 리전키의 핵심
- 한 리전에서 암호화
- 다른 리전에서 복호화
- 다음 리전으로 복제, 교차 리전 API시 데이터를 재 암호화 하지 않아도 됨
- 전역(글로벌)로 사용 할 수 없음
- 키본 키의 복제본이 있는 것임
- 다중 리전 키 사용은 권장하지 않음
- 사용 사례
- 전역 클라이언트 측 암호화가 있는데
- 한 리전에서 암호화 하고
- 다른 리전에서 복호화 한다.
- DyanmoDB Global
- Aurora Global
- 왜 클라이언트 측 암호화하는지?
- 중요한 건 전체 테이블만 암호화 하는게 아니라는 것
- 저장 데이터 암호화 이므로 테이블의 속성을 암호화해서
- 특정 클라이언트만 사용 할 수 있게 된다.
- 전역 테이블 덕분에 데이터뿐만 아니라 암호화 키도 함께 복제가 가능
- 데이터베이스에 액세스 할 수 있는 DB 관리자가
- 암호화된 열에 액세스 할 때 KMS 키 액세스 권한이 없으면
- 데이터를 읽을 수 없다.
S3 암호화된 복제
- 한 버킷에서 다른 버킷으로 S3 복제를 활성화 하면
- 암호화 되지 않은 객체와 SSE-S3로 암호화된 객체가 기본으로 복제 된다.
- 고객 제공 키인 SSE-C로 암호화한 객체도 복제가 가능
- SSE-KMS로 암호화된 객체도 있음
- 기본적으로 복제 안됨, 옵션 활성화를 해야함
- 어떤 KMS 키로 어떤 객체를 암호화 할 지 지정 필요
-
- KMS 키 정책을 대상 키에 적용
-
- S3 복제 서비스를 허용하는 IAM 역할 생성 필요
-
- 소스 버킷의 데이터를 먼저 복호화 하고
-
- 대상 KMS키로 대상 버킷을 다시 암호화 한다.
암호화된 AMI 공유 프로세스
- AMI를 다른 계정과 공유하는 과정에 관함
- AMI가 KMS 키로 암호화가 되어있고
- AMI는 소스 계정에 있고 KMS 키로 암호화 된 것
- 어떻게 A계정의 AMI를 B계정의 EC2 인스턴스로 시작을 하는가?
-
- 시작 권한으로 AMI 속성 수정
- B계정에서 AMI를 시작하도록 허용
-
- B계정에서 사용하게 KMS 키 공유 필요
- 일반적으로 키 정책으로 실행됨
-
- B계정에서 KMS키와 AMI를 모두 사용하는 권한이나 역할을 가진 사용자 생성
-
- B계정에서 EC2 인스턴스 시작
-
SSM 매개변수 저장소 개요
- 구성 및 암호를 위한 보안 스토리지
- 구성을 암호화 할지 선택 할 수 있다.
- KMS 서비스를 이용해 암호를 만들 수 있다.
- 서버 리스 (확장성, 내구성)이 있음
- SDK 사용에도 좋다.
- 매개변수 업데이트 할 시 구성과 암호의 버전 추적 가능
- IAM을 통해 보안 제공
- EventBridge로 알람 받기 가능
- CloudFormation과 통합 가능
- 계층 구조로 매개변수를 저장 할 수 있음
- 예시)
- my-app
- dev
- prod
- 사용시) my-app/dev/db-password
- my-app
- 예시)
- 고급 매개변수
- TTL
- 만료 기한을 추가 가능
- 업데이트나 삭제하도록 강제한다.
- 한번에 여러 정책을 할당할 수도 있음
- TTL
AWS Secrets Manager - 개요
- 암호를 저장하는 최신 서비스
- SSM과 다른 서비스 임
- X일마다 강제로 암호를 교체하는 기능이 있음
- 교체할 암호를 강제 생성 및 자동화 가능
- Lambda 함수를 정의해서 새 암호를 만들 수 있다.
- Amazon RDS MySQL PostgreSQL Aurora 등 통합이 가능
- 데이터베이스에 접근하기 위한 사용자 이름과 비밀번호 저장, 교체가 가능하다.
- 암호는 KMS 서비스를 통해 암호화 됨
- 다중 리전 암호
- 복수 AWS 리전에 암호를 복제 할 수 있음
- 기본 암호와 동기화된 읽기 전용 복제본을 유지 하는 것
- 기본키가 있는 리전에 문제가 생기면 다른 리전의 암호 복제본을 독립 실행형 암호로 승격이 가능
AWS Certificate Manager (ACM)
- TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포하게 해주는 서비스
- 예시
-
- ALB과 ACM을 통합
-
- ALB에서 직접 TLS 인증서를 프로비저닝, 유지관리
-
- 사용자가 HTTPS 프로토콜로 액세스 가능
-
- ACM은 퍼블릭, 프라이빗 TLS 인증서 모두 지원
- 인증서를 자동으로 갱신하는 기능도 있음
- 여러 AWS 서비스와 통합 되어 있음
- ELB
- ALB
- NLB
- CloudFront
- API Gateway
- ACM을 사용할 수 없는 곳이 하나 있는데 EC2 인스턴스임
- 퍼블릭 인증서일 때 추출이 안됨
- ACM을 통해 EC2 인스턴스 퍼블릭 인증서 생성 할 수 없다는 것
- Route 53
- ACM에서 CNAME을 주면은 레코드 생성해서 도메인 소유권 증명을 하면 ACM에서 인증서를 발행해준다.
- 퍼블릭 인증서는 어떻게 가져오나요?
-
- ACM 외부에서 생성된 인증서 (자동갱신 불가능)
-
- ACM에서 생성
-
- 인증서가 어떻게 만료되는지 아나요?
- EventBridge에 만료 45일 전부터 이벤트를 전송함
- AWS Config을 사용하면
- 관리형 규칙을 사용해서 ACM 서비스 검사
- 규칙에 위배된 인증서가 있을 때 EventBridge로 전송
웹 애플리케이션 방화벽
- 계층7(어플리케이션) 에서 일어나는 일반적인 웹 취약점 공격을 보호
- 계층7은 HTTP
- 계층4는 TCP/UDP 프로토콜
- ALB, API Gateway, CloudFront에서 사용이 가능
- 웹 액세스 제어 목록(ACL)과 규칙
- SQL 주입, XSS 등 일반적인 공격 차단도 가능
- IP세트 정의 가능
- 헤더와 본문 필터링 가능
- 용량에 제약 걸기 가능
- 지역 일치 조건
- 속도 기반 규칙으로 디도스 공격 방지
- 리전에만 적용됨, CloudFront는 글로벌로 정의
- 규칙 그룹
- 여러 웹 ACL에 추가 할 수 있는 재사용 가능한 규칙 모음
- 예시)
- 애플리케이션에 고정 IP를 사용하며, 로드밸런서와 WAF 사용 시
- WAF는 NLB(네트워크 로드 밸런서)지원을 안한다.
- WAF는 7계층(HTTP)만 되기때문
- NLB는 4계층(TCP/UDP)임
-
- 애플리케이션 로드 밸런서 고정 IP 할당
- AWS Global Accelerator로 고정 IP 할당 받음
-
- ALB에서 WAF 활성화
실드 - DDoS 보호
- 디도스 공격으로 스스로를 보호하기 위한 서비스
- 스탠다드 서비스
- AWS 고객에에게 무료로 활성화
- SYN/UDP Floods, 반사 공격
- L3/L4 공격으로 보호 해줌
- 어드밴스드 서비스
- 조직당 월 3,000달러 지불 필요
- 더욱 정교한 디도스 공격을 막아준다.
- EC2, CloudFront, Global Accelerator, Route 53 보호
- 디도스 대응 팀이 항시 대기 중
- 자동으로 WAF 규칙을 생성, 평가 배포하여 L7 공격 완화 해줌
Firewall Manager
- AWS 조직(Organizations)에 있는 모든 계정의 방화벽 규칙을 관리하는 서비스
- 여러 계정의 규칙을 동시에 관리 할 수 있음
- 보안 규칙의 집합인 보안 정책
- ALB, API Gateway, CloudFront 등에 적용되는 WAF 규칙
- ALB , CLB, NLB, Elastic IP, CloudFront를 위한 AWS Shield 규칙 등이 포함
- 모든 방화벽을 한 곳에서 관리할 수 있다.
- 정책은 리전 수준에서 생성
- 조직에 등록된 모든 계정에 적용 됨
- 예시)
- 새 ALB(애플리케이션 로드 밸런서)를 생성하면 자동으로 같은 규칙을 적용 해줌
- WAF, Firewall Manager, Shield 차이점
- WAF
- 리소스별 보호를 구성하는데 적절
- Firewal Manager
- 여러 계정에서 WAF를 사용 할 때 WAF 구성을 가속하고 새 리소스 보호 자동화때 적절
- 모든 계정에 Shield 어드밴스드 배포에 도움 줌
- Shield
- 디도스를 받을 때 적절
- WAF 규칙 자동 생성 할 수 있음
- WAF
Amazon GuardDuty
- 지능형 위협 탐지를 이용해서 AWS 계정 보호
- CloudTrail, Event Logs 같은 입력 데이터를 확인해서 비정상적인 API 호출, 무단 배포를 검색하는 것
- EventBridge 규칙으로 자동으로 알림 받기 가능
- 암호화폐 공격을 방어하기 아주 좋은 도구
Amazon Inspector
- 몇 군데 자동화된 보안 평가를 실행하는 서비스
- 취약점을 분석을 하는 것
- 예시)
- Lambda 소프트웨어 취약점 분석
- 컨테이너 이미지 ECR로 푸시되면 취약점 분석
- EC2 보안 평가
- 필요한 인프라만 지속적으로 스캔
Amazon Macie
- 데이터 보안 및 데이터 프라이버시 서비스, 머신러닝과 패턴 매칭으로 민감한 데이터를 발견하고 보호 한다.
- S3에 주민등록번호 있으면 Macie로 분석하고 Event Bridge로 결과를 알려주는것
'스터디 > AWS SAA' 카테고리의 다른 글
| 섹션 27: 네트워킹 - VPC (하) (0) | 2024.01.27 |
|---|---|
| 섹션 27: 네트워킹 - VPC (상) (0) | 2024.01.20 |
| 섹션 25: Identity and Access Management (IAM) - 고급 (0) | 2024.01.17 |
| 섹션 24: AWS 모니터링 및 감사: CloudWatch, CloudTrail 및 Config (0) | 2024.01.17 |
| 섹션 23: 머신 러닝 (0) | 2024.01.15 |
