IBM Tivoli Directory Server

IBM Tivoli Directory Server
Fejlesztő	IBM
Operációs rendszer	AIX HP-UX Microsoft Windows Sun Solaris RHEL SuSE
Platform	x86 SPARC PowerPC IBM System i IBM System z9
Kategória	Címtárszolgáltatás
Licenc	zárt
Az IBM Tivoli Directory Server weboldala

Az IBM Tivoli Directory Server (ITDS), korábban IBM Directory Server, az LDAP (Lightweight Directory Access Protocol) egy megvalósítása.

Korábbi verziók

Kezdetben IBM SecureWay Directory néven futott a termék, egészen az 5.1-es verzióig. A következő, 5.2-es kiadás nevébe ismét bekerült a Tivoli kulcsszó. Azóta IBM Tivoli Directory Serverként ismert a termék. A legfrissebb verzió jelenleg a 6.2-es verzió, amely 2008 novemberében jelent meg.

Alkotóelemek

• Adattárolásra az IBM DB2 adatbázist használja. A korai verziókban a DB2 viszonylag gyenge teljesítményt nyújtott. Ezen hiányosság az 5.1-es verzióra már ki lett javítva.
• Kiszolgáló: ibmslapd.
• A címtár adminisztrációjához használt eszközök a kiszolgáló gépen futó ibmdiradm (IBM Directory Administration Daemon) elnevezésű alkalmazásra támaszkodnak, amely távelérést tesz lehetővé:
  • Web Administration Tool: J2EE alkalmazás, amelyet az IBM WebSphere Application Server-re lehet telepíteni.
  • Configuration Tool (ldapxcfg): Grafikus felhasználói felület a címtár és az adatbázis beállítására.
  • Kisebb, parancssoros alkalmazások.
• Az IBM Tivoli Directory Server Client SDK fejlesztőeszközöket biztosít LDAP alkalmazások létrehozásához:
  • C nyelvű, alkalmazásprogramozási felületek (Client libraries)
  • C header fájlok
  • Programfejlesztő eszközök dokumentációja és mintaprogramok
  • Mintaprogramok forráskódjai
  • Parancssoros kliens alkalmazások

Címtár biztonsága

Azonosítás

Az IBM Tivoli Directory Server támogatja mind a kiszolgáló, mind a kliens azonosítását.

• A kiszolgáló azonosításához a kliens kap a kiszolgálótól egy X.509 tanúsítványt a kézfogás állapotában. Ha a kliens elfogadja a kiszolgáló tanúsítványát, akkor felépül egy biztonságos, titkosított kommunikációs csatorna a kiszolgáló és a kliens alkalmazás között. Ahhoz, hogy mindez működjön, a kiszolgálónak rendelkeznie kell egy magánkulccsal, és egy a magánkulcshoz kapcsolódó tanúsítvánnyal a kulcsadatbázison belül.
• A kiszolgáló és a kliens azonosítás gondoskodik arról, hogy a két oldal (LDAP kiszolgáló, LDAP kliens) felismerje egymást. A kliens azonosításához az LDAP kliensnek szintén rendelkeznie kell egy X.509 alapú, digitális tanúsítvánnyal, amely az IBM Tivoli Directory Server felé fogja azonosítani.

Az LDAP a 636-os TCP portot használja biztonságos kommunikációra, illetve a 389-es TCP portot titkosítatlan kommunikációra.

A titkosítás működhet SSL (Secure Sockets Layer), TLS (Transaction Layer Security), vagy mindkettő egyidejű alkalmazásával.

Transaction Layer Security

A 2830-as RFC definiálja a Transaction Layer Security (TLS) protokollt, amely két rétegből áll:

• A TLS Record Protocol gondoskodik a kapcsolat biztonságáról DES (Data Encryption Standard) illetve RC4 (ARCFOUR) eljárások alkalmazásával. Az előbb említett, szimmetrikus titkosításoknál használt kulcsban meg kell egyeznie a két kommunikáló félnek minden egyes kapcsolat kiépítése előtt. A TLS Handshake Protocol segítségével tud a két fél megállapodni a titkos kulcsban.
• A TLS Handshake Protocol biztosítja, hogy a kiszolgáló és a kliens egymást azonosítani tudják, valamint megállapodjanak a használt titkosítási eljárásban és az eljáráshoz használt kulcsban, mielőtt további adatokat küldenének egymásnak.

