[4] AWS 클라우드 보안

* 목차

[1]. AWS 공동 책임 모델

[2]. AWS Identity and Access Management(IAM)

[3]. 계정 보안

[4]. AWS의 데이터 보안

[5]. 규정 준수 보장 작업

 

[1]. AWS 공동 책임 모델

☑️ AWS 공동 책임 모델

: AWS와 고객이 클라우드 보안과 운영에 대해 각자 책임을 나눠서 맡는 것

- AWS: 클라우드의 보안 책임,  클라우드 자체 보안 책임

  ex) RDS DB 패치, 가상화, 데이터센터 보안

- 고객: 클라우드에서의 보안 책임, 클라우드 안에서 사용하는 모든 것의 보안 책임, 클라우드 안에서 내가 설정한 것 보호, AWS가 제공한 기반 위에 무엇을 어떻게 구성하느냐의 책임

  ex) EC2 OS, EC2 앱, S3 접근 설정

	고객 책임 (클라우드에서의 보안)	AWS 책임 (클라우드의 보안)
🔐 데이터 보안	- 고객 데이터 - 클라이언트 측 데이터 암호화 - 데이터 무결성 인증	- 서버 측 암호화 (파일 시스템 및/또는 데이터) - 스토리지 폐기 및 삭제 시 보안 보장
⚙️ 시스템 구성	- 플랫폼, 애플리케이션 설정 - IAM(자격 증명 및 액세스 관리) - 인스턴스 운영 체제(OS) 설치 및 패치	- 컴퓨팅, 스토리지, 데이터베이스, 네트워킹 리소스 제공 - 호스트 운영 체제 및 가상화 계층 관리
🔧 보안 설정	- 운영 체제 보안 구성 - 방화벽/보안 그룹 구성 - 네트워크 트래픽 보호 (암호화/무결성/자격 증명) - 침입 탐지 및 차단 설정 (EC2 안 IDS/IPS)	- 하드웨어 보안 - 네트워크 인프라 침입 탐지 시스템 운영
📦 관리 범위	- 애플리케이션 계층 보안 설정 - IAM 사용자/역할 관리 - MFA 및 접근 권한 설정 - 로깅/감사 정책 수립	- 물리적 인프라 보호 - 데이터 센터 보안 (출입통제, 모니터링 등) - 리전, 가용 영역, 엣지 로케이션 운영
🛰️ 가상화 및 인프라	- 인스턴스 배포 및 OS 설치 - 애플리케이션 로깅/모니터링 설정	- 인스턴스 격리 - 가상화 플랫폼 보안 - 물리적 서버 및 하드웨어 인프라 유지관리

 

☑️ 서비스 특성 및 보안 책임

구분	설명	고객이 관리하는 서비스 예시	AWS가 관리하는 서비스 예시
IaaS 서비스형 인프라	- 고객이 네트워킹, 스토리지 등을 직접 구성 가능 - 보안의 더 많은 측면을 고객이 직접 관리 - 액세스 제어, 운영체제 관리 등도 고객 책임	- Amazon EC2 - Amazon EBS - Amazon VPC	❌ (IaaS는 고객이 인프라 관리)
PaaS 서비스형 플랫폼	- 고객이 기본 인프라를 관리할 필요 없음 - 운영체제, 데이터베이스 패치, 방화벽 구성, 복구 등은 AWS가 처리 - 고객은 코드/데이터에 집중 가능	(제한적으로 애플리케이션 및 데이터 관리만)	- AWS Lambda - Amazon RDS - AWS Elastic Beanstalk (DB패치, 백업, 방화벽 구성)
SaaS 서비스형 소프트웨어	- 소프트웨어가 중앙에서 호스팅됨 - 고객은 접속해서 사용만 하면됨 - 웹/앱/API를 통해 접속만 하면 됨 - 고객은 인프라 관리 필요 없음 - 주로 구독 기반 라이선스로 제공	❌ (고객은 단순 사용자)	- AWS Trusted Advisor - AWS Shield - Amazon Chime

 

☑️ Q. 다음 배포에서 누구 책임일까?

