클라우드 보안

열공하는웅2·2025년 11월 18일

클라우드

목록 보기

13/13

1. 클라우드의 등장 배경

● 산업 경계가 사라지는 4차 산업혁명

IT 기술이 기존 산업(의료, 물류, 제조 등)과 결합하면서 산업 간 경계가 약화되고
서비스가 융합되는 형태가 나타남. 이 변화 속에서 클라우드 기술이 핵심 기반으로 자리잡음.

● IT 결합으로 탄생한 새로운 서비스들

기존 산업	새로운 서비스	특징
통신	WeChat	통신사를 대체하는 메신저 기반 전화 서비스
숙박	AirBnB	숙소 없이 제공하는 숙박 플랫폼
운송	Uber	택시 없이 제공하는 이동 서비스
콘텐츠	Netflix	공장 없이 콘텐츠 제공
SNS	Facebook	사용자 기반 SNS 서비스
전자상거래	Alibaba	재고 없는 판매 방식

이처럼 자체 자산 없이 서비스만 제공하는 플랫폼 기업들이 등장하며
클라우드 기술의 필요성이 증가함.

2. 4차 산업혁명 핵심 기술 ICBMA

● ICBMA 구성 요소

IoT
Cloud
BlockChain
Mobile
AI

● 클라우드의 역할

IoT·AI·모바일 서비스가 생성하는 데이터 수집·저장·분석 기반 제공
대규모 데이터를 처리할 컴퓨팅 자원을 저렴하게 제공
4차 산업혁명 기술들을 실현하는 핵심 기반 인프라

3. 클라우드의 기술적 특징

● 가상화 기반

물리적 장비(서버, 네트워크, 스토리지)에서 분리된 가상 자원 생성
사용자가 요청하는 만큼 즉시 확장/축소 가능

● 핵심 장점

확장성(Scalability)
탄력성(Elasticity)
비용 효율성(Pay-as-you-go)
고가용성·유연한 인프라 구성 가능

● 클라우드를 통한 IT 환경 변화

기존에는 기업이 직접 서버를 구매·운영
이제는 “필요한 자원만 빌려 쓰는” 모델로 전환
고객 맞춤형 IT 환경 구현이 용이

4. 주요 클라우드 사업자

● 글로벌 클라우드

Amazon AWS
Microsoft Azure
Google GCP
Alibaba Cloud
Tencent Cloud

● 국내 클라우드

KT ucloud
Naver Naver Cloud
SK CloudZ

5. AWS의 클라우드 시장 개척

● 탄생 배경

2003년 Amazon이 제공한 두 서비스가 클라우드 산업의 시작점

S3 : 확장 가능한 저장소
EC2 : 가상 서버(컴퓨팅 자원)

이후 AWS가 본격적으로 글로벌 클라우드 시장을 선도하며
현재는 수많은 클라우드 기업이 함께 성장 중.

■ 클라우드의 주요 특징

☁ 1. 접속 용이성 (Accessibility)

시간·장소 제약 없이 인터넷만 있으면 접속 가능
표준화된 API 호출을 통해 서비스 기능 활용
클라우드 환경은 언제 어디서나 연결 가능한 Ubiquitous 기술 실현

📌 API란?
외부 프로그램이 서비스 기능을 “원격 호출”하여 사용하게 해주는 인터페이스
→ 클라우드에서 핵심 역할

⚡ 2. 유연성 (Elasticity)

갑작스러운 사용량 증가에도 자동 확장
반대로 사용량이 감소하면 자동 축소
시스템 병목 없이 안정적인 운영 가능

📌 관련 기능 : AutoScaling
사용량 변화에 따라 컴퓨팅 자원을 자동으로 조절하는 기능

🛠 3. 주문형 Self-Service (On-Demand Provisioning)

사용자가 직접 포털(CMP)을 통해
서버 생성 · 삭제 · 설정 변경 등을 즉시 수행 가능
관리자가 없어도 필요한 자원을 스스로 조절하는 환경

📌 관련 개념 : CI/CD

개발 → 통합 → 배포를 자동화하는 클라우드의 핵심 기능
민첩한 서비스 개발 환경 제공

💳 4. 사용량 기반 과금 (Pay-As-You-Go)

사용한 만큼만 비용을 지불하는 과금 구조
초기 장비 구매 비용·유지보수 비용 최소화
스타트업·개발 환경에서 매우 유리

📌 관련 개념 : On-Demand Billing
필요한 순간에만 자원을 사용하고 그에 대한 비용만 지출

✔ 한눈에 보는 요약

특징	의미	관련 기능/개념
접속 용이성	어디서든 API로 접속	API, Ubiquitous
유연성	자원 자동 확장·축소	AutoScaling
주문형 Self-Service	포털에서 자원 직접 생성·삭제	CMP, CI/CD
사용량 기반 과금	사용한 만큼만 지불	On-Demand

■ 클라우드의 장단점

👍 장점

비용 절감
서버 구축·유지에 드는 초기 비용과 운영비를 크게 줄일 수 있음.
완성형 서비스 활용
필요한 기능을 바로 사용 가능해 생산성과 개발 속도 향상.
유연성 확보
사용량 증가/감소에 따라 자원 자동 조절 가능(AutoScaling).
자원 효율성 증가
필요한 만큼만 사용하는 구조(On-Demand).

⚠ 단점

보안 취약성
외부 서비스 사용으로 인한 보안 통제력 약화.
가상화 인프라 취약점
하이퍼바이저·가상 네트워크·스토리지 등 공격 표면 증가.
자원 공유로 인한 리스크
멀티테넌시 환경에서 자원 격리 문제가 발생할 가능성.
BlackBox 문제
AWS 같은 클라우드 서비스 내부 구조나 장애 원인을 직접 확인하기 어려움.
장애 발생 시 의존성 증가
문제 발생 시 해결 속도가 제공 업체에 종속됨.

■ 클라우드의 유형

클라우드는 목적과 배포 방식에 따라 여러 형태로 나뉜다.

🏢 1. 로컬 클라우드(Local / On-Premise / Private Cloud)

기업 자체 데이터센터(서버실)를 직접 구축·운영
서버, 네트워크, 스토리지 등 모든 인프라를 내부에서 관리
보안성·통제력 높음
단, 구축·운영 비용이 크고 확장성이 낮음

☁ 2. 상용 클라우드(Public Cloud / On-Demand)

AWS, Azure, GCP 등이 제공하는 클라우드
서버·저장소·네트워크 등을 보유하지 않고도 바로 사용 가능
초기 비용 없이 필요한 만큼만 사용
글로벌 인프라, 고가용성, 자동 확장 등 장점
단, 보안·통제 측면에서 제한 존재

🔗 3. 하이브리드 클라우드(Hybrid Cloud)

프라이빗(내부) + 퍼블릭 클라우드 결합
핵심 데이터와 민감 정보는 내부(On-Premise)에 두고
나머지 서비스나 확장 자원은 퍼블릭 클라우드 활용
비용 최적화 + 보안 + 확장성을 모두 확보하는 방식

🧩 4. 멀티 클라우드(Multi-Cloud)

여러 개의 클라우드(AWS + Azure + GCP 등)를 동시에 사용하는 환경
각 서비스의 장점을 조합하고 장애 발생 시 리스크 분산 가능
서비스별로 특화 기능 사용 가능
예: 웹 서버는 AWS, DB는 GCP 등으로 분리 구성

✔ 한눈에 정리

유형	특징
On-Premise	기업이 직접 구축/운영, 최고 수준의 통제·보안
Public Cloud	AWS 등 외부 제공자 사용, 비용 효율·유연성 최고
Hybrid	프라이빗 + 퍼블릭 조합, 민감정보는 내부, 나머지는 외부
Multi-Cloud	여러 퍼블릭 클라우드 병행 사용, 장애 대비·기능 조합

■ 클라우드 서비스 모델

1. 🏗 IaaS (Infrastructure as a Service)

■ 개념

인프라만 제공하는 서비스
(서버, 네트워크, 스토리지 등)
사용자가 OS·미들웨어·애플리케이션을 직접 설치하고 구성

■ 특징

가장 기본 계층
확장성 및 제어권이 높음
개발자/엔지니어가 직접 환경을 구성해야 함

■ 예시 서비스

AWS EC2, EBS
Azure VM
GCP Compute Engine
(온프레미스 환경을 외부에서 빌리는 느낌)

2. 🧱 PaaS (Platform as a Service)

■ 개념

개발을 위한 플랫폼까지 제공
(OS + 미들웨어 + DB + 런타임 환경 포함)
사용자는 애플리케이션 개발에만 집중할 수 있음

■ 특징

인프라 관리 필요 없음
배포 자동화, 스케일링, 버전 관리 등 기능 제공
개발 생산성을 높이는 서비스

■ 예시 서비스

AWS RDS (데이터베이스 서비스)
AWS Elastic Beanstalk
Google App Engine
Web/WAS 기반 개발 환경 제공

3. 💻 SaaS (Software as a Service)

■ 개념

완성된 소프트웨어를 그대로 사용하는 형태
설치 없이 웹이나 클라우드 환경에서 즉시 사용

■ 특징

사용자 입장에서 “가장 편한 형태”
업데이트·패치·유지보수 모두 공급자가 처리
비용 절감 효과 크고 접근성이 높음

■ 예시 서비스

MS Office 365
Google Workspace
Dropbox
Slack / Notion 등

■ 세 모델의 차이 한눈에 보기

구분	사용자가 관리하는 범위	제공되는 범위	예시
IaaS	OS, 미들웨어, SW, 데이터	서버·스토리지·네트워크	EC2, EBS
PaaS	애플리케이션, 데이터	OS + 미들웨어 + DB + 런타임	RDS, App Engine
SaaS	사용만 함	모든 SW + 인프라	Office 365, Gmail

■ 클라우드 환경의 핵심 속성 요약

클라우드에서 반드시 이해해야 하는 주요 속성은 다음 세 가지이다.

1. 🧩 멀티테넌시(Multi-Tenancy)

■ 개념

AWS 같은 클라우드 서비스 제공자의 하나의 자원을 여러 사용자가 함께 공유하는 구조
하나의 물리 자원을 여러 “임차인(tenant)”이 사용하는 형태
자원 공유 구조이므로 격리(보안)가 매우 중요함

■ 보안 관점

테넌트 간 데이터 격리 필요
하이퍼바이저, 가상 네트워크 계층에 대한 보안 고려 필수

2. 🌐 접근성(Accessibility)

■ 개념

인터넷만 연결되어 있다면 언제 어디에서나 서비스에 접속 가능
Ubiquitous(유비쿼터스) 환경을 제공하는 것이 핵심

■ 의미

전 세계 어디서든 동일한 환경으로 자원 접근 가능
개인·기업의 민첩한 서비스 운영을 가능하게 함

3. ⚡ 유연성(Elasticity)

■ 개념

사용량 변화에 따라 자원을 빠르게 확장·축소할 수 있는 능력
CI/CD 기반 자동화로 자원 생성·삭제가 신속하게 이루어짐

■ 장점

갑작스러운 트래픽 증가에도 서비스 중단 없이 대응
비용 최적화와 효율적 인프라 운영 가능

🔒 클라우드 속성에 필요한 보안 요소

멀티테넌시 · 접근성 · 유연성이 만족되기 위해서는 다음이 필수:

빠른 자원 변동을 고려한 자동화된 보안 설계
지속적인 모니터링 및 취약점 점검
데이터, 네트워크, 계정에 대한 격리·권한 관리 강화

■ 클라우드와 온프레미스 보안 비교

