보안장비는 실시간 원격 로그, 서버는 왜 요구하지 않을까?

 

 

전자금융기반시설 취약점 분석·평가를 몇 번 돌려보면 이상하게 걸리는 지점이 하나 있습니다.

정보보호시스템은 로그를 백업하는 것으로 끝나지 않고, 원격 서버와 실시간으로 연동하고 있는지까지 봅니다.

 

그런데 같은 점검표에서 서버로 넘어가면 그런 항목이 없습니다. 로깅이 켜져 있는지, 로그 파일 권한이 적절한지, 정기적으로 검토하는지, 보관 기간을 지키는지까지는 보는데 "어디에 보내고 있는가"는 묻지 않습니다.

그래서 두 가지 방향으로 의심이 갑니다.

정보보호시스템 쪽 요구가 과한 것인지, 아니면 서버는 백업만 되어 있으면 실시간 원격 관리가 필요 없는 것인지.

 

결론부터 말하면 둘 다 아닙니다. 이건 요구 수준의 문제가 아니라 점검 기준이 어떤 논리로 설계되었는가의 문제이고, 그 설계에는 명확한 의도와 명확한 공백이 함께 있습니다.

---

🎯 먼저 항목 차이를 정확히 봅시다

취약점 분석·평가 기준은 자산군별로 점검 카테고리가 나뉩니다. UNIX 서버, 윈도우 서버, 보안장비, 네트워크장비, DBMS, PC 등으로 나뉘고 "로그 관리" 카테고리는 대부분의 자산군에 존재합니다. 없는 게 아닙니다. 같은 이름의 카테고리인데 안에 들어 있는 항목의 성격이 다릅니다.

구분	서버 (UNIX·Windows)	정보보호시스템 (IPS·IDS·WAF·FW)
초점	로그를 남기고 있는가	남긴 로그를 지키고 보고 있는가
로깅 설정 적정성	✅	✅
로그 파일 접근 권한	✅	✅
정기 검토 및 보고	✅	✅
보관 기간 준수	✅	✅
원격 로그서버 실시간 연동	❌	✅

서

버 항목은 로컬 안에서 완결되는 통제로 구성되어 있습니다. 로그가 생성되고, 적절한 권한으로 보호되고, 주기적으로 검토되고, 정해진 기간 보관됩니다. 여기까지가 요구 범위입니다.

정보보호시스템은 여기에 한 단계가 더 붙습니다. 로그를 다른 곳으로 실시간으로 내보내라는 요구입니다.

 

---

🧩 왜 이렇게 나뉘어 있을까요?

기준을 만든 쪽 입장에서 생각해보면 답이 나옵니다.

① 대수 차이가 결정적입니다

자산군	통상 규모	전수 실시간 연동 시
정보보호시스템	수 대 ~ 수십 대	현실적
서버	수백 대 ~ 수천 대	에이전트 배포·스토리지·라이선스 부담 급증

규제는 모든 기관이 지킬 수 있는 하한선을 잡아야 합니다. 전 서버 실시간 연동을 의무화하면 규모가 작은 기관은 구조적으로 이행이 불가능해집니다. 지킬 수 없는 기준은 기준이 아니라 형식이 됩니다.

② 로그의 밀도가 다릅니다

보안장비 로그는 그 자체가 보안 이벤트입니다. 탐지·차단 기록이 곧 관제 대상입니다.

반면 서버 로그는 절대량의 대부분이 운영 로그이고, 보안 이벤트는 그중 일부입니다. 같은 비용을 들였을 때 보안장비 쪽이 단위당 효용이 훨씬 높습니다.

③ 길목에 통제점을 거는 설계입니다

이게 핵심입니다. 트래픽이 수렴하는 지점에 실시간 감시를 걸면, 적은 수의 통제점으로 넓은 범위를 커버할 수 있습니다.

서버 1,000대를 각각 감시하는 대신, 그 앞단을 지나는 IPS·WAF·방화벽 몇 대에 실시간 연동을 걸어 이상 징후를 잡아내는 구조입니다. 비용 효율 관점에서는 합리적인 선택이고, 실제 관제 조직도 이 구조로 돌아갑니다.

 

💡 정리하면 서버 로그 원격 연동이 불필요하다고 판단한 게 아니라, 최소 요구 수준을 어디에 걸 것인가를 두고 이행 부담이 가장 낮으면서 커버리지가 가장 넓은 지점을 고른 결과입니다.

