Amazon VPC 네트워킹 원리와 보안

차정도 지음

에이콘출판 2022년 01월 26일 출간 종이책 : 2022년 01월 28일 출간

작품소개

책소개

2022년 세종도서 학술부문 선정도서

기업 클라우드 보안 정책을 수립하고 적합성 평가를 직접 수행하며 겪은 저자의 노하우가 담긴 VPC 네트워킹 책이다. VPC 공간과 컴퓨팅, 네트워킹 연결 서비스의 구조와 원리를 AWS 토폴로지로 친절히 설명해 초보자도 쉽게 이해할 수 있다. AWS 클라우드 서비스 설계부터 구축, 운영, 보안까지 실무 활용 중심으로 상세하게 구성했다.

◈ 이 책에서 다루는 내용 ◈

◆ VPC 네트워킹 서비스 구조를 AWS 토폴로지와 그림으로 쉽게 설명
◆ 챕터별 단계적인 서비스 생성 실습 예제
◆ 온프레미스와 클라우드 환경 비교 설명
◆ AWS 서비스의 네트워킹 콘셉트와 VPC 네트워킹의 요건
◆ AWS 계정 생성과 보안 가이드
◆ VPC 네트워크와 서비스의 CIDR 전략
◆ VPC 주 보호 대상인 네트워크 인터페이스 유형별 특징
◆ 인스턴스에 연결된 네트워크 인터페이스의 변화 패턴
◆ 보안 그룹, 네트워크 ACL, 라우팅 테이블의 보안 최적 운영 방법
◆ 게이트웨이 유형별 특징과 활용 방법
◆ 로드밸런서 유형(ALB, NLB, CLB, GWLB)별 특징
◆ 피어링, VPN, Direct Connect, Transit Gateway 연결 서비스의 세부 형태
◆ 하이브리드 네트워킹 아키텍처
◆ AWS PrivateLink 기술, VPC 엔드포인트 액세스 유형과 서비스 보호

목차

1부. AWS 네트워킹 개요
1장 AWS 네트워킹 콘셉트
1.1. VPC 개념을 도입하다
1.2. VPC 네트워킹의 개념
1.2.1 네트워킹 서비스의 분류
1.2.2. 네트워크 인터페이스? 그럼 VPC!

2장. VPC 네트워킹 구성 요소의 역할 분류
2.1. 우리 동네와 닮은 VPC
2.2. VPC 네트워킹의 3요소 : 공간, 연결, 컴퓨팅

3장. VPC 네트워킹 구성 요소의 포함 관계
3.1. 수학의 집합
3.2. 공간의 포함 관계
3.2.1. 계정과 리전의 관계
3.2.2. 리전과 VPC의 관계
3.2.3. 리전과 가용 영역의 관계
3.2.4. VPC와 가용 영역의 관계
3.2.5. 서브넷과 VPC, 서브넷과 가용 영역의 관계
3.2.6. 공간의 포함 관계 정리
3.3. 공간과 다른 요소(연결, 컴퓨팅) 간 포함 관계
3.3.1. 패런트와 연결(Attach or Associate)
3.3.2. VPC 포함 관계의 이해 : 패런트와 연결 예제

2부. 네트워크 공간과 그 경계

4장. 나의 AWS 전용 공간 : 계정
4.1. [실습] AWS 계정 생성하기
4.2. AWS 계정의 이해와 올바른 사용법
4.2.1. AWS 계정 ≒ 루트 사용자
4.2.2. [실습] 루트 사용자 MFA 적용하기
4.3. IAM
4.3.1. IAM 작동 방식의 이해
4.3.2. 루트의 권한 대행 : IAM 사용자
4.3.3. IAM 보안 관리 방안

5장. AWS가 만들어 놓은 네트워크 공간
5.1. 클라우드의 이점
5.1.1. 데이터센터는 오늘도 전쟁 중
5.2. 글로벌 영역
5.3. 리전과 가용 영역
5.3.1. 리전
5.3.2. 가용 영역

