Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Szakdolgozat

Automatizálási és Infokommunikációs Intézeti Tanszék

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Szakdolgozat

Készítette:

Tar Péter ANRKRW 3529 Miskolc, Perczel M. u. 41/a

Köszönetnyilvánítás Szeretnék köszönetet mondani az fps webügynökség Kft csapatának, hogy több éve a csapat tagja lehetek, és ez idő alatt kölcsönösen bővítettük egymás szakmai tapasztalatát. Szeretnék köszönetet mondani Dr. Raffay Csabának, aki témavezetőként irányt mutatott a szakdolgozatom elkészítéséhez. Szeretnék köszönetet mondani a családomnak, akik az évek során mellettem álltak, és támogattak. Szeretnék köszönetet mondani a menyasszonyomnak, aki idejét nem kímélve segített a szakdolgozatom befejezésében.

Tartalom Tartalom ...................................................................................................................... I 1.

Összefoglaló .................................................................................................... 1

2.

Abstract ............................................................................................................ 2

3.

Bevezető .......................................................................................................... 3

4.

Cég bemutatása ................................................................................................ 5

5.

Elméleti háttér.................................................................................................. 6 5.1.

Autentikáció ................................................................................................. 6

5.1.1. Módszerek ............................................................................................. 6 5.1.2. A számítógépes autentikáció története .................................................. 8 5.1.3. Az autentikáció tényezői ..................................................................... 10 5.1.4. Kéttényezős autentikáció .................................................................... 11 5.1.5. Termék autentikáció ............................................................................ 12 5.1.6. Információ tartalom ellenőrzése.......................................................... 12 5.1.7. Akkor és ma ........................................................................................ 13 5.2.

Autorizáció................................................................................................. 14

5.2.1. Hozzáférés-vezérlés ............................................................................ 15 5.3. 6.

Identitás menedzsment ............................................................................... 17 Technikai háttér ............................................................................................. 19

6.1.

Probléma részletes ismertetése .................................................................. 19

6.2.

Korábban alkalmazott rendszerek ismertetése ........................................... 20

6.3.

Lehetséges megoldási módszerek .............................................................. 21

6.3.1. LDAP alapú autentikáció .................................................................... 21 6.3.2. PAM autentikáció MySQL adatbázis tárolással .................................. 23 6.3.3. Kerberos alapú autentikáció ................................................................ 24 7.

A megfelelő autentikációs rendszer kiválasztása........................................... 27

I

7.1.

OpenLDAP ismertetése.............................................................................. 27

7.2.

389 Directory Server ismertetése ............................................................... 30

7.3.

FreeIPA ismertetése.................................................................................... 31

8.

Technikai megvalósítás.................................................................................. 33 8.1.

Előkészületek ............................................................................................. 33

8.2.

FreeIPA telepítése ...................................................................................... 34

8.3.

Replikáció beállítása .................................................................................. 35

8.4.

Linux felhasználó kezelés beállítása .......................................................... 35

8.5.

Webszerver integrálása .............................................................................. 36

8.6.

Projektkezelő rendszer integrálása ............................................................. 37

8.7.

Verziókövető és egyéb webes rendszerek integrálása ................................ 38

8.8.

WiFi és VPN integrálása ............................................................................ 39

9.

Tapasztalatok, eredmények, fejlesztési lehetőségek ...................................... 41

10.

Irodalomjegyzék ............................................................................................ 43

11.

Mellékletek .................................................................................................... 44

11.1.

CD melléklet tartalma ............................................................................ 44

II

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél

1. Összefoglaló Szakdolgozatom témája egy központi autentikációs rendszer kiépítése jelenlegi munkahelyemen, az fps webügynökség Kft-nél. A vállalkozás jelenleg 24 alkalmazottat foglalkoztat, fő tevékenységei közé tartozik honlapok, webes és mobil alkalmazások fejlesztése, valamint az online marketing. A cég mindhárom telephelyén számos fejlesztői alkalmazást

és

menedzseléshez,

számlázáshoz

szükséges

szoftvert

használnak

párhuzamosan. A fő problémát az előbb említett rendszerek eltérő autentikációja képezte, mivel egyrészt a felhasználóknak minden rendszerhez más és más felhasználó név és jelszó párost kellett megjegyezniük, másrészt adminisztrációs szempontból egy alkalmazott érkezése vagy távozása esetén minden rendszerben külön kellett végrehajtani a felhasználó létrehozását, illetve törlését. Megoldást egy olyan rendszer kiépítése jelentett, mely egyetlen felületen biztosítja a felhasználók különböző rendszerekben történő adminisztrálását, mindemellett megfelel a cég által támasztott magas biztonsági követelményeknek és támogatja a távmunkát is. Szakdolgozatom első részében általánosságban és szakmai szempontból is bemutatásra kerülnek a probléma legfőbb alapfogalmai úgy, mint az autentikáció, az autorizáció és az identitás menedzsment. Ezt követően kutatómunkám eredményeképpen részletesebben ismertetésre kerülnek a cégnél korábban alkalmazott rendszerek, a megismert protokollok, szoftverek, valamint a legelterjedtebb lehetséges megoldási módszerek, mint például az LDAP, PAM és Kerberos alapú autentikációs rendszerek. A dolgozat további fejezeteiben a megfelelő autentikációs rendszer kiválasztását követően , ismertetem a FreeIPA szoftvercsomag implementálásának menetét, kitérve a cég által használt legfontosabb

többek között a projektkezelő és verziókövető rendszerek

integrálására. Végül a FreeIPA nyújtotta további lehetőségek és a jövőben megvalósításra váró feladatok kerülnek bemutatásra, kiemelve az fps webügynökség saját fejlesztésű keretrendszerének integrálását. Szintén jövőbeni terveim közt szerepel a kétlépcsős autentikáció bevezetése, mely tovább növelné rendszereink biztonságát. Szakdolgozatom eredményeképpen munkahelyemen egy olyan autentikációs rendszer került bevezetésre, mely megkönnyíti és gyorsabbá teszi a felhasználók adminisztrációját, ezáltal hozzájárul a vállalkozás fejlődéséhez és sikeres üzletmenetéhez.

1


2. Abstract The subject of my thesis is to build up a Central Authentication System at my current workplace, the fps web agency Ltd. The company has currently 24 employees, and the main activities include developing websites, mobile applications and online marketing. In all three premises of the company several developer tools and applications are used which are needed for management and finance parallel, as well. The main problem caused by the previously mentioned system’s different authentication methods, as on one hand users had to memorise different username and password pairs for every system, on the other hand from administration aspect when a new colleague arrives or leaves, all systems had to be modified separately, adding or removing the user’s every credential. A good solution could be to build a new system, which is capable for the administration of the users in different systems at one place; nevertheless it suits the company’s security requirements as well as supports telework. In the first part of my thesis main concepts of this problem are introduced in general and in technical aspects like authentication, authorization, and identity management. After that part, the results of my research are detailed, such as the used old system at the company, the known protocols, softwares as well as the most spread technical methods like LDAP, PAM and Kerberos based authentication systems. In the following chapters of my thesis after choosing the suitable authentication system I present the process of implementing the FreeIPA software package, mentioning the most important softwares the project management system and version control system used by the company. Finally the additional services and features, which are planned to be developed in the near future, of the FreeIPA are introduced, focusing on the integration of the content management framework developed by the fps webagency. Also my future plans consist of introducing the two-factor authentication, which will increase the comprehensive security of the whole system. As a result of my thesis, an authentication system is launched, which makes the administration of the users much easier and quicker in order to support the development and growth of the company.

2


3. Bevezető A szakdolgozatom témája egy központi autentikációs rendszer kiépítése jelenlegi munkahelyemen. Mivel a szakmai gyakorlati időmet is ennél a cégnél töltöttem, mint rendszergazda, így rálátásom volt a korábban használt változatos rendszerek, és az azokhoz kapcsolódó azonosítási szolgáltatások működésére. A webes projektek fejlesztéséhez számos különböző nyílt forráskódú fejlesztői és teszt környezet kialakítására van szükség, melyekhez biztonságos és személyre szabott hozzáférést kell biztosítani az alkalmazottak részére. Gyakorlatban, egy alkalmazott érkezése vagy távozása esetén, nehézséget és többletmunkát jelentett a felhasználói azonosítók létrehozása a megfelelő jogkörrel, mivel minden egyes használt szolgáltatás külön-külön a saját alapértelmezett módszere szerint tárolta ezeket az érzékeny adatokat. Ez a széttöredezett rendszer nem támogatta a több telephelyre történő terjeszkedést és a távmunkában történő munkavégzést. A gyakorlati időt követően kizárólagos főállású rendszergazdaként a korábban megismert rendszerek üzemeltetése teljes mértékben az én hatásköröm alá került, így lehetőségem nyílt egy új infrastruktúra kiépítésére és a felhasználói információk kezeléséhez kapcsolódó folyamatok optimalizálására. A stabilitási problémák megoldása mellett kiemelten fontosnak találtam a központi autentikáció megvalósítását, és a felhasználói adatok biztonságos tárolását. Az új rendszerrel szemben támasztott követelményeket három főbb csoportba lehet sorolni. Egyrészt a cég érdekét szem előtt tartva, egy olyan rendszer kerüljön megvalósításra,

mely költséghatékony,

nyílt

forráskódú

szoftverekből

építkezik,

ugyanakkor valamilyen iparági szabványt valósít meg, így biztosítva a kompatibilitást különböző rendszerekkel. Fontos szempont volt a cég számára az is, hogy a felhasználói adatokat könnyen, de biztonságosan el lehessen érni, akár távolról is. Másrészt az alkalmazottak szempontjából a felhasználói élmények javítása az elérendő cél azáltal, hogy a kollégáknak egy felhasználónév-jelszó páros kell csak megjegyezniük a szolgáltatások akár távolról történő eléréséhez, illetve saját maguk tudják a jelszavukat kezelni, betartva a vállalati jelszó házirendet. Harmadrészt technikailag szükséges a rendszer redundáns kiépítése, mely lehetővé teszi a több, földrajzilag távol lévő telephelyen történő használatot akkor is, ha kommunikációs problémák lépnek fel az átviteli úton.

3

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Megoldást tehát egy olyan rendszer kiépítése jelentene, mely egyetlen felületen biztosítja a felhasználók különböző rendszerekben történő adminisztrálását, mindemellett megfelel a cég által támasztott magas biztonsági követelményeknek és támogatja a távmunkát is. Így olyan rendszer megvalósítására törekedtem, mely a fentebb ismertetett feltételeknek megfelel, és illeszkedik az újonnan kialakított hálózati infrastruktúrába.

4


