దీనిలో ఎక్కువ భాగాన్ని నిర్ణయించే ప్రశ్న మీరు ఆర్కైవ్ను ఎలా ఎన్క్రిప్ట్ చేస్తారు అనేది కాదు. మీ CA ప్రైవేట్ కీ తన కంటైనర్ను విడిచి వెళ్లగలదా అనేది. కీ ఫైల్ అయితే, మొత్తం CA డైరెక్టరీని ఒక ఎన్క్రిప్ట్ చేసిన బ్లాబ్లోకి కాపీ చేసి నిమిషాల్లో పూర్తి చేయవచ్చు. అది HSM లో లేదా కీని సంగ్రహించలేనిదిగా గుర్తించే టోకెన్లో నివసిస్తే, ఆ కాపీ ఉండదు, మరియు మీ ప్రణాళిక విక్రేత చుట్టడం-మరియు-పునరుద్ధరణ విధానం గురించిన ప్రణాళిక అవుతుంది. రెండు మోడళ్లు పని చేస్తాయి, వేర్వేరుగా విఫలమవుతాయి, మరియు మీరు తట్టుకోగల వైఫల్యమే రూపకల్పనకు తగినది.

రెండు బ్యాకప్ మోడళ్లు ఎక్కడ విడిపోతాయి

మోడల్ A అనేది డైరెక్టరీ కాపీ. OpenSSL శైలి CA ఒక పని డైరెక్టరీ, ఒకే ధృవపత్రం కాదు: ca.key లేదా cakey.pem, ca.crt, ఇష్యూ డేటాబేస్, serial మరియు crlnumber కౌంటర్లు, మరియు openssl.cnf. ఆ డైరెక్టరీని సమమితీయ సైఫర్తో ముద్రించండి, ఫలితాన్ని రెండవ మాధ్యమానికి తరలించండి, మరియు పునరుద్ధరణ అంటే విప్పు, ధృవీకరించు, సంతకం చేయు. ఇష్యూయర్కు అవసరమైనదంతా కలిసి ప్రయాణిస్తుంది, ఎవరూ రాసినట్టు గుర్తులేని వారాల రద్దు చరిత్రతో సహా.

మోడల్ B అనేది కీ నిరోధం. కీ PKCS#11 మాడ్యూల్ లోపల ఉత్పత్తి అవుతుంది మరియు సంగ్రహించలేనిదిగా గుర్తించబడుతుంది; మాడ్యూల్ దానిని బ్యాకప్ కోసం చుట్టగలదు, కానీ ఏ ప్రక్రియా ఎప్పుడూ ముడి బైట్లను చదవదు. అప్పుడు మీ బ్యాకప్ సరైన క్రమంలో పునరుద్ధరించాల్సిన రెండు వస్తువులు: ఆ మాడ్యూల్ కుటుంబం మాత్రమే తెరవగల చుట్టిన కీ బ్లాబ్, మరియు డేటాబేస్, కాన్ఫిగరేషన్, ధృవపత్రాల సాధారణ కాపీ.

AttributeEncrypted archiveHSM key backup
What you storeone encrypted filewrapped blob plus CA records
Who can restore itanyone holding the passphraseholder of the module and the blob, often vendor support
If a copy leaksattacker with the passphrase becomes the CAblob is inert without the matching module
What usually breaks itforgotten passphrase, one damaged copyreplacement module rejects the blob, contract gap

పోలిక ఎప్పుడూ ఏ మోడల్ అమూర్తంగా బలంగా ఉంది అనేది కాదు. మీ బృందం రాత్రి 2 గంటలకు నిజంగా మేల్కొని ఉన్నవారితో ఏది పునరుద్ధరించగలదు అనేది. ఎవరూ డీక్రిప్ట్ చేయలేని ఆర్కైవ్ మరియు ఎవరూ పరీక్షించని HSM బ్లాబ్ సమానంగా నిష్ప్రయోజనకరం. తేడా ఏమిటంటే ఆర్కైవ్ వైఫల్యం పాస్వర్డ్ మేనేజర్లో కనిపిస్తుంది, HSM వైఫల్యం మద్దతు ఒప్పందంలో దాక్కుంటుంది.

ప్రతి CA బ్యాకప్లో ఏమి ఉండాలి

