길리랩blog

3 Tier 아키텍처 보안: Web·WAS·DB 방어 체계

3 Tier 아키텍처에서 Web Server, WAS, DB Server별 보안 점검 항목과 심층 방어 전략을 정리한다.

2026-08-14 · 최초 발행 2025-05-23

계층 분리가 곧 보안 분리는 아니다

3 Tier 아키텍처는 애플리케이션을 Web Server, WAS(Web Application Server), DB Server라는 독립된 논리 계층으로 나누는 방식이다. HTTP 요청과 정적 콘텐츠는 Web Server가 처리하고, 비즈니스 로직과 동적 콘텐츠는 WAS가 맡으며, 데이터 저장과 관리는 DB Server가 담당한다.

⤢✕ClientWeb ServerWeb Application ServerDatabase Server

이 구조는 확장성과 유지보수성에 유리하지만, 각 구간에 별도의 취약점이 생길 수 있다. 특히 외부에 노출되는 Web Server는 공격 시도가 집중되므로 다른 계층보다 엄격한 관리가 필요하다.

DB에 남는 계정과 권한부터 확인한다

DB Server는 중요 정보가 모이는 핵심 자산이다. 기본 계정, 불필요한 테스트 계정, 과도한 권한은 데이터 보호 체계를 쉽게 약화시킨다.

초기 패스워드가 남아 있지 않은지 확인해야 한다. Oracle의 scott/tiger 같은 기본 패스워드는 사용하지 않으며, 대소문자·특수문자·숫자를 조합한 최소 10자 이상의 복잡한 비밀번호 정책을 적용한다. 사용하지 않는 테스트 계정과 기본 계정도 제거 대상이다.

# 오라클 미사용 계정 확인 예시 쿼리
SELECT username, account_status, lock_date
FROM dba_users
WHERE account_status = 'OPEN'
AND username NOT IN ('SYS','SYSTEM');

권한은 최소 권한 원칙에 따라 사용자별 업무에 필요한 범위만 부여한다. PUBLIC 권한은 최소화하고 DBA 권한은 제한적으로 사용한다.

# MySQL 사용자 권한 확인 예시
SELECT user, host, db, select_priv, insert_priv, update_priv, delete_priv
FROM mysql.db;

개인정보와 금융정보 같은 민감 데이터는 암호화 대상이다. 컬럼 단위 암호화, 투명한 데이터 암호화(TDE), SSL/TLS 기반 전송 데이터 암호화를 함께 검토한다.

A금융회사는 고객 개인정보를 암호화하지 않은 DB에 저장했고, 불필요한 테스트 계정도 활성화된 상태로 운영했다. 내부자의 부정접근으로 고객정보가 유출됐으며 금융감독원 징계 및 과징금 부과 대상이 되었다.

Web과 WAS에서 확인할 노출 지점

운영체제 설정부터 살펴볼 필요가 있다. Umask는 파일과 디렉터리가 생성될 때의 기본 권한을 결정한다. 보안을 위해 022 또는 027 설정을 권장하며, 022는 소유자에게 전체 권한을, 그룹 및 기타 사용자에게 읽기·실행 권한을 부여한다.

# Umask 확인
$ umask

# Umask 설정 (022 권장)
$ umask 022

# /etc/profile에 추가하여 영구 설정
echo "umask 022" >> /etc/profile

필요하지 않은 네트워크 서비스도 비활성화한다. telnet, rsh, ftp처럼 보안에 취약한 서비스가 실행 중인지 확인하고 중지한다.

# 불필요한 서비스 확인
$ systemctl list-unit-files --type=service | grep enabled

# 불필요한 서비스 비활성화
$ systemctl disable telnet.service
$ systemctl stop telnet.service

백업 설정 파일이 웹에서 접근 가능한 위치에 남아 있으면 안 된다. .bak, .old, .backup 확장자 파일을 관리하고, 개인정보 파일·DB 접속 정보·내부 서버 정보가 노출되지 않도록 점검한다.

# 민감한 정보 검색 예시
$ find /var/www -type f -name "*.conf" | xargs grep -l "password"
$ find /var/www -type f -name "*.xml" | xargs grep -l "jdbc"

관리자 페이지는 URL 추측이나 외부 접근이 가능하지 않도록 제한한다. IP 기반 접근 제한을 적용할 수 있다.

# Apache 설정 예시 (관리자 페이지 IP 제한)
<Directory "/var/www/html/admin">
    Order deny,allow
    Deny from all
    Allow from 192.168.1.0/24
</Directory>

WAS를 root 권한으로 실행하면 보안 위험이 커진다. 전용 계정으로 구동하도록 분리한다.

# Tomcat 전용 사용자 생성 및 구동 예시
$ useradd -m -d /opt/tomcat -s /bin/bash tomcat
$ chown -R tomcat:tomcat /opt/tomcat
$ su - tomcat -c "/opt/tomcat/bin/startup.sh"

HTTP 헤더에 서버 정보와 버전이 노출되면 공격자에게 유용한 정보가 될 수 있다. Apache에서는 서버 배너를 숨기는 설정을 적용할 수 있다.

# Apache 서버 배너 감추기
ServerTokens Prod
ServerSignature Off

계층 사이에 방어선을 둔다

심층 방어는 단일 보안 장치에 의존하지 않고, 각 계층 사이에 여러 방어선을 배치하는 전략이다. DMZ와 내부망을 분리하고, 계층 사이에 방화벽을 두며, WAF(Web Application Firewall)로 SQL 인젝션과 XSS 같은 웹 공격을 방어한다.

⤢✕Client외부 방화벽Web Application FirewallWeb Server내부 방화벽WAS내부 방화벽Database

Web Server에는 최신 보안 패치와 mod_security 같은 보안 모듈을 적용하고, HTTPS와 강력한 암호화 설정을 사용한다. 헤더 정보도 최소화한다.

WAS는 서비스 계정으로 실행하고, 세션 타임아웃과 보안 쿠키를 포함한 세션 관리 정책을 적용한다. 에러 메시지 노출을 제한하며 로깅과 모니터링을 강화한다.

DB Server는 방화벽으로 접근을 제한하고 저장 데이터와 전송 데이터를 암호화한다. 감사 로그를 활성화하고 주기적으로 보안 설정을 점검한다.

B 기업은 Web Server를 외부 방화벽 뒤에 배치하고 WAF로 웹 공격을 차단했으며, mod_security로 OWASP Top 10 취약점을 방어했다. WAS는 내부망에 두고 tomcat 전용 계정으로 실행했으며 세션 타임아웃을 15분으로 설정하고 로그 감사 시스템과 연동했다. DB Server는 이중 방화벽 뒤에 배치해 테이블·컬럼 단위 암호화, 계정별 최소 권한, DB 접근 감사 로그를 적용했다. 이 조치로 웹 공격 시도 차단률을 이전 대비 95%까지 향상시켰고, 보안 감사에서도 높은 평가를 받았다.

점검 주기를 운영에 포함한다

3 Tier 보안은 한 번의 설정으로 끝나지 않는다. 월간 취약점 스캔과 패치 관리, 분기별 침투 테스트, 반기별 보안 설정 검토, 연간 전체 시스템 보안 감사를 통해 상태를 계속 확인해야 한다.

외부 경계의 Web Server와 핵심 데이터를 보관하는 DB Server를 각각 관리하는 것만으로는 충분하지 않다. 계층별 보안 설정과 계층 간 접근 경계를 함께 점검해야 방어 체계가 유지된다.

3 Tier 아키텍처웹서버 보안DB 보안심층 방어접근통제