4. Cég bemutatása Az fps webügynökség Kft-t miskolci fiatalok alapították közel 15 évvel ezelőtt. Fő tevékenységei közé tartozik weboldalak, webes alkalmazások, mobil alkalmazások fejlesztése, továbbá online marketing tevékenységek végzése az elkészült termékekhez kapcsolódóan. Céljaként tűzte ki, hogy a felhasználók számára élményt nyújtson a megoldásaival. Fontosnak tartják a helyi tehetségek felfedezését és gondozását. Jelenleg három telephelyen összesen 24 fő alkotja az fps színes csapatát különböző pozíciókban (1. ábra). A webes és mobil alkalmazás fejlesztők mellett grafikusok, menedzserek, értékesítők, marketingesek és alkalmanként különböző alvállalkozók is részt vesznek a cég sikeres alkotó munkájában. A miskolci központi telephelyen főként grafikusi és marketing tevékenységek, valamint webes fejlesztés folyik, részben a Miskolci Egyetemen, részben miskolci szakközépiskolákban végzett fiatal tehetségek tudásával. A szegedi telephelyen mobil alkalmazásfejlesztés folyik, a Szegedi Egyetem tudásbázisára alapozva. Az ügyfelek nagy része budapesti székhelyű, vagy nemzetközi cég, így a budapesti iroda a hatékonyabb ügyfél kapcsolattartást szolgálja értékesítő és menedzser alkalmazottakkal. Több változatos projekt fut párhuzamosan, melyek akár több részleget is érinthetnek a különböző munkafolyamatok során. Az elvállalt munkák többsége nagyban támaszkodik a fejlesztői csapat közreműködésére, mely a miskolci és a szegedi telephelyen valósul meg. A több irodában történő munkavégzés számos megoldandó biztonsági követelményt támasztott a régi infrastruktúrával szemben, melyre az nem volt alkalmas, így szükségessé vált az áttervezése.

Ügyvezető

Pénzügy

Fejlesztői csapat Miskolc

Fejlesztői csapat Szeged

Grafikus/UX

Support csapat

Online Marketing

Grafikus/UX

1. ábra: Az fps webügynökség Kft. szervezeti felépítése 5

Sales


5. Elméleti háttér 5.1. Autentikáció Az autentikáció – más néven hitelesítés egy olyan folyamat, amely során egy adat vagy entitás bizonyítja a róla állított tulajdonságok valódiságát. Az azonosítással szemben, mely

egy

személy

vagy

tárgy

személyazonosságát

igazolja,

a

hitelesítés

a

személyazonosság bizonyításának folyamata - mely jelentheti egy személy azonosságának igazolását iratokkal, egy weboldal hitelességét digitális tanúsítvánnyal, egy tárgy kormeghatározását, vagy azt, hogy egy termék megegyezik a csomagolásán feltüntetett megnevezéssel. Egy szóban összefoglalva, az autentikáció az azonosítás eredetiségének ellenőrzésére szolgál.

5.1.1. Módszerek A hitelesítésre számos példát találhatunk

az antropológia, antik tárgyak és a

művészet területén is mindennapos problémát jelent egy tárgy vagy műkincs eredetiségének igazolása, vagyis hogy az adott tárgy a meghatározott személy által készülte vagy a megfelelő helyen vagy korban. Az autentikációnak 3 típusát különböztetjük meg. A hitelesítés első típusa annak elfogadása, hogy a bizonyíték megbízható személytől, első kézből származik, mely szerint az identitás valódi. Amikor egy művészeti alkotás vagy egy tárgy hitelességére vagyunk kíváncsiak, bizonyítékként szolgálhat egy barát, családtag, munkatárs, aki igazolja a tárgy eredetét annak tanúsításával, hogy a tárgy a készítő birtokában volt. Erre jó példa az autogrammal ellátott sport relikviák, melyeknél valaki tanúsítja, hogy ténylegesen az adott sportoló írta alá. A szóbeszéd alapján történő hitelesítésre a számítógépes biztonság területén nem lehet példával szolgálni. A hitelesítés második típus az objektum tulajdonságait hasonlítja össze azokkal az ismert tulajdonságokkal, melyek az objektum valódiságát igazolják. Például egy művészeti szakértő hasonlóságokat keres a festési stílusban, ellenőrzi az aláírás elhelyezését és kinézetét, vagy összehasonlítja a tárgyat egy régi fényképpel. Az archeológus szénizotópos kormeghatározással fogja igazolni egy lelet korát, elvégzi a felhasznált anyagok kémiai vizsgálatát, vagy összehasonlítja az építés vagy díszítés stílusát más hasonló eredetű leletekkel. A hang és fény fizikája és összehasonlítása a már ismert valós környezettel, felhasználható hangfelvételek, fényképek vagy videók hitelességének vizsgálatára.

6

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Dokumentumok hitelességének megerősítésekor, a felhasznált tintát vagy papírt vizsgálják, hogy elérhető volt-e abban a korban, melyből feltételezhetően származik. A tulajdonságok összehasonlítása támadhatósági felületet képez a hamisítványok esetén. Általánosságban elmondható,

hogy az

eredetitől

megkülönböztethetetlen

hamisítványok elkészítése rendkívül nagy szakértelmet igényel, így a befektetett erőforrások jóval nagyobb anyagi ráfordítást jelentenek, mint a hamisításból származó profit. A művészet és antik tárgyak területén a tanúsítványok hitelesítése nagy jelentőséggel bír a tárgy népszerűségét és értékét tekintve. A tanúsítványokat szintén lehet hamisítani, ami ugyancsak problémát jelent. Például Jacques van Meegeren a jól ismert hamisító apja (Han van Meegeren) munkáit hamisította és gondoskodott az eredetüket igazoló tanúsítványokról is. A csalásért, hamisításért kiszabott büntetőjogi és polgárjogi szankciók csökkenthetik a hamisításra való hajlamot, a lebukás esélyének függvényében. Készpénz és egyéb fizetőeszközök esetén gyakran használják ezt a fajta hitelesítési eljárást. A papírpénzeket, érméket és csekkfüzeteket a fizikai jellemzőik miatt nehéz sokszorosítani, hiszen ellátják őket vízjellel, hologrammal, dombornyomással, csak UV fény alatt látható mintákkal, melyek alapján a boltosok, vevők, banki alkalmazottak könnyen kiszúrhatják a hamis fizetőeszközt. Az autentikáció harmadik típusa a dokumentációkra vagy más külső állításokra támaszkodik. A büntetőjogi hatóságok a bizonyítási eljárások során gyakran megkövetelik a bemutatott bizonyítékok megfelelő lefoglalását és megőrzését. Erre a célra megfelelő lehet egy írott bizonyíték leltár, valamint a rendőr nyomozók és igazságügyi szakértők vallomása a bizonyítékok megfelelő kezeléséről. Számos régiséghez, dedikált sport ereklyéhez tartozik kísérő dokumentum, mely a tárgy hitelességét igazolja. Ezeknél a csatolt dokumentumoknál is problémát jelent a hamisíthatóságuk, valamint fennáll az elvesztésük esélye is. A fogyasztási cikkek mint például a gyógyszerek, parfümök, divat ruházati cikkek – esetén mindhárom autentikációs módszer alkalmazható a hamisított áruk elterjedésének megelőzésére. Mint fentebb említésre került, ha van egy kiárusított termékünk, akkor az üzlet jó hírnevével hallgatólagosan igazolja a termék eredetiségét – ezt nevezzük a hitelesítés első típusának. A második típusnál már összehasonlítjuk a termék minőségét és kivitelezését a valódiság igazolásához – például egy drága kézi táska esetében megvizsgálhatjuk a varrásokat, a minőségi anyagösszetételt, a termék jellegzetes ismertető jegyeit. A harmadik hitelesítési típus lehet a terméken elhelyezett védjegy megléte amely 7

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél jogilag védett jelölés , vagy a termék bármely más jellegzetes tulajdonsága, mely segít azonosítani az eredeti márkás terméket. A számítógépes tudományok esetén, a felhasználó hozzáférést kaphat a biztonságos rendszerekhez, melyek a hitelesítéshez szükséges felhasználói adatokon alapulnak. A hálózati adminisztrátor a rendszerhez történő hozzáféréshez adhat a felhasználónak egy jelszót, egy belépőkártyát vagy más beléptetésre alkalmas eszközt, mely a hitelességet feltételezi, de nem garantálja. A szoftverhamisítás ellen a cégek nagy előrelépést tettek, bevezették a hologramokat, színváltó nyomatokat, biztonsági sávokat.

5.1.2. A számítógépes autentikáció története Kezdetekben a számítógépes rendszereknél úgy működött a levelezés, hogy a feladó címét maga a feladó állította be. Később alkalmazni kezdték az adott rendszerbe történő belépés esetén az azonosítást. Sajnos manapság is találni olyan rendszereket, amihez nem kell jelszót beírni, csak elegendő az azonosító megadása, és a belépés megtörténik. Ezután következtek a jelszavas rendszerek (2. ábra), amikor az azonosítóhoz egy jelszót is meg kellett adni, így védve az azonosítóval történő visszaélések és az azonosító alatt tárolt adatok jogosulatlan hozzáférések ellen a rendszert.

2. ábra: Számítógépes autentikáció Eleinte kódolatlanul tárolták a jelszavakat, így akinek van hozzáférése a rendszerhez, mások jelszavait is megtudhatta. Később kódolva tárolták a jelszavakat, de még mindig hozzá lehetett férni a jelszavakat tároló fájlokhoz, így különböző technikákkal a kódolt jelszavakat vissza lehetett fejteni. Végül manapság a nagyobb biztonságot adó rendszerekben a jelszófájlok el vannak rejtve a normál felhasználók elől. 8

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél A következő lépés a különböző azonosító eszközök megjelenése volt, melyek bemutatásával a rendszer elfogadta a hozzáférést. A különböző eszközök alatt legtöbb esetben valamilyen kártyát értünk, de manapság már lehetnek egyéb elektronikai eszközökben beépítve, vagy akár kulcstartónak álcázva. Az eddigiekhez képest a legbiztosabb azonosítást a biometrikus azonosítás (3. ábra) adja. A biometriával pontosan azonosítható a felhasználó, de fontos megjegyezni, hogy ez sem ad tökéletes megbízhatóságot és minden körülmények között alkalmazható megoldást.

3. ábra: Biometrikus autentikáció A legelterjedtebb azonosítási típusok az ujjlenyomat-, a szem (retina vagy írisz), és hangalapú azonosítás. Kereskedelemben is elérhető, napjainkban egyre népszerűbb az arcfelismerő, vagy a tenyérlenyomat-alapú azonosítás. Sokéves magyar fejlesztést követően idén került bevezetésre a vénaszkenner az új ferencvárosi futball stadion beléptető rendszerének részeként. A világon egyedülálló beléptető rendszer a szokásos tíz-ötven pont helyett öt millió ponton azonosítja a felhasználó tenyerét, ugyanakkor nem drágább a hagyományos kártyás technikánál. A vénaszkenner a tenyérben található vénák szerkezete alapján azonosítja a személyeket (4. ábra). Az érzékelő infravörös fény kibocsátásával azonosítja a testrészt, valamint hőtérképet készít, hogy kiderüljön, élő szövetről van-e szó. Legfeljebb egy másodperc alatt ötmillió ponton azonosítja a vénatérképet, ez jóval gyorsabb és pontosabb

9

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél a többi biometrikus rendszernél. Az adatok a legmagasabb biztonsági és titkosítási szinteken védettek. A véredények mintája minden embernél ugyanúgy egyedi, mint az ujjlenyomat. Az ujjlenyomat-elemzéssel szemben a vénaszkennelés előnye, hogy az egyedi minta azonosításához kevesebb adatra van szükség. Mivel a belső ismérvnek minősülő biometrikus azonosító nem lopható el, a szenzor használata nem hagy nyomot, így titkos adatgyűjtést sem tesz lehetővé.