기업들은 클라우드를 도입해 비용 절감, 민첩성(CI/CD) 향상 등을 기대하지만
기존 온프레미스(자체 구축 환경) 수준의 보안을 그대로 적용할 수 있는지에 대한 고민이 존재한다.
클라우드는 가상화 기술 기반으로 자원을 공유하는 방식이므로 보안 관점에서 온프레미스와 거의 동일한 위협과 취약점을 가진다.

1. 온프레미스 보안 특징

직접 제어 가능
모든 설정을 임의적으로 조작 가능(원하는 대로 구성 가능)
세밀한 설정 가능
네트워크, 스토리지, 방화벽 등 세부 조정 가능
물리적 분리
데이터센터를 직접 소유하거나 특정 구역을 임차해 사용
관리자 보안 영향
관리자 실수·설정 오류 등이 전체 보안에 큰 영향을 미침

2. 클라우드 보안 특징

서비스 제공자의 정책·설정 가이드에 영향을 받음
온프레미스처럼 모든 설정을 마음대로 할 수 없음
가상화 계층(VM, VPC, 네트워크) 보안이 중요
클라우드 운영 환경에 대한 지속적인 모니터링 필수
클라우드 제공자의 SLA(서비스 수준 계약)에 기반한 물리적 보안 제공

3. 주요 보안 영역 비교

🔐 기술적 보안

인터넷 기반 서비스 특성상 정보 유출 및 공격 위험 증가

🔍 모니터링 보안

클라우드 환경은 지속적인 모니터링과 자동화 기반의 탐지 기능 강화 필요

🛡 물리적 보안

온프레미스: 기업이 직접 책임
클라우드: 서비스 제공자가 담당(SLA 기반)

■ 클라우드 보안 책임 구분 문제

미국 Gartner에 따르면 클라우드 환경에서 발생하는 보안사고의 95%는 사용자의 설정 오류나 관리 부족으로 인해 발생한다.
AWS 같은 클라우드 서비스는 보안 기능을 제공하지만, 설정 자체는 사용자의 책임이기 때문이다.

그러나 클라우드 환경의 보안에서는 다음과 같은 문제점이 존재한다.

1. 서비스 제공자 책임인지 사용자 책임인지 구분이 어려움

● 원인

클라우드는 서비스 제공자 + 사용자가 함께 보안책임을 나누는 구조
(공유 책임 모델, Shared Responsibility Model)
문제가 발생해도
→ 서비스 제공자 책임인지
→ 사용자의 설정 실수인지
경계가 모호한 경우가 많음

● 결과

책임 분쟁 가능
문제 해결 지연
보안사고 대응 체계 혼선 발생

2. 물리적 보안 및 서비스 중단 이슈

클라우드 제공자의 물리적 서비스 중단은
사용자가 통제할 수 없으며,
문제가 발생해도 원인을 투명하게 공개하지 않는 경우가 많다.

3. 기업의 보안 대비 필요성

클라우드를 신뢰만 하고 그대로 사용하는 것이 아니라
기업은 온프레미스 수준의 백업 및 자체 보안 솔루션을 구축해야 한다.

자체적인 보안 모니터링 시스템 필요
클라우드 제공자의 장애에 대비한 백업 전략 필수
서비스 제공자의 과실 여부 판단이 어려우므로 독립적인 관찰체계 필요

📌 결론

“클라우드를 무조건 신뢰해서는 안 된다.”
이는 Apple 휴대폰 사례와 비슷하며,
기기가 문제가 있어도 Apple이 책임을 인정하지 않으면
사용자가 스스로 해결해야 하는 상황이 발생할 수 있다.

클라우드 역시 동일하게
사용자는 적극적으로 보안 체계를 갖추고 대비해야 한다.

■ 클라우드 보안 관리 기준

미국

NIST 800-53 보안 통제 기반
FISMA(연방 정보보안법)에 따라 특정 기준 충족 여부 심사
민간 클라우드 서비스는 FedRAMP 인증을 통해 보안성 검토 후 승인

유럽(EU)

ENISA(유럽 네트워크·정보보안청)에서
‘클라우드 컴퓨팅 위험요소 4가지’와 ‘35개 평가 항목’으로 구성된 보안 평가체계 운영
대표적인 기준: OWASP Top 10

일본

ASPIC 기준 운영

중국

자체적인 국가 기준으로 보안 프레임워크 구성

한국(KISA)

2015년 클라우드 컴퓨팅법 발표
2016년부터 KISA 주도로 클라우드 보안 인증제도 운영 시작

■ 클라우드 보안 관련 국제 단체 및 인증

1) CSA(Cloud Security Alliance)

전 세계 클라우드 보안 가이드라인을 만드는 국제 비영리단체
CSP(Cloud Service Provider)의 보안 수준을 평가할 수 있는 다양한 기준 제공
MSP(Managed Service Provider)의 클라우드 운영·보안 수준도 함께 평가

CSA 기반 주요 인증/평가 체계

CSA STAR 인증
- Level 1: 자기평가
- Level 2: 제3자 독립 평가
- Level 3: 지속적 모니터링 기반 인증(가장 높은 수준)
CSA GRC Stack
- 조직의 거버넌스·리스크·컴플라이언스를 평가하기 위한 체계

2) CCM(Cloud Controls Matrix)

CSA가 만든 클라우드 보안 통제 매트릭스
클라우드 고객이 CSP의 전반적 보안 수준을 평가할 때 사용
16개 영역, 130여 개의 세부 보안 항목으로 구성
(접근통제, 애플리케이션 보안, 데이터 보호 등)

3) CAIQ(Consensus Assessments Initiative Questionnaire)

고객 또는 감사기관이 CSP에게 질의할 수 있도록 만든 표준 질문지
140개 이상의 질문으로 구성
CSP의 보안 대응 능력을 객관적으로 확인 가능
CCM 기반으로 만들어져 상호 대응됨

■ 클라우드 보안의 개념

클라우드 보안이란
사용자가 클라우드 환경에서 생성한 자원이 외부 공격으로부터 안전하게 보호되고,
IT 서비스가 안정적으로 운영되도록 보안 기술·정책·서비스를 적용하는 것을 의미한다.

목표는 다음과 같다:

외부 악의적 위협 차단
내부자의 중요 정보 유출 방지
서비스 안정성과 신뢰성 확보

■ 클라우드 보안의 주요 구성 요소

1) 식별(Identification) 🔍

클라우드 자원에 접근하려는 “주체(사용자·서버·기기)”가 누구인지 확인하는 단계

사용자 ID
로그인 ID
계정 번호
이메일 주소 등

2) 인증(Authentication) 🔐

식별된 사용자가 실제로 본인이 맞는지 증명하는 단계

비밀번호
PIN
OTP, Token
Smart Card
생체 인증(지문, 얼굴 등)

3) 인가(Authorization) 🔏

인증된 사용자가 어떤 행동을 할 수 있는지 권한을 부여하는 과정

리소스 접근 권한
데이터 읽기/쓰기 권한
특정 서비스 설정 권한 등

4) 로그(Log) 📝

사용자가 시스템에서 수행한 모든 행위를 기록

로그인 기록
접근 기록
시스템 이벤트
관리자 행동 로그
→ 전자 문서 형태로 저장되어 보안 감사에 활용됨

5) 모니터링(Monitoring) 📡

시스템·네트워크·데이터의 이상 여부를 지속적으로 관찰

실시간 트래픽 변화
네트워크 비정상 신호
사용자 행위 분석
→ 문제를 빠르게 탐지하기 위한 핵심 기능

6) 감사(Auditing) 🧾

사용자 활동이 정책에 맞게 수행되었는지 검토하고,
보안 위협 요소(데이터 유출·계정 오남용 등)를 분석하는 단계

계정 권한 관리
시스템 설정 검사
규정 준수 여부 확인

7) 책임 추적성(Accountability) 🔎

클라우드에서 발생한 보안 사고의 원인과 책임을 명확히 추적할 수 있게 하는 기능

누가 언제 무엇을 했는지 기록
허가되지 않은 행위 파악
보안 사고 발생 시 근거자료 확보

■ 클라우드 보안의 핵심 흐름

1️⃣ 자원 접근 전에

식별 → 인증 → 인가

2️⃣ 자원 사용 후에는

로그 기록 → 모니터링 → 감사 → 책임 추적

■ 일반 보안 vs 클라우드 보안 비교

온프레미스 보안은 사용자가 모든 인프라를 직접 소유·관리하는 구조이고,
클라우드 보안은 서비스 제공자가 구축한 인프라를 임대해 사용하는 구조이다.
이로 인해 두 환경의 보안 방식에는 중요한 차이가 존재한다.

■ 온프레미스 보안(On-Premise Security)

✔ 보안 3요소 중심 설계 (기밀성 · 무결성 · 가용성)

온프레미스 환경은 모든 요소를 사용자가 직접 제어할 수 있기 때문에
기본적인 보안 3요소에 기반한 보호 전략을 사용한다.

1) 기밀성(Confidentiality)

데이터 암호화
파일·DB 암호화
VPN, 전용선 등을 통한 안전한 통신
접근 통제 및 사용자 인증 강화

2) 무결성(Integrity)

데이터가 변조되지 않고 정확히 유지되는지 보장
접근권한 검증, 로그 확인, 내부 통제 등 활용

3) 가용성(Availability)

재난·화재·정전 등 물리적 장애 대비
DDoS 대응
재난복구센터(DR), 업무연속성계획(BCP) 운영
백업 및 복구 시스템 자체 구축

■ 온디맨드(클라우드) 보안(On-Demand Cloud Security)

클라우드는 사용자가 전체 시스템 내부 구조를 확인할 수 없는 블랙박스(Black Box) 특성 때문에
온프레미스 보안과 동일한 방식만으로는 충분히 보호할 수 없다.

✔ 클라우드 보안 = 기본 보안 3요소 + 책임 추적성 포함한 4요소 모델 고려해야 함

1) 사용자 통제 범위의 한계

인프라·하드웨어·네트워크는 클라우드 제공자가 소유
사용자는 내부 시스템의 물리적 구조를 확인할 수 없음
어떤 장비인지(브랜드, 스펙, 위치 등) 알 수 없는 블랙박스 구조

2) 책임 추적성(Accountability)의 필요성

문제 발생 시
→ 제공자 책임인지
→ 사용자 설정 실수인지
경계가 모호함
이 때문에 로그·모니터링·추적 기능 강화가 필수

3) 고급 보안 도구 활용 필요

클라우드에서는 다음과 같은 오픈소스 도구 활용이 일반적이다:

Helm
Grafana
Kibana

이 도구들은 PaaS(Platform as a Service) 계층에서
트래픽·성능·이상 징후를 실시간 분석하기 위한 핵심 모니터링 도구다.

■ 요약

✔ 온프레미스 보안

사용자가 직접 제어
보안 3요소(기밀성·무결성·가용성) 중심
물리적·논리적 보안 모두 기업이 책임

✔ 클라우드 보안

제공자 인프라 → 사용자는 제한된 제어만 가능
기본 보안 3요소 + 책임 추적성 필수
블랙박스 구조 때문에 추가적인 모니터링·감사 시스템 필요
Helm·Grafana·Kibana 등 고급 분석 도구 필수

■ 책임 공유 원칙(Shared Responsibility)

클라우드 보안 사고의 핵심은
“클라우드 제공자와 사용자 모두가 보안 책임을 나누어 갖는다”는 점이다.
두 주체가 같은 자원(서버, 저장소, 네트워크 등) 을 공유하기 때문에
어디까지가 제공자 책임이고, 어디까지가 사용자 책임인지 명확히 이해해야 한다.

■ 1. 사용자의 책임(User Responsibility)

사용자는 데이터 및 애플리케이션 보안을 직접 담당해야 한다.

