Še en nemški kupec. Še ena povezava?

Nov kupec iz Nemčije pomeni dobro novico in nov seznam zahtev. Ena od njih se skoraj vedno glasi enako: podatke bi radi dobivali redno, po možnosti kar iz vašega sistema. Koliko dela je v resnici v »samo še eni povezavi«? In ali jo je treba vsakič zgraditi na novo?

Vzemimo podjetje s štiridesetimi zaposlenimi, ki izdeluje tesnila in ventile za procesno industrijo. Večino proizvodnje proda v Nemčijo, med kupci so upravljavci kemičnih in petrokemičnih obratov. Naročila, roke in zaloge vodi v poslovni aplikaciji, ki jo je pred leti razvil zunanji partner. Aplikacija je v Accessu, podatki v SQL Serverju. Deluje.

Ob podpisu pogodbe z novim kupcem direktor dobi dva dokumenta. Prvi so navodila za kupčev portal za dobavitelje, kjer bo treba potrjevati odpoklice. Drugi je prošnja kupčeve nabave: vsak ponedeljek bi radi prejeli pregled odprtih naročil z obljubljenimi roki, po možnosti tako, da ga lahko sami osvežijo.

Direktor pokliče zunanjega partnerja. Ta prisluhne in pove odkrito. Izvoz v Excel lahko pripravi, vendar bo nekdo moral vsak ponedeljek pritisniti gumb in ga poslati. Za samodejno povezavo s kupcem bo potreboval nekaj dni dela, pa še vzdrževanje, ker se bo pri kupcu prej ali slej kaj spremenilo. Pri drugem nemškem kupcu je bilo pred dvema letoma enako.

Direktor odloži telefon z vprašanjem, ki ga ne izreče na glas: ali bomo res za vsakega kupca gradili nov del sistema?

Na računu za integracijo je navadno ena številka. Pravi strošek je razpršen. Del gre na čas zunanjega partnerja, del na nekoga v podjetju, ki vsak teden preveri, ali je izvoz odšel. Del gre na popravke, ko kupec spremeni obliko datoteke. Nekaj pa stane tudi klic kupca, ki opazi, da so bili podatki stari.

Odločitve pri tem večinoma ne sprejema dobavitelj. Velik kupec ima svoj portal, svoj format in svoje roke, majhen dobavitelj pa se prilagodi, ker posel potrebuje. To ni očitek nemškim kupcem. Kupec s stotinami dobaviteljev mora imeti enoten postopek, sicer dobaviteljev ne obvlada. A tudi dobavitelj ima več kupcev in pri vsakem plača svoj del prilagoditve.

Pri tem niso vsi podatki enaki. Za račune bo v Sloveniji od 1. januarja 2028 med podjetji obvezna elektronska izmenjava, z jasno določenimi kanali. Za vprašanja, kot so »koliko je še na zalogi« ali »kdaj bo naročilo končano«, pa takšnega kanala ni. Prav tam nastaja največ ročnega dela.

Preden iščemo drugo pot, je pošteno priznati, zakaj obstajajo sedanje.

Excel po e-pošti si lahko kupčeva logistika uredi danes, brez svojega oddelka za informatiko. Deluje z vsemi. Podatki pa so stari že v trenutku pošiljanja, na obeh straneh pa z njimi nekdo dela ročno.

Portal za dobavitelje kupcu daje nadzor in voden postopek: potrditve, certifikati, reklamacije na enem mestu. Pri velikem številu dobaviteljev je to smiselno. Za dobavitelja pa pomeni še eno prijavo, še en vmesnik in ročni vnos podatkov, ki jih ima že v svojem sistemu.

EDI je pravo orodje za poslovne dokumente, ki potujejo med sistemi, na primer za dobavne načrte, dobavnice in račune. Ni pa narejen za odgovor na vprašanje, kaj je trenutno na zalogi. Za manjšega dobavitelja je priklop pogosto samostojen projekt.

VPN in prijava v podatkovno zbirko sta za zunanje podjetje redka izbira, in to upravičeno. VPN odpre omrežje, ne pa ene same tabele, vsako zunanje podjetje pa potrebuje svojo prijavo v SQL Server.

