벤더 VPN이 PLC subnet에 바로 떨어진다면 그건 DMZ가 아니다

VPN에 붙었더니 PLC가 ping에 답한다

이 한 줄이 원격 접속 설계를 판정한다. 벤더 노트북에서 ping 10.20.30.11이 돌아오면 그 노트북은 이미 제어망 장비다. 방화벽이 있든 없든 마찬가지다.

IEC 62443-3-2는 이 구조를 zone과 conduit으로 나누라고 요구한다. Purdue 모델로 말하면 Level 3.5 — enterprise(Level 4/5)와 제어망(Level 0–2) 사이에 DMZ 하나를 끼우고, 양쪽 트래픽이 DMZ에서 한 번 끊기게 만드는 층이다. NIST SP 800-82 Rev 3(2023)도 같은 말을 한다. 사무망과 제어망 사이에 직접 통과하는 flow가 있으면 안 된다.

원격 지원을 없애자는 얘기가 아니다. 라인이 멈췄는데 벤더 엔지니어가 두 시간 거리에 있으면 원격 접속이 답이다. 경계에서 한 번 멈추게 만들자는 것뿐이다.

무난한 경로는 이렇다.

사용자가 VPN 또는 zero-trust access 서비스에 인증한다.
접속 지점이 industrial DMZ 안으로만 떨어진다.
거기서 jump host, remote desktop gateway, 벤더 support VM에 접속한다.
DMZ에서 제어망으로는 승인된 프로토콜만 지나간다.
접속 기록, 파일 전송 기록, 작업 시간이 남는다.

3단계가 없으면 나머지는 장식이다.

표준이 실제로 요구하는 것

"보안 표준을 따른다"는 문장은 감사에서 아무 힘이 없다. IEC 62443-3-3(System security requirements and security levels)은 원격 접속에 대해 조항 번호로 요구한다. 붙일 수 있는 것만 적는다.

조항	요구 내용	설계에 미치는 영향
SR 1.13	신뢰할 수 없는 망을 통한 접속을 감시하고 통제할 것	VPN 종단이 DMZ 안이어야 한다
SR 1.13 RE(1)	접속 요청에 대한 명시적 승인	상시 개방 벤더 통로 금지, 요청·승인 절차 필요
SR 2.6	원격 session을 무활동 시간 후 자동으로, 또는 개시한 사용자가 수동으로 종료할 것	이 값은 방화벽 idle timeout과 반드시 맞춰야 한다(아래 참고)
SR 2.8	감사 가능한 event 기록	누가·언제·무엇을. login 로그만으로는 부족하다
SR 5.1	망 분할	Level 3.5 DMZ의 근거 조항
SR 5.2	Zone 경계 보호, deny all / permit by exception	`any-any` rule은 이 조항 위반이다

FR 5(Restricted Data Flow)가 SR 5.x를 묶는 상위 요구사항이다. 감사 대응 문서를 쓸 때는 rule 하나하나를 이 번호에 대응시켜두면 다음 심사가 짧아진다.

여기서 SL(security level) 등급까지 인용하는 문서를 자주 보는데, SL 매핑은 zone별 위험평가 결과에 따라 달라진다. 조항 번호는 확정적이고 SL 배정은 아니다. 확인하지 않은 SL 숫자는 쓰지 않는 편이 낫다.

운전 화면 접속과 엔지니어링 접속을 나눈다

HMI runtime, SCADA server, historian, PLC engineering workstation을 같은 방식으로 열면 안 된다.

접속 대상	주 목적	현장에서 쓰기 좋은 방식
HMI client	화면을 같이 보며 상황 확인	읽기 전용 support client 또는 mirrored session
SCADA server	서비스 재시작, 로그 확인, 패치 점검	jump host 경유, 개인 계정, 필요할 때만 관리자 권한
PLC engineering workstation	온라인 진단, 제한된 다운로드	시간 제한, 변경 티켓, 현장 승인 후 접속
Historian/reporting server	데이터 조회, collector 상태 확인	DMZ 쪽 reporting 화면 또는 제한된 database proxy
Vendor package controller	전용 진단 툴 사용	해당 장비로만 firewall rule이 열린 support VM

