AWS SAA 준비 - (3) 안전한 아키텍처

AWS에서 제공하는 SAA 준비 교육 영상 컨텐츠를 글로 적었습니다.

https://explore.skillbuilder.aws/learn/course/6452

1. 안전한 아키텍처

안전한 아키텍처 및 애플리케이션 설계의 몇 가지 모범 사례가 나와 있다.

영역 3: 안전한 애플리케이션 및 아키텍처 지정

• 1.1 애플리케이션 티어를 보호하는 방법 결정
• 1.2 데이터 보호 방법 결정
• 1.3 단일 VPC 애플리케이션을 위한 네트워킹 인프라 정의

애플리케이션 티어 보호 방법을 결정하고 데이터 보호 방법을 결정하고 단일 VPC 애플리케이션의 네트워킹 인프라를 정의하고 네트워크 보호 방법을 이해해야 한다.

인프라

• 인프라
  • 공동 책임 모델
• AWS 리소스 보호
  • 최소 권한의 원칙 적용
  • 자격 증명

AWS에서의 보안을 이해하기 위한 핵심은 공동 책임 모델, 최소 권한의 원칙, AWS의 자격 증명 개념이다.

스택 사이에 선을 그었을 때 공동 책임 모델 측면에서 선 아래는 AWS의 책임이고 선 위는 고객의 책임이다.
예를 들어 AWS 인프라의 물리적 보안은 AWS의 책임이다. EC2 인스턴스에서 내가 실행하는 애플리케이션 코드는 내 책임이다.
관리형 서비스를 사용하면 공동 책임의 선이 더 위로 이동한다.

최소 권한의 원칙

• 사용자(또는 프로세스)는 꼭 필요한 활동만 수행할 수 있다.

최소 권한의 원칙이란 필요한 작업을 수행할 수 있는 최소한의 권한만을 사용자와 서버에 부여하는 것을 말한다.

AWS IAM

• AWS에서 사용자와 사용자 권한을 중앙에서 관리한다.
• AWS IAM을 사용하면 다음을 수행할 수 있다.
  • 사용자, 그룹, 역할, 정책을 생성
  • 권한을 정의하여 사용자가 엑세스할 수 있는 AWS 리소스 제어.
• IAM은 SAML 자격 증명 연동을 통해 Microsoft Active Directory 및 AWS Directory Service와 통합된다.

AWS에서는 IAM을 통해 리소스를 보호한다.

IAM을 통해 사용자, 그룹, 역할을 만들 수 있다. 역할을 사무실 방문 허가증과 비슷한 임시 자격 증명으로 생각하면 된다.

이러한 자격 증명에 권한을 연결한다. 권한은 정책 형식으로 되어 있다.

정책은 리소스와 해당 리소스에서 수행할 수 있는 작업을 지정한다.
이러한 정책을 사용자 그룹 또는 역할에 연결해야 리소스에서 작업을 수행할 수 있다.

연동을 사용하여 IAM을 Active Directory 또는 기타 자격 증명 공급자와 통합할 수도 있다.

자격 증명

• IAM 사용자: 계정 내에서 생성된 사용자이다.
• 역할: EC2 인스턴스, Lambda 및 외부 사용자가 사용하는 임시 자격증명이다.
• 연동: Active Directory 자격 증명 또는 기타 기업 자격 증명이 있는 사용자에게는 IAM에서 역할이 할당된다.
• 웹 자격 증명 연동: Amazon.com 또는 기타 오픈 ID 제공자의 웹 자격 증명이 있는 사용자에게는 STS(Security Token Service)를 사용하여 역할이 할당된다.

AWS의 자격 증명은 이런 형식으로 존재한다. 계정 안에서 만들 수 있는 IAM 사용자가 있고 역할은 EC2 인스턴스, Lambda, 외부 사용자가 사용하는 임시 자격 증명이다.
연동을 통해 Active Directory 자격 증명 또는 기타 회사 자격 증명이 있는 사용자에게 역할을 할당할 수 있다.
그런 다음 웹 자격 증명 연동을 통해 amazon.com 또는 기타 ID 공급자에서 인증된 사용자에게 역할을 할당할 수 있다. 이때 STS, 즉 보안 토큰 서비스를 사용한다.

출처: https://explore.skillbuilder.aws/learn/course/120/play/3802

학습을 위한 자료 및 위치

• 보안 프로세스의 개요 백서
  • 공동 보안 책임 모델
  • Amazon 계정 보안 기능
