Application & Data Security

1. Overview

애플리케이션 및 데이터 보안(Application & Data Security, ADS)은 인프라라는 성벽을 뚫고 들어오거나 정당한 사용자로 위장한 해커가, 실제로 돈이 되는 '데이터'와 '비즈니스 로직'을 탈취하지 못하도록 막아내는 최후의 방어선을 다룹니다.

웹 서버의 포트를 열어두었다면 방화벽은 더 이상 웹 해킹을 막지 못합니다. 학습자는 데이터베이스를 통째로 지워버리는 SQL 인젝션(SQLi)과 사용자 브라우저를 좀비로 만드는 XSS 등 OWASP Top 10 웹 취약점의 공격 물리를 해부합니다. 이를 방어하기 위해 코드 레벨에서 입력값을 검증하는 보안 코딩(Secure Coding) 원칙을 체화하며, 만에 하나 데이터베이스가 통째로 유출되더라도 해커가 쓸 수 없도록 데이터를 암호화(Encryption)하고 개인정보를 비식별화(Anonymization)하는 실무적 방어 역학을 배웁니다.

2. Scope & Boundaries

In-Scope

웹 애플리케이션 취약점 (Web Vulnerabilities): SQL Injection, XSS(Cross-Site Scripting), CSRF(Cross-Site Request Forgery), SSRF.
보안 코딩과 진단 (Secure Coding): 입력값 검증(Input Validation), 출력값 인코딩(Output Encoding), SAST(정적 분석)/DAST(동적 분석).
데이터 보호 (Data Protection): 데이터베이스 암호화, 토큰화(Tokenization), 전송 중 데이터(TLS)와 미사용 데이터(At-rest) 보호.
프라이버시와 비식별화 (Privacy Tech): 데이터 마스킹, 가명 처리, K-익명성(K-Anonymity) 및 L-다양성.

Out-of-Scope

방화벽 및 VPC 네트워크 차단: IP 대역을 막거나 포트를 차단하는 인프라 레벨의 방어 $\rightarrow$ 10-02. Infrastructure & Platform Security 영역으로 위임.
사용자 인증 아키텍처 및 OAuth 흐름: 로그인, 세션, JWT 발급의 구조적 설계 $\rightarrow$ 10-04. Identity, Access & Trust 영역으로 위임.

Boundaries

ADS vs. Quality Assurance (09-04): QA(09-04)가 "사용자가 이메일 입력 칸에 이메일을 잘 적으면 에러가 안 난다"를 확인한다면, ADS는 "해커가 이메일 입력 칸에 <script> 태그나 SQL 쿼리를 적어 넣었을 때 서버가 뚫리는가?"를 현미경처럼 검증하는 악의적 상황에 대한 방어입니다.

3. Counterexample

프론트엔드 검증 맹신 (Client-side Validation Fallacy): 브라우저(자바스크립트)에서 "비밀번호는 특수문자 포함 8자 이상"을 검증했으니 서버는 안전할 것이라고 맹신하는 아마추어적 발상. 해커는 브라우저를 쓰지 않고 포스트맨(Postman)이나 파이썬 스크립트로 프론트엔드를 우회하여 서버 API로 악성 데이터를 직접 꽂아 넣습니다. 진정한 보안 코딩은 모든 클라이언트를 거짓말쟁이로 간주하고 **서버(Back-end)에서 입력값을 재검증(Validation)**하는 것입니다.
보안 코드 점검의 수동화 (Manual Review Fallacy): 10만 줄의 소스 코드를 개발팀장이 눈으로 한 줄씩 읽으며 보안 취약점을 찾겠다는 비효율. 인간의 눈은 SQL 인젝션의 미세한 흐름을 모두 쫓을 수 없습니다. 현대의 애플리케이션 보안은 CI/CD 파이프라인에 SonarQube 같은 SAST(정적 분석기) 도구를 연동하여, 코드가 git push되는 순간 기계가 1초 만에 취약점을 짚어내게 만드는 DevSecOps의 자동화 물리를 따릅니다.

4. Prerequisites

