Publikujeme

Nacházíte se zde: Úvodní stránka > Publikujeme > Blog > Požadavky kybernetického zákona - seriál o IdM část 5.

Požadavky kybernetického zákona - seriál o IdM část 5.

Požadavky kybernetického zákona - seriál o IdM část 5. 123

V tomto díle celou sérii zakončíme. Nejprve se seznámíme s vybranými požadavky Kybernetického zákona, které je možno realizovat pomocí nástrojů identity a access managementu a ISO 27001. Následně se budeme věnovat technickým řešením pro identity manager - jaké možnosti pro realizaci trh nabízí a jak se v nich zorientovat.

Sdílej na sociálních sítích:

V minulé části seriálu jsme prošli dvě oblasti: access management, který s řízením identit úzce souvisí, a řízení distribuce SSH klíčů pro uživatele linuxových systémů. Dozvěděli jsme se tak o autentizaci a autorizaci uživatelů, jednotném přihlašování a odhlašování - SSO, řešení pro sdílení identit mezi partnerskými systémy - federaci a s tím související BYOID, a bezpečnostních rizicích access managementu spolu s řešením v podobě standardu RAdAC. 

V tomto díle se nejprve seznámíme s vybranými požadavky Kybernetického zákona, které je možno realizovat pomocí nástrojů identity a access managementu a ISO 27001. Následně se budeme věnovat technickým řešením pro identity manager - jaké možnosti pro realizaci trh nabízí a jak se v nich zorientovat.

Kybernetický zákon

Celým názvem "Zákon č. 181/2014 Sb., o kybernetické bezpečnosti" definuje požadavky na provozovatele nebo správce kritické informační infrastruktury nebo významného informačního systému dle zákona 432/2010 Sb. Jako prvek kritické infrastruktury se zjednodušeně počítá ten, jehož narušení způsobí:

  • více než 250 mrtvých nebo 2500 hospitalizovaných osob po dobu 1 dne,
  • ztrátu více jak 0,5% HDP,
  • zásah do každodenního života pro více než 125 000 osob.

Významný informační systém je pak ten, jehož narušení významně způsobí ohrožení výkonu orgánu veřejné moci.

Jak může IdM pomoci při řešení požadavků ZoKB

Identity management může pomoct řešit především požadavky na řízení rolí, přístupů a stanovení politik. Pojďme se podívat, na konkrétní příklady přínosů (pro bližší seznámení s jednotlivými oblastmi nahlédněte do přechozích dílů tohoto seriálu).

Řízení rolí

Použitím Identity manageru můžeme stanovovat pravidla pro přidělování oprávnění. Pomocí rolí můžeme řídit, kdo obsazuje jakou roli, jaká oprávnění není možné mít současně.

Požadavky KZ

Požadavek na stálou obsazenost rolí a neslučitelnost rolí.

Řízení přístupů a bezpečné chování uživatelů

  • Organizace přiděluje a odebírá přístupová práva dle metodiky.
  • Organizace provádí pravidelné přezkoumání přístupových oprávnění a jejich přidělení.

Nástroj pro řízení přístupových oprávnění

  • Řízení přístupů na úrovni jednotlivých aplikací a části dat v aplikaci.
  • Řízení přístupů na úrovni Read-Write-Delete.

Evidence technických účtů

Programové a aplikační účty je možno v Identity manageru evidovat a například jim udělit výjimku z exspirace hesel.

Požadavek KZ

Řízení přístupů a bezpečné chování uživatelů

  • Aplikace, které se přihlašují do kritické infrastruktury, musí mít vlastní programový/aplikační účet.

Řízení identit

Pomocí IdM můžeme řídit používání sdílených účtů.

Požadavek KZ

Řízení přístupů a bezpečné chování uživatelů

  • Nesmí existovat sdílené účty (každá fyzická osoba musí mít jiný identifikátor, pod kterým se přihlašuje a pod kterým pracuje na KI).

Řízení privilegovaných účtů

Privilegované účty můžeme řídit jak pomocí Identity manageru, tak i nástrojem na key distribution management.

Požadavek KZ

Řízení přístupů a bezpečné chování uživatelů

  • Organizace řídí i privilegované účty.

Bezpečnostní politiky

Pravidla jsou nastavena a vynucována v Identity manageru. Politiky lze aplikovat například na heslo.

Požadavky KZ

Řízení přístupů a bezpečné chování uživatelů

  • Nástroj, který vynucuje politiku hesel.

Nástroj pro ověřování identity uživatelů

  • Požadavky na složitost a délku platnosti hesla, politik jeho změn a speciální politiky pro privilegované účty.
  • Heslo musí mít min. 8 znaků, platnost max. 100 dnů, musí obsahovat velká, malá, číslice a speciální znaky a nesmí se měnit víc jak 1x za 24 hodin. Pro administrátory musí mít min. 15 znaků.

