Felhasználó kezelés, engedélyezés

1. Intelligens rendszerfelügyelet Felhasználó kezelés, engedélyezés Tóth Dániel Micskei Zoltán

2. Számítógépes rendszerek biztonsága • Fontos ez? • Mindenkinek fontos? • Mikor fontos?

3. Mikor fontos a számítógépes biztonság? • Szoftverfejlesztésben minden szinten foglakozni kell a biztonsággal • „Ha egy rendszert nem terveztek biztonságosra, akkor később lehetetlen azzá tenni” • A rendszer biztonsága a leggyengébb láncszem biztonságával azonos.

4. Miből áll a „biztonság” fogalma • „C.I.A.”: Három kölcsönösen egymásra épülő alapfogalom • Cél: • garantálni, hogy a rendszer mindig az elvárt módon viselkedjen • Ne lehessen illetéktelenül adatokhoz jutni, műveletetvégezni Normális esetben: „jóindulatú” meghibásodások Biztonsági kontextusban: „rosszindulatú” meghibásodás„A valószínűtlen is valószínű” Most speciálisan ezzel foglalkozunk

5. Ki az „illetékes”?

6. Tartalom • Számítógépes biztonság bevezető • Felhasználó kezelés, hitelesítés • Linux alatt • Windows alatt • Központosított címtárak • Engedélyezés • Engedélyezés általános sémái • Szerep alapú hozzáférés-vezérlés • Hozzáférési jogosultság listák • Engedélyezés Linux alatt • Engedélyezés Windows alatt • Biztonsági alrendszer alapok • Központosított hozzáférés-vezérlés, csoportházirendek Ezekről majd a következő két előadáson részletesen

7. Hitelesítés • Mi alapján dönthető el, hogy ki kicsoda? • …amit tud (pl.: jelszó) • …amije van (pl.: kulcs, belépőkártya) • …ami ő (pl.: ujjlenyomat, arckép) • Ezek (akár egy kombinációja) alapján egy (sértetlen) gép el tudja dönteni, hogy ki a személy, aki előtte ül • Mi a helyzet, ha nem sértetlen a gép? • Mi a helyzet a gép-gép közötti szolgáltatásokkal?

8. Hitelesítés • Mindenféle szolgáltatás esetén szükség van rá • Hálózati és egy operációs rendszeren belüliek között is • Technikai és üzleti szolgáltatásokhoz is • Hitelesítési protokollok kellenek • Lényegében csak az „amit tud” séma lehetséges (bizalmasságot igényel – pl. közös titok) • Itt már feltételezhető bonyolult kriptográfiai számítás elvégzése is (embernél fejben nyilván nem)

9. Miből áll egy felhasználói fiók User + ID + Name + Real Name + Personaldata… + SharedSecret (Password, etc.) + PrivateDatastorepath A rendszer számára a felhasználó egy objektum…

10. Miből áll egy felhasználói fiók • Emlékeztetőül operációs rendszerekből • A felhasználói fiókot azonosítja… • Linux, UNIX alapú rendszerek alatt UID • Integer (root 0, felhasználók 1000-…) • /etc/passwd, /etc/shadow, /etc/group tárolja az attribútumokat • Windows alatt SID , pl: • S-1-5-21-2052111302-1677128483-839522115-500 • Nemcsak felhasználónak van SID-je:

11. Felhasználói fiókok Linux alatt • Tárolás fájlokban: • /etc/passwd • /etc/shadow • /etc/group • /etc/gshadow • Létrehozás, módosítás, törlés • useradd, usermod, userdel • groupadd, groupmod, groupdel • passwd

12. Miből áll egy felhasználói fiók Linux alatt User Group Initialgroup + UID + name + password + shell + homedirectory + comment + expirydate + GID + name(+ password) 1 * members * *

13. Futó folyamatok • Hogyan állapíthatjuk meg egy futó folyamatról, hogy ki a tulajdonosa • psaux, pstree, /proc/$PID/status • Folyamat futása közben effektív user és group váltása • setuid, setgid mechanizmus • su, sudo parancsok

14. Tartalom • Számítógépes biztonság bevezető • Felhasználó kezelés, hitelesítés • Linux alatt • Windows alatt • Központosított címtárak • Engedélyezés • Engedélyezés általános sémái • Szerep alapú hozzáférés-vezérlés • Hozzáférési jogosultság listák • Engedélyezés Linux alatt • Engedélyezés Windows alatt • Biztonsági alrendszer alapok • Központosított hozzáférés-vezérlés, csoportházirendek

15. Engedélyezés általános sémái Védett objektumok (protectedobjects) Biztonsági szabályzat (policy) ? Adatok ? ? Erőforrások Szereplő (Actor, Subject) Szereplőt leíróadatszerkezet A rendszerben a szereplőt egy adatszerkezet reprezentálja A jogosultság egy reláció a szereplők és a védett objektumok között

16. Hozzáférés végrehajtása Olvas(Adat1) Jogosultság végrehajtó (enforcementpoint) Adat1 elvégezhető Jogosultsági döntő (decisionpoint)   Adat2  Erőforrás3

17. Jogosultságkezelés alapjai • A rendszer működése során • A szereplők műveleteket kezdeményeznek • A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját • A jogosultsági döntő komponens kiértékeli kontextust és engedélyezi vagy megtiltja a műveletet • A jogosultsági végrehajtó komponens biztosítja, hogy a döntő által hozott döntés érvényre jusson

18. Jogosultságkezelés alapjai • A rendszer karbantartása során • Jogosultságok beállítása, módosítása történik • A jogosultságot leíró adatszerkezet maga is egy védett objektum • Tehát lehetnek olyan jogosultságok, amik saját magukra hatással vannak! • Általában a rendszer folyamatosan üzemel, nincs elkülönített karbantartási idő, a jogosultság módosítások azonnal érvényre jutnak

