웹 애플리케이션 구조와 신뢰 경계 | 정보보안기사 필기

1. 클라이언트와 서버는 장비 이름이 아니라 역할이다

네트워크에서 서비스를 요청하는 쪽을 클라이언트(client), 요청을 받아 기능을 제공하는 쪽을 서버(server)라고 한다.

따라서 “서버는 항상 한 대의 물리 장비”라고 생각하면 구조를 잘못 이해하기 쉽다. 서버는 통신과 처리에서 맡은 논리적 역할이며, 한 장비가 여러 역할을 동시에 수행하거나 한 역할이 여러 장비에 분산될 수 있다.

브라우저, 모바일 앱, API 클라이언트처럼 사용자의 의도를 HTTP 요청으로 표현하고 서버의 응답을 사용하는 역할이다. 사용자가 입력한 값뿐 아니라 쿠키, 요청 헤더, 업로드 파일 등도 서버가 처리할 입력이 될 수 있다.

외부의 HTTP/HTTPS 요청을 처음 받는 접점이다. 정적 파일을 직접 반환하거나, 동적 처리가 필요한 요청을 애플리케이션으로 전달할 수 있다. 실제 서비스에서는 TLS 종료, 접근 제어, 로드 분산, 요청 크기 제한 같은 기능을 함께 맡기도 한다.

WAS(Web 애플리케이션 서버)는 웹 요청에 따라 프로그램 로직을 실행하는 서버 측 역할을 가리킬 때 널리 사용하는 표현이다. 로그인 확인, 게시글 저장, 주문 처리, 권한 검사, API 처리 등이 여기에 해당한다.

웹 서버와 WAS가 반드시 물리적으로 분리되어야 하는 것은 아니다. 하나의 제품이나 프로세스가 정적 콘텐츠 제공과 애플리케이션 실행을 모두 처리할 수도 있다. 시험에서는 제품 이름보다 각 역할이 무엇을 하는지를 구분하는 것이 중요하다.

DBMS(Database Management System)는 사용자, 권한, 주문, 게시글 같은 업무 데이터를 저장하고 검색·변경한다. 일반적인 웹 구조에서는 외부 사용자가 DB에 직접 접속하기보다 애플리케이션이 필요한 작업을 대신 수행한다.

이 구조에서는 애플리케이션이 DB에 사용하는 계정도 필요한 권한만 가지도록 제한해야 한다. 웹 애플리케이션이 침해되더라도 DB 전체 권한까지 자동으로 넘어가지 않게 하기 위해서다.

사용자가 브라우저에 https://shop.example을 입력했다고 가정하자. 실제 구현은 다양하지만 학습할 때는 다음 순서로 나누면 이해하기 쉽다.

이름 해석: DNS를 통해 서비스 이름에 대응하는 접속 주소를 찾는다.
연결과 전송 보호: 클라이언트가 서버에 연결한다. HTTPS라면 HTTP 메시지를 보내기 전에 TLS를 이용해 보호된 통신 채널을 만든다.
HTTP 요청: 클라이언트가 원하는 자원이나 동작을 요청 메시지로 보낸다.
웹 접점 처리: 정적 파일은 웹 서버가 바로 반환할 수 있고, 업무 처리가 필요하면 애플리케이션으로 요청을 전달한다.
업무 로직과 권한 판단: 애플리케이션이 입력을 해석하고 현재 사용자가 해당 기능·데이터에 접근할 수 있는지 확인한다.
DB 접근: 필요한 경우 애플리케이션이 자신의 DB 권한으로 데이터를 조회하거나 변경한다.
응답 반환: 결과가 애플리케이션 → 웹 접점 → 클라이언트 순으로 돌아온다.

신뢰 경계(trust boundary)는 데이터가 서로 다른 신뢰 수준의 영역 사이를 넘어가는 지점이다. 경계를 넘는 데이터는 “이미 내부로 들어왔으니 안전하다”고 가정해서는 안 된다.

대표적으로 다음을 확인한다.

이 관점은 이후 SQL 삽입, XSS, CSRF, 파일 업로드, 경로 조작 같은 취약점을 “이름”으로만 암기하지 않고 어느 경계에서 어떤 검사가 빠졌는지 이해하는 데 사용된다.

“웹이 안 된다”는 현상 하나도 원인은 여러 단계에 있을 수 있다.

이렇게 계층과 역할을 나누면 운영 장애 분석과 보안 취약점 판단을 함께 정리할 수 있다.