"벤더 VPN" 하나가 모든 장비로 가는 공용 통로가 되면 안 된다. 포장기 OEM, drive 담당자, MES 담당자는 필요한 장비와 포트가 다르다.

Rule 이름에 목적이 없으면 아무도 못 지운다

allow-any-vendor는 영원히 남는다. 지웠을 때 무엇이 끊길지 아무도 모르기 때문이다. OEM_A_support_vm_to_filler_plc_tcp_44818_ticket_2317은 몇 달 뒤에도 질문할 수 있다.

Rule마다 최소한 이만큼 남긴다.

Source zone과 source host 또는 group.
Destination host, subnet, service.
Protocol과 port. TCP any로 뭉개지 않는다.
업무 owner와 기술 owner.
상시 rule인지, 작업 기간 rule인지, emergency-only인지.
시운전 때 어떤 방법으로 확인했는지.
대응하는 IEC 62443-3-3 조항.

포트 번호는 외워두는 편이 빠르다. 벤더에게 물어보면 대개 "다 열어달라"고 답한다.

용도	Port
RDP	TCP 3389
OPC UA (`opc.tcp`)	TCP 4840
Modbus TCP	TCP 502
EtherNet/IP explicit (CIP Class 3)	TCP 44818
EtherNet/IP implicit I/O (Class 1)	UDP 2222
EtherNet/IP `ListIdentity` browse	UDP 44818, 브로드캐스트
OPC Classic / DCOM	TCP 135 + 동적 49152–65535
Microsoft SQL Server	TCP 1433

마지막 두 줄이 zone을 넘는 설계에서 계속 문제를 만든다. 브로드캐스트는 라우팅되지 않고, 16384개짜리 동적 포트 범위는 사실상 열어주기 어렵다.

Jump host는 공용 창고가 아니다

Jump host는 단순해야 한다. 지원에 필요한 툴만 있고 나머지는 없어야 한다. 모두가 installer, password, screenshot, 오래된 project file을 올려두는 공유 바탕화면이 되면 관리 지점이 아니라 위험 지점이다.

공용 vendor 계정 대신 개인 또는 회사별 계정을 쓴다(SR 1.1).
Jump host에 닿기 전 MFA를 적용한다.
PLC, SCADA, database, domain password를 browser나 engineering tool profile에 저장하지 않는다.
Clipboard와 drive redirection은 정책으로 제한한다.
파일은 직접 끌어다 놓지 말고 검사되는 drop folder를 거친다.
권한 작업은 session recording 또는 최소한 login/command log를 남긴다(SR 2.8).
큰 벤더 작업 뒤에는 snapshot 복구나 재빌드 절차가 있어야 한다.

원격 접속 정책은 jump host에서 실제로 드러난다. Jump host가 방치되어 있으면 네트워크 구성도는 그림일 뿐이다.

성공 테스트만 하면 경계를 시험한 게 아니다

시운전에서 "벤더가 접속되나요?"만 확인하면 정상 경로만 본 것이다. SR 5.2가 요구하는 것은 막히는 쪽이다. 막히는 쪽을 시험하지 않으면 deny 설정이 실제로 걸려 있는지 알 수 없다.

VPN 사용자는 jump host에는 닿지만 PLC subnet으로 직접 ping하지 못한다.
Jump host에서는 필요한 HMI 또는 PLC engineering port에 접속된다.
Support task와 무관한 file share는 열리지 않는다.
시간 제한 계정이면 승인 시간 밖에는 login이 막힌다.
DMZ에서 사용하는 DNS 이름이 정상 해석된다.
큰 project upload나 trend export가 중간에 조용히 timeout되지 않는다.
Firewall log에서 넓은 fallback rule이 아니라 의도한 rule hit가 보인다.

DMZ firewall에서 짧게 packet capture를 잡으면 추측보다 빠르다. SCADA application을 의심하기 전에 source NAT, destination NAT, port translation, asymmetric routing을 먼저 본다.

자주 보는 실패 형태

원격 접속 문제는 application 문제처럼 보이지만 대개 network 설계 문제다.