4. ábra: Vénaszkenner működési elve A vénaalapú érzékelés kizárólagosan azonosítja az adott személyt, ezért a jövőben a bankkártya, az utazási bérlet mellett akár az útlevelet is kiválthatja. Az azonosítás után a szenzor automatikusan törli a szkennelt mintát, így a tenyér érlenyomata nem nyerhető ki a rendszerből.

5.1.3. Az autentikáció tényezői Egy személyt három különböző módon tudunk azonosítani, melyet a hitelesítés tényezőinek is tekintünk: 

tudás valami, amit a felhasználó tud



tulajdonlás valami, ami a felhasználó birtokában van



tulajdonság a felhasználó valamilyen tulajdonsága

10

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Mindegyik autentikációs tényező olyan adatok halmazát foglalja magában, melyek hitelesítik, vagy megerősítik egy személy azonosságát még mielőtt hozzáférést kapna a rendszerhez, végrehajthatna egy tranzakciót, aláírna egy dokumentumot vagy másoknak jogosultságokat adna. A biztonsággal kapcsolatos kutatások szerint azt tekintjük pozitív autentikációnak, melyhez legalább két, de inkább három tényező megerősítésére van szükség. A három tényező (osztály), valamint az egyes tényezők elemei a következők: Tudás: olyan adat, melyet a felhasználó tud (például jelszó, jelmondat, személyi azonosító szám (PIN – Personal Identification Number), kérdés-felelet (a felhasználónak egy feltett kérdésre kell válaszolnia), minta) Tulajdonlás: olyan eszköz, melyet a felhasználó birtokol (például karkötő, személyi igazolvány, biztonsági token, telefonba épített szoftveres vagy hardveres token, chipkártya) Tulajdonság: olyan tényező, mely a felhasználó megjelenéséhez, viselkedéséhez köthető (például ujjlenyomat, retina mintázat, DNS szekvencia, aláírás, arc, hang, egyedi bioelektromos jelek, vagy más biometrikus azonosítók)

5.1.4. Kéttényezős autentikáció Amikor két elem szükséges hitelesítéshez, kéttényezős autentikációt (5. ábra) kell alkalmazni – mint például a bankkártya (mely felhasználó tulajdona) és a hozzá tartozó PIN-kód (melyet a felhasználónak ismernie kell). Az üzleti hálózatok megkövetelik, hogy a felhasználónak a jelszón (tudás) kívül legyen egy pszeudorandom száma is, melyet a biztonsági token tartalmaz (tulajdon).

5. ábra: Kéttényezős autentikáció

11

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél A nagyon magas biztonsági szinttű rendszerek hozzáféréséhez szükség lehet egy magasság, testsúly, arc és ujjlenyomat (tulajdonság) ellenőrzésre is, valamint egy PINkódra és egy naponta változó kódra (tudás) – ezt továbbra is kéttényezős autentikációnak nevezzük.

5.1.5. Termék autentikáció A hamisított termékeket gyakran eredeti terméknek állítják be, a hamisított fogyasztási cikkek - mint az elektronikai, ruházati termékek, gyógyszerek - sokszor legális termékként vannak értékesítve. Az ellátási lánc felügyelete és a fogyasztók oktatása hozzájárul, hogy kizárólag eredeti márkajelzéssel ellátott termékek kerüljenek eladásra. Még a dobozokon és címkéken elhelyezett biztonsági nyomatok is a hamisítás áldozatává válhatnak. Léteznek biztonsági kulcsot tároló eszközök, melyek a fogyasztói cikkek, hálózatok, licenc menedzsment, ellátási lánc menedzsment autentikációjában nyújtanak segítséget. Általában ezek az eszközök a hitelesítéshez vezetékes vagy vezeték nélküli digitális kapcsolatot igényelnek, akárcsak egy kiszolgáló rendszer vagy hálózat. Ennek ellenére, a komponens hitelesítése nem kell, hogy elektronikus legyen, hiszen az autentikációs chipet mechanikusan is csatlakoztathatjuk és leolvashatjuk – mint például, amikor egy eredeti tintapatront behelyezünk a nyomtatóba. A termékeknél és szolgáltatásoknál alkalmazott biztonsági társprocesszorok megoldást kínálnak a hamisítás megnehezítésére, miközben könnyebbé teszik a hitelesítést.

5.1.6. Információ tartalom ellenőrzése Az információk autentikációja speciális problémákat vet fel az elektronikus kommunikációk során, mint például amikor egy harmadik fél titokban bekapcsolódik egy beszélgetésbe és mindkét féllel kommunikációt folytat, elfogva ezzel a két fél egymásnak küldött üzeneteit. Ez a probléma egy extra azonosítási tényezőt igényelne mindhárom fél megfelelő autentikációjához. Irodalmi hamisításnak tekinthetjük azt, amikor valaki utánozza egy híres író stílusát. Ha az eredeti kézirat, gépelt szöveg vagy felvétel nem áll rendelkezésre, akkor az író maga kell, hogy segítsen bizonyítni vagy cáfolni az irat hitelességét. Mivel azonban a szöveg, hang és video átmásolható új adathordozókra, valószínűleg kizárólag az információs tartalmat magát lehet majd felhasználni a hitelesítés

12

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél során. Ennek megfelelően számos rendszer született a szerzők segítésére, hogy bizonyítani tudják az adott szövegrész tőlük származik vagy plágium. Ezek a szükséges autentikációs tényezők a következők: 

nehezen reprodukálható fizikai eszközök, mint például egy vízjel, pecsét, aláírás, ujjlenyomat, különleges papír használata



egy közös titok, jelmondat elrejtése az üzenetben



elektronikus aláírás

A másik probléma a plagizálás felismerése, amikor egy másik szerző eredményeit saját munkájaként állítja be az író. Az általánosan elfogadott módszer a plagizálás bizonyítására az, hogy megkeresik az adott tartalom vagy ahhoz hasonló szöveg szerepel-e más műben. Bizonyos esetekben a túlzottan magas minőség vagy a stílus nagymértékű eltérése növelheti a plágium gyanúját. Egy üzenet igazságtartalmának meghatározása vagy ténybeli információk pontossága általában egy külön problémaként tekinthető a hitelesítéstől. A technikák széles köre a nyomozói munkától a tudományos kísérletekig áll rendelkezésre. A bírósági eljárások során szükségessé válhat egy videofelvétel valódiságának a megerősítése, hogy az bizonyítékként is felhasználható legyen. A megfelelő felügyeleti nyilvántartás és az analóg vagy digitális felvételek biztonságos tárolása segít biztosítani a bizonyítékok elfogadhatóságát a bíróságon.

5.1.7. Akkor és ma Történelmileg az ujjlenyomatot tekintik a leghitelesebb autentikációs eljárásnak, habár a legújabb bírósági ügyek kételyeket támasztanak az ujjlenyomat megbízhatóságával kapcsolatban. A jogrendszeren kívül is az a tapasztalat, hogy az ujjlenyomat leolvasó rendszerek könnyen becsaphatók. A British Telekom vezető számítógép-biztonsági szakembere jegyezte meg, hogy kevés olyan ujjlenyomat olvasó van, amit még nem játszottak ki. A hibrid vagy kétszintű autentikációs eljárások vonzó megoldást kínálnak, mint például az ujjlenyomattal titkosított privát kulcsok USB meghajtón. A számítógépes adatok összefüggésében kriptográfiai módszereket fejlesztettek ki (mint például a digitális aláírás, vagy a kérdés-felelet), amelyek jelenleg akkor és csak akkor nem becsaphatók, ha a létrehozó kulcs nem kompromittálódott. Jelenleg még nem ismert, hogy ezek a kriptográfián alapuló hitelesítési eljárások bizonyítottan biztonságosak lennének, mivel az előre nem ismert matematikai fejlesztések a támadásokkal szemben

13

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél sebezhetővé tehetik ezeket a jövőben. Amennyiben ez előfordulna, számos múltbéli hitelesítési eljárás megkérdőjelezhetővé válna. Különösen a digitálisan aláírt szerződések lennének megkérdőjelezhetőek, abban az esetben, ha a kriptográfia alapjául szolgáló aláírást törnék fel.

5.2. Autorizáció Az autorizáció folyamata eltér az autentikáció folyamatától - míg az autentikáció egy adott személy vagy tárgy hitelességének ellenőrzésére szolgál, addig az autorizáció egy engedélyezési folyamat, melynek során a felhasználó engedélyt kap bizonyos feladatok elvégzésére. Tehát az autorizáció feltétele az autentikáció. Például, ha egy ügyfél átutalást szeretne kezdeményezni a bankszámlájáról, először fel kell mutatnia a megfelelő személyi azonosításra alkalmas okmányát a bank dolgozójának, aki megerősíti, hogy a kártyán szereplő személy megegyezik annak tulajdonosával. Miután az ügyfél személyazonossága hitelesítésre került, engedélyt kap a banktól, hogy kizárólag a saját bankszámláján műveleteket hajtson végre. Amennyiben egy idegen próbál hozzáférni a saját személyi azonosító okmányával más egyén bankszámlájához, az okmányok sikeresen fogják autentikálni a személyt – hiszen azok nem hamisítványok és a megadott személyhez tartoznak -, de ez az idegen nem fog az autorizáció során hozzáférést kapni más bankszámlájához, mivel az ő személyi adatai nem lettek korábban hozzárendelve ahhoz a bankszámlához. Hasonlóképpen alakul a helyzet, amikor valaki egy számítógépre próbál bejelentkezni (6. ábra), a rendszer elsőként megkéri az illetőt, hogy azonosítsa magát egy felhasználó névvel és a hozzá tartozó jelszóval. Ezután a felhasználó által megadott felhasználónév-jelszó páros összehasonlításra kerül a rendszerben korábban eltárolt adatokkal, így hitelesítve a felhasználó személyét. Ha sikeres az autentikáció, a felhasználói névhez tartozó engedélyek és korlátozások kerülnek kiosztásra, ezt az utolsó lépést nevezzük autorizációnak.

14


6. ábra: Számítógépes autorizáció Habár az autorizáció nem fordulhat elő autentikáció nélkül, az engedélyezést gyakran a két fogalom kombinációjaként szokták értelmezni. Ugyanakkor a rövidítések használatakor is igyekeznek megkülönböztetni a két fogalmat, az autentikációt gyakran jelölik „AuthN” vagy „Au” rövidítéssel, míg az autorizációt „AuthZ” vagy „Az” rövidítéssel szokták hivatkozni egyes körökben. Általában a jogkörök kiosztását az autorizáció részének szokták tekinteni. Napjainkban, az autentikációt is a különböző típusú delegációs feladatoknál szokták felhasználni.

5.2.1. Hozzáférés-vezérlés Az autentikáció és az autorizáció egyik ismert felhasználási területe a hozzáférésvezérlés. A számítógépes rendszereknek, melyeket úgy fejlesztettek ki, hogy csak az engedéllyel rendelkezők tudják használni, fel kell ismernie és ki kell zárnia jogosulatlan felhasználókat. Éppen ezért az ilyen rendszerekhez történő hozzáférés vezérlése rendszerint

egy

autentikációs

eljáráshoz

ragaszkodik,

mely

bizonyos

fokig

megbizonyosodik a felhasználó hitelességéről, jogosultságokat biztosítva ezzel az egyénnek.

15

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Néhány gyakori példa a hitelesítést is tartalmazó hozzáférés-vezérlésre: 

