인터넷이 차단된 서버도 해킹된다 — 망분리 환경에서 로그 분석과 SOC가 반드시 필요한 이유

문제의 본질
“외부 인터넷이 차단되어 있으니 해킹될 수 없다”는 판단은
외부에서 서버로 직접 들어오는 경로만 본 것입니다.

망분리 서버의 실제 위험은 관리자 PC, 계정, 유지보수 경로, 허용된 포트, 내부 연계 시스템과 서버 내부 행위에서 시작됩니다.

먼저 요점만 정리하면

• 망분리는 공격 경로를 줄이는 통제이지, 침해 가능성을 없애는 통제가 아닙니다
• 외부 인터넷이 차단되어도 관리자 PC 감염, 계정 탈취, 유지보수 유입, 정책 오류, 내부 횡적 이동은 발생할 수 있습니다
• 실제로 강한 망분리와 내부망 통제를 운영하던 SK텔레콤과 법원행정처 전산망에서도 외부 접점, 관리망, 허용된 통신 경로와 탈취된 계정을 통해 중요 내부 시스템으로 공격이 확산됐습니다
• 망분리 의무가 적용되는 금융권도 예외가 아닙니다. 롯데카드와 SGI서울보증에서는 실제 해킹·랜섬웨어 사고가 발생했으며, 롯데손해보험에서도 노후 서버와 전산장애·보안관리 체계의 미흡 사항이 지적됐습니다
• 이러한 사례는 망분리 정책의 존재만으로 안전을 판단할 수 없으며, 허용된 연결과 서버 내부 행위를 지속적으로 검증해야 한다는 사실을 보여줍니다
• 이때 네트워크 경계만 봐서는 침해 여부를 판단하기 어렵고, 로그인·프로세스·권한·파일·네트워크·감사 로그를 확인해야 합니다
• 로그를 저장하는 것만으로는 부족하며, 여러 시스템의 이상 징후를 연결해 공격 여부를 판별하고 대응하는 SOC(Security Operations Center) 가 필요합니다
• PLURA 로그 전송은 일반 인터넷을 개방하는 방식이 아니라, 지정 목적지·포트·프로토콜만 최소 허용하는 구조로 설계할 수 있습니다
• 완전한 물리적 단절망이라면 클라우드 실시간 SOC가 자동으로 가능한 것이 아니므로, 내부 중계·통제된 반출·온프레미스 관제 구조를 별도로 설계해야 합니다

1) 망분리는 ‘안전 선언’이 아니라 ‘공격 경로 축소’입니다

망분리는 중요 시스템을 일반 인터넷망이나 업무망과 분리하여
공격자가 곧바로 접근하기 어렵게 만드는 중요한 보안 통제입니다.

그러나 망분리가 보장하는 것은 어디까지나
일부 네트워크 경로의 차단 또는 제한입니다.

다음까지 자동으로 보장하지는 않습니다.

• 관리자 단말이 악성코드에 감염되지 않았다는 것
• 관리자 계정과 비밀번호가 탈취되지 않았다는 것
• 방화벽 정책이 항상 정확하게 유지된다는 것
• 유지보수 파일과 프로그램이 안전하다는 것
• 내부 연계 서버가 침해되지 않았다는 것
• 정상 계정으로 실행된 명령이 모두 정상이라는 것
• 서버 내부에 백도어가 설치되지 않았다는 것
• 과거에 이미 침투한 공격자가 남아 있지 않다는 것

망분리는 신뢰의 근거가 아니라, 반드시 검증해야 할 하나의 경계 통제입니다.

특히 지상국, 생산망, 제어망, 통신 코어망, 연구망처럼
가용성과 기밀성이 중요한 환경일수록
“인터넷이 차단되어 있다”는 이유로 서버 로그 분석을 제외해서는 안 됩니다.

오히려 외부에서 보이는 트래픽이 적기 때문에
서버 내부에서 무슨 일이 일어나는지 확인할 수 있는 로그의 중요성이 더 커집니다.

2) 망 차단 환경에서도 발생할 수 있는 다섯 가지 침해 경로