웹 프로토콜 (Basic): HTTP의 구조, 쿠키(Cookie)와 세션(Session)의 작동 원리를 알아야 XSS와 CSRF 공격이 왜 가능한지 이해할 수 있습니다. (08-04. WAP)
보안 기초 (Basic): 해시(Hash), 대칭키(AES), 비대칭키(RSA)의 차이를 알아야 DB 암호화 아키텍처를 짤 수 있습니다. (10-01. SFC)

5. Learning Map

Sequence	Core Cluster	Objective & Description	Evidence (BoK)
1	Vulnerability Anatomy	SQLi, XSS 등 해커가 웹사이트를 박살 내는 가장 뻔하지만 치명적인 10가지 공격(OWASP Top 10)의 물리를 해부합니다.	Industry
2	Secure Coding	공격의 원리가 '사용자의 입력을 믿은 죄'임을 깨닫고, 모든 입력을 필터링하고 인코딩하는 방어 코딩을 체화합니다.	P2
3	Automated SecOps	소스 코드를 병합할 때마다 기계가 자동으로 취약점을 스캔해 주는(SAST/DAST) 데브섹옵스 파이프라인을 구축합니다.	P3
4	Data & Privacy Guard	데이터베이스가 통째로 털려도 해커가 읽지 못하도록 휴면 데이터를 암호화하고, 민감 정보를 가명 처리합니다.	Industry

6. Learning Topics

Basic

Core Topic 01: 웹 애플리케이션 주요 취약점 물리 (OWASP Top 10)

Why to Learn: 적(해커)이 내 웹 서버를 어떻게 부수고 데이터를 훔쳐 가는지 그 교활한 논리를 눈으로 확인해야 방패를 세울 수 있기 때문입니다.
What to Learn:
- Concepts: OWASP Top 10, 취약점(Vulnerability), 익스플로잇(Exploit), 페이로드(Payload).
- Skills: SQL 인젝션(SQLi), 교차 사이트 스크립팅(XSS), 교차 사이트 요청 위조(CSRF), 경로 조작(Path Traversal).
- Tools: DVWA(Damn Vulnerable Web App), Burp Suite.
- Trade-offs: 모든 공격 시나리오를 방어하기 위해 엄청난 검증 로직을 넣는 것 vs 코드가 지저분해지고 성능이 저하되는 트레이드오프.
How to Learn:
- 1단계: 해커가 로그인 폼에 admin' OR '1'='1이라고 입력했을 때, 서버 내부에서 데이터베이스 쿼리가 SELECT * FROM users WHERE id = 'admin' OR '1'='1'로 변조되어 비밀번호 없이도 강제 로그인되는 SQLi의 문법적 물리를 분석합니다.
- 2단계: 게시판 글에 <script>alert(document.cookie)</script>라는 코드를 심어두면, 그 글을 읽는 모든 사용자의 브라우저에서 스크립트가 실행되어 세션 쿠키를 해커에게 몰래 전송하는 Stored XSS의 무서움을 실습합니다.
Implement: 로컬 환경에 웹 모의 해킹 환경(DVWA)을 띄우고, SQLi와 XSS 공격을 직접 수행하여 성공 화면을 캡처한 뒤 방어 대책을 적은 보안 모의 해킹 보고서.