Namenski vmesnik (API) natančno sledi kupčevim pravilom. Vendar vsako novo vprašanje pomeni nov razvoj, Excel ga sicer lahko prek Power Query pokliče, odgovor v obliki JSON pa je treba večinoma ročno preoblikovati v tabelo. OData strukturo, metapodatke in filtriranje standardizira, zato ga Excel naloži kot tabelo neposredno.

Vsaka od teh poti je kje prava. Težava nastane, ko majhno vprašanje dobi velik odgovor.

Podatki, ki jih kupec želi, so v vašem SQL Serverju. Kupec ima Excel. In obratno: podatki o zalogi vaših izdelkov pri kupcu so v njegovem SQL Serverju, vi pa imate Excel. Excel zna brati standardni podatkovni vir OData, Power BI prav tako, Access pa z gonilnikom. Kaj torej še manjka?

Manjka ena odločitev na strani, ki ima podatke, in ta odločitev ima tri dele:

1. Kdo sprašuje? Vsaka oseba na drugi strani se prijavi s svojim ključem, ki ga lastnik podatkov izda, časovno omeji in kadar koli prekliče.
2. Kaj sme zahtevati? En objavljen pogled, samo za branje. Drugega zanjo ni.
3. Katere vrstice dobi? Podatkovna zbirka pogled filtrira po osebi, ki sprašuje. Vsak dobi le svoje vrstice.

Prvi dve odločitvi sprejme storitev pred podatkovno zbirko. Le ona doseže SQL Server, zahteve pa sprejema prek HTTPS. Tretjo sprejme SQL Server sam. Druga stran dobi le naslov in ključ, njen Excel pa ve, kaj z njima. Tako iz posamezne povezave s kupcem nastane nekaj večjega: infrastruktura, v kateri dostop do podatkov, poslovna aplikacija in zaščita povezave niso več neločljivo povezani.

Tako deluje Database Gateway, naša storitev za nadzorovan dostop do podatkov. Gre za naš izdelek, zato je to, kar sledi, naš opis. Preverite ga lahko v povezani dokumentaciji.

O tej smeri se govori redkeje, čeprav je pri nemških kupcih pogosta: kupec želi videti stanje vaših naročil, roke ali zalogo. Če vaša aplikacija hrani podatke v SQL Serverju, lahko tu ukrepate sami, brez kupčevega oddelka za informatiko.

Vrnimo se k proizvajalcu tesnil. Odprta naročila vseh kupcev so v eni tabeli, skupaj s stolpci, ki ostanejo interni, na primer kalkulacija. Zunanji partner doda dve stvari. Prva je kratka tabela, ki osebe pri kupcih poveže z njihovim podjetjem. Druga je pogled, ki pokaže le objavljene stolpce in le vrstice kupca, za katerega dela oseba, ki pošlje zahtevo:

CREATE VIEW objava.OdprtaNarocila AS
SELECT n.Kupec, n.Narocilo, n.Izdelek, n.Kolicina, n.ObljubljenRok
FROM dbo.Narocila AS n
WHERE EXISTS (SELECT 1 FROM objava.OsebaKupec AS ok
              WHERE ok.Kupec = n.Kupec
                AND ok.Oseba = CAST(SESSION_CONTEXT(N'wkl.person') AS nvarchar(256)));

Kalkulacije v pogledu ni, zato je kupec ne more prebrati. V podatkovnem prehodu partner ustvari eno pravilo (le ta pogled, samo za branje) in vsaki osebi pri kupcu izda osebni ključ. Pri vsaki zahtevi s takšnim ključem prehod zapiše ime osebe v kontekst seje podatkovne zbirke (SESSION_CONTEXT), in sicer samo za branje, pogled pa ga prebere od tam. Dokumentacija ta vzorec korak za korakom opisuje kot omejitev zastopnikov na njihove stranke.