fényképes igazolvány elkérése a vállalkozótól, amikor először találkozunk vele, hogy felújítsa a házunkat



Captcha használata a számítógép és az ember megkülönböztetésére



egyszer használatos, autentikációs jelszó, melyet mobiltelefonon fogadunk



határátlépés útlevéllel



bejelentkezés egy számítógépre



megerősítő e-mail használata, a felhasználó címének ellenőrzésére



netbank használata



készpénz felvétele bank automatából

Bizonyos esetekben, a könnyű hozzáférést a szigorú ellenőrzésekkel ellensúlyozzák ki. Például, a bankkártya hálózat nem mindig kér PIN-kódot a hitelesítéshez, a kisebb tranzakciók során nem kérik a bankkártya tulajdonos aláírását sem, amivel igazolni tudná, hogy rendelkezik a megfelelő engedéllyel a tranzakció végrehajtásához. A rendszer biztonságát az adja, hogy korlátozva van a bankkártya számok kiosztása, valamint a visszaéléseket súlyosan büntetik. A biztonsági szakértők egyetértenek abban, hogy teljes bizonyossággal lehetetlen bizonyítani egy számítógépes felhasználó személyazonosságát. Csupán arra van lehetőség, hogy a korábban lefektetett szabályok szerint, egy vagy több teszt alkalmazásával, melyeken a tesztelt alany megfelel, akkor azok elégséges feltételei a továbbjutásnak. A probléma az, hogy meg kell határozni mely tesztek elégségesek, és melyek nem megfelelőek. Bármely tesztet át lehet egy vagy többféle módon ejteni, különböző nehézségi szinteken. Az informatikai biztonsági szakértők arra is rájöttek, hogy a széleskörű törekvések (mint a vállalati, kutatási és hálózati közösségek erőfeszítései) ellenére, számos esetben továbbra sem rendelkezünk biztos megállapodással az autentikációs követelményekre vonatkozóan. Az egyetértés hiánya nagy akadályt jelent az optimális autentikációs metódusok azonosításában. A fő kérdések tehát: 

Mire való az autentikáció?



Ki profitál az autentikációból / kinek származik hátránya az autentikációs hibákból?



Milyen hátrányok ellen tud ténylegesen védelmet nyújtani egy hatékony autentikáció?

16


5.3. Identitás menedzsment Az identitás menedzsment egy széles adminisztrációs terület, mely az egyének azonosítását és az erőforrásokhoz való hozzáférését kezeli és teszi lehetővé egy adott rendszeren belül azáltal, hogy az identitásokhoz felhasználói jogokat és erőforrásokat rendel hozzá. A legalapvetőbb szinten az identitás menedzsment meghatározza, hogy a felhasználók mit csinálhatnak a hálózaton, milyen eszközökkel és milyen körülmények között. Manapság nagyon sok biztonságtechnikai termék kiemelten támogatja a mobil hozzáférések kezelését a vállalati rendszerekhez. Nagyvállalati környezetben az identitás menedzsment feladata a biztonság és a hatékonyság növelése, miközben csökkentik a költségeket és a többszörösen elvégzett munkát.

7. ábra: Identitás menedzsment rendszer Biztonsági okokból, az identitás menedzsment kezelésére használt eszközöknek külön alkalmazásként kell futniuk a dedikált szervereken, illetve a felhőben. Az identitás menedzsment rendszer (7. ábra) magját azok a szabályok határozzák meg, hogy milyen eszközöket és felhasználókat engednek be a hálózatra és mit érhet el a felhasználó, attól függően, hogy milyen eszközt használ, hol van és így tovább. Mindezek együtt a megfelelő

17

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél menedzsment funkcionalitásától függenek, beleértve a házirend szabályozást, jelentést, jelzést és egyéb gyakori üzemeltetési feltételeket. Egy riasztást például az is előidézhet, ha egy adott felhasználó egy olyan erőforrást próbál elérni, amelyhez nincs jogosultsága. A jelentés egy auditációs naplót készít, amely dokumentálja, hogy milyen tevékenységeket hajtottak végre. Számos identitás menedzsment rendszer biztosít címtár szolgáltatást, mely támogatja a vezetékes és vezeték nélküli felhasználókat és kellően rugalmas ahhoz, hogy megfeleljen bármilyen biztonsági és üzemeltetési követelménynek. A címtár szolgáltatás (directory service) egy olyan speciális adatbázis tárolási forma, mely a fa szerkezetének köszönhetően keresésre van optimalizálva, ennek megfelelően olyan esetekben célszerű ezt használni, ahol kevés a módosítás és nagy számú, gyors lekérdezésre van szükség – mivel az adatok a fa levél elemeiben kerülnek tárolásra. Mindegy egyes ilyen bejegyzésre egyértelműen hivatkozhatunk, mely lényegében a fában a csúcshoz vezető utat írja le. Egy identitás általános modelljét elő lehet állítani néhány axiómával, például minden identitás egy adott névtérben egyedi, vagy az identitások közötti kapcsolat megfelel a valós életbeli egyének közötti kapcsolatnak. Általánosságban egy entitásnak (valós vagy rendszerbeli) több azonosítója lehet, és minden egyes azonosító több tulajdonsággal rendelkezik, néhány ezek közül egyedi az adott névtérben. Az alábbi 8. ábra szemlélteti az elméleti kapcsolati hálót az azonosítók és az egyének között ugyanúgy, mint az azonosítók és tulajdonságaik közötti kapcsolatot.

8. ábra: Identitás általános modellezése

18


6. Technikai háttér 6.1. Probléma részletes ismertetése Az fps webügynökség Kft. 2012-ben a javuló gazdasági mutatóknak és az ügyfelek növekvő igényeinek köszönhetően, új irodát nyitott Szegeden. Mindemellett a cég által tervezett weboldalak megfelelő üzemeltetése megkívánta a saját üzemeltetésű hoszting szolgáltatás bevezetését is. Mindezekből kifolyólag újabb szerverek kerültek üzembe helyezésre, az ország több pontján is. Ezzel párhuzamosan több fejlesztést és menedzsmentet segítő szolgáltatás került bevezetésre, melyek szintén megkövetelték a felhasználók megfelelő azonosítását. A legjelentősebb problémát az okozta, hogy az általunk használt rendszerek és szolgáltatások saját, belső azonosítási rendszert alkalmaztak, mely nagyban megnehezítette a felhasználók kezelését. Legszembetűnőbb példa erre az volt, hogy több felhasználónak is több különböző rendszerhez kellett hozzáférnie, vagy amikor változás állt be az alkalmazottak létszámában. Ilyen esetekben hosszú időt és a jelszavak többszöri megadását vették igénybe a rendszerek, melyek ezáltal komoly biztonsági kockázatot jelentettek. A kiosztott jogosultságok átláthatóságát nagyban megnehezítette, hogy a különböző rendszerek többféle hozzáférései nem voltak egy helyen teljes körűen dokumentálva. A jogosultsági információk szájhagyomány útján terjedtek a rendszergazdák között, így nagy emberi kockázati tényezőt jelentett a belső rendszerek biztonságát illetően. Például egy elbocsátott alkalmazottnak bizonyos rendszerekhez a munkaviszony megszűnését követően is volt hozzáférése, így a céges érzékeny adatok kiszivárogtatását, vagy ellopását technikailag semmi sem akadályozta, csak a jogi következményektől való félelemnek volt visszatartó ereje. A technológiai átalakítást és a cég fejlődését megelőzően, a két kiszolgálóval és egy projektkezelő rendszerrel működő infrastruktúra a régi rendszerben alacsony biztonsági kockázatot és kevesebb adminisztrációs munkát jelentett. Az elmúlt két évben az alkalmazottak létszáma megkétszereződött, a kiszolgálók száma kilencre emelkedett, a használt szolgáltatások száma megsokszorozódott. A korábbi rendszer használatával a hozzáférési jogkörökben bekövetkező változások követése kezelhetetlen lett volna. Szerencsére, a fejlődés folyamata alatt lehetőségem nyílt különböző központosított technológiák megismerésére és kipróbálására.

19


6.2. Korábban alkalmazott rendszerek ismertetése Az fps webügynökség Kft. a nyílt forráskódú rendszerek híve, ahogyan a webes rendszerek nagy része is. Ezáltal Linux disztribúciókat használunk a szervereinken és ha lehetséges nyílt forráskódú szolgáltatásokat veszünk igénybe úgy, mint a Redmine projekt kezelő rendszer. Utóbbi egy Ruby On Rails nyelven írt rendszer, mely MySQL vagy PostgreSQL adatbázis szerverben tárolja az adatokat, beleértve a felhasználói adatokat is.

9. ábra: Felhasználói adatok tárolása Redmine-ban Ezek az adatok egy users nevű táblában (9. ábra), SHA-1 (Secure Hash Algorithm) kódolással vannak tárolva, mely az egyik legelterjedtebb hash-függvény. Ez az algoritmus az NSA által tervezett 160 bit hosszúságú hash, melyet az RFC-3174 internetes jegyzet ír le. Az alkalmazott Linux rendszereknél az alapértelmezett PAM (Pluggable Authentication Module) autentikációs rendszert használtuk, mely egyszerű fájlokban, kódolva tárolta az információkat. A PAM egy olyan magas szintű API-t valósít meg, amely többféle alacsony szintű autentikációs módszert integrál. Lehetővé teszi az autentikációt használó programok számára, hogy a rendszerben alkalmazott autentikációs eljárástól függetlenül tudjanak működni. A PAM működését az RFC 86.0 internetes jegyzet határozza meg, jelenleg ez a legelterjedtebb autentikációs keretrendszer a UNIX és Linux alapú rendszerekben.

20

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél A felhasználói adatokat szöveges fájlban tároltuk, mely a /etc/passwd útvonalon volt elérhető. A fájl tartalmazta a felhasználó nevét, jelszavát MD5 kódolással, csoportazonosítóját, és egyéb szöveges mezőket (10. ábra).

10. ábra: Felhasználói adatok tárolása PAM rendszerben Az MD5 (Message-Digest algorithm 5) egy 128 bites, egyirányú kódolási algoritmus, melyet az RFC-1321 internetes jegyzet ír le. Az MD5 kódolást az RSA algoritmus egyik megalkotója fejlesztette ki 1991-ben. Először 1996-ban fedeztek fel benne hibát, melyet követően a szakemberek más hashelési algoritmusok használatát javasolták, mint például az SHA-1. Később, 2004-ben további biztonsági rések láttak napvilágot, melyek megkérdőjelezték az MD5 megbízhatóságát. Így 2005 óta az algoritmust nem javasolják elektronikus aláíráshoz használni, és 2011-től az SHA-1 algoritmus helyett is az SHA-256 javasolt. Az MD5 kódolást, hibái ellenére még napjainkban is széles körben használják, például jelszótárolásra, jelszókódolásra vagy adatellenőrzésre, fájlok eredetiségének vizsgálatára. A WiFi hálózat üzemeltetéséhez a lakossági célú routereket használtuk, azok beépített autentikációs rendszereivel és jelszókódolásaival. A vezeték nélküli hálózati forgalom kódolására WPA2 Personal titkosítást használtunk.

