Рэзервовая копія прыватнага CA: зашыфраваны архіў супраць рэзервовай копіі ключа HSM

Пытанне, якое вырашае большасць гэтага, не ў тым, як вы шыфруеце архіў. Яно ў тым, ці ваш прыватны ключ CA можа наогул пакінуць свой кантэйнер. Калі ключ — гэта файл, вы можаце скапіраваць увесь каталог CA у адзін зашыфраваны блоб і скончыць за хвіліны. Калі ён жыве ў HSM або ў токене, які пазначае ключ як невымальны, такой копіі не існуе, і ваш план ператвараецца ў план пра працэдуру абгортвання і аднаўлення ў пастаўшчыка. Абедзве мадэлі працуюць, яны адмаўляюць па-рознаму, і адмова, якую вы можаце перажыць, — гэта тая, вакол якой варта праектаваць.

Дзе разыходзяцца дзве мадэлі рэзервовага капіравання

Мадэль A — гэта капіраванне каталога. CA у стылі OpenSSL — гэта працоўны каталог, а не адзін сертыфікат: ca.key або cakey.pem, ca.crt, база даных выпуску, лічыльнікі serial і crlnumber, і openssl.cnf. Запячатайце гэты каталог сіметрычным шыфрам, перанясіце вынік на другі носьбіт, і аднаўленне азначае распакаваць, праверыць, падпісаць. Усё, што патрэбна эмітэнту, падарожнічае разам, уключаючы тыдні гісторыі адклікання, пра напісанне якой ніхто не памятае.

Мадэль B — гэта ўтрыманне ключа. Ключ генеруецца ўнутры модуля PKCS#11 і пазначаецца як невымальны; модуль можа абгарнуць яго для рэзервовай копіі, але ні адзін працэс ніколі не чытае сырыя байты. Ваша рэзервовая копія тады — дзве часткі, якія трэба аднавіць у правільным парадку: абгорнуты блок ключа, які можа разгарнуць толькі тое сямейства модуляў, плюс звычайная копія базы даных, канфігурацыі і сертыфікатаў.

Параўнанне ніколі не пра тое, якая мадэль мацнейшая ў абстракцыі. Яно пра тое, якую з іх ваша каманда можа аднавіць а 2 гадзіны ночы з людзьмі, якія сапраўды не спяць. Архіў, які ніхто не можа расшыфраваць, і блок HSM, які ніхто не правяраў, аднолькава бескарысныя. Розніца ў тым, што збой архіва ўсплывае ў мэнэджары пароляў, а збой HSM хаваецца ў кантракце падтрымкі.

Што мусіць змяшчаць кожная рэзервовая копія CA

Абедзве мадэлі патрабуюць аднаго і таго ж набору запісаў. У CA OpenSSL гэтыя файлы — index.txt з адным радком на кожны выдадзены сертыфікат, які ахоплівае статус, тэрмін, серыйны нумар і суб’ект, затым index.txt.attr, serial, які трымае наступны серыйны нумар для выпуску, crlnumber, які трымае наступны нумар CRL, і openssl.cnf з dir, policy і default_days, з якімі ваш CA сапраўды працуе. Дапаможнік 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 з запісаным значэннем, пацвердзіце, што серыйны нумар адпавядае таму, што мяркуе апошні выдадзены сертыфікат, выдайце адзін сертыфікат для аднаразовага 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, які паведамляе модуль, адпавядае вашаму запісанаму адбітку, і толькі потым дазвольце яму падпісваць. Калі модуль мае ўласнае сховішча аб’ектаў, абгортванне мусіць ахопліваць аб’ект ключа і яго метку, бо аднаўленне ключа пад іншай меткай ламае канфігурацыю, якая на яго спасылаецца.

Рэжымы збояў, якія вызначаюць выбар

Пяць збояў тлумачаць большасць рэальных страт. Забыты пароль архіва без незалежнай копіі сакрэту ператварае архіў у цагліну. Адзіная копія на адным дыску памірае разам з гэтым дыскам, а кантрольная сума ніколі не скажа, ці працуе расшыфроўка. Сертыфікаты, адкліканыя пасля даты рэзервовай копіі, пасля аднаўлення выглядаюць зноў сапраўднымі, таму ваш інтэрвал рэзервовага капіравання — гэта таксама ваша сляпая зона адклікання. Аднаўленне старэйшага лічыльніка серыйных нумароў паўторна выкарыстоўвае нумары і блытае кэшы і пошук CRL, прывязаныя да серыйнага нумара. Заменны HSM, які адмаўляецца ад абгорнутага блока, ператварае замену абсталявання ў поўны перавыпуск.

Мадэль A спраўляецца з першымі чатырма дрэнна, але бачна. Мадэль B спраўляецца з імі добра аж да збою модуля або працэсу пастаўшчыка. Калі вашыя ключы экспартуюцца і каманда невялікая, зашыфраваны архіў — гэта сумленны выбар, падмацаваны двума носьбітамі і пісьмовай працэдурай пароля. Калі ключ невымальны, выбару ў вас няма зусім, і праца пераходзіць да доказу шляху аднаўлення ў пастаўшчыка да таго дня, калі ён спатрэбіцца.

Выбар мадэлі і планаванне

Тры ўмовы вырашаюць справу. Ці можна экспартаваць ключ без працэсу пастаўшчыка? Ці мусіць аднаўленне трапіць на абсталяванне, якім вы яшчэ не валодаеце? Як доўга можа стаяць выпуск, пакуль вы спрачаецеся з падтрымкай? Адкажыце на гэтыя тры, і мадэль вырашана; усё пасля гэтага — планаванне.

Рабіце рэзервовую копію пасля кожнай цырымоніі подпісу і перад любой зменай канфігурацыі, бо канфігурацыя — частка стану. Трымайце дзве копіі на розных носьбітах у розных месцах, адна з іх па-за сеткай, а сакрэт расшыфроўкі трымайце ў іншай давяральнай вобласці, чым копіі. Запішыце дату апошняга паспяховага аднаўлення ў запіс рэзервовай копіі. Рэзервовая копія, якая ніколі не аднаўлялася, — гэта гіпотэза, а не кантроль.

Перш чым зачыніць заяўку, пацвердзіце гэтыя пяць пунктаў:

• Адбітак ca.crt запісаны недзе па-за рэзервовай копіяй.
• index.txt, serial, crlnumber і openssl.cnf усе ўнутры архіва або набору блокаў.
• Захоўванне пароля або абгорнутага ключа дакументавана і знаходзіцца ў кагосьці іншага, чым уладальнік архіва.
• Аднаўленне пратэставана на ізаляваным хасце з адным выпускам і адным адкліканнем.
• Прабел у адкліканні, які вынікае з інтэрвалу рэзервовага капіравання, прыняты пісьмова або скарочаны.