클라우드 보안 (Cloud Security)

클라우드 보안을 왜 묻는가

백엔드 면접에서 클라우드 보안은 “보안팀이 따로 본다”는 식으로 넘길 수 있는 주제가 아닙니다.

보통 다음 질문으로 이어집니다.

누가 어떤 리소스에 접근할 수 있는가
민감한 값은 어디에 두고 어떻게 회전시키는가
내부망과 외부망은 어떻게 나누는가
잘못된 권한 변경이나 이상 접근을 어떻게 발견하는가

즉, 이 문서의 핵심은
클라우드 운영에서 보안을 별도 기능이 아니라 기본 제약 조건으로 설계할 수 있는가입니다.

인프라 변경 관리 관점은 IaC (Infrastructure as Code),
플랫폼 운영 관점은 Kubernetes, 서버리스 (Serverless) 문서와 같이 보면 좋습니다.

클라우드 보안이란

클라우드 보안은 단순히 방화벽 하나를 두는 문제가 아닙니다.

보통 다음 층을 같이 봅니다.

신원과 권한: 누가 무엇을 할 수 있는가
비밀 관리: 키, 토큰, 비밀번호를 어떻게 보호하는가
네트워크 격리: 어떤 경로로 어떤 트래픽이 오갈 수 있는가
암호화: 저장 시, 전송 시 데이터를 어떻게 보호하는가
감사 가능성: 누가 무엇을 바꿨는지 추적할 수 있는가

좋은 답변은 “보안을 강화합니다”보다
권한, 비밀, 네트워크, 암호화, 감사 로그를 각각 어떤 장치로 다루는지를 설명하는 편이 좋습니다.

IAM 최소 권한

클라우드 보안에서 가장 기본적인 원칙은 최소 권한(Least Privilege) 입니다.

의미는 단순합니다.

꼭 필요한 리소스만
꼭 필요한 동작만
꼭 필요한 시간 동안만 허용하는 방식입니다.

예를 들어:

배치 작업은 S3 읽기만 필요한데 전체 관리자 권한을 주지 않음
운영자가 RDS 조회만 하면 되는 상황에서 삭제 권한까지 주지 않음
CI 파이프라인이 특정 레지스트리와 배포 대상만 접근하도록 제한

최소 권한의 장점은 분명합니다.

권한 오남용 범위 축소
자격 증명 유출 시 피해 범위 제한
실수로 인한 대형 사고 확률 감소

하지만 비용도 있습니다.

권한 설계와 유지보수가 귀찮아짐
초기에는 권한 부족 오류가 자주 날 수 있음
팀이 무심코 admin 권한으로 우회하고 싶어질 수 있음

그래서 좋은 운영은 “권한을 빡세게 준다”가 아니라
권한을 좁게 주되, 왜 필요한지와 변경 절차를 같이 관리한다는 방향입니다.

User, Role, Service Account 감각

면접에서는 이 구분을 아는지 자주 봅니다.

대상	주 용도	주의점
User	사람 계정	장기 액세스 키 남용 주의
Role	임시 권한 위임	누가 assume하는지 경계 설정 필요
Service Account	애플리케이션/워크로드 신원	워크로드 단위 권한 분리 필요

User

사람이 콘솔이나 CLI에 접근할 때 쓰는 신원입니다.

가능하면 장기 액세스 키보다 SSO / 임시 인증을 선호하는 편이 안전합니다.
공용 계정 공유는 피하는 편이 좋습니다.

Role

사람이나 서비스가 필요한 순간에만 임시로 권한을 위임받는 개념입니다.

AWS IAM Role
GCP Service Account impersonation

운영에서는 role 기반 접근이 더 자연스럽습니다.

Service Account

애플리케이션이나 워크로드가 쓰는 신원입니다.

Kubernetes ServiceAccount
클라우드 런타임용 워크로드 아이덴티티

좋은 답변은 “애플리케이션에도 계정이 있습니다”보다
사람 신원과 워크로드 신원을 분리하고, 둘의 권한 범위를 다르게 관리한다고 설명하는 편이 좋습니다.

Secret 관리와 Rotation

비밀정보(secret)는 코드, 이미지, 로그, 평문 설정 파일에 남기지 않는 것이 기본입니다.

대표 예시는 다음과 같습니다.

DB 비밀번호
API 토큰
인증서
암호화 키

좋은 운영 패턴은 이렇습니다.

secret manager에 저장
애플리케이션은 런타임에 주입받아 사용
접근 권한을 workload 단위로 제한
rotation 주기와 절차를 준비

관련 IaC 경계는 IaC (Infrastructure as Code) 문서와 직접 연결됩니다.

자주 하는 실수

.env 파일을 그대로 커밋
컨테이너 이미지 안에 비밀번호를 bake-in
로그에 토큰이나 connection string 출력
만료 없는 장기 키를 계속 사용

Rotation

