Scenariji uporabe

Povzetek. Ta stran opisuje, zakaj zaupanje med organizacijami potrebuje lastno infrastrukturo, kaj prinaša posameznim ciljnim skupinam, za kaj se WKL TrustBridge uporablja, kako udeleženci sodelujejo v značilnih potekih in za kaj TrustBridge izrecno ni namenjen. Vsem scenarijem je skupno izhodišče: več samostojnih organizacij sodeluje, vsaka s svojimi sistemi, omrežji in pravili, in vsaka želi podeliti natanko toliko zaupanja, kolikor ga sodelovanje potrebuje, ter ga kadar koli odvzeti.

• Partner – organizacija v dobavni verigi, ki jo tehnično predstavlja njena izdajateljska CA.
• Sistem – partnerjev strežnik, storitev ali naprava, identificiran z natanko enim imenom DNS v imenskem prostoru partnerja.
• Preverjevalec – sistem, ki sprejme in preveri certifikat, na primer strežnik, ki zahteva odjemalski certifikat (mTLS); v TrustBridge je to praviloma adapter TLS.
• Razred profila – kategorija certifikatov s stalnimi pravili za vsebino, veljavnost in odobritev; ročni razredi zahtevajo odobritev osebe, samodejni potrditev storitve za vpis.
• Razmerje zaupanja – dvostranski dogovor dveh organizacij s politiko razmerja za vsako smer.

V dobavni verigi si podatke izmenjujejo sistemi različnih podjetij. Naročnik deli proizvodne podatke, dobavitelj vzdržuje del poslovnih aplikacij, servisni partner skrbi za opremo v obratu. Takšno sodelovanje danes največkrat sloni na mešanici dostopov VPN, zaupanja v skupno omrežje, centralnih uporabniških računov, certifikatov iz različnih virov, ročno vzdrževanih izjem in pogodb. Dokler je partnerjev malo, gre. Z vsakim novim partnerjem pa je težje povedati, kdo sme do česa, zakaj, od kdaj in kako se dostop spet zapre.

Pet razlogov govori za to, da se tako zaupanje upravlja z namensko infrastrukturo in ne mimogrede:

1. Identiteta prek meja podjetja. Certifikat javne certifikatne agencije dokazuje nadzor nad domenskim imenom, ne pa pripadnosti določenemu partnerju. Dobavna veriga potrebuje drugo trditev: ta sistem pripada partnerju A in se sme pojavljati samo v imenskem prostoru partnerja A. TrustBridge to zagotavlja z omejitvijo imen za vsakega partnerja (nameConstraints po RFC 5280).
2. Zaupanje je dvostransko, ne članstvo. Če A zaupa B in B zaupa C, iz tega ne sledi, da A zaupa C. Vsako razmerje se dogovori med natanko dvema organizacijama in se za vsako smer določi posebej.
3. Zakonska dolžnost varovanja dobavne verige. Direktiva NIS2 in njen nemški prenos, zakon BSIG, od zavezanih subjektov zahtevata, da obvladujejo varnost razmerij z dobavitelji in uporabo kriptografije (§ 30(2), točki 4 in 8 BSIG). Izdaja, odobritev in preklic, ki jih je mogoče dokazati, dajo revizorjem preverljiv odgovor.
4. Prehod na postkvantno kriptografijo. Usklajeni načrt EU zahteva, da se primeri uporabe z visokim tveganjem, med njimi izrecno PKI, do konca leta 2030 prestavijo na kvantno odporne algoritme. Sidra zaupanja pogosto veljajo deset do dvajset let, promet, posnet danes, pa je mogoče dešifrirati pozneje (shrani zdaj, dešifriraj pozneje). Zato TrustBridge že danes ščiti povezave z dodatno postkvantno skrivnostjo in izdaja hibridne certifikate.
5. Nadzor nad ključi in preklicem. Kdor sodeluje s partnerji, mora imeti možnost sodelovanje tudi končati, ne da bi čakal na tretjo stran, in mora znati pokazati, kdo je dal katero odobritev.

Ničelno zaupanje in vzajemno zaupanje si nista nasprotna. Ničelno zaupanje pomeni, da uporabniku, napravi, storitvi ali omrežnemu segmentu nikoli ne zaupamo samodejno. Vzajemno zaupanje v TrustBridge pomeni, da lahko dve organizaciji preverita dogovorjene kriptografske identitete in pogoje. Tudi takrat ciljna aplikacija vsako posamezno operacijo pooblasti sama.

Dobavitelj (partner A) vzdržuje del poslovnih aplikacij naročnika (partner B) in v ta namen samodejno pridobiva podatke. Doslej je za to potreboval dostop VPN in poverilnice za podatkovno bazo. S TrustBridge se dogovorita za razmerje, dobavitelj pa prek Database Gateway doseže natanko odobrene podatke.

