1Budapesti Műszaki és Gazdaságtudományi EgyetemMéréstechnika és Információs Rendszerek Tanszék

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

Tóth DánielMicskei Zoltán

Intelligens rendszerfelügyelet

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?

tervezés

implementáció

üzemeltetés

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

Sértetlenség(Integrity)

Rendelkezésre állás(Availability)

Bizalmasság(Confidentiality)

Miből áll a „biztonság” fogalma „C.I.A.”: Három kölcsönösen

egymásra épülő alapfogalom Cél:

o garantálni, hogy a rendszer mindig az elvárt módon viselkedjen

o 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”?

Hitelesítés(Autentikáció)• Ki vagyok?• Az vagyok-e

akinek mondom magam?

Engedélyezés(Autorizáció)• Mihez férhetek

hozzá?• Mit csinálhatok

vele?

6

Tartalom Számítógépes biztonság bevezető Felhasználó kezelés, hitelesítés

o Linux alatto Windows alatto Központosított címtárak

Engedélyezéso 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

o Engedélyezés Linux alatto 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?

o…amit tud (pl.: jelszó)o…amije van (pl.: kulcs, belépőkártya)o…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 üloMi a helyzet, ha nem sértetlen a gép?oMi 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á

o Hálózati és egy operációs rendszeren belüliek között iso Technikai és üzleti szolgáltatásokhoz is

Hitelesítési protokollok kelleneko Lényegében csak az „amit tud” séma lehetséges

(bizalmasságot igényel – pl. közös titok)o 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+ Personal data…+ Shared Secret (Password, etc.)+ Private Datastore path

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…

o Linux, UNIX alapú rendszerek alatt UID• Integer (root 0, felhasználók 1000-…)• /etc/passwd, /etc/shadow, /etc/group tárolja az

attribútumokatoWindows alatt SID , pl:

• S-1-5-21-2052111302-1677128483-839522115-500

• Nemcsak felhasználónak van SID-je:

11

DEMO

Tárolás fájlokban:o /etc/passwdo /etc/shadowo /etc/groupo /etc/gshadow

Létrehozás, módosítás, törléso useradd, usermod, userdelo groupadd, groupmod, groupdelo passwd

Felhasználói fiókok Linux alatt

12

Miből áll egy felhasználói fiók Linux alatt

User Group

+ GID+ name(+ password)

Initial group

+ UID+ name+ password+ shell+ home directory+ comment+ expiry date

members

1

* *

*

13

DEMO

Hogyan állapíthatjuk meg egy futó folyamatról, hogy ki a tulajdonosao ps aux, pstree, /proc/$PID/status

Folyamat futása közben effektív user és group váltásao setuid, setgid mechanizmuso su, sudo parancsok

Futó folyamatok

17

Tartalom Számítógépes biztonság bevezető Felhasználó kezelés, hitelesítés

o Linux alatto Windows alatto Központosított címtárak

Engedélyezéso 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

o Engedélyezés Linux alatto Engedélyezés Windows alatt

• Biztonsági alrendszer alapok• Központosított hozzáférés-vezérlés, csoportházirendek

18

Engedélyezés általános sémái

Szereplő(Actor, Subject)

Szereplőt leíróadatszerkezet

Adatok

Erőforrások

???

Biztonságiszabályzat(policy)

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

Védett objektumok(protected objects)

19

Hozzáférés végrehajtása

Adat1

Olvas(Adat1)

Adat2

Jogosultság végrehajtó

(enforcement point)

elvégezhető

Jogosultsági döntő (decision

point)

Erőforrás3

20

Jogosultságkezelés alapjai A rendszer működése során

o A szereplők műveleteket kezdeményezneko A műveletek kontextusa tartalmazza a szereplő

azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját

o A jogosultsági döntő komponens kiértékeli kontextust és engedélyezi vagy megtiltja a műveletet

o A jogosultsági végrehajtó komponens biztosítja, hogy a döntő által hozott döntés érvényre jusson

21

Jogosultságkezelés alapjai A rendszer karbantartása során

o Jogosultságok beállítása, módosítása történiko 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!o Á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

22

Jogosultságkezelés gyakorlati kihívásai Sok szereplőt kell kezelni a rendszerben

o Különböző rendszerek különbözőképpen azonosítják őket Sok védett objektumot kell kezelni

o 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 szorzatao Az ilyet teljes hozzáférési mátrixnak nevezzükoManuálisan (de még automatizáltan is) kezelhetetlen

méretű adathalmaz

23

Jogosultságkezelés gyakorlati kihívásai További jellegzetes kihívások

