Pred naročilom ocene pripravljenosti na postkvantno kriptografijo (PQC) določite, kateri dokazi bodo omogočili uporabo popisa pri odločanju o prehodu. Zahtevajte sledljive povezave med poslovnimi storitvami, aplikacijami, kriptografskimi operacijami, ključi, certifikati, dobavitelji in odgovornimi osebami.
PQC označuje kriptografske metode, zasnovane za odpornost proti napadom s klasičnimi in kvantnimi računalniki. Nacionalni center odličnosti za kibernetsko varnost (NCCoE) pri ameriškem Nacionalnem inštitutu za standarde in tehnologijo (NIST) povezuje odkrivanje uporabe kriptografije z upravljanjem tveganj in določanjem prednostnih nalog pri prehodu. Njegov projekt je podlaga za preverjanje, kje se kriptografija uporablja in kaj je od nje odvisno. Projekt prehoda na PQC pri NIST NCCoE
NIST v pogostih vprašanjih opisuje popis, ki zajema sisteme, aplikacije, storitve, naprave in podatkovne tokove. Stran kot datum posodobitve navaja 30. junij 2026; sam datum ne dokazuje, da so bile smernice za popis takrat objavljene prvič. NIST: pogosta vprašanja o prehodu na PQC
Spodnji prevzemni seznam in zahteve za pogodbo so avtorjeva priporočila za naročanje, oblikovana ob upoštevanju teh virov. Ne gre za NIST-ovo certifikacijsko shemo ali predpisan podatkovni model popisa. Pred podpisom pogodbe zahtevajte, da izvajalci izpolnjevanje zahtev ponazorijo z vzorčnimi zapisi.
Dogovorite se o prevzemnih merilih.
| Kaj naj popis izkaže | Zahtevani dokazi | Razlog za zavrnitev prevzema |
|---|---|---|
| Pokritost poslovnih storitev | Register storitev in aplikacij, usklajen z odkritimi sredstvi, okolji, podatkovnimi tokovi in odgovornimi osebami | Predložene so le domene, naslovi ali rezultati pregledovanja javnih sistemov |
| Natančen kriptografski kontekst | Točni algoritmi in ustrezni parametri; različice protokolov, knjižnic in izdelkov; ločeni dokazi o podpori, nastavitvah, opaženi uporabi in dobaviteljevih navedbah | Edini podatek je družina algoritmov, denimo »RSA«, ali navedba »uporablja TLS« |
| Ločene kriptografske vloge | Ločeni zapisi za javne ključe v certifikatih, podpise izdajateljev, avtentikacijo povezav, vzpostavljanje ključev in zaščito podatkov | Algoritem v certifikatu se obravnava kot dokaz mehanizma za vzpostavljanje ključev v povezavi |
| Odgovornost za ključe in certifikate | Veriga certifikatov ali sklic na ključ, namen, mesto upravljanja, življenjski cikel, okolje, odvisna storitev in odgovorna oseba | Zapisov ni mogoče povezati z aplikacijami oziroma procesi, ki jih uporabljajo, ali z odgovornimi osebami |
| Pokritost dobaviteljev | Izdelek ali storitev, različica, kriptografska odvisnost, dokazila, kontaktna oseba v organizaciji in odprta vprašanja | Odvisnosti od dobaviteljev izginejo iz obsega brez evidentiranih izjem |
| Dolgoročna zaupnost | Zahtevano obdobje zaupnosti, izpostavljenost zajemu, zaščitni mehanizem in čas, potreben za izvedbo prehoda | Prednostna obravnava temelji samo na ciljnem datumu prehoda organizacije |
| Ugotovitve, na podlagi katerih je mogoče ukrepati | Z dokazi povezane prednostne naloge, ovire, odločitve, odgovorne osebe, roki in postopek posodabljanja | Izvoz rezultatov odkrivanja je predstavljen kot celoten načrt prehoda |
TLS v tem članku pomeni Transport Layer Security, protokol za zaščito omrežnih povezav.
Povežite odkrivanje z dejanskimi storitvami.
Zahtevajte stalne identifikatorje zapisov, sklice na dokaze, datume zbiranja, okolja, odgovorne osebe in jasno oznako vključenosti v obseg. Zabeležite negotovosti in podlago za oceno zanesljivosti. Vsaki nerešeni postavki določite odgovorno osebo in datum nadaljnje obravnave.
Register storitev uskladite s konfiguracijsko podatkovno zbirko (CMDB), evidencami sredstev in namestitev, oblačnimi računi, podatki sistema domenskih imen (DNS) in evidencami upravljanja certifikatov. Poročajte o povezanih storitvah, nepovezanih sredstvih, izključitvah, ukinjenih sistemih in postavkah, ki čakajo na potrditev. Pri vsakem odstotku pokritosti navedite, glede na katero skupno število je izračunan.
Dogovorite se o obsegu, ki presega javna spletišča. Upoštevajte interne povezave med storitvami; aplikacijske programske vmesnike (API) in integracije; navidezna zasebna omrežja (VPN), oddaljeni dostop in skrbniška opravila; e-pošto in prenos datotek; povezave do podatkovnih zbirk in varnostnih kopij; podpisovanje kode in posodobitve programske opreme; ter identitete zaposlenih, storitev, aplikacij in naprav. Kjer je smiselno, vključite infrastrukturo javnih ključev (PKI), strojne varnostne module (HSM), sisteme za upravljanje ključev (KMS), platforme za upravljanje skrivnosti in storitve, ki jih upravljajo dobavitelji. Zabeležite izključitve in njihove posledice.
Pri vsaki uporabi ločite zaupnost, avtentikacijo, celovitost, podpisovanje in vzpostavljanje ključev. Preverite, katera komponenta izvaja posamezno operacijo ter katera aplikacija ali storitev je od nje odvisna.
Zabeležite natančne mehanizme in vrsto dokazov.
Zahtevajte različice protokolov ter točne različice nameščenih izdelkov in kriptografskih knjižnic, vključno z ustreznimi oznakami gradenj ali modulov. Pri vsakem algoritmu navedite operacijo in ustrezne parametre: dolžino ključa, imenovano krivuljo ali skupino, podpisno shemo in zgoščevalno funkcijo, način šifriranja ali nabor parametrov PQC. Pri hibridnem mehanizmu navedite njegove sestavne dele in uporabljeno specifikacijo.
Ločite štiri kategorije dokazov:
- Podprto: določena različica izdelka mehanizem podpira, kar izkazuje navedena dokumentacija ali preizkus zmogljivosti.
- Nastavljeno: datirana konfiguracija mehanizem omogoča ali izbira v navedenem okolju.
- Opaženo v uporabi: mehanizem je bil dejansko uporabljen v datirani povezavi ali operaciji; zapisani so odjemalec, končna točka, pot in pogoji preizkusa.
- Potrjeno z izjavo dobavitelja: dobavitelj navaja zmogljivost ali dejstvo o uvedbi; shranite izjavo, datum, različico, na katero se nanaša, in stanje preverjanja.
Dobaviteljeva izjava se lahko nanaša na podporo ali nastavitve, zato ohranite tako vsebino navedbe kot način njenega ugotavljanja. Oznake »podprto« brez dokazov ne spreminjajte v »opaženo v uporabi«. Vsako opažanje omejite na pogoje konkretnega preizkusa.
Algoritem in parametre javnega ključa imetnika certifikata beležite ločeno od algoritma in parametrov podpisa izdajatelja. Avtentikacijo povezave in vzpostavljanje ključev ugotovite z ločenimi dokazi. Sam certifikat ne dokazuje, kateri mehanizem za vzpostavljanje ključev je povezava uporabila. NIST pri omrežnih protokolih razlikuje med avtentikacijo in vzpostavljanjem ključev. NIST IR 8547, razdelek 3.1.3
Pri certifikatih zahtevajte tudi verigo, predvideno uporabo, veljavnost, mesto namestitve, postopek obnove, okolje in odgovorno osebo. Pri ključih zahtevajte sklice, namen, mesto upravljanja, stanje življenjskega cikla, odvisne storitve, osebo, odgovorno za ustvarjanje in menjavo ključev, ter omejitve pri zamenjavi ali obnovitvi.
Primer: hipotetični zapis povezave med storitvijo in dokazi.
Naslednji zapis je izmišljen in ponazarja zahtevane razlike. Imena izdelkov, različice, identifikatorji in ugotovitve so izmišljeni; ne gre za priporočeno konfiguracijo.
| Polje | Hipotetični zapis |
|---|---|
| Storitev in odgovornost | SVC-017, portal za dokumente strank, produkcija; za aplikacijo je odgovorna ekipa portala, za prehod pa infrastrukturna ekipa |
| Izvedba | Example Gateway 4.2.1; knjižnica ExampleTLS 2.6.3; dokaz o namestitvi DEP-017 |
| Podprto | Poročilo o zmogljivostih CAP-017 navaja TLS 1.2 in 1.3 ter vzpostavljanje ključev po postopku Diffie–Hellman na eliptičnih krivuljah z začasnimi ključi (ECDHE), s skupinama P-256 in P-384 |
| Nastavljeno | Konfiguracija CFG-017 na preizkušeni poslušalni točki omogoča samo TLS 1.3 in skupino ECDHE P-256 |
| Opaženo v uporabi | Preizkus OBS-017, 15. september 2026 ob 10.00 UTC: zunanji preizkusni odjemalec do javnega prehoda; TLS 1.3, ECDHE P-256, šifrirna zbirka TLS_AES_256_GCM_SHA384 |
| Dokazi o certifikatu | CERT-017 in pripadajoča veriga izdajateljev: javni ključ končnega certifikata RSA, 3072 bitov; izdajatelj je končni certifikat podpisal z algoritmom za digitalni podpis na eliptičnih krivuljah (ECDSA), P-384, SHA-384 |
| Avtentikacija povezave | OBS-017 beleži avtentikacijo strežnika z RSA-PSS, SHA-256, MGF1-SHA-256 in 32-bajtno soljo; brez avtentikacije odjemalca s certifikatom |
| Odvisnost, potrjena z izjavo dobavitelja | Dobavitelj navaja TLS 1.3 za upravljano povezavo med prehodom in arhivom; algoritmi, konfiguracija in dokazi o dejanski uporabi niso predloženi |
| Odprti ukrep | Oseba, odgovorna za infrastrukturo, mora do 15. oktobra 2026 pridobiti dokaze za povezavo z arhivom; vzpostavljanje ključev ostaja neznano; pripravljenosti celotne storitve še ni mogoče oceniti |
Enako sledljivost zahtevajte za druge poti in okolja. Opaženo delovanje javne povezave ne razreši odprte odvisnosti od arhiva.
Zaščitite tudi sam popis.
Iz zbiranja izključite zasebne ključe in drugo tajno ključno gradivo. Zbirajte samo metapodatke, potrebne za oceno. Tudi sklici na ključe, lokacije sistemov, podatki o odgovornih osebah in povezave med odvisnostmi so lahko občutljivi. Zahtevajte razvrstitev po občutljivosti ter nadzor dostopa, prenosa, hrambe in brisanja, tudi za kopije v izvajalčevih sistemih. Kadar zadoščajo dogovorjenemu namenu, uporabite sklice na dokaze ali izvlečke z zakritimi občutljivimi podatki.
Izrecno ocenite dolgoročno zaupnost.
Napadalec lahko danes zajame šifriran promet in ga pozneje dešifrira z dovolj zmogljivim kvantnim računalnikom. Poznejši prehod storitve ne more zaščititi že zajetih kopij. To je grožnja »zajemi zdaj, dešifriraj pozneje«. NIST IR 8547, razdelek 3
Za vsako relevantno kategorijo podatkov zahtevajte dokumentirano obdobje zaupnosti in navedbo osebe, ki ga je odobrila. Podatke povežite s hrambami, prenosnimi potmi in zaščitnimi mehanizmi. Zabeležite, kje bi lahko prišlo do zajema, kateri dokazi podpirajo oceno te izpostavljenosti in koliko časa bo predvidoma potrebnega za izvedbo in preverjanje prehoda, vključno z odvisnostmi od dobaviteljev. Te podatke obravnavajte skupaj; ciljni datum prehoda ne zadostuje kot merilo za začetno presojo.
Simetrično šifriranje arhiva analizirajte ločeno od mehanizmov z javnimi ključi, ki ščitijo ali vzpostavljajo njegove ključe. NIST simetrično kriptografijo in vzpostavljanje ključev z javnimi ključi obravnava različno. NIST IR 8547, razdelka 2.1.3 in 3.1.3
V zahteve naročila vključite sledljiv prikaz ustvarjanja, zaščite, razdeljevanja, obnovitve in zamenjave arhivskih ključev. Zahtevajte ločene ugotovitve za šifriranje podatkov, zaščito ključev in prenosne povezave. Same oznake algoritma za šifriranje arhiva ne sprejmite kot celovite analize.
Za odvisnosti od dobaviteljev določite ukrepe.
Za vsakega relevantnega dobavitelja zahtevajte različico izdelka ali storitve, način uvedbe, kriptografsko vlogo, podprto pot nadgradnje in datirane dokaze za navedbe o PQC. Razpoložljive zmogljivosti ločite od prihodnjih zavez. Zabeležite omejitve kriptografske agilnosti, torej zmožnosti spreminjanja kriptografskih mehanizmov ob ohranjanju delovanja storitve.
Določite osebo, odgovorno za sodelovanje z dobaviteljem, in datum nadaljnje obravnave. Neodgovorjena vprašanja ohranite v registru izjem ter navedite njihov vpliv na oceno. Oznaka »odvisno od dobavitelja« naj sproži ukrep, ne zaključi ugotovitve.
Pred prevzemom preverite rezultate in jih nato posodabljajte.
Izberite vzorec, ki zajema produkcijska in neprodukcijska okolja, javne in interne povezave, oblačne in lokalne sisteme, identitete zaposlenih ter identitete storitev, aplikacij in naprav, pa tudi storitve, ki jih upravljajo dobavitelji. Vsakemu zapisu sledite od odgovorne osebe za storitev do datiranih dokazov. Neodvisno ga primerjajte z razpoložljivimi konfiguracijami, evidencami namestitev, certifikati ali opažanji povezav. Zabeležite odstopanja in razširite preverjanje, kjer pokažejo težavo s pokritostjo.
Zahtevajte kazalnike pokritosti za usklajene poslovne storitve, določene odgovorne osebe, dovolj podrobne kriptografske zapise, nerešene postavke in njihovo starost, odgovore dobaviteljev ter izključitve. Prevzem zavrnite, kadar zapisom ni mogoče slediti, neznanke izginejo, odvisnosti nimajo odgovornih oseb ali prednostne naloge niso utemeljene.
Nato določite ukrepe: odpravite vrzeli v popisu, preverite neznane mehanizme, pridobite dokaze dobaviteljev, ocenite podprte nadgradnje in načrtujte preizkuse. Sisteme za prehod prednostno razvrstite glede na poslovni vpliv, potrebe po zaupnosti, izpostavljenost zajemu, odvisnosti in čas, potreben za izvedbo. Načrt redno posodabljajte, prizadete zapise pa osvežite po pomembnih spremembah aplikacij, infrastrukture, certifikatov ali dobaviteljev.
Navedite omejitve posamezne metode: katere poti so bile opazovane, katere konfiguracije pregledane in kje dostop ali dokazi niso bili na voljo. Ohranite predpostavke in nerešene postavke. NIST IR 8547 je še vedno označen kot začetni javni osnutek; uporabljajte ga kot predlagani pristop k prehodu, ne kot dokončno univerzalno izvedbeno zahtevo. Status objave NIST IR 8547
Je odkrivanje zunanjih povezav TLS primeren začetek?
Da, za javne končne točke, vključene v pregled. Zahtevajte, da končna ocena ločeno obravnava interne storitve, druge uporabe kriptografije, odvisnosti od dobaviteljev in podatke, ki zahtevajo dolgoročno zaupnost.
Ali mora ocena pregledati prav vsak sistem?
Ni nujno. Dogovorite se o dokumentiranem obsegu na podlagi tveganj in uporabite dopolnjujoče se vire dokazov. Z vzorčenjem preverjajte izbrane zapise. Izključitve in področja, za katera ni mogoče pridobiti dokazov, morajo ostati vidna, z odgovorno osebo, utemeljitvijo in načrtom nadaljnjih ukrepov.
Kaj mora vsebovati končni rezultat?
Zahtevajte z dokazi povezan popis, obseg in metode, natančne mehanizme in vrste dokazov, kazalnike usklajenosti in pokritosti, analizo tveganj za zaupnost, odvisnosti od dobaviteljev in izjeme, prednostno razvrščene ukrepe, odgovorne osebe, roke in postopek posodabljanja. Preglednica je sprejemljiva, če ohranja te povezave in omogoča preverjanje.
Nadaljnje branje
Komentarji
Ni še komentarjev. Bodite prvi!
Dodaj komentar