Skip to content
Published on

보안 완전 가이드 — Zero Trust·Secret·OAuth·OIDC·Supply Chain·AI 보안 (Season 2 Ep 10, 2025)

Authors

들어가며 — 왜 모든 엔지니어가 보안을 알아야 하는가

보안이 "보안 팀만의 일"이라는 착각이 뚫린 이유:

  • 보안 팀 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)

  1. 모든 리소스를 "자원"으로 취급
  2. 모든 통신 보안 (네트워크 위치 무관)
  3. 접근은 세션별 승인 (영구 ❌)
  4. 접근 결정은 동적 정책 (ID·기기·위치·시간·행동)
  5. 자산·통신 계속 모니터링

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. ClientAuthServer: /authorize + code_challenge
2. User 로그인·동의
3. AuthServerClient: auth_code
4. ClientAuthServer: /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 주의
LocalStorageXSS 취약 ❌
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 기본

  1. Dependabot / Renovate: 자동 PR로 업데이트
  2. SCA 도구 (Snyk, Trivy, Dependency-Check): 알려진 취약점 스캔
  3. Lock 파일 고정: package-lock.json, uv.lock, Cargo.lock
  4. Private Registry: 공격 노출 면 축소
  5. 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) 요약

  1. Broken Access Control: 인가 결함 (IDOR, 권한 상승)
  2. Cryptographic Failures: 약한 암호화, 평문 저장
  3. Injection: SQL·NoSQL·OS·LDAP 주입
  4. Insecure Design: 설계 자체의 결함
  5. Security Misconfiguration: 기본값·잘못된 설정
  6. Vulnerable and Outdated Components: 오래된 라이브러리
  7. Identification and Authentication Failures: 약한 비밀번호·세션
  8. Software and Data Integrity Failures: Supply Chain
  9. Security Logging and Monitoring Failures: 공격 감지 실패
  10. 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대 위험

  1. Prompt Injection: 악의적 프롬프트로 시스템 조작
  2. Insecure Output Handling: LLM 출력을 그대로 실행
  3. Training Data Poisoning: 학습 데이터 오염
  4. Model Denial of Service: 비용 폭주 공격
  5. Supply Chain: 모델·플러그인 공급망
  6. Sensitive Information Disclosure: 학습 데이터 유출
  7. Insecure Plugin Design: 플러그인/Tool 과권한
  8. Excessive Agency: Agent가 너무 많은 권한
  9. Overreliance: LLM 결과 과신
  10. 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가지:

  1. Input Filter: injection 패턴 감지
  2. Structured Output: Function Calling·JSON Schema
  3. Output Filter: 민감 정보·코드 실행 검사
  4. Principle of Least Privilege: Agent Tool 권한 최소
  5. 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 단계

DesignCodeBuildTestDeployOperate
  │       │       │       │       │         │
  ↓       ↓       ↓       ↓       ↓         ↓
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단계

  1. Preparation: 정책·런북·도구·훈련
  2. Detection & Analysis: 감지·분류·범위 파악
  3. Containment, Eradication, Recovery: 격리·제거·복구
  4. 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

  1. Zero Trust 5원칙을 안다
  2. Authorization Code + PKCE 흐름을 설명할 수 있다
  3. JWT 검증 시 확인 항목 5가지를 안다
  4. Vault 동적 Secret의 장점을 안다
  5. SBOM의 목적과 표준 2가지를 안다
  6. SLSA 레벨의 의미를 안다
  7. K8s Pod Security Standards 3단계를 안다
  8. S3 보안 체크리스트를 안다
  9. OWASP Top 10 중 3개 이상 방어법을 설명할 수 있다
  10. Prompt Injection 방어 5가지 레이어를 안다
  11. Shift-Left + 각 단계 도구를 안다
  12. Blameless Postmortem 원칙을 안다

13부 — 보안 안티패턴 10

  1. "이건 내부망이라 괜찮아": Zero Trust 위반. 내부도 검증
  2. Git에 .env 커밋 + 나중에 reset: 히스토리엔 남음. 토큰 즉시 회전
  3. Refresh Token 영원히 유효: 탈취 시 피해 극대화. Rotation 필수
  4. Secret을 환경변수 + 로그에 덤프: 로그 수집 시 노출
  5. 의존성 업데이트 미루기: 취약점 축적. Dependabot 활성화
  6. K8s에 root로 실행: 컨테이너 탈출 시 호스트 점령
  7. IAM을 *로 설정: 최소 권한 원칙 위반
  8. 공개 S3 버킷: 2025년에도 매주 사고 뉴스
  9. JWT secret을 env에 평문: HSM 또는 KMS로 보호
  10. 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를 만드는 일", 다음 글에서 이어진다.