Distribuce klíčů

Úkolem oblasti key distribution management je bezpečně řídit vydávání a distribuci klíčů jako přihlašovacích prostředků pro (převážně privilegované) účty.

Požadavky KZ

Kryptografické prostředky

  • Jsou stanoveny možnosti používaných šifer.
  • Povinnost mít systém správy klíčů, který zajistí generování, distribuci, ukládání, archivaci, změny, ničení, kontrolu a audit klíčů.  

Access Management

AM jako aktivní prvek v řízení přístupů uživatele pomůže tam, kde je třeba jednak monitorovat činnost uživatele v reálném čase, jednak v případech, kdy potřebujeme zaznamenávat aktivitu uživatele nad informačními systémy (ve spolupráci s danými systémy).

Požadavky KZ

Nástroj pro řízení přístupových oprávnění

  • Zaznamenávat přihlášení na kritické infrastruktuře.

Audit a reporting

Záznam důležitých událostí v Identity Manageru a následný audit a reporting je jednou z esenciálních funkcionalit IdM.

Požadavky KZ

Zvládání kybernetických bezpečnostních událostí

  • Procesy o tom, jak zjišťovat, vést a hlásit bezpečnostní incidenty.

Obrázek 1 - Auditní body požadavků Kybernetického zákona z pohledu IdM, AM a KDM

ISO 27001

Z pohledu ISO norem je nejvýznamnější přínos identity managementu pro ISMS - řízení bezpečnosti informací, v české verzi jako ČSN ISO/IEC 27001. Zde jsou důvody pro její zavedení spojené s naplněním požadavků v kapitolách:

  • Požadavky organizace na řízení přístupu - s cílem omezit přístup k informacím a vybavení pro zpracování informací. (A.9.1.1-2)
  • Řízení přístupu uživatelů - s cílem zajistit oprávněný přístup uživatelů a předcházet neoprávněnému přístupu k systémům a službám. (A.9.2.1-6)
  • Odpovědnosti uživatelů - s cílem učinit uživatele odpovědné za ochranu jejich autentizačních informací. (A.9.3.1)
  • Řízení přístupu k systémům a aplikacím - s cílem předcházet neautorizovanému přístupu k systémům a aplikacím. (A.9.4.1-5)
  • Kryptografická opatření - s cílem zajistit řádné a efektivní používání kryptografie k ochraně důvěrnosti, autentičnosti a / nebo integrity informací. (A.10.1.1-2)

Tolik k legislativním a normativním požadavkům. Pojďme se nyní podívat na některé aspekty realizace identity manageru z pohledu požadavků, které bychom na takový systém mohli mít.

Technické řešení

V rámci fyzické realizace řízení identit je třeba popsat dvě propojené oblasti:

  • architekturu - co s čím budeme propojovat a co zpřístupníme uživatelům,
  • možnosti realizace - jakým nástrojem provedeme realizaci.

Architektura řešení

Integrace s podnikovými systémy

Systém na řízení identit musí umět především komunikovat s podnikovými aplikacemi, jejichž uživatele má spravovat. Zde obecně platí, že čím specializovanější software, tím dražší je řešení.

Nejsnáze proto připojíme systémy s dobře známým rozhraním - LDAP a databázové servery, textové soubory, webové služby. Další v řadě jsou široce nasazované systémy, například Active Directory, Exchange, SAP, Solaris OS. Pro zbytek je pak nutné vyvinout kód pro připojení, který se může prodražit nejvíce. Jedná se většinou o výrobcem identity manageru nepodporované nebo vlastními silami vyvinuté systémy.

Uživatelské rozhraní

Identity manager poskytuje informace pro různé typy uživatelů, typicky:

  • Konfigurátoři - starají se o správné nastavení IdM a jeho funkcionalit.
  • Administrátoři - spravují uživatele a oprávnění, spouštějí reporty a audity.
  • Schvalovatelé - v závislosti na míře propojení s Helpdeskem provádění schválení žádostí o role.
  • Koncoví uživatelé - přistupují do uživatelské samoobsluhy, kde mohou žádat o role, měnit heslo a zobrazit své informace.

Toto uživatelské rozhraní je následně možné těmto typům uživatelů zobrazit různými způsoby:

  • Jako samostatnou aplikaci, běžící na své vlastní webové adrese - nejběžnější použití, v tomto režimu typicky pracují administrátoři a konfigurátoři.
  • Integrace do portálu či Helpdesku - uživatel tak má rozhraní integrované s tím, na které je zvyklý. Vhodné především pro koncové uživatele.
  • Mobilní a tabletové rozhraní - jakýkoliv typ uživatelů může přistupovat na identity manager z počítače, tabletu či mobilu. Toho se dosahuje buď responsivním designem zvoleného uživatelského rozhraní, nebo nativní aplikací pro mobilní platformu (Android, iOS a jiné).