rotation은 단순히 키를 바꾸는 것이 아니라,
새 키 배포 → 구 키 제거 → 연결 검증의 절차를 운영 가능한 형태로 만드는 것입니다.

좋은 답변은 “secret manager를 씁니다”에서 멈추지 않고,
누가 읽을 수 있고, 언제 바꾸고, 실패하면 어떻게 되돌릴지까지 말하는 편이 좋습니다.

CI/CD 파이프라인 안의 secret scanning 감각은 배포 전략과 CI/CD (Deployment Strategies and CI/CD) 와도 연결됩니다.

네트워크 격리

클라우드 보안에서는 네트워크 경계를 어떻게 나누는지도 중요합니다.

보통 다음 개념을 묶어서 설명합니다.

public subnet / private subnet
ingress / egress
security group / firewall rule / NACL
bastion, VPN, private endpoint

핵심은 외부에 노출할 것과 내부에만 둘 것을 먼저 분리하는 것입니다.

예를 들어:

ALB / API Gateway만 public
애플리케이션 서버와 DB는 private subnet
DB는 애플리케이션 보안 그룹에서만 접근 허용

좋은 점:

불필요한 노출 면이 줄어듦
리소스별 허용 경로를 명확히 할 수 있음

주의점:

너무 넓은 egress 허용은 데이터 유출 경로가 될 수 있음
0.0.0.0/0 인바운드 개방은 운영 실수의 대표 사례임
내부망이라도 무조건 신뢰하지 않고 세밀한 허용 규칙이 필요함

즉, 네트워크 보안은 “막는다”보다
어떤 트래픽만 통과시킬지 명시하는 문제입니다.

저장/전송 구간 암호화

암호화는 크게 두 축으로 설명하면 좋습니다.

구간	대표 수단	주 목적
저장 시 암호화	디스크/볼륨 암호화, DB 암호화, KMS	저장 매체 유출 대비
전송 시 암호화	TLS, mTLS, HTTPS	네트워크 구간 도청/변조 방지

저장 시 암호화

S3, EBS, RDS 같은 관리형 서비스 암호화 옵션
KMS 기반 키 관리
백업 스냅샷 암호화

전송 시 암호화

외부 공개 API는 HTTPS 기본
내부 서비스 간에도 필요한 경우 TLS / mTLS 검토
DB 연결도 TLS 사용 여부 확인

좋은 답변은 “암호화합니다”보다
어떤 데이터를 어떤 구간에서 어떤 키 체계로 보호하는가를 말하는 편이 더 좋습니다.

감사 로그와 권한 변경 추적

보안은 막는 것만으로 끝나지 않고,
누가 무엇을 했는지 나중에 추적할 수 있어야 합니다.

대표 항목은 다음과 같습니다.

IAM 정책 변경
보안 그룹 규칙 변경
secret 접근 이력
관리자 권한 상승
데이터 export / snapshot 생성

감사 로그가 중요한 이유:

사고 원인 추적
내부 오남용 탐지
규제 / 감사 대응

좋은 운영은 보통 다음을 같이 둡니다.

audit log 중앙 수집
권한 변경 알림
고위험 행동 탐지 규칙
로그 보존 정책

관측성과 운영 경보 감각은 로깅 및 모니터링 (Logging & Monitoring) 문서와도 연결됩니다.

실무에서 자주 나는 사고 패턴

면접에서는 실제로 어떤 실수를 경계하는지도 자주 묻습니다.

과도한 권한: 개발 편의를 위해 admin 권한을 그대로 부여
장기 키 방치: 퇴사자 키, 오래된 액세스 키 미정리
잘못된 네트워크 개방: DB, Redis, 관리 포트를 public으로 노출
secret 노출: 코드 저장소, 이미지, 로그에 비밀정보 남김
감사 부재: 누가 권한을 바꿨는지 나중에 추적 불가
암호화 경계 누락: 백업이나 내부 통신은 괜찮다고 가정하고 방치

좋은 답변은 “보안 사고를 막는다”보다
사람 실수와 자동화 오류를 전제로, 피해 범위와 탐지 시간을 줄이는 장치를 둔다는 흐름이 좋습니다.

면접 포인트

클라우드 보안의 핵심은 권한, 비밀, 네트워크, 암호화, 감사 로그를 각각 운영 가능한 방식으로 설계하는 것입니다.
IAM 최소 권한은 보안 원칙이면서도 운영 비용이 따르는 선택이라, 변경 절차와 함께 설명하는 편이 좋습니다.
사람 계정과 워크로드 신원은 분리하고, role/service account 중심으로 말하면 답변이 실무적으로 들립니다.
secret manager와 rotation, public/private 분리, 감사 로그 추적은 기본 운영 포인트입니다.
좋은 답변은 해킹 방지보다 실수·권한 남용·유출 시 피해 범위 제한과 탐지 가능성을 같이 설명합니다.