사용자가 책임지는 영역

IaaS
→ 데이터, 애플리케이션, OS 관리
PaaS
→ 데이터, 애플리케이션
SaaS
→ 데이터(사용자 정보, 계정 관리 등)

사용자가 수행해야 할 보안 활동

데이터 암호화
사용자 인증 강화
접근통제 설정
계정·권한 관리
애플리케이션 보안 패치
로그 기록 및 보안 설정 관리

👉 즉, 데이터 보호와 서비스 환경 설정에 대한 책임은 사용자에게 있다.

■ 2. 제공자의 책임(Cloud Service Provider Responsibility)

클라우드 제공자는
사용자가 통제할 수 없는 인프라 전체의 보안을 담당한다.

제공자가 책임지는 영역

서비스 모니터링
가상화 하이퍼바이저 보안
OS 및 네트워크를 포함한 하부 인프라 보안
물리적 데이터센터 보안
서버 패치·정책 관리
장애 대응 및 인프라 운영
시스템 보안(분리, 격리, 방화벽 등)

👉 즉, 클라우드가 안전하게 운영되도록 하는 근본적인 인프라 보안은 제공자가 책임진다.

■ 3. 왜 책임 공유가 필요한가?

클라우드 환경은 제공자와 사용자가 하나의 플랫폼을 함께 사용하기 때문에
보안 사고가 발생했을 때 책임 범위가 모호해질 수 있다.

누구의 설정 실수인지?
데이터 유출이 사용자 문제인지?
인프라 장애가 제공자 책임인지?

이러한 문제를 방지하기 위해
양쪽 모두가 명확한 책임 분담 구조를 따라야 한다.

■ 4. 책임 공유 모델에서 사용자가 반드시 해야 할 것

사용자는 클라우드 서비스 제공자 보안 수준을 점검하고
자신에게 부여된 보안 책임을 충실히 수행해야 한다.

사용자가 수행해야 할 보안 설계 요소:

식별(Identification)
인증(Authentication)
인가(Authorization)
책임 추적성(Auditing & Accountability)
모니터링
보안 정책 준수

👉 즉, 사용자 스스로 책임을 설계하고 실행해야 사고를 예방할 수 있다.

■ 제로 트러스트(Zero Trust) 보안 모델

제로 트러스트는
“아무것도 신뢰하지 않고, 모든 것을 검증한다"라는 원리를 가진 최신 보안 모델이다.
클라우드 환경에서 신규 서비스를 런칭하거나
기존 시스템을 클라우드로 이전할 때 가장 많이 적용되는 방식이다.

■ 1. 제로 트러스트가 필요한 이유

기존 보안 체계는 내부 시스템을 ‘신뢰 구역’, 외부를 ‘비신뢰 구역’으로 구분하는 방식이었다.
하지만 클라우드 시대에는 다음의 이유로 기존 모델이 더 이상 유효하지 않다:

내부 사용자라도 보안 사고를 일으킬 수 있음
재택근무·원격 접근 증가
클라우드 리소스가 외부 인터넷 기반에서 동작
애플리케이션·데이터가 여러 지역에 분산

👉 따라서 클라우드에서는 어떤 사용자·장치·네트워크도 기본적으로 신뢰하지 않는 구조가 필요하다.

■ 2. 제로 트러스트의 핵심 개념

제로 트러스트는 다음의 원칙을 기반으로 한다.

✔ 모든 보안 설정을 “처음부터 다시 검증”

기존 설정을 신뢰하지 않으며
내부·외부 구분 없이 모든 접근 요청을 완전히 새롭게 검증한다.

✔ 전체 시스템에 대한 지속적 관찰

로그 분석
트래픽 모니터링
정책 준수 검증
→ 지속적인 모니터링과 감사(Auditing)를 통해 실시간 관리

✔ 단 한 번도 신뢰하지 않음

“한 번 인증하면 모든 자원에 접근 가능”한 구조를 제거
→ 요청할 때마다 접근 권한을 재확인

■ 3. 제로 트러스트의 보안 단계(5단계 구조)

클라우드 보안에서 제로 트러스트는 5가지 구성 요소로 이루어진다.

1) 네트워크를 통한 접속 차단

가장 먼저 네트워크 레벨에서 잠재적 위협을 차단

2) 접근자의 신원 분석

접속 요청을 보낸 주체가 누구인지, 정상적인 사용자·기기인지 확인

3) 접근 요청의 정당성 검증

요청하는 행위가 적절한 권한 내에서 이루어지는지 판단

4) 리소스 접근 권한 확인

각 클라우드 리소스에 대해 사용자가
정확한 권한(읽기/쓰기/수정 등)을 가지고 있는지 판단

5) 검증 후 최소 권한 기반으로 자원 접근 허용

위의 1~4단계를 모두 통과해야만
사용자는 필요한 최소 범위 안에서만 클라우드 리소스를 사용할 수 있음

👉 즉, “Only verified users with least privilege can access.”

■ 결론

제로 트러스트는 클라우드 시대를 위한 가장 강력한 보안 모델로,
사용자·네트워크·기기·리소스 모두를 지속적으로 검증하며
단 한 순간도 신뢰하지 않는 방식으로 동작한다.

■ 클라우드 보안의 Trade-Off

클라우드 환경에서는 사용 편리성과 보안 통제력이 서로 충돌(trade-off)하는 특성이 있다.

사용자(내부 직원·외부 사용자·개발자·운영자 등)에게 얼마나 많은 권한을 부여할지
서비스가 외부에 얼마나 노출되는지
데이터가 어디에 저장되는지

이러한 요소에 따라 필요한 보안 설정은 달라지며,
클라우드는 보안 등급을 기준으로 평가할 수 있다.

■ 클라우드 보안 등급

● 1등급 보안

네트워크 패킷이나 사용자 로그 기반으로 이상행위를 탐지해야 하는 수준

침입 탐지(IDS)
트래픽 분석
사용 패턴 기반 모니터링 강화 필요

● 2등급 보안

데이터 보호와 웹 서비스의 보안 강화가 필요한 단계

암호화
웹 방화벽(WAF)
안전한 API 게이트웨이
데이터 접근제어

● 3등급 보안

네트워크·사용자 인증·접근 통제 등
전반적인 보안 체계를 광범위하게 적용해야 하는 높은 수준

다중 인증(MFA)
최소 권한 기반 접근 제어
강력한 네트워크 정책
서비스 전체 감사·모니터링 체계 필요

참고: IDG(Integration Data Group)에 따르면
기업의 IT 과제 및 필요 역량이 다르므로 클라우드 선택 목적도 자연스럽게 달라진다.

■ 클라우드 모델별 선택 목적

각 클라우드 서비스 모델(SaaS, PaaS, IaaS)은
보안 책임 범위·관리 난이도·운영 필요성에 따라 선택 이유가 다르다.

✔ SaaS (Software as a Service)

ERP, CRM, 메일, 협업툴, 모바일 앱 등
“완성된 소프트웨어”를 그대로 사용하는 경우 선택

유지보수 부담 최소화
생산성 향상
보안 대부분을 제공자가 관리함

✔ PaaS (Platform as a Service)

개발·테스트·시스템 관리·DevOps 환경 구축에 적합

애플리케이션 개발 효율성 상승
환경 설정과 서버 관리 시간 절감
비즈니스·데이터 분석 환경 구축에도 활용

✔ IaaS (Infrastructure as a Service)

최대 유연성과 확장성을 제공

재난복구(DR)
개발·테스트 환경
대규모 DB·스토리지
백업 및 보관 목적

기업은 IaaS를 통해 클라우드의 자유로운 커스터마이징과 확장성을 최대한 활용할 수 있다.

■ 온프레미스 vs 온디맨드(클라우드) 보안의 가장 큰 차이

온프레미스(자체 구축 환경)와 클라우드 보안 설계의 가장 큰 차이는
보안의 중심이 ‘자원 보호’인지, ‘행위 기반 통제’인지에 있다.

온프레미스 → 서버·네트워크·물리 장비를 “직접 보호”하는 보안
클라우드 → 사용자·계정·행위에 대한 “모니터링과 통제”가 핵심

■ 왜 클라우드는 ‘보안 관제’가 더 중요할까?

클라우드는 사용자가 인프라 내부 구조를 알 수 없는 블랙박스 환경이다.
따라서 기존처럼 서버에서 직접 패킷을 수집해 분석하는 방식이 어렵다.

클라우드의 한계

물리적 장비(서버, 네트워크 스위치) 접근 불가
내부 로그·메모리·패킷을 직접 수집하기 어려움
제공자가 어떤 하드웨어·위치·특성을 사용하는지 알 수 없음

👉 그래서 클라우드 보안에서 가장 중요한 것은
사용자의 행위 기반 모니터링과 추적(Accountability) 이다.

■ 클라우드 보안에서 필요한 접근 방식

클라우드에서는 서버를 보호하는 대신
다음과 같은 요소를 통해 보안 이상 징후를 탐지해야 한다.

✔ 사용자 행위 분석(UEBA)

비정상 로그인
과도한 권한 변경
데이터 대량 다운로드 등

✔ 실시간 모니터링

트래픽 증가
API 호출 패턴 변화
비정상적인 인증 요청

✔ 로그 기반 추적

모든 접근·행위에 대한 지속적인 기록
책임 추적성 확보

■ 클라우드 보안 강화: SECaaS / CASB 활용

클라우드 보안의 특성상
기업이 자체적으로 모든 보안 영역을 커버하기 어렵기 때문에
다음과 같은 보안 전문 서비스를 활용하는 것이 효과적이다.

✔ SECaaS (Security as a Service)

클라우드 기반 보안 서비스 제공 모델

✔ CASB (Cloud Access Security Broker)

클라우드 사용자와 CSP 사이에서
보안 정책·접근 제어·데이터 보호를 수행하는 중간 보안 게이트웨이

■ CSA(Cloud Security Alliance)가 선정한 클라우드 보안 주요 영역

CSA가 인정한 클라우드 보안 분야는 다음과 같다:

IAM (Identity Access Management) — 계정 관리
DLP (Data Loss Prevention) — 자료 유출 방지
Web Security — 웹 보안
Email Security — 이메일 보안
Security Assessment — 보안 평가
Intrusion Management — 침입 관리
SIEM (Security Information & Event Management) — 보안 이벤트 관리
Encryption — 암호화
BCDR (Business Continuity & Disaster Recovery) — 비즈니스 연속성과 재해 복구
Network Security — 네트워크 보안

■ AWS에서 CMP 사용하기 (AWS Management Console)

AWS(https://aws.amazon.com)에 가입하면
AWS Management Console(CMP)을 통해 모든 클라우드 리소스를 관리할 수 있다.

로그인 후 콘솔 화면에서는
서비스 선택, 리전(Region) 변경, 자주 사용하는 기능 접근 등을 빠르게 수행할 수 있다.

■ AWS에서 제공하는 주요 서비스 구성

AWS는 크게 다음 요소들로 구성된다:

✔ 컴퓨팅

EC2 : 가상 머신 인스턴스 생성
Auto Scaling : 서버 자동 확장

✔ 스토리지

S3 : 객체 저장소
EBS : 블록 스토리지

✔ 네트워크

VPC : 격리된 가상 네트워크 환경 구성
VPN, ACL, 보안그룹(SG) 설정 가능

✔ 계정 및 권한

IAM : 사용자·그룹·정책 관리

✔ 모니터링

CloudWatch : CPU, 메모리, 로그, 이벤트 등 모니터링
CloudTrail : 사용자·API 호출 기록 확인

✔ 보안

ACM : TLS/SSL 인증서
Shield / WAF : DDoS 및 웹 공격 방어
KMS : 암호화 키 관리

✔ 운영 및 기타 서비스

AMI : 인스턴스 이미지
RDS : 관리형 데이터베이스
ECR : 컨테이너 이미지 저장소

➡ 이러한 서비스들을 메뉴에서 클릭해 필요한 리소스를 즉시 생성할 수 있다.

■ 계정 및 접근 권한 관리(IAM: Identity and Access Management)

클라우드 보안의 핵심은 계정 관리 + 권한 통제이다.

IAM은 AWS에서 다음과 같은 기능을 제공한다.

✔ 1) 사용자(User)