Secure Sockets Layer

Amikor SSL-t használunk az LDAP kommunikáció biztonságossá tételére az IBM Directory Serverrel, akkor mind a kiszolgáló, mint a kliens oldali azonosítás támogatott. A kiszolgáló azonosításához van egy X.509 alapú, digitális tanúsítvány, amely a kliensek felé azonosítja az IBM Tivoli Directory Servert.

Tanúsítványok

Ha kiszolgáló és kliens azonosítást is használunk SSL esetén, akkor a kiszolgáló beállítható úgy, hogy ellenőrizze azt, hogy a klienstől érkező tanúsítvány lejárt-e vagy érvénytelenítették-e. Amikor a kliens kérést küld a kiszolgáló felé, akkor a kiszolgáló lekérdezi az érvénytelenített tanúsítványok listáját egy LDAP kiszolgálótól. Ha a kliens tanúsítványa nem szerepel a visszakapott listán, akkor a kommunikáció engedélyezett SSL-en keresztül a kliens és a kiszolgáló között. Ellenkező esetben nem engedélyezett a kommunikáció.

Interneten keresztül történő használathoz célszerű egy széles körben elfogadott tanúsítványszolgáltató (CA) által kiadott tanúsítvány használata. Ha kizárólag intranetes környezetben használjuk az IBM Tivoli Directory Servert, akkor elegendő lehet a saját cég által aláírt tanúsítvány is.

Sértetlenség

Az adatok sértetlenségét az IBM DB2, valamint az LDAP biztonságos, kommunikációs protokolljai garantálják.

Titkosság

A bizalmas adatok védelme titkosítások használatával történik, hogy illetéktelenek ne férjenek hozzá ezen adatokhoz. Egyik legérzékenyebb adat a felhasználó jelszava. Éppen ezért a biztonságos azonosításon kívül az IBM Tivoli Directory Server egyéb funkciókat is biztosít a titkosság növelésének érdekében.

Jelszavak titkosítása

A felhasználók jelszavai külön titkosítva vannak eltárolva. Ez megakadályozza, hogy a jelszavakhoz bárki hozzáférhessen, beleértve a rendszergazdákat is. Az adminisztrátornak lehetősége van beállítani a userPassword attribútumra egyirányú vagy kétirányú kódolást. Négyféle beállítás létezik jelszavak kódolására:

None	Nincs titkosítás. A jelszavak nyílt szövegként vannak eltárolva.
crypt	A UNIX crypt kódoló algoritmusát használja a jelszavak kódolására tárolás előtt.
SHA-1	Az SHA-1 nemzetközileg elfogadott, szabványosított lenyomatkészítő eljárást alkalmazza a jelszavakra tárolás előtt.
imask	Tárolás előtt alkalmazza a jelszavakra az imask algoritmust. A jelszavak visszanyerése az eredeti, nyílt szöveg egy részével történik. Ez az alapértelmezett beállítás.

Jelszóházirend

Szabályrendszer, amely a jelszavak használatát és adminisztrációját írja le az IBM Tivoli Directory Server rendszeren belül. A szabályok biztosítják, hogy a felhasználók bizonyos időközönként cseréljék a jelszavaikat, valamint hogy a jelszavakra vonatkozó szintaktikai követelmények teljesüljenek. Ugyanezen szabályok korlátozzák a régi jelszavak újrafelhasználását, és kizárják azon felhasználókat, akik meghatározott számszor rossz jelszót adnak meg. Minden felhasználóra vonatkozik ezen jelszóházirend, kivéve a rendszergazdát, és az adminisztrációs csoportba tartozókat.

Jogosultságkezelés

