Skip to content

Կրիպտոգրաֆիկ բանալիները պահելը

Անձնական բանալին կարող է հաստատել իր լիազորությանը թույլատրված ցանկացած գործողություն։ Երբեք մի կիսվեք անձնական բանալիով։ Seed նյութը, վերականգնման գաղտնիքները, bearer token-ները և արտահանված բանալու ֆայլերը պաշտպանեք նույն խնամքով։

Նախքան արտադրության մեկնարկը ընտրեք պահեստային դիզայնը: Դիզայնը պետք է համապատասխանի ռիսկի արժեքին, հաշվառման վերահսկողության քաղաքականությանը եւ տեղակայման վերականգնման գործընթացին:

Սահմանեք պահառության սահմանը

  • Պահպանեք յուրաքանչյուր իշխանության, հանրային բանալի, ալգորիթմի, շրջակա միջավայրի, նպատակի, պահպանի, պահպանման վայրի, կրկնօրինակումների եւ փոխարինման ընթացակարգերի ինվենտարի:
  • Օգտագործեք առանձին բանալիներ մշակման, փորձարկման, արտադրության, սովորական գործարքների, կառավարման, տեղակայման եւ վերականգնման համար:
  • Մարդկանց եւ գործընթացներին թույլ տալ մուտք գործել միայն իրենց դերի պահանջվող բանալիները:
  • Պահանջվում է անկախ հավանություն բարձր արժեքի կամ կառավարման ստորագրության համար, երբ ռիսկային մոդելը դա պահանջում է:
  • Գրիր, թե որ ցանցից եւ իշխանությունից կարող է օգտվել ստորագրողը: ստորագրման ծառայությունը պետք է մերժի այդ ոլորտի սահմաններից դուրս գտնվող դիմումները:

Ընտրեք համապատասխան պահեստավորման մեթոդ

Տեղային մշակման, վերահսկվող թեստերի կամ անվտանգ պահառության փոխանցման համար բանալին կարելի է արտահանել սահմանափակ թույլտվություններով ֆայլ։ Աջակցվող Unix հարթակում kagami-ով ստեղծեք բանալիների նոր գրացուցակ․

bash
cargo run --bin kagami -- keys --algorithm ed25519 --out-dir ./client-key

Ծնող գրացուցակը պետք է գոյություն ունենա։ Նպատակային գրացուցակը պետք է լինի նոր կամ պատկանի ընթացիկ օգտատիրոջը, ունենա 0700 ռեժիմ, չպարունակի խորհրդանշական հղումներ և լինի դատարկ։ Kagami-ն public.key և private.key ֆայլերը գրում է 0600 ռեժիմով, իսկ --pop-ը նաև գրում է pop.hex։ Այն հարթակներում, որտեղ Kagami-ն չի կարող պարտադրել միայն սեփականատիրոջ համար նախատեսված ֆայլային համակարգի կանոնները, հրամանն ավարտվում է սխալով։

Անձնական բանալու ֆայլը չգաղտնագրված արտահանում է։ Այն մի պահեք source control-ում, ընդհանուր պանակներում, log-երում, ticket-ներում, chat-ում կամ build artifact-ներում։ Արտադրական բանալին ներմուծեք հաստատված պահառության սահման, ապա տեղակայման ընթացակարգի համաձայն հեռացրեք արտահանված ֆայլը։ Մշակման բանալին արտադրությունում կրկին մի օգտագործեք։

Արտադրության համար նախընտրում է վերահսկվող պահեստային սահման, ինչպիսիք են'

  • սարքավորումների անվտանգության մոդուլ կամ սարքավորմամբ ապահովված բանալիրների պահեստ
  • օպերացիոն համակարգի կամ շարժական բանալիրների պահեստ
  • մեկուսացված ստորագրման ծառայություն
  • գաղտնի տնօրեն, որը բանալին է տալիս միայն թույլատրված աշխատանքային բեռնվածության համար

Պահպանեք առանցքային նյութը, որը չի կարող արտահանվել, երբ ընտրված ինտեգրումը աջակցում է այդ հատկությանը: Համոզվեք, որ պահեստավորման համակարգը աջակցում է Iroha մարմնի կողմից պահանջվող ալգորիթմին եւ ստորագրման գործողություններին:

Պահված վիճակի գաղտնագրումը պաշտպանում է միայն պահված պատճենը։ Այն չի պաշտպանում բանալին այն բանից հետո, երբ չարտոնված գործընթացը կամ օպերատորը ստանում է վերծանված բայթերը։ Ամրացրեք host-ը, սահմանափակեք runtime հասանելիությունը և վերահսկեք ստորագրման գործողությունները։