2-1. 내부 관리자 PC 감염 또는 계정 탈취

관리자는 점검, 배포, 설정 변경, 장애 대응을 위해
망분리 서버에 접속할 수 있는 권한을 가집니다.

공격자가 관리자 PC를 감염시키거나 계정을 탈취하면
방화벽을 외부에서 직접 뚫지 않고도
정상 관리 경로를 이용해 중요 서버에 접근할 수 있습니다.

이 경우 네트워크 장비에는
“허용된 관리자 IP에서 정상 계정으로 접속한 기록”만 남을 수 있습니다.

그러나 서버 로그를 보면 다음과 같은 차이를 확인할 수 있습니다.

• 평소와 다른 시간대의 로그인
• 사용하지 않던 계정의 접속
• 짧은 시간 동안 여러 서버로 확산되는 접속
• 로그인 직후 실행된 셸 또는 PowerShell 명령
• 비정상적인 권한 상승과 계정 생성
• 관리 목적과 무관한 파일 압축·복사·전송

2-2. 방화벽·네트워크 접근제어 정책 오류

망분리는 정책이 정확할 때만 유효합니다.

운영 과정에서는 다음과 같은 예외가 발생할 수 있습니다.

• 장애 대응을 위해 포트를 임시 개방
• 테스트 후 임시 정책을 원복하지 않음
• 목적지 또는 출발지 대역을 과도하게 허용
• 신규 시스템 연동 과정에서 우회 경로 생성
• 관리망과 중요망 사이의 통신 규칙 누적
• 방화벽 변경 이력과 실제 적용 정책 불일치

공격자는 새로 방화벽을 만들 필요가 없습니다.
이미 존재하는 허용 포트와 연계 경로를 찾아 이용하면 됩니다.

2-3. 유지보수 파일·프로그램·이동식 저장장치 유입

인터넷이 차단된 시스템도
패치, 프로그램 설치, 백업 복구, 장비 설정, 로그 반출을 위해
외부 파일이 들어옵니다.

이 과정에서 다음이 유입될 수 있습니다.

• 악성코드가 포함된 설치 파일
• 변조된 업데이트 패키지
• 감염된 USB 또는 외장 저장장치
• 협력업체가 제공한 점검 도구
• 공격 코드가 삽입된 스크립트
• 정상 프로그램으로 위장한 원격제어 도구

따라서 파일이 어떤 경로로 들어왔는지만 보는 것이 아니라,
서버에서 실제로 어떤 프로세스를 만들고 무엇을 변경했는지를 분석해야 합니다.

2-4. 정상 관리자 계정의 오용과 과도한 권한

침해사고는 항상 취약점 공격으로 시작하지 않습니다.

공격자가 정상 계정을 확보했거나
내부 사용자가 권한을 오용하면
보안 장비를 우회할 필요 없이 정상 기능으로 다음 행위를 수행할 수 있습니다.

• 중요 설정 파일 열람·변경
• 신규 계정 또는 SSH 키 등록
• 서비스 중지와 보안 기능 해제
• 스케줄러·서비스·시작 프로그램 등록
• 데이터 압축과 대량 복사
• 감사 로그 삭제 또는 설정 변경
• 인접 서버로의 원격 접속

이때 필요한 것은 “계정이 성공적으로 로그인했다”는 기록이 아니라,
로그인 후 무엇을 했는지 설명할 수 있는 감사 로그입니다.

2-5. 내부 시스템 침해 후 횡적 이동

망분리 서버가 외부 인터넷과 직접 통신하지 않더라도
업무망, 관리망, 백업망, 모니터링망, 배포망, 인증 서버와 연결되어 있을 수 있습니다.

공격자는 상대적으로 취약한 내부 시스템을 먼저 장악한 뒤
다음 경로로 중요 서버에 접근할 수 있습니다.

관리자 PC 또는 연계 서버 침해
        ↓
계정·인증정보 확보
        ↓
관리망 또는 허용 포트 이용
        ↓
망분리 중요 서버 접속
        ↓
권한 상승·백도어 설치·자료 수집

이것이 바로 횡적 이동(Lateral Movement) 입니다.

