Lista e bllokimit e Nebula: shpërndaje vetë, feneri nuk do ta bëjë

Zbatimi i listës së bllokimit është veti e hostit që kryen kontrollin, jo e certifikatës që kontrollohet. Një makinë që nuk e ka ngarkuar kurrë zërin vazhdon ta pranojë identitetin, dhe asgjë në handshake nuk ju paralajmëron se dy peer-e nuk pajtohen. Rregullimi i lirë dhe ai i shtrenjtë për një kredencial të ekspozuar ndryshojnë në shtrirje dhe në kthyeshmëri, prandaj zgjidhni me qëllim. Seksionet më poshtë mbulojnë çfarë bën zëri, ku duhet dorëzuar, kur rrotullimi është përgjigjja më e mirë dhe si të provoni se njëra prej tyre funksionoi.

Çfarë bën në të vërtetë një zë në listën e bllokimit

Konfigurimi i PKI rendit gjurmë gishtash që një host duhet t'i refuzojë edhe pse certifikata është nënshkruar në mënyrë të vlefshme dhe nuk ka skaduar. Zbatimi ndodh lokalisht, kundrejt listës që hosti ngarkoi kur shërbimi filloi. Asgjë nga zëri nuk udhëton brenda certifikatës, kështu që një peer nuk mund ta mësojë vendimin nga kredenciali që i tregohet. Kjo është arsyeja pse një fener nuk luan rol këtu: fenerët ndihmojnë peer-et të gjejnë njëri-tjetrin dhe përcjellin trafikun aty ku një rrugë e drejtpërdrejtë dështon. Ata janë një shtresë zbulimi dhe përcjelljeje, jo një kanal shpërndarjeje konfigurimi.

Përditësimi i një makine ndryshon vendimet e asaj makine dhe çdo peer tjetër e lë saktësisht ashtu si ishte. Një peer që i beson autoritetit nënshkrues dhe nuk e ka parë kurrë zërin nuk ka arsye të refuzojë asgjë. Testimi i revokimit duke vëzhguar fenerin pra nuk provon asgjë, sepse komponenti që po vëzhgoni nuk u kërkua kurrë të zbatojë listën.

Identifikoni certifikatën, jo pajisjen

Përdorni gjurmën e gishtit të kredencialit që synoni të refuzoni, sepse një emër hosti, një etiketë pajisjeje ose një adresë aktuale identifikon një makinë sot dhe diçka tjetër muajin tjetër. Asnjë prej këtyre vargjeve nuk shfaqet në listën e bllokimit dhe asnjë nuk i mbijeton një riinstalimi. Printoni certifikatën, lexoni gjurmën e gishtit dhe kontrolloni që i përket kredencialit që po tërhiqet dhe jo zëvendësuesit të tij. Leximi i të dy skedarëve ka rëndësi kur një zëvendësues është lëshuar tashmë, pasi certifikatat e vjetra dhe të reja mund të ndajnë një emër dhe të ndryshojnë në çdo fushë tjetër.

Regjistroni cila gjurmë gishti u bllokua dhe kur, që një auditim i mëvonshëm të ndajë një ndryshim të përfunduar nga një i synuar. Vini re edhe çfarë nuk bën zëri: nuk e pavlefshëm autoritetin nënshkrues dhe nuk pengon pranimin e një certifikate të ardhshme nga ai autoritet. Bllokimi i një certifikate hosti dhe zëvendësimi i një autoriteti të komprometuar janë operacione të ndryshme me pasoja të ndryshme.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Shpërndajeni si çdo konfigurim tjetër

Trajtoni listën si konfigurim me një mekanizëm dorëzimi, jo si një skedar që dikush e redakton kur kujtohet. Shtyjeni listën e plotë në vend të një delte, që një host që humbi një përditësim të mëparshëm të konvergojë në vend që të grumbullojë boshllëqe. Dokumentacioni PKI i Nebula rekomandon pikërisht këtë, dhe këshilla ia vlen të ndiqet fjalë për fjalë në vend që të parafrazohet në një proces manual.

Konfirmoni që shërbimi që punon e ringarkoi përmbajtjen, jo vetëm që skedari në disk ndryshoi. Ndiqni cilat makina e zbatuar ndryshimin dhe mbani listën e mbetur të dukshme derisa të jetë bosh. Një laptop i mbyllur për një javë është një peer që nuk e mësoi kurrë vendimin, dhe mund të rilidhet nga një rrjet që askush nuk e priste. Regjistroni metodën e dorëzimit pranë gjurmës së gishtit, sepse revokimi i radhës e ripërdor atë dhe në të parin procesi korrigjohet.

Lista e bllokimit apo rrotullimi i autoritetit

Një zë në listën e bllokimit është i ngushtë: një identitet ndalon së punuari dhe gjithçka tjetër vazhdon. Rrotullimi i autoritetit nënshkrues është i gjerë: çdo certifikatë që ai lëshoi bëhet e pabesuar, dhe çdo host ka nevojë për një kredencial të re dhe një ankorë të re besimi. I pari është një revokim i synuar dhe i dyti është një migrim, prandaj kërkojnë miratime të ndryshme dhe dritare mirëmbajtjeje të ndryshme. Tabela i vendos të dy krah për krah për shtrirje, përpjekje dhe kthyeshmëri.

Një laptop i humbur kërkon listën e bllokimit, sepse rrezja e goditjes është një identitet dhe ndryshimi është i kthyeshëm nëse bllokuat gjurmën e gabuar. Një çelës autoriteti i zbuluar kërkon rrotullim, sepse lista e bllokimit nuk mund të ndihmojë me certifikata që nuk janë lëshuar ende. Midis këtyre ekstremeve, pyesni nëse kredenciali i ekspozuar mund të kishte nënshkruar diçka tjetër, pasi një autoritet është më shumë se një host.

Shkruani vendimin përpara një incidenti, sepse zgjedhja nën presion priret të prodhojë si parazgjedhje opsionin e gjerë. Cilado rrugë që merrni, pika e punës që mbetet është e njëjtë: provoni se zbatimi ndodhi në hostet që kanë rëndësi. Regjistrimi i gjurmës së gishtit dhe datës në atë moment është ai që e bën provën të mundur më vonë.

Verifikoni refuzimin dhe pjesën e mbetur

Lidhuni nga identiteti i bllokuar dhe konfirmoni dështimin, më pas lidhuni nga një peer i autorizuar dhe konfirmoni se ai ende arrin atë që i nevojitet. Një ndryshim që prish të gjithë nuk është revokim i suksesshëm. Bëjini të dyja nga sesione të reja, sepse gjendja e ruajtur në cache mund ta fshehë rezultatin.

Kontrolloni nëse një sesion i vendosur përfundon pas ndryshimit, dhe shënoni sjelljen për versionin dhe konfigurimin tuaj në vend që të supozoni se redaktimi i një skedari përfundon diçka. Opsioni disconnect_invalid mbulon klientët certifikatat e të cilëve kanë skaduar ose janë të pavlefshme, prandaj konfirmoni si zbatohet në rastin tuaj përpara se të mbështeteni tek ai. Nëse përfundimi i menjëhershëm është kërkesë, testojeni atë specifikisht dhe regjistroni çfarë vëzhguat. Më pas përsëritni testin pas një rindezjeje, sepse një host që e zbaton listën vetëm deri në rindezjen tjetër ka një problem dorëzimi që testi i parë e fshehu. Një fener i shëndetshëm ju thotë se zbulimi funksionon, jo se ndonjë peer zbatoi një politikë.