실무 보안 아키텍처 설계 시리즈 - [1편] 왜 WEB/WAS를 분리해야 하는가
※ 목차
⬛ 레거시에서 한 번쯤 만나는 요구사항
⬛ 2-Tier와 3-Tier, 보안 관점에서 뭐가 다른가
⬛ 두 가지 보안 관점
⬛ 레거시에서 한 번쯤 만나는 요구사항
레거시 시스템을 운영하다 보면 WEB(웹서버)과 WAS(웹 애플리케이션 서버)의 분리 요구를 한 번쯤 만나게 됩니다. 저도 그랬습니다.
어서와, 서버 해체는 처음이지?
고객사에서 두 가지 요청이 들어왔습니다.
첫 번째는 WEB 서버와 DB 서버의 물리적 분리, 즉 2-Tier 구조입니다.
두 번째는 WEB 서버를 다시 클라이언트 접근용 서버와 애플리케이션 서버로 나누는 3-Tier 구조입니다.
내부에서도 비슷한 방향의 요구가 있었습니다. 클라이언트에서 WAS에 직접 접근하는 것을 차단하고, WAS는 사설 네트워크에서만 접근 가능하게 하자는 것이었습니다.
이러한 요구사항을 받으면 보통 두 가지 반응으로 나뉩니다.
1️⃣ "고객사 요청이니까 바로 진행하자."
갑이 원하면 을은 묻고 따질 것 없이 바로 개발에 들어가는 것입니다.
2️⃣ "왜 분리해야 하는데?"
요구사항의 근거부터 이해하려는 것입니다. 느리지만, 이후 아키텍처와 암호화 방식을 결정할 때 판단의 기준이 됩니다.
저는 후자를 택했습니다. WEB/WAS를 분리했을 때 어떤 장단점이 있고, 기존 시스템에 어떤 임팩트가 있는지를 먼저 이해하고 싶었습니다.
여기서 잠깐. "이거 주니어가 왜 신경 써요? 아키텍처는 시니어분들이 정하는 거 아닌가요?"
보통은 그렇습니다.
그런데 "왜 이렇게 설계했는지"를 모르면, 나중에 그 위에 코드를 쌓으면서 설계 의도를 깨뜨리게 됩니다.
그게 바로 '나'가 될 수 있습니다.
⬛ 2-Tier와 3-Tier, 보안 관점에서 뭐가 다른가
사용자 입장에서는 2-Tier든 3-Tier든 똑같이 동작합니다.
차이는 "공격자 시점에서 어디까지 접근할 수 있느냐"에서 갈립니다.
2-Tier: 공격 표면이 곧 전체 시스템
2-Tier 구조에서는 클라이언트가 WAS에 직접 접근합니다.
이 말은 WAS의 IP, 포트, 서버 종류와 버전 등의 정보가 외부에 노출된다는 뜻입니다.
공격자 입장에서 보면 타깃이 바로 보입니다. WAS의 취약점이 곧 전체 시스템의 취약점이 됩니다.
3-Tier: 네트워크 경계가 하나 더 생긴다
3-Tier 구조에서는 WEB 서버가 외부 접근 영역에, WAS는 외부에서 직접 도달할 수 없는 내부 영역에 배치됩니다.
두 영역 사이에는 네트워크 경계가 존재하고, 허용된 통신만 통과할 수 있습니다.
외부에서 WEB까지는 접근할 수 있지만, WAS에는 직접 닿을 수 없습니다.
⬛ 두 가지 보안 관점
분리가 필요하다는 건 알겠는데, 그래서 어떤 기준으로 아키텍처를 설계할 것인가?
저는 이 과정에서 두 가지 관점을 세웠습니다.
관점 1) 보안사고 예방
알 수 없으면 공격할 수 없습니다. WAS 정보를 외부에 노출하지 않는 것, 즉 공격 표면 자체를 줄이는 것이 1차 방어선입니다.
위 2-Tier 구조도를 다시 보시면, 공격자가 WAS에 바로 접근하는 것을 원천적으로 막는 것이 관점 1입니다.
관점 2) 2차 피해 방지
아무리 잘 막아도 100% 안전한 시스템은 없습니다.
침해가 발생했을 때 그 범위를 구조적으로 제한하는 게 핵심입니다.
3-Tier 구조도에서 WEB이 뚫리더라도 경계 앞에서 WAS/DB로의 접근이 차단되는 부분, 그게 관점 2입니다.
이 두 가지 관점(보안사고 예방과 2차 피해 방지)이 이후 시리즈에서 제가 내리는 모든 의사결정의 기준이 됩니다.
정리
고객사의 요구사항은 "WEB/WAS를 분리해주세요"였습니다.
이 요구의 본질은 공격 표면 최소화와 침해 범위 제한이었습니다. 저는 이 두 가지를 이후 설계의 판단 기준으로 삼았습니다.
"다음으로는, 기존 프로젝트가 이미 운영되고 있는 상태에서 구체적으로 어떤 아키텍처로 분리할지를 정해야 합니다."
다음 편 → [2편] 세 가지 아키텍처 직접 비교
댓글