sequenceDiagram
  participant A as zaloga.partner-a.example
  participant TA as Adapter TLS partnerja A
  participant TB as Adapter TLS partnerja B
  participant G as Database Gateway partnerja B
  A->>TA: zahteva
  TA->>TB: TLS 1.3, odjemalski certifikat, dodatna skrivnost PQ
  TB->>TB: veriga do sidra razmerja, nameConstraints, seznam preklicanih
  TB->>TB: storitev in namen v politiki partnerja B
  TB->>G: zahteva z identiteto partnerja
  G->>G: preveri pravilo za partnerja A
  G-->>TB: odobreni podatki
  TB-->>TA: odgovor
  TA-->>A: odgovor

Na čem sloni varnost. Naročnik dobavitelja ne prepozna po polju O ali CN, temveč po izdajateljski CA, ki jo je sprejel v razmerje. Ker je ta CA z nameConstraints omejena na partner-a.example, niti napačna ali zlonamerna izdaja pri A ne more ustvariti certifikata za ime partnerja B, ki bi prestal preverjanje. Kaj sme dobavitelj brati ali spreminjati, odloča izključno Gateway. Potek v podrobnostih opisuje stran Povezava z Database Gateway.

Ponudnik storitev (partner C) tri mesece vzdržuje napravo naročnika. Potrebuje dostop do dveh storitev, za ta namen in za ta čas.

1. Naročnik se s C dogovori za razmerje. V svoji smeri dovoli natanko obe storitvi, trajanje nastavi na tri mesece in zahteva dodatno postkvantno skrivnost.
2. C nima lastne PKI. V hierarhiji naročnika dobi partnersko CA; odgovorni pri C certifikate svojih sistemov odobrijo sami prek partnerskega portala.
3. Po treh mesecih razmerje poteče. Novih povezav ni več, ne da bi moral kdo zakleniti uporabniški račun ali odstraniti dostop VPN.
4. Če se sodelovanje konča prej, naročnik svojo smer takoj prekliče.

Industrijske naprave partnerja dobijo certifikat s kratko veljavnostjo in ga obnavljajo samostojno, ne da bi vsako obnovo odobrila oseba.

1. Naprava sama ustvari par ključev in pošlje CSR prek EST (simpleenroll) ali Lightweight CMP, pri obnovi s svojim dosedanjim certifikatom.
2. Pri prvi izdaji se izkaže z dokazom, ki ga zahteva njen razred profila: z vnaprej shranjeno enkratno vrednostjo, s proizvajalčevim certifikatom (IEEE 802.1AR) ali z atestacijo TPM.
3. Storitev za vpis preveri, da zahtevek ustreza samodejnemu razredu profila in je v imenskem prostoru partnerja, oblikuje naročilo in ga potrdi s svojim storitvenim ključem.
4. Delavec CA preveri potrditev glede na svoj pravilnik in izda certifikat.
5. Obnova se začne, ko ostane še tretjina veljavnosti; najkrajša veljavnost je tri dni, da enodnevni izpad storitve za vpis ne povzroči poteka.

Strežnik partnerja A velja za kompromitiranega; njegov certifikat mora takoj postati neuporaben.

Meja. Med preklicem in naslednjim prenosom pri preverjevalcu mine do šest ur. Kdor potrebuje hitrejši učinek, dodatno prekliče razmerje: nov sveženj zaupanja doseže adapterje TLS organizacije, ki preklicuje, v eni uri, na zahtevo takoj.

Izpad podatkovne baze. Preklic je mogoč tudi brez podatkovne baze: na konzoli gostitelja delavca CA. Seznam preklicanih certifikatov doseže distribucijo po drugi poti mimo podatkovne baze.

Vsi sistemi partnerja A naj naenkrat izgubijo dostop.

Partnerja se dogovorita, da mora biti njuna povezava zaščitena tudi pred prihodnjimi kvantnimi računalniki. Ločiti je treba dva varnostna cilja:

Prva grožnja je nujnejša, ker se napad začne že danes. Druga postane nujna, še preden obstaja kvantni računalnik, ker sidra zaupanja veljajo dolgo. Obe zahtevi vpiše politika razmerja; adapter TLS ju uveljavi pri vsaki povezavi.

Partner upravlja vmesnik, ki streže tako poljubnim odjemalcem HTTPS kot partnerskim sistemom.

TrustBridge nobenemu običajnemu odjemalcu HTTPS ne vsiljuje lastniške komponente. Hibridni certifikati ostanejo berljivi za klasične preverjevalce: alternativni podpis je v nekritičnih razširitvah, ki jih preverjevalec brez postkvantne podpore preskoči.

Posamezno podjetje uporablja TrustBridge za lastne storitve in naprave. Takrat je en najemnik z eno ali več izdajateljskimi CA; razmerja obstajajo med organizacijskimi enotami ali lokacijami z lastnimi imenskimi prostori.