AWS에 로그인할 수 있는 계정
실 사용자 또는 시스템 계정에 해당

✔ 2) 그룹(Group)

여러 사용자를 묶어서 일괄적으로 권한 부여
예: 개발팀 그룹, 운영팀 그룹 등

✔ 3) 역할(Role)

AWS 리소스가 다른 서비스에 접근할 때 사용하는 “임시 권한”
서버·람다·컨테이너 등이 역할(Role)을 대신 사용

✔ 4) 정책(Policy)

IAM 권한의 핵심
JSON 형식으로 작성된 “허용/거부 규칙”
- 읽기(Read)
- 쓰기(Write)
- 삭제(Delete)
- 특정 리소스만 허용 등

→ 어떤 작업을 어떤 리소스에 대해 수행할 수 있는지를 정의

■ IAM이 중요한 이유

클라우드는 누가 무엇을 했는지 추적하는 것이 매우 중요
잘못된 권한 설정은 클라우드 보안 사고의 80% 이상을 차지
IAM을 통해 사용자 접근을 최소 권한(Least Privilege)으로 유지해야 함
AWS는 콘솔·CLI·SDK·라이브러리를 통해 IAM 정책을 자동화 가능

■ IAM 활용 핵심 요약

기능	설명
사용자	로그인 가능한 개별 계정
그룹	공통 권한을 여러 사용자에게 빠르게 부여
역할(Role)	AWS 서비스가 다른 서비스에 접근할 때 사용하는 임시 권한
정책(Policy)	JSON 기반 권한 규칙

IAM을 잘 설정하면
클라우드 전체 보안을 가장 크게 강화할 수 있다.

■ AWS에서 IAM 사용하기 (실습형 정리)

IAM은 AWS 클라우드에서 사용자·그룹·권한을 관리하는 핵심 서비스이며,
주로 다음 흐름으로 구성된다:

그룹(Group)을 생성
그룹에 정책(Policy)을 연결
사용자(User)를 생성
사용자를 그룹에 추가

아래는 그 과정을 이해하기 쉬운 순서대로 정리한 실습 예시이다.

■ 1. IAM 그룹 생성하기

예제에서는 개발자를 위한 그룹을 만들고,
해당 그룹에 필요한 권한을 연결하는 과정으로 설명한다.

➤ 단계 1: IAM 서비스 이동

AWS Management Console 좌측 상단에서 IAM 서비스로 이동한다.

➤ 단계 2: 그룹 생성

좌측 메뉴에서 그룹(Group) 선택
그룹 생성(Create Group) 버튼 클릭
그룹 이름 입력: 예) Develops

➤ 단계 3: 정책 연결

그룹에 권한(Policy)을 부여하는 단계

검색창에 AmazonEC2ReadOnlyAccess 입력
정책을 선택하고 다음 단계 진행
그룹 생성 버튼 클릭 → 그룹 생성 완료

이제 Develops 그룹은 EC2 리소스를 읽기만(ReadOnly) 할 수 있는 권한을 가진다.

■ 2. IAM 사용자 생성하기

이제 그룹에 포함될 사용자를 생성한다.

➤ 단계 1: 사용자 생성 페이지 이동

좌측 메뉴에서 사용자(Users) 선택
→ 사용자 추가(Add User) 클릭

➤ 단계 2: 사용자 정보 입력

사용자 이름: 예) paul
액세스 유형 선택:
- ❗ 보통 실습에서는 “AWS Management Console 액세스”를 선택
- 로그인 비밀번호 또한 설정 필요

➤ 단계 3: 그룹에 사용자 연결

“그룹에 사용자 추가” 단계에서
기존에 만든 Develops 그룹 선택
다음 버튼 클릭하여 사용자 생성 완료

이제 paul 사용자는 Develops 그룹에 속해,
AmazonEC2ReadOnlyAccess 정책이 자동 적용된다.

■ 3. 최종 구조 확인

그룹 → 정책 → 사용자 순으로 연결된 최종 구성은 다음과 같다:

그룹: Develops
그룹 권한: AmazonEC2ReadOnlyAccess
사용자: paul
결과: paul은 EC2 리소스 조회만 가능(ReadOnly)

■ 핵심 요약

항목	설명
그룹(Group)	여러 사용자에게 공통 권한 부여
정책(Policy)	JSON 기반 권한 규칙 (읽기/쓰기/삭제 등)
사용자(User)	AWS 콘솔/CLI 사용 주체
흐름	그룹 생성 → 정책 연결 → 사용자 생성 → 그룹에 추가

■ AWS에서 CloudWatch 사용하기

CloudWatch는 AWS에서
로그 수집 · 모니터링 · 알림 관리 · 대시보드 시각화
등을 담당하는 핵심 서비스이다.

AWS 콘솔에서 CloudWatch로 이동하면
모든 리소스의 지표(metric)와 로그(log)를 실시간으로 모니터링할 수 있다.

CPU/메모리 사용량 추적
네트워크 트래픽 분석
애플리케이션 동작 상태 확인
특정 조건에서 알람(Alert) 발동
사용자 정의 대시보드 구성 가능

CloudWatch는 AWS 운영의 “눈”이라고 부를 정도로 필수적인 서비스이다.

■ CloudWatch에서 수집되는 주요 로그 종류

AWS에서는 서비스 특성에 따라 다양한 로그가 발생하며,
아래는 가장 대표적인 로그 유형이다.

✔ 1) VPC Flow Logs (가상 네트워크 트래픽 로그)

AWS의 VPC(가상 네트워크) 내부에서 발생하는
네트워크 트래픽 흐름을 기록한 로그

서브넷 간 트래픽
보안그룹(SG)·ACL에 의해 차단/허용된 흐름
외부로 나가는 트래픽 확인
침입 탐지(IDS) 및 분석에 유용

👉 네트워크 단의 모든 패킷 흐름을 추적

✔ 2) DNS Query Logs (DNS 요청 로그)

AWS Route 53 또는 내부 DNS가
어떤 도메인을 요청했고, 어떤 서버로 연결되었는지 기록

악성 도메인 접속 여부 파악
내부 사용자 DNS 행위 분석
이상 트래픽 탐지

👉 모든 DNS 기반 요청 기록

✔ 3) CloudTrail Logs (사용자 이벤트 로그)

AWS 계정 내에서 누가 어떤 작업을 수행했는지 기록하는 로그

콘솔 로그인 기록
IAM 변경 기록
EC2 생성/삭제
S3 버킷 수정
API 호출 내역

👉 사용자·계정 행동 추적(Event Logs)

✔ 4) Resource Logs (AWS 리소스별 로그)

각 서비스에서 자체적으로 발생하는 로그들

S3 Access Logs
RDS Slow Query Logs
Lambda 실행 로그
ECS 컨테이너 상태 로그
ELB Access Logs
DynamoDB Audit Logs

👉 서비스 동작 상태를 실시간으로 추적

✔ 5) Application Logs (애플리케이션 로그)

애플리케이션 레벨에서 발생하는 로그로
CloudWatch Agent 또는 SDK를 통해 업로드한다.

예시:

애플리케이션 에러 로그
비즈니스 로직 로그
API 호출 흐름 로그

👉 개발자가 생성한 로그

✔ 6) User-Defined Logs (사용자 정의 로그)

AWS가 제공하지 않는 서비스나
기업 내부에서 직접 만든 프로그램 로그를
CloudWatch Logs로 전송하는 방식

예:

사내 시스템 로그
커스텀 스크립트 로그
특정 알림 조건 설정용 로그

👉 사용자가 직접 생성하여 업로드한 로그

■ CloudWatch 로그 요약표

로그 종류	용도
VPC Flow Logs	네트워크 트래픽 추적·보안 분석
DNS Logs	DNS 기반 요청·악성 도메인 탐지
CloudTrail Logs	사용자·계정 API 호출 기록
Resource Logs	서비스별 동작 상태 분석
Application Logs	애플리케이션 동작 기록
User-Defined Logs	커스텀 로그 / 기업 자체 로그

■ 골든환경(사용자 정의 환경)이란?

클라우드에서 원하는 자원을 효율적으로 사용하려면
매번 처음부터 값을 입력해 VM·인스턴스·스토리지 등을 생성하는 것이 비효율적이다.

그래서 자주 사용하는 설정·보안 구성·패키지 등을 미리 적용해 둔 이미지(템플릿) 를 만들어
복제하여 쓰는 방식이 바로 골든이미지(Golden Image)이다.

■ 왜 골든이미지가 필요한가?

✔ 1) 보안·정책 일관성 유지

인스턴스마다 설정이 제각각이면 보안 사고 위험 증가
공통 보안정책(방화벽, 계정 정책, 패키지 버전 등)을 이미지에 미리 포함
→ 배포되는 모든 인스턴스가 동일한 보안 구조를 가짐

✔ 2) 운영 자동화 / 관리 부담 감소

매번 수동 설정 X
이미지 한 번 만들면 → 수백·수천 개 서버도 일관되게 구성
DevOps 자동화 환경(CI/CD)에서 특히 중요

✔ 3) 신속한 서비스 배포

이미지 기반으로 즉시 인스턴스 생성
설정·패키지·보안 구성 모두 이미 포함
→ 배포 속도 극대화

■ 골든이미지에서 반드시 포함되는 항목

골든이미지는 보안 설정이 미리 적용된 표준 템플릿이다.

포함되는 대표 요소

최신 보안 패치(OS, 패키지 업데이트)
불필요한 포트 차단
SSH 등 접근 보안(키 인증)
필수 패키지 설치
사용자 생성 정책
모니터링 에이전트(CloudWatch, Datadog 등)
로깅 설정

예)

기본 SSH 포트 22만 허용하거나
80/8080 웹 포트만 개방
Ubuntu는 root 로그인 차단
ECS 접근은 ‘user+password’가 아닌 passphrase 기반 SSH 키만 허용

■ AWS에서 골든이미지 만들기 (AMI)

AWS에서는 AMI(Amazon Machine Image)를 통해 골든이미지를 구성한다.

만들기 방식

기본 EC2 생성
필요한 패키지·보안 패치 적용
OS 설정·계정 구성
모니터링 및 로깅 설정 추가
“이미지 생성(Create Image)” 버튼 클릭

→ 이렇게 만든 AMI는 보안정책이 반영된 Gold-VM으로 언제든지 재사용 가능

활용 예

개발/테스트용 서버 여러 대 생성
대규모 확장(오토스케일링)
특정 서비스 전용 사양 템플릿 생성

■ 글로벌 주요 클라우드의 골든이미지 서비스

클라우드	골든이미지 서비스
AWS	AMI (Amazon Machine Image)
Azure	Managed Disk / Azure Resource Manager 기반 이미지
GCP	Image + Cloud Deployment Manager

모두 보안 정책·설정이 미리 들어 있는 기본 템플릿 기능을 제공한다.

■ 골든이미지(Golden Image)의 핵심 개념

골든이미지(Gold-Image)는
“보안 설정·패키지·네트워크 정책·계정 규칙 등을 미리 적용해둔 표준 서버 이미지” 이다.