---

🔍 그러면 보안장비 로그가 서버 로그를 대신할 수 있나요?

여기서 한 발 더 나간 해석이 나옵니다.

"어차피 서버로 들어가는 트래픽은 보안장비를 지나간다. 보안장비 로그를 실시간으로 원격 관리하고 있으면, 사실상 서버 로그를 원격 관리하는 것과 비슷하게 볼 수 있지 않나?"

 

설계 의도를 읽은 것으로는 정확합니다. 그런데 대체 가능성으로 넘어가면 성립하지 않습니다.

둘은 관측 위치가 다르고, 따라서 보이는 것이 다릅니다.

 

구분	보안장비 로그	서버 로그
관측 위치	네트워크 경유 구간	시스템 내부
기록 내용	패킷·세션·시그니처 매칭 결과	인증 성공/실패, 권한 상승, 프로세스 실행, 파일 변경
암호화 트래픽	복호화 미적용 시 내용 관측 불가	해당 없음
장비 미경유 구간	관측 불가	관측 가능
사고 대응 역할	침입 시도 탐지	침입 성공 이후 행위 추적

 

보안장비가 구조적으로 못 보는 것들

사례	안 잡히는 이유
내부자가 콘솔로 접속해 권한 오용	네트워크 경유 자체가 없음
SSH 세션 안에서 실행한 명령	복호화 미적용 시 페이로드 불가시
정상 계정으로 정상 포트 접근	시그니처에 걸릴 이유가 없음
관리망·VPN·서버 간 동서 트래픽	장비를 지나지 않는 경로
침입 성공 후 계정 생성·로그 삭제	시스템 내부 행위

 

마지막 항목이 특히 중요합니다. IPS가 공격 시도를 탐지한 로그는 원격 서버에 안전하게 남아 있습니다. 그런데 그 공격이 성공한 뒤 서버 안에서 무슨 일이 벌어졌는지는 서버 로그에만 있습니다. 그리고 그 서버 로그는 지금 공격자 권한 아래 있습니다.

 

---

⚠️ 그래서 기준이 덮지 못하는 구간이 생깁니다

정리하면 이렇습니다.

침해 단계	보안장비 로그	서버 로그	실시간 원격 보존 여부
정찰·스캔	✅	△	✅
침입 시도	✅	△	✅
침입 성공	✅	✅	✅
권한 상승	❌	✅	❌
내부 이동	△	✅	❌
흔적 삭제	❌	✅	❌

침해 대응에서 가장 중요한 구간이 원격 보존 요구 밖에 있습니다.

백업이 있으니 괜찮지 않냐고 할 수 있는데, 백업과 실시간 원격 전송은 목적이 다릅니다.

 

구분	정기 백업	실시간 원격 전송
목적	가용성·복구	무결성·위변조 방지
공격자가 로그를 지웠을 때	마지막 백업 이후 구간 소실	이미 원격에 기록되어 보존
서버를 장악당했을 때	백업 파일도 동일 권한으로 접근 가능	별도 신뢰 경계에 저장
사고 대응	사후 복원	실시간 탐지·상관분석

 

서버 root 권한을 잡은 공격자에게 로컬 로그와 로컬에 마운트된 백업은 같은 대상입니다. 백업은 하드웨어 장애와 실수를 막아주지, 의도적인 삭제를 막아주지 않습니다.

 

⚠️ 위험 기반으로 보면 순서가 뒤집혀 있습니다. 보안장비는 공격자가 직접 장악하는 경우가 드물고, 서버는 침해의 최종 목적지입니다. 로그 무결성이 더 절실한 쪽은 오히려 서버입니다. 기준의 합리성에 대한 지적이 계속 나오는 이유이기도 합니다.

---

🚫 보고서에 이렇게 쓰면 나중에 발목 잡힙니다

점검 결과를 정리하면서 표현 하나만 조심하시면 됩니다.

표현	문제
"서버 로그 원격 연동은 과도한 요구"	규제가 불필요하다고 판단했다는 뜻으로 읽힙니다. 나중에 SIEM 확대나 중요 서버 연동을 추진할 때 본인이 쓴 문장이 반대 근거로 돌아옵니다
"기준에 없으므로 문제없음"	점검 기준은 하한선입니다. 없다는 것과 필요 없다는 것은 다릅니다
"기준서는 이행 부담을 고려해 최소 요구 수준을 보안장비에 설정한 것"	사실 관계만 진술. 상위 통제를 추가할 여지를 남깁니다

 