망분리는 외부와 내부를 나누지만,
이미 내부에 들어온 공격자의 이동까지 자동으로 차단하지는 못합니다.

3) 외부 트래픽이 없을수록 서버 내부 로그를 봐야 합니다

외부 인터넷 통신이 제한된 서버에서는
경계 방화벽이나 NDR만으로 안전 여부를 판단하기 어렵습니다.

공격자가 정상 관리 경로를 이용하거나
이미 내부에 거점을 확보했다면
외부에서 들어오는 명확한 공격 트래픽이 보이지 않을 수 있기 때문입니다.

이때 확인해야 할 핵심 데이터는 다음과 같습니다.

인터넷이 없다는 것은 공격자가 없다는 뜻이 아닙니다.
공격자를 확인해야 할 관측 지점이 네트워크 외부에서 서버 내부로 이동했다는 뜻입니다.

NIST는 로그 관리가 보안 사고 식별·조사와 운영 문제 확인을 지원한다고 설명하며,
CISA도 위협 탐지와 대응을 위한 이벤트 로깅 기준과 중앙 분석의 중요성을 강조합니다. (NIST, CISA)

4) 사례 1 — 법원행정처: 망분리 사이의 ‘허용된 연결’이 공격 경로가 됐다

법원행정처 전산망 해킹 사건은
“내부망과 외부망을 나누었다”는 사실만으로는 충분하지 않다는 점을 보여줍니다.

공개된 사건 분석에 따르면 공격자는 다음 흐름을 이용한 것으로 정리됩니다.

1. 외부망용 PC 여러 대를 먼저 침해
2. 외부망과 내부 스캔 서버 사이에 열려 있던 통신 경로 악용
3. 내부 스캔 서버를 거점으로 전자소송 서버 접근
4. 소송 관련 문서를 장기간 수집
5. 별도 포트를 통해 외부로 데이터 전송

분석 자료에서는 내부·외부망 간 포트 개방,
미흡한 계정·비밀번호 관리와 장기간 미탐지가 주요 문제로 제시됩니다. (PLURA 법원행정처 사례)

여기서 중요한 것은
“망분리가 없었다”는 단순한 결론이 아닙니다.

실제 교훈은 다음과 같습니다.

• 분리된 망 사이에도 업무상 허용된 통신 경로가 존재할 수 있음
• 외부망 PC가 내부망 침투의 중간 거점이 될 수 있음
• 연계 서버는 양쪽 망을 연결하는 고위험 자산임
• 포트가 허용되면 그 안에서 전달되는 명령과 파일을 추가로 봐야 함
• 장기간 데이터 수집과 유출은 서버·계정·파일 로그를 분석해야 식별 가능함

즉, 망분리 정책만 확인할 것이 아니라
허용된 연결을 통해 실제로 어떤 행위가 발생했는지를 지속적으로 감시해야 합니다.

5) 사례 2 — SKT: ‘로그가 있었지만 충분히 보지 않은 것’의 대가

SKT 침해사고는 망분리·관리망 환경에서
로그 분석과 SOC가 왜 필요한지를 더욱 직접적으로 보여줍니다.

정부 최종 조사 결과에 따르면 공격자는
외부 인터넷 연결 접점이 있는 시스템 관리망 서버에 침투한 뒤,
서버에 평문으로 저장된 계정정보를 이용해 다른 관리 서버와
음성통화인증(HSS) 관리서버로 이동했습니다.

이후 HSS 관리서버와 음성통화인증 서버에 BPFDoor가 설치됐고,
유심정보는 외부 인터넷 연결 접점이 있는 다른 서버를 거쳐 유출됐습니다. (정부 최종 조사결과)

특히 주목해야 할 내용은 로그 점검 실패입니다.

정부는 SKT가 2022년 비정상 로그인 정황을 발견하고도
해당 서버의 로그기록 6개 중 1개만 확인했다고 밝혔습니다.

그리고 나머지 5개 로그를 함께 점검했다면
당시 이미 BPFDoor에 감염된 HSS 관리서버에
공격자가 접속한 사실을 확인할 수 있었을 것이라고 설명했습니다. (정부 최종 조사결과)