6장. 우리가 만들어 나갈 네트워크 공간
6.1. VPC
6.1.1. VPC와 VPC 네트워킹
6.1.2. VPC와 온프레미스의 비교
6.1.3. CIDR 블록
6.1.4. 퍼블릭 CIDR 전략
6.1.5. VPC 네트워킹 리소스 할당량 조정
6.1.6. 기본 VPC란?
6.1.7. 기본(Default)의 위험성
6.1.8. [실습] VPC 생성 예제
6.2. 서브넷
6.2.1. 서브넷 = 가용 영역 ∩ VPC
6.2.2. 서브넷의 역할
6.2.3. 서브넷 우회 경로의 근원
6.2.4. [실습] 서브넷 생성 예제

3부. 컴퓨팅 서비스

7장. 컴퓨팅 서비스의 네트워킹 요건
7.1. 트래픽의 시작 : IP 주소
7.1.1. IP 유형 = [정적/동적] + [퍼블릭/프라이빗]
7.1.2. 퍼블릭 IP와 인터넷 라우팅
7.1.3. 프라이빗 IP와 VPC CIDR 선정
7.1.4. AWS의 IP 분류
7.1.5. [실습] 탄력적 IP 할당 예제
7.2. 트래픽 전달의 주체 : 탄력적 네트워크 인터페이스(ENI)
7.2.1. VPC 서비스의 전용 배송원 : ENI
7.2.2. ENI의 2가지 유형
7.2.3. ENI 유형 비교(1) : 소스/대상 확인
7.2.4. 요청자 관리형 ENI
7.2.5. ENI 유형 비교(2) : 보안 그룹(SG) 강제 적용
7.2.6. SG와 서브넷에 의존하는 ENI
7.2.7. ENI 보호 = VPC 보호
7.2.8. [실습] ENI 생성 예제
7.3. 트래픽 생성의 주체 : EC2 인스턴스
7.3.1. 트래픽 공장의 대표 이사 : 인스턴스
7.3.2. 인스턴스로 위장한 AWS 서비스들
7.3.3. 인스턴스의 위상
7.3.4. 인스턴스는 바람둥이? 2개 서브넷에 양다리 걸치기
7.3.5. [실습] 인스턴스 생성 예제

8장. 컴퓨팅 서비스 활용
8.1. 인스턴스의 네트워킹 패턴
8.1.1. 인스턴스 기본 통신 요건
8.1.2. 컴퓨팅 기본 3요소의 독립 형태
8.1.3. 인스턴스 유형별 ENI와 프라이빗 IP 최대 개수
8.1.4. 퍼블릭 IP 자동 할당
8.1.5. ENI 연결과 탄력적 IP 할당
8.1.6. 결코 뗄 수 없는 꼬리표 : 동적 퍼블릭 IP
8.1.7. 보조 프라이빗 IP에 탄력적 IP 할당
8.1.8. [실습] 인스턴스에 ENI 연결/분리, 신규 퍼블릭 IP 확인
8.2. 컴퓨팅 서비스 응용 : RDS
8.2.1. VPC를 사용하는 데이터베이스의 종류
8.2.2. RDS 서브넷 그룹의 특징
8.2.3. RDS 서브넷 그룹의 역할
8.2.4. VPC 경계를 넘나드는 RDS : 서브넷 그룹 변경
8.2.5. 다중 AZ 배포
8.2.6. Aurora RDS의 다중 AZ
8.2.7. Aurora 이외 RDS의 다중 AZ

4부. 연결 193