이 이미지를 기반으로 서버(EC2 등)를 생성하면
매번 초기 설정을 반복하지 않아도 되고,
모든 서버가 동일한 보안 기준을 유지할 수 있다.

■ 골든이미지가 필요한 이유

✔ 1) 보안 정책 일관성 유지

SSH 포트 최소 허용
패스워드 로그인 차단
키 기반 인증 설정
root 계정 비활성화
기본 방화벽 규칙 포함

✔ 2) 운영 자동화 및 오류 감소

매번 설치·설정 반복 불필요
사람이 반복할 때 발생할 수 있는 실수 제거
대규모 배포 시 동일한 환경 보장

✔ 3) 빠르고 안전한 서버 운영

배포 직후 바로 서비스 운영 가능
보안 패치가 반영된 상태에서 시작

■ 예시: 미리 적용되는 보안 설정들

골든이미지에는 보안 요소가 미리 포함된다:

SSH 포트 22만 허용, 기타 포트 차단
HTTP 80 또는 8080 허용 (웹 서버용)
Ubuntu 계정 비활성화
ECS 작업은 user+password가 아닌 passphrase 기반 SSH 키로 접속
로깅·모니터링 에이전트 설치 (CloudWatch 등)

이런 설정을 매번 직접 하지 않아도 되므로
안전하고 표준화된 서버 환경을 즉시 만들 수 있다.

■ AWS에서 골든이미지(AMI) 만들기

AWS에서는 AMI(Amazon Machine Image)를 이용해 골든이미지를 생성할 수 있다.

✔ 골든이미지 생성 방식

EC2 인스턴스를 먼저 생성
필요한 보안 패키지·OS 패치 적용
계정 정책 설정
네트워크 규칙 구성
모니터링·로그·보안 에이전트 설치
완료 후 → “이미지 생성(Create Image)” 클릭

✔ 중요 포인트

EC2 자원을 사용할 때 기존 인스턴스를 그대로 사용하는 것이 아니라,
골든이미지를 실행해야 보안 정책이 반영된 Gold-VM 이미지가 생성된다.

즉,
기존 VM을 그대로 복사하면 보안 기준이 빠질 수 있기 때문에
반드시 “보안 기준이 적용된 이미지”를 기반으로 새 서버를 시작해야 한다.

■ AMI 만들기 후 활용

골든이미지를 만든 뒤에는 AWS 콘솔에서

새로운 서버 생성 시 AMI를 선택
즉시 동일한 보안환경의 서버 생성 가능
Auto Scaling 그룹에도 연결하여 동일한 환경 유지 가능

AWS뿐만 아니라

Azure → Managed Disk / Azure Resource Manager
GCP → Image / Cloud Deployment Manager
와 같은 방식으로 동일하게 지원한다.

■ 핵심 요약

골든이미지는 보안·설정·패키지가 미리 적용된 표준 VM
매번 초기 설정이 필요 없어 운영 속도·안정성 증가
보안 정책 누락 방지
AWS에서는 AMI로 구성
“기존 EC2”가 아닌 “골든이미지 기반 EC2”를 사용해야 보안이 유지됨

■ 클라우드에서의 네트워크 보안

클라우드의 네트워크 영역은
인터넷 기반에서 외부 공격에 노출될 가능성이 가장 높은 부분이며
내부 사용자·외부 사용자 모두 접근할 수 있으므로
가장 중요한 보안 대상이다.

특히 Shadow IT(허가되지 않은 시스템 사용) 등의 위험도 존재하므로
사용자와 다른 클라우드 제공자 인프라가 연결되는 모든 지점에서
네트워크 경계 보안을 고려해야 한다.

■ 클라우드 네트워크를 보호해야 하는 이유

외부 인터넷 환경과 직접 맞닿아 있음
불특정 다수가 접근 가능
DDoS·스캐닝·침투 공격 위험
모바일·PC·서버 등 다양한 디바이스가 접근
내부 사용자의 설정 실수도 치명적인 보안 사고 유발

👉 따라서 네트워크 보안 계층 설계는 클라우드 보안의 핵심 영역이다.

■ 가상 사설 클라우드 (VPC: Virtual Private Cloud)

VPC는 클라우드에서 사용자가 직접 정의하는
논리적으로 완전히 분리된 가상 네트워크 공간이다.
(kubernetes의 Namespace 개념과 유사)

각 VPC는 상호 간에 기본적으로 통신 불가이며,
IP 대역·서브넷·라우팅·방화벽 등을 직접 설정하여
사용 목적에 맞는 네트워크를 만들 수 있다.

■ VPC의 특징

✔ 1) 네트워크가 독립적

회사 내부망처럼 완전히 분리된 네트워크 구축 가능
개발/테스트/운영/외부 서비스 등을 분리하여 보안성 향상

✔ 2) 사용자 정의 네트워크

원하는 IP 대역을 직접 설정 가능:

예) 10.0.10.0/16, 192.168.0.0/16 등

✔ 3) VPC는 자동 생성되기도 함

EC2 인스턴스를 최초 생성할 때
“기본 VPC(Default VPC)”가 자동으로 생성되어 사용 가능
→ 네트워크 지식이 없어도 서버를 배포할 수 있다는 장점

✔ 4) 목적별로 여러 VPC 구성 가능

상황이나 업무 특성에 맞게

운영용 VPC
개발용 VPC
테스트용 VPC
데이터 분석용 VPC
등을 각각 따로 만들 수 있음

■ 예시로 보는 VPC 구성하기

✔ 예시 1) 운영 환경용 VPC

IP 대역: 10.0.0.0/16
내부 서버 간 고도의 보안 필요
→ 운영 서비스 리소스 배치

✔ 예시 2) 개발 환경용 VPC

IP 대역: 172.31.0.0/16
테스트용, 시뮬레이션용 서버 배치
→ 운영과 완전히 분리되어 안전함

✔ 예시 3) 외부 서비스용 VPC

IP 대역: 192.168.100.0/24
웹서비스·API 서버 배치
→ 인터넷 게이트웨이를 통해 외부와 통신

✔ 예시 4) 격리 환경 VPC

IP 대역: 10.40.0.0/24
외부와 완전 단절
→ 민감한 데이터 처리 환경에 적합

■ VPC를 사용하면 얻는 보안 효과

환경 간 완벽한 분리(운영·개발·테스트 간 격리)
특정 IP·포트만 허용하는 세밀한 제어
인터넷 노출 최소화
내부 통신 보호
Shadow IT 차단
사용자 실수로 인한 보안사고 감소
멀티 계층 보안 설계(ACL, NACL, SG 등) 가능

■ 핵심 요약

개념	설명
VPC	클라우드에서 직접 만드는 독립 네트워크
목적	보안 강화, 환경 구분, 통신 제어
장점	외부 공격 차단, 사용자 실수 방지, 운영·개발 완전 분리

■ AWS에서 서브넷 설정하기 (Subnets)

VPC 안에서 EC2 인스턴스가 위치하는 “세부 네트워크 구역”이 바로 서브넷(Subnet)이다.
서브넷을 분리하면 운영·개발·DB 등 목적에 따라 네트워크를 안전하게 분리할 수 있다.

아래는 새로운 서브넷을 만들고,
기존 EC2 자원을 새 서브넷으로 이동하는 실습 흐름이다.

■ 1. 서브넷 생성하기

① 서브넷 서비스로 이동

AWS Management Console → VPC 메뉴
좌측에서 Subnets 선택
Create Subnet(서브넷 생성) 버튼 클릭

② 서브넷 이름 지정

예: Cloud-Private-subnet

③ 사용할 VPC 선택

예: 한국 리전(ap-northeast-2) →
a, b, c, d 중 원하는 AZ(가용 영역) 선택
예: ap-northeast-2a

④ 서브넷의 IP 대역 입력

기존 VPC가 10.10.0.0/16이라면 →
예: 10.10.10.0/24 등으로 세부 대역 할당

⑤ 생성 버튼 클릭 → 서브넷 생성 완료

■ 2. 기존 EC2 인스턴스를 새 서브넷으로 이동하기

EC2는 한 번 생성하면 기본적으로 다른 서브넷으로 직접 이동할 수 없기 때문에
다음의 절차가 필요하다.

✔ 이동 방법

AMI(이미지)를 만들고 → 그 이미지로 새로운 인스턴스를 생성 → 새 서브넷에 배치

■ 3. AMI 기반으로 새인스턴스 생성 (골든이미지 활용 시)

① 기존 인스턴스에서 AMI 생성

EC2 → 인스턴스 선택
Actions → Create Image(이미지 생성) 클릭
Gold-Image를 선택할 수도 있음

② AMI로 새 인스턴스 생성

AMI 메뉴 → 생성된 이미지 선택
Launch Instance(인스턴스 시작) 클릭

③ 인스턴스 유형 선택

T2, T3, M5 등 원하는 사양 선택

④ 새 서브넷 선택

Networking 설정에서 “Subnet” 항목 변경
앞서 만든 Cloud-Private-subnet 선택

⑤ 나머지 설정 완료 후 인스턴스 생성

이제 새 서브넷에서 EC2가 시작됨
기존 인스턴스는 필요시 종료 가능

■ 참고: 글로벌 클라우드 공통 사항

AWS, Azure, GCP 등 주요 클라우드는
모두 “서브넷(Subnet)” 개념을 사용한다.

AWS: Subnet
Azure: Subnet
GCP: Subnet

→ 네트워크를 잘게 나눠 보안·관리 목적에 맞게 구성하는 기능은 모든 클라우드에서 동일하다.

■ 핵심 요약

서브넷은 VPC 내부의 논리 네트워크 구획
새 서브넷 생성 → 기존 EC2 이동은 AMI 기반으로
운영/개발/DB 환경 분리에 매우 효과적
글로벌 클라우드 모두 동일 개념 사용

■ 방화벽(Firewall)

방화벽은 VPC 네트워크 안에서 허용된 IP·포트만 통과시키는 보안 장치로,
클라우드 환경에서 가장 기본적이며 필수적인 보호 계층이다.

클라우드 자원을 생성하기 전부터
어떤 자원이 어떤 그룹에 속하고, 어떤 접근을 허용할지
사전에 계획해야 한다.

■ 방화벽의 기본 원리

클라우드 방화벽은 다음 두 가지 방향 규칙을 가진다:

✔ 인바운드(Inbound) 규칙

외부 → 내부로 들어오는 요청 제어
(예: 인터넷에서 EC2로 접근하는 트래픽)

✔ 아웃바운드(Outbound) 규칙

내부 → 외부로 나가는 요청 제어
(예: 서버에서 외부 API 요청)

두 규칙을 조합하여
자원이 허용된 트래픽만 주고받도록 통제한다.

■ 방화벽의 특징

✔ 1) Stateful 특성

트래픽의 상태를 기억한다.
요청이 정상적으로 들어왔으면 응답 패킷은 자동 허용.
인입되는 패킷과 인출되는 패킷을 함께 관리.

✔ 2) 자동 생성

클라우드에서는
자원이 생성되면 “기본 방화벽(보안 그룹)”이 자동으로 설정되지만,
수백~수천 개 자원을 운영하려면
반드시 설계된 정책 기반으로 재구성해야 한다.

✔ 3) 자원 단위 필터링

각 가상머신, 로드밸런서, 컨테이너 등 원하는 자원별로
개별적 방화벽 적용 가능
공용/사설 구분도 가능 (공개서버: 80/443 허용, 내부서버: 제한)

■ 방화벽 구성 예시

✔ 웹 서버(공개 서비스)

인바운드: 80, 443 허용
출발지: 0.0.0.0/0 (전 세계)
아웃바운드: 기본 전체 허용

✔ 내부 DB 서버