Referentka v kupčevi nabavi nato v Excelu izbere Podatki > Pridobi podatke > Iz drugih virov > Iz vira OData, vpiše naslov, ki ste ji ga poslali, izbere Osnovno, kot uporabniško ime vpiše pkuser, kot geslo pa svoj ključ. V navigatorju vidi eno samo tabelo z naročili svojega podjetja. Osveži prinese stanje ob zadnjem vnosu v vaši aplikaciji. Excel ključ hrani v svojem upravitelju poverilnic, ne v delovnem zvezku.

Ko prehod deluje, je takšna osnovna predloga narejena v nekaj minutah. Postavitev prehoda, digitalnega potrdila in pravil je delo za vašega partnerja. Ko se oglasi naslednji nemški kupec z isto zahtevo, ne gre za nov razvoj. Gre za nove vrstice v tabeli povezav, nove osebe in nove ključe. To velja, dokler kupec želi iste podatke. Če potrebuje druga polja, drugačen postopek ali strožje varnostne zahteve, dobi svoj pogled ali več, in to pomeni dodatno delo.

Pri tem je pomembno, čigavi so podatki. Zaloga vaših izdelkov pri kupcu je v kupčevem sistemu. Tega pogleda ne morete postaviti vi. Lahko pa kupcu predlagate isti vzorec. Za njegov oddelek za informatiko je to en pogled za vse dobavitelje, ne poseben projekt za vsakega.

Opis na papirju še ni dokaz. Zato smo 5. novembra 2026 natanko tak primer postavili z aktualno izdajo prehoda, na ločeni preizkusni namestitvi s preizkusnimi tabelami, ki smo jih nato odstranili. V preizkusu so bili v vlogi zunanjih partnerjev dobavitelji, ki berejo podatke kupca. Mehanizem je enak tudi v obratni smeri.

V tabeli zalog so bili trije dobavitelji in interni stolpec s ceno. Dvema dobaviteljema sta bili dodeljeni po dve osebi, tretjemu nobena, ena oseba pa je imela pravilo, ne pa tudi dodeljenega dobavitelja. Pogled je bil brez stolpca s ceno, pravilo je veljalo le zanj, vsaka oseba pa je imela svoj osebni ključ. Vseh 20 preverjanj je dalo pričakovani rezultat:

1. Vsaka dodeljena oseba je prebrala le vrstice svojega dobavitelja. Oseba brez dodelitve ni dobila nobene vrstice.
2. Na zahteve po osnovnih tabelah in po tabeli, ki s preizkusom ni bila povezana, je prehod odgovoril »ni najdeno«. Enako je odgovoril na zahtevo po posamezni vrstici drugega dobavitelja, naslovljeno neposredno z njeno številko. Filter na drugega dobavitelja je vrnil nič vrstic.
3. Spreminjanje in dodajanje sta bila zavrnjena, enako lastna poizvedba SQL na tabelo zalog.
4. Štiri osebe so skupaj poslale 400 zahtev, do 16 hkrati. Noben odgovor ni vseboval tuje vrstice. Nato je ključ storitve brez osebe 50-krat prebral isti pogled in vsakič dobil nič vrstic. Ponovno uporabljena povezava torej ni prenesla osebe iz prejšnje zahteve.
5. Tudi prek našega gonilnika ODBC, v 64- in 32-bitni različici, so osebe videle le svoje vrstice.
6. Dnevnik dostopov je zabeležil 410 vnosov. Vsak navaja osebo, ključ, pravilo, ki je dostop dovolilo, zahtevani cilj in rezultat.

Kaj ta preizkus ni, je treba povedati enako jasno. Je naš lastni dokaz za en scenarij, ne neodvisna varnostna presoja in ne certifikat. 400 zahtev preverja, da se pri hkratnem delu nič ne pomeša. Merilo zmogljivosti to ni. Preverjali smo branje. Zapisovanje je bilo zavrnjeno, ker je bilo pravilo nastavljeno samo za branje.

Tu se v pogovorih rade pomešajo tri različne stvari.

Excel in Power BI berejo. Podatke naložita prek Power Query in jih osvežita. Kar nekdo vpiše v celico, se ne zapiše nazaj v podatkovno zbirko.

