{"id":87793,"date":"2020-07-10T13:41:57","date_gmt":"2020-07-10T11:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya"},"modified":"2020-07-10T13:41:57","modified_gmt":"2020-07-10T11:41:57","slug":"stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","title":{"rendered":"Budujemy model r\u00f3l zarz\u0105dzania dost\u0119pem. Cz\u0119\u015b\u0107 pierwsza, przygotowawcza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Obecnie pracuj\u0119 w firmie dostarczaj\u0105cej oprogramowanie, a dok\u0142adniej w zakresie rozwi\u0105za\u0144 do zarz\u0105dzania dost\u0119pem. Moje do\u015bwiadczenie z \"przesz\u0142ego \u017cycia\" wi\u0105\u017ce si\u0119 natomiast z rol\u0105 klienta \u2013 du\u017c\u0105 instytucj\u0105 finansow\u0105. W\u00f3wczas nasza grupa zajmuj\u0105ca si\u0119 kontrol\u0105 dost\u0119pu w dziale zabezpiecze\u0144 informacji nie mog\u0142a pochwali\u0107 si\u0119 du\u017cymi kompetencjami w dziedzinie IdM. Uczyli\u015bmy si\u0119 wiele w trakcie, musieli\u015bmy pope\u0142ni\u0107 wiele b\u0142\u0119d\u00f3w, aby zbudowa\u0107 w firmie dzia\u0142aj\u0105cy mechanizm zarz\u0105dzania uprawnieniami u\u017cytkownik\u00f3w w systemach informacyjnych.
\n\"Budujemy
\n\u0141\u0105czenie mojego do\u015bwiadczenia zdobytego po stronie klienta z wiedz\u0105 i kompetencjami dostawcy, chc\u0119 podzieli\u0107 si\u0119 z wami swoist\u0105 instrukcj\u0105 krok po kroku: jak w du\u017cej firmie stworzy\u0107 model r\u00f3l zarz\u0105dzania dost\u0119pem i jakie to przyniesie korzy\u015bci. Moja instrukcja sk\u0142ada si\u0119 z dw\u00f3ch cz\u0119\u015bci: pierwsza \u2013 przygotowania do stworzenia modelu, druga \u2013 samo budowanie. Oto cz\u0119\u015b\u0107 pierwsza, przygotowawcza.
\n<\/a><\/noindex>
\nN.B.<\/b> Budowanie modelu r\u00f3l to, niestety, nie rezultat, a proces. A dok\u0142adniej, jest to cz\u0119\u015b\u0107 procesu tworzenia w firmie ekosystemu zarz\u0105dzania dost\u0119pem. Dlatego nastaw si\u0119 na d\u0142ugotrwa\u0142\u0105 gr\u0119.
\n<\/i>
\nNa pocz\u0105tku zdefiniujmy \u2013 czym w\u0142a\u015bciwie jest zarz\u0105dzanie dost\u0119pem oparte na rolach? Za\u0142\u00f3\u017cmy, \u017ce masz du\u017c\u0105 bank z dziesi\u0105tkami, a nawet setkami tysi\u0119cy pracownik\u00f3w (podmiot\u00f3w), z kt\u00f3rych ka\u017cdy ma dziesi\u0105tki uprawnie\u0144 do setek wewn\u0119trznych system\u00f3w informacyjnych (obiekt\u00f3w). A teraz pomn\u00f3\u017c liczb\u0119 obiekt\u00f3w przez liczb\u0119 podmiot\u00f3w \u2013 dok\u0142adnie tyle relacji minimum musisz najpierw zbudowa\u0107, a potem kontrolowa\u0107. Czy da si\u0119 to zrobi\u0107 r\u0119cznie? Oczywi\u015bcie, \u017ce nie \u2013 w tym celu powsta\u0142y role.<\/p>\n

Rola to zestaw uprawnie\u0144, kt\u00f3re s\u0105 potrzebne u\u017cytkownikowi lub grupie u\u017cytkownik\u00f3w do wykonywania okre\u015blonych zada\u0144 zawodowych. Ka\u017cdy pracownik mo\u017ce posiada\u0107 jedn\u0105 lub wi\u0119cej r\u00f3l, a ka\u017cda rola mo\u017ce zawiera\u0107 od jednego do wielu uprawnie\u0144, kt\u00f3re s\u0105 dozwolone u\u017cytkownikowi w ramach tej roli. Role mog\u0105 by\u0107 przypisane do okre\u015blonych stanowisk, dzia\u0142\u00f3w lub funkcjonalnych zada\u0144 pracownik\u00f3w.<\/p>\n

\"Budujemy
\n
\nRole s\u0105 zazwyczaj tworzone na podstawie indywidualnych uprawnie\u0144 pracownika w ka\u017cdym systemie informacyjnym. Nast\u0119pnie z r\u00f3l ka\u017cdego systemu formu\u0142owane s\u0105 globalne role biznesowe. Na przyk\u0142ad rola biznesowa \u201emened\u017cer kredytowy\u201d obejmie kilka indywidualnych r\u00f3l w systemach informacyjnych wykorzystywanych w biurze klienta banku. Powiedzmy, w takich jak g\u0142\u00f3wny zautomatyzowany system bankowy, modu\u0142 kasowy, system elektronicznego obiegu dokument\u00f3w, mened\u017cer us\u0142ug oraz inne. Role biznesowe zazwyczaj s\u0105 powi\u0105zane z organizacyjn\u0105 struktur\u0105 firmy \u2013 kr\u00f3tko m\u00f3wi\u0105c, z zestawem jednostek organizacyjnych firmy oraz stanowiskami w nich. W ten spos\u00f3b formu\u0142owana jest globalna macierz r\u00f3l (przyk\u0142ad podaj\u0119 w tabeli poni\u017cej).<\/p>\n

\"Budujemy
\n
\nWarto zauwa\u017cy\u0107, \u017ce zbudowanie modelu r\u00f3l w 100%, zapewniaj\u0105c wszystkie niezb\u0119dne prawa pracownikom na ka\u017cdym stanowisku w strukturze komercyjnej, jest po prostu niemo\u017cliwe. Nie ma te\u017c takiej potrzeby. Gdy\u017c model r\u00f3l nie mo\u017ce by\u0107 statyczny, poniewa\u017c zale\u017cy od ci\u0105gle zmieniaj\u0105cego si\u0119 otoczenia. I od zmiany dzia\u0142alno\u015bci biznesowej firmy, co odpowiednio ma wp\u0142yw na zmian\u0119 struktury organizacyjnej i funkcji. I od braku pe\u0142nego zabezpieczenia zasobami, i od nieprzestrzegania przepis\u00f3w s\u0142u\u017cbowych, i od d\u0105\u017cenia do zysku kosztem bezpiecze\u0144stwa, i od wielu innych czynnik\u00f3w. Dlatego nale\u017cy budowa\u0107 model r\u00f3l, kt\u00f3ry b\u0119dzie w stanie zaspokoi\u0107 do 80% potrzeb u\u017cytkownik\u00f3w w zakresie niezb\u0119dnych podstawowych praw przy przyjmowaniu na stanowisko. A pozosta\u0142e 20% b\u0119d\u0105 mogli, je\u015bli zajdzie taka potrzeba, zg\u0142asza\u0107 p\u00f3\u017aniej w osobnych wnioskach.<\/p>\n

Oczywi\u015bcie mo\u017cesz zapyta\u0107: \u201eCzy w og\u00f3le istniej\u0105 100% modele r\u00f3l?\u201d C\u00f3\u017c, zdarzaj\u0105 si\u0119 takie sytuacje, na przyk\u0142ad w strukturach non-profit, kt\u00f3re nie podlegaj\u0105 cz\u0119stym zmianom \u2013 w jakim\u015b instytucie badawczym. Lub w organizacjach sektora obronnego o wysokim poziomie zabezpiecze\u0144, gdzie bezpiecze\u0144stwo jest priorytetem. Zdarza si\u0119 te\u017c w strukturach komercyjnych, ale w ramach pojedynczej jednostki, kt\u00f3rej dzia\u0142alno\u015b\u0107 jest na tyle statyczna i przewidywalna.<\/p>\n

G\u0142\u00f3wn\u0105 zalet\u0105 zarz\u0105dzania rolami jest uproszczenie przyznawania uprawnie\u0144, poniewa\u017c liczba r\u00f3l jest znacznie mniejsza ni\u017c liczba u\u017cytkownik\u00f3w systemu informacyjnego. A to odnosi si\u0119 do ka\u017cdej bran\u017cy.<\/p>\n

We take a retail company: it employs thousands of sellers, but they all have the same rights in system N, and only one role will be created for them. When a new seller joins the company, they are automatically assigned the appropriate role in the system, which already has all the necessary permissions. Similarly, with one click, rights can be changed for thousands of sellers at once, for example, adding a new option for generating reports. There is no need to perform a thousand operations, linking the new right to each account \u2013 it\u2019s enough to include this option in the role, and it will appear for all sellers simultaneously.<\/p>\n

Another advantage of role management is the exclusion of incompatible permissions. That is, an employee with a specific role in the system cannot simultaneously have another role whose permissions should not coincide with those in the first. A clear example is the prohibition of combining functions of entering and controlling a financial operation.<\/p>\n

Everyone interested in how role-based access management came into being can
\n dive into a history overview<\/b>
\n If we look back at history, it was in the 1970s that the IT community first began to think about methods of access management. Although applications were quite simple at that time, just like now, everyone wanted to manage access to them conveniently. Granting, changing, and controlling user rights \u2013 simply to better understand what access each of them has. However, at that time, there were no common standards; the first access management systems were being developed, and each company based its systems on its own ideas and rules.<\/p>\n

Now, many different access management models are known, but they did not emerge all at once. Let\u2019s focus on those that made a significant contribution to the development of this field.<\/p>\n

The first and probably the simplest model is Discretionary (selective) access control<\/b> (DAC \u2013 Kontrola dost\u0119pu w oparciu o uprawnienia). Model ten zak\u0142ada wsp\u00f3lne korzystanie z uprawnie\u0144 przez wszystkich uczestnik\u00f3w procesu dost\u0119pu. Ka\u017cdy u\u017cytkownik otrzymuje dost\u0119p do konkretnych obiekt\u00f3w lub operacji. W istocie, liczba podmiot\u00f3w uprawnie\u0144 odpowiada liczbie obiekt\u00f3w. Model ten zosta\u0142 uznany za zbyt elastyczny i zbyt skomplikowany do utrzymania: listy dost\u0119pu z czasem staj\u0105 si\u0119 ogromne i trudne do kontrolowania.<\/p>\n

Drugim modelem jest Zarz\u0105dzanie dost\u0119pem oparte na zezwoleniach (MAC \u2014 Mandatory access control)<\/b>. W tym modelu ka\u017cdy u\u017cytkownik uzyskuje dost\u0119p do obiektu zgodnie z okre\u015blonym zezwoleniem na dany poziom poufno\u015bci danych. Odpowiednio, obiekty musz\u0105 by\u0107 klasyfikowane wed\u0142ug poziomu poufno\u015bci. W przeciwie\u0144stwie do pierwszego elastycznego modelu, ten okaza\u0142 si\u0119 zbyt rygorystyczny i ograniczaj\u0105cy. Jego zastosowanie nie jest uzasadnione, gdy w firmie jest wiele r\u00f3\u017cnorodnych zasob\u00f3w informacyjnych: aby rozdzieli\u0107 dost\u0119p do r\u00f3\u017cnych zasob\u00f3w, b\u0119dzie trzeba wprowadzi\u0107 wiele kategorii, kt\u00f3re nie b\u0119d\u0105 si\u0119 krzy\u017cowa\u0107.<\/p>\n

W zwi\u0105zku z oczywistymi niedoskona\u0142o\u015bciami tych dw\u00f3ch metod, \u015brodowisko IT kontynuowa\u0142o opracowywanie modeli, kt\u00f3re by\u0142yby bardziej elastyczne i mniej wi\u0119cej uniwersalne do wsparcia r\u00f3\u017cnych typ\u00f3w organizacyjnych polityk kontroli dost\u0119pu. I w ten spos\u00f3b pojawi\u0142 si\u0119 trzeci model zarz\u0105dzania dost\u0119pem oparty na rolach!<\/b> Podej\u015bcie to okaza\u0142o si\u0119 najbardziej obiecuj\u0105ce, poniewa\u017c wymaga nie tylko autoryzacji to\u017csamo\u015bci u\u017cytkownika, ale i jego funkcji w systemach.<\/p>\n

Pierwsz\u0105 jasno opisan\u0105 struktur\u0119 modelu r\u00f3l zaproponowali ameryka\u0144scy naukowcy David Ferraiolo i Richard Kuhn z Narodowego Instytutu Standard\u00f3w i Technologii USA w 1992 roku. Wtedy po raz pierwszy pojawi\u0142 si\u0119 termin RBAC (Kontrola dost\u0119pu oparta na rolach). <\/b>Badania te oraz opisy podstawowych komponent\u00f3w, jak r\u00f3wnie\u017c ich wzajemnych powi\u0105za\u0144, stanowi\u0142y podstaw\u0119 obowi\u0105zuj\u0105cego do dzi\u015b standardu INCITS 359-2012, zatwierdzonego przez Mi\u0119dzynarodowy Komitet ds. Standard\u00f3w Technologii Informacyjnych (INCITS).<\/p>\n

Standard okre\u015bla rol\u0119 jako \u201efunkcj\u0119 s\u0142u\u017cbow\u0105 w kontek\u015bcie organizacji, z pewn\u0105 zwi\u0105zan\u0105 semantyk\u0105 w odniesieniu do pe\u0142nomocnictw i odpowiedzialno\u015bci, na\u0142o\u017conych na u\u017cytkownika, kt\u00f3remu przydzielono rol\u0119\u201d. Dokument ustala podstawowe elementy RBAC \u2013 u\u017cytkownik\u00f3w, sesje, role, uprawnienia, operacje i obiekty, a tak\u017ce relacje i powi\u0105zania mi\u0119dzy nimi.<\/p>\n

W standardzie przedstawiono minimalnie konieczn\u0105 struktur\u0119 do budowy modelu r\u00f3l \u2013 \u0142\u0105czenie praw w rolach, a nast\u0119pnie przydzielanie dost\u0119pu u\u017cytkownikom za po\u015brednictwem tych r\u00f3l. Okre\u015blono mechanizmy sk\u0142adania r\u00f3l z obiekt\u00f3w i operacji, opisano hierarchi\u0119 r\u00f3l i dziedziczenie pe\u0142nomocnictw. W ka\u017cdej firmie wyst\u0119puj\u0105 role, kt\u00f3re \u0142\u0105cz\u0105 podstawowe uprawnienia, kt\u00f3re s\u0105 niezb\u0119dne dla wszystkich pracownik\u00f3w firmy. Mo\u017ce to obejmowa\u0107 dost\u0119p do poczty elektronicznej, systemu zarz\u0105dzania tre\u015bci\u0105, portalu korporacyjnego itp. Te uprawnienia mo\u017cna po\u0142\u0105czy\u0107 w jedn\u0105 wsp\u00f3ln\u0105 rol\u0119 o nazwie \u201epracownik\u201d, co eliminuje konieczno\u015b\u0107 wymieniania wszystkich podstawowych praw w ka\u017cdej z r\u00f3l wy\u017cszego poziomu. Wystarczy wskaza\u0107 atrybut dziedziczenia roli \u201epracownik\u201d.<\/p>\n

\"Budujemy
\n
\nP\u00f3\u017aniej standard zosta\u0142 uzupe\u0142niony o nowe atrybuty dost\u0119pu, zwi\u0105zane z dynamicznie zmieniaj\u0105cym si\u0119 \u015brodowiskiem. Dodano mo\u017cliwo\u015b\u0107 wprowadzenia ogranicze\u0144 statycznych i dynamicznych. Statyczne wi\u0105\u017c\u0105 si\u0119 z niemo\u017cliwo\u015bci\u0105 \u0142\u0105czenia r\u00f3l (to w\u0142a\u015bnie ten wprowadzenie i kontrola operacji, o kt\u00f3rym wspomniano wcze\u015bniej). Ograniczenia dynamiczne mog\u0105 by\u0107 okre\u015blane przez zmieniaj\u0105ce si\u0119 parametry, na przyk\u0142ad czas (godziny robocze\/nierobocze), lokalizacj\u0119 (biuro\/dom) itp.<\/p>\n

Osobno warto wspomnie\u0107 o zarz\u0105dzaniu dost\u0119pem opartym na atrybutach (ABAC \u2014 kontrola dost\u0119pu oparta na atrybutach).<\/b> Podej\u015bcie to polega na udzielaniu dost\u0119pu za pomoc\u0105 regu\u0142 wsp\u00f3\u0142dzielenia atrybut\u00f3w. Model ten mo\u017ce by\u0107 u\u017cywany samodzielnie, ale do\u015b\u0107 cz\u0119sto aktywnie uzupe\u0142nia klasyczny model r\u00f3l: do danej roli mo\u017cna dodawa\u0107 atrybuty u\u017cytkownik\u00f3w, zasob\u00f3w i urz\u0105dze\u0144, a tak\u017ce czasu lub lokalizacji. Pozwala to na stosowanie mniejszej liczby r\u00f3l, wprowadzenie dodatkowych ogranicze\u0144 i zapewnienie minimalnego, wystarczaj\u0105cego dost\u0119pu, a tym samym zwi\u0119kszenie bezpiecze\u0144stwa.<\/p>\n

Na przyk\u0142ad ksi\u0119gowy mo\u017ce mie\u0107 dost\u0119p do kont, je\u015bli pracuje w okre\u015blonym regionie. Wtedy lokalizacja specjalisty b\u0119dzie por\u00f3wnywana z okre\u015blon\u0105 warto\u015bci\u0105 referencyjn\u0105. Mo\u017cna te\u017c przyzna\u0107 dost\u0119p do kont tylko wtedy, gdy u\u017cytkownik loguje si\u0119 z urz\u0105dzenia, kt\u00f3re znajduje si\u0119 na li\u015bcie dozwolonych. To dobre uzupe\u0142nienie modelu r\u00f3l, ale rzadko stosowane samodzielnie z powodu potrzeby tworzenia wielu zasad i tabel uprawnie\u0144 lub ogranicze\u0144.<\/p>\n

Podam przyk\u0142ad zastosowania ABAC z mojej 'poprzedniej pracy'. W naszym banku by\u0142o kilka oddzia\u0142\u00f3w. Pracownicy biur obs\u0142ugi klienta w tych oddzia\u0142ach wykonywali absolutnie takie same operacje, ale musieli pracowa\u0107 w g\u0142\u00f3wnym systemie tylko z kontami swojego regionu. Na pocz\u0105tku zacz\u0119li\u015bmy tworzy\u0107 osobne role dla ka\u017cdego regionu \u2013 takich r\u00f3l z powtarzaj\u0105c\u0105 si\u0119 funkcjonalno\u015bci\u0105, ale z dost\u0119pem do r\u00f3\u017cnych kont by\u0142o bardzo du\u017co! Wtedy, wykorzystuj\u0105c atrybut lokalizacji u\u017cytkownika i \u0142\u0105cz\u0105c go z konkretnym zakresem kont do weryfikacji, znacznie zmniejszyli\u015bmy liczb\u0119 r\u00f3l w systemie. W rezultacie pozosta\u0142y role tylko dla jednego oddzia\u0142u, kt\u00f3re by\u0142y powielone na odpowiednie stanowiska we wszystkich pozosta\u0142ych terytorialnych jednostkach banku.<\/p>\n

A teraz porozmawiajmy o niezb\u0119dnych krokach przygotowawczych, bez kt\u00f3rych nie mo\u017cna zbudowa\u0107 dzia\u0142aj\u0105cego modelu r\u00f3l.<\/p>\n

Krok 1. Tworzymy model funkcjonalny<\/h2>\n

\nWarto zacz\u0105\u0107 od stworzenia modelu funkcjonalnego - dokumentu na wysokim poziomie, w kt\u00f3rym szczeg\u00f3\u0142owo opisano funkcjonalno\u015b\u0107 ka\u017cdego dzia\u0142u i ka\u017cdej pozycji. Zazwyczaj informacje do niego trafiaj\u0105 z r\u00f3\u017cnych dokument\u00f3w: instrukcji stanowiskowych oraz regulamin\u00f3w dotycz\u0105cych poszczeg\u00f3lnych dzia\u0142\u00f3w - wydzia\u0142\u00f3w, zarz\u0105d\u00f3w, departament\u00f3w. Model funkcjonalny powinien by\u0107 uzgodniony ze wszystkimi zainteresowanymi dzia\u0142ami (biznes, kontrola wewn\u0119trzna, bezpiecze\u0144stwo) i zatwierdzony przez kierownictwo firmy. Do czego potrzebny jest ten dokument? Aby model r\u00f3l m\u00f3g\u0142 si\u0119 do niego odwo\u0142ywa\u0107. Na przyk\u0142ad, zamierzacie zbudowa\u0107 model r\u00f3l na podstawie ju\u017c istniej\u0105cych uprawnie\u0144 pracownik\u00f3w - wyeksportowanych z systemu i \u201eujednoliconych\u201d. W\u00f3wczas przy uzgadnianiu otrzymanych r\u00f3l z w\u0142a\u015bcicielem biznesowym systemu mo\u017cna powo\u0142a\u0107 si\u0119 na konkretny punkt modelu funkcjonalnego, na podstawie kt\u00f3rego do roli w\u0142\u0105czane jest dane prawo.<\/p>\n

Krok 2. Audytujemy systemy IT i opracowujemy plan priorytetyzacji<\/h2>\n

\nNa drugim etapie nale\u017cy przeprowadzi\u0107 audyt system\u00f3w IT, aby zrozumie\u0107, jak zorganizowany jest w nich dost\u0119p. Na przyk\u0142ad, w mojej firmie finansowej eksploatowano kilka setek system\u00f3w informacyjnych. We wszystkich systemach by\u0142y pewne zal\u0105\u017cki zarz\u0105dzania rolami, w wi\u0119kszo\u015bci - jakie\u015b role, ale g\u0142\u00f3wnie na papierze lub w katalogu systemu - by\u0142y one dawno przestarza\u0142e, a dost\u0119p do nich przyznawano na podstawie faktycznych wniosk\u00f3w u\u017cytkownik\u00f3w. Naturalnie, zbudowanie modelu r\u00f3l od razu w kilku setkach system\u00f3w jest po prostu niemo\u017cliwe, trzeba od czego\u015b zacz\u0105\u0107. Przeprowadzili\u015bmy szczeg\u00f3\u0142ow\u0105 analiz\u0119 procesu zarz\u0105dzania dost\u0119pem, aby okre\u015bli\u0107 poziom jego dojrza\u0142o\u015bci. W trakcie analizy opracowali\u015bmy kryteria priorytetyzacji system\u00f3w informacyjnych - krytyczno\u015b\u0107, gotowo\u015b\u0107, plany wycofania z eksploatacji itp. Z ich pomoc\u0105 ustalili\u015bmy kolejno\u015b\u0107 opracowywania\/aktualizacji modeli r\u00f3l dla tych system\u00f3w. A nast\u0119pnie w\u0142\u0105czyli\u015bmy modele r\u00f3l do planu integracji z rozwi\u0105zaniem zarz\u0105dzania to\u017csamo\u015bci\u0105, aby zautomatyzowa\u0107 zarz\u0105dzanie dost\u0119pem.<\/p>\n

Jak wi\u0119c okre\u015bli\u0107 krytyczno\u015b\u0107 systemu? Odpowiedz sobie na nast\u0119puj\u0105ce pytania:<\/p>\n