роля базирани контрол на достъпа ползи, практики, характеристики - недвижими ITSM всичко за ITIL,

Здравейте, скъпи посетители на портала Моето име е Александър Омелченко, аз - но Vy Collab Великобритания компания Cleverics. Аз ще се справят с проекта за IDM изпълнение и решения за управление на достъпа. Във връзка с появата на ново направление в компанията, искам да ви кажа повече за концепцията на свързания контрол на достъпа. Днес нека да поговорим за най-популярната досега модел на достъп - роля на основата на контрола на достъпа, известен като RBAC (Role базата за контрол на достъп).

роля базиран контрол на достъпа

Основна характеристика на модел за подражание е, че всички достъп до информационните системи и ресурси, налични само чрез ролята. Роля - набор от права за достъп. Потребителите имат достъп само чрез определени роли.

Идеята за ролята базиран достъп произтича от необходимостта да се групови набори от права върху отделни лица, които ясно даде да се разбере какъв вид достъп потребителят има, което би било по-удобно и по-интуитивен за работа в случай на промени, като позицията на потребителя в организацията, и права набор потребителски достъп. Исторически погледнато, набор от правила, стана свързана с историческото, в действителност - към функционалните роли. Следователно понятието роли. Първите приложения, които реализират роля базиран контрол на достъпа на потребителите, започнаха да се появяват още през 1970-те години. Въпреки че е сравнително прости системи и приложения. Нямаше нито един модел, който описва как предоставения достъп на потребителя въз основа на ролята си в организацията. Системи, разработени от различни организации, без съгласувани определения и стандарти.

Предимства на роля базиран контрол на достъпа

В сравнение с посочените по-горе модели, ролята на основата на контрол на достъпа има редица важни положителни свойства. Например:

• Възможност за изграждане на роля йерархия с наследството набор от права. Това улеснява пример за подражание, особено в организации с хетерогенна инфраструктура, която използва много информационни системи. С използването на йерархията не е необходимо да се включат отново в правото в няколко от тези роли, е достатъчно, за да ги постави в голяма роля, тъй като децата, което показва само уникалните разрешения за всяка роля.
• Просто и ефективно да предостави същите права за много потребители - достатъчно, за да зададете на потребителите да роля.
• Ако е необходимо, променете набор от права за много потребители е достатъчно, за да се промени набор от права в ролята.
• Възможността за прилагане на принципа на разделение на властите (SOD - разделяне на функциите). Това значително намалява риска от потребителите на излишък от сили, например, когато двете роли не може да бъде по едно време, определен за същия потребител.

Удобства

При проектирането, изпълнението и прилагането на ролевите базиран модел за контрол на достъпа, трябва да се вземат под внимание фактори, които могат да доведат до сериозни загуби на време и пари.

На първо място, "най-различни потребители": на практика в големите организации могат да бъдат доста по-голям брой потребители с уникални привилегии, някои от тях може да бъде на същите позиции, а дори и в една единица. Това го прави по-трудно да се изгради модел за подражание и може да доведе до ситуация, в която всеки потребител се нуждае от своя уникална роля. Такава ситуация може да възникне, когато един служител "отглежда" в рамките на кабинета си или той просто има уникална функция в рамките на тяхната единица. Това може да се превърне в сериозен проблем за системата за контрол на достъп:

• В този случай, е трудно да се дефинира понятието "разумно малка" набор от роли, които са отговорни за основната маса на правата за достъп на потребителите.
• Не е практично да се създаде един и същ брой роли на потребителите - това е еквивалентно на потребителя за контрол на достъпа.

Второ, "твърде много роли": това не винаги е така, но това може да се случи ситуация, в която, когато се свържете към системата за контрол на достъпа има контролирана система, ролята, определена за по-рано, свързани системи, е необходимо да се раздели на няколко други роли, като се вземат предвид всички възможни случаи на употреба, заедно с новата система. Ако има няколко нови системи, една ситуация може да възникне, когато ролите ще бъде повече от потребители.

На трето място, "промяна на задълженията polzovateleyi бизнес реорганизация": дори ако ролеви модел отразява сегашната ситуация в организацията, е необходимо да се поддържа актуална, да следи промените в задълженията на потребителите и да направи бързи промени в пример за подражание.

Четвърто, "цената": това е необходимо да се вземе предвид, че развитието и подкрепата на модел за подражание в края на краищата може да струва повече от ръчно въвеждане. В допълнение, моделът на управление роля изисква по-квалифициран от администратора, който предоставя права.

прилагане на практика,

По-рано видяхме защо управлението на правата на потребителите въз основа на модел за подражание може да бъде сложно и скъпо, а дори и след успешното изпълнение да достави много проблеми едновременно ИТ и бизнеса.

В някои случаи, обаче, въпреки тези функции, осигуряване на достъп на базата на роли се оправдава? На първо място, в една и съща система, където броят на възможните комбинации на човека е доста малък, и в резултат на това, че е лесен за управление на малък брой роли. Всъщност, използването на RBAC отдавна е смятан за най-добрите практики в разработването на приложения, бази данни, сървъри и операционни системи. На второ място, в организации, където достатъчно голям брой потребители имат същите права. Например, един банков касиер, продажбите в мрежите за търговия на дребно и заведения за бързо хранене, счетоводство и т.н. Във всеки от тези примери множество роли достатъчно за осигуряване на достъп до хиляди потребители.

Обобщавайки, можем да кажем следното - RBAC е полезно решение за някои специфични проблеми: управление на потребителите в една директория, или управление на големи групи от потребители със същите права. Но RBAC, като единствен модел на достъп, не е подходящ за по-общия проблем на управлението на правата на голямо разнообразие от потребители и динамичен потребителски достъп в много системи.