Access zna pisati. Prek našega gonilnika OData ODBC Access poveže tabele in poglede podatkovnega prehoda ter v podatkovnih listih in obrazcih spreminja podatke, če pravilo to dovoli. To smo preverili z meritvami, tudi v primeru, ko dve osebi hkrati spreminjata isti zapis. Access takrat pokaže svoj običajni spor pri pisanju in ničesar ne prepiše tiho (pisanje in spori pri pisanju). Za podjetje z obstoječo aplikacijo v Accessu to pomeni, da obrazci ostanejo, kot so (več o tem spodaj).

Potrditev naročila je postopek, ne le pravica. Če želite, da druga stran tako potrjuje roke, potrebujete cilj, narejen prav za to. To je lahko tabela ali shranjena procedura, ki v podatkovni zbirki preveri, da vsak potrdi le svoja naročila in le z veljavnimi vrednostmi. To je treba načrtovati in posebej preizkusiti. Naš preizkus je ne pokriva, prehod pa poslovne logike ne nadomesti. Kjer je potrditev zavezujoč poslovni dokument, ostane EDI prava pot.

Za majhno podjetje vsaka nova zahteva kupca najprej pomeni novo orodje, ki se ga je treba naučiti. Tu ni tako. Pri proizvajalcu tesnil iz začetka članka vodja proizvodnje obdrži svojo Excelovo preglednico, le da ob osvežitvi podatke prebere iz vira OData namesto iz izvoza. Serviser obdrži svoje poročilo v Power BI, podatki kupca so v njem le še en vir. Poslovna aplikacija v Accessu, ki jo je pred leti razvil zunanji partner, objavljeni pogled poveže prek gonilnika ODBC kot vsako drugo tabelo. Obrazci ostanejo, kot so, pisati pa lahko le tja, kamor to dovoli pravilo.

Pravice ostanejo pri tistem, čigar so podatki, in to na enem samem mestu: v podatkovnem prehodu, ki ga upravlja. Tam se določi, kateri pogled oseba vidi, ali sme brati ali pisati in kako dolgo njen ključ velja. Druga stran ne potrebuje računa v tujem sistemu in se ne uči tuje aplikacije. Tako ohrani vrednost tudi tisto, v kar ste že vložili: preglednice, poročila in aplikacija, ki teče že leta. Kako takšno aplikacijo razvijati naprej in nove različice zanesljivo spraviti do uporabnikov, opisuje Aplikacija v Accessu ni za odpis.

»Kdo bo to postavil, mi ali kupec?« Tisti, čigar so podatki. Za vaše podatke vi oziroma vaš partner, za kupčeve kupec. Podatkovni prehod teče na strežniku z Windows 10 ali 11, Windows Server 2016 ali novejšim ali na Linuxu (zahteve).

»Ali moramo zamenjati poslovno aplikacijo?« Ne. Pogled in prehod se postavita pred obstoječe podatke. Aplikacija v Accessu, ERP in Excelove predloge ostanejo. Spremeni se le pot, po kateri pridejo podatki do zunanjega partnerja.

»Ali je to varno?« Zunanji uporabniki ne dosežejo strežnika SQL, ampak le storitev prek HTTPS. Vsaka zahteva je zabeležena, tudi zavrnjena, preklic ključa pa velja od naslednje zahteve. Dve pravili je treba poznati. Prijave v SQL Server, s katero prehod bere pogled, ne sme neposredno uporabljati nihče drug, saj bi lahko sam nastavil kontekst seje. Pravice za lastne poizvedbe SQL zunanji partnerji nikoli ne dobijo, saj bi z njo dosegli tabele za pogledom. Podrobnosti so v varnostnem modelu in mejah zaupanja.

»Kaj, če osebo preimenujemo?« V zgornjem primeru gre povezava med osebo in podjetjem prek imena osebe, zato je treba ob preimenovanju popraviti tudi tabelo povezav. Prehod v kontekst seje zapiše tudi številko osebe iz svoje uprave (wkl.person_id), ki se ob preimenovanju ne spremeni. Pri novi postavitvi je bolje povezovati prek nje. Naš preizkus zgoraj je uporabljal ime.

»Kaj se zgodi s podatki, ko so pri kupcu?« Ostanejo pri njem. Prehod ne nadzoruje, kaj kdo shrani, posreduje ali natisne. Zato v pogled spada le tisto, kar druga stran potrebuje za svoje delo.

