✍️ 필사 모드: 보안 완전 가이드 — Zero Trust·Secret·OAuth·OIDC·Supply Chain·AI 보안 (Season 2 Ep 10, 2025)
한국어들어가며 — 왜 모든 엔지니어가 보안을 알아야 하는가
보안이 "보안 팀만의 일"이라는 착각이 뚫린 이유:
- 보안 팀 1명 : 엔지니어 100명 → 제때 검토 불가
- Shift-Left: 개발 초기부터 보안 고려하지 않으면 늦음
- Supply Chain 공격: 우리가 쓰는 오픈소스가 통로
- Cloud·K8s 오설정: 보안 팀이 막을 곳이 수백 곳
- AI 시대의 새 공격면: Prompt Injection, Data Poisoning, Model Theft
2025년 시니어 엔지니어에게 보안은 "교양"이 아니라 "실무".
이 글은 보안 전문가가 아닌 엔지니어가 알아야 할 것만 담는다.
1부 — Zero Trust 아키텍처
1.1 전통 vs Zero Trust
전통 (성곽 모델): 네트워크 경계 방어. 안에 들어오면 신뢰. Zero Trust: "Never trust, always verify." 네트워크 위치 무관, 모든 요청 검증.
1.2 Zero Trust 5원칙 (NIST 800-207)
- 모든 리소스를 "자원"으로 취급
- 모든 통신 보안 (네트워크 위치 무관)
- 접근은 세션별 승인 (영구 ❌)
- 접근 결정은 동적 정책 (ID·기기·위치·시간·행동)
- 자산·통신 계속 모니터링
1.3 실전 구현 요소
- Identity-aware Proxy: Google BeyondCorp, Cloudflare Access
- SASE/SSE: Zscaler, Netskope
- Service Mesh + mTLS: Istio, Linkerd
- Fine-grained ACL: OPA (Open Policy Agent), SpiceDB
- PAM (Privileged Access Management): HashiCorp Boundary, Teleport
1.4 VPN의 종말 (2020~)
COVID 이후 "회사 네트워크" 개념 해체. VPN = 한 번 뚫리면 전체 접근 = 적합도 ↓.
교체: Zero Trust + SSO + MFA + 기기 증명 (Device Trust).
2부 — 인증·인가: OAuth 2.1·OIDC
2.1 개념 정리
- Authentication (AuthN): "누구인가?"
- Authorization (AuthZ): "무엇을 할 수 있는가?"
- OAuth 2.0: AuthZ 프로토콜 (API 접근)
- OIDC (OpenID Connect): OAuth 위에 AuthN 표준
- SAML: 엔터프라이즈 SSO 표준 (구세대)
2.2 OAuth 2.1 (2024 초안)
OAuth 2.0의 "권장 사항"을 의무화한 버전:
- Implicit Flow 제거 (위험)
- Resource Owner Password Credentials Flow 제거
- PKCE 필수 (모든 Flow)
- Refresh Token Rotation 의무화
2.3 Authorization Code Flow + PKCE (2025 표준)
1. Client → AuthServer: /authorize + code_challenge
2. User 로그인·동의
3. AuthServer → Client: auth_code
4. Client → AuthServer: /token + code + code_verifier
5. AuthServer: code_challenge == hash(code_verifier)? → access_token + id_token
PKCE (Proof Key for Code Exchange): Authorization Code 탈취 방어. 공개 클라이언트(SPA, 모바일)에 필수.
2.4 OIDC id_token (JWT)
{
"iss": "https://auth.example.com",
"sub": "user_12345",
"aud": "client_abcdef",
"exp": 1735689600,
"iat": 1735686000,
"email": "alice@example.com",
"email_verified": true
}
- iss: 발급자
- sub: 사용자 ID (고유)
- aud: 의도된 수신자 (client_id)
- exp/iat: 만료·발급
- 검증: 서명 + iss + aud + exp
2.5 액세스 토큰 저장
| 위치 | 장단점 |
|---|---|
| Cookie (HttpOnly, Secure, SameSite) | XSS 방어 ✅, CSRF 주의 |
| LocalStorage | XSS 취약 ❌ |
| Memory | 새로고침 시 소실, 안전 |
| BFF 패턴 | 서버가 토큰 보관, 브라우저엔 세션 쿠키 |
2025 권장: BFF (Backend-for-Frontend) + HttpOnly Cookie. SPA에서 토큰 노출 최소.
2.6 Refresh Token Rotation
Refresh Token을 한 번 사용 → 새 토큰 + 기존 Refresh 무효화. 탈취 감지 가능.
3부 — Secret 관리
3.1 절대 하면 안 되는 것
- Git에 .env 커밋 (GitHub secret scanner 활성화 필수)
- Dockerfile에 Secret 하드코딩
- 로그에 Secret 출력
- Slack·Jira에 Secret 붙여넣기
3.2 Secret 관리 레벨
Level 1: .env + .gitignore (단독 개발) Level 2: .env + dotenv-vault / Doppler (팀) Level 3: Vault / AWS Secrets Manager / GCP Secret Manager (프로덕션) Level 4: Vault + 짧은 TTL 동적 Secret + 회전 자동화
3.3 HashiCorp Vault
# 저장
vault kv put secret/myapp/db password=super-secret
# 조회 (런타임)
vault kv get -field=password secret/myapp/db
# 동적 Secret (DB)
vault write database/config/postgres ...
vault read database/creds/my-role
# → 임시 DB 계정 (TTL 1시간)
강점: 동적 Secret, TTL, 감사 로그.
3.4 SOPS (Secrets OPerationS)
Mozilla가 만든 파일 암호화 도구. Git에 암호화된 Secret을 커밋 가능.
sops -e -i secrets.yaml # 암호화
# 파일 커밋
sops -d secrets.yaml # 복호화
장점: GitOps 친화. 단점: 키 관리가 별도.
3.5 Kubernetes Secret은 Secret이 아니다
- etcd에 Base64로 저장 (평문 ≠ 암호화)
- 해결: SealedSecrets, External Secrets Operator, SOPS + Flux
3.6 AWS KMS / GCP KMS / Azure Key Vault
- 클라우드 환경에선 KMS가 root key 관리
- IAM 연동으로 세밀한 접근 제어
- HSM 하드웨어 지원 옵션
4부 — Supply Chain 보안
4.1 2020~2024 주요 공격 사례
- SolarWinds (2020): 빌드 시스템 침투 → 18,000 조직 영향
- Log4Shell (2021): Log4j 취약점, 수백만 서버
- ua-parser-js (2021): npm 패키지 피싱
- PyTorch (2023): 공식 패키지 악성 코드 잠복
- XZ Utils (2024): 2년 걸쳐 백도어 심음 (발견됨)
4.2 SBOM (Software Bill of Materials)
"소프트웨어의 성분표" — 모든 의존성·버전·라이선스 나열.
표준:
- SPDX (Linux Foundation)
- CycloneDX (OWASP)
생성 도구:
- Syft (Anchore)
- Trivy
- Snyk
- cargo-auditable (Rust)
- cyclonedx-npm / cyclonedx-bom-python
2024 법규: 미국 CISA·EU CRA에서 SBOM 의무화 움직임.
4.3 SLSA (Supply-chain Levels for Software Artifacts)
Google 주도 프레임워크. 빌드 파이프라인 무결성 4단계:
- L1: 빌드 스크립트 버전관리
- L2: 서명된 Provenance
- L3: 재현 가능 빌드, 격리된 빌드 환경
- L4: Two-party review, 헤르메틱 빌드
4.4 Sigstore: Cosign·Fulcio·Rekor
- Cosign: 컨테이너·아티팩트 서명
- Fulcio: 무료 CA (OIDC 기반)
- Rekor: 투명성 로그
# 서명
cosign sign --yes my-registry/my-app:v1.0
# 검증
cosign verify --certificate-identity-regexp=".*" ...
4.5 Dependency Management 기본
- Dependabot / Renovate: 자동 PR로 업데이트
- SCA 도구 (Snyk, Trivy, Dependency-Check): 알려진 취약점 스캔
- Lock 파일 고정: package-lock.json, uv.lock, Cargo.lock
- Private Registry: 공격 노출 면 축소
- Typosquatting 방어: npm-audit resolver
5부 — Container·Kubernetes 보안
5.1 Container 이미지 보안
- 최소 이미지: distroless, alpine, scratch
- 취약점 스캔: Trivy, Grype (빌드 시 CI)
- 이미지 서명: Cosign
- Admission Control: 서명 검증된 이미지만 배포
- Runtime Monitoring: Falco, Tetragon (eBPF)
5.2 Dockerfile 보안 체크리스트
# 좋은 Dockerfile
FROM cgr.dev/chainguard/python:latest-dev AS builder
# ... 빌드
FROM cgr.dev/chainguard/python:latest
# non-root
USER 1000
# 필요한 포트만
EXPOSE 8080
# HEALTHCHECK
HEALTHCHECK CMD curl -f http://localhost:8080/health || exit 1
- 멀티스테이지 빌드
- Non-root 사용자
- Secret은 build-arg 아닌 runtime env
.dockerignore로 빌드 컨텍스트 최소화
5.3 Kubernetes Pod Security Standards (2024~)
PSP (Pod Security Policy) 제거됨. 대체: PSS (Pod Security Standards).
- Privileged: 제한 없음 (위험)
- Baseline: 기본 보안
- Restricted: 강력한 제한 (프로덕션 권장)
apiVersion: v1
kind: Namespace
metadata:
name: my-app
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
5.4 NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
Default-deny → 필요한 통신만 명시 허용. Cilium이 L7 NetworkPolicy까지 지원.
5.5 Admission Control (Policy-as-Code)
- OPA Gatekeeper: Rego 언어
- Kyverno: YAML 기반 (K8s native)
- Polaris: Best Practice 검사
예시: "모든 Pod은 resources.limits 설정 필수", "latest 태그 금지".
5.6 Service Mesh와 mTLS
Istio, Linkerd, Cilium Service Mesh: Pod 간 통신을 자동 mTLS로. Zero Trust의 Pod-to-Pod 구현.
6부 — Cloud 보안 (AWS 중심)
6.1 IAM 기본 원칙
- Least Privilege: 필요한 권한만
- Role-based Access: User 아닌 Role에 권한
- Temporary Credentials: STS AssumeRole
- MFA 필수: root · admin · 고위험 작업
- Audit: CloudTrail 전체 활성화
6.2 S3 보안 체크리스트
- 기본 Public Access Block (계정·버킷 레벨)
- Bucket Policy 명시적 (IAM만으론 부족)
- 암호화 (SSE-S3 또는 SSE-KMS)
- Versioning + MFA Delete
- Object Lock (WORM)
- Access Log
6.3 Secrets Scanning
- AWS Macie: S3에서 PII 스캔
- GitHub Secret Scanning (무료)
- Gitleaks: pre-commit hook
- TruffleHog: 저장소 전체 감사
6.4 CSPM (Cloud Security Posture Management)
- AWS Config + Security Hub: 네이티브
- Prowler: 오픈소스 감사
- Steampipe: SQL로 클라우드 쿼리
- Wiz, Orca: 상용 CSPM
7부 — OWASP Top 10 (2021) 요약
- Broken Access Control: 인가 결함 (IDOR, 권한 상승)
- Cryptographic Failures: 약한 암호화, 평문 저장
- Injection: SQL·NoSQL·OS·LDAP 주입
- Insecure Design: 설계 자체의 결함
- Security Misconfiguration: 기본값·잘못된 설정
- Vulnerable and Outdated Components: 오래된 라이브러리
- Identification and Authentication Failures: 약한 비밀번호·세션
- Software and Data Integrity Failures: Supply Chain
- Security Logging and Monitoring Failures: 공격 감지 실패
- Server-Side Request Forgery (SSRF): 서버가 내부 리소스 접근
7.1 실전 방어
- Parameterized Query: SQL Injection 방어
- Content Security Policy: XSS 방어
- CORS 엄격 설정
- Rate Limit: 로그인·민감 API
- Input Validation: 서버 측 필수
- Output Encoding: 컨텍스트별 (HTML, JS, URL)
- HTTPS Everywhere + HSTS
8부 — LLM·AI 보안: OWASP LLM Top 10 (2025)
8.1 10대 위험
- Prompt Injection: 악의적 프롬프트로 시스템 조작
- Insecure Output Handling: LLM 출력을 그대로 실행
- Training Data Poisoning: 학습 데이터 오염
- Model Denial of Service: 비용 폭주 공격
- Supply Chain: 모델·플러그인 공급망
- Sensitive Information Disclosure: 학습 데이터 유출
- Insecure Plugin Design: 플러그인/Tool 과권한
- Excessive Agency: Agent가 너무 많은 권한
- Overreliance: LLM 결과 과신
- Model Theft: 모델 추출·재현
8.2 Prompt Injection 방어
# 나쁨: 사용자 입력을 시스템 프롬프트에 직결
system = f"You are a helpful assistant. User said: {user_input}"
# 좋음: 사용자 입력 경계 명확화
messages = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": user_input}, # SDK가 이스케이프
]
방어 레이어 5가지:
- Input Filter: injection 패턴 감지
- Structured Output: Function Calling·JSON Schema
- Output Filter: 민감 정보·코드 실행 검사
- Principle of Least Privilege: Agent Tool 권한 최소
- Human-in-the-loop: 중요 액션 승인
8.3 데이터 보호
- RAG 전 마스킹: PII 제거 후 벡터화
- 출력 필터: 답변에서 PII·secret 스캔
- DLP (Data Loss Prevention): 모든 프롬프트 입출력 모니터
- Tenant Isolation: 멀티 테넌트 간 Embedding 분리
8.4 Model Safety
- Guardrails (NVIDIA, Guardrails AI): 정책 기반 필터
- Rebuff: Prompt Injection 전문
- Lakera Guard: 상용 LLM 방어
- Moderation API: OpenAI·Anthropic 제공
9부 — 보안 개발 라이프사이클 (SSDLC)
9.1 Shift-Left 단계
Design → Code → Build → Test → Deploy → Operate
│ │ │ │ │ │
↓ ↓ ↓ ↓ ↓ ↓
Threat Lint SBOM DAST Signed Monitor
Model SAST Scan PenTest Image Logs
SIEM
9.2 각 단계 도구
- Threat Modeling: STRIDE, PASTA, OWASP Threat Dragon
- SAST (정적): CodeQL, Semgrep, Snyk Code, SonarQube
- SCA (의존성): Snyk, Trivy, Dependabot
- DAST (동적): OWASP ZAP, Burp Suite
- Secret Scanning: Gitleaks, TruffleHog
- IaC Scanning: Checkov, tfsec, KICS
- Container Scanning: Trivy, Grype
- SIEM: Splunk, Elastic SIEM, Panther
9.3 CI/CD 보안 파이프라인 예시
# GitHub Actions
- uses: actions/checkout@v4
- run: npm ci
- uses: gitleaks/gitleaks-action@v2 # Secret scan
- uses: github/codeql-action/analyze@v3 # SAST
- uses: aquasecurity/trivy-action@master # SCA + container
- run: npm test
- run: npm run build
- uses: sigstore/cosign-installer@v3 # Sign image
10부 — Incident Response 기본
10.1 NIST SP 800-61 — 4단계
- Preparation: 정책·런북·도구·훈련
- Detection & Analysis: 감지·분류·범위 파악
- Containment, Eradication, Recovery: 격리·제거·복구
- Post-Incident Activity: 포스트모템·개선
10.2 흔한 초기 대응 실수
- 영향 조사 전 서버 재부팅 → 증거 소실
- 한 엔지니어가 혼자 대응 → 실수·탈진
- Slack 공개 채널에 공유 → 공격자 모니터링 가능
- 법무·PR·고객 소통 늦음
- 포스트모템 없이 종결 → 재발
10.3 Blameless Postmortem
- 사람 아닌 시스템 탓
- 타임라인 재구성
- Root Cause 5 Whys
- 개선 항목 + 책임자 + 기한
11부 — 보안 엔지니어 로드맵 6개월
Month 1: 기초
- OWASP Top 10 실습 (DVWA, WebGoat)
- OAuth/OIDC 흐름 직접 구현
- Burp Suite·ZAP 기본
Month 2: AppSec
- SAST·SCA 파이프라인 구축
- Threat Modeling (STRIDE)
- 코드 리뷰 보안 체크리스트
Month 3: Cloud/K8s
- AWS IAM 심화 + Prowler 감사
- Pod Security Standards
- OPA Gatekeeper / Kyverno
Month 4: Supply Chain
- SBOM 생성·소비
- Cosign 서명·검증
- SLSA 레벨별 요구사항
Month 5: AI 보안
- Prompt Injection 공격·방어 실습
- Guardrails 도입
- RAG 안전 패턴
Month 6: IR + 조직
- Incident Response 훈련 (Tabletop)
- SIEM 규칙 작성
- Security Champion 제도
12부 — 보안 체크리스트 12
- Zero Trust 5원칙을 안다
- Authorization Code + PKCE 흐름을 설명할 수 있다
- JWT 검증 시 확인 항목 5가지를 안다
- Vault 동적 Secret의 장점을 안다
- SBOM의 목적과 표준 2가지를 안다
- SLSA 레벨의 의미를 안다
- K8s Pod Security Standards 3단계를 안다
- S3 보안 체크리스트를 안다
- OWASP Top 10 중 3개 이상 방어법을 설명할 수 있다
- Prompt Injection 방어 5가지 레이어를 안다
- Shift-Left + 각 단계 도구를 안다
- Blameless Postmortem 원칙을 안다
13부 — 보안 안티패턴 10
- "이건 내부망이라 괜찮아": Zero Trust 위반. 내부도 검증
- Git에 .env 커밋 + 나중에 reset: 히스토리엔 남음. 토큰 즉시 회전
- Refresh Token 영원히 유효: 탈취 시 피해 극대화. Rotation 필수
- Secret을 환경변수 + 로그에 덤프: 로그 수집 시 노출
- 의존성 업데이트 미루기: 취약점 축적. Dependabot 활성화
- K8s에 root로 실행: 컨테이너 탈출 시 호스트 점령
- IAM을
*로 설정: 최소 권한 원칙 위반 - 공개 S3 버킷: 2025년에도 매주 사고 뉴스
- JWT secret을 env에 평문: HSM 또는 KMS로 보호
- LLM 출력을 sanitize 없이 실행: Remote Code Execution 위험
마치며 — 보안은 "일상의 엔지니어링"
보안은 특별한 일이 아니다. 코드 리뷰에서 1줄, 배포 파이프라인에서 1 스텝, 설계 회의에서 1 질문 — 이 작은 것들이 쌓여야 된다.
2025년의 보안은:
- Shift-Left: 배포 후 아닌 설계·코드에서 막기
- Zero Trust: 경계 신뢰 포기
- Supply Chain: 우리가 쓰는 것까지 검증
- AI 대응: 새로운 공격면 인지
"우리 회사는 작아서 괜찮다"는 착각을 버려라. 자동화된 공격자는 규모를 가리지 않는다.
다음 글 예고 — "플랫폼 엔지니어링 완전 가이드: IDP·GitOps·Backstage·Cost·DX"
Season 2 Ep 11은 "개발자의 개발자" 플랫폼 엔지니어링. 다음 글은:
- Internal Developer Platform (IDP) 설계
- Backstage로 서비스 카탈로그
- GitOps (ArgoCD, Flux) 심화
- Platform Engineering vs SRE vs DevOps
- Cost Allocation과 FinOps
- Developer Experience (DX) 측정
"Golden Path를 만드는 일", 다음 글에서 이어진다.
현재 단락 (1/308)
**보안이 "보안 팀만의 일"이라는 착각이 뚫린 이유:**