• AWS 보안 모범 사례 백서
• IAM 모범 사례
• AWS STS를 사용해야 하는 경우

예시문항 1

AWS 계정 관리자가 오늘 퇴사를 한다고 합니다. 관리자는 루트 사용자와 개인 IAM 관리자 계정에 엑세스할 권한이 있었고, 이들 계정을 가지고 다른 IAM 사용자와 키를 생성했습니다.
AWS 인프라를 보호하기 위해 지금 당장 해야 할 일은 무엇입니까? (3개 선택)

A. 암호를 변경하고 루트 사용자에 MFA를 추가합니다.
B. 루트 사용자 로그인 시 IP에 제한을 둡니다.
C. 키를 교체하고 IAM 사용자의 암호를 변경합니다.
D. 모든 IAM 사용자를 삭제합니다.
E. 관리자의 IAM 사용자를 삭제합니다.
F. 새 역할로 모든 EC2 인스턴스를 다시 시작합니다.

해설

B는 불가능하기 때문에 제거할 수 있다.
D는 불필요하고 지나친 대응이기 때문에 제거할 수 있다.
F도 제거할 수 있다. 역할은 임시 자격 증명이지 사용자가 아니므로 아무런 효과가 없다.

그러면 필요한 3개의 답이 남는다.
A. 암호를 변경하고 루트 사용자에 MFA를 추가합니다.
C. 키를 교체하고 IAM 사용자의 암호를 변경합니다.
E. 관리자의 IAM 사용자를 삭제합니다.

2. Amazon VPC

클라우드에서 네트워킹 인프라를 어떻게 보호할 수 있을까?
그 열쇠는 Virutal Private Cloud(VPC) 이다.

컴퓨팅/네트워크 아키텍처

• Virtual Private Cloud(VPC)
• 클라우드에서 네트워크 아키텍처 설계
  • 보안
  • 라우팅
  • 네트워크 격리
  • 관리
  • 배스천 호스트

VPC를 사용하면 인스턴스의 프라이빗 IP 주소 기반을 만들 수 있다.
VPC에 대해 알아보자.

Virtual Private Cloud

• 조직: 서브넷
• 보안: 보안 그룹 / 엑세스 제어 목록
• 네트워크 격리: 인터넷 게이트웨이 / VPC / NAT 게이트웨이
• 트래픽 방향: 라우팅

VPC는 프라이빗 IP 주소의 하위 네트워크인 서브넷으로 구성된다.
VPC 내에서 보안 그룹과 엑세스 제어 목록을 사용하여 누가 누구와 통신할 수 있는지 결정한다.
인터넷 게이트웨이, 가상 프라이빗 게이트웨이, NAT 게이트웨이를 만들어 데이터가 VPC를 드나들도록 허용한다.
경로를 사용하여 서브넷 간의 연결을 결정한다.

서브넷 사용 방법

다음은 서브넷에 대한 몇 가지 권장 사항이다.

• 권장 사항: 서브넷을 사용하여 인터넷 접근성을 정의하십시오.
• 퍼블릿 서브넷
  • 퍼블릭 인터넷에 대한 인바운드 / 아웃바운드 엑세스를 지원하려면 인터넷 게이트웨이에 라우팅 테이블 항목을 포함시켜야 한다.
• 프라이빗 서브넷
  • 인터넷 게이트웨이에 대한 라우팅 테이블 항목이 없다.
  • 퍼블릭 인터넷에서 직접 엑세스가 불가하다.
  • 제한된 범위의 아웃바운드 전용 퍼블릭 인터넷 엑세스를 지원하려면 보통 ‘점프 박스’(NAT/프록시/배스천호스트)를 사용한다.

퍼블릭 서브넷을 통해 퍼블릿 인터넷에 대한 인바운드 엑세스와 아웃바운드 엑세스가 가능하다.
라우팅 테이블에는 인터넷 게이트웨이의 진입점이 포함되어야 한다.

프라이빗 서브넷에는 인터넷 게이트웨이 항목이 없다.
프라이빗 서브넷은 퍼블릭 인터넷에서 직접 엑세스할 수 없다.
아웃바운드 엑세스의 경우 NAT 인스턴스 또는 NAT 게이트웨이를 사용한다.
인바운드 엑세스의 경우 점프 박스 또는 배스천 호스트를 사용한다.

보안 그룹과 네트워크 ACL 비교

VPC에서 엑세스를 제한하고 허용하는 두 가지 주요 메커니즘이 있다.

