Deutsch
Francais
Nederlands
Svenska
Norsk
Dansk
Suomi
Espanol
Italiano
Portugues
Magyar
Polski
Cestina
Русский
A tanúsítványhitelesítő (CA) rendszerek létrehozása és kezelése kulcsfontosságú szerepet játszik a biztonságos kommunikáció biztosításában, különösen a titkosított adatátvitel terén. Az OpenSSL egy széles körben használt eszköz, amely segít a különböző típusú tanúsítványok generálásában, kezelésében és aláírásában. A következő szövegben az OpenSSL konfigurációjának és a tanúsítványok kezelésének alapvető lépéseit fogjuk bemutatni.
Az OpenSSL konfigurációja kulcsfontosságú a CA működésében. Az egyik legfontosabb konfigurációs elem a default_ca kulcs, amely a különböző tanúsítványokat kezelő beállításokat tartalmazó szekcióra mutat. A CA_default szekció felelős a tanúsítvány aláírásáért, és meghatározza, hogy a rendszer hogyan működik, és milyen paraméterek szükségesek a tanúsítványkérés kezeléséhez.
A konfigurációban meghatározott alapértelmezett könyvtár (base_dir) az a hely, ahol az OpenSSL új fájlokat hoz létre, ha nem adunk meg másik helyet. A root tanúsítvány és annak privát kulcsa azok az alapvető fájlok, amelyek szükségesek a tanúsítványok aláírásához. A CA szekcióban meghatározott fájlok tárolják a kiadott tanúsítványok történelmét, beleértve az index és a sorozatszám nyomkövetőket is, amelyek segítenek a kiadott tanúsítványok rendszerezésében.
Az aláírt tanúsítványok 10 éves érvényességgel rendelkeznek, és SHA-512 üzenet-kivonatokat használnak az aláírások generálásához. Az X.509 verzió 3 kiterjesztések segítenek a tanúsítvány céljának meghatározásában, és ezek a kiterjesztések kritikusak a tanúsítványok biztonságos használatához.
Az egyik legfontosabb kiterjesztés, amit figyelembe kell venni, a Subject Alternative Name (SAN), amely lehetővé teszi a tanúsítvány számára, hogy több IP címet vagy hosztnevet tartalmazzon, amelyekre érvényes. Ez segít abban, hogy egyetlen tanúsítvány több szerverre vagy szolgáltatásra is érvényes legyen, anélkül, hogy külön-külön tanúsítványokat kellene létrehozni. Ezt az opciót a copy_extensions = copy beállítással valósíthatjuk meg, így a tanúsítványkéréshez tartozó SAN-kat a végleges aláírt tanúsítványba másolhatjuk.
Amikor az OpenSSL req parancsot használjuk, új kulcspárt, root tanúsítványt és aláírási kérelmet generálunk. A req parancs alapértelmezés szerint nem kér felhasználói adatokat, mivel a konfigurációs fájlban már előre be vannak állítva a szükséges információk. A generált kulcsok 4096 bit hosszúak, és a tanúsítványkérés aláírásához használt üzenetkivonat SHA-512-t alkalmaz.
A tanúsítványok aláírásához szükséges politikákat a signing_policy szekcióban határozhatjuk meg. Bár ezek az opciók választhatóak, azok, amelyek kötelezővé vannak téve, azt jelentik, hogy bárkinek, aki tanúsítványt szeretne, meg kell felelnie a CA által előírt szervezeti és helyi értékeknek.
A CA szekciókban az nsComment beállítás segít röviden leírni a tanúsítvány típusát, míg a subjectKeyIdentifier a közönséges kulcs hash értékét adja, amely segít azonosítani a kulcspárt. Az authorityKeyIdentifier a CA kiadó kulcsát azonosítja, és segít megerősíteni a tanúsítvány hitelesítését. Az alapértelmezett basicConstraints beállítás CA:TRUE értékre van állítva, hogy jelezze, hogy a konfiguráció egy CA-t reprezentál, amely más tanúsítványok aláírásáért felelős.
Az keyUsage beállítások kritikusak, és azokat azokat az opciókat kell tartalmazniuk, amelyek lehetővé teszik a tanúsítvány számára, hogy aláírásokat végezzen. A pathlen:0 beállítás, amely az ca_intermediate szekcióban található, azt jelenti, hogy az aláíró CA nem hozhat létre további alárendelt CÁ-kat, és csak felhasználói vagy szerver tanúsítványokat írhat alá.
A client_cert és server_cert szekciók különbsége abban rejlik, hogy a client_cert csak olyan tanúsítványokat hoz létre, amelyek képesek TLS kapcsolatokat kezdeményezni, míg a server_cert olyan tanúsítványokat generál, amelyek fogadni képesek a TLS kapcsolatokat. A flex_cert szekció mindkét kiterjesztést tartalmazza, és mind kliens, mind szerver tanúsítványokat képes kezelni.
Miután minden szükséges beállítást és konfigurációt végrehajtottunk, a root CA generálásához a következő parancsot kell futtatni:
Ez a parancs egy új, 4096-bites tanúsítványt generál, amely 10 évig érvényes, és SHA-512 üzenet-kivonatot használ. A tanúsítvány tartalmát az alábbi parancs segítségével ellenőrizhetjük:
Fontos megjegyezni, hogy a root CA-t önállóan aláírják, mivel az aláíró és a címzett ugyanaz, és az authorityKeyIdentifier valamint a subjectKeyIdentifier értékek azonosak.
A root CA által kibocsátott tanúsítványokat nyomon követhetjük az index és sorozatszám-tracker segítségével. Az index nyomon követi a kiadott tanúsítványok adatokat, míg a sorozatszám-tracker az elérhető következő sorozatszámot tárolja.
Hogyan kezeljük a Syslog adatokat: sablonok és szabálykészletek alkalmazása
A Syslog naplóüzeneteinek kezelésére és feldolgozására különböző technikák és eszközök állnak rendelkezésre. A Rsyslog rendszerének egyik alapvető eszköze a sablonok alkalmazása, melyek segítségével dinamikusan módosíthatjuk az üzenetek tartalmát, és testreszabhatjuk a naplózási folyamatot. Ebben a fejezetben a Rsyslog sablonok és szabálykészletek használatát vizsgáljuk, amelyek lehetővé teszik az üzenetek formázását, a dinamikus fájlnevek létrehozását, valamint a logok különböző kimenetekre irányítását.
A sablonok alapvetően kétféle formátumot kínálnak: sztring és lista típusú sablonokat. A sztring típusú sablonok egyszerű módosítást tesznek lehetővé az üzenet tartalmában, míg a lista típusú sablonok lehetővé teszik, hogy az üzenet egyes elemeit statikus és dinamikus értékek keverésével formázzuk meg.
A sztring típusú sablonok esetében az üzenetben szereplő egyes elemeket speciális szintaxissal, például %property:fromChar:toChar:options% kifejezésekkel lehet módosítani. Ezzel a módszerrel lehetőség nyílik arra, hogy egy adott üzenetet például nagybetűssé alakítsunk. A fromChar és toChar mezők üresek maradhatnak, ami az egész üzenetet befolyásolja. Az alábbi példában a msg mezőt nagybetűs formára alakítjuk át:
A sztring típusú sablonok előnye, hogy egyszerűek és könnyen olvashatóak, de a lista típusú sablonok még nagyobb rugalmasságot biztosítanak a formázásban. A lista típusú sablonok esetében minden egyes mezőt egy-egy kulcsszóval és paraméterekkel definiálunk, mint például constant(value="...") és property(name="..."). Az alábbi példa egy egyszerű lista sablont mutat be, amely a tűzfal naplóbejegyzéseit formázza meg:
Ez a sablon a constant és property kulcsszavak kombinációját használja, hogy az üzenetet az előírt formátumban alakítsa. A msg mezőhöz egy compressspace="on" opció is tartozik, amely eltávolítja a felesleges szóközöket az üzenetből, így biztosítva, hogy két egymást követő szóköz helyett csak egy maradjon.
A dinamikus fájlnevek használata szintén fontos funkció a Syslog adatfeldolgozásában. A sablonok segítségével fájlneveket generálhatunk dinamikusan a naplózott üzenetek tulajdonságai alapján, például a hosztnevek vagy IP címek alapján. Például a következő sablon a tűzfal naplóüzeneteket egy-egy egyedi fájlba irányítja a hosztnév alapján:
Ez lehetővé teszi, hogy a naplókat egyedileg kezeljük, és tárolásukhoz különböző fájlokat használjunk, amelyek megfelelnek a megőrzési és auditálási követelményeknek.
A JSON kimenetek generálása is elterjedt a Rsyslog rendszerében. A jsonmesg nevű speciális tulajdonságot használva az üzenetek kulcs-érték párként továbbíthatók, ami elősegíti az üzenetek könnyebb feldolgozását és elemzését más rendszerekben, például Logstash-ben. Az alábbi sablon egyszerű JSON kimenetet generál a naplózott üzenetekből:
Az ilyen típusú sablonok előnye, hogy a naplózott adatokat könnyen integrálhatjuk más rendszerekbe, mint például az adatelemző platformok, és lehetőséget adnak a naplózott adatok részletesebb feldolgozására.
A szabálykészletek (rulesets) alkalmazása lehetővé teszi az üzenetek finomabb szintű szűrését és feldolgozását. A szabálykészletek if-else feltételek segítségével határozzák meg, hogy milyen műveletek hajtódjanak végre egy-egy naplóüzenet esetében. A következő példa azt mutatja be, hogyan irányíthatjuk a tűzfal naplóit dinamikusan egy fájlba, amelynek neve a hosztnév alapján jön létre:
Ez a szabálykészlet először ellenőrzi, hogy a naplóüzenet tartalmazza-e a [UFW szöveget, majd végrehajtja az akciót, amely a dinamikusan generált fájlba irányítja a naplóüzenetet.
A szabálykészletek és sablonok kombinálása lehetővé teszi a naplóüzenetek tartalmának módosítását és a különböző kimeneti célokhoz való irányítását. Például egy szabálykészlet segítségével egyedi címkéket adhatunk a naplóüzenetekhez, vagy módosíthatjuk a forrást, hogy az jobban illeszkedjen az adott környezethez.
A Syslog üzenetek helyes feldolgozásának megértése és a sablonok, szabálykészletek hatékony alkalmazása alapvető fontosságú a rendszerek naplózási folyamatainak finomhangolásához. A Rsyslog rendszerének rugalmassága és bővíthetősége lehetővé teszi, hogy testreszabott naplózási megoldásokat építsünk, amelyek megfelelnek a különböző auditálási és megőrzési követelményeknek, miközben biztosítják az adatok hatékony feldolgozását.