Az ACL (Access Control List) egy engedélylista, amely a címtárbejegyzésekhez van kapcsolva. Lényege, hogy a rendszergazdák korlátozhassák illetve engedélyezhessék a címtár egyes részeihez a hozzáférést. Az ACL terminológiában az Object és a Subject általánosan használt kifejezések. Az Object az a címtárbejegyzés, amelyre az ACL alkalmazva van, míg a Subject azon címtárbejegyzés, amelyre a konkrét engedély vagy korlátozás vonatkozik.

Access control model attribútumai

Minden egyes objektum tartalmazza az egyedi nevét, valamint az attribútumait és azok értékeit. Az Access control model két attribútumhalmazt definiál:

• entryOwner information – bejegyzés tulajdonosa
• Access Control Information (ACI) – hozzáféréssel kapcsolatos engedélyek

Ez megegyezik az LDAP modellel abban, hogy az ACI Information és az entryOwner information attribútum-érték párként van eltárolva.

Az entryOwner information határozza meg, hogy mely Subject-ek hozhatnak létre ACI-t. A bejegyzés tulajdonosa teljes hozzáférést kap a cél object-hez. A bejegyzés tulajdonosát definiáló attribútumok:

• entryOwner: Egyértelműen meghatározza a bejegyzés tulajdonosát.
• ownerPropagate: Meghatározza, hogy az engedélyhalmaz továbbadható-e a részfa leszármazott bejegyzéseire.

A bejegyzés tulajdonosainak teljeskörű engedélye van az object-en bármilyen műveletvégzésre az aclEntry bejegyzéstől függetlenül. Továbbá a bejegyzés tulajdonosai az egyedüliek, akik az object aclEntry bejegyzéseit kezelhetik. A rendszergazdák és az adminisztratív csoport tagjai alapértelmezésben az összes, címtárbeli Object-nek tulajdonosai, és ez a tulajdonosi joguk egyetlen Object-ről sem távolítható el.

Subject

A Subject egy olyan entitás, amely hozzáférést kér valamilyen művelet elvégzéséhez egy Object-en. Egy DN típus és egy DN (Distinguished Name/Megkülönböztető Név) kombinációjából áll. Az érvényes DN típusok az access ID (hozzáférés azonosító), group (csoport), és a role (szerepkör). A DN meghatároz egy egyedi hozzáférés azonosítót, szerepkört, és egy csoportot.

Access targets

Az engedélyek alkalmazhatók egy teljes Objectre (gyerek bejegyzés hozzáadása, bejegyzés törlése), bejegyzés egyes attribútumaira, attribútumcsoportokra (Attribute Access Classes).

Azon attribútumok, amelyek hasonló engedélyeket követelnek meg, osztályokba vannak csoportosítva. Az attribútumok a címtár sémafájlbeli attribútum-osztályokhoz vannak társítva. Ezen osztályok különállók; egy adott osztályhoz hozzáférés nem jelenti azt, hogy egy másik osztályhoz is hozzáférünk. Egy attribute access class egészére történik engedélybeállítás.

Az IBM Tivoli Directory Server öt attribútumosztályt definiál: normal, sensitive, critical, system, és restricted.

Access rights

Egy access target-re alkalmazott LDAP hozzáférési jogok különállók. Egy jog nem von maga után másik jogot. Az egyes jogosultságok persze kombinálhatók, hogy a kívánt jogosultsági listát össze tudjuk állítani. A jogok három részből állnak:

• Action (művelet): Értéke grant (megad) vagy deny (megtagad). Ha ez a mező nem létezik, akkor az megadást (grant) jelent.
• Permission (engedély): Hat alapművelet végezhető egy címtár object-en: bejegyzés hozzáadása, bejegyzés törlése, attribútumérték olvasása, attribútumérték írása, attribútum keresése, attribútumérték összehasonlítás. A lehetséges attribútum engedélyek: olvasás (r), írás (w), keresés (s), és összehasonlítás (c). Ezen felül a felsorolt object engedélyek a bejegyzés egészére vonatkoznak: gyerek bejegyzés hozzáadása (a), bejegyzés törlése (d).
• Access target (hozzáférés célja)

