Jogosultság nyilvántartó rendszer

Iroda

Sziasztok!

 

Ha valaki használ a címben említett valamilyen rendszert, jöhetne javaslat.

Van nálunk egy webes megoldás, ami az AD-vel szinkronizál, de túlnőttünk ezen már egy ideje és a mester aki alkotta már nem dolgozik a cégnél. Dokumentáció hiányában nehézkes a további fejlesztés, elavult és a kecske... egy szóval csereérett is.
Vannak különböző alrendszerek és jó lenne egy helyen látni, hogy a Józsikának mihez van hozzáférése ha pl. költözik, kilép a cégtől.

Pl. hova vannak hozzáférési jogai, milyen egyéb dedikált megosztásokhoz fér hozzá, milyen csoportokban volt még benne, eü rendszerekben hova milyen jogai vannak, egyéb állami rendszerekben, milyen levelezési csoportokban szerepel, hova van delegálva a postafiókja, melyik kamerarendszerekhez van hozzáférése, milyen egyéb szoftverekben milyen típusú hozzáférései vannak.

Minden egyes rendszerben külön-külön lekérdezhetők, listázhatók ezek a dolgok többé-kevésbé (nyilván nem mindenhol annyira részletes), de most már annyi karja van a polipnak, hogy megszámolni is nehéz nemhogy egyesével lekérdezgetni amikor egyszerre 30-an váltják egymást vagy költöznek cégen belül.

A jogosultságok adminisztrálása legtöbb esetben csak az adott célrendszerben lehetséges (pl. egy vmátrix ami az eeszt alá tartozik és valamilyen állami üzemeltetés van mögötte), mert sok esetben nem is mi üzemeltetjük és/vagy nincs rá hatásunk, olyan magas szintű hozzáférés. Nyilván API vagy egyéb más lehetőségek sincsenek jó magyar módra. Tehát az még rendben lenne ha az adminisztrálás külön-külön történik, de jó lenne egy egységes nyilvántartás. Gondoltam rá, hogy csinálunk egy webes megoldást jó kis adatbázissal, de ha már van erre kész megoldás ami *természetesen ingyen van, akkor lehet megnézném mert feltehetően kevesebb időt venne igénybe egy létező rendszerre történő berendezkedés. Komoly dolgokra nem kell gondolni, de azért egy excel tábla ehhez már nagyon kevés lenne :D

  • 932 megtekintés

( uid_17626 | 2023. 01. 06., p – 11:36 )

Szerkesztve: 2023. 01. 06., p – 11:37

~off: Saját magamból kiindulva a legacy code-nak esnék neki.

( zrubi v | 2023. 01. 06., p – 12:13 )

és egy szimpla AD csoporttagság alapú megoldás miért nem jó?

Még ha az adott célrendszer ezt nem is tudja használni, nyilvántartásnak tökéletes.

(Ezen felül csak egy megfelelő 'jogosultság kiadó' process kell, hogy szinkronban maradjon a vaósággal)

zrubi.hu

Ja, de ha jól értem, itt arról van szó, hogy kb le akarják írni, hogy józsinak valami random lófaszban valaki csinált egy usert a kicsi kezével, mert természetesen nem lehet hozzákötni az ADhez.

Nyilván, lehet mindenféle ilyet kb "kamu" csoportokkal reprezentálni az ADban, amiket igazából nem használ semmi, csak aki adminol, de valahol értem, hogy miért alakul ki elsőre az érzés, hogy ez szemetelés.

Hogy mennyire kényelmetlen az ilyesmi benne, azt a jó ég tudja, hálisten nem adminolok ADket, de egyrészt gondolom nem annyira lehet para, hiszen ja, tényleg erre is való, másrészt meg azért azt tudjuk, hogy egész szép piaca van azoknak az eszközöknek, amik valami workflowk végigbaszkurálása utan végülis AD csoportokat managelnek :) szóval gondolom bizonyos komplexitás felett már megéri ez.

