왜 이 편이 먼저 필요한가

02편에서 정보자산·위협·취약점·위험이라는 뼈대를 잡았고, 04편에서 계정·권한·파일 접근 방식이라는 운영체제(OS, Operating System) 관점의 사전지식을 정리했습니다. 이 편부터는 그 뼈대를 애플리케이션이 사용자와 데이터베이스를 연결하는 실제 계층 구조에 적용합니다.

시험 출제기준의 “시스템 및 애플리케이션 보안” 영역은 매년 상당한 비중을 차지하는데, 정작 응시자들이 자주 놓치는 지점은 개별 공격 기법(SQL 인젝션 문법 등)이 아니라 왜 그 계층에 그런 구멍이 뚫리는가라는 구조적 이해입니다. 10~12편에서 악성코드·취약점·DB 접근통제를 각각 깊게 다루기 전에, 이 편에서 애플리케이션·웹·DB가 서로 데이터를 주고받는 기본 구조와 그 경계마다 어떤 신뢰 가정이 깔려 있는지 먼저 정리합니다.

쉽게 말하면: 이 편은 “공격이 시작되는 무대”를 설명합니다. 사용자의 입력이 애플리케이션을 거쳐 데이터베이스까지 도달하는 길을 한 번 그려 보면, 그 길의 각 구간마다 왜 검증이 필요한지가 저절로 보입니다.

1. 3계층 구조와 신뢰 경계

웹 기반 정보시스템은 보통 세 계층(3-tier)으로 나눕니다. 프레젠테이션 계층(사용자 화면, 브라우저), 애플리케이션 계층(비즈니스 로직을 처리하는 서버 프로그램), 데이터 계층(데이터베이스, DB)입니다.

정보보호 관점에서 이 그림에서 가장 중요한 개념은 신뢰 경계(Trust Boundary)입니다. 신뢰 경계란 “이 선을 넘어오는 데이터는 검증되지 않았다고 가정해야 하는 지점”을 뜻합니다. 사용자가 입력한 값은 그것이 로그인 폼이든 URL 파라미터든, 애플리케이션 서버 입장에서는 누가 무엇을 보냈는지 확신할 수 없는 값입니다. 이 값을 그대로 믿고 데이터베이스 쿼리나 화면 출력에 사용하면 취약점이 발생합니다. 11편에서 다룰 SQL 인젝션·XSS(Cross-Site Scripting)는 모두 이 신뢰 경계에서 검증을 생략했을 때 생기는 문제입니다.

2. 입력 검증의 원칙

입력 검증(Input Validation)은 애플리케이션이 외부에서 들어온 값을 사용하기 전에 그 값의 형식·길이·범위·문자 종류가 기대한 조건과 일치하는지 확인하는 절차입니다. 정보보호 시험에서 입력 검증을 다룰 때는 다음 세 가지 원칙을 구분해서 기억해야 합니다.

3. HTTP 요청·응답과 상태 비저장 문제

웹은 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜) 위에서 동작합니다. HTTP는 설계상 상태를 저장하지 않는(Stateless) 프로토콜입니다. 즉 사용자가 로그인에 성공한 직후 다음 페이지를 요청해도, 서버 입장에서는 그 요청이 “방금 로그인한 그 사용자”의 요청인지 매번 새로 확인해야 합니다.

이 상태 비저장 문제를 해결하기 위한 장치가 쿠키(Cookie)와 세션(Session)입니다.

• 쿠키: 서버가 브라우저에게 저장하라고 내려보내는 작은 데이터 조각입니다. 이후 같은 사이트에 요청을 보낼 때마다 브라우저가 자동으로 그 쿠키를 함께 실어 보냅니다.
• 세션: 서버 쪽에 저장되는, 사용자별 로그인 상태·임시 데이터의 묶음입니다. 서버는 각 세션을 구분하기 위해 무작위로 생성한 세션ID(Session ID)를 발급하고, 이 세션ID 자체를 쿠키에 담아 브라우저에게 전달합니다.

즉 브라우저에는 세션 전체가 아니라 세션ID라는 “열쇠”만 쿠키로 저장되고, 실제 로그인 상태·개인정보 같은 값은 서버 안의 세션 저장소에 남습니다. 이 구조를 정확히 알아야 12편의 세션 관리, 14편의 인증 메커니즘을 이어서 이해할 수 있습니다.

