Vmesniki in integracija
Povzetek. WKL TrustBridge razlikuje štiri vrste vmesnikov: standardizirane protokole za partnerske sisteme (ACME, EST, CMP), javno distribucijo certifikatov CA, seznamov preklicanih certifikatov in svežnjev zaupanja prek HTTP, strokovni upravljalni API za upravljalno aplikacijo, partnerski portal in avtomatizacijo ter lokalne vmesnike adapterja TLS in agenta ključev na vsakem povezanem strežniku. Standardizirane končne točke so izvedene nespremenjeno; lastni vmesnik obstaja samo tam, kjer standarda ni. Vse poti vodijo do istih strokovnih operacij in istih pravic.
Pojmi
- Protokolni adapter – komponenta, ki standardni protokol izvede v celoti (sporočila, podpisi, stanja, formati napak) in strokovno odločitev preda skupnemu jedru.
- Strokovno jedro – upravljanje in jedro vpisa: pooblastitev, najemnik, oblikovanje naročila, revizija.
- OData v4 – standard OASIS in ISO/IEC za vmesnike REST s strojno berljivo shemo, možnostmi poizvedb in akcijami.
- Ukaz – operacija, ki učinkuje na več kot eno vrstico, ustvari naročilo ali vrne skrivnost; izvedena kot akcija OData oziroma
POST.
Pregled
graph TD
subgraph EXT [Standardni protokoli]
ACME[ACME<br/>RFC 8555]
EST[EST<br/>RFC 7030]
CMP[Lightweight CMP<br/>RFC 9483]
end
subgraph MGM [Strokovni API]
OD[Upravljalni API<br/>OData v4, akcije]
end
subgraph PUB [Javna distribucija]
AIA[Certifikati CA<br/>HTTP GET]
CDP[Seznami preklicanih<br/>HTTP GET]
TB[Svežnji zaupanja<br/>HTTP GET]
end
PS[Sistemi partnerjev] --> ACME
PS --> EST
PS --> CMP
ADM[Upravljalna aplikacija] --> OD
PP[Partnerski portal] --> OD
AUT[Avtomatizacija] --> OD
PR[Preverjevalci] --> AIA
PR --> CDP
TLA[Adapterji TLS, agenti ključev] --> TB
ACME --> K[Strokovno jedro]
EST --> K
CMP --> K
OD --> K
K --> DB[(Naročila)]
classDef std fill:#deecf9,stroke:#0078d4,color:#201f1e
classDef own fill:#f3f2f1,stroke:#605e5c,color:#201f1e
classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
class ACME,EST,CMP,AIA,CDP,TB std
class OD,K,PP own
class ADM,AUT,PR,PS,TLA par
class DB onl
style EXT fill:#ffffff,stroke:#8a8886,color:#201f1e
style MGM fill:#ffffff,stroke:#8a8886,color:#201f1e
style PUB fill:#ffffff,stroke:#8a8886,color:#201f1eNačelo: standardi nespremenjeni, lastni API samo, kjer standarda ni
Partnerski sistem za običajne postopke PKI ne bi smel potrebovati lastnega odjemalca TrustBridge. Zato so standardizirane končne točke izvedene natanko tako, kot jih opisuje specifikacija – vključno z njihovimi potmi in formati napak –, namesto da bi jih prevajali v lastno konvencijo poimenovanja. Pri velikih ponudnikih zasebnih CA je vzorec enak: sistemi uporabljajo protokole IETF, upravljanje pa lasten, na vire usmerjen API.
Protokolni adapterji
Načelo ovojnice. Adapter je popoln v protokolu in tanek v strokovni logiki:
| Odgovornost | Adapter | Strokovno jedro |
|---|---|---|
| Protokol HTTP, formati sporočil, podpisi protokola | da | ne |
| Stanja protokola (na primer naročilo ACME, nonce) | da | ne |
| Pooblastitev | zagotovi kontekst (račun, odjemalski certifikat) | odloči |
| Preverjanje zahtevka glede na razred profila in imenski prostor | ne | da |
| Oblikovanje naročila, atestacija samodejnih razredov | ne | da |
| Revizija | zagotovi protokolne dogodke | piše varnostni revizijski dnevnik |
| Napake | prevede v format protokola | zagotovi strokovne napake |
Jedru ni treba vedeti, kaj je naročilo ACME; razume: pooblaščen udeleženec zahteva certifikat za določeno identiteto v določenem razredu profila. Ne podpisuje se ne v adapterju ne v jedru, temveč pozneje v delavcu CA; noben adapter ne čaka na podpis.
ACME (RFC 8555)
| Vidik | Določitev |
|---|---|
| Vstopna točka | imenik (directory) na poljubno izbranem naslovu; imena operacij (newNonce, newAccount, newOrder, revokeCert, keyChange) so standardizirana, njihove poti ne |
| Vezava na najemnika | računi ACME se prek External Account Binding vežejo na najemnika; račun brez vezave ne dobi ničesar |
| Dokaz nadzora nad imenom | http-01, dns-01 ali tls-alpn-01 za imena v imenskem prostoru partnerja; katere vrste so za posameznega partnerja dovoljene, določi razred profila |
| Izdaja | zaključek naročila ACME ustvari naročilo; certifikat je na voljo, ko ga delavec CA izda (ACME predvideva asinhrono obdelavo) |
| Preklic | revokeCert z dokazom posesti ključa certifikata ali prek računa |
EST (RFC 7030)
| Končna točka | Uporaba |
|---|---|
/.well-known/est/cacerts | pridobitev certifikatov CA |
/.well-known/est/simpleenroll | prva izdaja, overjena z dokazom razreda profila (enkratna vrednost, certifikat naprave ali atestacija TPM) |
/.well-known/est/simplereenroll | obnova z dosedanjim certifikatom |
/.well-known/est/serverkeygen | ustvarjanje ključa na strežniku: se ne ponuja, TrustBridge ne ustvarja ključev za vlagatelje |
Dodatni segmenti poti za vsako CA ali profil so po RFC 7030 dovoljeni.
Lightweight CMP (RFC 9483)
Lightweight CMP je razširjen v industrijskih napravah in krmilnikih. TrustBridge ga ponuja za razrede profilov strojev in naprav, s proizvajalčevim certifikatom (IEEE 802.1AR) kot dokazom za prvo opremljanje. Kot pri ACME in EST adapter samo ustvari naročilo; podpiše se v delavcu CA.
SCEP
SCEP se ne ponuja. Prvo opremljanje overi s skupnim geslom izziva, ki zahtevam za prvo opremljanje ne zadošča. Sistemi za upravljanje naprav, ki podpirajo samo SCEP, se povežejo prek predhodne storitve z EST ali CMP.
Upravljalni API
Upravljalni API je edini strokovni vmesnik za upravljalno aplikacijo, partnerski portal in avtomatizacijo. Vsi gredo skozi ista preverjanja, pravice in revizijske vpise; ali ukaz prihaja iz Accessa ali iz skripta, ni pomembno.
| Vidik | Določitev |
|---|---|
| Oblika | OData v4: množice za branje (filtriranje, razvrščanje, ostranjevanje, štetje, združevanje), akcije za ukaze; strojno berljiva shema; iz nje ustvarjen opis OpenAPI za orodja brez OData |
| Imena | angleška imena virov in polj (na primer certificates, certificate-requests, trust-relationships) |
| Ukazi | ustvarijo naročila in odgovorijo, ko so ta shranjena; noben ukaz ne čaka na delavca CA |
| Idempotentnost | Idempotency-Key pri vsakem pisalnem klicu; ponovitev dobi prvi odgovor |
| Konflikti pri pisanju | različica vrstice kot ETag, If-Match, odgovor 412 |
| Napake | format napak OData s stalnim identifikatorjem in sporočilom v jeziku klicatelja; brez ključa, podpisa in dobesedne napake podatkovne baze |
| Najemniki | objekt zunaj lastnega obsega vidnosti je 404, ne 403 |
| Prijava oseb | osebni ključ v glavi; drugi faktor prek izziva (401 z napotilom na naslov za zamenjavo enkratne kode za sejo); za vsako osebo, tudi samo za branje. V domenah Windows po izbiri prijava Windows prek Kerberosa |
| Prijava programov | mTLS z odjemalskim certifikatom lastne certifikatne agencije |
| Proste poizvedbe v podatkovni bazi, transakcije prek več zahtev | se ne ponujajo |
| Različice | glavna različica v poti; napoved konca različice prek glav Deprecation (RFC 9745) in Sunset (RFC 8594) z najkrajšim rokom dvanajstih mesecev |
Zakaj OData in ne čisti seznami REST. Upravljalna aplikacija sezname povezuje prek gonilnika ODBC, ki podpira izključno OData; čistih seznamov REST ne more povezati. OData je standard REST; iz njega ustvarjeni opis OpenAPI služi orodjem brez OData. Druga bralna površina REST poleg množic OData bi iste podatke dostavljala dvakrat in bi jo bilo treba dvakrat pooblaščati in preverjati.
Zakaj ne OAuth za osebe. Gonilnik ODBC upravljalne aplikacije podpira ključe v glavi, prijavo Windows in osnovno prijavo, ne pa žetonov Bearer. Za osebe zato ostane osebni ključ z drugim faktorjem.
Varnostna analiza prijave oseb
Prijava oseb – osebni ključ v glavi, drugi faktor prek enkratne kode, seja v glavi – je prilagojena zmožnostim gonilnika ODBC upravljalne aplikacije. Ta prilagoditev ne sme določati ravni varnosti; naslednja analiza zato prijavo oceni glede na ustrezne grožnje.
| Grožnja | Ocena | Ukrep | Preostalo tveganje |
|---|---|---|---|
| Kopiranje osebnega ključa | Ključ je skrivnost imetnika (256 bitov naključja), shranjena v shrambi poverilnic računa Windows; zlonamerna programska oprema z uporabniškimi pravicami ga lahko prebere | drugi faktor za vsako osebo; datum poteka za vsak ključ; pravila izvora (omrežni obsegi) | kopiran ključ sam ne zadošča, skupaj s prestreženo kodo pa zadošča |
| Prestrezanje enkratne kode (lažno predstavljanje v realnem času) | enkratne kode iz aplikacije niso odporne proti lažnemu predstavljanju | pravila izvora; koda velja samo enkrat | ostane; postopkov, odpornih proti lažnemu predstavljanju (FIDO2, pametna kartica), gonilnik ne podpira |
| Ponovitev zahteve | prenos prek TLS; vsaka enkratna koda se sprejme natanko enkrat; pisalni klici nosijo ključ idempotentnosti, ponovitev dobi prvi odgovor in ne učinkuje dvakrat | M-40, idempotentnost | majhno |
| Kraja sejnega žetona | Seja velja samo skupaj s ključem, s katerim je bila odprta; žeton sam ne odpre ničesar | vezava na osebo, postopek in ključ | vezave na napravo ali kanal TLS ni; zlonamerna programska oprema na isti delovni postaji lahko sejo souporablja |
| Potek | seje se končajo po določenem času; ključi imajo datum poteka | M-44 | zloraba znotraj trajanja seje |
| Izguba naprave | ključ je v shrambi poverilnic izgubljene naprave; aplikacija za enkratne kode na telefonu | takojšen preklic ključa konča vse seje, vezane nanj; drugi faktor ponastavi druga pooblaščena oseba z revizijskim vpisom | čas do prijave izgube |
| Odvzem pravic | pravice se preverijo pri vsaki zahtevi, ne hranijo se v seji | M-43 | nobeno, razen pri zahtevi, ki že teče |
| Kompromitirana delovna postaja zaposlenega | napadalec deluje s pravicami osebe, dokler seja velja: predlaga in stornira naročila, sproži preklice, bere | odobritve potrebujejo ločen ključ za odobritev na lastni strojni opremi s potrditvijo osebe (M-45); pravilo dveh oseb v občutljivih razredih | zlonamerna programska oprema lahko potvori prikaz naročila; proti temu pomaga samo druga, neodvisna odobritev ali prikaz na napravi za odobritev |
Prijava Windows. V domenah Windows se osebe po izbiri prijavijo prek Kerberosa (Negotiate). S tem odpade shranjena skrivnost imetnika; s prijavo v Windows s pametno kartico je prijava odporna proti lažnemu predstavljanju. Varnost je tedaj odvisna od domene; vsaka organizacija izbere postopek za svoje osebe.
Odobritev prek API
Odobritev ni prijavljena potrditev, temveč podpis osebe nad zgoščeno vrednostjo naročila. Potek prek API:
sequenceDiagram participant P as Oseba participant A as Upravljalna aplikacija participant V as Upravljalni API P->>A: odpre naročilo A->>V: pridobi bajte naročila V-->>A: bajti, nespremenjeni A->>A: izračuna SHA-256, primerja z identifikatorjem,<br/>prikaže vsebino iz natanko teh bajtov P->>A: odobri A->>A: podpiše zgoščeno vrednost z osebnim ključem A->>V: akcija: oddaj odobritev (podpis) V->>V: shrani, ne preverja Note over V: preverjanje opravi delavec CA
API ne priča o ničemer in podpisa ne preverja; samo ga posreduje. Ključ za odobritev je na pametni kartici ali varnostnem ključu s funkcijo PIV in za vsak podpis zahteva PIN osebe.
Stanja in napake
Ukazi upravljalnega API spreminjajo stanja samo v podatkovni bazi; rezultat delavca CA se pozneje pokaže kot projekcija. Za upravljalno aplikacijo to pomeni: po ukazu se naročilo prebere znova, na odgovor delavca CA se ne čaka.
| Stanje naročila v API | Pomen | Možni ukazi |
|---|---|---|
| čaka odobritev | shranjeno, čaka na odobritve | oddaj odobritev, storniraj |
| odobritev popolna | odobritve so na voljo | storniraj |
| prevzeto | delavec CA ga obdeluje | ni |
| izdano / zavrnjeno | rezultat iz registra | ni; pri zavrnitvi z razlogom |
| stornirano, poteklo | dokončno | ni |
| Status | Uporaba |
|---|---|
400 | vhod ni dovoljen (na primer CSR brez dokaza posesti, ime zunaj imenskega prostora, nedovoljen razlog za preklic) |
401 | ni prijave ali je zahtevan drugi faktor |
403 | prijavljen, a brez potrebne pravice |
404 | ne obstaja ali je zunaj obsega vidnosti |
409 | stanje ukaza ne dovoli (na primer odobritev za stornirano naročilo) |
412 | zastarela različica vrstice |
503 | hramba podatkov ni dosegljiva |
Prehod v „odobritev popolna“ nastavi delavec CA, ker samo on pozna pravila odobritve svojega pravilnika. Do takrat API prikazuje oddane odobritve.
Upravljalna aplikacija
Upravljalna aplikacija je orodje zaposlenih v organizaciji in pri njenem operativnem partnerju (upravljanje sistema, upravljanje partnerjev, podpora). Je aplikacija Access, ki kliče izključno upravljalni API: seznami so povezane množice OData, ukazi tečejo prek razreda VBA. Povezava odjemalca s podatkovno bazo je izključena.
Partnerski portal
Partnerski portal je spletni vmesnik za odgovorne pri partnerju, katerega izdajateljska CA je v hierarhiji naročnika. Uporablja isti upravljalni API z obsegom vidnosti za vsakega partnerja: oddaja zahtevkov, odobritev lastnih naročil, vpogled v inventar in stanje preklica lastnega imenskega prostora, sprožitev preklicev. Partnerji z lastno namestitvijo uporabljajo lastno upravljalno aplikacijo.
Vmesniki na povezanem strežniku
| Vmesnik | Uporaba |
|---|---|
| Odhodna vrata adapterja TLS | lokalna aplikacija se poveže z lokalnim naslovom; adapter vzpostavi zaščiteno povezavo z nasprotno stranjo |
| Dohodna vrata adapterja TLS | adapter sprejme povezave partnerjev in jih posreduje lokalni aplikaciji |
| Posredovanje identitete partnerja | pri HTTP v glavah z organizacijo, imenom storitve, razmerjem in namenom; aplikacija sme biti dosegljiva samo prek adapterja |
| Vmesnik posrednika ključev | samo za storitveni račun adapterja TLS, z zaščito dostopa operacijskega sistema |
| Certifikata adapterja in agenta | samodejna obnova prek ACME ali EST pri lastni certifikatni agenciji |
| Podatki o stanju | lokalna poizvedba o razmerjih, veljavnosti skrivnosti, zadnji izmenjavi in zadnjih zavrnitvah, brez ključnega gradiva |
Česa ta stran ne določa
- SCEP in ustvarjanja ključev za vlagatelje.
- Oskrbe kratkoživih delovnih obremenitev z identitetami prek SPIFFE Workload API. TrustBridge dodeli natanko eno ime DNS za vsak sistem; imena URI niso predvidena.
- Oblikovanja upravljalne aplikacije in partnerskega portala. Ta stran opisuje vmesnik, ki ga uporabljata, ne njunega uporabniškega vmesnika.
Viri
- RFC 8555 – ACME: imenik, računi, naročila, dokazi, External Account Binding (razdelek 7.3.4).
- RFC 7030 – EST: končne točke pod
/.well-known/est/, avtentikacija, neobvezni segmenti poti. - RFC 9483 – Lightweight CMP Profile: profil za industrijske naprave.
- OData Version 4.01: protokol, format sheme, možnosti poizvedb.
- RFC 9745 – glava Deprecation in RFC 8594 – glava Sunset: napoved konca različice API.