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

Параўнайце два праекты там, дзе яны сапраўды адрозніваюцца

Праект з таймерам аптымізуе бок сервера. Запланаваная задача выклікае CA, з'яўляецца новы сертыфікат, і аператар лічыць працу выкананай. Усё, што адбываецца пасля выдачы, — чыясьці іншая праблема, пакуль прылада не зможа падключыцца і дата заканчэння не патлумачыць прычыну.

Праект працоўнага працэсу аптымізуе апошнюю мілю. Ён мяркуе, што выдача — гэта адзін крок у ланцугу і што кожны наступны крок можа праваліцца незалежна. Гэта каштуе больш на пабудову і значна менш на эксплуатацыю, бо збоі паказваюцца як адсочваныя станы, а не як кліенты з скончаным тэрмінам.

Карысны спосаб утрымаць розніцу ў полі зроку — гэта паслядоўнасць, якую кожны праект мусіць назваць яўна.

detect window -> authenticate request -> authorize -> issue
-> deliver and stage -> activate -> verify fresh auth -> retire old material

Вызначце акно па самім сертыфікаце

Чытайце тэрмін дзеяння з сертыфіката, які кліент сапраўды прадстаўляе, а не з даты, убудаванай у скапіяваную назву файла. Назвы файлаў дрыфтуюць, і файл з надпісам 2026 можа ўтрымліваць уліковыя дадзеныя, якія сканчаюцца ў сакавіку.

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

Аўтарызуйце запыт, перш чым нешта будзе выдадзена

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

Спісаны ноўтбук, запланаваная задача якога ўсё яшчэ працуе, не павінен атрымліваць новае права. RFC 7030 варта прачытаць тут, бо ён аддзяляе аўтэнтыфікаванае перарэгістраванне ад аўтарызацыі і палітыкі на баку сервера; гэта мадэль, якую можна пазычыць, а не сцвярджэнне, што OpenVPN ці EasyRSA пастаўляюць гэты пратакол.

Дастаўка, падрыхтоўка і актывацыя — асобныя крокі

Выдача захоўвае ідэнтычнасць, прызначэнне і адносіны выдачы, а замена, створаная з новай парай ключоў, бескарысная, калі адпаведны ключ не падарожнічае разам з ёй. Дастаўляйце пару па канале, за якім стаіць праект кантролю доступу, бо невыгадвальны URL — гэта не кантроль, а зацямненне.

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

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

Спачатку спраектуйце аднаўленне прапушчанага акна

Калі ноўтбук дасягае службы рэгістрацыі толькі праз VPN, заканчэнне тэрміну стварае пятлю: прыладзе патрэбен сертыфікат, каб увайсці ў тунэль, і тунэль, каб атрымаць сертыфікат. Вызначце пазапаласную дамоўленасць да адпраўкі першай запланаванай задачы, ці гэта асобна аўтэнтыфікаваная канцавая кропка рэгістрацыі, ці перарэгістрацыя з дапамогай адміністратара.

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

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

Падобныя артыкулы