보안 그룹은 인스턴스 수준 또는 네트워크 인터페이스 수준에서 작동한다.
네트워크 ACL은 서브넷 수준에서 작동한다.

보안 그룹과 네트워크 ACL의 주요 차이점은 보안 그룹은 트래픽 허용만 가능하다는 점이다.
즉, 특정 위치에서 명시적으로 트래픽을 거부할 수 없지만 네트워크 ACL은 트래픽 허용과 거부가 모두 가능하다.

보안 그룹은 상태 저장이다. 요청이 들어오면 요청의 응답이 나갈 수 있다.
반면 네트워크 ACl은 상태 비저장이다.

보안 그룹은 네트워크 인터페이스에 적용되지만 네트워크 ACL은 서브넷에 적용된다.

애플리케이션의 다양한 티어 또는 구성 요소를 어떻게 구분해야 할까?

보안 그룹을 사용하여 구분할 수 있다.
예를 들어 애플리케이션 서버를 포함하는 애플리케이션 티어와 데이터베이스를 포함하는 데이터베이스 티어가 있을 수 있다.

보안 그룹의 좋은 점은 다른 보안 그룹에서 인스턴스나 네트워크 인터페이스에 엑세스하는 것을 허용하도록 보안 그룹을 구성할 수 있다는 것이다.
IP 주소를 추적할 필요가 없다.
보안 그룹 맴버십이 있으면 다른 티어에 대한 엑세스 권한을 인스턴스에 부여하기에 충분하다.

위 그림에서 보안 그룹은 앱이 데이터베이스 티어에 엑세스하도록 허용할 수 있다.
그러면 새 앱 서버가 앱 티어 보안 그룹에 조인할 때 자동으로 데이터베이스에 엑세스할 수 있다.

위 그림을 보고 보안 그룹이 여러 가용 영역에 걸칠 수 있는지 알 수 있을까?

Yes, 보다시피 가능하다. 물론 VPC도 가능하다.
그러나 둘 중 어느 것도 여러 리전에 걸칠 수는 없다.

VPC 연결

• VPC 안팎으로 트래픽을 가져오거나 내보내는 서비스를 파악
  • 인터넷 게이트웨이: 인터넷에 연결
  • 가상 프라이빗 게이트웨이: VPN에 연결
  • AWS Direct Connect: 전용 파이프
  • VPC 피어링: 다른 VPC에 연결
  • NAT 게이트웨이: 프라이빗 서브넷에서 인터넷 트래픽 허용

이 서비스들은 데이터가 VPC를 드나들 수 있게 하는 서비스이다.

인터넷 게이트웨이를 통해 인터넷에 연결할 수 있다.
가상 프라이빗 게이트웨이를 사용하면 VPN 또는 Direct Connect를 통해 고객 데이터 센터에 연결할 수 있다.
Direct Connect는 코로케이션 시설을 사용하여 AWS와 고객 데이터 센터 간의 전용 파이프를 설정한다.
VPC 페어링을 통해 VPC를 서로 연결할 수 있다.
NAT 게이트웨이는 프라이빗 서브넷에서 나가는 인터넷 트래픽을 허용한다.

이 모든 것이 조합된 예가 나와 있다.
이 내용들은 복습과 같다.
이 개념 중 하나라도 생소하다면 시험 전에 복습하자.

2개의 VPC가 있다.
첫 번째 VPC에는 프라이빗 서브넷 밖으로 트래픽을 라우팅할 NAT 인스턴스가 있다.
두 번째 VPC에는 NAT 게이트웨이가 있다.
NAT 게이트웨이는 확장성이 더 뛰어나고 관리형 서비스이다.
NAT 인스턴스는 단일 EC2 인스턴스이므로 보다 저렴하다.

또한 2개의 VPC에 프라이빗 IP 주소가 할당되어 서브넷이 이 IP 주소의 하위 집합을 만든다는 점에도 유의하자.
라우팅 테이블은 서브넷에 연결된다.
서브넷은 연결을 정의한다.

VPC 좋은 자료 :

VPC 관련 좋은 설명 제공

학습을 위한 자료 및 위치

• VPC의 기본 사항에 대한 동영상
• 배스천 호스트
• VPC 사용 설명서

예시문항 2

VPC의 서브넷에서 웹 서버를 실행 중인 인스턴스를 배포했다고 합시다. 인터넷에서 HTTP를 사용하여 브라우저를 통해 연결을 시도하면 연결 시간이 초과됩니다.
다음 중 이 문제를 해결할 수 있는 방법은 무엇입니까? (3개 선택)

