Közös CA, külön ajtók: egy szolgáltatás egy beengedési fájlhoz

A közös hatósággal szemben érvényesülő tanúsítvány bizalmi tesztet teljesített, nem tagsági tesztet. Ezt a két döntést gyakran összemosják, mert mindkettő a kapcsolódás pillanatában történik, és az összemosás addig láthatatlan, amíg egy szolgáltatásba olyasvalakit nem engednek be, akinek nem lenne ott a helye. A megoldás nem egy második hatóság; hanem egy második döntés, szolgáltatásonként meghozva és ott rögzítve, ahol a démon olvassa. Tartsa a kettőt külön, és az ezen a területen tapasztalható zűrzavar nagy része eltűnik.

Egy megbízható lánc semmit sem mond a szolgáltatás-tagságról

Két szolgáltatás elfogadhatja ugyanazt a kibocsátó hierarchiát, és mégis különböző populációi lehetnek. Egy laptop az elsőhöz tartozik, és nem érheti el a másodikat, miközben ugyanazon hierarchia más kliensei valóban oda tartoznak. A hatóság eltávolítása abból a szolgáltatásból mindenkit kizárna, aki jogszerűen használja, tehát a munka beengedés, nem bizalom.

Segít elképzelni két zárat egy ajtón. A tanúsítvány a külső zárat nyitja, a szolgáltatásonkénti döntés pedig a belsőt; egyik sem helyettesíti a másikat. A csak külső zárral rendelkező szolgáltatás egyáltalán nem érvényesít tagságot, csupán hitelesít. Írja le mindkét döntést, mielőtt bármit módosítana, mert egy olyan szabályzat, amely csak egy működő kapcsolat formájában létezik, nem auditálható. A következők a belső zárról szólnak.

Alakítsa a választható felülírásokat beengedési kapuvá

Az ügyfélkonfigurációs könyvtár általában kényelmi eszköz: a benne lévő fájlok felülírják az általuk megnevezett ügyfelek beállításait, a fájl nélküli ügyfél pedig egyszerűen a kiszolgáló alapértelmezéseivel fut. Egyetlen direktíva ezt a kényelmet kapuvá alakítja, így a hiányzó fájl azt jelenti, hogy a kapcsolat elutasításra kerül.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

A közösségi kiadású OpenVPN 2.6 ccd-exclusive a kézikönyv oldalán dokumentálja pontosan ezt a feltételt, és a megnevezett fájl keresése az ügyfél tényleges identitásától függ. Más build-ek és termékek által kezelt kiszolgálók eltérhetnek, ezért erősítse meg a telepített verziót, mielőtt máshol ugyanerre a szemantikára támaszkodna.

Tekintse a fenti útvonalat példának, és ellenőrizze a telepített elrendezést, ahelyett hogy egy útmutató kitalálta könyvtárat hozna létre. Hagyja a meglévő tanúsítványellenőrzéseket, a kiszolgálóidentitás-ellenőrzéseket és a fiókhitelesítést pontosan úgy, ahogy voltak, mert a töredék feltételt ad hozzá, és semmit nem távolít el. Készítse elő a változást élesítés előtt, mert a rossz ponton keletkező elutasítás tanúsítványhibának tűnik, és a hatósághoz tereli a vizsgálatot. Ezután erősítse meg, hogy az elutasított ügyfél naplósora a hiányzó konfigurációs fájlt nevezi meg, nem a láncot.

Egy könyvtár szolgáltatásonként, nem egy közös lista

A tagság ahhoz a szolgáltatáshoz tartozik, amely érvényesíti, ezért minden szolgáltatás a saját könyvtárát és a saját fájljait tartja. Két szolgáltatás egy listára irányítása megosztja velük a tagságot akár akarta ezt valaki, akár nem, és az így létrejött változás nehezen vezethető vissza egy döntésre. A közös hatóság közös maradhat; a beengedési fájlok nem. Külön tartásuk azt is jelenti, hogy az egyik szolgáltatás hibája nem szélesítheti csendben a másikat.

A DEFAULT bejegyzés az az eset, amely félrevezeti az embereket. Tartalékbeállításokat ad, ha nem található megnevezett fájl, de nem ez az a megnevezett fájl, amelyet a kapu megkövetel, ezért önmagában nem tud beengedni egy ügyfelet. Teszteljen egy ügyfelet, amelynek egyáltalán nincs bejegyzése, és erősítse meg az elutasítást; ha ezt az ügyfelet beengedik, akkor a tartalék érvényesül, és ccd-exclusive nem hatályos abban a példányban.

A tényleges identitás dönti el, melyik fájlt olvassák

A keresés azt az identitást használja, amellyel az ügyfél ténylegesen hitelesítette magát, ami általában a tanúsítvány közös neve. Ahol a kiszolgáló felhasználónevet és jelszót is ellenőriz, és ezt a nevet a közös névre képezi le, ott a fájlnak inkább a hitelesített felhasználónévhez kell illeszkednie. Az eltérés olyan hihető fájlnevekkel teli könyvtárat hagy hátra, amelyeket soha nem választanak ki.

Az olvasás a másik fél. A démon általában indítás után elengedi a jogosultságokat, ezért a csökkentett fióknak olvasási hozzáférésre van szüksége a könyvtárhoz és annak minden bejegyzéséhez. Az ügyfelek nem hozhatják létre a saját bejegyzésüket semmilyen írható útvonalon keresztül, mert az önkiszolgáló beengedés teljesen hatástalanítja a mechanizmust. Ellenőrizze a csatolási és megosztási engedélyeket, nem csak a fájlmódot, mert egy könyvtár, amely az egyik fiók számára zártnak tűnik, egy másik számára nyitott lehet. Ezután erősítse meg, melyik fiókot használja valójában a futó folyamat, nem pedig azt, hogy melyik fiókot említi az unit fájl. A kettő csak akkor azonos, ha semmi más nem változtatta meg őket.

Figyelje külön az elutasítást, a beengedést és a visszavonást

Próbáljon egy szolgáltatáshoz tartozó identitást, és erősítse meg, hogy csatlakozik. Próbáljon egy érvényes tanúsítványt bejegyzés nélkül, és erősítse meg, hogy elutasítják. Próbáljon egy identitást, amelyet a másik szolgáltatásba beengedtek, és erősítse meg, hogy itt nem engedik be. Jegyezze fel a szolgáltatáspéldányt és a tényleges identitást minden eredmény mellé, mert e kontextus nélkül az eredményt senki más nem tudja megismételni.

A visszavonás külön művelet a visszahívástól. A beengedési fájl szerkesztése eltávolít egy szolgáltatásra vonatkozó jogosultságot, miközben az identitás mindenhol másutt érvényes marad, viszont egy kompromittált kulcs a szervezet visszahívási válaszát igényli. Döntse el előre, mi történik a már felállított munkamenetekkel, mert sem a könyvtár szerkesztése, sem a visszahívási lista nem fejezi be őket önmagukban.

A beengedés is csak az első kapu. Egy szolgáltatáshoz csatlakozás semmit sem mond a mögötte lévő alhálózatokról, adatbázisokról vagy felügyeleti interfészekről, és ezt az erőforrás-szabályzatot külön kell megírni és tesztelni.