4. 데이터베이스 계정·권한·역할의 기본 구조

애플리케이션 서버는 데이터베이스에 접속할 때 자신의 DB 계정(DB Account)을 사용합니다. 이때 정보보호 관점에서 핵심 원칙은 04편에서 다룬 최소 권한 원칙(Principle of Least Privilege)을 DB 계정에도 그대로 적용하는 것입니다.

역할(Role)이 필요한 이유는 계정이 수백 개일 때 권한을 하나씩 부여·회수하는 관리 부담을 줄이기 위해서입니다. “영업팀 조회 역할”이라는 역할 하나를 만들어 필요한 SELECT 권한들을 미리 묶어 두면, 신규 입사자에게는 그 역할 하나만 부여하면 됩니다. 이 역할 기반 설계는 12편에서 다룰 RBAC(Role-Based Access Control, 역할 기반 접근통제) 모델의 실제 구현 형태이기도 합니다.

애플리케이션 서버가 DB에 접속할 때 흔히 저지르는 실수가 있습니다. 모든 기능을 처리할 수 있는 관리자급(DBA, Database Administrator) 계정 하나로 애플리케이션 전체를 운영하는 것입니다. 이렇게 하면 SQL 인젝션 같은 취약점이 뚫렸을 때, 공격자가 그 애플리케이션 계정의 권한 전체(테이블 삭제, 다른 사용자 데이터 열람 등)를 그대로 넘겨받게 됩니다. 반대로 애플리케이션 기능별로 필요한 최소한의 권한만 가진 계정을 나누어 쓰면, 같은 취약점이 뚫려도 피해 범위가 그 계정의 권한만큼으로 제한됩니다.

5. SQL 기반 취약점의 위치 — 개관만

이 계층 구조에서 SQL 인젝션이 발생하는 지점을 짚어 두면 11편을 이해하기 쉬워집니다. 애플리케이션이 사용자 입력을 검증 없이 SQL 문자열에 그대로 이어붙여 데이터베이스에 전달하면, 사용자가 입력한 값이 데이터가 아니라 SQL 명령어의 일부로 해석될 수 있습니다.

정상 의도: SELECT * FROM users WHERE id = '입력값'
공격자 입력값: ' OR '1'='1
결과 쿼리: SELECT * FROM users WHERE id = '' OR '1'='1'

위 예시처럼 입력값 안에 SQL 구문 조각을 섞어 넣어 원래 쿼리의 의미를 바꾸는 것이 SQL 인젝션의 핵심 원리입니다. 이 취약점의 상세한 분류·방어 기법(Prepared Statement 등)은 11편에서 다룹니다. 이 편에서는 “왜 애플리케이션 계층의 입력 검증 실패가 곧 DB 계층의 문제로 이어지는가”라는 계층 간 연결 관계만 기억하면 됩니다.

핵심 정리

• 웹 기반 시스템은 프레젠테이션·애플리케이션·데이터 3계층으로 나뉘며, 각 계층 경계는 신뢰 경계로서 별도의 검증이 필요하다.
• 입력 검증은 화이트리스트 방식·서버 측 검증을 원칙으로 하며, 클라이언트 측 검증만으로는 보안이 성립하지 않는다.
• HTTP는 상태 비저장 프로토콜이므로 쿠키(브라우저 저장)와 세션(서버 저장)을 조합해 로그인 상태를 유지하며, 쿠키에는 세션ID 같은 식별값만 담아야 한다.
• DB 접근에도 최소 권한 원칙을 적용해 애플리케이션 계정을 기능별로 분리하고, 역할(Role)로 권한 묶음을 관리한다.
• 입력 검증 실패는 애플리케이션 계층에서 끝나지 않고 SQL 인젝션 등 DB 계층 취약점으로 이어지므로, 두 계층은 하나의 방어선으로 함께 다뤄야 한다.

마무리 복습

참고 자료

• OWASP - Top 10 웹 애플리케이션 보안 위험 
• 한국인터넷진흥원(KISA) - 웹 취약점 및 개인정보 DB 보호조치 가이드