บทที่ 06 · Built-in by Design · X.509 · TLS · 3 Layers

Security

Security คือเหตุผลสำคัญที่ Industry 4.0 เลือก OPC UA — ออกแบบมาให้ "Secure by Default" ไม่ใช่ add-on ทีหลัง — ผ่านการตรวจสอบโดย German Federal Office for Information Security (BSI) ในระดับสากล

ทำไม Security สำคัญในระบบอุตสาหกรรม?

ในยุค Modbus + RS-485 ปี 1990 — โรงงานเป็น "เกาะ" แยกจาก IT Network ใครจะ Hack ก็ต้องเข้าโรงงานด้วยตนเอง — Security จึงไม่สำคัญในระดับ Protocol

ในยุค Industrie 4.0 + Cloud — ทุกเครื่องเชื่อมต่อ Internet → ความเสี่ยงเพิ่มขึ้นมหาศาล:

โรงงานสมัยใหม่ ต้อง มีระบบ Security ตั้งแต่ Protocol ขึ้นไป — และเป็นเรื่องของ Engineer Mechatronics ไม่ใช่แค่ฝ่าย IT

OPC UA Security Model — 3 Layers

Security ของ OPC UA แยกเป็น 3 ชั้น — แต่ละชั้นมีหน้าที่ต่างกัน เปิด/ปิด แต่ละชั้นได้อิสระ:

OPC UA scalable security concept: User Security (token), App Security (authentication of client/server/messages), Transport Security (signing and encryption)
OPC UA Security Model — User, Application, และ Transport Security ทำงานคู่กัน ทำให้ Client/Server ตรวจสอบกันก่อนคุย, ส่งข้อมูลอย่างปลอดภัย, และ Authorize ตาม User (ที่มา: OPC Foundation Brochure)

1️⃣ Transport Security — ระดับช่องสื่อสาร

จุดประสงค์: ป้องกันข้อมูล ระหว่างทาง — ใครดักอ่านระหว่าง Client กับ Server ไม่ได้

2️⃣ Application Security — ระดับแอป

จุดประสงค์: Client และ Server ตรวจสอบ ตัวตน ของกันและกัน — ป้องกัน "Rogue Device" ปลอมเป็น Server

3️⃣ User Security — ระดับคน

จุดประสงค์: ตรวจสอบว่า ใคร เป็นคนใช้งาน — Authorize ตามบทบาท

OPC UA รองรับการ Authenticate User 4 แบบ:

วิธีเหมาะกับ
Anonymous Public Data ที่ใครเข้าได้ (เช่น Status Page)
UserName + Password Operator/Engineer ที่ใช้งาน HMI
X.509 Certificate Service Account / Machine-to-Machine
IssuedToken (Bearer/OAuth2) SSO / Enterprise IdP — Azure AD, Okta, Keycloak

Role-based Authorization (Part 18) — แต่ละ User มี Role เช่น "Operator", "Engineer", "Maintenance" แต่ละ Role มีสิทธิ์ที่ระดับ Node ของแต่ละ Variable/Method

SecureChannel + Session — ขั้นตอนตอนต่อ

ลำดับเหตุการณ์ตอน Client เปิดเข้าหา Server:

  1. Find Endpoint — Client เรียก GetEndpoints ไปที่ Server เพื่อดูว่ามี SecurityPolicy อะไรให้เลือก
  2. OpenSecureChannel — แลก Public Keys + กำหนด Symmetric Key สำหรับ Session — เข้ารหัส Message ทั้งหมดที่ตามมา
  3. CreateSession — Client ส่ง User Token (Username/Password/Certificate)
  4. ActivateSession — Server Validate User Token แล้ว Authorize ตาม Role
  5. Read / Write / Browse / … — เริ่มใช้งานปกติ ทุก Message ผ่าน Encryption
  6. CloseSession + CloseSecureChannel — ปิดเมื่อเสร็จ