Why to Learn: 해킹의 99%는 "개발자가 사용자의 입력을 의심하지 않고 그대로 시스템에 집어넣었기 때문"에 발생하므로, 이 구멍을 코드 단에서 원천 봉쇄하기 위해서입니다.
What to Learn:
- Concepts: 보안 코딩(Secure Coding), 컨텍스트 혼동(Context Confusion).
- Skills: 입력값 검증(Input Validation), 매개변수화된 쿼리(Parameterized Query / Prepared Statement), 출력값 인코딩(Output Encoding).
- Tools: 웹 프레임워크 내장 보안 기능(ORM, 템플릿 엔진).
- Trade-offs: 프론트엔드와 백엔드 양쪽에서 2번씩 검증 로직을 짜야 하는 극악의 개발 피로도 vs 한 번만 검증 로직을 빼먹었을 때 발생하는 수십억 원의 데이터 유출 배상금.
How to Learn:
- 1단계: 문자열 결합 연산자(+)로 SQL을 만들 때 발생하는 SQLi를 방지하기 위해, 쿼리 뼈대(SELECT * FROM users WHERE id = ?)를 먼저 DB에 보내 컴파일시키고 데이터는 나중에 끼워 넣는 Prepared Statement의 물리적 방어 기제를 코드로 작성해 봅니다.
- 2단계: 사용자가 입력한 HTML 태그(<script>)를 브라우저가 실행하지 못하도록, 화면에 출력하기 직전에 <script>로 변환(HTML Entity Encoding)해 버리는 XSS 방어 로직을 실습합니다.
Implement: 회원가입 API에서 정규 표현식(Regex)을 통한 이메일/비밀번호 강력한 검증 로직을 구현하고, DB 저장 시 ORM을 사용하여 SQLi를 물리적으로 차단한 코드베이스.

Practical

Core Topic 03: 데이터베이스 암호화와 키 관리 체계 (Data Security & KMS)

Why to Learn: 애플리케이션 방어선이 모두 뚫려 해커가 DB를 통째로 복사해 가더라도, 열어보면 의미 없는 쓰레기 문자열만 보이게 만들기 위함입니다.
What to Learn:
- Concepts: 미사용 데이터(Data At-rest) 암호화, 전송 중 데이터(Data In-transit) 암호화, 토큰화(Tokenization).
- Skills: 컬럼 암호화 vs TDE(Transparent Data Encryption) 비교, 키 관리 시스템(KMS) 역학.
- Tools: AWS KMS, HashiCorp Vault.
- Trade-offs: "암호화 키"를 안전하게 관리하기 위해 별도의 거대한 KMS 인프라를 구축하고 트래픽을 태우는 비용 vs 키를 소스 코드에 하드코딩해서 무료로 쓰다가 깃허브(GitHub)가 털려 회사가 통째로 망하는 비용.
How to Learn:
- 1단계: 비밀번호를 암호화할 때는 복호화가 불가능한 '단방향 해시(Bcrypt)'를 쓰지만, 주민등록번호는 나중에 관리자가 조회해야 하므로 '양방향 대칭키 암호화(AES)'를 써야 하는 데이터 속성별 암호화 전략의 차이를 맵핑합니다.
- 2단계: 애플리케이션의 소스 코드 파일(예: .env)에 DB 접속 비밀번호나 API 키를 하드코딩하는 짓을 멈추고, HashiCorp Vault나 AWS Secrets Manager에서 실행 시점에 동적으로 키를 주입받아 메모리에만 들고 있는 물리적 격리 체계를 구현합니다.
Implement: 애플리케이션에서 AWS KMS API를 호출해 중요한 데이터(예: 계좌번호)를 암호화(Encrypt)하여 DB에 저장하고, 조회할 때만 다시 복호화(Decrypt)하는 과정을 증명하는 프로토타입.

Advanced

Core Topic 04: 정적/동적 분석(SAST/DAST)과 프라이버시 (DevSecOps & Privacy)

Why to Learn: 개발자의 실수(Human Error)를 사람의 리뷰로 잡는 대신 파이프라인(CI/CD) 안의 기계가 자동으로 쳐내고, 개인정보 보호법(GDPR)의 기술적 조치를 자동화하기 위해서입니다.
What to Learn:
- Concepts: SAST(정적 분석: 소스 코드 자체 검사), DAST(동적 분석: 실행된 앱을 찔러봄), DevSecOps.
- Skills: 프라이버시 강화 기술(PET), K-익명성(K-Anonymity), L-다양성, 데이터 마스킹(Masking).
- Tools: SonarQube(SAST), OWASP ZAP(DAST).
- Trade-offs: 마케팅 팀이 "고객 분석하게 데이터 다 주세요!"라고 할 때, 데이터를 넘겨주는 비즈니스 가치 vs "개인정보보호법 위반입니다"라며 비식별화 처리를 하느라 데이터의 분석 가치가 떨어지는 유용성 하락 간의 타협점.
How to Learn:
- 1단계: GitHub Actions 파이프라인에 SonarQube를 연동하여, 개발자가 eval() 함수나 하드코딩된 암호화 키를 푸시(Push)하면 "보안 심각도: High"를 띄우고 병합(Merge)을 강제 취소시키는 DevSecOps 자동화 물리를 셋업합니다.
- 2단계: 고객 테이블에서 이름은 "홍*동"으로 마스킹하고, 나이는 "32세" 대신 "30대"로 뭉뚱그려 특정 개인을 식별하지 못하도록(K-익명성) 변환하는 데이터 가명 처리 과정을 실습합니다.
Implement: 특정 소스 코드 리포지토리에 SAST 도구를 붙여 취약점을 자동 진단하고, 데이터베이스에서 개인정보 컬럼을 식별하여 K-익명성 기준으로 변환하는 스크립트 작성.

