Nebula tiltólista: terítsd szét, a világítótorony nem fogja
A tiltólista bejegyzés csak azokon a hosztokon érvényes, amelyek betöltötték. Hasonlítsd össze a lista terítését a CA rotációjával, majd ellenőrizz egy elutasított partnert és egy működőt.
A tiltólista érvényesítése a vizsgálatot végző hoszt tulajdonsága, nem a vizsgált tanúsítványé. Egy gép, amely soha nem töltötte be a bejegyzést, továbbra is elfogadja az identitást, és a kézfogásban semmi nem figyelmeztet arra, hogy két partner nem ért egyet. Ugyanahhoz a felfedett hitelesítő adathoz az olcsó és a drága megoldás hatókörben és visszafordíthatóságban tér el, ezért szándékosan válassz. Az alábbi szakaszok leírják, mit tesz a bejegyzés, hova kell eljuttatni, mikor jobb válasz a rotáció, és hogyan bizonyítható, hogy valamelyik működött.
Mit tesz valójában egy tiltólista-bejegyzés
A PKI-konfiguráció olyan ujjlenyomatokat sorol fel, amelyeket a hosztnak el kell utasítania, még akkor is, ha a tanúsítvány érvényesen aláírt és nem járt le. Az érvényesítés helyben történik, az ellen a lista ellen, amelyet a hoszt a szolgáltatás indításakor betöltött. A bejegyzésről semmi nem utazik a tanúsítványban, így a partner nem tudhatja meg a döntést a neki megmutatott hitelesítő adatból. Ezért nincs itt szerepe a világítótoronynak: a világítótornyok segítenek a partnereknek megtalálni egymást, és továbbítják a forgalmat ott, ahol a közvetlen útvonal meghiúsul. Ezek felderítési és továbbítási rétegek, nem konfigurációterjesztési csatornák.
Egy gép frissítése megváltoztatja annak a gépnek a döntéseit, és minden más partnert pontosan úgy hagy, ahogy volt. Egy partner, amely megbízik az aláíró hatóságban és soha nem látta a bejegyzést, semmi okot nem lát az elutasításra. Ezért a visszavonás tesztelése a világítótorony figyelésével semmit nem bizonyít, mert attól az összetevőtől, amelyet figyelsz, soha nem kérték a lista érvényesítését.
A tanúsítványt azonosítsd, ne az eszközt
Az elutasítani kívánt hitelesítő adat ujjlenyomatát használd, mert egy hosztnév, egy eszközcímke vagy egy aktuális cím ma egy gépet azonosít, jövő hónapban valami mást. Ezek közül egyik karakterlánc sem szerepel a tiltólistán, és egyik sem éli túl az újratelepítést. Nyomtasd ki a tanúsítványt, olvasd el az ujjlenyomatot, és ellenőrizd, hogy a kivonuló hitelesítő adathoz tartozik, nem annak utódjához. Mindkét fájl elolvasása számít, ha az utód már kiadásra került, mert a régi és az új tanúsítvány osztozhat a névben, és minden más mezőben eltérhet.
Jegyezd fel, melyik ujjlenyomatot blokkoltad és mikor, hogy egy későbbi audit megkülönböztesse a befejezett változtatást a szándékolttól. Azt is jegyezd fel, mit nem tesz a bejegyzés: nem érvényteleníti az aláíró hatóságot, és nem akadályozza meg, hogy egy jövőbeli tanúsítványát elfogadják. Egy hoszt-tanúsítvány blokkolása és egy kompromittált hatóság lecserélése különböző műveletek, különböző következményekkel.
nebula-cert print -path /etc/nebula/host.crt
pki:
blocklist:
- "a1b2c3d4e5f6"
Terítsd szét, mint bármely más konfigurációt
Kezeld a listát konfigurációként, amelynek kézbesítési mechanizmusa van, ne olyan fájlként, amelyet valaki szerkeszt, amikor eszébe jut. A teljes listát küldd el, ne deltát, hogy az a hoszt, amely kihagyott egy korábbi frissítést, felzárkózzon, ahelyett hogy hézagokat halmozna fel. A Nebula PKI dokumentációja pontosan ezt javasolja, és érdemes szó szerint követni, nem pedig kézi folyamattá átfogalmazni.
Erősítsd meg, hogy a futó szolgáltatás újratöltötte a tartalmat, és ne csak azt, hogy a lemezen lévő fájl megváltozott. Kövesd nyomon, mely gépek alkalmazták a változtatást, és tartsd láthatóan a fennmaradó listát, amíg ki nem ürül. Egy hétre lecsukott laptop olyan partner, amely soha nem tanulta meg a döntést, és olyan hálózatról csatlakozhat újra, amelyre senki nem számított. Jegyezd fel a kézbesítési módot az ujjlenyomat mellé, mert a következő visszavonás újra használja, és az elsőnél hibakeresik a folyamatot.
Tiltólista vagy hatóságrotáció
A tiltólista-bejegyzés szűk: egy identitás leáll, minden más folytatódik. Az aláíró hatóság rotációja széles: minden általa kiadott tanúsítvány megbízhatatlanná válik, és minden hosztnak új hitelesítő adat és új bizalmi horgony kell. Az első célzott visszavonás, a második migráció, ezért különböző jóváhagyásokat és különböző karbantartási ablakokat igényelnek. A táblázat egymás mellé állítja őket hatókör, ráfordítás és visszafordíthatóság szerint.
| 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 |
Az elveszett laptop a tiltólistát kívánja, mert a kár sugara egy identitás, és a változtatás visszafordítható, ha rossz ujjlenyomatot blokkoltál. A kiszivárgott hatóságkulcs rotációt kíván, mert a tiltólista nem segít azokon a tanúsítványokon, amelyeket még nem adtak ki. E szélsőségek között kérdezd meg, aláírhatott-e mást is a felfedett hitelesítő adat, mivel egy hatóság több mint egy hoszt.
Írd le a döntést egy incidens előtt, mert a nyomás alatti választás hajlamos alapértelmezésként a széles lehetőséget adni. Bármelyik utat választod, a fennmaradó munkatétel ugyanaz: bizonyítsd, hogy az érvényesítés a fontos hosztokon megtörtént. Az ujjlenyomat és a dátum akkori rögzítése teszi lehetővé a bizonyítást később.
Ellenőrizd az elutasítást és a maradékot
Csatlakozz a blokkolt identitástól, és erősítsd meg a hibát, majd csatlakozz egy engedélyezett partnertől, és erősítsd meg, hogy még mindig eléri, amire szüksége van. Az a változtatás, amely mindenkit elvág, nem sikeres visszavonás. Mindkettőt friss munkamenetekből végezd, mert a gyorsítótárazott állapot elrejtheti az eredményt.
Vizsgáld meg, hogy egy meglévő munkamenet véget ér-e a változtatás után, és jegyezd fel a viselkedést a verziódhoz és konfigurációdhoz, ahelyett hogy feltételeznéd, hogy egy fájl szerkesztése bármit megszüntet. A disconnect_invalid opció azokra az ügyfelekre terjed ki, amelyek tanúsítványa lejárt vagy érvénytelen, ezért erősítsd meg, hogyan vonatkozik az esetedre, mielőtt támaszkodnál rá. Ha az azonnali megszüntetés követelmény, teszteld külön, és jegyezd fel, amit tapasztaltál. Ezután ismételd meg a tesztet újraindítás után, mert az a hoszt, amely a listát csak a következő újraindításig érvényesíti, olyan kézbesítési problémával küzd, amelyet az első teszt elrejtett. Egy egészséges világítótorony azt mondja meg, hogy a felderítés működik, nem azt, hogy bármely partner alkalmazott egy házirendet.