Encryption
Encryption in flight - 전송중 암호화 (SSL)
- 데이터는 전송되기 전에 암호화되고 서버가 데이터를 받으면 복호화합니다.
- 클라이언트와 서버만이 암호화와 복호화를 하는 방법을 알고 있습니다.
- SSL 인증서가 암호화를 해줍니다.
- 기본적으로 이것을 활성화하면
'중간자'
공격으로부터 보호됩니다.
서버 측 저장 데이터 암호화
- 데이터가 서버에 수신된 후 암호화하는 겁니다.
- 데이터는 클라이언트로 다시 전송되기 전에 복호화됩니다.
- 데이터 키라고 불리는 키 덕분에 데이터는 암호화된 형태로 저장됩니다.
- 암호 키와 해독 키는 주로 KMS (Key Management Service) 같은 곳에 따로 관리됩니다.
클라이언트 측 저장 데이터 암호화
- 클라이언트 측 암호화에서 데이터는 클라이언트가 암호화합니다.
- 여기서 클라이언트는 우리고 서버는 그 데이터를 절대 복호화할 수 없고 데이터를 받는 클라이언트에 의해 복호화됩니다.
- 서버는 최선의 방법으로도 데이터를 복호화할 수 없어야 합니다.
봉투 암호화
를 활용할 수 있습니다.
AWS KMS (Key Management Service)
AWS KMS
- 보통 AWS 서비스에서 암호화라고 하면
KMS
일 가능성이 높습니다.
KMS
키를 사용하여 데이터에 액세스할 수 있는 사람과 대상을 쉽게 제어할 수 있습니다.
- AWS가 모든 암호화 키를 관리해준다는 점에서 좋습니다.
- KMS는 권한 부여를 위해 IAM과 완전히 통합됩니다.
- 거의 모든 서비스와 통합되어 있습니다.
- Amazon EBS
- Amazon S3
- Amazon Redshift
- Amazon RDS
- Amazon SSM
- ETC...
- CLI / SDK 사용 가능합니다.
Customer Master Key (CMK) 종류
- 대칭 키
- AES-256비트 유형의 암호화 키
- KMS의 첫 제품이었습니다.
- 단일 암호화 키로 데이터를 암호화하고 복호화 합니다.
- KMS와 통합된 많은 서비스가 실제로 이 대칭 고객 마스터 키로 씁니다.
- 봉투 암호화에도 대칭 고객 마스터 키가 필요합니다.
- KMS로 대칭 키를 생성하면 암호화되지 않은 키에 절대 액세스할 수 없습니다.
- KMS API를 사용해야 해당 키를 쓸 수 있으며 절대 이 키를 볼 수 없습니다.
- 비대칭 키
- RSA 및 ECC 키 쌍에 속합니다.
- 두 개의 키가 있는데 :
- 암호화를 위한
공개 키
- 복호화를 위한
개인 키
- 서명/검증 작업이라는 KMS의 새로운 사용 사례도 있습니다.
- 공개 키는 공개되어 있으므로 다운로드할 수 있습니다.
- 개인 키는 액세스할 수 없습니다.
- KMS API를 호출할 수 없는 사용자가 AWS 외부에서 암호화를 할 수 있게 하는 겁니다.
대칭 키
- 대칭 키에서는
키
와 정책
을 완전히 관리
할 수 있습니다.
CloudTrail 통합
으로 키 사용을 감사할 수 있으므로 누가 언제 키를 사용하는지 확인할 수 있습니다.
고객 마스터 키 : 세 종류 :
AWS 관리형 서비스 기본 고객 마스터 키
사용자가 KMS에서 생성한 키 / 자체 키를 가져오는 경우
- KMS의 경우 KMS에 수행된 각 API 호출에 대해 호출 10,000건당 약 3센트가 과금됩니다.
AWS KMS 101
데이터베이스 비밀번호
외부 서비스에 대한 자격 증명
SSL 인증서의 개인 키
또는 암호화해야 하는 모든 것
등 민감한 정보를 공유해야 할 때 사용합니다.
- KMS의 진정한 가치는 데이터를 암호화하거나 복호화하는 키를 볼 수 없기 때문에
전체 보안이 AWS에 속하게 된다는 것입니다.
- KMS는 추가 보안을 위해 이러한 키를 교체할 수 있습니다.
암호화의 기본적인 개념
은 데이터베이스 비밀번호 등의 비밀을 절대로 평문으로
, 특히 코드에 절대 저장하지 않는다는 것
입니다.
- 대신 이러한 비밀을 암호화해야 하기 때문에 암호화한 다음 코드나 환경 변수에 저장할 수 있는데 이 경우 암호화 되어있기 때문에 문제가 없습니다.
- KMS에는 제한이 있는데 호출당 최대 4KB의 데이터만 암호화할 수 있습니다.
- 더 많은 데이터를 암호화하려면
봉투 암호화
라는 것을 써야 합니다.
- 누군가에게 KMS에 대한 액세스 권한을 부여하려면
- 키 정책에서 사용자가 키에 액세스할 수 있도록 합니다.
- IAM 정책에서 API 호출을 허용해야 합니다.
- KMS 키가 특정 리전에 바인딩된다는 점입니다.
KMS Key Policies
- S3 버킷 정책과 비슷하지만 키 정책 없이는 액세스를 제어할 수 없습니다.
기본 KMS 키 정책
- 매우 허용적입니다.
- 특정 KMS 키 정책을 제공하지 않으면 기본값으로 생성됩니다.
- 루트 사용자에게 액세스 권한을 부여합니다.
- 즉, 전체 AWS 계정이 IAM 정책을 사용할 수 있는 경우에만 이 KMS 키를 쓸 수 있는 권한이 있습니다.
- 올바른 IAM 정책을 생성하여 사용자에 연결하기만 하면 됩니다.
사용자 지정 KMS 키 정책
- 이 특정
KMS 키에 액세스할 수 있는
사용자와 역할을 구체적으로 정의합니다.
키를 관리할 수 있는 사람
을 정의합니다.
- KMS 키에 대한
교차 계정 액세스
를 수행할 때 매우 유용합니다.
교차 계정 복사
- 스냅샷을 생성하면 자체 CMK로 암호화합니다.
- 키 정책을 연결합니다.
- 해당 키에 대한 교차 계정 액세스를 승인합니다.
- 대상 계정이 KMS 키를 읽을 수 있도록 허용합니다.
- 대상 계정에서 암호화된 스냅샷을 공유하고 스냅샷의 복사본을 만들 수 있게 합니다.
KMS Automatic Key Rotation
자동 키 순환
은 고객 관리 CMK에 대해 활성화할 수 있습니다.
- 자동 키 순환을 활성화하면
매년 한 번씩 일어납니다.
- 과거 데이터를 복호화할 수 있도록 하기 위해
이전 키도 유효한 상태로 유지됩니다.
- 새로운 키는 동일한 CMK ID를 가지게 됩니다.
- 백업 키, 즉, 키의 백업 자료만 바뀌는 것입니다.
KMS Manual Key Rotation
- 매 90일 또는 180일마다 키를 순환시킬 수 있습니다.
- 수동으로 생성했기 때문에 새로운 키는 다른 CMK ID를 가지게 됩니다.
- 물론 과거 데이터를 복호화하기 위해 이전 키도 유효한 상태로 보관됩니다.
- 그렇게 하지 않으면 모든 과거 데이터에 접근할 수 없게 될 겁니다.
- 데이터를 암호화 및 복호화할 때
별칭
을 사용하는 것이 더 좋습니다.
- 애플리케이션에 대해 키가 변경된 것을 숨길 수 있기 때문입니다.
KMS Alias Updating
- 애플리케이션에 대해 변경을 숨기기 위해 별칭을 사용합니다.
- 애플리케이션이 API 관점에서 키 별칭 MyAppKey와 상호작용 합니다.
SSM Parameter Store
- 구성과 암호를 AWS에 안전하게 저장하기 위한 것입니다.
- SSM 파라미터 스토어 내부에서 직접 암호를 KMS로 암호화하여 저장하도록 선택할 수 있습니다.
- 서버리스 서비스입니다.
- 확장 가능하며 오래 갑니다.
- SDK 사용법도 매우 쉽습니다.
- 구성과 암호의 버전 관리도 할 수 있습니다.
- 구성 관리를 위한 모든 보안은 경로 및 IAM 정책을 사용하여 이루어집니다.
- CloudWatch 이벤트를 통해 알림을 받을 수도 있습니다.
- CloudFormation과 통합하여 매개변수를 다듬을 수 있습니다.
- 매우 완전한 서비스입니다.
SSM Parameter Store Hierarchy (계층구조)
Standard and advanced parameter tiers
Parameters Policies (for advanced parameters)
- TTL 즉, Time to Live 등을 매개변수에 배정할 수 있도록 함으로써 만료일을 효과적으로 생성합니다.
- 매개변수 내에서 비밀번호 등 민감한 데이터를 업데이트하거나 삭제하도록 강제하는 것입니다.
- 한 번에 여러 개의 정책을 배정할 수도 있습니다.
AWS Secrets Manager
- 새로 출시된 서비스
- 이 서비스의 유일한 목적은
암호의 저장
입니다.
- Secrets Manager와 파라미터 스토어의 차이는
- Secrets Manager가 더 암호에 집중되어 있고 며칠에 한 번씩 강제로 암호를 순환시킬 수 있다는 점입니다.
- 순환되는 암호 생성을 자동화하는 능력도 있습니다.
- 데이터베이스와 Secrets Manager 간의 암호를 동기화
- KMS를 사용해 암호화할 수 있습니다.
CloudHSM
KMS
를 통해 AWS는 암호화 소프트웨어를 관리하고 사용자가 암호화 키를 제어할 수 있습니다.
CloudHSM
은 AWS가 일부 암호화 하드웨어를 프로비저닝하게하는 장치입니다.
- 하드웨어 보안 모듈입니다.
- AWS가 아닌 사용자가 암호화 키를 완전히 관리합니다.
- AWS의 클라우드 내에 설치됩니다.
- FIPS 104-2 레벨 3 규정을 준수해 변형 억제됩니다.
- 누군가 HSM 장치에 수동으로 액세스하려고 하면 중지 및 차단됩니다.
- 대칭 및 비대칭 암호화 키를 지원하는데
SSL
과 TLS
키를 가질 수 있습니다.
프리 티어
는 없습니다.
- 꽤 복잡하고 범위에서도 벗어난 클라이언트 소프트웨어가 필요합니다.
- CloudHSM으로 데이터베이스를 암호화하고 키 관리를 하려는 경우,
Redshift
와 CloudHSM
를 통합합니다.
- S3에 SSE-C 유형의 암호화를 구현하려는 경우에 적합합니다.
- 스스로 자체 암호화 키를 관리하고 CloudHSM에 저장하기 때문입니다.
CloudHSM – 고가용성
- CloudHSM 클러스터는 고가용성을 가지고 분산된 다중 AZ에 있습니다.
- 가용성과 내구성이 뛰어납니다.
CloudHSM vs KMS
AWS Shield
- AWS Shield Standard
- 모든 AWS 고객에 적용되는 무료 서비스
- 모든 AWS 고객을 DDoS 공격에서 보호합니다.
- 사용자를 보호 :
- SYN/UDP Flood
- 반사 공격
- 3계층/4계층 공격
- AWS Shield Advanced
- DDoS 공격에 대한 완화 서비스를 제공합니다.
- 비용은 조직당 매달 3,000달러입니다.
- 그 대상은
Amazon EC2
와 ELB
그리고 CloudFront
, Global Accelerator
및 Route 53 서비스
입니다.
- DDoS 대응 팀인
DRP
에 항시 액세스 가능합니다.
- DDoS 공격 때문에 로드 밸런서 등의 그룹이 크게 확장됨에 따라 더 많은 비용이 발생할 경우에 더 많이 나온 비용을 면제받을 수 있습니다.
AWS WAF – Web Application Firewall (방화벽)
- 일반적인 웹 취약점 공격으로부터 애플리케이션을 보호하는 방화벽입니다.
- L7(7계층)에 위치합니다.
- L7에는 HTTP가 있고 L4(4계층)는 강의에서 언급했겠지만 TCP를 위한 계층입니다.
- 요청이 구조화되는 방법에 관한 정보를 더 많이 가지고 있습니다.
- WAF는 세 군데에 배포될 수 있습니다. :
애플리케이션 로드 밸런서
API Gateway
CloudFront
- WAF를 사용하려면 웹 ACL을 정의해야 하는데 바로
웹 액세스 제어 목록
입니다.
- 규칙 :
- IP 주소
- HTTP 헤더
- HTTP 본문
- URL 문자열
- HTTP 수준의 일반 공격에서 보호받을 수 있게 됩니다.
- SQL 주입 및 크로스 사이트 스크립팅인 XSS 등이 있습니다.
- 쿼리 크기에 대한 제약을 둘 수도 있습니다.
- 지리적 일치를 통해 특정 국가 API Gateway 등의 액세스를 막을 수 있습니다.
- DDoS로부터 보호해 주는 DDos 방어 기능을 제공합니다.
- 속도 기반 규칙을 사용하는데 각 요청을 개별이 아닌 벌크로 인식하는 겁니다.
AWS Firewall Manager
- AWS Organization 내 모든 WAF 규칙을 관리합니다.
- 공통된 보안 규칙 세트를 정의합니다.
- WAF 규칙도 똑같이 적용되는데
ALB
, API Gateway
그리고 CloudFront
입니다.
AWS Shield Advanced
(ALB
, CLB
, Elastic IP
, CloudFront
)
- VPC의 EC2 및 ENI 리소스를 위한 보안 그룹
- 모든 것들을 조직 내부에서 중앙 집중식으로 관리할 수 있습니다.
DoS 보호 및 웹 취약점 보호
Amazon GuardDuty
- AWS 계정을 보호하는 지능형 위협 탐지 서비스입니다.
- 백엔드에서 머신 러닝 알고리즘을 사용하여 이상 탐지를 수행합니다.
- 타사 데이터를 이용하여 계정에 대한 공격을 탐지합니다.
- 클릭 한 번으로 30일 평가판을 활성화해줍니다.
- 소프트웨어를 설치할 필요 없이 백엔드에서 작동됩니다.
- 입력 데이터 :
- CloudTrail 이벤트 로그 - 비정상적 API 호출과 무단 배포 등을 탐지
- CloudTrail Management Events - VPC 서브셋 생성, trail 생성
* CloudTrail S3 Data Events - get object, list objects delete object
- VPC Flow Logs
- 비정상적인 인터넷 트래픽과 IP 주소를 찾습니다.
- DNS Logs
- DNS 쿼리에서 인코딩된 데이터를 전송할 EC2 인스턴스가 손상되었는지 확인할 수 있습니다.
- Kubernetes Audit Logs
- 의심스러운 활동 및 잠재적인 EKS 클러스터 손상을 감지합니다.
- CloudWatch 이벤트 규칙을 설정하여 탐색 결과가 나타나면 알림을 받을 수 있습니다.
- 작업을 수행할 Lambda 함수를 대상으로 하는 규칙을 설정하거나 이메일을 보낼 SNS 주제로 규칙을 설정하지요.
- GuardDuty로 암호화폐 공격을 보호할 수 있다는 점입니다.
Amazon Inspector
- AWS 인프라의 자동 보안 평가
EC2 인스턴스
- 백엔드에서
AWS System Manager(SSM) 에이전트
를 실행하고 의도하지 않은 네트워크 접근성을 분석합니다.
- 실행 중인 운영 체제를 분석하여 알려진 취약성을 확인합니다.
- EC2 인스턴스에 문제가 있는지 자동으로 감지합니다.
Amazon ECR로 푸시 되는 컨테이너를 분석
- 컨테이너가 Amazon ECR로 푸시 될 때 컨테이너 평가를 얻습니다.
- 모든 리포트는
AWS Security Hub
로 전달됩니다.
- 그 결과는 Amazon의 EventBridge에도 전송됩니다.
AWS Inspector 평가
- 이 평가는 EC2 인스턴스와 컨테이너 인프라에만 해당하며 필요한 경우에만 지속적으로 인프라를 스캔하게 됩니다.
- 패키지 취약성을 확인합니다.
- EC2 인스턴스의 패키지와 ECR 컨테이너를 알려진 데이터베이스 취약성인 CVE 데이터베이스와 비교합니다.
- EC2에서 네트워크 접근성을 평가합니다.
- 우리는 모든 취약성과 관련한 위험도(Risk Score)를 얻게 되고 점수를 기반으로 우선순위를 정합니다.
Amazon Macie
- 완전 관리형의 데이터 보안 및 데이터 프라이버시 서비스
- 머신 러닝과 패턴 일치를 사용합니다.
- AWS의 민감한 정보를 검색하고 보호합니다.
- 민감한 데이터를 경고합니다.
- 예를 들면, 개인 식별 정보 즉, PII 같은 정보입니다.
예를 들면, 개인 식별 정보 즉, PII 같은 정보입니다.
간단히 보면 PII 데이터가 S3 버킷에 있습니다
Macie가 이것을 분석한 후
PII로 분류되는 데이터를 검색하여
CloudWatch 이벤트나 EventBridge로
검색 결과를 알려줄 것입니다
그러면 CloudWatch 이벤트와 통합해서
SNS 주제나 람다 함수에 통합할 수 있습니다.
공동 책임 모델
AWS 책임
이란 클라우드의 보안을 뜻합니다.
- 인프라를 보호해야합니다.
- (하드웨어, 소프트웨어와 시설 그리고 네트워킹)
- S3, DynamoDB, RDS는
AWS의 책임
입니다.
사용자의 책임
WS에서 서비스를 제공한 후에는 서비스를 어떻게 사용하는지에 대한 것
- 사용자는 고객으로서 클라우드 보안에 책임이 있습니다.
- EC2 인스턴스의 경우 고객인 사용자가 운영체제 패치와 업데이트를 포함한 운영체제 관리에 책임을 지는 겁니다.
- 방화벽을 구성해야 하므로 네트워크 ACL과 보안 그룹을 구성합니다.
- IAM 인스턴스 역할을 통해 EC2 인스턴스가 올바른 IAM 정보를 가지게 해야 합니다.
- 규정 준수 요구 사항에 따라서 애플리케이션 데이터를 암호화해야 합니다.
- 공유된 제어 항목
Example, RDS
AWS 책임
- 기본 EC2 인스턴스를 관리합니다.
- SSH 액세스를 비활성화합니다.
- 데이터베이스 패치를 자동화합니다.
- 운영체제 패치를 자동화합니다.
- 기본 인스턴스와 디스크를 감사합니다.
사용자의 책임
- 포트와 IP, 그리고 데이터베이스 보안 그룹의 보안 그룹 인바운드 규칙을 올바르게 설정합니다.
- 인-데이터베이스 사용자 생성과 그 사용자 권한이 제대로 실행되는지 확인합니다.
- 데이터베이스를 생성할 때 공용 액세스 유무를 확인해야 합니다.
- 데이터베이스를 구성하려면 파라미터 그룹 등을 사용해서 암호화된 연결만 강제하도록 합니다.
- 데이터베이스 내의 데이터를 암호화할 때에도 그 활성화는 사용자의 책임입니다.
공유 책임 모델 다이어그램
From
AWS Certified Solutions Architect Associate 시험합격!