이 사례는 세 가지를 분명하게 보여줍니다.

첫째, 로그가 존재하는 것과 로그를 분석하는 것은 다릅니다

로그 파일이 서버에 남아 있어도
누군가 필요한 범위 전체를 확인하지 않으면 탐지가 되지 않습니다.

둘째, 단일 로그만 보면 공격 흐름을 놓칠 수 있습니다

로그인 기록 하나만으로는 의미가 약할 수 있습니다.

그러나 다음이 연결되면 침해 가능성이 커집니다.

비정상 로그인
    ↓
관리 서버 간 연속 접속
    ↓
권한 있는 계정 사용
    ↓
의심 프로세스·백도어 실행
    ↓
HSS 접근과 데이터 수집
    ↓
외부 연결 서버를 통한 유출

셋째, 망분리 환경일수록 SOC의 판단이 필요합니다

관리망, HSS, 인증 서버, 외부 연결 접점의 로그가
서로 다른 시스템에 흩어져 있으면
개별 운영자는 전체 공격 흐름을 보기 어렵습니다.

이를 시간순으로 연결하고
“정상 운영인지, 침해 확산인지” 판단하는 역할이 바로 SOC입니다.

SKT 사건은 로그가 없어서만 놓친 사고가 아닙니다.
로그를 충분한 범위로 확인하고 연결해 판단하는 운영 체계가 작동하지 않은 사고이기도 합니다.

PLURA-Blog의 SKT 기술 분석에서는
웹셸·RCE, 권한 상승, BPFDoor 설치, HSS 접근과 데이터 탈취 흐름을 가설적으로 재구성하고,
웹 로그와 OS 감사 로그를 함께 봐야 한다고 설명합니다. (PLURA SKT 분석)

6) 왜 로그 수집만으로 부족하고 SOC가 필요한가

로그 수집과 SOC는 같은 의미가 아닙니다.

• 로그 수집은 서버에서 일어난 일을 기록하는 것입니다
• 로그 분석은 기록에서 이상 징후를 찾는 것입니다
• SOC는 이상 징후를 검증하고 공격 흐름을 판단하여 대응하는 운영 체계입니다

로그만 쌓아 두면 사후 조사 자료는 될 수 있지만,
진행 중인 공격을 멈추게 하지는 못합니다.

SOC가 필요한 이유는 다음과 같습니다.

6-1. 정상과 비정상을 구분해야 하기 때문

관리자가 sudo를 실행했다고 모두 공격은 아닙니다.

그러나 다음 조건이 겹치면 위험도가 달라집니다.

• 평소 접속하지 않던 계정
• 새벽 시간 원격 로그인
• 로그인 직후 권한 상승
• 임시 디렉터리 실행 파일 생성
• 감사 로그 중지
• 인접 서버로 연속 접속

SOC는 개별 이벤트가 아니라
행위의 맥락과 순서를 분석합니다.

6-2. 여러 서버와 보안 장비의 로그를 연결해야 하기 때문

망분리 환경의 공격은 한 대의 서버에서 끝나지 않습니다.

관리자 PC, 점프 서버, 인증 서버, 업무 서버, DB 서버, 방화벽 로그를
같은 시간축에서 연결해야 실제 이동 경로가 보입니다.

CISA의 SIEM·SOAR 지침도
중요 로그를 우선 수집하고 중앙에서 분석할 수 있도록 설계해야 한다고 권고합니다. (CISA SIEM·SOAR 지침)

6-3. 탐지 후 즉시 대응해야 하기 때문

공격은 다음 단계로 빠르게 진행됩니다.

계정 탈취 → 로그인 → 권한 상승 → 백도어 설치 → 내부 확산 → 자료 유출

SOC는 탐지 이벤트를 확인한 뒤 다음 조치를 수행해야 합니다.

• 접속 계정 잠금 또는 비밀번호 변경 요청
• 의심 세션과 프로세스 종료
• 공격 IP·내부 출발지 차단
• 감염 의심 서버 격리
• 관련 서버와 계정으로 조사 범위 확대
• 포렌식 자료 보존
• 책임자 통보와 사고 대응 절차 개시

