Miért üzletkritikus a PAM?
A privilegizált identitás képes biztonsági kontrollokat megkerülni, konfigurációt módosítani, adatot kinyerni, szolgáltatást leállítani vagy további jogosultságot létrehozni. Emiatt egy rendszergazdai, root, szolgáltatás-, alkalmazás- vagy felhőbeli kulcs kompromittálódása ritkán marad egyetlen rendszer problémája.
A PAM csökkenti az állandó jogosultságot és a megosztott jelszavakat; a hitelesítő adatot elkülönített trezorban tartja; szabályhoz, jóváhagyáshoz és időablakhoz köti a használatot; majd naplózza, közvetíti és szükség esetén rögzíti a munkamenetet. Nem helyettesíti az IAM-et: az IAM azt kezeli, hogy ki a felhasználó és általában mihez férhet hozzá, a PAM pedig azt, hogyan és milyen kontrollok mellett használhat emelt jogosultságot.
Fenyegetési modell
Hitelesítőadat-lopás
Adathalászat, infostealer, memóriadump, böngészőbe mentett jelszó, forráskódba írt token, rosszul védett kulcsfájl vagy naplóba került secret.
Jogosultság-kiterjesztés
Helyi adminjog, hibás sudo-szabály, túl széles cloud role, örökölt csoporttagság vagy alkalmazásból elérhető szolgáltatásfiók.
Oldalirányú mozgás
Újrahasznált helyi adminjelszó, pass-the-hash, SSH-kulcs terjedése, tartományi fiók vagy felhős access key több rendszerben.
Belső és beszállítói visszaélés
Indokolatlan adatlekérés, változtatás jóváhagyás nélkül, megosztott fiók miatti letagadhatóság, távoli hozzáférés kontrollálatlan időablakban.
A védelmi modellnek az emberi és gépi identitásokat együtt kell kezelnie. A támadó célja gyakran nem maga a vault, hanem egy tartósan aktív token, szolgáltatásfiók, automatizációs kulcs, böngésző-munkamenet vagy túl széles végponti alkalmazásjog.
Működés és referencia-architektúra
Egy tipikus megoldás kliens/UI és API rétegből, központi alkalmazás- és policy rétegből, titkosított adattárból, célközeli engine/proxy komponensekből, valamint audit- és integrációs csatornákból áll. A célrendszerekhez közel telepített végrehajtó komponens végzi a felderítést, heartbeatet, távoli jelszócserét vagy session proxyzást, miközben a központi policy marad az irányítási pont.
A szétválasztás biztonsági zónák és telephelyek között csökkenti a szükséges bejövő kapcsolatokat. A vault, a session-recording tárhely, a SIEM és a célhálózat adatfolyamait külön kell méretezni; a jelszórotáció és a felderítés terhelése nem azonos a nagy sávszélességű RDP-forgaloméval.
Credential és secrets vaulting, rotáció
A vault titkosítva tárolja a jelszavakat, SSH-kulcsokat, API-kulcsokat, tanúsítványokat és egyéb érzékeny mezőket. A hozzáférést szerepkör, mappa, secret-sablon, tulajdonos, célrendszer és kockázati feltétel alapján korlátozza. A megtekintés, másolás, indítás, szerkesztés és adminisztráció külön jogosultság legyen.
Rotáció és függőségek
A rendszer heartbeat ellenőrzéssel igazolja, hogy a tárolt credential működik, majd ütemezetten, használat vagy check-in után, illetve incidensre automatikusan új értéket generál és a célon is átvezet. Szolgáltatásfióknál a Windows service, scheduled task, IIS application pool, adatbázis-kapcsolat vagy konfigurációs fájl függőségét is frissíteni kell; enélkül a biztonságos rotáció üzemszünetet okozhat.
SSH esetén nemcsak a private key trezorálása, hanem a kulcspár cseréje, az authorized_keys frissítése, a régi kulcs visszavonása és a host elérhetőségének ellenőrzése is a folyamat része. Vészhelyzeti hozzáféréshez dokumentált break-glass eljárás, erős hitelesítés, kettős kontroll és utólagos kötelező felülvizsgálat szükséges.
Discovery és onboarding
A program nem lehet teljes, ha csak az ismert adminfiókokat védi. A felderítés hálózati tartományokból, Active Directoryból, Windows és Unix/Linux gépekről, virtualizációs és felhős környezetekből azonosítja a privilegizált fiókokat és – ahol támogatott – azok függőségeit. Az eredményeket importszabályok rendelhetik mappához, sablonhoz, tulajdonoshoz és rotációs policyhez.
Az onboarding előtt érdemes tulajdonost, üzleti kritikusságot, fióktípust, függőséget, rotálhatóságot és tesztelési módot rögzíteni. A kezdeti jelszócsere csak a függőségek feltérképezése és az alkalmazástulajdonos jóváhagyása után induljon. Az újonnan talált, még nem kezelt fiók kivétel vagy kockázat legyen, ne egyszerű információs tétel.
Session proxying, recording és monitoring
A credential injection a jelszó felfedése nélkül indít RDP-, SSH-, web- vagy egyedi klienskapcsolatot. Proxyzott modellben a kliens a PAM-komponenshez kapcsolódik, az pedig a vaultból származó vagy rövid életű credentiallel éri el a célt. Ez csökkenti annak esélyét, hogy a tartós secret a felhasználói eszközre kerüljön.
A rögzítés lehet videó, terminál-visszajátszás, billentyűzet- és parancsmetaadat, illetve folyamatszintű esemény. Az élő monitorozás támogatja a megfigyelést és – megfelelő jogosultsággal – a munkamenet megszakítását. A felvétel jogalapját, érintetti tájékoztatását, megőrzési idejét és megtekintési jogosultságát a technikai beállítással együtt kell kialakítani.
Least privilege, JIT, JEA és zero standing privilege
A least privilege a feladat elvégzéséhez szükséges minimumot jelenti. A Just-in-Time (JIT) az engedély időtartamát, a Just-Enough-Administration/Privilege (JEA/JEP) pedig a végrehajtható műveletek körét szűkíti. A zero standing privilege célállapotban nincs tartósan kiosztott emelt jog: azt kontextus, jóváhagyás és lejárat alapján hozzák létre vagy aktiválják.
Jó policy például: az üzemeltető saját vállalati identitásával, MFA után, jóváhagyott változásjegyre hivatkozva két órára kap adott szervercsoporton meghatározott parancsokra emelt jogot. A rendszer a lejáratkor automatikusan visszavonja azt, és a tevékenységet az egyéni identitáshoz köti – akkor is, ha a célon technikailag közös root vagy administrator kontextus fut.
Endpoint privilege management és szervervédelem
A munkaállomásokon a helyi adminjog eltávolítása önmagában nem elég: üzleti alkalmazásoknak továbbra is szükségük lehet emelt műveletre. Az EPM agent alkalmazás-, felhasználó-, fájlútvonal-, hash-, aláíró-, gyermekfolyamat- és kockázati feltételek alapján engedélyezhet, emelhet, blokkolhat, korlátozhat vagy jóváhagyáshoz köthet futtatást. Offline policy és felhasználói indoklás is szükséges lehet.
Szervereken az emelésnek host- és parancsszinten kell működnie Windows, Linux és Unix rendszereken. A központi identitás, az MFA bejelentkezéskor és emeléskor, a sudo/admin szerepek időszakos aktiválása, valamint a host-alapú audit együtt korlátozza az oldalirányú mozgást.
Távoli és beszállítói hozzáférés
A beszállító ne kapjon általános VPN-hozzáférést és megosztott adminjelszót. Célszerű böngészőből indítható, VPN nélküli RDP/SSH kapcsolatot adni kijelölt célokra, előre meghatározott időablakban, MFA-val, jóváhagyással, credential injectionnel és rögzítéssel. A jogosultság a szerződéses feladathoz, tickethez és egyedi identitáshoz kapcsolódjon.
Az állományátvitel, vágólap, port-forwarding, párhuzamos session és továbbkapcsolás külön szabályozandó. Lejárat, inaktivitás vagy incidens esetén a hozzáférést és az aktív sessiont is automatikusan meg kell szüntetni.
Secrets management DevOps- és cloud-környezetben
A CI/CD pipeline, konténer, Kubernetes workload, RPA-bot, serverless funkció és IaC eszköz nem interaktív felhasználó. Titkait nem szabad repositoryban, image-ben, pipeline-változóban vagy hosszú életű konfigurációban tárolni. A workload rövid életű, erősen azonosított csatornán kérje le a secretet API-n, CLI-n, SDK-n vagy natív integráción keresztül.
A dinamikus secret igényléskor keletkezik, minimális cloud- vagy adatbázis-joggal és TTL-lel, majd lejár. Ez kisebb újrahasznosítási ablakot ad, mint a ritkán rotált statikus kulcs. A bootstrap credentialt, cache-t, log-redactiont, rate limitet, kiesési viselkedést és secret-zero problémát ugyanúgy tervezni kell. Cloud esetén a jogosultságok méretezése és a PAM-vault kiegészítik, nem helyettesítik egymást.
MFA, SSO és identitásintegráció
A PAM saját helyi fiókjai helyett vállalati címtár- és IdP-integráció javasolt. SAML vagy OIDC alapú SSO, AD/Entra ID csoportszinkron és RBAC csökkenti az árva hozzáféréseket. Az MFA ne csak a portál belépését védje: magas kockázatú secret megtekintés, checkout, sessionindítás vagy privilege elevation előtt is kérhető.
A feltételes hozzáférés vegye figyelembe az eszköz állapotát, hálózatot, időt, kockázati jelet és célkritikusságot. A szolgáltatásfiókokhoz ne erőltessünk emberi MFA-t; helyette workload identity, tanúsítvány, rövid életű token és szűk policy szükséges. Legalább két, erősen védett és tesztelt vészhelyzeti adminfiók maradjon az IdP-kiesés kezelésére.
Audit, megfelelőség és észlelés
Az auditlánc rögzítse az igénylőt, jóváhagyót, policy-döntést, MFA-t, célrendszert, secretműveletet, session kezdetét és végét, rotációt, adminisztratív változást és exportot. A naplókat időszinkronnal, integritásvédelemmel, elkülönített megőrzéssel és SIEM-továbbítással kell kezelni.
A PAM bizonyítékot adhat többek között NIS2, DORA, ISO 27001, PCI DSS és ágazati kontrollok teljesítéséhez, de önmagában nem jelent megfelelőséget. A kontrollt célhoz kell kötni: például „minden termelési adminhozzáférés egyéni, MFA-védett, jóváhagyott és 365 napig visszakereshető”. A periodikus access review a tényleges használatot, kivételeket és policyváltozásokat is vizsgálja.
HA, DR és telepítési modellek
Elérhető SaaS/cloud, on-premises és hibrid megközelítés. SaaS-nál a szolgáltató üzemelteti a központi réteget, míg a célközeli engine-ek elérik a belső erőforrásokat. On-premises modellnél a szervezet felel a web/app csomópontokért, adatbázisért, üzenetkezelésért, tanúsítványokért, mentésért és frissítésért.
Magas rendelkezésre állásnál több alkalmazáscsomópont, terheléselosztó, HA adatbázis, redundáns üzenetkezelés és telephelyenként legalább két megfelelően méretezett engine szükséges. A session proxy kapacitását külön kell számolni. A DR-terv tartalmazza a vault-adat, titkosítási kulcsok, konfiguráció, audit és felvételek helyreállítását, a DNS/tanúsítvány-függőségeket, RPO/RTO célt és a break-glass utat. A mentés csak akkor kontroll, ha a restore-t rendszeresen tesztelik.
Folyamatok és felelősségek
Napi
Engine- és heartbeat-hibák, sikertelen rotációk, riasztások, lejáró tanúsítványok, rendkívüli checkoutok és aktív sessionök ellenőrzése.
Heti/havi
Discovery-delta, nem kezelt fiókok, kivételek, inaktív privilégiumok, kapacitás, felvételtár és integrációk állapotának vizsgálata.
Negyedéves
Hozzáférés-felülvizsgálat, policy-tuning, break-glass teszt, DR-gyakorlat, tulajdonosok és szolgáltatásfiók-függőségek validálása.
Változáskezelés
Új célrendszer, jelszóchanger, launcher, engine vagy IdP-módosítás először tesztkörnyezetben, dokumentált visszaállási tervvel.
Az irányítás tipikusan megoszlik: az IAM felel az identitásért és csoportokért; a PAM-csapat a platformért és policyért; a rendszer-/alkalmazástulajdonos a hozzáférés indokoltságáért; a SOC a riasztásokért; a compliance az ellenőrzési célokért. A vault-admin ne hagyhassa jóvá saját hozzáférését, és a felvétel megtekintése is külön szerepkör legyen.
A Delinea képességei – pontos termékszerepek
A Delinea nem egyetlen „PAM doboz”. A Delinea Platform közös, cloud-native irányítási és identitásréteget ad, amelyhez különböző, egymást kiegészítő képességek kapcsolódnak. A szükséges komponenseket a védendő identitások, célrendszerek és folyamatok alapján kell kiválasztani.
Secret Server
Vállalati credential vault és klasszikus PAM-központ. Titkokat trezorál, RBAC- és mappapolicyt alkalmaz, fiókokat és függőségeket derít fel, heartbeatet és Remote Password Changinget futtat, checkoutot/jóváhagyást kezel, valamint launchert, RDP/SSH proxyzást, session monitoringot és felvételt biztosít. Cloud és on-premises változatban érhető el.
A célközeli Distributed Engine végzi többek között a discoveryt, heartbeatet, jelszócserét és proxyfeladatokat. Ez nem azonos a Platform Engine-nel: utóbbi platform workloadokat – például on-prem AD-integrációt, Privilege Control for Servers vagy Privileged Remote Access elérést – futtat. Terheléses környezetben a Delinea a discovery elkülönítését javasolja a rotációs és sessionmunkától.
Privilege Manager
Agent-alapú endpoint privilege management és application control Windows- és macOS-munkaállomásokhoz. Felderíti az adminjogot igénylő alkalmazásokat és helyi fiókokat; eltávolítja vagy szabályozza a helyi adminjogot; alkalmazást emel, engedélyez, tilt vagy korlátoz; támogat indoklást, jóváhagyási workflowt, JIT-hozzáférést és helyi jelszórotációt. Elérhető cloud és on-premises modellben.
Privilege Control for Servers / Server PAM
Windows, Linux és Unix szervereken központi, host-alapú policyvel valósít meg JIT/JEA jogosultságot, identitáskonszolidációt, MFA-t bejelentkezéskor és emeléskor, valamint részletes auditot és sessionrögzítést. A Delinea Platformon szállított Privilege Control for Servers, továbbá a Cloud Suite és az on-premises Server Suite eltérő szállítási modellek ugyanazon szerver-PAM problématérben.
Privileged Remote Access
Böngészőalapú, VPN nélküli RDP- és SSH-hozzáférést ad belső célokhoz, helyi kliens telepítése nélkül. A vaultból közvetlenül injektálhat credentialt, időkorlátos least-privilege policyt, központi ellenőrzést és agent nélküli sessionrögzítést alkalmaz. Kifejezetten alkalmas külső adminok és beszállítók célhoz kötött hozzáférésére.
DevOps Secrets Vault
Nagy sebességű, API-központú SaaS vault DevOps-, RPA- és gépi identitásokhoz. Statikus és dinamikus secretet, TTL-alapú ephemeral credentialt, cloud- és adatbázis-dinamikus hozzáférést, OIDC/cloud hitelesítést, CLI/SDK és CI/CD integrációkat, lokális cache-t és tanúsítványkiadást támogat. Nem a humán adminsessionök teljes értékű helyettesítője, hanem a gépi hozzáférésekre optimalizált komponens.
Identity Threat Protection és cloud entitlement kontroll
A Delinea Platform identitásbiztonsági képességei feltárhatják a hibás konfigurációkat, privilegizált hozzáférési útvonalakat és kockázatos viselkedést; a Privilege Control for Cloud Entitlements a felhős jogosultságok méretezését és a tartós privilégium csökkentését célozza. Ezek a vault és a JIT kontrollok kockázatalapú kiterjesztései.
| Igény | Elsődleges Delinea-képesség | Megjegyzés |
|---|---|---|
| Admin- és szolgáltatásfiók vault, rotáció | Secret Server | Discovery, dependency, RPC, launcher/proxy és audit. |
| Munkaállomási adminjog és alkalmazáskontroll | Privilege Manager | Agent-alapú Windows/macOS kontroll. |
| Szerveres JIT/JEA és host-policy | Privilege Control for Servers | Windows/Linux/Unix, MFA és audit. |
| Beszállítói, VPN nélküli távoli elérés | Privileged Remote Access | Böngészős RDP/SSH, időkorlát és recording. |
| CI/CD, workload és dinamikus secret | DevOps Secrets Vault | API/CLI/SDK, TTL, cloud és DB integráció. |
Tipikus use case-ek és bevezetési sorrend
- Domain-, root- és hálózati adminfiókok: trezorálás, egyéni hozzáférés, MFA, rotáció és jelszó nélküli sessionindítás.
- Szolgáltatásfiókok: függőségfeltárás, koordinált rotáció és hibás credential riasztás.
- Beszállítók: VPN helyett célhoz és időhöz kötött, rögzített böngészős hozzáférés.
- Helpdesk: teljes helyi admin helyett konkrét eszközök vagy alkalmazások JIT emelése.
- DevOps: hard-coded kulcsok kiváltása workload-hitelesítéssel és dinamikus secretekkel.
- Cloud admin: állandó szerepkörök csökkentése, időszakos entitlement és auditált konzol/CLI használat.
Pragmatikus fázisok
1. Alap: kritikus fiókleltár, vault, MFA, RBAC, mentés. 2. Kontroll: automatikus discovery, rotáció, dependency és sessionindítás. 3. Least privilege: EPM, szerveres JIT/JEA és beszállítói hozzáférés. 4. Gépi identitások: CI/CD secrets és cloud entitlement. 5. Optimalizálás: viselkedési jelzések, automatizált válasz, folyamatos kontrollmérés.
A siker mérőszámai: vaultba vont privilegizált fiókok aránya; automatikusan rotált secretek aránya; nem kezelt discovery-találatok; állandó adminjoggal rendelkező identitások; jelszófelfedések; sikertelen rotációk; jóváhagyási idő; rögzített kritikus sessionök; kivételek életkora; hozzáférés-felülvizsgálat lezárási aránya.
Aktuális gyártói dokumentáció
A termékleírások és architekturális állítások a Delinea nyilvános termékoldalai és dokumentációja alapján, 2026. augusztus 7-én ellenőrizve.