9장. 연결 제어 I : VPC 통제 3요소
9.1. 접근 제어 : 보안 그룹과 네트워크 ACL
9.1.1. 접근 제어 방식 비교(1) : Whitelist vs. Blacklist
9.1.2. [SG] 표면적 특징과 다중 연결성(1:N, N:1)
9.1.3. [SG] 규칙의 형태
9.1.4. [SG] 소스/대상에 SG 허용
9.1.5. [NACL] 표면적 특징과 다중 연결성(1:N)
9.1.6. [NACL] 규칙의 형태
9.1.7. 접근 제어 방식 비교(2) : Stateful vs. Stateless
9.1.8. SG vs. NACL 비교
9.1.9. SG와 NACL 바르게 사용하기
9.1.10. [실습] SG 생성 예제
9.1.11. [실습] NACL 생성 예제
9.2. 경로 제어 : 라우팅 테이블
9.2.1. 라우팅이란?
9.2.2. 반환 트래픽의 라우팅
9.2.3. 서비스의 아지트 : On-link(로컬) 라우팅
9.2.4. VPC의 라우팅
9.2.5. 새로운 세상을 여는 문 : 게이트웨이(GW)
9.2.6. 인터넷 게이트웨이(IGW)와 NAT 테이블
9.2.7. 퍼블릭과 프라이빗 서브넷의 경계 : IGW
9.2.8. NAT 게이트웨이
9.2.9. 라우팅의 솔로몬 : Longest Prefix Match
9.2.10. VPC 라우팅 구체화 : East-West 트래픽 검사
9.2.11. 엣지 연결과 Ingress Routing : North-South 트래픽 검사
9.2.12. 기본 게이트웨이와 그 위험성
9.2.13. 라우팅 테이블의 표면적 특징과 다중 연결성(1:N)
9.2.14. [실습 1] 라우팅 테이블 생성 및 서브넷 연결
9.2.15. [실습 2] 라우팅 추가 및 Blackhole 상태 확인
9.2.16. [실습 3] 엣지 연결
9.2.17. Destination : 라우팅 전파 → Target : 11장

10장. 연결 제어 II : 분산 제어
10.1. 서버 로드밸런싱(SLB) 개요
10.1.1. 온프레미스의 SLB 제어 : L4 스위치
10.1.2. L4 스위치의 특징
10.1.3. L4 스위치 Config 예시 : Alteon
10.2. AWS의 SLB 제어 : 로드밸런서(ELB)
10.2.1. L4 스위치 vs. 로드밸런서(ELB)
10.2.2. ELB 학습 순서
10.2.3. ELB 유형 비교 : ALB, NLB, CLB, GWLB
10.3. 로드밸런싱 처리부
10.3.1. ELB 가용 영역과 노드
10.3.2. ELB 중복 구현 : 교차 영역 로드밸런싱
10.3.3. 대상 그룹과 대상
10.3.4. 가변 노드를 장착한 ELB : ALB, CLB
10.3.5. NLB 대상 그룹에 ALB 연결하기
10.4. 요청 수신부
10.4.1. ELB 체계와 DNS 이름
10.4.2. 리스너
10.5. 요청 수신부터 로드밸런싱 처리까지
10.5.1. 리스너와 대상 그룹
10.5.2. 상태 검사 결과가 ELB에 미치는 영향
10.5.3. 컴퓨팅 노드와 라우팅 노드 비교 : ALB vs. NLB
10.6. 게이트웨이 로드밸런서(GWLB)
10.7. [실습] ALB 생성 과제

11장. 연결 서비스 I : 공간과 공간 연결(양방향)
11.1. 연결 서비스 개요
11.1.1. 기본(Implicit) 연결 서비스 : 로컬 라우팅, IGW
11.1.2. 명시적(Explicit) 연결 서비스 : PCX, VPN, DX, TGW
11.2. VPC와 VPC의 연결 : PCX
11.2.1. [실습] PCX 생성 예제
11.2.2. CIDR이 겹치는 VPC 간 피어링 - 불가
11.2.3. 전이적 VPC 피어링 - 불가
11.2.4. Full-mesh 피어링
11.2.5. PCX 특징 정리
11.3. VPC와 온프레미스의 연결(하이브리드 네트워킹) : VPN, DX
11.3.1. VPN 연결 개요
11.3.2. [실습] Site-to-Site(사이트 간) VPN 연결 생성 과제
11.3.3. Direct Connect(DX) 연결 개요
11.3.4. 가상 인터페이스(VIF)의 특징과 유형
11.3.5. 글로벌 DX 게이트웨이(DXGW)
11.3.6. 다른 계정에게 VIF 만들어 주기
11.3.7. DXGW에 다른 계정의 게이트웨이(VGW/TGW) 연결하기
11.3.8. 퍼블릭 VIF를 활용한 VPN Over DX
11.3.9. DX 리소스 할당량
11.4. VPC와 온프레미스의 중앙 라우터 : TGW
11.4.1. 전송 게이트웨이(TGW) 개요
11.4.2. 연결(Attachment)과 연결(Association)
11.4.3. TGW 라우팅 테이블 작동 원리
11.4.4. TGW 공유
11.4.5. [실습] TGW 생성 과제
11.4.6. TGW와 통합된 하이브리드 네트워킹

