- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (80)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Chraňte IS před kybernetickými útoky na privilegované účty
Na rozdíl od situace, která u nás panovala jetě před několika málo lety, si dnes ji větina firem a institucí uvědomuje důleitost procesního a auditovatelného řízení ivotního cyklu uivatelů a jejich přístupových oprávnění. A nejen e si je firmy uvědomují, ale tyto principy buď ji zavedly, nebo je právě zavádějí do své kadodenní praxe.

Nejméně pozornosti v oblasti digitálních identit, základu dnení aplikační ekonomiky a digitální transformace, se vak paradoxně věnuje těm uivatelům, od kterých hrozí největí riziko privilegovaným uivatelům. Jedná se zejména o administrátory jednotlivých systémů a o externí subjekty vzdáleně spravující určitou část informační infrastruktury. A ač to moná není z aktuálně platných či připravovaných zákonů či regulací, které na nás postupně dopadají, na první pohled zřejmé (a je jedno, zda se jedná o zákon o kybernetické bezpečnosti, NIS, PCI DSS, ENISA či GDPR), procesní řízení přístupu privilegovaných uivatelů je základním stavebním základem jak těchto bezpečnostních regulací, tak zejména účinné obrany proti stále sofistikovanějím útokům na hybridní informační infrastrukturu. Ostatně ne nadarmo se říká, e největí přehled o firmě má vrátný a IT administrátor. Zatímco vak od vrátného moc velké riziko kybernetického útoku nehrozí, u IT administrátorů, na které sofistikované útoky cílí právě díky jejich privilegovanému postavení, je to riziko naopak velmi vysoké.
Jene jak efektivně sníit rizika plynoucí z často a neomezených přístupových oprávnění administrátorů či externích firem k privilegovaným, často sdíleným účtům, kde se dnes v mnoha případech nevyaduje ani silná autentizace, o detailním auditu jednotlivých administrátorských relací ani nemluvě? A jak to celé zařídit tak, aby to bylo z pohledu implementace co nejméně invazivní, z pohledu provozu nenáročné na zdroje, z pohledu auditora transparentní a z pohledu privilegovaných uivatelů maximálně komfortní?
Autentizace a správa hesel
Prvním krokem ke zvýení bezpečnosti a sníení rizika zcizení a zneuití přihlaovacích údajů je zajitění a vynucení silné, minimálně dvoufaktorové autentizace uivatelů k privilegovaným, tedy zejména administračním účtům, ideálně společně s vyhodnocováním aktuální úrovně rizika daného přihláení (pouité zařízení, denní doba, lokalita uivatele, typ připojení, atd.). V případě tak heterogenního prostředí, jaké je dnes běné, tedy kombinace různých operačních systémů, aplikací, databází, síových a bezpečnostních prvků, hypervizorů či cloudových aplikací, by vak konsolidace autentizace k jejich privilegovaným účtům byla bez pouití speciálního nástroje velmi komplikovaná. Nicméně na trhu ji jsou k dispozici řeení, která tuto problematiku v různé míře pokrývají. Nazývají se nejčastěji obecně jako Privileged Access Management (zkráceně PAM), případně také Privileged Identity Management (PIM) nebo Privileged User Management (PUM). A některé z nich jsou ji přímo dodávány spolu s funkcí silné a rizikové autentizace, případně se integrují s vaím současným autentizačním serverem.
Aby vak bylo moné silnou autentizaci opravdu vynutit, privilegovaní uivatelé nesmí disponovat hesly k jednotlivým privilegovaným účtům. Ta musí být ifrovaně uloena a jejich ivotní cyklus řízen přímo prostřednictvím PAM řeení. Uivatelům pak hesla nesmí být kromě velmi specifických situací (např. havarijní stav) volně k dispozici. Řeení PAM tedy slouí jako centrální silný autentizační hub, který zajistí prvotní ověření privilegovaného uivatele a následně mu na bázi nastavených politik (buď přímo v PAM řeení, nebo na bázi integrovaného identity managementu) zpřístupní transparentní přihláení k vybraným účtům na vybraných systémech. Transparentním přihláením, tedy přihláením uivatele na pozadí, je aktuální heslo zabezpečeno nejen proti vyzrazení administrátorem, ale i proti zcizení např. na bázi tzv. keyloggingu, stínování či kodlivého kódu. Celý ivotní cyklus hesel, tedy jejich generování a změna v cílových systémech, je pak kompletně v reii PAM dle nastavených pravidel.
To, e vhodným řeením PAM lze kromě vynucení silného ověření administrátorů zajistit také jasnou zodpovědnost konkrétních administrátorů při pouití sdílených účtů (např. admin, root nebo sysdba), u je jen třeničkou na dortu.
K administračním, systémovým a technickým účtům vak nepřistupují pouze uivatelé, ale také aplikace či skripty. Ty v sobě dnes obsahují názvy účtů a hlavně jejich (často dlouho nezměněná) hesla, mnohdy navíc v čitelné podobě. V rámci zabezpečení přístupu i k těmto účtům je tak nutné, aby PAM systém umoňoval také autentizaci skriptu vůči systému PAM, který mu v momentě sputění poskytne aktuálně platné heslo. Taková funkce se v rámci PAM řeení obecně nazývá application-to-application (zkráceně A2A).
Autorizace a restrikce oprávnění
Po silné autentizaci přichází na řadu autorizace uivatele k přístupu ke konkrétním účtům a za předem definovaných okolností, a následně i případná omezení jeho oprávnění v rámci daných relací. Autorizace i jednotlivá omezení by měla být zaloena na centrálně řízeném RBAC modelu uivatel má pouze taková oprávnění, jaká náleí jeho roli.
Pro předcházení chybám či úmyslným útokům je vhodné mít i monost monitorování obsahu probíhajících relací včetně filtrování příkazů. Nestane se vám pak, e si databázový administrátor splete produkční a testovací prostředí a spustí příkaz drop table.
Častým vektorem útoku bývá také pouití jednoho serveru pro získání přístupu k jinému serveru, na který u nemá uivatel oprávnění, tzv. leapfrogging. PAM řeení by mělo pamatovat i na tyto situace a neumonit tak uivateli či kodlivému kódu obcházet bezpečnostní mechanismy.
Pokud firma či instituce provozuje kritické servery či servery obsahující citlivé údaje, měla by také zváit monost zabezpečení těchto serverů přímo na úrovni kernelu, a toto mít se svým PAM řeením integrováno. Při přímém přístupu k privilegovaným účtům na těchto kritických serverech, co je za určitých okolností třeba, je pak zajitěno vynucení stejných politik a omezení jako v případě přístupu přes řeení PAM.
Čím dál více firem také začalo pro své klíčové procesy vyuívat hypervizory a cloudové sluby, a přístup k jejich administraci tak musí začít podléhat stejně striktním pravidlům, jako jim podléhá administrace interních systémů. A u se jedná o VMware, Office365 či Amazon Web Services, je to oblast, kterou prostě nelze ignorovat.
Audit a monitoring
V oblasti PAM audit zdaleka nekončí jen sledováním, kdo má kam jaká přístupová práva a kdy se přihlásil k jakému účtu. Auditem a monitoringem je zde mylen komplexní proces logování a nahrávání relací a pouitých příkazů, tedy kombinace videa a textu, které se pak v komprimované a zaifrované podobě ukládají pro případ budoucí potřeby přehrání a analýzy, v krajních případech také pro případ dokazování konkrétního jednání u soudu.
Pro dalí zvýení bezpečnosti je v rámci monitoringu kritických systémů dobré uvaovat také o vyhodnocování aktuálního rizika chování jednotlivých uivatelů přihláených k privilegovaným účtům. Cílem je detekce podezřelých aktivit uivatele s případným vynuceným ukončením dané relace.
Implementace, integrace a správa
Ač se z pohledu určitého zásahu do způsobu práce privilegovaných uivatelů a s tím spojených procesů můe jednat o sloitou disciplínu a z toho plynoucí sloité řeení, nemusí tomu tak být. Implementace a integrace PAM řeení můe být ji dnes přímočará a rychlá, správa intuitivní a uivatelský komfort maximální.
Stejně tak je dobré se při výběru vaeho PAM řeení soustředit na jeho irokou podporu systémů a na jednoduchost jejich integrace, ideálně prostřednictvím dodávaných konektorů s moností vlastní integrace např. na bázi API.
Architektura a forma provozu
Architektura a forma provozu PAM řeení se vám moná nemusí zdát tak důleitá jako jeho funkce, ale jen do momentu, ne začnete řeit jeho implementaci, správu a podporu. Při výběru PAM řeení si tedy dobře vímejte, kolik modulů je pro provoz ve vaem prostředí třeba, kolik to reálně reprezentuje virtuálních nebo fyzických serverů, jaká je výkonnost, jak se řeí jeho vysoká dostupnost a jak se dané řeení licencuje. Teprve po přidání těchto parametrů se rozhodněte, které řeení si nakonec vyberete.
![]() |
David Matějů Autor článku je Senior Security Consultant ve společnosti CA CEE, s. r. o. |






