o 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

o 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

24

Felhatalmazás csoportosítása

Kötelezőség

Kötelező(Mandatory)

Belátás szerint (Discretionary)

Szint

Rendszer szintű

Erőforrás szintű

Típus

Integritási szintek

Hozzáférési listák

Jogosultságkezelés fajtái

25

Felhatalmazás fajtái - kötelezőség

Klasszikus fogalmak (US DoD szabvány)

Kötelező (mandatory)o csak központi jogosultság osztáso felhasználók nem módosíthatják a házirendet

Belátás szerint (discretionary)omegfelelő jogú felhasználó továbboszthatja a jogokat

26

Felhatalmazás fajtái - típus

Integritás védelemo Objektumok címkézése

• alacsony, közepes, magas… integritási szinto Ellenőrzés:

• alacsonyabb szintű felhasználó nem olvashat/írhat magasabb szintű objektumot

o Bell LaPadula (bizalmassági) és Biba (sértetlenségi) modellek

Hozzáférés vezérlési listáko objektum → (szereplő, engedélyek)

• engedély: adatok írása, attribútumok olvasása…

Feltételek:„No read up” – nem olvashatok magamnál

magasabb szintű objektumból„No write down” – nem írhatok magamnál

alacsonyabb szintű objektumba

Feltételek:„No write up” – nem írhatok magamnál

magasabb szintű objektumba„No read down” – nem olvashatok

magamnál alacsonyabb szintű objektumból

27

Hozzáférés vezérlési listák

+ mask*

Szereplő Védett objektumEngedély(Permission)

A hozzáférési maszk (access mask)

tartalmazza, hogy pontosan milyen

műveletekre vonatkozik az

engedély

+ OP1()+ OP2()

28

Hozzáférés vezérlési listák

+ mask* *

Szereplő Védett objektumEngedély(Permission)

Egy védett objektumhoz engedélyek

halmaza rendelhető

*

Néha sorrendezést is megkövetel

29

Role-based Access Control (RBAC)

Szerep alapú hozzáférés-vezérlés

Szereplő Védett objektumSzerep(Role)

+ mask

Engedély(Permission)

*

*

***

A szerep fogalom hierarchikus

szereplő csoportosítási

lehetőséget ad.

A szükséges engedélyek száma kezelhető szintre

csökken

30

Hierarchikus objektumok

Szereplő Védett objektumSzerep(Role)

+ mask+inherit

Engedély(Permission)

*

*

***

*1

Ha a védett objektumok között természetszerűen hierarchia van…

…egy engedély vonatkozhat

egész részfára is öröklődéssel(inheritance)

31

Miből áll egy felhasználói fiók

User

Group

+ Name(+ Purpose…)(+ Shared Secret)

memberOf

A felhasználó csoporttagság valójában egy RBAC megvalósítási

lehetőség

32

Szoftverfejlesztői percek… Miket kell megtervezni:

o Hogyan kezeljük a szereplőket• Legyen-e hierarchia? (Legyen!)

oMik lesznek a védett objektumaink • nyilván osztályok szintjén tervezzük• Van-e kihasználható hierarchia (pl. tartalmazások mentén)

oMik a védett objektumokon végezhető műveletek• Itt dől el, hogy az AccessMask hogy is nézzen ki: enumeráció,

boolean flagek, egyedi alosztályok…o Ezek alapján melyik séma felel meg legjobban

33

Szoftverfejlesztői percek… Készen vagyunk? Nem…

oMi fogja garantálni az engedélyek betartását?• Aspektus orientált programozási szemléletmód kell

o Az engedélyek karbantartását hogyan végezzük?oMi a helyzet egyéb követeleményekkel?

• Pl. bizonyos műveletek loggolása

Szabványos megoldás használata…o XACML – XML alapú platformfüggetlen engedélyezési

szabályleíró szabványo http://www.oasis-open.org/committees/download.php

/2406/oasis-xacml-1.0.pdf

34

Jogosultságkezelési architektúraPolicy

Administration Point(PAP)

Policy Decision

Point(PDP)

PolicyEnforcement

Point(PEP)

Policy Information Point(PIP)

Hozzáférési szabályoklétrehozása,

karbantartása

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

35

A következő rész tartalmából… Számítógépes biztonság bevezető Felhasználó kezelés, hitelesítés

o Linux alatto Windows alatto Központosított címtárak

Engedélyezéso 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

o Engedélyezés Linux alatto Engedélyezés Windows alatt

• Biztonsági alrendszer alapok• Központosított hozzáférés-vezérlés, csoportházirendek