12장. 연결 서비스 II : 공간과 서비스 연결(단방향)
12.1. VPC 네트워킹의 꽃, VPC 엔드포인트
12.1.1. VPC 엔드포인트 개요 : 트래픽 순간이동
12.1.2. AWS PrivateLink 기술과 엔드포인트 유형 분류
12.1.3. 서비스 범주별 엔드포인트 유형 매칭
12.1.4. 기본 DNS 이름과 프라이빗 DNS 이름
12.2. 게이트웨이 엔드포인트 : 퍼블릭 액세스
12.2.1. 엔드포인트 라우팅 = 접두사 목록 + 엔드포인트(GW)
12.2.2. 접두사 목록 접근 제어
12.2.3. 인터넷 vs. 엔드포인트 접속 비교 : 비용과 보안 측면
12.2.4. [실습] 게이트웨이 엔드포인트 생성 예제
12.3. AWS PrivateLink 엔드포인트 : 프라이빗 액세스
12.3.1. AWS PrivateLink 엔드포인트의 4가지 유형
12.3.2. [실습 1] 엔드포인트 서비스 생성 예제
12.3.3. [실습 2] 엔드포인트 생성 예제
12.3.4. 엔드포인트 ENI와 NLB 노드의 관계(feat. 교차 영역 로드밸런싱)
12.3.5. 리전 DNS 이름과 가용 영역 DNS 이름
12.3.6. 공급자 서비스 접근 제어
12.3.7. 엔드포인트 ENI 접근 제어 : 아웃바운드 프리패스
12.3.8. 엔드포인트 - 엔드포인트 서비스 - NLB의 관계
12.3.9. [실습 3] 타계정 엔드포인트 허용
12.3.10. 공급자와 소비자의 CIDR 일치
12.3.11. 엔드포인트 서비스 보호
12.3.12. 리전 외부 공간에서 엔드포인트 액세스

출판사 서평

◈ 이 책의 대상 독자 ◈
◆ VPC 네트워크 구조와 동작 원리를 이해하고 싶은 독자
◆ AWS 클라우드 입문자
◆ AWS 네트워크 관리자와 보안 관리자
◆ VPC 라우팅 이해가 필요한 독자
◆ AWS 아키텍처 디자이너
◆ AWS 서비스 운영자
◆ 클라우드 보안 정책 수립 담당자
◆ 클라우드 인프라 보안성 평가 담당자
◆ AWS SDK를 활용한 자동화 솔루션 개발자

작가정보

저자(글) 차정도

경북대학교에서 컴퓨터공학, 전자전기공학을 복수전공하고 삼성네트웍스에 입사했다. 2012년 삼성물산 8세컨즈 공식몰 인프라 구축을 리딩했다. 현재 삼성SDS에서 인프라 보안 기준을 수립하고 보안 수준 평가와 클라우드 아키텍처 보안성 검토를 맡고 있다. 정보 유출과 악성코드 감염 피해 예방을 위한 방화벽 정책 분석 시스템, 클라우드 보안 취약점 분석 시스템 개발을 이끌고 관련 특허를 다수 출원했다. 번역서로는 『컴퓨터 포렌식 수사 기법』(에이콘, 2016)이 있다.

작가의 말

