Tartsa az OpenVPN CA aláírókulcsát az /etc/openvpn-en kívül

Két könyvtár, amely egy útmutatóban hasonlónak tűnik, teljesen különböző feladatokat lát el. Az egyik a hitelesítésszolgáltatót tartalmazza: annak privát kulcsát, sorozatszám-számlálóját és minden általa aláírt dolog nyilvántartását. A másik azt tartalmazza, amire a daemonnak az indításhoz és az ügyfelek kiszolgálásához szüksége van. Mindkettőt ugyanazon a hoszton, ugyanazon fiók alatt elhelyezni egy délutánra kényelmes, a telepítés hátralévő életére pedig drága, mert a daemon ekkor az egyetlen kulcs mellett fut, amely bármilyen általa kívánt identitást képes előállítani.

Mit tartalmaz a CA munkaterülete

A PKI-könyvtár kibocsátói állapot, nem konfiguráció. Tartalmazza a CA privát kulcsát és tanúsítványát, egy sorozatszám-fájlt, a kiadott tanúsítványok indexét és az ezekből előállított, identitásonkénti anyagot.

Egy kérelem aláírása megváltoztatja ezt az állapotot, ezért a munkaterület egy adminisztrátor által kezelt fiókhoz tartozik olyan hoszton, ahol a VPN-szolgáltatás nem fut. Aki a CA privát kulcsát olvasni tudja, olyan tanúsítványt tud kiadni, amelyben a kiszolgáló megbízik, tehát a kulcs védelme az egész bizalmi modell egyetlen fájlban. Egy lépés megspórolásáért egy második helyre másolni egy második védendő és egy második elfelejtendő dolgot teremt. Minden aláírás növeli a sorozatszámot és bejegyzést fűz az indexhez, ezért a munkaterület az állapot egyetlen példánya, nem pedig fájlok mappája.

A CA nyilvános tanúsítványa más. Terjesztésre szánják, és az ügyfelek és kiszolgálók ezzel ellenőrzik egymást.

Mit olvas a daemon indításkor

Egy futó kiszolgáló kis készletet fogyaszt: saját tanúsítványát, saját privát kulcsát, a CA tanúsítványát a partnerek ellenőrzéséhez és a választott módja által megkövetelt kulcsanyagot. Ezeket az útvonalakat indításkor és újratöltéskor is beolvassa.

A tulajdonjogot ahhoz az egységhez kell mérni, amely valóban elindul, nem egy interaktív root-héjhoz. A deklarált homokozás a fájlrendszer egy részét csak olvashatóvá vagy láthatatlanná teheti, még akkor is, ha a rootként végzett kézi próba sikerül.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

A harmadik sort szokták kihagyni az emberek. A daemon saját fiókjától kérdezi, hogy olvashatja-e a kulcsot, és ez a kérdés egyetlen változata, amely számít, miután a jogosultságokat elengedték. A rootként kapott nulla kilépési kód semmit sem mond arról, mi történik az elengedés után.

A két hibaútvonalat érdemes szétválasztani, mielőtt bármilyen engedélyt módosít. Az aláírási hiba a PKI-könyvtárra, annak szülőkönyvtárain a keresési engedélyre és a kibocsátót futtató fiókra mutat. Az indítási hiba az egységre, annak munkakönyvtárára és a kiszolgáló konfigurációjában megnevezett útvonalakra mutat. Az egész fa mindenki számára olvashatóvá tétele egyiket sem javítja, és eltávolítja a határt, amelytől mindkettő függ.

Miért vall kudarcot később a CA-kulcs kiszolgálóra másolása

A másolat általában hibakeresési lépésként indul: valaki meg akar újítani egy ügyfelet a VPN-hoszten, így a CA-kulcs az /etc/openvpn könyvtárba kerül, és a megújítás működik. Az azonnali feladat sikerül, és a határ eltűnt.

Aztán a kiszolgálóról biztonsági mentés készül, és az aláíró hatóság bekerül a mentésekbe. Egy pillanatkép, egy támogatási csomag vagy a konfigurációs könyvtár másolata most magában hordozza a megbízható identitások kiadásának képességét, ameddig a CA érvényes. Aki ezzel a másolattal rendelkezik, bármilyen, a kiszolgáló által elfogadott névhez készíthet tanúsítványt, beleértve a soha ki nem adott neveket is. Az egyetlen nyilvántartás erről a kiadásról az, amelyet meg kívánnak tartani.

Az ilyen állapotból való helyreállás nem egy fájl törlésének kérdése. El kell döntenie, hogy a kulcs nyilvánosságra került-e, ha igen, rotálni kell a CA-t, és újra kell osztani a bizalmat minden partnernek. Egy külön munkaterület elkerüli az egész beszélgetést.

Fiókok, könyvtárak, biztonsági mentések

Adjon a kibocsátónak saját fiókot és saját könyvtárat, a VPN-hosztól távol, ahol ez praktikus. Adjon a daemonnak másik fiókot, olvasási hozzáféréssel a telepített anyaghoz és írási hozzáférés nélkül bármihez, ami tanúsítványt ad ki. Telepítsen úgy, hogy a nyilvános tanúsítványokat kifelé másolja, és soha ne húzza befelé a kibocsátó privát állapotát. Mentse a két szerepet külön, mert érzékenységük és helyreállítási történetük eltér.

Visszavonás után frissítse a CRL-fájlt, amelyet a kiszolgáló konfigurációja megnevez, majd töltse újra a szolgáltatást, hogy az új kapcsolatok beolvassák. A Easy-RSA dokumentáció a munkaterület elrendezését és az aláírási munkafolyamatot tárgyalja; a körülötte lévő tulajdonjogi szabályok továbbra is a hosztjára vonatkozó döntés. Ellenőrizze, mit töltött be a szolgáltatás ezzel: openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate ahelyett, hogy feltételezné, hogy az újratöltés felvette.

Egy teszt, amely bizonyítja a szétválasztást

Ellenőrizze a negatív esetet, ne csak a működőt. Írjon alá egy tanúsítványt a kibocsátó fiókjából a tervezett módon, majd igazolja, hogy ugyanaz a fiók nem tudja elindítani a szolgáltatást, és nem tudja olvasni a kiszolgáló privát kulcsát. Ezután igazolja, hogy a daemon fiókja nem tudja olvasni a CA privát kulcsát.

Ez a három ellenőrzés néhány percet vesz igénybe, és túlél személyzeti változásokat, mert engedélyekről szóló állítások, nem szokásokról szólók. Írja le az eredményt az érintett útvonalakkal és fiókokkal, valamint a futtatás dátumával. A következő ember, aki örökli ezt a telepítést, különben újra levezeti a határt egy olyan útmutatóból, amelynek soha nem volt ilyenje. A dátumozott feljegyzés az is, amitől a következő felülvizsgálat percekig, nem pedig egy délutánig tart.