»Kaj, če kupec zahteva EDI?« Za dokumente je to prav. Pogled odgovarja na vprašanja, za katera EDI ni bil narejen, in oboje lahko obstaja hkrati.

»Koliko to stane?« Licenc po delovnih mestih ni. Stroški nastanejo s postavitvijo, z delom pri pogledih in pravilih ter z delovanjem prehoda: digitalno potrdilo, varnostne kopije, ločeno shranjen glavni ključ. Prehod je nova odvisnost. Če ne deluje, podatkov ne dobi nihče. Kako se stroški razvijejo pri več partnerjih, kaže računski primer v naslednjem razdelku.

Vprašanje direktorja iz začetka članka je bilo v resnici vprašanje o strošku vsakega naslednjega kupca. Odgovor je odvisen od vprašanja, ki si ga skoraj nihče ne zastavi dovolj zgodaj: ali vsi kupci želijo isto? Če ga, objavljeni pogled ni več le poizvedba. Postane podatkovna pogodba, nabor stolpcev z dogovorjenim pomenom, ki ga enkrat načrtujete, preizkusite in vzdržujete, vsi kupci pa se nanj lahko zanesejo.

Računski primer: dvajset zunanjih partnerjev, ki berejo podatke, tri leta, napor v človek-dnevih. Številke so predpostavke za nalogo, pri kateri partnerji podatke le berejo. To niso meritve in ne podatki iz projektov pri strankah. Vstavite svoje številke, oblika računa ostane enaka.

Brez skupne podatkovne pogodbe potrebuje vsak partner svoj pogled, kar v modelu pomeni 3 človek-dneve več za vsakega. V grafu je ta različica črtkana.

Pri dvajsetih partnerjih to pomeni 280 človek-dni za posamezne vmesnike, 155 za portal, 119 za dostopni sloj s svojim pogledom za vsakega partnerja in 59 s skupno podatkovno pogodbo. Pomembnejša od vsot je oblika črt:

• Posamezni vmesniki nimajo stalnega dela stroškov. Pri enem ali dveh partnerjih so zato najcenejši, v tem primeru do približno treh. Nato vsak naslednji partner stane toliko kot prvi.
• Portal ima visok stalni del in nizek strošek za vsakega partnerja. Zmore pa več kot branje. Kdor vodene postopke že tako potrebuje, ta stalni del plača v vsakem primeru.
• Dostopni sloj ima majhen stalni del. Razmik med modrima črtama je vrednost podatkovne pogodbe: veča se z vsakim partnerjem, ki bere isto.

V računu niso stroški licenc, delo na strani partnerjev ter usklajevanje in usposabljanje. Licenca za podatkovni prehod ni vezana na delovna mesta, ponudbo pripravi DATEC pro.

Za majhnega dobavitelja ima podatkovna pogodba še eno plat: pogajalsko moč. Kupčevemu portalu se težko izognete. Lahko pa ponudite nekaj, kar kupcu prihrani delo. Če isti nabor stolpcev ponudite vsem kupcem, imate en pogled namesto petih izvozov, vsak kupec pa ga v Excelu bere sam. Tudi podatkovna pogodba se sme spremeniti. Takrat ob prvi različici postavite drugo, na primer OdprtaNarocila_v2, staro pa pustite, dokler vsi ne preidejo nanjo. Tako se nobena kupčeva predloga ne pokvari čez noč.

Podatkovna storitev pred podatkovno zbirko ni naša iznajdba. Podobno delo opravlja pet razširjenih izdelkov, vsak s svojim poudarkom. Podatki so iz dokumentacije proizvajalcev, stanje 5. novembra 2026.

Podatkovni prehod ima ožji poudarek, njegova moč pa je v kombinaciji, ki je preverjena zgoraj: vrstice za vsako osebo loči podatkovna zbirka sama. Excel in Power BI berejo prek standardnega OData, ne da bi bilo treba na drugi strani kar koli namestiti. Access prek gonilnika ODBC piše tja, kamor to dovoli pravilo, in spor pri pisanju javi, namesto da bi podatke tiho prepisal. Ključi, pravila in dnevnik vseh partnerjev pa se upravljajo na enem mestu.