신입사원 입문 교육이 끝나갈 무렵, 각자의 꿈과 10년 후의 모습을 그려보는 시간이 있었다. 나눠준 종이에 “보안 전문가가 되고 싶습니다”라고 적었다. 보안 전문가라면 진단 대상 시스템과 그 주변 환경을 포괄적으로 이해하고 취약점과 해결책을 제시하는 실력을 갖춰야 한다고 생각했기 때문이다. 이 점이 참 매력적이었고 멋져 보였다. 그러고는 IDC 인프라 운영 팀에 지원해서 서버, 네트워크, 보안 등 다양한 장비를 경험했다. 데이터 센터는 IT 최전방이자 현장이며, 내 꿈을 실현하기 위한 첫 단추라고 믿었다.
10년도 훌쩍 넘은 지금, 그 당시 기준으로 비춰볼 때 나는 ‘보안 전문가’가 아닌 ‘보안 담당자’로 일하고 있다. 이렇게 많고 다양한 분야가 있을 줄은 몰랐으니 말이다. 비록 전문가는 아니지만, 보안 업무를 하고 있다는 것으로 목표의 반은 이룬 셈이다. 오히려 더욱 연구하고 고민하는 겸손한 자세를 갖게 돼 기쁘다. 언젠가 ‘전문가’가 될 수 있을 것이라는 믿음은 설레게 한다.
‘보안’이 주는 매력은 신입 때와 변함없다. 보안 취약점과 관련한 해결책을 제시하려면 상황에 따라 변하는 시스템의 여러 모습에 정통해야 하는데, 비록 그 과정은 고되지만 다른 분야의 IT 전문가들과 소통하는 기반이 되기 때문이다. 이 과정에서 보다 현실적인 보안 대책을 고민해볼 수도 있다.
서비스 운영자는 시스템 성능과 비즈니스 연속성을 최우선으로 생각한다. 정상으로 작동하는 데 필요한 운영 방법을 잘 알면 된다. 그러나 보안은 좀 다르다. 보안성 평가 대상 서비스의 종류나 비즈니스 모델에 따라 시스템을 이용하는 형태와 패턴이 제각기 다르기 때문이다. ‘무엇 무엇을 하는 방법’에 초점을 둔 것이 운영이라면, 보안은 ‘무엇을 하면 어떤 모습으로 변화하는가?’를 A부터 Z까지 관찰하고 정리해야 한다. 그리고 잘못된(해킹) 방향으로 이끄는 문제점을 찾아 조치해야 한다. 그렇다면 어떤 시스템이든 최초 설계자가 해킹 방어력이 가장 높다고 할 수 있지 않을까? 시스템의 변화 양상을 가장 잘 알고 있을 테니 말이다.
그러한 관점에서 이 책은 VPC 설계자의 기조를 해부하겠다는 마음가짐으로 써내려갔다. VPC 네트워킹 구성 요소를 역할에 따라 3가지(공간, 연결(네트워크), 컴퓨팅 서비스)로 분류하고, 상호 구조와 관계, 각 네트워킹 요소들이 띠는 패턴을 최대한 담으려 노력했다.
클라우드는 쉽고 빠르며 합리적이다. 의사결정을 신속하고 유연하게 한다. 따라서 클라우드 도입과 전환은 기업 비즈니스 성공의 핵심이자 필수가 됐다. 이는 해커의 놀이터가 온프레미스에서 클라우드로 옮겨갔다는 방증이다. 사업 추진력 앞에서 보안은 대개 등한시되며, 확장과 변경이 용이한 클라우드는 해커가 활동하기에 더할 나위 없는 환경이다.
클라우드가 급속도로 발전하고 변화를 거듭하지만 그 기본 바탕은 온프레미스다. VPC는 기업 엔터프라이즈(온프레미스) 환경과 유사한 가상 네트워크 공간이다. 그런 의미에서 VPC로 클라우드를 시작해보는 것도 좋은 방법일 것 같다.
앞으로도 VPC는 서비스 확장과 개선 등 많은 변화를 겪겠지만, Amazon의 최초 VPC 설계 기조까지는 쉽게 바꾸지 못할 것이다. 기회가 된다면 서비스 개선에 발맞춰 책 내용도 조금씩 보완해 나가고 싶다. 이 책이 최적화된 클라우드 서비스 운영에 도움이 되고, 평소 잘 보이지 않던 보안 취약점을 찾아 해결책을 제시하는 계기가 됐으면 좋겠다.