Címtár séma

A séma egy szabályhalmaz, amely a címtárbeli adattárolás elveit határozza meg. Definiálja a megengedett bejegyzéstípusokat, azok attribútum struktúráját, és az attribútumok szintaxisát.

Az IBM Tivoli Directory Server sémája előre definiált, de az igényeknek megfelelően módosítható. A séma az alábbi címtárszabványok alapján épül fel:

• Internet Engineering Task Force (IETF) – LDAP Version 3 RFC-k (például RFC 2252 és RFC 2256)
• Directory Enabled Network (DEN)
• Desktop Management Task Force (DMTF) – Common Information Model (CIM)
• Network Application Consortium – Lightweight Internet Person Schema (LIPS)

Rendelkezésre állás és skálázhatóság

Az IBM Tivoli Directory Server lehetővé tesz másolatkészítést, felosztást a magas rendelkezésre állás és skálázhatóság érdekében. A másolatkészítési mechanizmus biztosítja a redundáns információtárolást és a gyorsabb keresési lehetőséget (a keresésre vonatkozó kérések több kiszolgáló közt vannak elosztva).

Másolatkészítési topológiák:

• Master – Replica (eredeti – másolat)
  • Legegyszerűbb kiépítés.
  • Teljesítményt növeli, mert a kérések több kiszolgáló között vannak elosztva.
  • Magas rendelkezésre állás csak olvasható módban.
  • Skálázható címtár.
  • Azonosítás történhet: Simple bind, SASL EXTERNAL és SSL, Kerberos.
• Master – Forwarder – Replica (eredeti – továbbító – másolat)
  • A Forwarder végzi a másolatkészítési munka egy részét, így csökkentve a Master kiszolgáló terhelését.
  • A Master-Replica topológia jellemzői igazak itt is.
• Peer replication
  • Tovább növeli a teljesítményt és a Master kiszolgáló rendelkezésre állását azzal, hogy több Mastert alkalmaz.
  • A több Master között a Load Balancer végzi kérések elosztását.
  • A Master kiszolgálókat hívják ebben a topológiában Peer-nek.
• Gateway
  • Elosztott rendszer több, fizikailag különböző helyszínen.
  • A gateway kiszolgálók gyűjtik és továbbítják a másolatinformációkat a hálózaton.
  • Csökken az adatforgalom a hálózaton azzal, hogy csak a Gateway kiszolgálók kommunikálnak egymással illetve minden Gateway kiszolgáló a hozzá tartozó Master kiszolgálókkal, és nem az összes Master kiszolgáló egymással.

Naplózás

Az IBM Tivoli Directory Server több naplózási megoldást is kínál. A naplók a webes adminisztrációs eszközzel illetve parancssorból is megtekinthetők. Több naplófajta létezik, amelyeket egyenként lehet beállítani az egyes szinteken. Az egyes naplótípusok magukban foglalják a következőket:

• Error log
• Audit log
• DB2 error log
• Bulkload error log
• Administration daemon error log
• Administration daemon audit log

Adminisztráció

Az IBM Tivoli Directory Server adminisztrációs tulajdonságai:

• Távoli elérés: Az adminisztrációs eszközök és maga a kiszolgáló külön gépeken fut.
• Központosított adminisztráció: Bármely címtár kiszolgáló kézben tartható egy helyről.
• Nagy számú adminisztrációs feladat elérhető beépítve.
• Felhasználóbarát eszközök.

Az adminisztrációs eszközök a directory administration daemon-ra (címtár adminisztrációs folyamat) támaszkodnak, amelynek minden gépen futni kell, amire az IBM Tivoli Directory Servert telepítették. A directory administration daemon LDAP-on keresztül fogadja a kéréseket. Lehetőség van az Tivoli Directory Server indítására, leállítására, újraindítására és figyelésére. A címtár adminisztrációs folyamat alapból a 3538-as porton figyeli a nem SSL kéréseket, és a 3539-es porton az SSL kéréseket, ha az SSL kommunikáció engedélyezett.