Lista de blocare Nebula: distribuie-o, farul nu o va face

Aplicarea listei de blocare este o proprietate a gazdei care face verificarea, nu a certificatului verificat. O mașină care nu a încărcat niciodată intrarea continuă să accepte identitatea, iar nimic din handshake nu te avertizează că doi peers nu sunt de acord. Rezolvarea ieftină și cea scumpă pentru o singură acreditare expusă diferă ca acoperire și ca reversibilitate, așa că alege deliberat. Secțiunile de mai jos acoperă ce face intrarea, unde trebuie livrată, când rotirea este răspunsul mai bun și cum dovedești că oricare dintre ele a funcționat.

Ce face de fapt o intrare în lista de blocare

Configurația PKI listează amprente pe care o gazdă trebuie să le respingă chiar dacă certificatul este semnat valid și neexpirat. Aplicarea se face local, împotriva listei pe care gazda a încărcat-o la pornirea serviciului. Nimic din intrare nu călătorește în interiorul certificatului, așa că un peer nu poate afla decizia din acreditarea care i se arată. De aceea un far nu joacă niciun rol aici: farurile ajută peers să se găsească unii pe alții și relayează traficul acolo unde o cale directă eșuează. Ele sunt un strat de descoperire și relay, nu un canal de distribuire a configurației.

Actualizarea unei mașini schimbă deciziile acelei mașini și lasă fiecare alt peer exact așa cum era. Un peer care are încredere în autoritatea de semnare și nu a văzut niciodată intrarea nu are niciun motiv să refuze ceva. Testarea revocării privind farul nu dovedește deci nimic, pentru că componenta pe care o privești nu a fost niciodată rugată să aplice lista.

Identifică certificatul, nu dispozitivul

Folosește amprenta acreditării pe care intenționezi să o respingi, pentru că un nume de gazdă, o etichetă de dispozitiv sau o adresă curentă identifică o mașină astăzi și altceva luna viitoare. Niciunul dintre aceste șiruri nu apare în lista de blocare și niciunul nu supraviețuiește unei reinstalări. Tipărește certificatul, citește amprenta și verifică faptul că aparține acreditării care este retrasă, nu înlocuitorului ei. Citirea ambelor fișiere contează când un înlocuitor a fost deja emis, deoarece certificatele vechi și nou pot împărtăși un nume și diferi în orice alt câmp.

Notează ce amprentă a fost blocată și când, astfel încât un audit ulterior să separe o schimbare finalizată de una intenționată. Notează și ce nu face intrarea: nu invalidează autoritatea de semnare și nu împiedică acceptarea unui certificat viitor de la acea autoritate. Blocarea unui certificat de gazdă și înlocuirea unei autorități compromise sunt operațiuni diferite, cu consecințe diferite.

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

Distribuie-o ca orice altă configurație

Tratează lista ca o configurație cu un mecanism de livrare, nu ca pe un fișier pe care cineva îl editează când își amintește. Împinge lista întreagă în loc de o deltă, astfel încât o gazdă care a ratat o actualizare anterioară să convergă în loc să acumuleze goluri. Documentația PKI Nebula recomandă exact asta, iar sfatul merită urmat literal, nu parafrazat într-un proces manual.

Confirmă că serviciul care rulează a reîncărcat conținutul, nu doar că fișierul de pe disc s-a schimbat. Urmărește ce mașini au aplicat schimbarea și ține lista restantă vizibilă până când este goală. Un laptop închis o săptămână este un peer care nu a aflat niciodată decizia și se poate reconecta dintr-o rețea la care nimeni nu se aștepta. Notează metoda de livrare lângă amprentă, pentru că următoarea revocare o refolosește, iar prima este locul unde procesul este depanat.

Lista de blocare sau rotirea autorității

O intrare în lista de blocare este îngustă: o identitate încetează să funcționeze și tot restul continuă. Rotirea autorității de semnare este largă: fiecare certificat emis de ea devine neîncrezut, iar fiecare gazdă are nevoie de o acreditare nouă și de o ancoră de încredere nouă. Prima este o revocare țintită, iar a doua este o migrare, așa că necesită aprobări diferite și ferestre de mentenanță diferite. Tabelul le pune pe cele două alături la acoperire, efort și reversibilitate.

Un laptop pierdut cere lista de blocare, pentru că raza de impact este o identitate, iar schimbarea este reversibilă dacă ai blocat amprenta greșită. O cheie de autoritate scursă cere rotire, pentru că lista de blocare nu poate ajuta cu certificate care nu au fost încă emise. Între aceste extreme, întreabă dacă acreditarea expusă ar fi putut semna altceva, deoarece o autoritate este mai mult decât o gazdă.

Scrie decizia înainte de un incident, pentru că alegerea sub presiune tinde să producă opțiunea largă în mod implicit. Indiferent de calea pe care o iei, elementul de lucru rămas este identic: dovedește că aplicarea s-a produs pe gazdele care contează. Înregistrarea amprentei și a datei în acel moment este ceea ce face dovada posibilă mai târziu.

Verifică respingerea și restul

Conectează-te din identitatea blocată și confirmă eșecul, apoi conectează-te dintr-un peer autorizat și confirmă că ajunge în continuare la ce are nevoie. O schimbare care rupe pe toată lumea nu este o revocare reușită. Fă ambele din sesiuni noi, pentru că starea din cache poate ascunde rezultatul.

Verifică dacă o sesiune deja stabilită se încheie după schimbare și notează comportamentul pentru versiunea și configurația ta, în loc să presupui că editarea unui fișier încheie ceva. Opțiunea disconnect_invalid acoperă clienții ale căror certificate sunt expirate sau invalide, așa că verifică modul în care se aplică în cazul tău înainte de a te baza pe ea. Dacă încheierea imediată este o cerință, testeaz-o specific și înregistrează ce ai observat. Apoi repetă testul după o repornire, pentru că o gazdă care aplică lista doar până la următoarea repornire are o problemă de livrare pe care primul test a ascuns-o. Un far sănătos îți spune că descoperirea funcționează, nu că vreun peer a aplicat o politică.