Razlika torej ni v tem, da drugi izdelki ne bi znali objaviti podatkovnih zbirk. Odločilno je, koliko obstoječe infrastrukture, poslovne logike in aplikacij je treba za dostop spremeniti. Pri vzorcu zgoraj dobi podatkovna zbirka pogled in tabelo povezav, poslovna aplikacija in Officeova orodja partnerjev pa ostanejo, kot so.

Zunanji partner, ki skrbi za več podjetij, pozna to sliko. Naročila so v SQL Serverju za aplikacijo v Accessu. Vzdrževanje strojev teče v poslovni aplikaciji na PostgreSQL, merilni sistem piše v MySQL, zgodovina naročil zadnjih dvajsetih let pa je v starejšem sistemu na Oracle. Nemški kupec bi rad videl nekaj iz več teh sistemov.

Če bi za vsako od teh podatkovnih zbirk posebej uredili dostop za kupce, bi prvotni problem le pomnožili: štiri vrste računov, štiri mesta za pravice, štirje dnevniki. Nadzorovan dostop do podatkov zato loči dvoje. Kdo sprašuje, kaj sme in kaj se zabeleži, se odloči na enem mestu, za vse vire enako. Kako se doseže posamezna podatkovna zbirka, ureja poseben modul za vsak sistem, ki ga dokumentacija podatkovnega prehoda imenuje ponudnik. Katere podatkovne zbirke je mogoče povezati, piše v zahtevah.

Za kupca bi to pomenilo en ključ, eno mesto, ki ga pozna, in en vir OData za vsak vir podatkov, ki jih v Excelu ali Power BI postavi drugega ob drugem. Za vas ali vašega partnerja pa en prehod za vzdrževanje, ne glede na to, koliko sistemov je za njim.

Od tega nimajo koristi le kupci. Tudi lastni razvijalci ali zunanji partner lahko nove aplikacije gradijo na objavljenih pogledih in tabelah, prek OData ali gonilnika ODBC, namesto da bi v vsaki aplikaciji znova urejali povezave s podatkovno zbirko, poverilnice in pravice.

Kdor načrtuje povezovanje sistemov, naj ve, da integracije podatkov to ne nadomesti. Storitev ne združuje tabel iz različnih podatkovnih zbirk. Združi jih prejemnik, na primer v Power Query, ali pa se združijo že prej v eni od podatkovnih zbirk. Tudi filtriranje vrstic ostane stvar posameznega sistema: pogled iz primera bere osebo, ki sprašuje, iz SESSION_CONTEXT v SQL Serverju, in tam smo vzorec tudi preverili.

Prej ali slej v kupčevem vprašalniku pride vprašanje o postkvantni kriptografiji, pogosto kar v nemščini, na primer »quantensicher gemäß BSI?«. Za majhno podjetje je to neprijetno vprašanje, ker se zdi, da kupec pričakuje kratek »da«. Ni naključje, da pride do vas: nemške smernice organizacijam priporočajo, naj zahteve za kriptografijo prenesejo v dobavno verigo in nabavo. Podobna vprašanja lahko pričakujete tudi od slovenskih naročnikov, saj URSIV zavezancem po ZInfV-1 od avgusta 2026 priporoča vprašalnik za dobavitelje.

Najprej mirna presoja. Podatki o zalogi danes čez tri mesece nikogar več ne zanimajo. Pri njih je tveganje, da nekdo promet posname zdaj in ga pozneje razvozla s kvantnim računalnikom, majhno. Pri cenah, recepturah ali pogodbah, ki morajo ostati zaupne deset let, je drugače. Vprašanje je torej odvisno od podatkov, ne od tehnike. Kako oceniti, koliko časa morajo vaši podatki ostati zaupni, opisuje Kako dolgo morajo vaši podatki ostati skrivnost?

Nekaj pa velja skoraj za vsako povezavo med dvema podjetjema: postopke, ki jo ščitijo danes, bo treba v njeni življenjski dobi vsaj enkrat zamenjati. Kako boleča bo ta menjava, se odloči veliko prej, namreč s tem, kje je katera odgovornost. Tri so:

• Poslovna aplikacija, na primer skladiščni sistem, ERP ali aplikacija v Accessu, je odgovorna za podatke in poslovno logiko. O partnerjih ji ni treba vedeti ničesar.
• Dostop do podatkov odloča, kdo sme brati ali pisati kateri pogled, in vsako zahtevo zabeleži. To je naloga podatkovnega prehoda.
• Kriptografsko zaupanje odloča, katero podjetje se pogovarja s katerim, na kakšni podlagi in s katerimi postopki. To je naloga TrustBridge.

Ločitev se obrestuje, ko se kaj spremeni. Ko se spremeni priporočilo za postopek, lahko ločena arhitektura spremembo omeji na raven komunikacije in zaupanja, namesto da bi jo morali prenesti skozi vse poslovne aplikacije. Pogledi, pravila in Excelove predloge praviloma ostanejo, kot so. Kako daleč to seže, je odvisno od posamezne integracije: kar aplikacija šifrira ali podpisuje sama, se mora spremeniti skupaj z njo. Ko pride nov kupec, je to novo pravilo in novo razmerje, ne sprememba kriptografije. Ko pride nova podatkovna zbirka, partnerji ne potrebujejo novih ključev ali povezav, za Excel, Power BI in Access se navadno spremeni le naslov. Temu, da lahko postopke menjate načrtovano in ne da bi se kaj pokvarilo, pravimo kriptografska agilnost. Ne prinese je izdelek. Prinese jo to, da postopkov ne vgradite v poslovne aplikacije, račune VPN ali prijave v podatkovno zbirko pri vsakem partnerju posebej. Zakaj je to težava, kadar je algoritem del poslovne logike, opisuje prispevek Če je vaš kriptografski algoritem del poslovne logike, imate problem.

Za raven zaupanja je zasnovan TrustBridge, in sicer kot dodatek, ne kot pogoj. Dostop do podatkov deluje prek običajnega HTTPS. TrustBridge pride v poštev, kjer se dve podjetji želita o zaupanju izrecno dogovoriti: vsako obdrži svoja digitalna potrdila, dogovorita pa se za omejeno razmerje, ki ga lahko vsaka stran prekliče. Tehnično zasnova predvideva TLS 1.3 s hibridno izmenjavo ključev, torej klasično in ML-KEM po FIPS 203, dodatno, neodvisno ustvarjeno postkvantno skrivnost in potrdila z dodatnim podpisom ML-DSA po FIPS 204. Postopki in parametri sledijo nemški smernici BSI TR-02102-1. Hibridni postopek pa ščiti le tam, kjer ga zahtevata obe strani. Kako se to poveže s podatkovnim prehodom, opisuje dokumentacija o povezavi s podatkovnim prehodom.

Kdaj so take menjave na vrsti, določajo priporočila, obveznosti in pogodbe. Vse tri je lahko pomešati:

• Priporočila. Načrt EU za PQC državam članicam priporoča, da do konca leta 2026 naredijo prve korake, do konca 2030 preidejo pri primerih uporabe z visokim tveganjem in do konca 2035 pri tistih s srednjim. URSIV zavezancem po ZInfV-1 in drugim organizacijam priporoča, naj prehod začnejo že zdaj. Nemška tehnična smernica BSI TR-02102-1 (izdaja 2026-01) klasično izmenjavo ključev samostojno priporoča le še do konca 2031, od leta 2032 torej le v kombinaciji s postkvantnim postopkom. Klasični podpisi samostojno naj bi ostali priporočeni predvidoma do konca 2035. Zakona, ki bi podjetjem na splošno določal rok za postkvantno kriptografijo, nismo našli.
• Obveznosti. NIS2 od zavezancev zahteva ukrepe po stanju tehnike. Nemški § 30 BSIG med njimi izrecno navaja koncepte za uporabo kriptografije, roka za postkvantne postopke pa ne določa. Trdni rok, konec 2030, velja za nemške izdelke, odobrene za tajne podatke.
• Pogodbe. V praksi rok največkrat pride prek pogodb in vprašalnikov.