7. Terminology

Term (EN / ko, abbr)	1문장 정의	단계(기본/권장/실무/심화)	역할/맥락	관련 개념	유사/대비/함께 사용	오해 포인트	Evidence(Primary/Secondary/Industry)	Flags(core)
Input Validation	외부로부터 들어오는 모든 데이터가 허용된 형식과 범위를 준수하는지 확인하는 일차적 방어 기법입니다.	기본	결함 예방	Sanitization	Output Encoding	프론트엔드 검증만으로 충분하다 오해	P2:SWEBOK.	core
Secret Management	API 키, DB 비밀번호 등 민감한 인증 정보를 코드와 분리하여 안전하게 관리하는 물리적 체계입니다.	추천	인증 관리	Vault	Hardcoding	단순히 '암호화 저장'으로 오해	Industry Standard	core
SAST	정적 프로그램 분석 기술을 활용하여 런타임 없이 소스 코드 수준에서 취약점을 찾아내는 보안 기법입니다.	실무	자동 소스 진단	DAST	Linting	모든 버그를 잡는다고 오해	P3:CyBOK Sec	core
PII (개인정보)	특정 개인을 직접적으로 식별하거나 다른 정보와 결합하여 식별할 수 있는 모든 정보를 말합니다.	실무	법적 규제	GDPR	Sensitive Data	'이름/번호'만 해당한다고 오해	Industry	core

8. References

Primary References

[P3] CyBOK - Software Security / Privacy & Online Rights — Application-level standards.
[P2] SWEBOK v4.0 - Software Construction / Quality — Secure implementation foundations.

Secondary References

[OWASP Top 10 Project] — The standard for web application risk assessment.
[The Web Application Hacker's Handbook] Dafydd Stuttard — Deep dive into web attacks.

Industry References

[Google - Secure Software Development Framework (SSDF)] — Industry process standard.
[GDPR Articles] — Privacy and data protection regulations for software.

9. Final Checklist

Primary Checklist

사용자 입력값이 비즈니스 로직에 전달되기 전, 서버 측(Server-side)에서 검증되어야 하는 물리적 보안 필연성을 기술할 수 있는가? (P2)
데이터베이스 통신 시 '동적 SQL'이 '정적 SQL(Parametrized)'보다 보안상 취약한 이유를 데이터 처리 역학 관점에서 설명 가능한가? (P3)

Secondary Checklist

암호화된 데이터를 전송할 때, 데이터의 무결성과 기밀성을 동시에 보장하기 위한 암호화 모드(예: GCM)의 이점을 이해하는가?
소스 코드에 포함된 민감 정보를 탐지(Secret Scanning)하고, 이를 외부 관리 도구로 전환하는 자동화 환경을 구축할 수 있는가?

Industry Checklist

실무 서비스의 개인정보 처리 방침에 따라, 데이터 보존 기간이 만료된 데이터를 물리적으로 안전하게 파기하는 절차를 설계할 수 있는는가? (SFIA)
외부 라이브러리(NPM, Maven 등)의 CVE 취약점 공시를 모니터링하고, 패치 수준에 따른 시스템 영향도를 평가할 수 있는가?