"기준에 없다"와 "필요 없다"를 문서상 분리해 두세요. 이 한 줄 차이가 다음 해 개선 과제를 올릴 때 큰 차이를 만듭니다.

그리고 점검 결과 처리는 이렇게 갑니다.

 

대상	판정
정보보호시스템에 원격 연동 미적용	취약 — 점검 항목 근거 있음
서버에 원격 연동 미적용	취약 판정 불가 — 항목 자체가 없음
서버 원격 연동	개선 권고로 별도 기재

 

권고 사유를 규정이 아니라 위험 논리로 세우는 게 방어하기 좋습니다. 가장 설득력 있는 문장은 이겁니다.

 

보안장비 로그로는 침입 시도까지만 확인 가능하며, 침해 성공 이후 서버 내부에서 발생한 행위의 추적이 불가능하다. 해당 기록은 공격자 권한 하에 놓인 로컬 로그에만 존재한다.

---

📋 현실적인 3계층 적용안

전 서버 확대는 비용과 스토리지 부담이 커서 한 번에 밀기 어렵습니다. 계층을 나눠 단계 적용하는 안으로 올리면 통과 가능성이 훨씬 높습니다.

 

계층	대상	요구 수준	근거
1계층	정보보호시스템 (IPS·IDS·WAF·FW)	실시간 원격 연동 필수	점검 기준 항목
2계층	중요 서버 (인증·결제·DB 연동·관리 서버)	실시간 원격 연동 권고	위험 기반 자체 판단
3계층	일반 서버	로컬 기록 + 정기 백업·검토	점검 기준 항목

 

2계층 범위를 먼저 정의하는 게 핵심입니다. 여기서 "중요 서버"를 어떻게 뽑느냐가 보고의 성패를 가릅니다. 자산 등급 분류가 이미 있다면 그걸 쓰고, 없다면 개인정보·금융거래정보 처리 여부와 외부 노출 여부두 축으로 잘라도 충분합니다.

 

기술 구현 선택지

방식	대상	비고
rsyslog / syslog-ng 원격 전송	Linux·UNIX	OS 기본 제공, 추가 비용 없음. TLS 전송 설정 권장
Windows Event Forwarding (WEF)	Windows	에이전트 없이 수집기로 전달
Filebeat · Fluent Bit 등 에이전트	혼합 환경	파싱·필터링 유연. 에이전트 관리 부담 발생
SIEM 커넥터	이미 SIEM 보유 시	라이선스가 EPS·용량 기준이면 비용 산정 먼저

💡 전송량이 걱정되면 전체 로그를 보내지 말고 인증·권한 상승·감사 로그만 선별 전송하는 것부터 시작하세요. auth.*, authpriv.*, sudo, Windows 보안 이벤트 4624·4625·4672·4720·4726·1102 정도만 잡아도 침해 추적의 상당 부분이 커버됩니다.

---

점검 전 확인 체크리스트

확인 항목
정보보호시스템 전체가 원격 로그서버로 실시간 전송 중인가	☐
전송 구간이 암호화(TLS)되어 있는가	☐
원격 로그서버가 점검 대상 자산과 다른 신뢰 경계에 있는가	☐
로그 수집 누락 장비가 없는지 대사(對査)했는가	☐
서버 로그 보관 기간이 규정 요구를 충족하는가	☐
서버 로그 백업본이 원본과 동일한 권한 아래 있지는 않은가	☐
중요 서버 범위가 문서로 정의되어 있는가	☐
중요 서버의 감사 로그가 원격으로 전송되고 있는가	☐
로그 시각 동기화(NTP)가 전 자산에 적용되어 있는가	☐

 

마지막 항목은 자주 놓치는데, 시각이 안 맞으면 원격에 모아도 상관분석이 안 됩니다. 로그를 모으는 것보다 먼저 확인해야 할 전제 조건입니다.

---

💬 자주 나오는 질문

Q. 서버 로그가 원격 연동 안 되어 있으면 취약으로 잡아야 하나요?

