인증서 갱신에는 계획이 필요하다
OPC UA 보안은 인증서 수명 주기를 갑작스러운 장애가 아니라 정기 유지보수 작업으로 다룰 때만 쓸모가 있습니다. 시운전 당시에는 잘 돌던 SCADA 연결이 몇 년 뒤에 끊기는 경우가 많은데, 애플리케이션 인증서가 만료되거나, 신뢰 목록이 덮어써지거나, 게이트웨이가 새 인증서 지문(thumbprint)을 가진 장비로 교체되었기 때문입니다.
목표는 단순합니다. 인증서를 갱신하되, 모든 클라이언트와 서버가 여전히 올바른 애플리케이션 신원을 신뢰하고 있음을 증명하는 것입니다.
손대기 전에 목록부터 만든다
작은 표부터 시작하세요. 기억이나 초기 프로젝트 당시의 스크린샷에 의존하지 마세요.
| 항목 | 기록할 내용 |
|---|---|
| OPC UA 애플리케이션 이름 | 인증서와 엔드포인트에 표시되는 정확한 이름. |
| 역할 | 서버, 클라이언트, 게이트웨이, 히스토리언 수집기, 엔지니어링 도구. |
| 호스트명과 IP | 클라이언트가 사용하는 NAT나 별칭 이름도 포함. |
| 엔드포인트 URL | 예: opc.tcp://plc-gateway-01:4840. |
| 현재 인증서 만료 시점 | 날짜와 시간, 가능하면 시간대까지. |
| 신뢰 목록 위치 | 파일 경로, 벤더 UI 페이지, 또는 인증서 저장소. |
| 재시작 필요 여부 | 인증서 적용 시 서비스나 드라이버가 재시작되는지. |
현장 노트: 여러 벤더가 섞인 시스템에서는 인증서가 Windows 장비나 Linux 호스트가 아니라 OPC UA 애플리케이션 자체에 묶여 있을 수 있습니다. 호스트명이 그대로여도 런타임을 재설치하면 새 애플리케이션 인증서가 생성될 수 있습니다.
갱신 전 확인
무엇이든 교체하기 전에 현재 시스템 동작을 먼저 확인하세요.
- 현재 애플리케이션 인증서, 필요한 경우 개인 키, 그리고 신뢰 목록을 내보내거나 백업한다.
- 활성 엔드포인트 URL, 보안 정책(security policy), 메시지 보안 모드를 기록한다.
- 어떤 클라이언트가 연결되어 있는지, 대기(standby) 노드에서 실행되는 것이 있는지 확인한다.
- 클라이언트와 서버의 시간 동기화를 확인한다. 시계가 틀어지면 유효한 인증서도 무효로 보인다.
- 인증서의 주체 대체 이름(SAN)에 클라이언트가 실제로 사용하는 이름이 포함되어 있는지 확인한다.
- 벤더 도구가 수동 수락을 요구할 때 신뢰 프롬프트를 승인할 수 있는 사람이 누구인지 파악한다.
운영에 중요한 연결이라면 롤백 시간을 확보하세요. 인증서 작업은, 장애 시간 창이 명시적으로 함께 다루는 경우가 아니라면, 무관한 드라이버 업그레이드와 섞지 않아야 합니다.
갱신 순서
통제된 갱신은 보통 다음 순서를 따릅니다.
- 새 서버 애플리케이션 인증서를 생성하거나 가져온다.
- 인증서에 예상한 애플리케이션 URI와 DNS/IP 이름이 포함되어 있는지 확인한다.
- 서버 애플리케이션 인증서 저장소에 설치한다.
- 필요한 OPC UA 서비스나 런타임 구성 요소만 재시작한다.
- 테스트 클라이언트 하나에서 보안 연결을 시도하고, 예상되는 경우 신뢰 거부(trust rejection)를 확인한다.
- 새 서버 인증서를 각 클라이언트의 신뢰 목록으로 옮긴다.
- 클라이언트 인증서 인증을 사용한다면 서버가 각 클라이언트 인증서를 신뢰하는지 확인한다.
- 가능하면 운영 클라이언트를 하나씩 재연결한다.
- 실시간 데이터, 품질, 구독(subscription), 알람, 히스토리언 수집을 확인한다.
- 기존 및 새 인증서 정보를 시운전 노트와 함께 보관한다.
이중화 시스템에서는 아키텍처가 허용하는 경우 비활성 또는 대기 측을 먼저 갱신하세요. 그런 다음 페일오버하여 확인하고, 다른 쪽에서 반복합니다.
재연결 후 확인할 것
연결 아이콘이 초록색으로 바뀌었다고 끝난 것이 아닙니다. 변경 후에도 구독과 데이터 품질이 살아남았음을 증명하는 동작을 확인하세요.
| 확인 | 확보할 증거 |
|---|---|
| 세션이 안전하게 연결됨 | 클라이언트 진단 화면 또는 로그 항목. |
| 예상한 보안 모드가 활성화됨 | 의도하지 않은 한 None으로 조용히 낮아지지 않았는지. |
| 실시간 값이 갱신됨 | 타임스탬프 또는 변하는 공정 값. |
| 항목 품질이 양호함 | BadSecurityChecksFailed, BadCertificateUntrusted, 오래된 품질 값이 없음. |
| 알람/이벤트가 도착함 | 안전한 테스트 이벤트를 발생시키거나 알려진 시뮬레이터 포인트를 사용. |
| 히스토리언이 샘플을 저장함 | 트렌드나 아카이브 조회에서 최근 값 확인. |
| 대기 노드가 동작함 | 활성 노드뿐 아니라 이중화 경로도 테스트. |
첫 테스트는 좁게 유지하세요. 클라이언트-서버 경로 하나를 먼저 증명한 뒤, 나머지 클라이언트마다 같은 체크리스트를 반복합니다.
자주 하는 실수
- 서버 인증서는 갱신하면서, 같은 인증서를 신뢰하는 히스토리언 수집기와 엣지 게이트웨이는 잊는다.
- 인증서에는 이전 DNS 이름만 들어 있는데 엔드포인트 호스트명을 바꾼다.
- 엔지니어링 노트북이 인증서를 자동 신뢰하도록 두고, 운영 클라이언트도 똑같이 동작할 것이라 가정한다.
- 애플리케이션이 인증서와 개인 키를 모두 필요로 하는데 개인 키 없이 인증서만 복사한다.
- 갱신 후 예전 VM 스냅샷을 복원하면서 만료된 인증서를 실수로 되살린다.
- 문제 해결 후 보안 정책을
None으로 남겨 둔다.
최소 인수인계 기록
프로젝트 폴더에 짧은 기록을 남기세요.
- 인증서 주체(subject), 발급자(issuer), 지문(thumbprint), 일련번호, 만료일.
- 애플리케이션 URI와 엔드포인트 URL.
- 운영에서 사용한 보안 정책과 메시지 모드.
- 갱신한 클라이언트와 서버 목록.
- 재시작 또는 페일오버 시각.
- 테스트 증거: 실시간 태그, 알람/이벤트, 히스토리언 샘플.
- 롤백 노트와 백업 위치.
현장 노트
인증서를 교정(calibration) 날짜처럼 다루세요. 흥미롭지는 않지만 예측 가능합니다. 짧은 갱신 로그 하나가, 다음 엔지니어가 새벽 2시 통신 장애 중에 신뢰 체인을 처음 파악하게 되는 일을 막아 줍니다.