Выдаліць парольную фразу ключа ці пакінуць? Копія, якую вы ствараеце
Незашыфраваны файл ключа трымае той жа сакрэт пад слабейшай аховай. Параўнайце рызыку ў стане спакою перад пераўтварэннем і ведайце, што яно не выпраўляе.
Зашыфраваны прыватны ключ і незашыфраваны трымаюць адзін і той жа ключавы матэрыял. Пераўтварэнне не стварае новую асобу, не скідвае ўліковы запіс VPN і не робіць стары файл несапраўдным. Яно запісвае другую копію, і гэтая копія нясе іншую рызыку ў стане спакою.
Ці варта гэтага абмен, залежыць ад таго, дзе будзе жыць файл і хто можа яго чытаць.
Што пераўтварэнне насамрэч змяняе
Да пераўтварэння ключ абаронены парольнай фразай, якую падае аператар. Пасля пераўтварэння ён абаронены правамі файлавай сістэмы і любым кантролем доступу, які атачае файл. Крыптаграфія не змянілася; змянілася колькасць рэчаў паміж зламыснікам і ключом. Вось і ўсё параўнанне.
Табліца робіць розніцу канкрэтнай.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
Ні адна форма не з'яўляецца аўтаматычна бяспечнейшай. Яны адмаўляюць па-рознаму, і толькі адзін з гэтых шляхоў пакідае запіс у журнале.
Калі лепш пакінуць парольную фразу
Калі падтрыманы кліент можа запрасіць парольную фразу або ўзяць яе з зацверджанага сховішча сакрэтаў, пераўтварэнне нічога не дае. Вы трымаеце адну копію, адну мяжу аховы і на адзін файл менш для адсочвання. Большасць VPN-кліентаў, якія прымаюць ключы PEM, могуць гэта рабіць.
Пераўтварэнне таксама няправільны крок, калі каманда дзеліцца ключом. Незашыфраваны файл на агульным хосце становіцца ўліковымі данымі, якія можа скапіраваць любы, хто мае доступ да shell.
Калі незашыфраваная копія апраўданая
Некаторыя службы не могуць запытаць, некаторыя кантэйнеры манціруюць сакрэты толькі для чытання, а некаторыя прылады чытаюць файл ключа пры загрузцы без інтэрактыўнага шляху. У такіх выпадках незашыфраваны ключ у належна абмежаваным каталогу можа быць падтрымліванай канструкцыяй. Апраўданне — асяроддзе, а не зручнасць.
Калі вы не можаце сказаць, хто можа чытаць файл і чаму, адказ — не.
Каманда і яе вострыя куты
Для ключа на аснове файла, які падтрымлівае OpenSSL 3.5, даведка pkey апісвае выдаленне парольнай фразы і інтэрактыўны запыт, калі ўвод зашыфраваны і крыніца пароля не пададзена. Мінімальная форма кароткая, і яе лёгка запусціць нядбайна.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemТры вострыя куты. Увод/вывад файла вываду не атамарны, таму існуючы шлях вываду можа быць абрэзаны пасярэдзіне запісу. Не выкарыстоўвайце шлях уводу як выхад і не эксперыментуйце на адзінай абароненай копіі. Увядзіце парольную фразу ў запыце, а не ў камандным радку, дзе яна трапляе ў гісторыю shell.
Праверце вынік перад змяненнем любой канфігурацыі VPN: openssl pkey -in new-private-key.pem -pubout павінна вывесці той жа публічны ключ, які быў у вас раней.
Што пераўтварэнне не робіць
Яно не адклікае зашыфраваную копію, якая ўсё яшчэ існуе там, дзе вы яе пакінулі. Яно не змяняе пароль уліковага запісу VPN або сертыфікат. І яно не выпраўляе ўжо адбыўшуюся ўцечку. Калі ключ быў счытаны, рашэнне — замена і адкліканне на баку сервера, а не лакальная змена фармату.
Выдаліце прамежкавы файл наўмысна і пераканайцеся, што шлях, які вы выдаляеце, — той, які вы стварылі.