Az OpenVPN-ben semmi sem követeli meg, hogy a tanúsítvány az Easy-RSA-ból származzon, és egy már szervezeti PKI-val rendelkező flottának általában nem kellene másodikat építenie. Az igazi munka nem az eszköz kiválasztása, hanem annak eldöntése, mit jelentenek a kiadott identitások, mely partnereket fogadja el az alagút, és hogyan érkezik meg a megújítás és a visszavonás az ellenőrhöz. Haladjon végig az alábbi öt lépésen sorrendben, mert egy későbbi lépés nem tudja kijavítani az elsőben hozott szerepdöntést.

Két szerepet adjon ki egy közös identitás helyett

Minden partnernek saját tanúsítványra és hozzá illő privát kulcsra van szüksége. Kérjen a PKI csapattól kiszolgálói használatú kiszolgáló-identitást és külön klienshasználatú kliens-identitásokat, hogy az alagút a kézfogáskor meg tudja különböztetni a kettőt.

Álljon ellen a határidő-nyomás alatt felbukkanó rövidítéseknek. Egy webszerver kulcsának laptopokra másolása eltörli azt a megkülönböztetést, amelyre a szerepellenőrzés támaszkodik, és a VPN-végpontra telepített CA-aláíró kulcs egy kompromittált gazdagépből kompromittált hierarchiát csinál. Egy PKCS12 csomag hordozhat végpontkulcsot és annak láncát, de soha nem ad engedélyt arra, hogy ezt az identitást más szerepben újra felhasználják.

Kösse be a bizalmi bemeneteket mindkét oldalon

Az ügyfélnek és a kiszolgálónak egyaránt szüksége van egy bizalmi horgonyra, a saját identitására és egy kifejezett szerepelvárásra. Egy ügyfélrészlet, amely mindhármat megadja, így néz ki.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

A kiszolgáló oldala ezt remote-cert-tls client-gyel és saját tanúsítványával tükrözi, és ez az, ami megakadályozza, hogy egy ügyféltanúsítványt kiszolgálóként fogadjanak el. A névellenőrzés a szerepellenőrzéstől külön döntés. Olvassa el a telepített konfigurációt, hogy lássa, melyik mezőt hasonlítják össze, ahelyett hogy böngészőstílusú gazdagépnév-egyezést feltételezne. Mindkét oldalnak kifejezetten meg kell mondania, melyik kibocsátóban bízik, mert a flottán átívelő közös fájlútvonal nem ugyanaz, mint a közös szabályzat.

Szállítsa a köztes tanúsítványokat a bizalom szélesítése nélkül

A két oldalnak nem kell egyetlen kibocsátási láncot megosztania. Amikor egy partner köztes tanúsítvány által aláírt tanúsítványt mutat be, az ellenőrző oldalnak szüksége van arra a köztesre elérhetően, és az OpenVPN megkülönbözteti a bizalmi horgony bemenetét azoktól a további tanúsítványoktól, amelyek egy helyben bemutatott lánc kiegészítésére szolgálnak. Az OpenVPN 2.6 TLS-beállítási referenciája mindkettőt dokumentálja.

Egy köztes CA önmagában nem probléma, de a bizalmi kötegbe dobott széles vállalati gyökér az. Minél szélesebb a horgony, annál több tanúsítvány felel meg a lánctesztnek, és a szerepellenőrzés ezt nem fordítja át jogosult személyzet listájává. Szűkítse a horgonyt arra a kibocsátóra, amely ténylegesen aláírja a VPN-identitásokat, ahol a hierarchia engedi. Ha nem engedi, dokumentálja a szélesebb horgonyt szándékosan elfogadott kockázatként ahelyett, hogy hallgatólagosan hagyná.

Egyezzen meg a PKI csapattal arról, hogyan érkezik meg a megújítás és a visszavonás a VPN-ellenőrökhöz, beleértve azt is, mely kibocsátók számítanak, és ki teszi közzé a listát. A tanúsítványba ágyazott CRL-terjesztési pont utasítás, nem bizonyíték arra, hogy valami letöltötte.

Döntse el, hogyan érkezik meg a visszavonás valójában

A crl-verify arra készteti az ellenőrt, hogy egy fájlt vagy végpontot kérdezzen le, és ehhez a megoldáshoz tulajdonosra és frissítési útra van szükség. Egy lista, amelyet a bevezetés során egyszer másolnak, csendesen abbahagyja az Ön védelmét, amikor először visszavonnak egy tanúsítványt.

Írja le a várható terjedési időt, és tesztelje egy olyan tanúsítvánnyal, amelyet hajlandó visszavonni. Ha a lista nem frissíthető a VPN-gazdagépen, az alternatíva egy rövidebb érvényességi idő plusz egy valóban futó megújítási folyamat, nem pedig annak feltételezése, hogy a visszavonás működik, mert létezik egy URL.

Bizonyítsa az elfogadást egy valódi ügyféllel

Csatlakoztasson egy ügyfelet, amelyet engedélyezni kellene, és erősítse meg a naplóban a megtárgyalt tanúsítvány részleteit. Utána próbálja ki azokat az eseteket, amelyeknek meg kell hiúsulniuk: kiszolgálóként bemutatott ügyféltanúsítvány, a bizalmi horgonyon kívüli kibocsátó tanúsítványa, és visszavont tanúsítvány, ha van egy tartaléka.

Jegyezze fel az elfogadott kibocsátót, a szerepellenőrzést és a visszavonás forrását a profil mellé. Ez a feljegyzés az, amire a következő mérnöknek szüksége lesz, amikor egy múlt hónapban működő eszköz abbahagyja a kapcsolódást, és ez annak a bizonyítéka is, hogy a vállalati CA-t dokumentált elfogadási határon belül használják, nem pedig általános célú bizalmi lerakóként.

Kapcsolódó cikkek