아닙니다. 점검 항목에 근거가 없으므로 취약 판정의 근거가 없습니다. 개선 권고로 별도 기재하시고, 근거는 규정이 아니라 침해 대응 관점의 위험 논리로 쓰세요.

Q. 정보보호시스템에 요구하는 게 과한 건 아닌가요?

과하지 않습니다. 보안장비 로그는 사고 발생 시 1차 증거입니다. 장비 자체가 침해되거나 설정이 변경되면 로컬 로그의 신뢰성이 무너지므로, 별도 신뢰 경계에 실시간으로 보존하는 것이 타당합니다. 대수도 많지 않아 이행 부담도 낮습니다.

Q. 백업 주기를 짧게 가져가면 원격 연동을 대체할 수 있나요?

대체되지 않습니다. 주기를 아무리 줄여도 공백 구간은 남고, 더 중요한 건 백업본이 원본과 같은 권한 경계 안에 있으면 삭제 대상이 똑같다는 점입니다. 관건은 주기가 아니라 저장 위치의 신뢰 경계 분리입니다.

Q. SIEM이 없는데 어떻게 시작하나요?

SIEM 없이도 됩니다. 별도 리눅스 서버 한 대에 rsyslog 수집기를 올리고 중요 서버만 붙이는 것부터 시작할 수 있습니다. 이때 수집기는 다른 네트워크 세그먼트에 두고, 서버 쪽 계정으로 접근되지 않도록 분리하는 게 핵심입니다. 그것만 지켜도 원격 보존의 목적은 달성됩니다.

Q. 전 서버에 적용하라고 요구가 들어오면요?

로그량과 스토리지 산정 먼저 하시길 권합니다. 일 단위 로그량 × 보관 기간으로 필요 용량이 나오고, SIEM 라이선스가 EPS 기준이면 여기서 비용이 크게 뜁니다. 선별 전송 + 중요 서버 우선으로 범위를 조정한 대안을 함께 올리는 게 현실적입니다.

Q. 클라우드 환경은 어떻게 보나요?

관리형 로깅 서비스(CloudWatch Logs, Cloud Logging 등)를 쓰고 있다면 이미 원격 보존 구조에 해당합니다. 다만 로그 삭제 권한을 가진 IAM 주체가 서버 워크로드와 분리되어 있는지를 확인해야 합니다. 같은 역할로 로그 삭제가 가능하면 신뢰 경계가 분리되지 않은 것과 같습니다.

---

🎉 정리

1. 항목이 없는 게 아니라 범위가 다릅니다. 서버에도 로그 관리 카테고리는 있고, 로컬 안에서 완결되는 통제까지가 요구 범위입니다.
2. 길목에 통제점을 거는 설계입니다. 대수와 이행 부담을 고려해 최소 요구 수준을 보안장비에 걸었고, 규제 하한선으로는 합리적인 선택입니다.
3. 그렇다고 대체되지는 않습니다. 보안장비는 네트워크 경유 구간을, 서버는 시스템 내부를 봅니다. 관측 위치가 다르면 보이는 것도 다릅니다.
4. 덮이지 않는 구간은 권한 상승 이후입니다. 침해 대응에서 가장 중요한 구간이 원격 보존 요구 밖에 있습니다.
5. 백업은 원격 전송을 대신하지 못합니다. 가용성 통제와 무결성 통제는 목적이 다릅니다.
6. "기준에 없다"와 "필요 없다"를 분리해서 쓰세요. 문서에 남긴 판단이 다음 해 개선 과제의 발목을 잡습니다.
7. 중요 서버부터 단계 적용하세요. 전 서버 확대는 비용으로 막히고, 범위를 좁힌 안은 통과됩니다.

점검 기준은 최소 수준을 정의한 문서이지, 우리 조직의 목표 수준을 정의한 문서가 아닙니다. 항목이 없는 자리를 발견했을 때 "안 해도 되는구나"로 닫지 않고 "왜 없을까"를 한 번 물어보면, 거기서 그 해의 개선 과제가 하나 나옵니다. 이번 건이 딱 그런 경우였습니다.

---

🔗 참고 자료

• 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드 — KISA — 자산군별 점검 카테고리 구성
• 주요정보통신기반시설 취약점 분석·평가 기준 — 법제처 — 행정규칙 원문
• 취약점 분석·평가 — 금융보안원 — 전자금융기반시설 평가기준 안내서 배포처