인바운드: 3306(예시), 출발지: 웹서버 서브넷만 허용
외부에서 직접 접근 금지
아웃바운드: 보안 솔루션/업데이트 서버만 허용

✔ SSH 관리 서버

인바운드: 22 포트
출발지: 관리자 고정 IP로 제한
Any IP 허용 금지

👉 Any IP (0.0.0.0/0), Any Port, Any Protocol 설정은 가능한 최소화!
보안 취약점의 핵심 원인이 됨.

■ 방화벽 설계 시 권장 사항

✔ 1) 최소 권한(Least Privilege)

CIDR(예: 10.0.1.0/24) 범위를 가능한 좁게 설정

✔ 2) 목적별 분리

웹, DB, 관리, 내부 API 등 자원마다 방화벽 별도 구성

✔ 3) 정기 검토

포트 개방 내역 점검
불필요 규칙 제거
서비스 변경 시 규칙 업데이트

✔ 4) Any 규칙 최소화

Any IP, Any Port, Any Protocol은 가능한 지양
자원 기반 필터링으로 축소

■ 핵심 요약

개념	설명
방화벽	IP·포트 기반 네트워크 접근 통제
인바운드	외부 → 내부 요청
아웃바운드	내부 → 외부 요청
원칙	최소 허용(Least Privilege), Any 규칙 최소화
필요성	자원 보호, 서비스 안정성, 보안 사고 예방

■ AWS에서 방화벽(Security Group) 사용하기

AWS의 방화벽은 Security Group(SG) 이다.
각 자원(EC2, RDS, 로드밸런서 등)에 대해
목적별로 서로 다른 보안 규칙을 적용할 수 있는 독립적인 방화벽이다.

Security Group은 자원 기반·상태 기반(Stateful) 필터링을 제공하며,
서비스별로 개별 SG를 만들어 분리된 보안 체계를 구성할 수 있다.

■ 1. Security Group 생성 흐름

AWS 콘솔에서 다음 경로로 이동한다:

네트워크 및 보안 → 보안그룹(Security Groups)

기본적으로 “default” SG가 존재하지만
실제 운영에서는 목적별 보안그룹을 개별적으로 생성하여 사용한다.

예를 들어 다음과 같이 구성할 수 있다:

WEB-Security-group
WAS-Security-group
DB-Security-group

각 서비스 계층별로 독립 보안 정책을 적용해
보안 침해를 격리하는 구조를 만든다.

■ 2. Security Group 생성하기 (예: 웹 서버용)

✔ 단계 1

좌측에서 보안그룹 생성(Create Security Group) 클릭

✔ 단계 2

이름 입력: WEB-Security-group
설명 입력: “웹 서비스용 보안 그룹”
VPC 선택: 연결될 VPC 지정(예: default 또는 custom VPC)

✔ 단계 3 (인바운드 규칙 설정)

웹 서버라면 다음 정도가 일반적:

프로토콜	포트	출발지	설명
TCP	80	0.0.0.0/0	HTTP
TCP	443	0.0.0.0/0	HTTPS

필요한 경우 관리용 SSH 포트(22번)는 관리자의 고정 IP로만 허용하도록 제한

✔ 단계 4

보안그룹 생성(Create) 클릭 → SG 생성 완료

■ 3. 다른 계층(WAS/DB) 보안그룹 생성

같은 방식으로 WAS, DB 보안그룹도 생성한다.

예)

WAS-Security-group

Inbound: 8080 포트
출발지: WEB-Security-group
(웹서버만 WAS 서버 접근 가능)

DB-Security-group

Inbound: 3306 포트
출발지: WAS-Security-group
(WAS만 DB에 접근 가능)

➡ 계층 구조를 통한 완전한 보안 분리 효과

■ 4. 기존 보안그룹 수정하기

예를 들어 기본으로 있는 “Total-Security-group”을
WEB-Security-group으로 바꾸고 싶다면:

보안그룹 선택
인바운드 규칙 편집(Edit inbound rules)
필요 없는 Any 규칙 제거
최소화된 포트만 허용
저장(Save)

특히 Any IP(0.0.0.0/0) 또는 Any Port는
불가피한 경우 외에는 절대 최소화해야 한다.

■ 5. 글로벌 클라우드의 방화벽 개념 비교

클라우드	방화벽 이름
AWS	Security Group (SG)
Azure	Network Security Group (NSG)
GCP	Firewall Rules

모든 클라우드가 “방화벽을 자원 단위로 적용한다”는 점에서 구조는 동일하다.

■ 핵심 요약

SG = AWS 자원 단위 방화벽
인바운드/아웃바운드 규칙 설정
목적별로 SG를 분리해 적용 (WEB / WAS / DB 등)
Any 규칙 최소화
SG는 Stateful → 응답 트래픽 자동 허용
Azure(NSG), GCP(Firewall Rules)도 같은 개념

■ 네트워크 구간 암호화(TLS & PKI)

인터넷 환경에서 사용자 ↔ 클라우드 자원 간 통신은
항상 외부 공격자에게 노출될 위험이 있다.
이 위험을 줄이기 위해 사용하는 것이 바로 TLS(Transport Layer Security) 기반 암호화다.

TLS는 패킷 단위로 데이터를 암호화하여
외부·내부 구간에서 데이터를 안전하게 전송할 수 있도록 한다.

■ 1. TLS를 적용해야 하는 이유

✔ 데이터 도청(스니핑) 방지

네트워크 구간에서 공격자가 패킷을 가로채도
내용을 해석할 수 없도록 보호한다.

✔ 무결성 보장

전송 중 데이터가 위·변조되지 않았음을 보장한다.

✔ 서버·사용자 인증

서버가 진짜 서버인지(피싱/위조 방지)
사용자가 인증된 사용자임을 증명할 수 있다.

■ 2. TLS 구축에 필요한 것: PKI(Public Key Infrastructure)

TLS는 공개키 기반구조(PKI) 를 통해 인증서를 발급받아 작동한다.

TLS 인증서 구성 요소

공개키(서버가 공개적으로 제공)
개인키(서버 내부에만 저장)
인증서(CA가 발행)

서버 인증서를 통해
사용자는 “이 서버가 진짜인지” 확인할 수 있다.

■ 3. 인증서 발급 방법

✔ 무료 TLS 인증서

Let’s Encrypt 등 무료 CA
대부분 자동화 + 무료 발급
※ 단, 도메인이 실제 존재해야 하며,
정기적인 갱신 자동화 필요

✔ 클라우드 제공 인증서

클라우드에서는 별도로 인증서 발급 서비스를 제공한다:

AWS – ACM (Amazon Certificate Manager)
GCP – Certificate Manager
Azure – TLS/SSL Certificates

클라우드 내부 서비스와 연계되기 때문에
발급·적용이 매우 간편하다.

✔ 도메인 관리

클라우드 사용자라면
Route 53(AWS), Cloud DNS(GCP), Azure DNS 등을 사용해
도메인까지 함께 관리 가능

■ 4. TLS가 적용되는 대표 서비스들

TLS는 “서비스에 인증서를 적용하여 구간을 암호화하는 것”이며,
다음 환경에서 필수적으로 사용된다.

✔ 로드밸런서 (AWS ELB 등)

HTTPS Listener에 인증서를 적용
외부 → 로드밸런서 통신 암호화

✔ API Gateway

API 호출을 HTTPS로 보호
민감한 API 자원 보호

✔ 웹 서버 (EC2, 온프레미스 등)

Apache/Nginx에 SSL 인증서 적용
HTTPS 기반 서비스 제공

✔ 데이터 전송

클라이언트 ↔ 서버
마이크로서비스 ↔ 마이크로서비스
서버 ↔ 데이터베이스 트래픽(지원 환경에 따라)

■ 5. 핵심 정리

주제	설명
TLS	네트워크 구간 암호화 프로토콜
PKI	TLS 인증서를 발급·검증하는 구조
인증서 발급	무료/유료/클라우드 서비스(ACM 등)
적용 대상	로드밸런서, 웹 서버, API Gateway 등
목적	기밀성·무결성·인증 보장

■ 가상 사설 네트워크 (VPN: Virtual Private Network)

클라우드 환경에서
내부 네트워크 ↔ 외부 인터넷 ↔ 온프레미스(회사 내부망)
사이에 데이터가 전송되면, API 호출이나 암호화되지 않은 트래픽을 통해
중간 노출 위험이 생길 수 있다.

이 위험을 줄이기 위해
두 지점 사이의 네트워크 구간을 가상의 사설망(VPN)처럼 암호화하여
안전하게 통신하는 기술이 VPN이다.

■ 1. VPN이 필요한 이유

✔ 데이터 전송 구간 보호

중간자 공격(MITM), 패킷 도청, 트래픽 분석 등
외부 침입 가능성을 차단.

✔ 원격지·회사 내부·클라우드 간 연결

서로 다른 지리적 위치의 네트워크를
하나의 “사설망”처럼 연결할 수 있음.

✔ 사용자 및 서버 접속 보호

원격근무 사용자의 PC → 회사 네트워크
온프레미스 DB → AWS 서버
등의 트래픽을 안전하게 암호화.

■ 2. 클라우드에서의 VPN 구현 방식

온프레미스에서는
하드웨어 기반 장비(물리 방화벽, 전용 게이트웨이 등)를 사용하지만,

클라우드에서는 대부분 소프트웨어 기반 VPN 게이트웨이를 제공한다.

즉, 별도의 장비 없이
클라우드가 제공하는 VPN Gateway 자원과
내부망을 연결하는 방식이다.

✔ 클라우드 → 온프레미스 연결

AWS VPN Gateway ↔ 회사 내부 VPN 장비
암호화된 터널 생성
IPsec 기반 통신

✔ 클라우드 ↔ 클라우드(멀티 클라우드) 연결

AWS ↔ Azure
AWS ↔ GCP
VPN 터널을 통해 상호 사설망처럼 연결 가능

■ 3. AWS에서의 VPN 구성 방식

AWS는 VPN Connection 서비스를 제공하여
아래와 같은 구성을 매우 쉽게 만들 수 있다.

✔ 구성 요소

Virtual Private Gateway (VGW) – AWS 측 게이트웨이
Customer Gateway (CGW) – 사용자 네트워크(회사, 집, DC 등) 측 장비
VPN Connection – 두 게이트웨이를 연결하는 암호화 터널

✔ 기능

사용자의 내부 네트워크와 AWS 간 안전한 암호화 통신
트래픽 모니터링
암호화 규칙, 라우팅 설정
대역폭 관리
CloudWatch를 통한 상태 감시 가능

■ 4. VPN 사용 시 이점

✔ 외부 공격 차단

인터넷을 거치지만, 구간 전체가 암호화되므로 공격자 차단 가능.

✔ 내부망 확장

클라우드 리소스를 내부 네트워크처럼 사용할 수 있음.

✔ 네트워크 일관성

온프레미스, 사용자 PC, 클라우드가
하나의 사설망처럼 통신할 수 있어 운영이 단순해짐.

■ 핵심 요약

항목	내용
VPN 목적	구간 암호화 / 안전한 사설망 구축
클라우드에서의 VPN	소프트웨어 기반, 게이트웨이로 구성
AWS VPN 구성	VGW + CGW + VPN Connection
장점	암호화·보안 강화·네트워크 확장·트래픽 보호

■ IDS / IPS (침입 탐지/방지 시스템)

클라우드 환경에서도
악의적인 공격이나 침입 시도를 실시간으로 탐지하고 대응해야 한다.

✔ IDS (Intrusion Detection System)

침입 “탐지”
비정상 트래픽이나 의심 패턴을 감지
관리자에게 알림 전송
차단은 하지 않음