6.3. Lehetséges megoldási módszerek 6.3.1. LDAP alapú autentikáció A központi autentikációs rendszer Linux rendszeren történő megvalósításához az LDAP (Lightweight Directory Access Protocol) áll a rendszergazdák rendelkezésére, mely egy kliens-szerver protokoll a címtár szolgáltatás megvalósításához. Eleinte X.500 hozzáféréshez alkalmazták, azonban önállóan is használni kezdték egy másfajta címtár szolgáltatásként. 21

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Az X.500 egy olyan számítógép-hálózati szabványcsomag, amely kiterjed a címtárak szolgáltatásaira. Az ITU-T (előző nevén CCITT) fejlesztette ki és 1988-ban fogadták el szabványként. Fejlesztésében a Nemzetközi Szabványügyi Szervezet (ISO) volt az a partner, aki belefoglalta az Open System Interconnection protokollcsomagba., melynek ISO azonosítója ISO/IEC 9594. Az X.500 protokollcsomag négy protokollt tartalmaz, melyek a következők: 

DAP (Directory Access Protocol)



DSP (Directory System Protocol)



DISP (Directory Information Shadowing Protocol)



DOP (Directory Operational Bindings Management Protocol).

Ezek közül számunkra a DAP fontos, mivel ez teszi elérhetővé az X.500 címtár szolgáltatást az internetező kliensek számára. Erre a célra számos alternatívát fejlesztettek ki, melyek közül a legnépszerűbb az LDAP, mely a DAP és az X.500 protokollokat már TCP/IP-n is implementálja. A protokollt az RFC 2251 internetes jegyzet definiálja. Az X.500 alapgondolata, hogy egy hierarchikus fa szerkezetbe (DIT – Directory Infromation Tree) rendezi a bejegyzéseket (11. ábra), melyek eloszthatóak egy vagy több szerveren (DSA – Directory System Agent). A fa egyes levél elemei egy-egy bejegyzést valósítanak meg, melyeknek számos egy vagy több értékű attribútumai vannak.

11. ábra: LDAP fa szerkezete Minden bejegyzésnek van egy a rendszerben egyértelműen meghatározható neve (DN – Distinguised Name), melyet úgy kapunk meg, hogy a fa minden egyes ágának egyedi nevét (RDN – Relative Distinguised Name) bejárási sorrendben összefűzzük egészen a fa gyökeréig.

22

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Az LDAP, mint címtár szolgáltatás a fentebb részletezett adatszerkezetet használja adatbázisként, ugyanakkor részletesebb, tulajdonság alapú információkezelést valósít meg. Mivel a címtárakban az információt gyakrabban olvassák, mint írják, ennek következtében nem alkalmaznak bonyolult tranzakció-kezelést vagy roll-back rendszereket, amelyeket a komolyabb adatbázis kezelő rendszerek használnak a nagy méretű, összetett műveletekhez. Az LDAP címtár szolgáltatás kliens-szerver modellen alapul, melynél egy LDAP kliens csatlakozik valamilyen LDAP szerverhez. A kliens részéről lényegtelen, hogy melyik LDAP szerverhez intézi a kérését, ugyanazt a címtárat látja és válaszként vagy a kért elemet vagy egy mutatók kap, amely egy másik LDAP-beli elemre mutat. Egy-egy elem egy-egy objektumnak felel meg, melynek tulajdonságait – például az azonosításhoz használható jellemzők csoportját – speciális sémák, az objectClass-ok határozzák meg (12. ábra). Az objektumokat több séma alapján is meg lehet határozni. Ezek a sémák írják le, hogy az adott objektumnak mely attribútumai kötelezőek vagy opcionálisak, és ezen attribútumok milyen típusúak lehetnek – illetve tartozik hozzá egy rövid leírás, szintaxis leíró résszel együtt.

12. ábra: Példa egy objektumra Sok esetben lép fel fogalomzavar az LDAP elnevezéssel kapcsolatban, az LDAP csak egy protokoll, és ennek megvalósítására különböző szoftverek léteznek: 

Microsoft Active Directory Server



OpenLDAP Server



Fedora 389 Directory Server



FreeIPA Identity Management Server

6.3.2. PAM autentikáció MySQL adatbázis tárolással A PAM autentikációs modul többféle rendszerben tudja tárolni a felhasználók adatait. Alapértelmezés szerint és ennek megfelelően, kezdetekben az fps webügynökség

23

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Kft-nél sima szöveges fájl szolgált az adatok tárolására. A webfejlesztési környezethez híven felmerült a lehetőség, hogy a fejlesztéskor is használt MySQL adatbázis szervert használjuk a felhasználói adatok tárolására. Az interneten szabadon elérhető az ehhez szükséges PAM könyvtár, mely képes egy előre meghatározott adatbázis séma szerint MySQL adatbázis szerverből a felhasználói adatokat, úgy mint a felhasználónevet, a jelszót titkosítva, a felhasználói- és csoport azonosítót kiolvasni. A MySQL szerverek újabb verziói nagy stabilitással rendelkeznek az olvasási célú terhelés elosztásban, fürtözésben, mely elengedhetetlen feltétele a redundáns kiépítésnek. Ezzel ellentétben a PAM könyvtár fejlesztése megrekedt, 2006 óta nem történt fejlesztés a programkönyvtár kódján. Ez a tény nagyban nehezíti a fentebb már említett módszer újabb rendszereken, újabb technológiákkal történő integrálását, így a MySQL szerver replikációját is. Mivel régi, és régóta nem karbantartott szoftverről van szó, így nem lehet tudni, hogy milyen biztonsági réseket rejt magában, amely elég kritikus probléma egy autentikációs rendszerrel kapcsolatban. A technológia alkalmazhatóságának korlátai miatt, a PAM ilyen irányú több rendszeren történő közös használata nem is került tesztelésre, tervezési síkon a megvalósítása problémákba ütközött.

6.3.3. Kerberos alapú autentikáció A Kerberos a Massachusetts Institute of Technology (MIT) egyetem által kiadott és használt számítógépes hálózati hitelesítési protokoll, melynek elsődleges célja egy kliensszerver modell kialakítása volt, ahol mind a kliens, mind a szerver kölcsönös azonosítást biztosít egymás személyazonosságának megállapítására. A protokollt és a hozzá tartozó szoftvercsomagot eredetileg az Athena Projekt részeként alkották meg, amely elosztott rendszerként egységes felületet biztosított az MITn belüli tudás megosztására és elérhetővé tételére a hallgatók számára. Az Athena Projektnek több része is volt, melyek a befejezést követően a szabad szoftver világában önálló projektekként a mai napig tovább élnek úgy, mint a Kerberos rendszer is. A protokoll több verziót is megélt, az 1-3. verzió csak az MIT belső köreiben fordult elő. Az 1980-as évek végén tették szabadon elérhetővé az első publikus verziót, mely sorban a negyedik volt. 1993 óta az ötödik verzió van érvényben, mely az előző verzió hibáit hivatott javítani és az RFC 1510 internetesen jegyzetben tették közzé (2005-ben az RFC 4120 vette át a helyét).

24

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél A Kerberos Társulatot 2007-ben alapította meg az MIT, melyhez olyan neves nagy cégek csatlakoztak, mint például a Google, Microsoft, Oracle, Apple és számos felsőoktatási intézmény. A társulás célja a Kerberos folyamatos fejlesztésének elősegítése és széles körben történő terjesztése. A Kerberos működési elvét tekintve egy „jegy-alapú” rendszer, amely a felhasználók és a szolgáltatások azonosítását szolgálja (13. ábra). Az autentikációs folyamat egy „megbízható harmadik felet” vesz igénybe az azonosításhoz, azaz egy úgynevezett Kulcs Elosztó Központot (KDC – Key Distribution Center), amely egy Hitelesítési Szerverből (AS – Authentication Server) és egy Jegy Kiadó Szerverből (TGS – Ticket Granting Server) épül fel. A kliens az Autentikációs szerveren keresztül elküldi a felhasználónevét a Kulcs Elosztó Központ felé. A központ kiállít egy Jegy kiadó jegyet (TGT – Ticket Granting Ticket), amely időbélyeggel van ellátva és a felhasználó jelszavával van kódolva. Ezt a kódolt adatot kapja vissza a kliens. Ez a folyamat tipikusan a felhasználó belépésekor megy végbe, és a TGT egy idő után lejár, ugyanakkor a felhasználó folyamatkezelője automatikusan megújítja azt mindaddig, amíg a felhasználó be van jelentkezve.

13. ábra: Kerberos működési elve Amikor a felhasználó kommunikálni szeretne más kiszolgálóval, a kliens elküldi a TGT-t a Jegy Kiadó Szervernek, amely rendszerint ugyanazon a kiszolgálón helyezkedik el, mint a Kulcs Elosztó Központ. Miután a TGS ellenőrizte a jegy érvényességét és a 25

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél felhasználó hozzáférést kaphat a kért szolgáltatáshoz, a Jegy Kiadó Szerver kiállít egy TGS kulcsot és egy munkamenet kulcsot, melyet visszaküld a kliens részére. Aki ezt követően a TGS kulcsot továbbítja a Szolgáltatás Szerverhez (SS – Service Server) a szolgáltatásra irányuló kéréssel együtt.

26


7. A megfelelő autentikációs rendszer kiválasztása Az előző fejezetek kapcsán megállapítható, hogy egy több telephelyen is működő, több különböző szolgáltatást használó cég számára az LDAP protokollon alapuló, nyílt forráskódú megoldások tűnnek hatékonynak. Ezen megoldások közül a jelenleg legelterjedtebb három LDAP implementáció került tesztelésre: 

OpenLDAP



389 Directory Server (389-DS)



FreeIPA

7.1. OpenLDAP ismertetése Kezdetben a teljesen nyílt, közösség által fejlesztett OpenLDAP került kipróbálásra, mivel az fps webügynökség Kft. első fejlesztői szervere egy szintén nyílt, közösség által fejlesztett és karbantartott, független Linux disztribúciót használt, a Gentoo Linuxot. Az OpenLDAP projektet 1998-ban hozták létre azzal a céllal, hogy a University of Michigan referencia LDAP megvalósításából kiindulva egy LDAP szerver implementációt hozzanak létre. A kezdeti koncepció egy önálló LDAP démonból (slapd – Standalone LDAP Daemon) állt, mely egy frontend és egy backend részre volt osztva. A frontend a hálózati kapcsolatokat és protokollt valósítja meg, míg a backend kizárólag az adattárolással foglalkozik. A háttérrendszer moduláris felépítésű, ennek köszönhetően nem csak hagyományos adatbázisokkal tud kapcsolatot létesíteni, hanem más technológiákkal is összekapcsolható. Jelenleg 16 különféle háttérrendszer érhető el és számos külső gyártó kínál saját megoldást. Ezek a rendszerek három különböző kategóriába sorolhatók: 

Adattárolók – tényleges adattárolást hajtanak végre



Proxy

háttérrendszerek

–

átjáróként

szolgálnak

más

adattároló

rendszerekhez 

Dinamikus háttérrendszerek – menet közben állítják elő az adatokat

