분기마다 돌아오는 보안 취약점 점검 결과가 팀 메일함에 도착했습니다. 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- open 상태 포트 목록을 먼저 확인 — 22(SSH), 80, 443, 8080 외 예상치 못한 포트(3306, 6379, 27017 등)가 보이면 즉시 차단 대상
- "filtered" 상태 포트 수가 0이면 방화벽이 없는 것 — 서버 직접 노출 환경. 외부에서 스캔 시 filtered 포트는 100개 이상이 정상
- open 포트가 있고 해당 서비스의 목적이 불분명하면 — ss -tlnp로 프로세스를 식별하고, systemctl status로 서비스 설명을 확인한 뒤 불필요하면 즉시 중지
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- ss -tlnp 출력에서 Local Address가 0.0.0.0:PORT인 것을 먼저 찾는다 — 127.0.0.1:PORT는 로컬 바인딩이라 외부 노출 없음. 0.0.0.0은 전체 인터페이스 노출
- 불필요 서비스 중지 후 ss -tlnp | grep 포트번호 결과가 완전히 빈 줄이어야 정상 — 한 줄이라도 남아있으면 다른 프로세스가 같은 포트를 쓰는 것
- systemctl stop(중지)과 disable(자동시작 해제)을 모두 적용해야 완전 차단 — stop만 하면 재부팅 후 서비스가 다시 열림. is-enabled로 disabled 확인 필수
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 요구사항이지만, 별도 정책으로 더 길게 잡는 조직도 있습니다.
보안 사고 대응 절차 — 탐지에서 재발 방지까지
보안 사고를 탐지하고 수습하는 5단계 — 탐지 · 격리 · 조사 · 복구
앞의 "보안 점검 결과 대응 6단계"는 정기 점검에서 나온 취약점을 계획적으로 닫는 흐름이었습니다. 하지만 침해나 이상 징후가 실시간으로 터지면 순서가 달라집니다 — 여유 있게 조치 계획을 세울 때가 아니라, 지금 벌어지는 사고를 탐지 → 격리 → 조사 → 복구로 수습해야 합니다. 이 절차가 몸에 배어 있지 않으면 격리보다 조사를 먼저 하다 피해가 번지거나, 서두르다 증거를 밟아 없앱니다.
[이상 신호] 경보 · 이상 로그 · 외부 신고
│
① 탐지 무엇이 · 언제 · 어디서 벌어지는지 포착
│
② 분류 · 심각도 영향 범위 · 데이터 민감도로 등급 매김
│
③ 격리 계정 잠금 · 세션 종료 · 네트워크 차단 ← 조사보다 먼저
│
④ 원인 조사 로그 · 포렌식으로 침입 경로 · 타임라인 복원
│
⑤ 복구 · 재발 방지 패치 · 재구축 · 모니터링 · 정책 보강
▼
[종결] 사고 보고서 + 증적으로 "닫힘"을 증명
각 단계가 하는 일과, 어긋났을 때의 증상:
| 단계 | 하는 일 | 여기서 어긋나면 |
|---|---|---|
| ① 탐지 | 알람 · 이상 로그 · 신고로 사고 인지 | 탐지 지연=확산된 뒤에야 인지 · 오탐 과다=진짜 신호가 묻힘 |
| ② 분류 · 심각도 | 범위 · 민감도로 등급 · 에스컬레이션 | 과소평가=대응 지연 · 과잉=불필요한 전체 셧다운 |
| ③ 격리 | 계정 · 세션 · 네트워크 차단으로 확산 차단 | 범위 좁으면 측면 이동 허용 · 넓으면 정상 서비스까지 중단 |
| ④ 조사 | 로그 · 포렌식으로 경로 · 타임라인 복원 | 증거 미보존(로그 위·변조 · 성급한 재부팅)=원인 규명 불가 |
| ⑤ 복구 · 재발 방지 | 패치 · 재구축 · 모니터링 보강 | 근본 원인 미해결=같은 경로로 재침해 |
사고 대응의 철칙은 "격리(③)가 조사(④)보다 먼저"라는 것입니다 — 원인을 다 밝힌 뒤 막으려다 그 사이 피해가 번집니다. 그리고 ④조사가 성립하려면 사고가 나기 전에 증거가 준비돼 있어야 합니다: 침해된 서버 안의 로그는 공격자가 지울 수 있으므로, 원격 수집 · append-only로 침해 호스트의 통제 밖에 사본을 둬야 합니다. 바로 이 ④의 전제 — 로그를 "믿을 수 있는" 증적으로 만드는 법 — 을 아래 심화에서 다룹니다.
심화 — 증적은 '있다'가 아니라 '믿을 수 있다'여야 한다
심화: 로그는 '보존'만으로 증적이 되지 않는다 — 무결성과 원격 수집
앞의 로그 보존 지적은 '얼마나 오래 두느냐'의 문제였습니다. 그런데 심사와 침해 조사가 정작 묻는 것은 그다음 질문입니다 — 그 로그를 믿을 수 있느냐. 보존 기간을 채워도 로그가 위·변조될 수 있으면 증거로서 가치가 없습니다.
- 로컬 로그는 서버가 뚫리는 순간 함께 무너진다: 침입자는 흔적을 지우려 접근 로그부터 편집·삭제합니다. root 권한이면
> access.log한 줄로 특정 구간을 날릴 수 있습니다. 보존 정책은 파일을 in-place로 지우는 것을 막지 못합니다. - 실시간으로 침해 호스트 밖에 내보낸다: 로그를 원격 수집 서버(원격
rsyslog·SIEM)로 실시간 전송해 두면, 그 서버가 뚫려도 독립 사본이 별도 위치에 남습니다. 이 사본이 사고 시 유일하게 믿을 수 있는 타임라인이 됩니다. - 로컬 로그는 append-only, 규제 대응은 WORM: 로컬 로그 파일을
chattr +a로 추가만 가능하게 잠그면 덮어쓰기·삭제가 어려워집니다. 감사·규제 요건이 강하면 object-lock(WORM) 스토리지에 보관해 지정 기간 동안 수정 자체를 불가능하게 합니다. - 시각이 맞아야 대조가 된다: 여러 서버·장비의 로그를 이어 붙여 사건을 재구성하려면 NTP로 시계가 맞아 있어야 합니다. 시각이 어긋나면 원격 사본과 로컬 로그의 순서를 신뢰할 수 없습니다.
- 한계: 로컬에만 있는 로그는 그 서버가 침해되는 순간 신뢰를 잃습니다. 그래서 성숙한 조직은 '보존됐는가'가 아니라 '감사받는 사람이 몰래 고칠 수 없는가'로 증적을 설계합니다.
상황: 이상 징후를 발견해 조사를 시작했는데, 하필 사고가 일어난 것으로 보이는 시간대의 Nginx·SSH 로그만 빈 줄입니다. 앞뒤 시간대 로그는 멀쩡하고 보존 설정도 정상입니다.
원인: 그 구간만 사라졌다는 것은 로그가 침해된 서버 안에서 수정·truncate됐다는 강한 신호입니다. 공격자가 권한을 얻은 뒤 자기 흔적이 담긴 구간을 지운 것입니다. 로그가 그 호스트에만 있었고 독립 사본이 없었기 때문에, 조작을 막지도 대조하지도 못했습니다. 보존 기간은 충분했지만 무결성이 없었던 것이 근본 원인입니다.
진단: 먼저 침해 호스트의 통제 밖에 있는 사본을 찾습니다 — 원격 수집 서버(SIEM)로 전송된 로그, 또는 앞단 LB·CDN처럼 다른 장비에 남은 접근 로그입니다(이들은 공격자가 지우기 어렵습니다). 동시에 auditd/ausearch로 로그 경로에 대한 unlink·truncate 이벤트와 실행된 명령을 조회하고, 파일 속성(lsattr)과 inode 변화를 확인합니다. 원격 사본과 로컬 로그의 시각이 NTP로 맞는지도 함께 봅니다.
해결: 지금 당장은 남아 있는 독립 사본으로 타임라인을 재구성해 조사를 이어갑니다. 재발 방지가 본질입니다 — 모든 서버 로그를 실시간으로 접근이 제한된 별도 수집 서버로 전송하고, 로컬 로그는 chattr +a로 append-only로 잠그며, 규제 대응이면 object-lock 스토리지에 보관합니다. logrotate는 copytruncate의 오용으로 로그가 잘리지 않도록 create 방식으로 점검합니다. 감사 대상자가 조용히 고칠 수 없는 로그라야 사고 때 진짜 증거가 됩니다.
실제 업무에서 이 흐름이 반복되는 상황:
분기 보안 점검은 결과서를 받는 순간부터 조치 기한 카운트다운이 시작됩니다. 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 심사가 없더라도 이 흐름대로 하면 나중에 감사 대응이 훨씬 수월해집니다.
명령어·단축키 빠른 참조
이 모듈에서 다룬 취약점 점검·불필요 포트 정리·패치 검증·로그 증적 명령을 실전 옵션과 함께 모았습니다.
| 명령어/단축키 | 용도 | 자주 쓰는 예 |
|---|---|---|
nmap -sT | 열린 포트 외부 시점 스캔 | nmap -sT -p 1-1024 localhost (불필요 포트 발견) |
ss -tlnp | 리스닝 포트·프로세스 내부 확인 | ss -tlnp | grep 631 (차단 후 빈 줄이면 정상) |
systemctl stop/disable | 불필요 서비스 중지+자동시작 해제 | systemctl disable cups → systemctl is-enabled cups |
yum update --security | OS 보안 패치만 적용 | RHEL/CentOS, Ubuntu는 apt-get upgrade |
rpm -q / openssl version | 실제 설치 버전으로 오탐 판별 | rpm -q openssl (backport면 버전 유지·패치됨) |
nginx -v / java -version | 미들웨어 버전 확인·전후 증적 | nginx -v > before.txt → 패치 → > after.txt |
grep PermitRootLogin | SSH root 직접 로그인 점검 | grep PermitRootLogin /etc/ssh/sshd_config → no |
chage -l / chage -M | 비밀번호 만료 정책 확인·설정 | chage -M 90 <계정> (90일 만료) |
usermod -s /sbin/nologin | 미사용 계정 로그인 차단 | usermod -s /sbin/nologin <계정> |
chattr +a / lsattr | 로컬 로그를 append-only로 잠금 | chattr +a /var/log/secure (덮어쓰기·삭제 차단) |
ausearch | auditd에서 로그 삭제·truncate 추적 | ausearch -f /var/log/secure -k log_tamper |
cat /etc/logrotate.d/nginx | 로그 보존 기간 증적 확인 | rotate 26 = 6개월(ISMS-P 기준) |
관련 모듈로 더 깊이:
- 계정 권한 관리, 보안 헤더, TLS 강화 실무 — 감사에서 지적되는 취약점을 평소 운영에서 예방하는 보안 기본기
- OS 보안 패치와 미들웨어 버전 업 절차 — 취약점 조치의 핵심인 OS·패키지 패치를 이력과 함께 관리하는 법
- 타임라인 분석과 재발 방지 대책 수립 — 보안 사고 발생 시 조치 내용을 보고서로 정리하는 법
다음 모듈에서는 파일, 설정, DB 백업 전략과 재해복구 기초를 다룹니다.