Nebulas blokeringsliste: distribuer den, fyrtårnet gør det ikke
En blokeringslistepost gælder kun på værter, der har indlæst den. Sammenlign distribution af listen med rotation af CA'en, og verificer derefter en afvist peer og en fungerende.
Håndhævelse af blokeringslisten er en egenskab ved den vært, der udfører kontrollen, ikke ved certifikatet, der kontrolleres. En maskine, der aldrig har indlæst posten, bliver ved med at acceptere identiteten, og intet i håndtrykket advarer dig om, at to peers er uenige. Den billige løsning og den dyre løsning for én eksponeret legitimation adskiller sig i rækkevidde og i reversibilitet, så vælg bevidst. Afsnittene nedenfor dækker, hvad posten gør, hvor den skal leveres, hvornår rotation er det bedre svar, og hvordan du beviser, at en af de to virkede.
Hvad en blokeringslistepost egentlig gør
PKI-konfigurationen oplister fingeraftryk, som en vært skal afvise, selv om certifikatet er gyldigt signeret og ikke udløbet. Håndhævelsen sker lokalt mod den liste, som værten indlæste, da tjenesten startede. Intet om posten rejser inde i certifikatet, så en peer kan ikke lære beslutningen fra den legitimation, den får vist. Derfor spiller et fyrtårn ingen rolle her: fyrtårne hjælper peers med at finde hinanden og videresende trafik, hvor en direkte vej fejler. De er et lag for opdagelse og videresendelse, ikke en kanal til distribution af konfiguration.
Opdatering af én maskine ændrer den maskines beslutninger og lader enhver anden peer være præcis som før. En peer, der stoler på signeringsmyndigheden og aldrig har set posten, har ingen grund til at afvise noget. At teste tilbagekaldelse ved at kigge på fyrtårnet beviser derfor intet, fordi den komponent, du kigger på, aldrig er blevet bedt om at håndhæve listen.
Identificer certifikatet, ikke enheden
Brug fingeraftrykket af den legitimation, du vil afvise, fordi et værtsnavn, en enhedsetiket eller en aktuel adresse identificerer en maskine i dag og noget andet i næste måned. Ingen af de strenge optræder på blokeringslisten, og ingen af dem overlever en geninstallation. Udskriv certifikatet, læs fingeraftrykket, og kontroller, at det hører til den legitimation, der udfases, og ikke til dens erstatning. Det betyder noget at læse begge filer, når en erstatning allerede er udstedt, fordi det gamle og det nye certifikat kan dele et navn og afvige i alle andre felter.
Noter, hvilket fingeraftryk der blev blokeret og hvornår, så en senere revision kan skelne en fuldført ændring fra en påtænkt. Læg også mærke til, hvad posten ikke gør: den ugyldiggør ikke signeringsmyndigheden, og den forhindrer ikke, at et fremtidigt certifikat fra den myndighed accepteres. At blokere et værtscertifikat og at erstatte en kompromitteret myndighed er forskellige operationer med forskellige konsekvenser.
nebula-cert print -path /etc/nebula/host.crt
pki:
blocklist:
- "a1b2c3d4e5f6"
Distribuer den som enhver anden konfiguration
Behandl listen som konfiguration med en leveringsmekanisme i stedet for en fil, som nogen redigerer, når de husker det. Skub hele listen i stedet for en delta, så en vært, der missede en tidligere opdatering, konvergerer i stedet for at samle huller. Nebula PKI-dokumentationen anbefaler præcis det, og rådet er værd at følge bogstaveligt i stedet for at omforme det til en manuel proces.
Bekræft, at den kørende tjeneste har genindlæst indholdet, ikke blot at filen på disken er ændret. Følg, hvilke maskiner der har anvendt ændringen, og hold listen over udestående synlig, indtil den er tom. En bærbar computer, der har været lukket en uge, er en peer, der aldrig har lært beslutningen, og den kan genoprette forbindelse fra et netværk, som ingen forventede. Noter leveringsmetoden ved siden af fingeraftrykket, fordi den næste tilbagekaldelse genbruger den, og det er ved den første, processen fejlfindes.
Blokeringsliste eller rotation af myndighed
En blokeringslistepost er smal: én identitet holder op med at virke, og alt andet fortsætter. Rotation af signeringsmyndigheden er bred: hvert certifikat, den har udstedt, bliver ubetroet, og hver vært har brug for en ny legitimation og et nyt tillidsanker. Den første er en målrettet tilbagekaldelse, og den anden er en migrering, så de kræver forskellige godkendelser og forskellige vedligeholdelsesvinduer. Tabellen stiller de to side om side på rækkevidde, indsats og reversibilitet.
| Question | Blocklist entry | Authority rotation |
|---|---|---|
| What stops working | One identity | Every certificate from that authority |
| Fleet work | Push one file and confirm a reload | New credentials and a new trust anchor everywhere |
| Reversible | Yes, remove the line | No, the old authority stays distrusted |
| Fits | A lost or stolen device | A leaked authority key |
En mistet bærbar computer kalder på blokeringslisten, fordi påvirkningsradius er én identitet, og ændringen er reversibel, hvis du blokerede det forkerte fingeraftryk. En lækket myndighedsnøgle kalder på rotation, fordi blokeringslisten ikke kan hjælpe med certifikater, der endnu ikke er udstedt. Mellem de yderpunkter skal du spørge, om den eksponerede legitimation kunne have signeret noget andet, fordi en myndighed er mere end én vært.
Skriv beslutningen ned før en hændelse, fordi valg under pres har tendens til som standard at frembringe den brede mulighed. Uanset hvilken vej du tager, er det resterende arbejdspunkt identisk: at bevise, at håndhævelsen skete på de værter, der betyder noget. At notere fingeraftrykket og datoen i det øjeblik er det, der gør beviset muligt senere.
Verificer afvisningen og resten
Forbind fra den blokerede identitet og bekræft fejlen, og forbind derefter fra en autoriseret peer og bekræft, at den stadig når det, den har brug for. En ændring, der ødelægger alt for alle, er ikke en vellykket tilbagekaldelse. Gør begge dele fra friske sessioner, fordi cachet tilstand kan skjule resultatet.
Kontroller, om en etableret session slutter efter ændringen, og noter adfærden for din version og konfiguration i stedet for at antage, at redigering af en fil afbryder noget. Indstillingen disconnect_invalid dækker klienter, hvis certifikater er udløbet eller ugyldige, så bekræft, hvordan den gælder i dit tilfælde, før du stoler på den. Hvis øjeblikkelig afbrydelse er et krav, skal du teste det specifikt og notere, hvad du observerede. Gentag derefter testen efter en genstart, fordi en vært, der kun håndhæver listen indtil næste genstart, har et leveringsproblem, som den første test skjulte. Et sundt fyrtårn fortæller dig, at opdagelse virker, ikke at nogen peer har anvendt en politik.