రెండు మోడళ్లకూ ఒకే రికార్డు సమితి అవసరం. OpenSSL CAలో ఆ ఫైళ్లు index.txt, ప్రతి జారీ చేసిన ధృవపత్రానికి ఒక వరుస స్థితి, ముగింపు, serial మరియు విషయాన్ని కవర్ చేస్తుంది, తర్వాత index.txt.attr, తదుపరి జారీ చేయాల్సిన serialను ఉంచే serial, తదుపరి CRL సంఖ్యను ఉంచే crlnumber, మరియు మీ CA నిజంగా పని చేసే dir, policy, default_days ఉన్న openssl.cnf. openssl-ca మాన్యువల్ ఆ కౌంటర్లలో ప్రతిది ఏమి నియంత్రిస్తుందో వివరిస్తుంది. easy-rsa అదే డేటాను pki/ కింద ఉంచుతుంది, vars ఫైల్ ధృవపత్రం ఫీల్డ్లను నిర్ణయిస్తుంది.

కీ మరియు ధృవపత్రం తిరిగి నిర్మించలేని భాగాలు. డేటాబేస్ జ్ఞాపకం నుండి పునర్నిర్మించలేని భాగం. index.txtను దాటవేసినా కొత్త ధృవపత్రాలపై సంతకం చేయగలరు, మరియు అదే నిజమైన ఉచ్చు: క్లయింట్ ధృవపత్రం రద్దు అయిందా అని మొదటిసారి అడిగినప్పుడు అది లేదని తెలుస్తుంది. CA వేలిముద్రను బ్యాకప్ వెలుపల నమోదు చేయండి, తద్వారా పునరుద్ధరణ మీరు నమ్మే విలువతో పోల్చబడుతుంది, మీరు ఇప్పుడే పునరుద్ధరించిన ఫైల్తో కాదు.

openssl x509 -in ca.crt -noout -fingerprint -sha256
tar czf ca-state.tar.gz ca.crt ca.key index.txt* serial* crlnumber* openssl.cnf
openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt -in ca-state.tar.gz -out ca-state.tar.gz.enc
openssl ca -config openssl.cnf -gencrl -out crl.pem

ఇష్యూయర్ను శాఖలు చేయని పునరుద్ధరణ పరీక్షలు

ఒకే విషయం మరియు ఒకే కీ ఉన్న రెండు సజీవ CAలు అసలైనదాన్ని నమ్మే ప్రతి క్లయింట్కు ఒకేలా కనిపిస్తాయి. ఒకే సంఖ్య కానీ వేరే కంటెంట్ ఉన్న రెండు CRLలు క్లయింట్లు మీరు రద్దు చేసిన ధృవపత్రాన్ని నిశ్శబ్దంగా అంగీకరించే మార్గం. మీ క్లయింట్లకు మార్గం లేని హోస్ట్లో లేదా ఒకసారి ఉపయోగించే VMలో పునరుద్ధరణను అమలు చేయండి, మరియు పరీక్ష ఉత్పత్తి చేసే CRLను ఎప్పుడూ ప్రచురించవద్దు.

ఆర్కైవ్ తెరుచుకుంటుందని మాత్రమే నిరూపించే పరీక్ష జారీ గురించి ఏమీ నిరూపించదు. ముఖ్యమైన క్రమం: పునరుద్ధరించిన ca.crt వేలిముద్రను మీరు నమోదు చేసిన విలువతో పోల్చండి, serial మీ చివరి జారీ చేసిన ధృవపత్రం సూచించే దానితో సరిపోతుందని నిర్ధారించండి, ఒకసారి ఉపయోగించే CN కోసం ఒక ధృవపత్రం జారీ చేసి index.txt ఒక వరుస పొందుతున్నట్టు చూడండి, తర్వాత ఆ ధృవపత్రాన్ని రద్దు చేసి CRLను మళ్లీ సృష్టించండి.

openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdate

HSMతో అదే పరీక్ష మాడ్యూల్ ద్వారా వెళ్తుంది. బ్లాబ్ను భర్తీ పరికరంలో తెరవండి, మాడ్యూల్ నివేదించే CA ధృవపత్రం మీరు నమోదు చేసిన వేలిముద్రతో సరిపోతుందని నిర్ధారించండి, ఆ తర్వాత మాత్రమే సంతకం చేయనివ్వండి. మాడ్యూల్కు దాని స్వంత వస్తు నిల్వ ఉంటే, చుట్టడం కీ వస్తువు మరియు దాని లేబుల్ను కవర్ చేయాలి, ఎందుకంటే వేరే లేబుల్ కింద కీని పునరుద్ధరించడం దాని వైపు చూపే కాన్ఫిగరేషన్ను బద్దలు కొడుతుంది.

ఎంపికను నిర్ణయించే వైఫల్య విధానాలు