✔ IPS (Intrusion Prevention System)

침입 “차단”
악성 패킷을 실시간으로 자동 차단
방화벽보다 더 높은 수준의 패킷 분석 방어

■ IDS/IPS의 탐지 방식

✔ 1. 시그니처(Signature) 기반

알려진 공격 패턴 DB와 비교
전통적, 빠르지만 신종 공격 탐지 한계

✔ 2. 이상 행위(Anomaly) 기반

정상 트래픽 패턴과 비교하여 이상을 탐지
알려지지 않은 공격에도 대응 가능

✔ 3. 머신러닝 기반

AI로 트래픽 행동 분석
지속 학습으로 탐지 정밀도 향상
클라우드 환경에 특히 적합

■ IDS/IPS가 필요한 이유

외부 인터넷 구간은 항상 침입 위험 존재
API 호출, 웹 트래픽 등 서비스가 외부에 노출되어 있음
클라우드 내부도 사용자 설정 실수로 보안 사고 발생 가능
실시간 탐지·차단이 필수

■ DDoS(Distributed Denial of Service) 방지

DDoS 공격은
수천~수만 개의 공격자를 통해 서버에 트래픽을 집중시켜
서비스를 마비시키는 공격이다.

클라우드 서비스는 공개되어 있어
DDoS 공격 위험이 매우 높기 때문에
클라우드 전용 DDoS 방어 서비스가 필수다.

■ DDoS 방지 방식

비정상 트래픽 필터링
봇넷 IP 차단
트래픽 우회 처리
L3/L4/L7 계층 기반 공격 차단
정상 트래픽만 통과하도록 분석

■ AWS에서의 DDoS 방어: AWS Shield

AWS는 IDS/IPS와 별도로
AWS Shield라는 전용 DDoS 방어 서비스를 제공한다.

■ AWS Shield 유형

✔ 1) AWS Shield Standard

모든 AWS 서비스에 기본 제공
비용 없음
L3/L4 네트워크 공격 자동 방어
대부분의 일반적인 DDoS 공격 대응 가능

✔ 2) AWS Shield Advanced

고급 보호 기능
별도 비용
L7(애플리케이션 계층) 공격 방어
DDoS 대응 전문 지원팀(24/7)
공격시 비용 보호(Cost Protection)
대규모 트래픽 방어(엔터프라이즈급)

■ AWS Shield 사용법

AWS 콘솔에서 Shield 검색
서비스 진입
기본은 Shield Standard 자동 적용
고급 보호가 필요하면 Activate Shield Advanced 선택
CloudFront, ELB, Route53 등과 연계하여 보호 강화

■ 글로벌 클라우드 비교

클라우드	DDoS 방어 서비스
AWS	AWS Shield
Azure	DDoS Protection
GCP	Cloud Armor

대부분의 클라우드가 DDoS 전용 보안 서비스를 제공하여
네트워크 계층(L3~L7)을 보호한다.

■ 핵심 요약

구분	설명
IDS	침입 탐지 (알림)
IPS	침입 차단 (실시간 방어)
DDoS	서비스 마비 공격
AWS Shield Standard	자동 제공, L3/L4 보호
AWS Shield Advanced	고급 보호, 비용 발생, L7 방어

■ 클라우드 서비스 자원 간 내부 게이트웨이(Inner Gateway)

클라우드 환경에서는
다양한 서비스와 멀티 클라우드 구성 전략에 따라
특정 자원을 외부(인터넷)로 노출하지 않고 내부에서만 안전하게 통신해야 하는 경우가 많다.

예:

내부 DB ↔ EC2 통신
내부 스토리지(S3, Blob 등) ↔ 애플리케이션
클라우드 서비스 간 비공개 통신
민감한 데이터 자원 등

이때 공용 IP로 통신하면
평문 노출, 위변조, 데이터 유출 위험이 생기므로
클라우드에서는 내부 게이트웨이(Inner Gateway) 를 사용해
사설망 기반·암호화 통신 기반으로 보호한다.

■ 내부 게이트웨이의 목적

✔ 1) 자원 노출 최소화

외부 인터넷을 거치지 않아
공격 표면(Attack Surface)이 줄어든다.

✔ 2) 사설망(Private Network)에서만 접근

특정 계정(IAM)만 접근 가능
사설 IP 전용
외부 사용자는 절대 접근 불가

✔ 3) 성능 최적화

인터넷을 거치지 않아
지연 시간 감소 + 안정적인 전송 가능

✔ 4) 데이터 보호

특히 스토리지·데이터베이스처럼
기밀성이 높은 자원은 내부 게이트웨이를 통한 사설 전용 통신이 이상적

■ 대표적인 내부 게이트웨이 구성 방식

클라우드마다 이름은 다르지만
의미는 동일하다: “자원 간 사설 전용 연결”

클라우드	내부 게이트웨이 이름
AWS	VPC Endpoint (PrivateLink 기반)
Azure	Service Endpoints / Private Link
GCP	Private Google Access

이 서비스들을 사용하면
인터넷 없이, 완전한 사설망 통신을 구성할 수 있다.

■ AWS에서 내부 게이트웨이 사용하기 (VPC Endpoint)

AWS에서는 VPC Endpoint를 사용하여
EC2 ↔ S3, EC2 ↔ DynamoDB 등
AWS 리소스 간 사설 통신을 할 수 있다.

✔ VPC Endpoint 종류

종류	특징
Interface Endpoint	PrivateLink 기반, ENI 생성, 대부분의 AWS 서비스에 사용
Gateway Endpoint	S3 / DynamoDB 전용, 라우팅 테이블에 추가

■ AWS VPC Endpoint 생성 절차

VPC 메뉴 → Endpoints 선택
Create Endpoint 클릭
내부 통신이 필요한 AWS 서비스 선택
(예: com.amazonaws.ap-northeast-2.s3)
연결할 VPC 선택
Private DNS 옵션 활성화
서브넷·보안그룹 선택
엔드포인트 생성

→ 이렇게 생성된 Endpoint를 통해
인터넷을 전혀 거치지 않고 완전 사설망 기반으로 S3/DynamoDB와 통신 가능

■ 내부 게이트웨이를 사용하면 얻는 보안 효과

✔ 인터넷 노출 0

외부 IP 없이 내부 IP로만 통신 → 공격 표면 최소화

✔ 보안 정책 강화

서비스별 IAM 정책으로 권한을 최소화 가능

✔ 데이터 기밀성 향상

암호화된 사설망
외부 경유 없이 직접 전송
민감 정보 보호에 최적화

✔ 민감 자원의 안전한 접근

스토리지, DB, 메시징 서비스 등
보안상 인터넷 사용이 위험한 자원에서 매우 효과적

■ 핵심 요약

항목	설명
내부 게이트웨이	클라우드 자원 간 사설 전용 통신 제공
목적	인터넷 노출 제거, 보안 강화
AWS	VPC Endpoint(PrivateLink 기반)
Azure	Service Endpoint / Private Link
GCP	Private Google Access
장점	빠르고 안전한 내부망 연결, 계정 기반 접근 통제

■ 웹 방화벽 (WAF: Web Application Firewall)

WAF는 웹 애플리케이션으로 전달되는 요청이 정상인지 판단하고
애플리케이션 취약점을 노린 공격을 차단하는 보안 장치다.

일반 방화벽이 OSI 3~4계층(IP·포트 기반)을 통제하는 것과 달리
WAF는 OSI 7계층(L7)에서 작동하여
웹 요청의 패턴·내용·파라미터·헤더 등을 분석한다.

■ WAF가 필요한 이유

웹 서비스는 누구나 접근할 수 있는 구조이므로,
다음과 같은 공격에 직접 노출된다:

SQL Injection
XSS(교차 스크립팅)
CSRF
파일 업로드 공격
인증 우회
인가 취약점 공격
봇/스크래퍼 공격
DDoS L7(HTTP Flood) 공격

기존 L3/L4 방화벽으로는 애플리케이션 공격을 차단할 수 없기 때문에
반드시 WAF를 사용해야 한다.

■ WAF의 주요 기능

✔ 1) 입력값 필터링

악의적 스크립트
특수문자 기반 공격
비정상 패턴 탐지

✔ 2) 정책 기반 필터링

IP 차단/허용
HTTP 메서드 제한
특정 지역/국가 차단
URI 접근 제어

✔ 3) 취약점 공격 방어

SQLi, XSS, RFI, LFI 등 자동 탐지 및 차단

✔ 4) DDoS L7 공격 완화

WAF는 AutoScale, Shield, CDN 등과 함께 사용하면 효과가 크다.

✔ 5) 로그 기반 알림

공격 발생 기록
비정상 요청 분석
트래픽 패턴 모니터링

■ WAF 적용 vs 기존 온프레미스 방식

과거 온프레미스에서는 WAF가 두 종류로 나뉘었다:

구분	설명
NID (Network-based)	네트워크 단에서 하드웨어 장비로 동작
HID (Host-based)	서버 내부에 에이전트 설치 후 운영

그러나 클라우드 환경에서는 다음 이유로
네트워크 기반(L7) WAF가 주로 사용된다:

가상 서버(VPC) 환경에서는 하드웨어 장비 사용 불가
설정 변경이 잦아 소프트웨어 기반이 더 유연
AutoScale 등과 연계해야 함
CDN / 로드밸런서와 결합 용이

👉 결론: 클라우드에서는 WAF를 로드밸런서 또는 프록시 앞단(VPC 외부)에서 운영하는 것이 일반적

■ WAF 작동 방식

사용자가 웹 서비스 요청을 보냄
요청이 로드밸런서/프록시를 통해 WAF로 전달
WAF가 요청 헤더/바디/패턴 분석
정상 또는 악성으로 판정
악성일 경우 즉시 차단
정상 요청만 애플리케이션으로 전달

즉,
WAF는 VPC 외부에서 들어오는 HTTP/HTTPS 요청의 내용을 분석해 차단하는 역할을 수행한다.

■ 글로벌 클라우드의 WAF 서비스

클라우드	WAF 이름
AWS	AWS WAF
Azure	Azure WAF
GCP	Cloud Armor (L7 보안 포함)

모든 클라우드에서 공통적으로
L7 공격 방어를 위한 WAF 기능을 제공한다.

■ 핵심 요약

항목	설명
WAF	L7 웹 공격을 탐지·차단
필요 이유	SQLi/XSS 등 애플리케이션 취약점 방어
적용 위치	로드밸런서·프록시 앞단
클라우드 특징	소프트웨어 기반, AutoScale 연계 용이
글로벌 서비스	AWS WAF, Azure WAF, GCP Cloud Armor

■ API Gateway로 API 보안하기

API는
웹·모바일·백엔드 애플리케이션 간 데이터를 교환하도록 연결하는 핵심 요소다.
따라서 API가 노출되면 내부 자원 전체가 공격받을 수 있기 때문에
API 보안은 필수적이다.

API Gateway는
API 요청을 받아 인증·라우팅·제한(Metering)·로깅·보안 정책 처리를 수행하는
클라우드 전용 보안·관리 서비스이다.

■ API Gateway의 역할

✔ 1) 인증(Authentication)

API를 호출하는 사용자가 인증된 사용자/클라이언트인지 확인
OAuth2, JWT, Cognito, IAM 정책 등과 연계 가능
인증 실패 시 API 접근 차단

✔ 2) 권한(Authorization)

인증된 사용자라도, 서비스별/리소스별 접근 권한 확인
예: 관리자 전용 API / 일반 사용자 전용 API 구분

✔ 3) 라우팅(Routing)

API 요청 경로에 따라
→ 특정 Lambda
→ 특정 EC2
→ 특정 백엔드 서비스
로 전달

