Zëvendësimi i një çelësi VPN të rrjedhur: çfarë duhet të bëjë serveri

Një laptop me një çelës klienti u humb, dhe hapi i parë zakonisht është fshirja e kopjes lokale. Kjo nuk ndryshon asgjë në server, i cili ende mban një autorizim që do ta pranojë atë çelës derisa dikush ta heqë. Zëvendësimi është dy operacione, dhe vetëm i dyti ka të bëjë me kredencialin e vjetër.

Kopja lokale nuk është autoriteti

Një kredencial VPN pranohet sepse konfigurimi në anën e serverit e thotë këtë. Për certifikatat kjo do të thotë që certifikata zinxhirohet me një lëshues të besuar dhe nuk shfaqet në një listë revokimi që konsulton porta. Për WireGuard do të thotë që çelësi publik i palës shfaqet në konfigurimin e ndërfaqes. Fshirja e një skedari në një klient heq një kopje të një sekreti dhe e lë rregullin e pranimit të paprekur.

Kjo është arsyeja pse një çelës i vjedhur vazhdon të funksionojë pas pastrimit të dukshëm, dhe pse incidenti duket i pazgjidhur edhe kur konfigurimi i ri instalohet.

Filloni nga rregulli i serverit, pastaj punoni nga jashtë drejt klientit.

Certifikatat: serveri mban vendimin

Lëshoni zëvendësimin përmes procesit të vetë lëshuesit që identiteti i ri të regjistrohet, pastaj tërhiqni të vjetrin me një revokim të nënshkruar. Porta duhet të konfigurohet për të konsultuar atë burim revokimi dhe duhet ta ringarkojë atë, përndryshe skedari qëndron në disk ndërsa tuneli vazhdon të pranojë numrin serial të vjetër. Sesionet aktive gjithashtu mund të mbijetojnë deri në rinegocimin, prandaj planifikoni një rilidhje.

Konfirmoni që zëvendësimi funksionon për aplikacionin e synuar, pastaj konfirmoni përmes një procesi të miratuar që certifikata e tërhequr nuk vendos më akses.

Këto janë dy teste të ndryshme dhe të dyja nevojiten. RFC 5280 përcakton semantikën e certifikatës dhe të revokimit në të cilën mbështetet porta.

WireGuard: çelësi i palës është identiteti

WireGuard nuk ka shtresë certifikatash: çelësi publik i palës është identiteti, dhe hyrja allowed-ips e serverit është autorizimi. Heqja e palës së vjetër nga konfigurimi i ndërfaqes është revokimi, dhe zbatohet menjëherë për shtrëngimet e duarve të reja.

Sesionet ekzistuese përfundojnë kur shtrëngimi i radhës i duarve dështon, që zakonisht ndodh brenda pak minutash dhe jo menjëherë.

Shpërndani konfigurimin e ri përmes një kanali të cilit do t'i besonit një fjalëkalim, sepse çelësi privat është kredenciali. Mbani një çelës për pajisje, që një pajisje e humbur të mos i detyrojë të gjitha pajisjet të ndryshojnë.

Çfarë tjetër ishte në atë paketë

Një paketë klienti shpesh mbart më shumë sesa çelësin privat: një çelës statik TLS, një emër përdoruesi dhe fjalëkalim, një sekret të ndarë më parë ose një token provizionimi. Kufizoni incidentin në atë që u ekspozua vërtet dhe rrotulloni edhe ato artikuj. Rrotullimi i certifikatës duke lënë një çelës statik të ndarë në vend mbyll një derë dhe lë një tjetër hapur.

Nëse paketa u nda midis pajisjeve, çdo pajisje që e mbart trashëgon ekspozimin.

Shkruani çfarë u rrotullua, sepse auditimi i radhës do të pyesë.

Vërtetoni refuzimin, pastaj regjistroni zëvendësimin

Zëvendësimi është i plotë kur qëndrojnë dy fakte: identiteti i ri funksionon për shërbimin e synuar dhe ai i vjetri refuzohet. Verifikoni të dytin me kredencialin e tërhequr nga një mjedis testimi, ose me një përpjekje të kontrolluar që organizata e miraton, dhe lexoni regjistrat e portës për të konfirmuar se refuzimi erdhi nga politika dhe jo nga një gabim shtypi. Pastaj regjistroni identifikuesin e vjetër, atë të riun dhe kohën e ndryshimit, sepse këto tre vlera janë ato që i nevojiten një audituesi për ta rindërtuar. Asgjë tjetër në ticket nuk do ta shpjegojë atë boshllëk.

Mbani çelësat privatë jashtë ticket-ave dhe bisedave, dhe sipas politikës hiqni eksportet e vjetruara nga ruajtja dhe kopjet rezervë.

Një zëvendësim pa test refuzimi është një supozim, jo një rregullim.