ఐదు వైఫల్యాలు చాలా వాస్తవ నష్టాలను వివరిస్తాయి. రహస్యం యొక్క స్వతంత్ర కాపీ లేకుండా మరచిపోయిన ఆర్కైవ్ పాస్ఫ్రేజ్ ఆర్కైవ్ను ఇటుకగా మారుస్తుంది. ఒక డిస్క్పై ఒకే కాపీ ఆ డిస్క్తో మరణిస్తుంది, చెక్సమ్ డీక్రిప్షన్ ఇంకా పని చేస్తుందా అని ఎప్పుడూ చెప్పదు. బ్యాకప్ తేదీ తర్వాత రద్దు చేసిన ధృవపత్రాలు పునరుద్ధరణ తర్వాత మళ్లీ చెల్లుబాటు అయినట్టు కనిపిస్తాయి, కాబట్టి మీ బ్యాకప్ విరామమే మీ రద్దు అంధ బిందువు. పాత serial కౌంటర్ను పునరుద్ధరించడం serial నంబర్లను తిరిగి ఉపయోగిస్తుంది మరియు serial ఆధారిత క్యాష్లు మరియు CRL శోధనలను గందరగోళపరుస్తుంది. చుట్టిన బ్లాబ్ను తిరస్కరించే భర్తీ HSM హార్డ్వేర్ మార్పును పూర్తి పునర్జారీగా మారుస్తుంది.

మోడల్ A మొదటి నాలుగింటిని దారుణంగా కానీ కనిపించేలా నిర్వహిస్తుంది. మోడల్ B మాడ్యూల్ లేదా విక్రేత ప్రక్రియ విఫలమయ్యే వరకు వాటిని బాగా నిర్వహిస్తుంది. మీ కీలు ఎగుమతి చేయగలిగినవి మరియు బృందం చిన్నది అయితే, ఎన్క్రిప్ట్ చేసిన ఆర్కైవ్ నిజాయితీ ఎంపిక, రెండు మాధ్యమాలు మరియు లిఖిత పాస్ఫ్రేజ్ విధానంతో మద్దతు పొందుతుంది. కీ సంగ్రహించలేనిది అయితే మీకు ఎలాంటి ఎంపికా లేదు, మరియు పని అది అవసరమయ్యే రోజు ముందు విక్రేత పునరుద్ధరణ మార్గాన్ని నిరూపించడం వైపు మారుతుంది.

మోడల్ను ఎంచుకోవడం మరియు షెడ్యూల్ చేయడం

మూడు షరతులు నిర్ణయాన్ని పరిష్కరిస్తాయి. విక్రేత ప్రక్రియ లేకుండా కీని ఎగుమతి చేయవచ్చా? మీరు ఇంకా కలిగి లేని హార్డ్వేర్పై పునరుద్ధరణ పడాలా? మద్దతుతో వాదిస్తున్నప్పుడు జారీ ఎంతసేపు ఆగగలదు? ఆ మూడింటికి సమాధానం చెప్పండి, మోడల్ నిర్ణయమవుతుంది; తర్వాతదంతా షెడ్యూలింగ్.

ప్రతి సంతకం వేడుక తర్వాత మరియు ఏదైనా కాన్ఫిగరేషన్ మార్పు ముందు బ్యాకప్ తీసుకోండి, ఎందుకంటే కాన్ఫిగరేషన్ స్థితిలో భాగం. వేర్వేరు ప్రదేశాల్లో వేర్వేరు మాధ్యమాలపై రెండు కాపీలు ఉంచండి, ఒకటి ఆఫ్లైన్, మరియు డీక్రిప్షన్ రహస్యాన్ని కాపీలకు భిన్నమైన విశ్వాస డొమైన్లో ఉంచండి. చివరి విజయవంతమైన పునరుద్ధరణ తేదీని బ్యాకప్ రికార్డ్పై రాయండి. ఎప్పుడూ పునరుద్ధరించని బ్యాకప్ ఊహ, నియంత్రణ కాదు.

టికెట్ మూసివేసే ముందు ఈ ఐదు అంశాలను నిర్ధారించండి:

  • ca.crt వేలిముద్ర బ్యాకప్ వెలుపల ఎక్కడో నమోదై ఉంది.
  • index.txt, serial, crlnumber మరియు openssl.cnf అన్నీ ఆర్కైవ్ లేదా బ్లాబ్ సెట్ లోపల ఉన్నాయి.
  • పాస్ఫ్రేజ్ లేదా చుట్టిన కీ సంరక్షణ నమోదై ఉంది మరియు ఆర్కైవ్ యజమాని కాకుండా మరొకరి వద్ద ఉంది.
  • వేరుచేసిన హోస్ట్పై ఒక జారీ మరియు ఒక రద్దుతో పునరుద్ధరణ పరీక్షించబడింది.
  • మీ బ్యాకప్ విరామం సూచించే రద్దు అంతరం లిఖితంగా అంగీకరించబడింది లేదా తగ్గించబడింది.

సంబంధిత వ్యాసాలు