A fejlesztések során kialakultak az úgynevezett Overlay funkciók, ezek olyan programkódok, amelyek a frontend és a backend rendszer közé épülnek be, így további műveletekkel és funkcionalitással ruházzák fel a szervert. Egyszerre több Overlay is használható, ennek köszönhetően kiterjeszthető a háttérrendszerek funkcionalitása anélkül, hogy az eredeti programkódot módosítani kellene. Az Overlayek meg tudják változtatni a 27

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél frontend és a backend rendszer között zajló kommunikációt. Jelenleg 21 Overlay található az alap OpenLDAP kiadásban, és további 15 a felhasználók által készített szekcióban, ezen kívül rengeteg Overlay vár még elfogadásra. A számos Overlay közül a replikációt megvalósító Overlayt emelném ki, mely a cég számára kritikus szerepet játszott a megvalósítás szempontjából. A replikáció egy olyan folyamat, mely úgy oszt meg információkat két redundáns erőforrás között, hogy az adatok integritását mindvégig biztosítja. A replikáció célja a megbízhatóság növelése, a hibatűrés és az általános elérhetőség biztosítása. A replikációt kiszolgáló bővítmény a syncrepl, mely egy master-slave (mesterszolga) alapú szinkronizációs eljárás, amit az RFC 4533 internetes jegyzet definiál. Ez a bővítmény kettős rendszert használ a változások követésére – egyrészt minden objektum rendelkezik egy változási sorozatszámmal (CSN – Change Sequence Number), másrészt rendelkezik egy optimalizált munkafolyamat naplófájllal, amely különösen akkor hasznos, amikor az objektumok törlését szeretnénk nyomon követni. Működését tekintve, a replikációs kliens (consumer – fogyasztó) egy tartalom szinkronizálási kereső parancsot és az utoljára kapott CSN értékét elküldi a replikációs szervernek (provider – kiszolgáló), majd a kiszolgáló a keresés eredményeként visszaadja az aktuális értékeket (melyek nem változtak), az új, a módosított, vagy a törölt objektumokat, valamint az új CSN értéket. Amennyiben a fogyasztó nem küld CSN értéket, vagy az érték azt jelzi, hogy kiesett a szinkronizációból, válaszként a kiszolgáló új, hozzáadott objektumként elküldi az összes nála lévő objektumot. Ideális esetben a szinkronizálás csak törölt elemeket, és néhány új értéket tartalmaz. A syncrepl modul adatátviteli szempontból optimalizált változata a delta-syncrepl, mely szigorúan csak a megváltozott adatokat küldi el a fogyasztó részére, nem pedig a teljes objektumot. Ez a protokoll egy adatbázisban tartja nyilván az írási folyamatokat, ennek eredményeképpen pontosan meg tud határozni minden egyes módosítást (így csak az attribútumok kerülnek változtatásra). Habár ez az eljárás is a szabvány syncrepl specifikációk alapján történik, azonban a delta-syncrepl által átküldött bejegyzések ténylegesen a napló adatbázisból származnak, ahol minden egyes módosítás egy naplóbejegyzést eredményez.

28

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Az OpenLDAP a 2.4. verzió óta korlátozott mértékben képes a multi-master (több főkiszolgálós) replikáció (14. ábra) megvalósítására. A replikáció technikailag a syncrepl modulon alapszik, azonban ennél a megközelítésnél minden egyes kiszolgáló egyben fogyasztó is.

14. ábra: Multi-master replikáció Ez a megoldás adat-konzisztencia problémákat vet fel, mivel minden egyes kiszolgáló képes önmagában is működni. Amikor a kiszolgálók újra kommunikálni tudnak egymással, akkor mindegyik azt hiszi magáról, hogy az ő adatbázisa tartalmazza a legfrissebb és legaktuálisabb adatokat, így a kiszolgálók nem tudnak egyértelmű CSN értéket küldeni – a hálózaton az összes kiszolgáló a teljes adatbázisát küldi. Ez egyrészt hatalmas hálózati terhelést okoz, másrészt amennyiben ugyanazon az objektumon több kiszolgáló is egymástól függetlenül módosított, akkor sérül a szinkronizáció és adat integritási probléma lép fel, mely kézi beavatkozást igényel. A problémát úgy lehet megoldani, hogy az egész rendszer elé egy LDAP proxy szervert helyezünk, mely meghatározza, hogy melyik szerver végzi az írási folyamatokat – így elkerülhető a fent említett split-brain effektus. Nagy rendelkezésre állású rendszereknél, különböző terheléselosztású mechanizmusok esetén ez egy folyamatosan megoldandó problémát jelent. A cégnél támasztott rendszerkövetelmények szempontjából az OpenLDAP használatával történő infrastruktúra kialakítása master-slave környezetben erőforrás 29

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél takarékos, ellenben ez a megoldás nem támogatja a több telephelyen történő módosítások lehetőségét. Az OpenLDAP egy viszonylag régóta fejlesztett szoftvercsomag, ezáltal a merőben új elgondolások implementálása nehézkes vagy egyáltalán nem kivitelezhető. Üzemeltetés szempontjából nem rendelkezik átfogó, saját adminisztrációs felülettel – csak külső, harmadik fél által szállított szoftvercsomagokkal lehet hozzávetőlegesen felhasználóbarát módon adminisztrálni a szervert.

7.2. 389 Directory Server ismertetése Miután adminisztrációs nehézségekbe ütköztem az OpenLDAP szerver kapcsán, olyan megoldás után néztem, amely egyrészt rendelkezik saját adminisztrációs felülettel, másrészt támogatja a multi-master replikációt. A 389 Directory Server az eredeti Michigan Egyetemi slapd projekt legújabb megvalósítása. 1996-ban a Netscape Communication Corporation felvette a projekt fejlesztőit és ettől kezdve a projekt neve Netscape Directory Server (NDS) lett. Az NDS szellemi tulajdonának többszöri felvásárlását és tulajdonváltását követően a jogokat végül a Red Hat szerezte meg, aki 2005. június 1-én a forráskódok nagy részét szabad szoftverré tette a GPL (GNU General Public License) keretein belül. A 389 Directory Server 1. verzióját 2005. december 1-én adta ki a Red Hat, szabad szoftverként tartalmazva a fennmaradó további forráskódokat és komponenseket (mint például az adminisztrációs szervert, adminisztrációs konzolt, stb.), valamint folytatta annak karbantartását a licencek keretein belül. 2009. májusában a Fedora Directory Server projekt megváltoztatta a nevét 389 Directory Server projektre, hogy disztribúció és forgalmazó függetlenné tegye a nevét, elősegítve ezzel a szoftver portolását vagy más operációs rendszereken való futtatását. Funkcióit és működését tekintve megegyezik az OpenLDAP szoftvercsomaggal, ugyanakkor számos lényeges plusz funkcióval is rendelkezik, mint például multi-master replikációval, saját Java alapú GUI frontenddel adminisztrátorok részére és lehetőség van arra, hogy egyes részfákat csak olvasható módon, külön kezeljünk. Munkahelyemen az új fejlesztői szerver üzembe helyezésével lehetőség nyílt más Linux disztribúciók használatára úgy, mint a Red Hat alapú nyílt forráskódú CentOS Linux operációs rendszer. Az OpenLDAP menedzselési nehézségei és a CentOS Linux meglétének ténye adta a lehetőséget a 389 Directory Server kipróbálására és a felhasználói adatbázis migrálására. Ez a rendszer két éven keresztül hatékonyan működött a két telephely között, és számos szolgáltatás részére biztosította az autentikációs rendszert.

30

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Hatékonyan működött rajta a multi-master replikáció, és adminisztrálási szempontból is nagy előnyt jelentett a külön programként futó adminisztrációs konzol attól függetlenül, hogy egyéb LDAP adminisztrációs szoftverek is remekül tudtak együtt működni a rendszerrel. A korábban használt PAM-alapú autentikációból könnyen lehetett a felhasználói és csoport adatokat az LDAP fába importálni, így a migrálás a felhasználók számára észrevétlenül tudott végbemenni, szükségtelen volt a jelszavuk újbóli megadása.

15. ábra: 389 Directory Server menedzsment felülete A 389 Directory Server (15. ábra) hátránya, hogy egy olyan kizárólag címtárszolgáltatást megvalósító szoftvercsomag, melyhez, ha a weben elterjedt SSO (Single Sign-On) technológiát tervezzük használni, akkor különböző autorizációs szoftvereket – például Kerberos

kell manuálisan a rendszerhez illeszteni. Az SSO

segítségével a felhasználók munkáját lehet könnyebbé tenni az által, hogy csak egy adott szolgáltatáshoz kell autentikálni magukat, az ehhez kapcsolódó szolgáltatások már automatikusan, további felhasználói beavatkozás nélkül azonosítani tudják őket. Mivel a 389 Directory Server szoftvercsomag is viszonylag régi fejlesztés, így a modern technológiák rendszerbe integrálása nehézkes.

7.3. FreeIPA ismertetése Az újabb szoftveres és webes trendek megjelenésével szükségessé vált az eddig használt rendszer bővítése különböző szolgáltatásokkal, melyeket a meglévő 389 Directory

31

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Server rendszerhez már csak nagy erőfeszítések árán tudtunk volna kapcsolni. Erre a problémára jelentett megoldást a FreeIPA (IPA – Identity, Policy and Audit) identitás menedzsment szoftvercsomag. A FreeIPA szintén egy Red Hat által támogatott, nyílt forráskódú projekt, melynek célja a modern technológiák felhasználásával a felhasználói adatok, a szabályok könnyű kezelése és az auditálás (16. ábra). A szoftvercsomag fő alkotóelemei már létező, nyílt forráskódú szoftverek, melyek e programcsomag keretein belül kerültek összehangolásra, kiegészítve egy egységes parancssori és webes adminisztrációs felülettel, amely versenyképessé teszi más zárt forráskódú szoftverekkel – mint például a Microsoft Active Directory.

16. ábra: FreeIPA modulok és kapcsolódásuk A FreeIPA a következő szoftvereket foglalja magában: 

389 Directory Server – LDAP implementációhoz és adatbázishoz



MIT Kerberos 5 – autentikációhoz és SSO-hoz



Apache HTTP Server és Python – menedzselési keretrendszerhez és webes felülethez



Dogtag – integrált tanúsítványkezeléshez



BIND – DNS szerver kiszolgálásához

A szoftvercsomag nagy előnye a cég számára abból adódik, hogy a korábban alkalmazott 389 Directory Servert használja a felhasználói adatok tárolására, és a Kerberos 5-ön keresztül biztosítja az SSO technológiát, mindemellett adminisztrátorként és normál felhasználóként is el lehet érni a saját jogkörnek megfelelő beállításokat az online webes felületen. 32


8. Technikai megvalósítás Az előzőleg ismertetett LDAP implementációk közül választásom a FreeIPA szoftvercsomagra esett, mivel a korábban használt 389 Directory Server által nyújtott funkciók kevésnek bizonyultak. Ebből kifolyólag hatékonyabbnak láttam egy új szoftvercsomag használatát a különböző egyéni szoftverek telepítésével szemben. Mindemellett a FreeIPA tervezett funkciói között számos modern technológia implementálására nyílt lehetőség, mint például a kétfaktoros autentikáció. Szempont volt az is, hogy a fejlesztők nagy részre Microsoft Windows alapú operációs rendszert használ, mely szintén erőteljesen támaszkodik a Kerberos alapú autentikációra – amely megtalálható a FreeIPA szoftvercsomagban. A kiválasztott megoldás telepítése a legjobban CentOS operációs rendszeren támogatott, így én is a legfrissebb, 7. verziójú CentOS disztribúciót választottam erre a célra. Az ehhez kapcsolódó szolgáltatások szintén ezt a disztribúciót használják, mely nagyban megkönnyítette az összehangolás folyamatát.