IAM vagy már inkább IGA irányba kellene nézelődni. Rengeteg termék van a piacon.

Az AD/AAD nem erre való - még ha sokan ezt is próbálják erőltetni -incl. MS.

A pontos igények ismeretében lehet meghatározni hogy milyen szintű integráció kell a végrendszerek felé. Csak egy központi nyilvántartás a megfelelő workflow-k mentén kiosztott jogokról vagy auto provisioning (hozza létre, módosítsa, vonja vissza,...) is.

Ha csak nyilvántartás akkor is időnként a szinkront ellenőrizned kell. És a kulcs dolog ehhez az egészhez az auditálhatóság - főleg ha a rendszer létre is hozza a jogot - adat/resource ownerek felkonfigurálása, jóváhagyók (akár több szintű) és a végrehajtó(adminok) beállítása ill ezen szerepkörök minél jobban való szeparálása.

SegregationOfDuties (SoD kezelés - milyen olyan jog/jogok vannak amit nem lehet egy embernek egyidőben kiadni (vagy csak spec jóváhagyással),...

 

Ahol félre szokott menni, hogy ez az egész jogosultságkezelés a kialakított workflow-ról szól, nem a nyilvántartó rétegről. Ha jó, attól jó, ha rossz, amiatt rossz. "Papíron" is működnie kell - a technológia/automatizálás csak segíti egyes csoportok munkáját ebben. Alapvetően drága mulatság és emiatt a business case eladásakor észnél kell lenni, hogy olyanra húzd fel, amire az üzlet is rezonál. Az hogy az admin kézzel hoz létre egy accot - arra elsődlegesen nem fognak pénzt dobni - azért kapja a fizetését + nem feltétlenül kell mindent automatizálni (kevés user, ritkán változik, nem nagy kockázatú adatok vannak,...) Meg kell találni az egyensúlyt.

 

Szerintem...

( bazso | 2023. 01. 06., p – 12:16 )

KeyCloak?

Egy rakás protokollt beszél, webes felülete van, ami képes rá, oda akár SSO-t is ad, de amit nem tudsz hozzá kötni, annak az adminisztrációja is elfér benne. Ja és ha véletlen valami csak egyedi kommunikációval interfészelhető, mivel minden plugin, írsz saját illesztőt. 

Ha nem tetszik, ott az OpenIAM, hasonló.

Sok munka egy ilyen motort jól megírni és biztonsági elvárásokat folyamatosan tartva karbantartani, ha nem ez a cég elsődleges biznisze, tuti nem saját erőforrást égetnék rá. 

Fordítsuk meg: Ha van n darab szolgáltatásom, ami LDAP-ot tud, abból az n darabból hány olyan lesz, ami tud mondjuk oAuth-ot? És ugye ami LDAP-ot tud (normálisan), az az AD-vel is meg tud barátkozni elég könnyen. (jelen esetben egy rakat nem oAuth-os motyó is képbe kerül, ahogy látom, azok mögé meg max. nyilvántartást tud rakni - jobb esetben scriptelve/leprogramozva a nyilvántartott jogosultságok változásának az automatizált átvezetését is...)

Egyébként általános, egy mondatos válasz nincs a poszt-toló kérdésére: van, ahol AD+LDAP(+Kerberos), van, ahol mondjuk KC, aminek a backend-et az AD-adja, van, ahol az AD mellé célszerű mondjuk egy IPA-t odarakni, vagy épp valami ágyú-veréb IAM-ot, ami a teljes workflow-t (igénylés-jóváhagyás-beállítás...) és valamennyi releváns funkciót (felülvizsgálat (DB és a rendszerekben beállított jogok összevetése is(!)), helyettesítés, felfüggesztés, kiléptetés, stb.) megvalósít.

 

Például az AD? (natív AD, LDAP, Kerberos...) A kc-val nekem több bajom is van. Egyrészt ha scriptelni akarod (lehet), akkor nem láttam még azt, hogy hogyan lehet a meglévő jogokat _elvenni_? Ami van tool, az felnyal egy yaml-t, és bután addicionálisan betolja azt, ami még nincs, de olyat nem láttam benne, hogy na ha ez van, akkor azt törölni kell. (ha tudsz ilyen eszközt, ami yaml-t vagy más, jogosultságokat leíró konfigot "eszik", akkor  kérek hozzá linket, mert van, ahol nagyon hasznos lenne).
Jelen környezetben _nem_ az oAuth/AD/LDAP/Kerberos/stb a kérdés, hanem az, hogy hogyan lehet nyilvántartani az n+1 féle rendszerben felvett jogosultságokat, miközben az adott rendszer/szolgáltatás jogosultsági rendszere/környezete nem módosítható - maximum felvinni/módosítani/lekérdezni lehet valamilyen felületen.
Az persze jó lenne, ha minél több rendszer ebből a nyilvántartó rendszerből tudna közvetlenül autentikálni és jogosultságokat hozzárendelni az userhez - épp ez az, ami miatt a környezet, az érintett alkalmazások/szolgáltatások ismerete nélkül nem igazán lehet értelmes választ adni a kérdezőnek.

 

Az openai chatbot szerint: "If you are using a script to automate the removal of permissions in Keycloak, you will need to use the Keycloak API and make HTTP requests to the appropriate endpoints. You can use a library such as requests in Python or curl in the command line to make these requests."

Nem megoldani akarom, csak kíváncsi voltam, hogy mit tud :)