ทั้งหมดนี้ทำโดย Library อัตโนมัติ — Application Developer ไม่ต้องจัดการ Crypto เอง

ตัวอย่าง — ตอนต่อ OPC UA Server ด้วย Python

from asyncua import Client
from asyncua.crypto.security_policies import SecurityPolicyBasic256Sha256
from asyncua.ua import MessageSecurityMode

async with Client('opc.tcp://plant-floor:4840') as client:
    # 1) Application Security — ใช้ Certificate ของเราเอง + Trust ของ Server
    await client.set_security(
        SecurityPolicyBasic256Sha256,
        certificate_path='client-cert.pem',
        private_key_path='client-key.pem',
        server_certificate_path='server-cert.pem',
        mode=MessageSecurityMode.SignAndEncrypt
    )

    # 2) User Security — ใส่ Username/Password
    client.set_user('operator-a')
    client.set_password('s3cur3-p4ss')

    # 3) Transport + Encryption ทำให้อัตโนมัติ — เริ่มใช้งานปกติ
    await client.connect()
    value = await client.get_node('ns=2;s=Temp1').read_value()

Global Discovery Server (GDS)

ในโรงงานใหญ่ที่มี Server เป็นร้อยตัว — การจัดการ Certificate ทุกตัวด้วยมือเป็นเรื่องโหด OPC UA จึงมีระบบ GDS:

เป็น Infrastructure ที่ทำให้ Security ทำงานได้ในสเกลใหญ่

BSI Security Analysis — ตรวจสอบโดยผู้เชี่ยวชาญ

German Federal Office for Information Security (BSI) — หน่วยงานความมั่นคงไซเบอร์ของรัฐบาลเยอรมัน — เคยทำ Security Analysis ของ OPC UA ในปี 2017 — ผลคือ "OPC UA ไม่มีช่องโหว่ในเชิงระบบ (does not contain systematic security vulnerabilities)"
นี่คือคำแนะนำให้ใช้ OPC UA ใน Critical Infrastructure ของเยอรมนี

เทียบกับ Modbus

ประเด็นModbusOPC UA
Encryption ระหว่างทาง❌ Plain Text✅ AES-256
Authentication App❌ ไม่มี✅ X.509 Certificates
Authentication User❌ ไม่มี✅ User/Pass, Cert, Token
Authorization (Role)❌ ไม่มี✅ Role-based ที่ระดับ Node
Integrity (กัน Tamper)มี CRC แต่ป้องกัน Active attack ไม่ได้✅ SHA-256 Signing
Audit Trail❌ ไม่มี✅ Session events บันทึกได้
Certificate Management—✅ GDS + Auto-renewal
Replay Attack Protection❌✅ Nonces + Timestamps

Best Practices สำหรับโรงงาน

  1. ใช้ SignAndEncrypt เสมอใน Production — None และ Sign ใช้ใน Lab เท่านั้น
  2. หมุน Certificate ก่อนหมดอายุ — GDS ช่วยได้ ทำได้อัตโนมัติ
  3. กำหนด Trust List ที่ Server — รับเฉพาะ Client ที่รู้จัก ไม่ใช่ Trust ทุกคน
  4. ใช้ User Authentication ที่เหมาะสม — User/Pass สำหรับคน, Certificate สำหรับเครื่อง
  5. Audit Log ทุก Session — ใครเข้ามาเมื่อไหร่ ทำอะไรบ้าง
  6. ปิด Anonymous endpoint บน Production — เปิดเฉพาะที่จำเป็น
  7. Update SecurityPolicy ทุกๆ ปี — เปลี่ยนตามคำแนะนำของ OPC Foundation Security Advisories

สรุปบทที่ 06

เสร็จส่วน "แนวคิดหลัก" แล้ว — บทต่อไปจะเข้าสู่ ระบบนิเวศ เริ่มจาก Companion Specifications ที่ทำให้ Robot, Machine Tools, IO-Link พูดภาษาเดียวกันได้

← ก่อนหน้า
05 — PubSub & MQTT