로그가 있어도 대응 주체가 없으면
공격은 계속 진행될 수 있습니다.

6-4. 사고 당시의 증거를 보존해야 하기 때문

사고가 발생하면 다음 질문에 답해야 합니다.

• 최초 접근 시점은 언제인가
• 어떤 계정이 사용됐는가
• 어떤 명령이 실행됐는가
• 어떤 파일이 생성·변경·삭제됐는가
• 어느 서버까지 확산됐는가
• 어떤 데이터가 조회·복사·유출됐는가
• 보안 통제가 언제 우회 또는 중지됐는가

이 질문에 답할 수 있는 핵심 근거가 로그입니다.

로그가 없거나 일부만 남아 있으면
침해 범위와 유출 여부를 확인하지 못하는 구간이 생깁니다.

SKT 정부 조사에서도 방화벽 로그가 남아 있지 않은 기간에는
정보유출 여부를 확인할 수 없었다고 밝혔습니다. (정부 최종 조사결과)

7) 망분리 중요 서버에서 반드시 수집해야 할 로그

모든 로그를 무조건 많이 수집하는 것이 목적은 아닙니다.

중요한 것은 공격 흐름을 설명할 수 있는
핵심 보안 로그를 빠짐없이 수집하고 연결하는 것입니다.

Linux 서버

• auth.log, secure 등 로그인·인증 로그
• auditd 기반 명령 실행·파일 접근·권한 변경 로그
• sudo, su, SSH 접속과 키 변경
• 프로세스 생성과 부모·자식 관계
• /tmp, /var/tmp, /dev/shm, /var/run 실행 파일 생성
• cron, systemd 서비스·타이머 등록
• 계정·그룹·권한 변경
• 비정상 네트워크 연결과 원격 전송
• 로그 삭제·감사 정책 변경
• 보안 에이전트 중지 또는 설정 변경

Windows 서버

• 로그인 성공·실패와 특권 로그인
• 프로세스 생성과 명령줄
• PowerShell 실행과 Script Block
• 서비스·작업 스케줄러 등록
• 사용자·그룹·권한 변경
• 원격 데스크톱·WinRM·SMB 접속
• 보안 로그 삭제 또는 감사 정책 변경
• 실행 파일·스크립트 생성
• Defender 또는 보안 에이전트 상태 변경
• 비정상 외부·내부 네트워크 연결

공통 인프라

• 방화벽 정책 변경과 허용·차단 로그
• VPN·점프 서버·PAM 접속 로그
• NAC·인증 서버·디렉터리 서비스 로그
• 배포·패치·유지보수 작업 이력
• 백업·복구와 대량 파일 접근
• 데이터베이스 관리자 접속과 대량 조회
• WAF·웹서버 로그가 존재하는 경우 요청과 서버 행위 연계

핵심은 로그의 개수가 아니라 연결 가능성입니다.
누가 접속했고, 무엇을 실행했고, 어떤 권한을 얻었으며, 어디로 이동했는지를 하나의 흐름으로 설명할 수 있어야 합니다.

8) “아웃바운드 차단”을 유지하면서 로그를 전송하는 방법

PLURA 에이전트의 로그 전송을 위해
서버에 일반 인터넷 접속을 허용할 필요는 없습니다.

보안 정책은 다음과 같이 구성할 수 있습니다.

• PLURA 로그 전송 목적지에 대해서만 통신 허용
• 지정된 포트와 프로토콜만 허용
• 서버에서 시작하는 아웃바운드 세션만 허용
• 업무용 웹사이트와 일반 인터넷 접속은 계속 차단
• DNS도 필요한 목적지 해석 범위로 최소화
• 방화벽 정책 변경 이력과 접속 로그를 별도 보존
• 필요 시 내부 중계 서버를 통해 로그 전송
• 지상국·제어망·운영망 정책에 맞는 별도 연동 구조 협의

즉, 목적은 “인터넷 사용 허용”이 아니라
보안 텔레메트리 전송을 위한 최소 목적 통신 허용입니다.

