OPC UA biztonsági módok a gyakorlatban

Röviden

Az OPC UA az ipari kommunikáció egyik legbiztonságosabbra tervezett protokollja: üzenetaláírást, titkosítást, tanúsítványalapú alkalmazás-hitelesítést és felhasználói hitelesítést is ismer. A gyakorlatban mégis gyakran fut None biztonsági móddal, névtelen hozzáféréssel, vagy olyan szerverrel, amely minden kliens-tanúsítványt automatikusan elfogad. Ez a jegyzet bemutatja, mit jelentenek a biztonsági módok, mit lát egy támadó az egyes beállításoknál, és milyen konfigurációt javaslunk.

Biztonsági mód és biztonsági szabályzat

Minden OPC UA végpontot (endpoint) két beállítás jellemez:

• Biztonsági mód (MessageSecurityMode): None (sem aláírás, sem titkosítás), Sign (az üzenetek aláírtak, de olvashatók), SignAndEncrypt (aláírt és titkosított).
• Biztonsági szabályzat (SecurityPolicy): a használt algoritmusok. Ma ajánlott: Basic256Sha256, Aes128_Sha256_RsaOaep, Aes256_Sha256_RsaPss. Elavult, kerülendő: Basic128Rsa15 és Basic256 (SHA-1-re épülnek).

Egy szerver egyszerre több végpontot is kínálhat. A biztonság szempontjából a leggyengébb felkínált végpont számít: ha a szerver a SignAndEncrypt mellett None-t is elfogad, a támadó a gyengébbet fogja választani.

Mit lát a támadó?

• Végpontfelderítés hitelesítés nélkül. A GetEndpoints hívás a szabvány szerint nyilvános: bárki lekérdezheti, milyen végpontokat, szabályzatokat és felhasználói tokentípusokat kínál a szerver. Ez önmagában nem hiba, de pontos térképet ad a hálózaton lévő támadónak.
• None mód. A teljes kommunikáció olvasható és módosítható a hálózaton: folyamatértékek, receptek, alarmok és írási műveletek. Ha a felhasználói token szabályzata sem ír elő külön titkosítást, a felhasználónév és a jelszó is olvasható lehet.
• Névtelen hozzáférés (Anonymous token). Hitelesítés nélkül olvasható, rossz jogosultsági beállításnál írható is a címtér. Írható csomópont esetén ez közvetlen beavatkozást jelenthet a folyamatba.
• Automatikus tanúsítvány-elfogadás. Sok szerver (és sok kliens) fejlesztési kényelemből minden ismeretlen tanúsítványt megbízhatónak fogad el. Ilyenkor a tanúsítványalapú hitelesítés gyakorlatilag nem véd, és közbeékelődéses támadás is lehetséges.
• Sign mód. Védi az üzenetek sértetlenségét, de az adatforgalom olvasható marad. Ipari titoknak számító receptúránál vagy gyártási adatnál ez kevés lehet.

Hogyan ellenőrizzük?

Írásos felhatalmazással, termelő rendszeren csak passzívan vagy karbantartási ablakban:

1. Végpontlista lekérdezése, a felkínált módok, szabályzatok és tokentípusok rögzítése.
2. A névtelen és a None végpont elérhetőségének ellenőrzése, kizárólag olvasó műveletekkel.
3. A szerver tanúsítványának vizsgálata: lejárat, kulcsméret, aláírási algoritmus.
4. A megbízhatósági lista (trust list) és a visszavonási lista (CRL) beállításának áttekintése, az automatikus elfogadás kiszűrése.
5. A címtér jogosultságainak áttekintése: mely csomópontok írhatók, és kinek.
6. Passzív forgalomrögzítésből: mely kliensek, milyen módban kapcsolódnak valójában.

Ajánlott konfiguráció

• Csak SignAndEncrypt végpont, korszerű szabályzattal (Basic256Sha256 vagy újabb); a None és az elavult szabályzatok kikapcsolása.
• Névtelen hozzáférés tiltása; felhasználónév és jelszó vagy X.509 felhasználói tanúsítvány, szerepkör szerinti jogosultságokkal.
• Kézzel karbantartott megbízhatósági lista, az automatikus tanúsítvány-elfogadás kikapcsolása, visszavonási lista vezetése.
• Az írható csomópontok minimalizálása; az írási jog csak azoknak a klienseknek, amelyeknek feltétlenül szükséges.
• Hálózati szinten: az OPC UA port csak a szükséges zónákból legyen elérhető (IEC 62443 szerinti zónák és csatornák), a felügyeleti és diagnosztikai felületek ne legyenek a teljes hálózatra kiengedve.

Gyakorlati tanulság a laborból

Saját laborunkban egy OPC UA aggregátort (több PLC-modul adatait összefogó szervert) vizsgáltunk. A tipikus kiinduló állapot ugyanaz volt, mint amit terepen is látunk: a névtelen hozzáférés engedélyezve volt, a megbízhatósági lista üres maradt, a diagnosztikai webfelület pedig a teljes hálózatról elérhető volt. A javítás sorrendje: először a diagnosztikai felület leszűkítése és a host-tűzfal, utána, a kliens oldallal egyeztetve, a biztonsági mód és a hitelesítés szigorítása. Ez utóbbinál a kliens (SCADA vagy MES) beállítását is módosítani kell, ezért csak tervezett átállással végezhető.

Források

• OPC Foundation: OPC 10000-2 (Security Model) és OPC 10000-7 (Profiles)
• BSI: OPC UA Security Analysis
• IEC 62443-3-3: rendszerszintű biztonsági követelmények