①	EC2 인스턴스의 운영체제(OS) 업그레이드와 패치	🟣 고객	EC2는 IaaS 서비스니까, OS 설치와 업데이트는 직접
②	데이터센터 물리적 보안	🟠 AWS	건물 출입, 전력, 냉각, 감시 물리적 보안은 AWS 책임
③	가상화 인프라 관리	🟠 AWS	가상 머신(VM)을 운영하는 기반 시스템은 AWS 몫
④	EC2의 보안 그룹 설정	🟣 고객	EC2에 접근할 수 있는 포트/대역폭을 직접 설정
⑤	EC2에서 실행 중인 애플리케이션 설정	🟣 고객	무슨 프로그램 돌릴지는 고객이 설치하고 구성
⑥	Oracle이 Amazon RDS 서비스로 실행될 때 업그레이드/패치	🟠 AWS	RDS는 PaaS 서비스니까 AWS가 Oracle도 알아서 관리
⑦	Oracle이 EC2에 설치돼 있을 때 업그레이드/패치	🟣 고객	EC2에 설치했으면 고객 책임
⑧	S3 버킷의 접근 권한 설정	🟣 고객	S3는 AWS가 제공하지만, 누구에게 공개할지는 고객 설정

①	AWS Management Console 해킹 차단	🟠 AWS	콘솔 로그인 관련된 기본 플랫폼 보안은 AWS가 관리
②	서브넷 구성	🟣 고객	VPC 안에서 어떤 서브넷을 만들지는 고객이 직접 설정
③	VPC 구성	🟣 고객	VPC는 가상의 네트워크니까, 직접 생성/설정
④	AWS 리전의 네트워크 중단에 대한 보호	🟠 AWS	리전 단위의 큰 인프라 운영은 AWS 책임
⑤	SSH 키 보안 관리	🟣 고객	EC2에 접속하는 키는 고객이 직접 생성하고 보관해야 하니까 고객 책임
⑥	고객 데이터 간 네트워크 격리 보장	🟠 AWS	테넌트 간 격리(VPC 분리 등)는 AWS 인프라 레벨에서 보장
⑦	EC2와 S3 간 빠른 네트워크 연결 보장	🟠 AWS	리전 내에서 빠르게 연결되게 해주는 인프라는 AWS 몫
⑧	사용자 로그인에 MFA 적용	🟣 고객	IAM 설정에서 직접 MFA 적용해야 보안이 강화됨

[2]. AWS Identity and Access Management(IAM)

☑️ IAM

: IAM = AWS에서 누가 무엇을 할 수 있는지 정해주는 보안 관리자

- 무료로 제공되는 기능

- IAM을 사용하여 AWS 리소스(EC2, S3)에 대한 액세스 관리 

ex) EC2 인스턴스를 종료할 수 있는 사용자 제어

      IAM 사용자/그룹에게 정책을 연결해서 EC2나 S3같은 자원에 전체 액세스 혹은 읽기 전용 권한을 줄 수 있음

 

☑️ IAM 필수 구성 요소 - IAM 사용자, 그룹, 정책, 역할

1. IAM 사용자

- AWS 계정으로 인증할 수 있는 사람 또는 애플리케이션

2. IAM 그룹

- 동일한 권한 부여를 허락받은 IAM 사용자의 모음

- 동일한 정책을 여러 사용자에게 연결하는 간단한 방법

- 한 사용자가 여러 그룹에 속할 수 있음

- 기본 그룹은 없음

- 그룹을 중첩할 수 없음

3. IAM 정책

- 액세스할 수 있는 리소스와 각 리소스에 대한 액세스 수준을 정의하는 문서

4. IAM 역할

- 특정 권한이 있는 IAM 자격 증명, 특정 권한을 가진 임시 신분증으로 누구든지 그 역할을 빌려서 AWS 작업할 수 있음

- AWS 서비스 요청을 위한 권한 세트를 부여하는 유용한 메커니즘

- 권한 정책이 연결될 수 있으며 사용자 또는 애플리케이션에 임시 액세스 권한을 위임하는 데 사용될 수 있음

	IAM 사용자	IAM 역할
공통점	권한 정책을 IAM 역할에 연결
대상	특정한 사람 1명	사람, 서비스, 다른 계정 누구나
로그인	로그인 계정 있음 (ID, 비번)	로그인 계정 없음
권한 부여 방식	사용자에게 직접 붙임	누가 "수임(assume)" 해서 사용
예시	너의 AWS 계정	EC2, Lambda, 외부 사용자 등이 임시로 사용하는 권한

☑️ 액세스 가능한 IAM 사용자로 인증

- IAM 사용자를 정의할 때 이 사용자가 사용할 수 있는 액세스 유형을 선택

1. 프로그래밍 방식 액세스

   - 액세스 키 ID + 비밀 키

    - 액세스 키 ID, 보안 액세스 키

    - AWS CLI 및 AWS SDK 액세스 제공