8.1. Előkészületek A rendszer biztonsága érdekében célszerű belső hálózaton és egy erre a célra dedikált szerveren kialakítani a rendszert. Ennek megfelelően az fps webügynökségnél is egy használaton kívüli szerveren lett kialakítva a rendszer, így a telepítés alatt is zavartalanul folyt a régi rendszeren a munka. A kiválasztott Dell Poweredge 2009 szerver hardver specifikációját tekintve az alábbi tulajdonságokkal rendelkezik: 

Intel Xeon E5420 4 x 2,5 GHz processzor



8 GB DDR2 memória



2 db Seagate 147 GB 15000 rpm SAS merevlemez hardveres Raidben

A fent leírt teljesítményre azért volt szükség, mert a jövőben tervek között szerepel a cég saját fejlesztésű keretrendszerének hozzákapcsolása a FreeIPA rendszerhez. Operációs rendszerként a korábban említett CentOS 7 64 bites minimal verziója került telepítésre az alapértelmezett beállításokkal. A hálózaton belül a kiszolgáló fix IPcímet és egy fix aldomaint kapott. A telepítést követően az alapértelmezésként települő SELinux biztonsági modul kikapcsolásra került, mivel akadályozza a további telepítéseket. Később, a megfelelő betanítást követően a modul visszakapcsolható.

33


8.2. FreeIPA telepítése A programcsomag a használt CentOS 7 disztribúció részét képezi, így azt nem szükséges külső forrásból letölteni. A szoftvercsomagot és függőségeit a következő paranccsal lehet telepíteni: yum –y install ipa-server A paranccsal telepítésre kerülnek a szoftverkomponensek és beállításra kerül a FreeIPA automatikus indítása. A szerver kezdőbeállításait a következő paranccsal lehet konfigurálni: ipa-server-install Ennek hatására a parancssori telepítő a következő komponenseket állítja be: 

Létrehozza a Directory Server LDAP fa gyökerét



Létrehozza és beállítja a Kerberos KDC-t



Beállítja a KDC-hez szükséges Network Time Daemont (hálózati idő kezelő)



Beállítja a Dogtag tanúsítványkezelőt



Beállítja az Apache webszervert az online felülethez



Beállítja a BIND DNS szervert

A telepítő futása során meg kell adni teljes domain nevét, az LDAP fa nevét, illetve az adminisztrátori jelszót. A telepítést követően létre kell hozni az admin felhasználó Kerberos jegyét a következő paranccsal: kinit admin A megfelelő működés érdekében a következő portok megnyitása szükséges a tűzfalon: 

TCP portok o 80, 443: HTTP/HTTPS o 389, 636: LDAP/LDAPS o 88, 464: Kerberos



UDP portok o 88, 464: Kerberos o 123: NTP (Network Time Protocol)

Biztonsági okokból a Directory Server alapértelmezett működésén változattam, mivel a Directory Servert az internetről is el lehet érni, így a kezdő beállított érték – mely szerint az LDAP fát bárki olvashatja –, biztonsági kockázatot rejt. Ezt elkerülendő, a

34

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél szerver hozzáférését úgy változtattam meg, hogy kizárólag az autentikált felhasználók tudják elérni, emellett létrehoztam egy általános, csak olvasási jogosultsággal rendelkező felhasználót, amely a teljes fát tudja olvasni és keresni.

8.3. Replikáció beállítása A több telephelyen történő munkavégzés és a telephelyek közötti korlátozott és instabil hálózati kapcsolat miatt célszerű egy másolatot tárolni és üzemeltetni a FreeIPA szerverről. A FreeIPA multi-master replikációs képességének köszönhetően, földrajzilag is különböző telephelyeken lehet kialakítani magas rendelkezésre állású futtató környezetet. A második FreeIPA szerver is egy CentOS szerveren került kialakításra, így elegendő volt a telepítést elvégezni. Mivel a FreeIPA szerver a saját beállításait is az LDAP fában tárolja, így amint a két szerver szinkronizációja megvalósul, ezzel együtt a beállítások is szinkronizálásra kerülnek. A kezdeti szinkronizálás első lépéseként a már beállított szervert a következő paranccsal lehet replikációs üzemmódba kapcsolni: ipa-replica-prepare „második szerver domain címe” Ezt követően, az előzőleg létrejött titkos kulcsot át kell másolni a második szerverre, ezután el kell rajta indítani a kezdeti szinkronizálást a következő paranccsal: ipa-replica-install „átmásolt titkos kulcs elérési útvonala” A kezdeti szinkronizálás befejeztével már minden adat és beállítás redundánsan elérhető minkét kiszolgálón.

8.4. Linux felhasználó kezelés beállítása A Linux szerverek beépített autentikációs rendszerét, a PAM-ot és a Kerberost használjuk a FreeIPA-hoz történő kapcsolódáshoz. CentOS Linuxon a következő paranccsal lehet telepíteni a szükséges modulokat: yum –y install ipa-client Ezt követően a beállításokat az alábbi paranccsal lehet megejteni: ipa-client-install A folyamat során meg kell adni a kliens teljes domain nevét, valamint a már létező FreeIPA szerver nevét. Ezután automatikusan beállításra kerül a PAM-Kerberos modul az autentikációhoz.

35


8.5. Webszerver integrálása Az fps webügynökségnél fejlesztési célra két webszerver szoftvert használunk, ezek közül az egyik az NginX, mely lehetőséget biztosít arra, hogy domain név alapon különböző egyéb webszerverekhez irányítsuk a forgalmat. A másik szoftver az Apache webszerver, melyből fejlesztési céllal különböző példányok különböző beállítással, másmás PHP verzióval futnak és a korábban említett NginX határozza meg, hogy a forgalom éppen melyik Apache kiszolgálóhoz kerüljön. Ugyanakkor az Apache és az NginX webszerverek az internetről is direkt módon elérhetők, ezért mindkét webszerver szoftverhez szükséges az autentikáció megvalósítása. A cég fő fejlesztői szerverén fut az NginX webszerver, mely Gentoo Linux disztribúciót használ, amelyben az NginX vagy szöveges fájlból vagy pedig a Linux PAM rendszeréből tud autentikálni. A webszervert PAM autentikációra állítva elérhető (17. ábra), hogy az operációs rendszeren keresztül a FreeIPA-ból tudja autentikálni a felhasználókat. Amennyiben az operációs rendszer megfelelően tudja használni a PAM modulokat, abban az esetben speciális beállításra nincs szükség. location /secure { auth_pam "Secure Zone"; auth_pam_service_name "nginx"; }

17. ábra: NginX konfiguráció Az Apache webszerver szoftver autentikáció terén sokkal szélesebb körű megoldásokkal rendelkezik, mint az NginX, így lehetőség nyílik nem csak a rendszerbeli PAM autentikáció használatára, hanem az operációs rendszert kikerülve direkt módon a Kerberos vagy akár az LDAP autentikáció használatára is. Ennek megvalósításához szükséges a mod_auth_kerb és a mod_auth_ldap Apache modulok telepítése. AuthType Kerberos AuthName "Acme Corporation" KrbMethodNegotiate on KrbMethodK5Passwd off Krb5Keytab /etc/apache2/http.keytab

18. ábra: Apache Kerberos konfiguráció

36

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél A Kerberos modul használata során egy Kerberos kulcstároló fájl létrehozása szükséges a webszerver számára, melyben a HTTP szolgáltatásra vonatkozó jegyek kerülnek tárolásra (18. ábra). Mivel a Kerberos egy központi szerver lehet csak, így egy hálózaton belül nem szükséges konkrét kiszolgálót meghatározni a kapcsolódáshoz, hanem automatikusan kerül meghatározásra. LDAP modul használata esetén meg kell adni a szerver címet, ahova kapcsolódni kívánunk, illetve egy keresési feltételt, ami alapján meghatározható, hogy mely felhasználók autentikálhatnak. A cég hálózatán, mivel a FreeIPA szerver Directory Server modulja korlátozva lett, így kapcsolódáskor meg kell adni a csak olvasási joggal rendelkező felhasználó nevét és jelszavát – ellenkező esetben sikertelen lesz az autentikáció a kapcsolódási problémák miatt (19. ábra). Jelenleg ez az autentikációs rendszer van használatban az Apache webszerverek esetében. AuthType Basic AuthName "Stooges Web Site: Login with email address" AuthLDAPEnabled on AuthLDAPURL ldap://ldap.your-domain.com:389/o=stooges?mail AuthLDAPBindDN "cn=StoogeAdmin,o=stooges" AuthLDAPBindPassword secret1 require valid-user

19. ábra: Apache LDAP konfiguráció Mindkét esetben lehetséges az autentikációt konkrét felhasználókra, vagy felhasználói csoportokra korlátozni.

8.6. Projektkezelő rendszer integrálása Az fps webügynökségnél a Redmine nyílt forráskódú projektkezelő rendszer van használatban, mely Ruby On Rails nyelven van írva. A szoftver alapbeállításként a saját SQL alapú adatbázisrendszerében tárolja a felhasználói adatokat. A 2. verzió óta lehetőség van LDAP autentikáció használatára is, ehhez a Ruby nyelv LDAP bővítményére van szükség a futtató szerveren. A Redmine lehetőséget biztosít arra, hogy a felhasználók saját maguk automatikusan regisztráljanak, azonban a mi esetünkben ez egy korlátozott rendszer, így kizárólag az általunk létrehozott felhasználók léphetnek be és láthatják a hozzájuk tartozó projekteket. Habár megmarad a kézi regisztráció, de a felhasználói adatokat (úgy, mint a

37

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél felhasználói nevet, jelszót, teljes nevet) nem kell megadni, mert a Redmine a FreeIPA szerverről automatikusan beszinkronizálja. A projektkezelő rendszer FreeIPA szerverhez történő kapcsolódásához a következő adatokat kell megadni (20. ábra): 

LDAP szerver címét, portját



Felhasználó névét és jelszavát



LDAP fa bejárási útvonalát



Szükség esetén különböző szűrőket

20. ábra: Redmine LDAP konfiguráció Ezt követően, lehetőség nyílik a Redmine-ban és az LDAP-ban tárolt felhasználói tulajdonságok összerendelésére.

8.7. Verziókövető és egyéb webes rendszerek integrálása Általánosságban elmondható, hogy a webes szolgáltatások gyakran támogatják az LDAP protokollon keresztül történő autentikációt és felhasználó kezelést. Az fps webügynökségnél három webes szolgáltatást használunk a csoportmunka hatékony elvégzésére. A fejlesztőink számára a legfontosabb ilyen szolgáltatás a verziókövető rendszer, mely egy Java programnyelven írott webes git implementáció. Ehhez a git verziókövető rendszerhez csatlakoznak szabályos HTTP protokollon keresztül a fejlesztők