19. Jogosultságkezelés gyakorlati kihívásai • Sok szereplőt kell kezelni a rendszerben • Különböző rendszerek különbözőképpen azonosítják őket • Sok védett objektumot kell kezelni • Különböző rendszerek ezeket is különbözőképpen azonosíthatják • A lehetséges jogosultsági relációk száma a szereplők és objektumok valamint a rajtuk végezhető művelettípusok számának szorzata • Az ilyet teljes hozzáférési mátrixnak nevezzük • Manuálisan (de még automatizáltan is) kezelhetetlen méretű adathalmaz

20. Jogosultságkezelés gyakorlati kihívásai • További jellegzetes kihívások • A jogosultságok folyamatos, rendszeres karbantartást igényelnek • … a vállalati adatlopások, károkozások jelentős része ottfelejtett felhasználói fiókok és jogosultságok kihasználásával történik • Egyéb, esetleg törvényi követelményeknek kell megfelelni • Ellenőrizhető jogosultsági rendszer: szervezeti tisztségeknek és felelősségeknek megfelelően • Feladatok és felelősségek szétválasztása • Auditálási kötelezettségek: műveletek naplózása

21. Jogosultságkezelés fajtái

22. Felhatalmazás fajtái - kötelezőség • Klasszikus fogalmak (US DoD szabvány) • Kötelező (mandatory) • csak központi jogosultság osztás • felhasználók nem módosíthatják a házirendet • Belátás szerint (discretionary) • megfelelő jogú felhasználó továbboszthatja a jogokat

23. Felhatalmazás fajtái - típus • Integritás védelem • Objektumok címkézése • alacsony, közepes, magas… integritási szint • Ellenőrzés: • alacsonyabb szintű felhasználó nem olvashat/írhat magasabb szintű objektumot • Bell LaPadula (bizalmassági) és Biba (sértetlenségi) modellek • Hozzáférés vezérlési listák • objektum → (szereplő, engedélyek) • engedély: adatok írása, attribútumok olvasása… Feltételek: „No writeup” – nem írhatok magamnál magasabb szintű objektumba„No read down” – nem olvashatok magamnál alacsonyabb szintű objektumból Feltételek: „No readup” – nem olvashatok magamnál magasabb szintű objektumból„No write down” – nem írhatok magamnál alacsonyabb szintű objektumba

24. Hozzáférés vezérlési listák A hozzáférési maszk (accessmask) tartalmazza, hogy pontosan milyen műveletekre vonatkozik az engedély * + OP1() + OP2() + mask Szereplő Engedély (Permission) Védett objektum

25. Hozzáférés vezérlési listák Egy védett objektumhoz engedélyek halmaza rendelhető * * * + mask Szereplő Engedély (Permission) Védett objektum Néha sorrendezést is megkövetel

26. Szerep alapú hozzáférés-vezérlés A szerep fogalom hierarchikus szereplő csoportosítási lehetőséget ad. Role-based Access Control (RBAC) * * * * * + mask Szereplő Szerep (Role) Engedély (Permission) Védett objektum A szükséges engedélyek száma kezelhető szintre csökken

27. Hierarchikus objektumok Ha a védett objektumok között természetszerűen hierarchia van… 1 * * * * * * + mask +inherit Szereplő Szerep (Role) Engedély (Permission) Védett objektum …egy engedély vonatkozhat egész részfára is öröklődéssel(inheritance)

28. Miből áll egy felhasználói fiók User memberOf Group A felhasználó csoporttagság valójában egy RBAC megvalósítási lehetőség + Name(+ Purpose…) (+ SharedSecret)

29. Szoftverfejlesztői percek… • Miket kell megtervezni: • Hogyan kezeljük a szereplőket • Legyen-e hierarchia? (Legyen!) • Mik lesznek a védett objektumaink • nyilván osztályok szintjén tervezzük • Van-e kihasználható hierarchia (pl. tartalmazások mentén) • Mik a védett objektumokon végezhető műveletek • Itt dől el, hogy az AccessMask hogy is nézzen ki: enumeráció, booleanflagek, egyedi alosztályok… • Ezek alapján melyik séma felel meg legjobban

30. Szoftverfejlesztői percek… • Készen vagyunk? Nem… • Mi fogja garantálni az engedélyek betartását? • Aspektus orientált programozási szemléletmód kell • Az engedélyek karbantartását hogyan végezzük? • Mi a helyzet egyéb követeleményekkel? • Pl. bizonyos műveletek loggolása • Szabványos megoldás használata… • XACML – XML alapú platformfüggetlen engedélyezési szabályleíró szabvány • http://www.oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf

31. Jogosultságkezelési architektúra Policy AdministrationPoint (PAP) Hozzáférési szabályok létrehozása, karbantartása Policy InformationPoint (PIP) PolicyDecisionPoint (PDP) PolicyEnforcementPoint (PEP) Attribútum szolgáltatás Hozzáférési kérelmek eldöntése Hozzáférési döntés érvényesítése

32. A következő rész tartalmából… • Számítógépes biztonság bevezető • Felhasználó kezelés, hitelesítés • Linux alatt • Windows alatt • Központosított címtárak • Engedélyezés • Engedélyezés általános sémái • Szerep alapú hozzáférés-vezérlés • Hozzáférési jogosultság listák • Engedélyezés Linux alatt • Engedélyezés Windows alatt • Biztonsági alrendszer alapok • Központosított hozzáférés-vezérlés, csoportházirendek