A. VPC에 인터넷 게이트웨이가 포함되어 있고, 서브넷의 라우팅 테이블이 0.0.0.0/0을 인터넷 게이트웨이로 라우팅하고 있는지 확인합니다.
B. VPC에 가상 프라이빗 게이트웨이가 포함되어 있고, 서브넷의 라우팅 테이블이 0.0.0.0/0을 가상 프라이빗 게이트웨이로 라우팅하고 있는지 확인합니다.
C. 보안 그룹이 포트 80에서 인바운드 액세스를 허용하는지 확인합니다.
D. 보안 그룹이 포트 80에서 아웃바운드 액세스를 허용하는지 확인합니다.
E. 네트워크 ACL이 포트 80에서 인바운드 액세스를 허용하는지 확인합니다.

해설

가상 프라이빗 게이트웨이는 퍼블릭 인터넷에 대한 엑세스와는 관련이 없으므로 B를 제거할 수 있다.
가상 프라이빗 게이트웨이는 VPC를 고객 데이터 센터에 연결하는 데 사용된다.
D도 제거할 수 있다. 보안 그룹은 상태 저장이므로 아웃바운드 액세스는 필요 없다.
그럼 답 3개가 남는다.

정답은 A, C, E 이다.

3. 데이터 티어 보안

보안의 다른 측면은 보안이 데이터 티어에 적용되는 방식이다.
데이터 보안 문제는 두 가지 범주로 나눌 수 있다.

데이터 티어

• 전송 데이터
  • AWS 안과 밖
  • AWS 내
• 저장 데이터
  • Amazon S3
  • Amazon EBS

하나는 전송 데이터 보안으로서 데이터가 AWS 내에서 이동하거나 AWS를 드나드는 경우이다.
두 번째는 저장 시 데이터 보안으로서 데이터가 S3나 EBS 또는 AWS 내부의 다른 시스템에 저장된 경우이다.

전송 데이터

• AWS 인프라 안팎으로 데이터 전송
  • 웹을 통한 SSL
  • IPsec용 VPN
  • AWS Direct Connect를 통한 IPsec
  • Import/Export/Snowball
• AWS API에 전송된 데이터
  • AWS API 호출은 기본적으로 HTTPS/SSL 사용

전송 데이터의 경우 다음 중 하나를 사용한다.
회사 데이터 센터와 AWS 간에 이동하는 데이터의 경우 웹을 통한 SSL이나 IPsec을 사용한 VPN, 또는 VPN을 통한 IPsec 또는 Snowball이나 Snowmobile을 사용한 AWS Import/Export 서비스를 사용한다.
이러한 디바이스는 변조 방지 기능이 있고 데이터를 암호화된 상태로 유지한다.

AWS API에 전송되는 데이터는 기본적으로 SSL을 사용한다.

저장 데이터

Amazon S3에 저장된 데이터는 기본적으로 프라이빗하고 액세스하려면 AWS 자격 증명 필요

• HTTP 또는 HTTPS를 통한 엑세스
• 모든 객체에 대한 액세스 감사
• ACL 및 정책 지원
  • 버킷
  • 접두사(디렉터리/폴더)
  • 객체

S3에 저장된 데이터는 기본적으로 프라이빗이며 액세스하려면 AWS 자격 증명이 필요하고 HTTP 또는 HTTPS를 통해 액세스할 수 있다.
모든 객체에 대한 액세스 감사 로그가 있다.
버킷 수준 이하에서 ACL 및 정책에 대한 액세스를 잠글 수 있다.

• 서버 측 암호화 옵션
  • Amazon S3 관리형 키(SSE-S3)
  • KMS 관리형 키(SSE_KMS)
  • 고객 제공 키(SSE-C)
• 클라이언트 측 암호화 옵션
  • KMS이 관리하는 마스터 암호화 키(CSE-KMS)
  • 고객이 관리하는 마스터 암호화 키(CSE-C)

AWS에서 저장 데이터를 암호화하는 경우 몇 가지 암호화 옵션 중에서 선택할 수 있다.
크게 보면 서버 측 암호화가 있다.
이 암호화는 코드에 대해 투명하며 구성하기가 더 쉽다.
데이터는 AWS 서버의 디스크에 도달하기 전에 암호화된다.

그리고 클라이언트 측 암호화가 있다.
이를 위해서는 데이터를 AWS 서비스로 전송하기 전에 암호화해야 한다.