2. AWS Management Console 액세스

   - 계정 ID + 사용자 이름 + 비번 (+MFA)

   - 12자리 계정 ID 또는 별칭, IAM 사용자 이름, IAM 암호

   - 활성화하면 MFA에 의해 인증 코드를 입력하라는 메시지가 표시됨

   - 로그인 시, 휴대폰에 뜬 인증번호(6자리 코드) 입력해야 로그인 완료

 

☑️ IAM MFA

- MFA는 보안을 향상시킴

- MFA를 사용하는 경우 사용자 이름과 암호에 추가로 고유한 인증 코드를 제공해야 AWS 서비스에 액세스할 수 있음

- 사용자 이름 및 암호 + MFA 토큰

 

☑️ IAM: 권한부여

: IAM은 "누가 AWS에서 뭘 할 수 있냐?"를 정하는 보안 시스템으로 이걸 정책에 설정함

- Deny는 Allow보다 우선 적용됨

🔒 기본값	아무것도 안 줬을 땐 모두 거절 (암시적 거부)
✅ 허용	정책으로 명시해야 허용됨
❌ 명시적 거부	거부라고 직접 써놓으면 절대 허용 안 됨
📌 모범 사례	필요한 것만 최소한으로 허용
🌍 적용 범위	IAM 설정은 전 세계 모든 AWS 리전에 공통으로 적용

 

☑️ IAM 정책 2가지 - 자격 증명 기반 정책, 리소스 기반 정책

: '이 사람은 어디에 무슨 일을 할 수 있다'는 내용을 담은 규칙 문서

 ex) 사용자 A는 S3에서 파일만 읽을 수 있음

	자격 증명 기반 정책 (누구에게 권한을 줄까)	리소스 기반 정책 (어떤 리소스,자원에 누구를 허용)
정의	- IAM 사용자, 그룹, 역할에 붙이는 정책 - 자격 증명 기반 정책은 사용자, 그룹 또는 역할에 연결됨	- 자원 자체에 붙이는 정책 - 리소스 기반 정책은 일부 AWS 서비스에서만 지원됨 - 리소스 기반 정책은 리소스에 연결됨 (사용자, 그룹 또는 역할에 연결되지 않음)
특징	- 하나의 정책을 여러 사용자(엔터티)에게 - 하나의 사용자(엔터티)에게 여러 정책을	- S3 버킷 정책 - Lambda 함수 정책
예시	- 이 그룹은 RDS 읽기 전용만 가능 - 이 사용자한테 EC2 서버 만들 수 있는 권한	S3 버킷에 "이 사용자한테만 접근 허용"이라고 직접 적음

