글
OPC-UA 101/ (보안)- https://otti.kr/Downloads
- https://bridgeware.kr/110- /// https://bridgeware.kr/87
https://softwaretoolbox.com/opc-server-remote-config-client#resources
#브릿지 웨어 이영주 / KEP ServerEX (OPC-UA / Classic Server)
OPC UA
MQTT
CONNECT
EVERYTHING
ENTERPRISE CONNECTIVITY
PRODUCTIVITY TOOLS
EDGE TO CLOUD
DATA ANALYTICS
DEVICE CONNECTIVITY
FLOW
IOT & IIOT
TOP SERVER
TUNNELING
DATAHUB
Simulator Drive
SIM_CH1
SIM DEV1
TAG1 (R0~9999)
TAG2 (K0~9999) --동일 어드레스
TAG3 (K0~9999) ---동일 어드레스ㅇ
# DCOM 정책 _ OPC Classic 과 OPC UA 에서 보안정책을 ELI5로 설명해줘
OPC와 DCOM 보안을 5살 아이에게 설명하듯이 해볼게요!
🏠 공장과 집 이야기로 설명해보자
DCOM(Distributed COM)은 옛날 방식:
- 마치 옛날 집에서 문과 창문이 너무 많아서 어디로 도둑이 들어올지 모르는 것 같아요
- 집 주인(관리자)이 모든 문마다 다른 열쇠를 만들어야 하고, 누가 언제 들어왔는지 추적하기 어려워요
- Windows 컴퓨터끼리만 대화할 수 있어요 (같은 언어를 쓰는 사람들끼리만 대화하는 것처럼)
OPC UA는 새로운 방식:
- 현대적인 아파트처럼 보안카드 하나로 모든 곳을 관리해요
- 누가 언제 어디에 들어갔는지 다 기록돼요
- 어떤 브랜드 컴퓨터든 대화할 수 있어요 (세계 공통어를 쓰는 것처럼)
🔒 보안 정책 비교
OPC Classic + DCOM:
❌ 복잡한 설정 (문이 100개인 집)
❌ Windows만 사용 가능
❌ 방화벽 설정이 까다로움
❌ 누가 뭘 했는지 추적 어려움
OPC UA:
✅ 간단한 설정 (스마트폰 앱 하나로 모든 것 관리)
✅ 모든 운영체제에서 사용 가능
✅ 암호화로 대화 내용 보호
✅ 사용자별 권한 관리 쉬움
✅ 모든 활동 기록 가능
🎯 핵심 차이점
보안 수준:
- OPC Classic: 🔓 "우리 동네는 안전해서 문 안 잠가도 돼"
- OPC UA: 🔐 "은행 금고처럼 튼튼하게 보안 설정"
관리 편의성:
- OPC Classic: 📚 두꺼운 매뉴얼 100권
- OPC UA: 📱 스마트폰 앱 하나
그래서 요즘 공장들은 점점 OPC UA로 바꾸고 있어요. 더 안전하고 관리하기 쉽거든요!
OPC UA에서 클라이언트-서버 간 인증서 활용법을 자세히 설명드릴게요.
🔐 OPC UA 인증서 기본 개념
인증서의 역할
- 신원 확인: "너 정말 삼성 PLC야?"
- 데이터 암호화: 대화 내용을 남이 못 보게 암호화
- 무결성 검증: 데이터가 중간에 변조되지 않았는지 확인
📋 인증서 종류와 구성
1. Application Instance Certificate
- 각 OPC UA 애플리케이션마다 고유 인증서 보유
- Subject Name: "CN=MyOPCServer, O=Company, C=KR"
- 유효기간: 보통 1-5년
- 키 길이: 최소 2048bit (권장 4096bit)
2. 인증서 저장소 구조
📁 PKI (Public Key Infrastructure)
├── 📁 own (자신의 인증서)
│ ├── cert.der (공개키 인증서)
│ └── private.pem (개인키)
├── 📁 trusted (신뢰하는 인증서들)
├── 📁 rejected (거부된 인증서들)
└── 📁 issuers (CA 인증서들)
🔄 인증서 교환 프로세스
Phase 1: 초기 연결 시도
1. 클라이언트 → 서버: "연결하고 싶어요"
2. 서버 → 클라이언트: "내 인증서예요" + 서버 인증서
3. 클라이언트: 서버 인증서 검증
- 신뢰할 수 있는 인증서인가?
- 유효기간이 만료되지 않았나?
- 서명이 올바른가?
Phase 2: 상호 인증
4. 클라이언트 → 서버: "내 인증서도 드려요" + 클라이언트 인증서
5. 서버: 클라이언트 인증서 검증
- trusted 폴더에 있는가?
- 블랙리스트에 없는가?
- 권한이 적절한가?
🛠️ 실제 구현 예시
서버 측 인증서 설정
<ApplicationDescription>
<ApplicationUri>urn:MyCompany:MyOPCServer</ApplicationUri>
<ProductUri>http://mycompany.com/MyOPCServer</ProductUri>
<ApplicationName>My OPC Server</ApplicationName>
<ApplicationType>Server_0</ApplicationType>
</ApplicationDescription>
<SecurityPolicies>
<SecurityPolicy>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</SecurityPolicyUri>
<SecurityMode>SignAndEncrypt</SecurityMode>
</SecurityPolicy>
</SecurityPolicies>
클라이언트 연결 코드 예시
# Python 예시 (opcua 라이브러리)
from opcua import Client
import os
client = Client("opc.tcp://192.168.1.100:4840")
# 클라이언트 인증서 설정
client.set_application_uri("urn:MyCompany:MyClient")
client.load_client_certificate("client_cert.der")
client.load_private_key("client_private_key.pem")
# 보안 정책 설정
client.set_security_string("Basic256Sha256,SignAndEncrypt,client_cert.der,client_private_key.pem")
try:
client.connect()
print("연결 성공!")
except Exception as e:
print(f"연결 실패: {e}")
🔧 인증서 관리 시나리오
시나리오 1: 자체 서명 인증서 (Self-Signed)
장점:
✅ 빠른 구축
✅ 비용 없음
✅ 내부 네트워크에 적합
단점:
❌ 수동 신뢰 설정 필요
❌ 확장성 제한
❌ 관리 복잡성
구현 방법:
# OpenSSL로 자체 서명 인증서 생성
openssl req -new -x509 -days 3650 -nodes \
-out server_cert.pem -keyout server_key.pem \
-subj "/CN=OPC-Server/O=MyCompany/C=KR"
시나리오 2: CA 기반 인증서
장점:
✅ 중앙 집중 관리
✅ 자동 신뢰 체인
✅ 확장성 우수
✅ 감사 추적 가능
단점:
❌ 초기 설정 복잡
❌ CA 인프라 필요
❌ 비용 발생 가능
🚨 보안 정책별 인증서 요구사항
None 정책
- 인증서 불필요
- 암호화 없음
- 개발 환경에서만 사용 권장
Basic256Sha256 정책
- RSA 2048bit 이상 키
- SHA-256 해시 알고리즘
- AES-256 암호화
- 운영 환경 권장
Aes256_Sha256_RsaPss 정책
- RSA-PSS 서명
- AES-256-CBC 암호화
- 최고 보안 수준
- 중요 시설용
📊 트러블슈팅 가이드
일반적인 인증서 오류들
1. BadCertificateUntrusted
원인: 서버 인증서가 클라이언트의 trusted 폴더에 없음
해결: 서버 인증서를 클라이언트 trusted 폴더에 복사
2. BadCertificateTimeInvalid
원인: 인증서 유효기간 만료
해결: 새 인증서 생성 및 교체
3. BadCertificateHostNameInvalid
원인: 인증서의 CN과 실제 서버 주소 불일치
해결:
- 인증서 재발급 (올바른 호스트명으로)
- 또는 SAN(Subject Alternative Name) 추가
4. BadSecurityPolicyRejected
원인: 클라이언트와 서버의 보안 정책 불일치
해결: 양쪽 보안 정책을 동일하게 설정
🔄 인증서 갱신 프로세스
1. 계획된 갱신
30일 전: 갱신 계획 수립
14일 전: 새 인증서 생성
7일 전: 테스트 환경 적용
1일 전: 운영 환경 적용 준비
갱신일: 순차 적용 (서버 → 클라이언트)
2. 무중단 갱신 방법
# 이중 인증서 방식 (서버)
server.add_certificate("old_cert.der", "old_key.pem") # 기존
server.add_certificate("new_cert.der", "new_key.pem") # 신규
# 클라이언트들이 점진적으로 새 인증서 사용
# 모든 클라이언트 전환 후 구 인증서 제거
📈 모니터링 및 감사
인증서 상태 모니터링
def check_certificate_expiry():
cert_path = "server_cert.der"
cert = load_certificate(cert_path)
days_until_expiry = (cert.not_after - datetime.now()).days
if days_until_expiry < 30:
send_alert(f"인증서 {days_until_expiry}일 후 만료")
return days_until_expiry
연결 로그 예시
[2024-09-23 10:30:15] INFO: 클라이언트 연결 시도
[2024-09-23 10:30:15] INFO: 인증서 CN=MyClient, O=Company 확인
[2024-09-23 10:30:16] INFO: 보안 정책 Basic256Sha256 적용
[2024-09-23 10:30:16] SUCCESS: 클라이언트 인증 성공
[2024-09-23 10:30:16] INFO: 암호화된 세션 시작
이렇게 체계적으로 인증서를 관리하면 안전하고 신뢰할 수 있는 OPC UA 통신이 가능합니다!
OPC UA와 OPC Classic의 보안 방식을 체계적으로 비교해드리겠습니다.
🏗️ 아키텍처 기반 보안 차이
OPC Classic (DCOM 기반)
🔴 Windows 전용 보안 모델
├── Windows 인증 (NTLM/Kerberos)
├── DCOM 보안 설정
├── 방화벽 포트 관리 (복잡)
└── 레지스트리 기반 설정
OPC UA (네이티브 보안)
🟢 플랫폼 독립적 보안
├── 자체 인증서 기반 인증
├── 애플리케이션 레벨 보안
├── 단일 포트 사용 (4840)
└── 표준화된 보안 정책
🔐 인증(Authentication) 방식 비교
OPC Classic
인증 방식:
- Windows 사용자 계정 기반
- Domain/Workgroup 인증
- NTLM 또는 Kerberos 프로토콜
장점:
✅ 기존 Windows 인프라 활용
✅ Active Directory 통합 가능
단점:
❌ Windows 환경에서만 동작
❌ 복잡한 사용자 관리
❌ 도메인 의존성
설정 예시:
DCOM 설정 (dcomcnfg.exe):
- Authentication Level: Connect/Call
- Impersonation Level: Identify/Impersonate
- Enable Distributed COM on this computer
- 사용자별 Launch/Access Permissions
OPC UA
인증 방식:
- X.509 인증서 기반
- Username/Password
- Anonymous (선택적)
- Kerberos 토큰 (확장)
장점:
✅ 플랫폼 독립적
✅ 강력한 PKI 기반
✅ 세밀한 권한 제어
단점:
❌ 인증서 관리 복잡성
❌ 초기 설정 학습 곡선
설정 예시:
<UserTokenPolicies>
<UserTokenPolicy>
<TokenType>Certificate_2</TokenType>
<SecurityPolicyUri>Basic256Sha256</SecurityPolicyUri>
</UserTokenPolicy>
<UserTokenPolicy>
<TokenType>UserName_1</TokenType>
<SecurityPolicyUri>Basic256Sha256</SecurityPolicyUri>
</UserTokenPolicy>
</UserTokenPolicies>
🛡️ 암호화(Encryption) 방식 비교
OPC Classic
암호화 레벨:
❌ 기본적으로 암호화 없음
❌ DCOM 인증 단계에서만 제한적 보안
❌ 데이터 전송 시 평문
❌ 네트워크 스니핑에 취약
보안 강화 방법:
- IPSec 터널링
- VPN 연결
- 물리적 네트워크 격리
OPC UA
암호화 정책:
✅ 다중 보안 정책 지원
✅ 메시지 레벨 암호화
✅ 세션 암호화
✅ 디지털 서명
보안 정책 레벨:
1️⃣ None: 암호화 없음
2️⃣ Basic128Rsa15: 기본 암호화
3️⃣ Basic256: 향상된 암호화
4️⃣ Basic256Sha256: 고급 암호화
5️⃣ Aes256_Sha256_RsaPss: 최고급 암호화
암호화 알고리즘 비교:
OPC Classic:
🔴 없음 (의존: Windows/네트워크 레벨)
OPC UA:
🟢 Symmetric: AES-128/256
🟢 Asymmetric: RSA-1024/2048/4096
🟢 Hashing: SHA-1/256/384/512
🟢 Digital Signature: RSA-PSS, ECDSA
🔧 인가(Authorization) 및 접근 제어
OPC Classic
접근 제어:
방식: Windows ACL 기반
범위: 프로세스/COM 객체 레벨
세분화: 제한적
권한 종류:
- Launch Permissions
- Access Permissions
- Configuration Permissions
한계점:
❌ OPC 항목별 세부 권한 불가
❌ 실시간 권한 변경 어려움
❌ 감사 로그 제한적
OPC UA
접근 제어:
방식: Role-Based Access Control (RBAC)
범위: 노드/메소드/속성 레벨
세분화: 매우 상세함
권한 종류:
- Browse (탐색)
- Read (읽기)
- Write (쓰기)
- Call (메소드 호출)
- ReceiveEvents (이벤트 수신)
- Subscribe (구독)
장점:
✅ 노드별 세밀한 권한 설정
✅ 동적 권한 변경 가능
✅ 상세한 감사 로그
OPC UA 권한 매트릭스 예시:
사용자 역할 | Browse | Read | Write | Call | Events
-------------|--------|------|-------|------|--------
Operator | ✅ | ✅ | ✅ | ❌ | ✅
Supervisor | ✅ | ✅ | ✅ | ✅ | ✅
Engineer | ✅ | ✅ | ✅ | ✅ | ✅
Maintenance | ✅ | ✅ | ❌ | ✅ | ✅
Observer | ✅ | ✅ | ❌ | ❌ | ❌
🌐 네트워크 보안 비교
OPC Classic
포트 사용:
🔴 동적 포트 할당 (1024-65535)
🔴 RPC Endpoint Mapper (135)
🔴 방화벽 설정 복잡
네트워크 문제점:
- NAT 통과 불가
- 방화벽 구멍 다수 필요
- 포트 스캐닝 취약
- 프록시 서버 통과 어려움
방화벽 규칙 예시:
인바운드 규칙:
- Port 135 (RPC Endpoint Mapper)
- Port 1024-65535 (Dynamic RPC)
- 특정 DCOM 애플리케이션 포트
아웃바운드 규칙:
- 클라이언트에서 서버로 동적 포트
OPC UA
포트 사용:
🟢 고정 포트 (기본 4840)
🟢 HTTP/HTTPS 포트 사용 가능
🟢 WebSocket 지원
네트워크 장점:
- 단일 포트로 모든 통신
- NAT/방화벽 친화적
- 프록시 서버 통과 가능
- DMZ 구성 용이
방화벽 규칙 예시:
인바운드 규칙:
- Port 4840 (OPC UA)
- Port 443 (HTTPS, 선택적)
아웃바운드 규칙:
- 클라이언트에서 4840포트로만
📊 실제 보안 시나리오 비교
시나리오 1: 공장 내 HMI-PLC 통신
OPC Classic 구성:
문제점:
❌ Windows 도메인 가입 필수
❌ 사용자 계정 관리 복잡
❌ PLC 교체 시 DCOM 재설정
❌ 방화벽 포트 다수 개방
보안 위험:
- Pass-the-Hash 공격 가능
- DCOM 취약점 노출
- 평문 데이터 전송
OPC UA 구성:
장점:
✅ 인증서 기반 상호 인증
✅ 메시지 레벨 암호화
✅ 세션별 독립 보안
✅ 단일 포트 사용
보안 강화:
- 인증서 기반 PKI
- AES-256 암호화
- 디지털 서명 검증
시나리오 2: 원격 감시 시스템
OPC Classic:
원격 접근 방법:
1️⃣ VPN 터널링 필수
2️⃣ Terminal Services 사용
3️⃣ DCOM Over HTTP (복잡)
보안 고려사항:
- Windows 인증 연장
- 도메인 트러스트 관계
- 복잡한 권한 위임
OPC UA:
원격 접근 방법:
1️⃣ 직접 연결 (암호화)
2️⃣ HTTPS 터널링
3️⃣ Gateway 서버 경유
보안 장점:
- 종단간 암호화
- 인증서 기반 인증
- 세션 타임아웃 제어
🔍 보안 감사 및 로깅
OPC Classic
로깅 한계:
❌ Windows 이벤트 로그 의존
❌ OPC 특화 로그 부족
❌ 실시간 모니터링 어려움
❌ 데이터 접근 추적 제한
감사 정보:
- 로그인/로그아웃
- DCOM 인증 실패
- 기본적인 시스템 이벤트
OPC UA
로깅 장점:
✅ 상세한 보안 이벤트
✅ 실시간 감사 로그
✅ 노드별 접근 기록
✅ 커스텀 이벤트 정의
감사 정보:
- 인증서 검증 결과
- 사용자 인증 로그
- 데이터 읽기/쓰기 로그
- 메소드 호출 이력
- 보안 정책 변경 사항
OPC UA 감사 로그 예시:
{
"timestamp": "2024-09-23T10:30:15Z",
"eventType": "SecurityAudit",
"severity": "Medium",
"source": "OPC_Server",
"message": "Certificate validation failed",
"details": {
"clientId": "urn:Company:HMI_Client",
"certificate": "CN=HMI_Client",
"reason": "Certificate expired",
"clientIP": "192.168.1.100"
}
}
📈 성능과 보안의 균형
보안 오버헤드 비교
OPC Classic:
- 기본 성능: 높음 (암호화 없음)
- Windows 인증 오버헤드: 중간
- 네트워크 효율성: 낮음 (다중 포트)
OPC UA:
- 기본 성능: 중간 (암호화 포함)
- 인증서 검증 오버헤드: 초기에만
- 네트워크 효율성: 높음 (단일 포트)
- 확장성: 우수
🎯 결론 및 권장사항
기존 시스템 (OPC Classic)
적합한 환경:
✅ 기존 Windows 기반 시스템
✅ 폐쇄된 네트워크 환경
✅ 단순한 보안 요구사항
✅ 레거시 시스템 유지보수
주의사항:
⚠️ 새로운 보안 위협에 취약
⚠️ 규정 준수 어려움
⚠️ 확장성 제한
신규 시스템 (OPC UA)
권장 환경:
✅ 새로운 산업 프로젝트
✅ 다중 플랫폼 환경
✅ 높은 보안 요구사항
✅ 원격 접근 필요
✅ 규정 준수 (IEC 62541)
투자 가치:
💰 장기적 유지보수 비용 절감
💰 보안 사고 예방 효과
💰 시스템 통합 비용 절감
이처럼 OPC UA는 현대적인 보안 요구사항을 충족하는 포괄적인 보안 프레임워크를 제공하는 반면, OPC Classic은 레거시 환경에서의 호환성에 강점이 있습니다.
- https://softwaretoolbox.com/opc-server-remote-config-client#resources
#소프트웨어 tool box - https://softwaretoolbox.com/
A B O U T O T T i
OTTI는 산업계 필드 엔지니어링 영역으로 표현되는 OT(Operational Technology)엔지니어링 전문 교육 기관입니다.
자동화 관련 경력 20년 이상의 베테랑들이 실무에 적용할 수 있는 실용적인 OT 교육을 목적으로, PLC, DCS등의 컨트롤러를 통한 제조현장의 데이터를 IT영역의 MES, ERP등의 서비스와의 연계 및 전사적인 시스템 통합을 위해 요구되는 다양한 인터페이스 및 솔루션을 교육 합니다.
OPC UA를 비롯 HMI/SCADA, RDB, RTDB(Histoiran)등 데이터베이스와의 연계 방법, IIoT, 클라우드 서비스와의 통합을 위한 MQTT, REST등의 개념 및 인터페이스 방법을 효율적이고 실무에 적용 가능한 교육을 지향합니다.
댓글 없음:
댓글 쓰기