서버 측 암호화에는 세 가지 옵션이 있다.
다음 약어는 중요하며 시험에도 유용하다.

SSE-S3는 S3가 암호화 키를 관리하는 서버 측 암호화이다.
SSE-KMS는 KMS에서 암호화 키가 관리되는 서버 측 암호화이다.
SSE-C는 고객이 암호화 키를 관리하는 서버 측 암호화이다.
CSE-KMS는 KMS가 암호화 키를 관리하는 클라이언트 측 암호화이다.
CSE-C는 고객이 암호화 키를 관리하는 클라이언트 측 암호화이다.

규정 준수를 위해 클라이언트 측 암호화가 필요한 경우가 있는데 이 경우 클라이언트 암호화를 수행해야 한다.
일반적으로 서버 측 암호화가 더 쉽고 성능이 더 뛰어나다.

키 관리

• Key Management Service
  • 고객 소프트웨어 기반 키 관리
  • 여러 AWS 서비스와 통합
  • 애플리케이션에서 직접 사용
• AWS CloudHSM
  • 하드웨어 기반 키 관리
  • 애플리케이션에서 직접 사용
  • FIPS 140-2 규정 준수

키는 어디에 저장될까?
KMS를 사용하여 키를 관리할 수 있다.
또 다른 옵션은 AWS CloudHSM을 사용하는 것이다.
그러면 FIPS 140-2 규정을 준수할 수 있다.
이것은 키를 관리하는 전용 어플라이언스이다.

AWS KMS 통합

• AWS KMS에 통합된 서비스
  • Amazon EBS
  • Amazon S3
  • Amazon RDS
  • Amazon Redshift
  • Amazon Elastic Transcoder
  • Amazon WorkMail
  • Amazon EMR

KMS는 이러한 서비스 및 AWS의 기타 데이터 관련 서비스와 통합된다.
암호화는 요청 시 수행된다.

학습을 위한 자료 및 위치

• Protecting Your Data in AWS(동영상)
• 저장 데이터 암호화(백서)
• Amazon S3에서 암호화
• 보안 개요(백서)
• IAM Policies and Bucket Policies and ACLs!

예시문항 3

다음 중 IAM 정책으로 제어가 가능한 작업은 무엇입니까? (3개 선택)

A. MySQL RDS 데이터베이스에서 테이블 생성
B. VPC 보안 그룹 구성
C. .NET 애플리케이션에 로그인
D. Oracle RDS 데이터베이스 생성
E. Amazon S3 버킷 생성

해설

A는 DB 관리 작업이므로 제거할 수 있다.
C도 제거할 수 있다. IAM은 애플리케이션 수준 계정을 제어하지 않는다.

정답은 B, D, E이다.

예시문항 4

웹 티어의 인스턴스에서 오는 HTTP 트래픽만 수락하는 애플리케이션 티어 서브넷에서 Amazon EC2 인스턴스 그룹(웹 티어 보안 그룹을 공유하는 다른 서브넷의 인스턴스 그룹)을 생성하려 합니다.
다음 중 어떤 방법을 사용하면 가능합니까?

A. 웹 티어 인스턴스 앞에 로드 밸런서를 추가합니다.
B. 애플리케이션 티어의 각 인스턴스를 웹 티어 보안 그룹에서 오는 인바운드 HTTP 트래픽을 허용하는 보안 그룹에 연결합니다.
C. 웹 티어 서브넷의 IP 범위에서 오는 인바운드 HTTP 트래픽을 허용하는 애플리케이션 티어 서브넷에 ACL을 추가합니다.
D. 웹 티어 서브넷이 IP 주소를 기준으로 애플리케이션 티어 인스턴스에 트래픽을 전달할 수 있도록 라우팅 테이블을 변경합니다.

해설

A를 제거할 수 있다. 로드 밸런서는 트래픽을 차단하지 않는다.
D도 제거할 수 있다. 라우팅 테이블도 트래픽을 차단할 수 없다.
네트워크 ACL을 사용하면 문제가 해결될 수 있지만 복잡한 해결책이 될 것이다. ACL은 상태 저장이 아니다. ACL을 계속 작동하려면 많은 구성 및 유지 보수가 필요하다.

그러면 정답인 B가 남는다.
보안 그룹을 사용하는 것이 좋다.

4. 시험에 대한 조언

• 루트 사용자는 사용 금지
• 보안 그룹은 허용만 가능하다. 네트워크 ACL은 명시적 거부가 가능하다.
• 액세스 키보다 IAM 역할을 선호하라.