Možnosti realizace

V povídání o realizaci probereme tyto oblasti:

  • Proprietární řešení.
  • Closed source versus open source.
  • On-premises versus cloud.
  • IDaaS a IAMSaaS.

Vlastní řešení

Nejpřímější variantou, jak realizovat řízení identit, je vytvořit si vlastní proprietární řešení. Ať už na principu peer-to-peer s přímým propojením informačních systémů stylem každý s každým, nebo přes podnikovou ESB sběrnici. Takové řešení vlastními silami může být levné, a ze začátku určitě i rychle nasazené. Skrývá však v sobě tato rizika:

  • S každým přidaným systémem roste složitost exponenciálně.
  • V závislosti na oficiálnosti a míře zdokumentování takového díla je do budoucna špatně spravovatelné (například po odchodu autora).
  • Dodělání pokročilých funkcí se může prodražit (řízení rolí, audit firemních politik).

Pokud odhlédneme od vývoje Identity manageru vlastními silami, nalezneme na trhu řadu identity managerů. Jak se tato řešení liší po realizační stránce?

Closed versus Open source

Jedno hledisko je, zda je k dispozici otevřený zdrojový kód (open source projekt), nebo zda je kód zavřený a má k němu přístup jen výrobce (closed source, proprietární software). Open source řešení přináší tyto výhody:

  • možnost prověřit implementaci klíčových funkcionalit (například práci s Active Directory),
  • vývoj komunitou - rychlejší reakce na aktuální témata a rychleji uvolňované nové verze,
  • možnost rozvíjet produkt vlastními silami.

Více o tomto tématu (anglicky).

 

 

Obrázek 2 - On-premises Identity Manager, princip

On-premises versus Cloud

Druhý pohled na Identity managery si všímá toho, jak je řešení pro zákazníka provozováno:

  • On-premises - řešení je provozováno v infrastruktuře ve vlastnictví zákazníka; jedná se o tradiční, a dnes stále dominantní, způsob nasazení IdM. I z pohledu nabídky dodavatelů toto řešení stále převažuje. Dá se však předpokládat, že bude postupně nahrazováno provozováním IdM v cloudu.
  • Cloud - IdM je zde nabízeno v režimu služby, dostupné jako hostované řešení. Hovoříme zde o

SaaS, Software as a Service - model, ve kterém je běh softwaru outsourcován na cloudový server. Software a data s ním spojená jsou hostována v cloudu. Někdy je tento model označován též jako "on-demand software", software na vyžádání. Jednou z prvních českých vlaštovek je v toto směru SkyIdentity.

 

 

Obrázek 3 - Cloud Identity Manager, princip

IDaaS a IAMaaS

V oblasti identity a access managementu v cloudu se můžeme setkat s pojmy IDaaS a IAMaaS. Co tyto pojmy znamenají?

  • IDaaS, Identity as a Service - řešení z IAM oblasti, ve kterém společnost outsourcuje autentizaci a SSO poskytovateli služeb, který tuto část infrastruktury následně spravuje.
  • IAMaaS, Identity and Access Management as a Service - způsob řízení IT zdrojů, ve kterém společnost outsourcuje IAM poskytovateli služeb, který se o ní stará. Poskytovatel je zde odpovědný za fyzické zabezpečení řešení.

 

Obrázek 4 - Identity as a Service (IDaaS), princip

Závěrem

Posledním díl série byl věnován Kybernetickému zákonu, ISO normě 27001 a technickému řešení. Probrali jsme relevantní požadavky z pohledu řízení identit a přístupů jak u této nové legislativy, tak u normy pro bezpečnosti informací a řekli si, kde nám může identity management pomoct a jak. V části věnované technickému řešení jsme se pobavili o návrhu architektury pro Identity manager a porovnali možnosti jeho realizace.

A tím jsme celý seriál "Co je to IdM" uzavřeli.

 

Autor: Petr Gašparík pracuje posledních 6 let jako solution architect pro oblast řízení identit. Ve společnosti AMI Praha působí 19. rokem a má za sebou řadu významných IT projektů pro zákazníky z komerční i veřejné správy např. ČEZ ICT Services, Česká pošta, či Unicredit Bank Czech Republic and Slovakia.

Článek byl publikován v časopise Computerworld 2/2016.



Přejít na začátek stránky

Mapa stránek

© Copyright 1998-2014 AMI Praha a.s., powered by AMIGO CMS