✔ 4) 트래픽 제어(Throttling & Rate Limiting)

동시 요청 폭주(DDoS L7 포함)를 막기 위해
초당 호출 수 제한(SL API 보호)
각 사용자별 호출량 제한 가능

✔ 5) 조정(Mediation)

요청/응답 메시지 변환(JSON ↔ XML)
헤더 추가/삭제
파라미터 조정
백엔드 서비스 형태에 맞춰 형태 변환

✔ 6) 로깅(Logging)

API 호출 이력
에러·성공 로그 수집
CloudWatch / Stackdriver 등으로 모니터링

✔ 7) 미터링(Metering)

사용량 패턴 분석
유료 API라면 과금 데이터 생성
SLA 통계에 활용

■ API Gateway를 사용해야 하는 이유

✔ API는 내부 자원으로 직접 연결되는 “관문”

공격자가 API를 악용하면
→ 인증을 우회하거나
→ 권한이 없는 기능을 호출하거나
→ 대량 트래픽을 넣어 서비스 중단시키는 공격 수행 가능

✔ API Gateway는 보안 필터링 + 속도제한 + 인증 + 로깅까지 통합 제공

그래서 클라우드 보안 관점에서 API Gateway는 필수 구성 요소이다.

■ AWS에서 API Gateway 사용하기 (실습 흐름)

AWS Console → API Gateway 검색
HTTP / WebSocket / REST API 중 하나 선택
API 이름 입력
URL 엔드포인트 경로 생성
백엔드 서비스(Lambda, EC2 등) 연결
인증 방식 선택(IAM, Cognito, JWT 등)
스테이지(Stage) 생성
API 배포(Deploy)

이후 CloudWatch와 연동해
로그, 메트릭, 오류, 호출 수 등을 지속적으로 모니터링할 수 있다.

■ 글로벌 클라우드의 API Gateway 비교

클라우드	API Gateway 이름
AWS	Amazon API Gateway
Azure	Azure API Management
GCP	Apigee API Gateway

모두 API 인증·보안·트래픽 제어·라우팅을 제공하는 공통 기능을 수행한다.

■ 핵심 요약

항목	설명
API Gateway	API 요청을 제어·인증·라우팅하는 보안 게이트웨이
필요성	API는 내부 자원과 직결 → 보안의 핵심
주요 기능	인증, 권한, 라우팅, 변환, 모니터링, 로깅, 미터링
AWS 서비스	Amazon API Gateway
보호 효과	API 기반 공격·대량 요청·권한 우회 방지

🔍 Inspector를 사용한 보안 검사

WAF와 API 보호 서비스만으로는 부족하며,
클라우드 환경에서는 어플리케이션 자체의 취약점을 제거하는 서비스가 필요하다.
이를 위해 웹 스캐너(Web Scanner)와 소스 코드 점검(Code Scanning) 솔루션을 활용한다.

📌 웹 스캐너 서비스

웹 스캐너는 어플리케이션 사용자에게 제공되는 웹 사이트에서 발생 가능한 취약점을 자동 점검하는 솔루션이다.

웹 서버나 WAS 서버가 가진 취약점, OWASP TOP 10에 해당하는

SQL Injection
Command Injection
Path Traversal
서버 정보 노출
등의 다양한 공격 시도와 구조적 취약점을 탐지한다.

👉 클라우드형 웹 스캐너는 에이전트 설치 없이
클라우드 자원의 정보를 수집하고 자동으로 패킷을 분석해 취약점을 찾는다.

※ 자체 리소스로 운영할 필요 없이 SaaS 형태로 바로 사용 가능

📌 시큐어 코딩 서비스

시큐어 코딩 점검은 개발 단계 또는 완료 후 소스 코드의 보안 취약점을 점검하는 방식이다.
온프레미스나 클라우드 모두 동일하게 사용 가능하며, 개발자가 작성한 코드 내에서
취약한 함수 사용, 보안 설정 누락 등 문제점을 자동으로 분석한다.

✔ 주요 특징

개발자의 코드 품질 향상을 위한 자동 점검
운영 환경과 관계없이 소스코드 기반 분석
DevOps 환경과 CI/CD 파이프라인에 쉽게 결합 가능
코드 기반 보안 취약점 → 사전에 제거하는 효과

👉 온프레미스 대비 클라우드에서는 자동화·AOS 연결이 훨씬 용이해
보안 프로세스를 전체 개발 주기에 자연스럽게 녹일 수 있다.

🔒 AWS에서 Inspector 사용하기

Amazon Inspector 서비스에 접속하여
가운데 "Start" 버튼을 클릭하면 보안 평가를 시작할 수 있다.
Inspector는 다음 항목을 자동 평가한다:

네트워크 측면의 보안 평가
호스트 측면의 보안 평가
소프트웨어 취약점 점검
Run Once 평가 / Run Weekly 평가 선택 가능

평가가 완료되면 대시보드 색상 지표와 숫자로 결과를 확인할 수 있다.

🔑 키 관리 서비스 (KMS: Key Management Service)

클라우드 환경에서 서버나 디스크 내부 데이터를 암호화하려면
암호화 키가 필요한데, 온프레미스 환경에서는 사용자가 직접 키를 생성하지만
클라우드에서는 키 발급, 저장, 관리, 보안 위험 대응까지 KMS가 전담한다.

✔ KMS 주요 기능

암호화 키 자동 생성
생성된 키를 안전한 HSM(Hardware Security Module)에 저장
복호화 요청 시 키 관리 서버에서 키를 불러와 복호화 처리
사용자가 직접 키에 접근하지 않아도 되는 구조
접근 정책(관리자·사용자·서비스) 기반의 권한 제어
로테이션(주기적 키 변경) 기능 지원

✔ KMS 사용 흐름 요약

데이터를 암호화하면 암호화 키는 서버·스토리지에 저장
복호화 요청 시 KMS가 내부적으로 해당 키를 불러와 처리
사용자는 실제 키를 볼 필요 없이 KMS 호출만으로 암복호화 가능
키 분실 위험, 보안 위험을 최소화

👉 온프레미스와 달리 키를 사람이 직접 보관하지 않아서 오용 위험이 줄어듦

🔐 AWS에서 키 관리 서비스(KMS) 사용하기

AWS에서는 KMS 서비스에서 다음과 같은 키 관리를 수행할 수 있다:

1) 키 생성

콘솔에서 Create Key 선택
대칭키 / 비대칭키 선택
태그 추가
용도 지정

2) 키 사용 권한 설정

Key Policy 설정
IAM 사용자, 서비스에 대한 사용 권한 부여

3) 암호화 작업

aws kms encrypt 명령으로 데이터 암호화
EBS, S3, RDS 등 다양한 AWS 서비스에서 기본 지원
서비스 내부에서 암호화 옵션을 선택하면 KMS 자동 호출

4) 키 로테이션

일정 주기로 키 자동 교체
기존 키는 유지하면서 새 키로 암호화·복호화 처리

🌎 글로벌 CSP의 KMS 명칭

클라우드	키 관리 서비스
AWS	AWS KMS (Key Management Service)
Azure	Azure Key Vault
GCP	Cloud Key Management Service

☁️ CASB(Cloud Access Security Broker) 개요

클라우드 서비스의 활용성이 커질수록
보안 담당자가 관리해야 할 영역은 넓어지고 통제는 더 어려워진다.

특히 멀티·하이브리드 클라우드 환경에서는
클라우드 서비스 제공자별로 보안정책이 모두 다르고,
내부 사용자들이 사용하는 SaaS 앱, 개인용 IT 기기 등을 통해
데이터 유출 및 비인가 접근을 탐지하기가 훨씬 복잡해진다.

이때 클라우드 자원 전체에 대해
파일, 설정, 라이브러리, 패키지, 데이터, 애플리케이션 소스까지
높은 수준의 통합 보안을 제공하는 솔루션이 바로 CASB이다.

🔐 CASB란?

CASB(Cloud Access Security Broker)는
클라우드 사용자와 클라우드 서비스 제공자 사이에서
보안 정책을 강제하고 안전한 연결을 보장하는 중앙 통제 보안 게이트웨이다.

📌 CASB가 제공하는 주요 기능

데이터 암호화 / 인증 / 접근 통제
사용자 행동 분석(U.E.B.A)
웹·앱 트래픽 필터링
ID 관리·SSO 연동
개인정보보호 및 규제 준수 관리(GDPR, ISO 등)
위협 기반(Threat-based) 탐지
적응형 인증(Adaptive Authentication)
위험 대시보드(Risk Summary Dashboard) 제공

CASB를 적용하면
사용자가 클라우드에 접근하기 전·후 모든 활동을 모니터링하고
데이터 침해나 비정상 행위를 실시간으로 차단할 수 있다.

🔎 CASB의 세 가지 구성 방식

CASB는 클라우드 자원의 데이터 보호, 위협 탐지, 보안 정책 통합, 컴플라이언스, 가시성 등을 제공하며
클라우드 종류와 상관없이 일관된 보안 정책 적용이 가능한 것이 큰 장점이다.

CASB는 다음 3가지 방식(API형 / Forward Proxy형 / Reverse Proxy형)으로 구성된다.

1) 🔵 API형 (API Mode)

소프트웨어 형태로 제공되며,
사용자의 클라우드 계정과 별도로 존재하는 CASB가 API를 통해 클라우드 서비스의 데이터를 검사하는 방식이다.

✔ 특징

서비스용 앱에 라이브러리 형태로 CASB 소프트웨어 추가
클라우드 자원에 대한 로그 기반 분석 수행
API 호출이 실시간이 아니므로 보안 위협 탐지는 약간 지연됨
주로 사후 분석 / 감사 목적으로 사용
설정이 간단하고 사용 편의성이 높음

👉 장점: 설치가 매우 쉬움
👉 단점: 실시간 위협 탐지 어려움, 사용자 행위 분석 지연

2) 🟡 Forward Proxy형

사용자가 클라우드 자원에 접근하기 전에
CASB를 거쳐가는 방식이다.
WAF의 인라인 방식처럼 사용자 → CASB → 클라우드로 트래픽이 흐른다.

✔ 특징

사용자의 모든 클라우드 요청을 CASB가 먼저 처리
일원화된 보안정책 적용 가능
사용자가 인증하기 전에도 정책 적용 가능
실시간 위협 탐지 가능
사전에 Shadow IT(무단 사용 앱) 차단 가능
기업 단위에서 가장 많이 쓰이는 방식

👉 장점: 실시간 보안 탐지, 강력한 정책 적용
👉 단점: proxy 차단 문제 발생 가능, 외부 네트워크에서 우회 발생 가능

3) 🟢 Reverse Proxy형

사용자의 클라우드 서비스 요청을
CASB의 Reverse Proxy 주소를 통해 우회 시켜 처리하는 방식이다.

✔ 특징

사용자가 인증을 위해 CASB 페이지로 유도됨
인증 후 CASB가 클라우드 자원에 접근
실시간 보안 탐지 가능
SSO(Single Sign-On)와 연동이 쉬움
외부 또는 모바일 사용자 환경에서 자주 사용

👉 장점: 인증 기반 접근 제어에 강함
👉 단점: 모든 서비스가 Reverse Proxy를 지원하는 것은 아님

✔ 요약 비교

방식	실시간 탐지	설치 난이도	사용할 때 특징
API형	△ (지연 있음)	매우 쉬움	사후 분석·데이터 감사 목적
Forward Proxy형	◎	중간	강력한 정책 적용, Shadow IT 차단
Reverse Proxy형	◎	중간~높음	인증 기반 통제에 최적화

열공하는웅2

훌륭한 it 엔지니어 꿈나무

이전 포스트