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

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

- 보안 팀 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. 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 기본

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 단계

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단계

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를 만드는 일", 다음 글에서 이어진다.