Például az AD?

Az mindennel is integrálható ootb? Kevéssé hiszem. Azt még kevéssé hiszem, hogy könnyedén lehet hozzá plugin-rendszerben bármit is illeszteni.

A kc-val nekem több bajom is van.

Azt látom. Ennek szerintem egyik oka az, hogy nem olvasol dokumentációt...

Egyrészt ha scriptelni akarod (lehet), akkor nem láttam még azt, hogy hogyan lehet a meglévő jogokat _elvenni_? Ami van tool, az felnyal egy yaml-t, és bután addicionálisan betolja azt, ami még nincs, de olyat nem láttam benne, hogy na ha ez van, akkor azt törölni kell. (ha tudsz ilyen eszközt, ami yaml-t vagy más, jogosultságokat leíró konfigot "eszik", akkor  kérek hozzá linket, mert van, ahol nagyon hasznos lenne).

És még adjak ingyen tanácsot... :D

Jelen környezetben _nem_ az oAuth/AD/LDAP/Kerberos/stb a kérdés, hanem az, hogy hogyan lehet nyilvántartani az n+1 féle rendszerben felvett jogosultságokat, miközben az adott rendszer/szolgáltatás jogosultsági rendszere/környezete nem módosítható - maximum felvinni/módosítani/lekérdezni lehet valamilyen felületen.

Az én kérdésem az volt, hogy mi az, ami több integrációs lehetőséget tartalmaz ootb, mint a KeyCloak? Erre még nem kaptam választ. Arra igen, hogy több bajod is van vele.

https://iotguru.cloud

Értő olvasás... Amikhez szerencsém volt, azok szinte mind tudtak/tudnak legalább "mezítlábas" LDAP-ot -> azaz AD-vel next-next-finish mennek, de van, ami natívan beszélget az AD-vel, vagy épp az alapján ad jogosultságokat, hogy az adott vastagklienst futttaó AD-s user milyen csoportoknak a tagja.

Épp a fentiek miatt írtam, hogy a poszt alapján nagyon nem lehet határozottan kijelenteni, hogy a kérdezőnek mi lenne a megfelelő megoldás, maximum azt, hogy neki milyen komponensek/funkciók megvalósítása lehet célszerű.
Na ebből a funkcióhalmazból van, amit az AD is tud, van, amit a kc is tud (userek/csoportok az AD-ban/ból jönnek), és van, amikhez további elemek szükségesek.
_Nyilvántartásra_ önmagában egyik sem jó, illetve nem elég szerintem - nem véletlen, hogy IDM/IAM bevezetése során az eszköz(ök)/szoftver(ek) kiválasztása a sokadik lépésben történik, nem pedig gombhoz a kabátot alapon. legalábbis ott, ahol értelmesen gondolkodó emberek vannak.