툴은 연결되는데 browse 목록이 비어 있다. EtherNet/IP browse는 UDP 44818 ListIdentity를 브로드캐스트로 뿌린다. 브로드캐스트는 라우터를 넘지 않으므로 zone을 나눈 순간 browse는 반드시 비어 보인다. 연결 자체는 TCP 44818로 잘 되기 때문에 "연결은 되는데 목록이 없다"는 모양이 나온다. 답은 방화벽을 여는 게 아니라 IP를 직접 넣는 것이다. Zone을 넘을 때는 discovery보다 명시적 IP 설정이 항상 낫다.

OPC UA client가 endpoint를 못 붙잡는다. OPC UA Part 4 §5.4의 discovery service(GetEndpoints)는 server가 가진 EndpointDescription.endpointUrl을 그대로 돌려준다. 그 URL에는 server의 내부 hostname이나 사설 IP가 들어 있다. NAT 뒤에서는 client가 첫 접속에 성공한 뒤 응답에 실린 주소로 다시 걸었다가 실패한다. Server에 외부 hostname을 alternate endpoint URL로 등록해야 한다. 인증서 subjectAltName과 접속 URL의 hostname이 어긋나면 Bad_CertificateHostNameInvalid가 뜬다. 이건 방화벽 문제가 아니다.

RDP는 되는데 PLC software가 online이 안 된다. License server 경로가 없거나, USB license dongle이 session에 mapping되지 않거나, 위의 브로드캐스트 discovery가 zone을 넘지 못하는 경우다. 이 셋 중 하나다.

Firewall을 크게 열 때만 된다. 되는 상태에서 packet capture를 잡고 실제로 오간 flow만 남긴다. 장애가 끝난 뒤 any-any rule을 그대로 두면 다음 감사 때가 아니라 다음 사고 때 문제가 된다.

큰 project upload가 90% 근처에서 조용히 멈춘다. 여기서 시간 제일 많이 버린다. 원인은 대개 timeout 두 개가 안 맞는 것이다. Windows TCP keepalive 기본값은 7200 s(2시간)인데, 방화벽의 TCP session idle timeout은 흔히 3600 s다. Upload 중 응답을 기다리며 조용한 구간이 1시간을 넘으면 방화벽이 session을 먼저 지운다. 양쪽 어디에도 에러가 남지 않고 그냥 멈춘다. 방화벽 rule의 idle timeout을 올리거나 keepalive를 줄여서 맞춘다. SR 2.6이 요구하는 session 종료 시간도 이 값과 같이 정해야 한다. 따로 정하면 보안 정책이 upload를 끊는다.

벤더가 VPN이 느리다고 한다. MTU부터 본다. Ethernet MTU 1500 bytes에서 IPsec tunnel 헤더가 빠지므로 TCP MSS를 1350 bytes 부근으로 clamp하지 않으면 큰 패킷이 조각나거나 버려진다. 증상은 "ping은 되는데 파일 전송만 멈춘다"이다. 그 다음에 latency와 packet loss를 본다. 무거운 engineering tool은 원격 노트북보다 제어망 근처 support VM에서 돌리는 편이 안정적이다.

지원 중에 현장 화면이 느려진다. 원격 session이 historian, HMI, PLC 통신 여유를 잡아먹을 수 있다. 벤더 작업 중 controller connection count, SCADA client license, historian collector queue를 같이 본다.

운영 규칙까지 있어야 설계가 완성된다

벤더 접속을 열기 전에 현장 담당자를 지정한다.
사람 또는 회사 단위로 계정을 분리한다.
Emergency access는 사고 처리 후 닫는다. SR 1.13 RE(1)의 명시적 승인은 회수까지 포함한다.
Support VM에 설치 가능한 tool과 version 목록을 관리한다.
변경한 것, 보기만 한 것, 후속 조치가 필요한 것을 작업 기록에 나눈다.
프로젝트 종료, 정기 shutdown, 벤더 upgrade 뒤에는 remote access rule을 다시 본다.

마지막으로 확인할 것 하나. 지난 장애 때 누군가 "일단 열어주세요"라고 말했는가. 그랬다면 승인된 경로가 실제로는 동작하지 않는 것이고, 설계는 아직 끝나지 않았다.