권장 아키텍처

flowchart LR
    subgraph Isolated["망분리·인터넷 차단 구간"]
        Server["중요 서버
(로그인·프로세스·권한·파일·네트워크·감사 로그)"]
        Agent["PLURA 에이전트"]
        Relay["내부 로그 중계 서버
(선택 사항)"]

        Server --> Agent
        Agent --> Relay
    end

    FW["경계 방화벽
(목적지·포트·프로토콜 최소 허용)"]
    PLURA["PLURA-XDR
(수집·탐지·상관분석)"]
    SOC["PLURA SOC
(검증·분석·통보·대응 지원)"]
    Customer["고객 보안·운영 담당자"]

    Relay -->|"허용된 로그 전송만"| FW
    FW --> PLURA
    PLURA --> SOC
    SOC --> Customer

환경이 단순하면 에이전트가 지정 목적지로 직접 전송할 수 있고,
중요 서버에서 외부 목적지로 직접 통신하는 것을 허용하기 어렵다면
내부 중계 서버에 로그를 모아 한 지점에서만 전송하도록 구성할 수 있습니다.

완전한 물리적 단절망은 별도 설계가 필요합니다

외부로 어떠한 통신도 허용하지 않는 완전한 물리적 단절망에서는
클라우드 기반 실시간 SOC가 그대로 작동할 수 없습니다.

이 경우에는 다음 중 하나를 검토해야 합니다.

• 내부망 전용 수집·분석 시스템과 온프레미스 SOC
• 보안 중계 구간을 통한 통제된 로그 반출
• 단방향 전송 장비 또는 승인된 데이터 전달 구조
• 주기적 오프라인 반출과 별도 분석
• 사고 시 포렌식 자료를 보존·전달하는 절차

다만 주기적 반출은 실시간 탐지와 대응이 어렵기 때문에
중요도와 위협 수준에 따라 잔여 위험을 명확히 승인해야 합니다.

로그 전송이 불가능하다는 것은 위험이 없다는 뜻이 아닙니다.
현재 구조로는 외부 SOC가 위험을 볼 수 없다는 뜻입니다.

9) PLURA-XDR과 SOC는 어디에서 도움이 되는가

망분리 서버에서 필요한 것은
백신 탐지 건수만 보여주는 화면이 아닙니다.

실제로 필요한 것은 다음 흐름을 연결하는 것입니다.

관리자 또는 서비스 계정 로그인
        ↓
명령·스크립트·프로세스 실행
        ↓
권한 상승과 보안 기능 변경
        ↓
파일 생성·설정 변경·지속성 등록
        ↓
내부 서버 접속과 횡적 이동
        ↓
자료 수집·압축·전송

PLURA-XDR은 다음 로그를 같은 시간축에서 분석할 수 있습니다.

• 로그인 성공·실패
• 관리자·서비스 계정 행위
• 프로세스와 명령줄
• 권한 상승
• 파일 생성·변경
• 서비스·스케줄러 등록
• 내부·외부 네트워크 연결
• 감사 정책과 보안 에이전트 상태
• 웹·WAF 로그가 존재하는 경우 서버 행위와의 연계

SOC는 이 데이터를 바탕으로
단순 이벤트를 실제 위협 시나리오로 해석합니다.

예를 들어 다음 조합은 개별적으로는 정상처럼 보일 수 있습니다.

1. 관리 계정 로그인
2. sudo 실행
3. 임시 경로에 파일 생성
4. 서비스 등록
5. 인접 서버로 SSH 접속

그러나 짧은 시간에 연속으로 발생했다면
백도어 설치와 횡적 이동 가능성을 의심해야 합니다.

에이전트는 서버에서 일어난 일을 보여주고,
XDR은 여러 행위를 연결하며,
SOC는 그 연결이 실제 공격인지 판단하고 대응합니다.

10) 즉시 적용 체크리스트

11) 서버 호스트보안과 SOC를 제외할 때 반드시 남겨야 할 판단

의미를 다음과 같이 정확히 구분해야 합니다.

잘못된 해석

“인터넷이 차단되어 있으므로 서버는 안전하며, 호스트보안과 SOC가 필요 없다.”

정확한 해석

“현재 네트워크 정책상 PLURA 로그를 외부 분석 환경으로 전송할 수 없어
호스트 로그 분석과 외부 SOC 서비스를 적용하지 못한다.
따라서 해당 서버 내부의 침해 행위에 대한 실시간 가시성과 대응 능력이 제한된다.”

두 문장은 전혀 다른 의미입니다.

호스트보안과 SOC를 제외하면 다음 위험이 남습니다.

• 정상 계정으로 수행된 공격을 실시간으로 확인하기 어려움
• 내부 시스템에서 확산된 공격을 늦게 발견할 수 있음
• 백도어·권한 상승·로그 삭제 행위를 놓칠 수 있음
• 사고 발생 시 원인과 침해 범위를 입증하기 어려움
• 고객 또는 외부 조사기관에 충분한 증거를 제공하지 못할 수 있음

따라서 현재 견적에서 제외하더라도
향후 다음 조건이 마련되면 재검토해야 합니다.

• PLURA 목적지에 대한 최소 아웃바운드 허용
• 내부 로그 중계 서버 구축
• 보안 중계 구간 또는 승인된 로그 전달 구조 마련
• 온프레미스 분석·관제 체계 구축
• 지상국 운영 정책에 맞는 별도 연동 방식 합의

보안 항목의 제외는 위험의 제거가 아니라, 탐지·대응 능력의 제외입니다.

12) 결론

• 망분리는 필요하지만 충분하지 않습니다
• 외부 인터넷이 차단되어도 관리자 PC, 계정, 유지보수 파일, 정책 오류, 내부 연계망을 통해 공격이 들어올 수 있습니다
• 공격자가 정상 관리 경로를 이용하면 외부 공격 트래픽만으로 침해 여부를 확인하기 어렵습니다
• 따라서 중요 서버의 로그인, 프로세스, 권한, 파일, 네트워크, 감사 로그를 지속적으로 수집·분석해야 합니다
• 로그를 저장하는 것만으로는 부족하며, 공격 흐름을 연결하고 대응하는 SOC가 필요합니다
• PLURA 로그 전송은 일반 인터넷을 개방하는 것이 아니라, 지정 목적지와 포트만 최소 허용하는 방식으로 구성할 수 있습니다
• 완전한 단절망이라면 내부 분석 또는 통제된 로그 반출 구조를 별도로 설계해야 합니다

한 문장 요약
“망분리는 공격 경로를 줄이고, 로그 분석과 SOC는 이미 들어온 공격자를 찾아냅니다.”

법원행정처 사건은
분리된 망 사이의 허용 경로가 공격에 악용될 수 있음을 보여줬습니다.

SKT 사건은
중요 서버의 로그가 존재하더라도 필요한 범위를 모두 분석하고 연결하지 않으면
장기간 침해를 놓칠 수 있음을 보여줬습니다.

따라서 지상국을 포함한 중요 망분리 서버는
인터넷 연결 여부가 아니라 자산의 중요도와 침해 시 영향을 기준으로
로그 분석과 SOC 적용 여부를 결정해야 합니다.

📖 함께 읽기

• PLURA 위협 사례 전체 보기
• 법원행정처 전산망 해킹 시나리오
• SKT 해킹 가설: 유심 데이터 탈취와 BPFDoor 설치, 어떻게 이뤄졌나?
• SK텔레콤 침해사고 최종 조사결과 발표
• CISA: Best Practices for Event Logging and Threat Detection
• CISA: Guidance for SIEM and SOAR Implementation
• NIST SP 800-92: Guide to Computer Security Log Management

(참고) 법원행정처와 SKT 사례를 “완전한 물리적 단절망이 외부에서 직접 침해됐다”는 의미로 단순화해서는 안 됩니다.
두 사례의 핵심은 외부 접점, 관리망, 연계 서버, 허용 포트, 계정정보를 통해 중요 내부 시스템으로 공격이 확산될 수 있으며, 이를 발견하려면 서버 로그와 중앙 관제가 필요하다는 점입니다.