네 번째 발걸음웹 서버의 공개 영역과 업무 실행 영역을 구분한다

웹 서버가 읽을 수 있는 파일이 모두 외부에 공개되어야 하는 것은 아닙니다. 문서 루트는 공개할 자료만 담고, 설정 파일·키·백업·개발 저장소를 그 안에 두지 않습니다. 디렉터리 목록 표시를 끄는 것은 파일 이름 노출을 줄이지만, 파일의 정확한 주소를 아는 요청까지 거부하는 기능은 아닙니다. 공개 영역에 비밀 파일이 있다면 목록 설정을 꺼도 본질적인 문제가 남습니다.

WAS는 외부 요청을 업무 코드로 해석하므로 관리자 기능과 일반 기능을 분리하고 필요 없는 예제·진단·배포 관리 기능을 제거합니다. 업로드 파일은 실행 코드와 다른 저장 영역에 두고, 정해진 제공 경로로만 읽게 합니다. 웹 프로세스의 쓰기 권한이 애플리케이션 실행 파일까지 닿으면 파일 업로드나 다른 결함이 코드 변경으로 이어질 수 있습니다. 운영체제 권한의 세부는 방향 2에 연결되지만, 어떤 경로가 공개되고 어떤 경로가 실행되는지는 서비스 설정에서 확인해야 합니다.

# nginx.conf의 http 블록 안에 두는 격리 실습용 server
server {
    listen 127.0.0.1:8443 ssl;
    server_name shop.example;
    ssl_certificate     /srv/lab/tls/server-chain.pem;
    ssl_certificate_key /srv/lab/tls/server-key.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    root /srv/lab/public;
    autoindex off;
    location / {
        try_files $uri $uri/ =404;
    }
    location /api/ {
        proxy_pass http://127.0.0.1:9000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

이 설정에서는 외부 인터넷이 아니라 loopback 주소에서 실습 연결을 받습니다. /api/ 요청은 같은 호스트의 WAS에 전달하고 그 외 요청은 공개 디렉터리에서 찾습니다. proxy_pass에 URI 부분을 붙이지 않았으므로 이 예에서는 /api/를 포함한 원래 요청 경로가 전달됩니다. 백엔드가 같은 호스트라 평문 loopback을 사용했으며, 별도 장비로 옮길 때는 내부 구간의 암호화·서버 검증과 망 접근 조건을 따로 정해야 합니다.

여기서는 신뢰하는 프록시 한 대가 가장 바깥 경계라는 가정으로 X-Forwarded-For를 실제 연결 주소로 덮어씁니다. 사용자가 보낸 헤더를 그대로 믿고 내부에서 관리자 주소 여부를 판단해서는 안 됩니다. 프록시가 여러 단계라면 어떤 상위 프록시를 신뢰하고 어느 헤더를 재작성하는지 전체 경로의 정책을 정합니다. 원격 주소와 사용자 식별자를 로그에 함께 남길 때도 전달된 값의 신뢰 출처를 구분합니다.

참고　[175] · [168] · [176]