Értő olvasás... Amikhez szerencsém volt, azok szinte mind tudtak/tudnak legalább "mezítlábas" LDAP-ot

Jajj, baszki, de nehéz kihúzni belőled valami értelmeset. LDAP-ot tud a KeyCloak is ootb, szóval akkor mindent is lehet hozzá integrálni, semmi értelme nincs annak a sóhajnak, hogy "A KC nagyon szép, csak mire mindent _is_ integrálsz hozzá..."

Szóval? Mit kellene ebből értő olvasással kiolvasni, ami nem az, hogy a KeyCloak-hoz nehéz mindent is integrálni? Aztán jössz azzal, hogy a mindent is az nálad csak LDAP.

https://iotguru.cloud

Hmmmm.. Tehát szerinted a kc szervert meg lehet szólítani, mint LDAP-szerver? mert én azt látom, hogy LDAP-ból tudja szedni az usereket/csoportokat/miegyebet, de LDAP-szerverként nem tud viselkedni.
A "mindent is" nálam nem az LDAP, hanem az egy olyan lehetőség, amit nagyon sok dolog tud, ismer oob működik és működött már vele, mielőtt még a kc-ból érdemi verzió létezett volna...

Tehát szerinted a kc szervert meg lehet szólítani, mint LDAP-szerver?

Nem, de képes LDAP szervert módosítani, szinkronban tartani egyéb dolgokkal, satöbbi. Tudod, integráció, centralizált menedzsment, miért kellene bele LDAP szerver, amikor LDAP szerver van több is?

A "mindent is" nálam nem az LDAP, hanem az egy olyan lehetőség, amit nagyon sok dolog tud, ismer oob működik és működött már vele, mielőtt még a kc-ból érdemi verzió létezett volna...

A Keycloak egy integrátor eszköz, sok dolgot tud, főleg összekötni egyéb dolgokat és azokra ernyőként borulva federált és integrált szolgáltatást adni. Nem az a dolga, hogy LDAP szerver legyen, ha ezt gondolod, akkor tévúton jársz. Ezért kérdezem, hogy mi az, ami több integrációt tud ootb, mert a Keycloak alapvető célja az, hogy összeintegráljon dolgokat.

https://iotguru.cloud

Tehát ha van egy AD-m, egy rakat AD/LDAP auth-ot tudó, meg néhány egyedi userkezeléssel megvert cuccom, milyen pluszt tud adni a kc?

Összefogja az egészet, egy felületen lehet kezelni mindent, jogokat, szerepeket, objektumokat, egyebeket és ezt szinkronban tartja a különböző rendszerekkel (plugin írással az egyedi user kezelést is például) és ad SAML és OAuth protokollt minderre, ha szükséges vagy van rá igény.

Mivel lesz jobb, ha egy újonnan tervezett/fejlesztendő  alkalmazás oAuth/kc felé megy, mintha a meglévő AD/LDAP irányt használná direktben?

Ha ez a kérdés így felmerül, akkor nem lesz jobb, elég oda az AD/LDAP és minden azzal járó szopás meg előny. Felesleges behozni egyéb rendszert, annak szopásaival és előnyeivel.

https://iotguru.cloud

Fordítsuk meg: Ha van n darab szolgáltatásom, ami LDAP-ot tud, abból az n darabból hány olyan lesz, ami tud mondjuk oAuth-ot?

Ez egy elég hülye összehasonlítás, de mondok neked egy olcsó megoldást - a keycloak rá tud ülni az LDAP tetejére, és onnan beolvasni dolgokat, sőt, módosítani is. 

Így ami LDAPot beszél, mehet az ADhez közvetlen, ami oauthot, az mehet a keycloakon át. Pl nálunk a céges gitlab a céges LDAPba kaoott egy readonly usert, más céges toolok meg a keycloakba vannak bekötve. Én meg ugyanazzal a username/passal autholok mindenhova, és az LDAP csoportokban állítják a jogaimat. 

(az egyetlen edge case, hogy a keycloakba be van kötve a céges GApps fiókom is, így ami toolunk oauthon authol, ott nem adom meg a jelszavam általában, csak a sign in with Google megy. Ahogy néztem a kc forrást, ilyenkor az identity provider idt nem syncelni le az LDAPba, de minden mást (pl ha átírom a nevem, teleofnszamomat a kc felületén), azt minimális költözéssel beletol a megfelelő LDAP attribútumba) 

Aham. Eddig a kc-t csak AD->KC irányú adatátadással láttam használni, "visszafelé" nem mentek módosítások, és nem is volt rá igény - lehet, hogy innen az információhiányom - minden esetre ha megint szembejön, akkor lehet, hogy mélyebben bele fogom ásni magam ebbe a csodába...

Doksit nem keresek most hirelen, meg KC admin felületet sem tudok mutatni, de itt a forrás, hogy van READONLY, meg WRITEABLE syncmode: https://github.com/keycloak/keycloak/blob/main/federation/ldap/src/main…

Egy elég katyvasz a forrás - múltkor kellett ez alapján PoC jelleggel egy saját KC backend implementációt írni -, de AFAIK működik. De személyesen én eddig csak READONLY módban configtam keycloakot, a writeable módon összerakott céges configot nem én csináltam, meg nem látok rá.

( peterszky | 2023. 01. 06., p – 14:31 )

Ha kész termék felé is nézelődnél, én ezzel a kettővel találkoztam eddig:

Nemzetközi - Aveksa

Hazai - SAM (Informa a fejlesztő, asszem)

( n.balazs v | 2023. 01. 06., p – 22:40 )

A leírásod alapján valamilyen identity (access) management (IDM, IAM) rendszerre lenne szükséged.

Néhány kérdés, amit szerintem meg kellene fontolnod és/vagy rákérdezni business oldalon:
- Mennyire auditálják a céget? Ez mennyire mély és rendszeres?
- Mekkora a cégméret, ahol ezt használni akarjátok? Mennyi pénz van ilyenre?
- Ki és hogyan fogja integrálni az IDM-t a különféle rendszerekhez (Windows, AD, Linux, middleware stb.)? Van-e erre erőforrás?
- Milyen workflow-t akartok ráhúzni a hozzáférés kérés / törlés / felülvizsgálati folyamatra? Pl: 2 manager jóváhagyása is kell, a felülvizsgálat évente 1-szer történik stb.
- Hány rendszert kell hozzá drótozni az IDM-hez? 5, 10, 20 vagy 50+? Ki fogja ezt menedzselni, lesz-e rá erőforrásotok? Pl: valamelyik ilyen rendszert frissítik új verzióra, akkor esélyes, hogy hozzá kell nyúlni az IDM integrációhoz is.
- Mennyire cél, hogy minden jogosultság beállítás ezen az IDM-n keresztül történjen (magyarul megkerülhetetlen legyen)? Ha igen, akkor alaposan át kellhet szervezni a mostani IT folyamatokat, jogosultságokat. Ez pedig idő és pénz is.
- Van-e cloud a rendszerben? Ha igen, akkor azt is be akarjátok-e vonni az IDM alá? Nem biztos, hogy praktikus első körben...

Enterprise gyártók termékeihez volt ezen a téren szerencsém: Cyberark és IBM. Egyik sem olcsó. A műszaki véleményem? Hát izé... Ha működik (90+%), akkor jó. Ha nem megy, akkor valakiknek tutujgatnia kell a rendszert. Akár kézzel.

A Windows AD nem IDM. Persze lehet fejleszteni hozzá saját megoldásokat, körbefaragni csoportokkal, szkriptekkel, de ezt valakinek kő keményen gondoznia kell. Na meg dokumentálnia.