Պաշտպանեք ստորագրման աշխատանքային հոսքերը

  • Օգտագործեք անունով օպերատորի ինքնությունը, ուժեղ հավաստագրում եւ աուդիտացված մուտք գործել ստորագրման համակարգերը:
  • Հում բանալիները մի տեղադրեք command-line argument-ներում, shell history-ում, environment dump-երում, process listing-ներում, crash report-ներում կամ application log-երում։
  • Ստորագրողը unlock արեք միայն անհրաժեշտ գործողության համար։ Օգտագործումից հետո փակեք կամ ավարտեք session-ը։
  • Նախքան հաստատումը ցուցադրեք իշխանությունը, ցանցը, հրահանգները, ակտիվները եւ վճարները:
  • Պահանջվում է արտոնյալ կամ բարձր արժեք ունեցող գործարքների համար հստակ հաստատում:
  • Պահպանեք կաթվածային մասնավոր բանալիները բրաուզերների էջերից եւ ընդհանուր նպատակներով կիրառման գործընթացներից դուրս, երբ անհատական հաճախորդի ինտեգրումը կարող է պատվիրել ստորագրությունը:

Պարզ տեքստային client configuration-ը հարմար է միայն տեղային մշակման և վերահսկվող թեստերի համար։ Արտադրական ինտեգրումը պետք է ստորագրությունները ստանա իր հաստատված պահառության սահմանից։ Ստանդարտ Iroha CLI-ն անձնական բանալին կարդում է client configuration-ից և ընդհանուր external-signer adapter չի տրամադրում։ Հատուկ client-ները կարող են կառուցել transaction payload hash-ը և կցել արտաքին ստորագրողի ստեղծած ստորագրությունը։

Պահուստավորեք և վերականգնեք բանալիները

  • Պահուստավորեք միայն այն բանալիները, որոնց վերականգնման քաղաքականությունը պահուստ է պահանջում։
  • Գաղտնագրեք պահուստները և դրանք պահեք գործող ստորագրողից առանձին։
  • Պահուստի նկատմամբ կիրառեք հասանելիության և հաստատման նույն վերահսկումները, ինչ գործող բանալու նկատմամբ։
  • Երբ պահանջվում է պարտականությունների տարանջատում, վերականգնման credentials-ը պահեք անկախ պահառության ներքո։
  • Փորձարկեք վերականգնումը՝ առանց արտադրական բանալու նյութը բացահայտելու։
  • Գրանցեք և վերանայեք պահուստի ստեղծման, հասանելիության, վերականգնման ու ոչնչացման յուրաքանչյուր դեպք։

Մի ենթադրեք, որ չկապված դրամապանակի մնեմոնիկ ձեւաչափը կարող է ներկայացնել Iroha մասնավոր բանալին: Օգտագործեք միայն վերականգնման ձեւաչափ, որը աջակցում եւ փորձարկվում է ընտրված պահեստային համակարգով.

Փոխարինեք բացահայտված կամ օգտագործումից հանված բանալիները

Փոխարինմանը պատրաստվեք միջադեպից առաջ։ Ընթացակարգը պետք է սահմանի՝

  1. ով կարող է բանալին հայտարարել բացահայտված կամ օգտագործումից հանված
  2. ինչպես է մեկուսացվում տուժած ստորագրողը
  3. ինչպես է ստեղծվում նոր բանալին և տեղադրվում հաստատված պահառության ներքո
  4. հաշվի համար՝ ինչպես է արտոնված controller-ի փոխարինումը կամ social recovery-ն ստեղծում փոխարինող կանոնական AccountId և տեղափոխում կապված վիճակը
  5. node-ի կամ peer-ի համար՝ ինչպես է արտոնված on-chain consensus-key rotation-ը կամ disablement-ը համաձայնեցվում BLS PoP-ի, activation և overlap policy-ի, տեղային բանալու configuration-ի, trusted_peers_pop-ի և deployment topology-ի հետ
  6. ինչպես են կախյալ configuration-ները, application-ները և operator-ները ընդունում նոր AccountId, հանրային բանալին կամ peer identity-ն
  7. ինչպես է հանվում հին բանալու լիազորությունը, իսկ դրա պատճենները արխիվացվում կամ ոչնչացվում
  8. ինչպես են դրանից հետո ստուգվում ցանցն ու կախյալ application-ները

WARNING

Կոդավորումը կամ նոր գաղտնաբառը չեն կարող վերաապահովել կոպեացված անձնական բանալին: Երբ կասկածվում է բացահայտումը, դադարեք օգտագործել բանալին եւ հետեւեք հաստատված փոխարինման կամ չեղարկման ընթացակարգին:

Դիտեք Կրիպտոգրաֆիկ բանալիների ստեղծում, Օպերացիոն անվտանգություն եւ Անվտանգության սկզբունքներ: