Kdo sme spremeniti kriptografijo v vašem sistemu?

Izdaja 07 serije »Postkvantna varnost v slovensko-nemški dobavni verigi«. Za interne IT-oddelke in zunanje izvajalce v podjetjih, ki dobavljajo nemškim naročnikom.

Vaš skrbnik bi nastavitve VPN spremenil v desetih minutah. Gesla ima, znanje tudi. Toda VPN-napravo je v vaše omrežje postavil nemški proizvajalec strojev za daljinski servis, garancija stroja velja samo z njegovo nastavitvijo, ključ pa je v njegovem centru. Vaš skrbnik bi spremembo znal narediti. Sme pa je ne.

V tem članku: Trije glagoli · Od omrežja do aplikacije · Kje je meja internega IT · Primer · Sprememba kriptografije je sprememba · Ko ste razvijalec vi · Matrika v enem tednu · Vprašanje za naročnika · Priloga: matrika

Pri vsaki kriptografski spremembi se srečajo trije glagoli, ki jih v pogovorih pogosto pomešamo:

• Sme je vprašanje pravice. Ali licenca dovoljuje spremembo? Ali garancija ali certifikacija velja tudi po njej? Ali je naprava sploh vaša?
• Zna je vprašanje zmožnosti. Ali imate dostop, znanje, izvorno kodo, orodja? Ali izdelek novi postopek sploh podpira?
• Mora je vprašanje obveznosti. Ali spremembo zahteva pogodba z naročnikom, zakon ali vaša lastna politika?

Težave nastanejo, ko se glagoli ne ujemajo. Kdor zna in sme, mora pa ne, bo spremembo odlagal. Kdor mora in zna, ne sme pa, bo spremembo naredil in prevzel tveganje, ki ga ne bi smel. Kdor mora in sme, zna pa ne, potrebuje pomoč, ki je ni naročil.

V tipičnem slovenskem proizvodnem podjetju je kriptografija razporejena po plasteh, ki jih upravljajo različni ljudje:

Zadnja vrstica je pomembna za vse, ki prodajajo izdelke z elektroniko. Tam ste vi proizvajalec in tam boste tisti, ki jih bodo kupci spraševali. Tej temi bomo posvetili izdajo aprila 2027.

Interni IT ne more spremeniti vsega. Mora pa vedeti, kdo sme in kdo zna, za vsako mesto v registru. To je njegova naloga in je ne more predati naprej, ker nihče drug nima pregleda nad celotnim podjetjem.

Hkrati interni IT ne sme spreminjati tistega, kar ni njegovo, tudi če bi znal. Sprememba nastavitev na napravi proizvajalca strojev lahko pomeni izgubo garancije. Sprememba postopka v certificiranem sistemu, na primer v avtomobilski ali medicinski verigi, lahko zahteva ponovno potrjevanje. Sprememba v kodi razvijalca brez dogovora lahko pomeni, da razvijalec za posledice ne odgovarja več.

Meja ni v znanju. Je v dogovoru.

Mislimo si podjetje s 90 zaposlenimi, ki izdeluje plastične dele za nemške proizvajalce gospodinjskih aparatov. V proizvodnji stoji dvanajst strojev za brizganje treh proizvajalcev. Dva proizvajalca imata v podjetju lastni napravi za daljinski servis. Sistem MES je izdelek slovenskega proizvajalca. Povezavo med MES in tiskalniki nalepk z naročnikovimi črtnimi kodami je napisal zunanji razvijalec. Naročila prihajajo prek EDI.

Ko je interni IT izpolnil matriko, je ugotovil:

• pri obeh servisnih napravah ne sme ničesar spremeniti in ne ve, s katerimi postopki delujeta;
• pri MES sme spremeniti potrdila, ne zna pa spremeniti postopkov, ker jih določa izdelek;
• pri povezavi s tiskalniki ni jasno, kdo sme, ker pogodba z razvijalcem pravic do kode ne ureja;
• pri EDI sme in zna zamenjati potrdilo, postopek pa določa naročnikov profil.

Edino mesto, kjer bi lahko jutri sam naredil spremembo, je bila požarna pregrada. Skromna tolažba, a vseeno. Vse ostalo je zahtevalo pogovor z nekom drugim. Matrika je pokazala, s kom.

Ko veste, kdo sme, je naslednje vprašanje, kako. Kriptografska sprememba ni nastavitev, ki jo kdo preklopi ob petkih popoldne. Je sprememba z vsemi posledicami:

• Preizkus pred uvedbo. Nov postopek mora delovati na obeh straneh povezave. Če ga podpira samo ena, povezava preneha delovati ali se vrne na stari postopek.
• Pot nazaj. Za vsako spremembo zapišite, kako se vrnete na prejšnje stanje.
• Obvestilo drugi strani. Pri povezavah z naročnikom spremembo vedno uskladite. Nenapovedana sprememba je za naročnika incident.
• Zapis. Kdo je kaj spremenil, kdaj, s čigavim soglasjem. Ta zapis je hkrati dokazilo.

Podjetja, ki že imajo urejen postopek upravljanja sprememb, morajo kriptografijo le vključiti vanj. Tista, ki ga nimajo, bodo ob postkvantnem prehodu prvič opazila, da ga potrebujejo.

Mnoga slovenska podjetja niso samo uporabniki tuje programske opreme. Za nemške naročnike razvijajo povezave, prilagoditve ali cele aplikacije. Takrat se glagoli obrnejo: naročnik bo spraševal, ali sme sam spremeniti kriptografijo v vaši kodi, ali to znate narediti vi in ali to morate po pogodbi.

Na to vprašanje se je dobro pripraviti, preden ga postavi naročnik:

• Vedite, kje je kriptografija v vaši kodi. Katere knjižnice, kateri postopki, kje so izbrani: v nastavitvah ali neposredno v kodi.
• Ključi naj ne bodo pri vas. Podpisni in prijavni ključi spadajo v naročnikovo infrastrukturo. Če so pri vas, ste postali del njegove varnostne verige, ne da bi kdo to načrtoval.
• Ponudite jasna pravila. Kaj sme naročnik spremeniti sam, kaj samo z vami, kaj je vzdrževanje in kaj nov razvoj.
• Postopkov ne zapečatite v kodo. Če je postopek izbran na enem mestu in ga je mogoče zamenjati z nastavitvijo, je sprememba jutri majhna naloga. Če je razpršen po kodi, je projekt. Arhitekturi za takšno zamenljivost bomo posvetili izdajo julija 2026.

Razvijalec, ki na ta vprašanja odgovori brez obotavljanja, ima pri nemškem naročniku dober argument proti cenejšemu konkurentu, ki odgovori z »bomo videli«.

1. Iz registra (izdaja 04) prepišite komponente. Ne sistemov: ERP ima več komponent z različnimi odgovornimi.
2. Za vsako zapišite: sme, zna, mora. Pri »sme« navedite podlago: licenca, pogodba, garancija.
3. Pri tujih napravah vprašajte lastnika. Proizvajalec strojev mora vedeti, kaj je postavil v vaše omrežje.
4. Preverite pogodbe z razvijalci. Kdo ima kodo, kdo sme spreminjati, kdo vzdržuje.
5. Odprte primere predložite vodstvu z možnostmi: pogodba, zamenjava, sprejeto tveganje.

„Welche Komponenten der Verbindung zwischen uns dürfen wir ohne Ihre Zustimmung ändern, und wie stimmen wir eine Änderung ab, die beide Seiten betrifft?“

Prevod: Katere komponente povezave med nama smemo spremeniti brez vašega soglasja in kako uskladimo spremembo, ki zadeva obe strani?

Zakaj tako? Ker tudi pri naročniku velja »sme«. Njegov EDI-profil, njegov portal, njegove zahteve glede potrdil. Z vprašanjem dogovorite pravila, preden jih kdo potrebuje. Nemški naročnik bo v tem prepoznal nekaj, kar sam imenuje Change-Management, in to zaupanje vzbuja.

Nemška izdaja te teme se obrača na IT-vodstvo in nabavo naročnikov: „Wer ist für die Umstellung verantwortlich?“ (v nemščini). Prejšnja izdaja: Naročnik zahteva postkvantno varnost. Kaj ga morate najprej vprašati?

Ena vrstica za vsako komponento s kriptografijo. Matrika dopolnjuje register (izdaja 04) in matriko RACI (izdaja 05). V nemški izdaji je vsebinsko enaka.

Meja predloge: matrika pokaže odgovornosti, ne pravnega položaja. Ali pravica do spremembe obstaja, v dvomu presodi pravna služba na podlagi pogodb.

Vse objavljene izdaje serije: pregled »Postkvantna varnost v dobavni verigi«

Naslednja izdaja (2. 2. 2026): »PQC v pogodbi: ste prevzeli odgovornost, ki je ne morete izpolniti?«

Viri (stanje 5. 1. 2026): NIS Cooperation Group, »A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography«, različica 1.1 (junij 2025), poglavje 6.

Če v matriki ostane več vprašajev kot imen, nam pišite.