{
"Version": "2012-10-17",
"Statement":[{
"Effect":"Allow", // 허용 (이 사용자는 작업이 가능함)
"Action":["DynamoDB:*","s3:*"], // DynamoDB와 S3에서 모든 작업
"Resource":[
"arn:aws:dynamodb:region:account-number-without-hyphens:table/table-name",
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"]
},
{
"Effect":"Deny", // 명시적 거부 (우선 적용됨, 절대 작업 못 함)
"Action":["dynamodb:*","s3:*"],
"NotResource":["arn:aws:dynamodb:region:account-number-without-hyphens:table/table-name”,
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"]
}
]
}

[3]. 계정 보안

☑️ AWS Oraganizations

: 여러 AWS 계정을 통합하여 중앙에서 관리

- 일반적으로 계정은 1개, 그 아래에 IAM을 하는게 일반적임

- 하지만 엄청 큰 회사는 ai, 포털 등등 부서들이 많으므로 각각 만들고, 여러개의 계정들을 조직단위로 관리하는 것이 Organizations임

- 계정을 OU(조직 단위)로 그룹화하고 각 OU에 다른 액세스 정책을 연결

- IAM에 대한 통합 지원 가능

- 서비스 제어 정책 사용, 계정마다 액세스하게끔 사용 가능

 

☑️ AWS Key Management Service(AWS KMS) 

- 암호화 키 생성/관리

-  AWS CloudTrail과 통합할 경우 모든 키 사용을 로깅

- FIPS(Federal Information Processing Standards) 140-2에서 검증한 HSM(하드웨어 보안 모듈)을 사용하여 키를 보호

 

☑️ Amazon Cognito 기능

- 웹 및 모바일앱 만들때 사용자 인증

- 수백만 명의 사용자까지 확장

- 소셜 자격 증명 공급자, 엔터프라이즈 자격 증명 공급자를 사용한 로그인 지원

 

☑️ AWS Shield 

- 디도스 공격 방어

- 상시 탐지 및 자동 인라인 완화

- AWS Shield Standard는 추가 비용 없이 활성화됨

- AWS Shield Advanced는 선택형 유료 서비스

- 애플리케이션 다운타임과 지연 시간을 최소화할 수 있음

 

[4]. AWS의 데이터 보안

☑️ 유휴 데이터 암호화

- 유휴 데이터: 디스크에 물리적으로 저장된 데이터

- S3에 업로드한 것 암호화해서 저장되기에 타인이 S3만 별도로 해킹해도 별도로 데이터를 암호화하기에 퍼가기 어려움

- 읽을 수 없는 보안키로 데이터를 인코딩함

- 보안 키가 있는 사용자만 데이터를 디코딩할 수 있음

- 데이터를 암호화해서 저장한다

- AWS KMS가 지원하는 모든 서비스에 저장된 데이터를 암호화함

- Amazon S3, Amazon EBS,  Amazon Elastic File System(Amazon EFS) , Amazon RDS 관리형 데이터베이스

 

☑️ 전송 중 데이터의 암호화

- 네트워크에서 이동하는 데이터의 암호화

- TLS(전송 계층 보안)는 개방형 표준 프로토콜임

- AWS Certificate Manager는 TLS 또는 SSL 인증서를 관리, 배포 및 갱신하는 방법을 제공

- 보안 HTTP(HTTPS)는 보안 터널을 생성, 양방향 데이터 교환에는 TLS, SSL이 사용됨

 

☑️ Amazon S3 버킷 및 객체 보안

- 새로 생성된 S3 버킷과 객체는 기본적으로 비공개이며 보호됨

- Amazon S3의 데이터 객체를 공유해야 하는 사용 사례의 경우

  ㄴ 데이터 액세스를 관리하고 제어하는 것이 필수적

  ㄴ 최소 권한 원칙을 준수하는 권한을 따르고 Amazon S3 암호화 사용을 고려

- S3 데이터 액세스 제어를 위한 도구 및 옵션

  ㄴ Amazon S3 Block Public Access 기능: 사용이 간단

  ㄴ IAM 정책: 사용자가 IAM을 사용하여 인증할 수 있는 경우에 좋은 옵션

  ㄴ 버킷 정책 • ACL(액세스 제어 목록): 레거시 액세스 제어 메커니즘

  ㄴ AWS Trusted Advisor 버킷 권한 확인: 무료로 제공되는 기능

 

[5]. 규정 준수 보장 작업

☑️ AWS 규정 준수 프로그램

: AWS가 설정하고 운영하는 정책, 프로세스 및 제어에 대한 정보를 제공

- 고객에게 적용되는 보안 및 규제 준수와 요건은 매우 다양함

- AWS는 인증 기관 및 독립 감사자와 협력하여 AWS가 설정하고 운영하는 정책, 프로세스 및 제어에 대한 상세한 정보를 제공

- 준수해야되는 가이드가 제공되는데 AWS가 기본적으로 제공해줌

 

☑️ AWS Config

- AWS 리소스의 구성을 측정, 감사 및 평가

- 설정에 맞게 되어있는지 감사해줌

- 구성을 지속적으로 모니터링

- 구성 변경을 검토

 

☑️ AWS Artifact

- 규정 준수 관련 정보를 위한 리소스

- 보안 및 규정 준수 보고서에 액세스하고 온라인 계약을 선택할 수 있음

 

 

 

💡핵심사항

1. AWS 공동 책임 모델: AWS와 고객은 공동으로 보안을 책임

   - AWS는 클라우드의 보안, 고객은 클라우드에서의 보안

2. IaaS(서비스형 인프라)는 고객이 필요한 보안 구성 및 관리 작업을 수행 (OS 업데이트, 보안패치, 방화벽, 보안그룹 구성)

3. IAM 정책은 JSON(JavaScript Object Notation)으로 작성되며 권한을 정의함

4. IAM 필수 구성 요소 - IAM 사용자, 그룹, 정책, 역할

5. AWS Config: AWS 리소스의 구성을 측정, 감사 및 평가하는 데 사용

6. AWS Artifact: 보안 및 규정 준수 보고서에 대한 액세스를 제공

7. AWS 보안 규정 준수 프로그램: AWS가 설정하고 운영하는 정책, 프로세스 및 제어에 대한 정보를 제공