Vse datume z virom in statusom navaja naša referenčna stran o BSI TR-02102.

Nekaj je smiselno storiti že zdaj, ne glede na datume. Povezave s kupci vpišite v svoj popis kriptografije, skupaj s tem, kdo katero nadzira. Podatke, ki si jih izmenjujete, razvrstite po tem, kako dolgo morajo ostati zaupni. Ko pa vprašalnik vpraša, ne odgovorite s kratkim »da«, ampak s tem, kar lahko pokažete, in posebej navedite, kaj je načrtovano in do kdaj. Tak odgovor je pošten in vas pri kupcu ne postavi v slabši položaj. Kako se nanj pripraviti, opisuje Nemški vprašalnik o postkvantni varnosti: kaj lahko dokažete?

Katera pot ustreza kateri nalogi, grobo razvrstijo tri vprašanja:

Smiselno je, če

• gre v glavnem za branje trenutnega stanja: zaloge, odprta naročila, roki, statusi,
• več kupcev ali dobaviteljev potrebuje enako vrsto podatkov,
• druga stran dela v Excelu, Power BI ali Accessu,
• in je lastnik podatkov pripravljen določiti pogled ter vzdrževati storitev pred svojimi podatkovnimi zbirkami.

Ni dovolj ali ni smiselno, če

• si izmenjujete zavezujoče poslovne dokumente. Za to je EDI.
• gre za voden postopek z odobritvami in prilogami. Za to so portali.
• podatki sploh niso v podatkovni zbirki, ampak na primer le v datotekah ali aplikacijah v oblaku. Za to je primernejši kateri od izdelkov zgoraj.
• podatki sploh ne smejo zapustiti podjetja, niti kot kopija na drugi strani.

Kaj se je spremenilo? Kupčeva referentka v nabavi ob ponedeljkih ne čaka več na izvoz. Osveži svojo preglednico in vidi stanje ob zadnjem vnosu. Pri vas nihče več ne pritiska gumba za izvoz, vašega SQL Serverja pa kupec ne vidi.

Direktor iz začetka članka ni potreboval novega sistema. Potreboval je odgovor na vprašanje, ali je treba za vsakega kupca graditi nekaj novega. Za naročila, ki jih kupci želijo videti, lahko zadošča en pogled za vse. Za zalogo pri kupcu lahko kupcu predlaga enak pogled na njegovi strani. Za odpoklice v portalu in za račune pa ostane pri obstoječih kanalih. In ko kupec vpraša po kvantnih računalnikih, ve, kje je pri njem katera odgovornost, in lahko pokaže, kar ima.

Če vam nova zahteva nemškega kupca znova odpira vprašanje portala, povezave ali dodatnega razvoja, se najprej pogovorite o tem, kaj že imate. Svetovanje, ponudbe in podporo za podatkovni prehod v Nemčiji ureja Sönke Dobat pri DATEC pro v Hamburgu. Prinesite seznam podatkov, ki jih kupec od vas zahteva vsak teden. Skupaj boste hitro videli, ali zadošča pogled ali je primernejša druga pot. Za vprašanja informacijske varnosti in predpisov lahko k pogovoru povabi prof. dr. Linusa Schleupnerja, ki pri DATEC pro vodi projekt o postkvantnem šifriranju v avtomatiziranih sistemih, financiran iz sredstev Evropske unije in dežele Severno Porenje-Vestfalija.

• E-pošta: sd@datecpro.de
• Telefon: +49 40 77127-123
• DATEC pro GmbH, Nartenstraße 19, 21079 Hamburg, Nemčija

V slovenščini se lahko najprej pogovorite z Željkom Petrušićem, ki pri DATEC pro vodi ekipo za razvoj programske opreme.

• Telefon: +386 51 675 840

Če želite podrobnosti najprej preveriti sami, sta v dokumentaciji strani ozadje, primeri uporabe in alternative in nalaganje podatkov v Excel s Power Query. Kako je storitev nastala, pripoveduje Delo od doma 2020: aplikacija je delovala. Je bila arhitektura pripravljena?