분기마다 돌아오는 보안 취약점 점검 결과가 팀 메일함에 도착했습니다. PDF 한 장에 취약점 40여 개, CVSS 점수, CVE 번호, 조치 기한. 어디서부터 시작해야 할지 막막합니다. 게다가 올해는 ISMS-P 인증 심사가 잡혀 있어서 점검 결과 대응 뿐 아니라 증적 자료까지 준비해야 합니다.
어떤 것을 먼저 처리해야 하는지, 개발팀과 어떻게 역할을 나눠야 하는지, 심사 때 어떤 서류가 필요한지 — 이 모듈에서 실무 흐름을 정리합니다.
- 1CVSS 점수를 해석하고 Critical/High/Medium/Low 우선순위를 정할 수 있다
- 2취약점 조치 범위를 인프라팀과 개발팀으로 분리해 협업할 수 있다
- 3OS 패치, 미들웨어 버전 업, 불필요 포트/계정 정리를 수행할 수 있다
- 4보안 점검 결과 대응 6단계 절차를 설명하고 따를 수 있다
- 5ISMS-P 심사 대응에 필요한 정책·절차·증적을 이해하고 준비할 수 있다
취약점 스캔 도구와 CVSS 점수
취약점 스캔 도구 — 어떻게 결과가 나오나
외부 보안 점검 업체로부터 결과서가 도착했습니다. CVE-2021-44228, CVSS 10.0, Critical — Log4Shell 취약점이 발견됐다는 내용입니다. 그런데 우리 서버가 실제로 취약한지, 이미 패치됐는지, 결과서가 어떻게 만들어진 것인지를 모르면 대응 우선순위를 정할 수 없습니다. 스캔 도구가 어떻게 동작하고 CVSS 점수가 무엇을 의미하는지 이해해야, 결과서를 받았을 때 흔들리지 않고 판단할 수 있습니다.
보안 점검 결과서가 어떻게 만들어지는지 알아야 대응 방향을 잡을 수 있습니다. 대부분의 기업 보안 점검은 자동화 스캔 도구가 서버를 스캔해 알려진 취약점(CVE)을 탐지한 결과입니다. 이 도구들이 내뱉는 숫자가 CVSS 점수입니다.
주요 스캔 도구:
| 도구 | 특징 | 주로 사용하는 곳 |
|---|---|---|
| Nessus | 상용, 가장 많이 쓰이는 엔터프라이즈 스캐너 | 대기업 보안팀, 외부 감사 |
| OpenVAS | 오픈소스 취약점 스캐너, Nessus 대안 | 중소기업, 내부 점검 |
| Nmap | 포트 스캔 + 서비스 버전 탐지 | 개방 포트 확인, 1차 점검 |
| OWASP ZAP | 웹 애플리케이션 취약점 전문 | 개발팀 SAST/DAST |
CVSS 점수 해석:
CVSS 점수 범위:
Critical 9.0 ~ 10.0 → 즉시 조치 (당일~72시간)
High 7.0 ~ 8.9 → 빠른 조치 (1~2주 내)
Medium 4.0 ~ 6.9 → 일정 내 조치 (1개월 내)
Low 0.1 ~ 3.9 → 장기 계획 내 처리
None 0.0 → 정보성 (조치 불필요)
점검 결과서를 받으면 Critical → High 순서로 정렬해 조치 계획을 잡습니다. Medium은 개수가 많아도 High를 먼저 끝내는 것이 원칙입니다.
조치 범위 분리 — 인프라팀 vs 개발팀
취약점은 누가 고치나 — 역할 분리가 핵심
보안 점검 결과를 받으면 가장 먼저 해야 하는 일이 "이게 우리 팀 건가, 개발팀 건가" 구분입니다. 잘못 가져가면 시간을 낭비하고 정작 담당자가 늦게 인지합니다.
인프라팀 조치 범위:
# 1. OS 패치 — 커널, 시스템 라이브러리 취약점
sudo yum update --security # RHEL/CentOS: 보안 패치만
sudo apt-get upgrade # Ubuntu: 전체 업그레이드
# 2. 미들웨어 버전 업 — Nginx, Tomcat, Java 등
nginx -v # 현재 버전 확인
java -version
sudo yum update nginx # 버전 업
# 3. 불필요 포트 차단 — 외부에 열려있는 서비스 포트
ss -tlnp # 현재 열린 포트 전체 확인
sudo systemctl stop <서비스> # 불필요 서비스 중지
sudo systemctl disable <서비스>
# 4. 기본 계정 정리
cat /etc/passwd | grep -v '/sbin/nologin\|/bin/false' | grep -v root
# 사용하지 않는 시스템 계정 확인
sudo usermod -s /sbin/nologin <계정명> # 로그인 차단
개발팀 조치 범위:
- 애플리케이션 라이브러리 취약점 (log4j, spring-framework 등 CVE)
- SQL 인젝션, XSS, CSRF 등 코드 취약점
- npm/pip 패키지 취약점 (npm audit, pip-audit)
- 하드코딩 비밀번호/API 키
- 안전하지 않은 파일 업로드 처리
판단 기준 — 어느 팀인지 헷갈릴 때:
| 취약점 내용 | 담당 팀 | 판단 근거 |
|---|---|---|
| OpenSSL 구버전 (CVE-XXXX) | 인프라팀 | OS/미들웨어 패키지 |
| Apache Tomcat 구버전 | 인프라팀 | 미들웨어 |
| Log4j 취약점 | 개발팀 | 애플리케이션 라이브러리 |
| SSH 기본 설정 (PermitRootLogin yes) | 인프라팀 | 서버 설정 |
| 웹 애플리케이션 XSS | 개발팀 | 코드 문제 |
| 불필요 포트 개방 (예: 8080 외부 노출) | 인프라팀 | 방화벽/서비스 설정 |
보안 점검 결과 대응 6단계
취약점 통보부터 조치 확인서까지
보안 점검 결과서를 받으면 가장 먼저 해야 하는 것은 "어디서부터 시작하지?"가 아니라 정해진 단계를 순서대로 밟는 것입니다. 영향도 분석 없이 바로 패치하면 오탐(False Positive)에 시간을 낭비하고, 조치 후 확인서를 남기지 않으면 심사에서 "증적 없음"으로 재지적을 받습니다. 6단계 절차는 Critical부터 시작해 증적 제출까지 빠뜨리는 게 없도록 설계된 실무 흐름입니다.
실무에서 보안 점검은 한 번으로 끝나지 않습니다. 결과 수신 → 조치 → 확인 → 심사 증적 제출의 루프가 반복됩니다. 이 6단계를 순서대로 따라가면 어느 조직에서든 통용됩니다.
1단계: 취약점 목록 수신
보안팀 또는 외부 감사기관에서 점검 결과서 수령
→ CVE 번호, CVSS 점수, 대상 시스템 정리
2단계: 영향도 분석 (우리 서버에 해당하는가)
→ 취약점이 실제 운영 중인 버전에 해당하는지 확인
→ False Positive 제거 (스캐너 오탐 있음)
3단계: 조치 계획 수립
→ Critical/High 먼저, 담당팀 분리
→ 조치 기한, 담당자, 방법 명시
4단계: 개발계(테스트 환경) 적용
→ 패치 후 서비스 정상 여부 확인
→ 호환성 문제 사전 검증
5단계: 운영 반영
→ 패치 적용 (변경 관리 절차 준수)
→ 서비스 기동 확인
6단계: 조치 확인서 제출
→ 변경 전/후 버전 캡처
→ 재스캔 또는 수동 확인 결과 첨부
영향도 분석 — 오탐(False Positive) 걸러내기:
# 스캐너가 "OpenSSL 1.0.2 취약"이라고 했을 때
openssl version # 실제 버전 확인
rpm -q openssl # RHEL: 패키지 버전 확인
# → 실제로 1.1.1 이상이면 오탐 → 근거를 명시해 제외 처리
실습 — Nmap 포트 스캔과 불필요 포트 정리
서버에서 실제로 열려 있는 포트를 확인합니다. -sT는 TCP 연결 스캔, -p 1-1024는 잘 알려진 포트 범위입니다. 보안 점검에서 "불필요 포트 개방" 지적을 받는 것들이 여기서 보입니다.
Starting Nmap 7.92
Nmap scan report for localhost (127.0.0.1)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
631/tcp open cups
위 예시에서 631번(CUPS 프린터 서비스)은 서버에 불필요한 경우가 많습니다. 보안 점검에서 자주 지적되는 항목입니다.
nmap -sT -p 1-1024 localhost- 의도적으로 오픈한 포트(22, 80, 443, 8080 등)만 표시되는가
- 예상치 못한 포트(3306, 6379, 27017 등)가 외부에서 접근 가능한 상태로 나타나지 않는가
- "filtered" 상태 포트가 방화벽에서 올바르게 차단되고 있는가
ss -tlnp는 TCP 리스닝 포트와 해당 프로세스를 함께 보여줍니다. nmap은 외부 시각이고, ss는 내부 시각입니다. 둘을 비교해서 실제로 어떤 서비스가 열었는지 특정합니다.
# 출력 예시
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1024))
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=2048))
LISTEN 0 5 127.0.0.1:631 0.0.0.0:* users:(("cupsd",pid=3100))
# 불필요 서비스 중지 및 자동 시작 해제
sudo systemctl stop cups
sudo systemctl disable cups
# 중지 후 재확인
ss -tlnp | grep 631
# 아무것도 출력되지 않으면 정상 차단
ss -tlnp- nmap 스캔 결과에서 서비스 목적이 없는 포트가 열려 있지 않은가
- ss -tlnp 출력에서 각 포트가 어떤 프로세스에 의한 것인지 식별됐는가
- 불필요 서비스 중지 후 ss -tlnp에서 해당 포트가 사라졌는가
- systemctl disable로 재부팅 후에도 서비스가 자동 시작되지 않게 됐는가
ISMS-P 보안 심사 대응
보안 심사에서 인프라팀이 준비해야 하는 것
ISMS-P(정보보호 및 개인정보보호 관리체계) 인증 심사는 "정책이 있는가" + "절차대로 했는가" + "증적이 있는가"를 봅니다. 기술적으로 완벽해도 서류가 없으면 지적받습니다.
인프라팀이 준비해야 하는 증적:
1. 보안 패치 관리 정책
- 패치 주기 (월별, 분기별)
- CVSS 등급별 조치 기한 기준
- 담당자 및 승인 라인
2. 패치 이력 (변경 관리 대장)
- 날짜, 대상 시스템, 변경 내용, 담당자, 확인자
- 변경 전/후 버전 캡처 포함
3. 취약점 조치 확인서
- 취약점 명칭, CVE 번호
- 조치 내용 및 조치일
- 조치 후 확인 결과 (재스캔 또는 버전 확인 캡처)
4. 접근 로그 보존
- SSH 접근 로그 (6개월 이상)
- Nginx/Apache 액세스 로그 보존 정책
- 로그 무결성 확보 방안
자주 지적되는 취약점 항목 (ISMS-P 단골):
| 취약점 항목 | 확인 명령 | 조치 방법 |
|---|---|---|
| 불필요 포트 개방 | nmap -sT localhost | 해당 서비스 중지 |
| 기본 계정 미삭제 | cat /etc/passwd | 계정 잠금 또는 삭제 |
| 구버전 OS/미들웨어 | nginx -v, java -version | 버전 업 |
| root 직접 SSH 허용 | grep PermitRootLogin /etc/ssh/sshd_config | PermitRootLogin no |
| 비밀번호 정책 미적용 | chage -l <계정명> | PAM 정책 설정 |
| 감사 로그 미보존 | ls -la /var/log/ | logrotate 정책 확인 |
# SSH root 로그인 차단 확인 및 조치
grep PermitRootLogin /etc/ssh/sshd_config
# PermitRootLogin yes 이면 취약 → yes를 no로 변경 후
sudo systemctl reload sshd
# 패스워드 만료 정책 확인
chage -l <계정명>
# Maximum number of days between password change: 99999 → 90일로 변경
sudo chage -M 90 <계정명>
트러블슈팅
원인: 보안 취약점 조치로 Tomcat이나 Java 버전을 올렸을 때, 기존 애플리케이션이 새 버전과 호환되지 않아 기동에 실패하는 경우입니다. 특히 Java 8 → 11, Tomcat 8 → 9 업그레이드 시 deprecated API나 설정 변경으로 자주 발생합니다.
# Tomcat 기동 실패 시 로그 확인
sudo tail -100 /opt/tomcat/logs/catalina.out
# 출력 예: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
# → Java 11에서 제거된 JAXB (JAX-B는 별도 의존성 필요)
# Java 버전 확인
java -version
# 조치 방법:
# 1. 개발팀에 호환성 확인 요청 (운영 반영 전에 개발계 먼저)
# 2. 개발계에서 문제 없으면 운영 반영
# 3. 개발계에서 오류나면 임시 롤백 후 개발팀 수정 후 재적용
# 임시 롤백 (버전 다운그레이드)
sudo yum downgrade tomcat
# 또는 이전 버전 패키지 직접 설치
sudo yum install tomcat-8.5.82
예방: 반드시 개발계(테스트 환경) 먼저 적용하고 서비스 정상 여부를 확인한 뒤 운영에 반영합니다. 조치 계획서에 "개발계 검증 완료" 항목을 필수로 포함시킵니다.
원인: 보안 점검에서 패치 조치는 다 했는데 심사에서 "로그가 없다"는 지적을 받는 경우입니다. Nginx/SSH 로그가 logrotate 정책으로 7일만 보존되거나, 로그 자체가 삭제된 경우입니다.
# 현재 로그 보존 정책 확인
cat /etc/logrotate.d/nginx
# rotate 4 → 4번 순환(4주) → ISMS-P 기준 6개월 미충족
# 로그 보존 기간 조정 (6개월 = 약 26주)
sudo vim /etc/logrotate.d/nginx
# rotate 4 → rotate 26 으로 변경
# weekly 유지 시 26주 = 6개월 확보
# SSH 로그 위치 확인
grep 'AuthLog\|auth.log' /etc/rsyslog.conf
ls -la /var/log/auth.log # Ubuntu
ls -la /var/log/secure # CentOS/RHEL
# 로그 보존 정책 문서화 (심사 증적)
# /etc/logrotate.d/* 설정 캡처 + 보존 기간 명시한 정책 문서 작성
예방: 로그 보존 정책을 문서로 만들어두고, logrotate 설정과 함께 심사 준비 체크리스트에 포함시킵니다. 6개월 이상 보존이 ISMS-P 요구사항이지만, 별도 정책으로 더 길게 잡는 조직도 있습니다.
실제 업무에서 이 흐름이 반복되는 상황:
분기 보안 점검은 결과서를 받는 순간부터 조치 기한 카운트다운이 시작됩니다. Critical은 72시간, High는 2주. 그런데 실무에서 가장 시간을 잡아먹는 건 기술적 조치가 아니라 "누가 할 건가" 논의와 "증적 어떻게 남길까" 고민입니다.
인프라팀이 주도적으로 할 수 있는 것:
# 1. 점검 결과서 수령 즉시 — 인프라/개발 분류 표 만들기
# 2. 인프라 영역부터 빠르게 처리 (포트 정리, OS 패치)
# 3. 변경 전/후 버전 캡처 습관화
nginx -v > /tmp/before_patch.txt
sudo yum update nginx
nginx -v > /tmp/after_patch.txt
# 4. 조치 확인서 템플릿 미리 만들어두기 (취약점명/CVE/조치내용/날짜/담당자)
ISMS-P 심사가 없더라도 이 흐름대로 하면 나중에 감사 대응이 훨씬 수월해집니다. 다음 모듈에서는 파일, 설정, DB 백업 전략과 재해복구 기초를 다룹니다.