38

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél eszközei. A rendszer webes megjelenéséért a GitBlit szoftver felel, mely képes saját adatbázisból, valamint LDAP szerverből kinyerni a felhasználók adatait. A szoftver a korábban ismertetett módon, azaz egy LDAP kiszolgáló cím, a kapcsolódáshoz használt felhasználó név és jelszó, valamint az LDAP fa megadásával tud kapcsolódni a FreeIPA szerveréhez. A dokumentumaink egy részét az ownCloud elnevezésű privát felhő szoftverben tároljuk, mely a felhasználók kezelésére szintén a FreeIPA szervert használja. A szokásos kapcsolódási információk megadását követően, a szoftver letölti a felhasználói és csoport információkat, mely fontos részét képezi a kiterjedt hozzáférés-vezérlési szinteknek. A felhasználó információk szinkronizálása a rendszerben folyamatos, így ha egy felhasználót törlünk a FreeIPA szoftverből, az ownCloudból is automatikusan törlődik. A harmadik, csoportmunkát segítő szoftver az OpenMeetings, mely egy webes konferenciarendszer. Alapjául a Red5 streaming média szerver szolgál, amely Java nyelven íródott. Az OpenMeetings szintén rendelkezik LDAP, illetve Active Directory kapcsolódási lehetőséggel. A korábban említett szoftverekkel ellentétben, az OpenMeetings felhasználói az első sikeres belépéskor kerülnek létrehozásra. A szoftver FreeIPA kiszolgálóhoz történő kapcsolódása és beállítása megegyezik a fentebb említett szoftvereknél leírtakkal.

8.8. WiFi és VPN integrálása Az fps webügynökségnél használt WiFi és VPN megoldások ugyanazt a szolgáltatást használják az autentikációhoz. A cég fejlesztéseinek kisebb része Microsoft alapú platformra történik, illetve a számlázó szoftverünk is igényel Windowsos környezetet, ezért kialakításra került egy Windows 2008 Server. Mivel fejlesztőink és az alkalmazottak nagy részre szintén a Windows operációs rendszert használ az irodában és otthoni környezetben is, így adta magát a lehetőség, hogy a Windows szervert használjunk VPN kiszolgálóként is – segítségével a kollégák otthonról is el tudják érni az irodai erőforrásokat. A Windows szerver beépített VPN kiszolgálóval rendelkezik, mely kétféle autentikációs rendszerrel tud együttműködni. Az egyik ezek közül az Active Directory tartományt használja autentikációra, míg a másik egy külső RADIUS (Remote Authentication Dial In User Service) szervert használt a felhasználók azonosítására. Napjainkban az emberek rengeteg vezeték nélküli eszközzel – mobiltelefonokkal, laptopokkal, tabletekkel – rendelkeznek, így a kor követelményeinek megfelelően a cégünk

39

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél is kiterjedt vezeték nélküli hálózatot üzemeltet. A felhasználói WiFi igények kiszolgálására a Ubiquiti Networks UniFi megoldásait használjuk. Ez a rendszer több hozzáférési pont használatával, egy darab cella rendszerű, vezeték nélküli hálózatot hoz létre, így lehetőség nyílik nagy területek lefedésére. A vezeték nélküli rendszer támogatja a WPA2 Enterprise hitelesítési módszerét, melynek köszönhetően csatlakozni tud egy RADIUS kiszolgálóhoz. A RADIUS egy olyan hálózati protokoll, amely központosított autentikációt, autorizációt és felhasználó-kezelést valósít meg a hozzá kapcsolódó hálózati szolgáltatások számára. 1991-ben fejlesztették ki egy autentikációs hozzáférési szerverként, ezt követően lett IETF (Internet Engineering Task Force) szabvány. A széleskörű támogatottságának és használatának köszönhetően az internet szolgáltatók és nagyvállalatok előszeretettel használják internetes, belső hálózati vagy vezeték nélküli hálózatok eléréséhez. A RADIUS egy olyan kliens-szerver protokoll, amely az alkalmazási rétegben fut és UDP-t használ adatátvitelre. A protokoll megvalósítására Linuxon a FreeRADIUS, a legnépszerűbb RADIUS szerver szolgál. A szoftver autentikálni és autorizálni is tud egy LDAP kiszolgálóból, ehhez csak telepíteni kell a freeradius-ldap modult. Az LDAP kapcsolódási adatok beállítását követően a program képes az LDAP fa kiszolgálására RADIUS protokollon keresztül, ezáltal lehetőség nyílik WPA2 Enterprise WiFi és VPN kiszolgálók csatlakoztatására. Mindkét esetben a RADIUS szerver címének, portjának és titkos kulcsának megadásával lehet kapcsolódni a FreeRADIUS kiszolgálóhoz.

40


9. Tapasztalatok, eredmények, fejlesztési lehetőségek A központi autentikációs rendszer kiépítését egy több éves fejlesztési folyamat és tesztelési fázis előzte meg. Rendszergazdaként feladataim közé tartozik az új alkalmazottak technikai felvétele és betanítása a cégnél alkalmazott rendszerek használatára, valamint a távozó alkalmazottak hozzáféréseinek megszüntetése. A szervezet és a telephelyek számának növekedésével egyre nagyobb feladatot rótt rám az említett folyamatok menedzselése, így saját magamnak kellett a rendszerrel szemben támasztott igényeket meghatározni és megoldást találni a problémára. A kezdeti egy kiszolgálós PAM autentikációt használó rendszer növekedésének következményeként

jelentkezett

az

igény

valamilyen

központosított

megoldás

használatára, melynek eredményeként elkerülhető a felhasználói adatok inkonzisztens tárolása. Ez a probléma a felhasználói szinten úgy jelentkezett, hogy a kollégák hajlamosak voltak összekeverni a hozzáféréseiket a különböző szolgáltatásokhoz. A központosítás hiánya miatt nem volt lehetőség egységes jelszó-házirend és tiltási rendszer használatára. Kutatásaim eredményeként a központosításra valamilyen LDAP protokollon alapuló implementáció tűnt hatékonynak. Első körben a legtriviálisabbnak tűnő megoldást, az OpenLDAP szerver programot kezdtem el tesztelni, melynek hamar kiderültek a hiányosságai és hátrányai, így a rendszer igazából sosem tudta elhagyni a tesztfázist – éles környezetben önmagában sosem került használatra. Később egyéb LDAP implementációk után kutattam, melynek eredményeképpen került megvalósításra a 389 Directory Server. Ez a rendszer nagyon szimpatikusnak tűnt számomra, mivel magas fokú kompatibilitást nyújtott a hasznát CentOS Linux disztribúciókkal. A szoftver több évig megbízhatóan működött, és adminisztrálása kevés problémát jelentett mindaddig, amíg meg nem jelentek az újabb technológiák iránti ötletek. A hosszas kutatómunka után – melyet azzal töltöttem, hogy hogyan lehet a jelenlegi rendszerhez a különböző újabb technológiákat illeszteni –, egyre inkább kiderült számomra, hogy erre a problémára megoldásként létezik komplett szoftvercsomag, a FreeIPA

programcsalád.

Segítségével

tovább

egyszerűsödött

a

felhasználók

és

szolgáltatások adminisztrálása, illetve az újabb technológiák megvalósítására is lehetőség nyílt. Szerencsére az átállás a régi rendszerről zökkenőmentesen zajlott le, mivel a FreeIPA által használt háttérrendszer megegyezett az előzővel. Az új rendszer segítségével

41

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél egyre több szolgáltatást tudtam az identitás menedzsment szoftverrel integrálni úgy, mint a projektkezelő rendszert, a verziókövető rendszert, WiFi-t és VPN-t, és így tovább. A hálózatban van még néhány elszigetelten működő szolgáltatás, melyek nem kerültek még integrálásra – amelyhez a hálózaton egy Microsoft alapú tartományi rendszer működése szükséges. Ilyen szolgáltatások a különböző szervereken és telephelyeken működő Windowsos fájlmegosztó szerverek, melyeket a Linuxos Samba szerverek szolgálnak ki. Elsődleges cél a több Samba fájlszerver közül egy dedikált tartományvezérlő készítése, mely Kerberos protokollon keresztül tud csatlakozni a FreeIPA szerverhez. További megvalósítást igénylő feladat az fps webügynökség által fejlesztett Feracotta keretrendszer és a nyílt forráskódú Wordpress keretrendszer integrálása a FreeIPA szerverrel. A fejlesztések előnyei szintén az alkalmazottak fluktuációjakor jelentkeznének, mivel jelenleg minden rendszert más-más felhasználó név és jelszó párossal tudnak elérni az alkalmazottak – a fejlesztést követően azonban mindenki a saját felhasználó nevével és jelszavával tudná elérni a keretrendszereket. A FreeIPA szerver 4. verziójának fejlesztése a jövőben lehetővé teszi a kétlépcsős autentikáció használatát, mely nagyban hozzájárulna rendszereink biztonságának növeléséhez, így követve az aktuális biztonsági trendeket.

42


10. Irodalomjegyzék 1. MTA-SZTAKI: Az informatika hálózati infrastruktúra biztonsági kockázatai és kontrolljai, 2004 2. Jeges Ernő, Hornák Zoltán: Biometriával ötvözött digitális aláírás, Híradástechnika, LX. évfolyam 2005/4 szám 3. Bajnok Kristóf: Autentikációs és autorizációs infrastruktúrák, Híradástechnika, LXI. évfolyam 2006/6 szám 4. Paljak Gergely, Szombath István: Felhasználói identitás menedzsment, 2009 5. Federal Financial Institutions Examination Council: Authentication in an Internet Banking Environment, 2008 6. Microsoft által használt termékhitelesítések: http://www.microsoft.com/ en-us/howtotell/Software.aspx 7. Széchenyi Tőkealap-kezelő Zrt. közleménye a vénaszkennerről: http://www.szta.hu/kozlemeny/30/ venaszkenner-magyar-innovacio-a-nemzetkozi-siker-kapujaban 8. Internet Engineering Task Force internetes jegyzék keresője: http://www.ietf.org/rfc.html 9. Microsoft Developer Network dokumentáció: http://msdn.microsoft.com/library/ 10. MIT Kerberos dokumentáció: http://web.mit.edu/kerberos/ 11. OpenLDAP dokumentáció: http://www.openldap.org/ 12. 389 Directory Server dokumentáció: http://directory.fedoraproject.org/ 13. FreeIPA dokumentáció: http://www.freeipa.org/page/Main_Page 14. PAM dokumentáció: http://www.linux-pam.org/Linux-PAM-html/ 15. Apache HTTPD dokumentáció: http://httpd.apache.org/ 16. NginX dokumentáció: http://nginx.org/ 17. Redmine dokumentáció: http://www.redmine.org/ 18. GitBlit dokumentáció: http://gitblit.com/ 19. Identitás menedzsment ISO szabvány: http://standards.iso.org/ittf/ PubliclyAvailableStandards/c057914_ISO_IEC_24760-1_2011.zip 20. X.500 szabvány leírása: http://www.x500standard.com/ 21. FreeRADIUS dokumentáció: http://freeradius.org/ Linkek utoljára ellenőrizve: 2014. október 26.

43


11. Mellékletek 11.1. CD melléklet tartalma Dolgozat mappa tartalma 

Szakdolgozat_Tar_Peter_ANRKRW.docx



Szakdolgozat_Tar_Peter_ANRKRW.pdf



Temakiiras_Tar_Peter_ANRKRW.pdf



Osszefoglalo_Tar_Peter_ANRKRW.docx



Osszefoglalo_Tar_Peter_ANRKRW.pdf



Summary_Tar_Peter_ANRKRW.docx



Summary_Tar_Peter_ANRKRW.pdf

44

Központi autentikációs rendszer kiépítése az fps webügynökség Kft-nél Szakdolgozat

Recommend Documents