Зараз я працюю в компанії-вендорі програмного забезпечення, зокрема рішень щодо управління доступом. А мій досвід «з минулого життя» пов'язаний із стороною замовника – великою фінансовою організацією. Тоді наша група контролю доступу в ІБ-департаменті не могла похвалитися великими компетенціями в IdM. Ми багато чого навчалися в процесі, довелося набити купу шишок, щоб побудувати в компанії механізм управління правами користувачів в інформаційних системах.
Об'єднавши свій вистражданий у замовнику досвід із вендорськими знаннями та компетенціями, я хочу поділитися з вами по суті покроковою інструкцією: як створити у великій компанії рольову модель управління доступом і що це дасть на виході. Моя інструкція складається з двох частин: перша – готуємось будувати модель, друга – власне будуємо. Перед вами частина перша, підготовча.
NB Побудова рольової моделі – це, на жаль, результат, а процес. А точніше навіть частина процесу творення у компанії екосистеми управління доступом. Тож налаштуйтеся на гру довгу.
Спочатку визначимося – а що таке управління доступом з урахуванням ролей? Припустимо, є у вас великий банк із десятками, а то й сотнями тисяч співробітників (суб'єктів), у кожного з яких є десятки прав доступу до сотень внутрішньобанківських інформаційних систем (об'єктів). А тепер помножте кількість об'єктів на кількість суб'єктів - саме стільки зв'язків мінімум вам потрібно спочатку побудувати, а потім контролювати. Чи реально це зробити вручну? Звичайно, ні – для вирішення цього завдання і з'явилися ролі.
Роль – це набір повноважень, необхідний користувачеві чи групі користувачів виконання певних робочих завдань. Кожен співробітник може мати одну або кілька ролей, а кожна роль може містити від одного до багатьох повноважень, які дозволені користувачеві в рамках цієї ролі. Ролі можуть бути прив'язані до певних посад, підрозділів чи функціональних завдань працівників.
Ролі зазвичай створюються з окремих повноважень співробітника у кожній інформаційній системі. Потім із ролей кожної системи формуються глобальні бізнес-ролі. Наприклад, бізнес-роль «кредитний менеджер» буде включати кілька окремих ролей в інформаційних системах, які використовуються в клієнтському офісі банку. Скажімо, таких, як основна автоматизована банківська система, касовий модуль, система електронного документообігу, сервіс-менеджер та інших. Бізнес-ролі, як правило, прив'язуються до організаційно-штатної структури – простіше кажучи, до набору підрозділів компанії та посад у них. Так формується глобальна рольова матриця (приклад наводжу в табличці нижче).
Варто зазначити, що побудувати 100% рольову модель, забезпечивши всіма необхідними правами працівників кожної посади у комерційній структурі, просто неможливо. Та це й не потрібне. Адже рольова модель не може бути статичною, тому, що вона залежить від оточення, що постійно змінюється. І від зміни бізнес-діяльності компанії, яка, відповідно, впливає на зміну оргструктури та функціоналу. І від відсутності повного забезпечення ресурсами, і від недотримання посадових інструкцій, і від прагнення прибутку на шкоду безпеці, і багатьох інших чинників. Тому потрібно будувати рольову модель, яка зможе закрити до 80% потреб користувачів у необхідних базових правах при призначенні на посаду. А решта 20% вони зможуть, якщо потрібно, допитувати пізніше за окремими заявками.
Звичайно, ви можете запитати: «А що взагалі не буває 100% рольових моделей?» Ну чому ж, таке зустрічається, наприклад, у некомерційних структурах, які не схильні до частих змін, – у якомусь НДІ. Або в організаціях ВПК із високим рівнем захищеності, де безпека стоїть на першому місці. Буває, і в комерційній структурі, але в рамках окремо-взятого підрозділу, робота якого є досить статичним та передбачуваним процесом.
Головний плюс рольового управління – це спрощення видачі прав, тому що кількість ролей значно менша, ніж користувачів інформаційної системи. Причому, це справедливо для будь-якої галузі.
Візьмемо рітейлову компанію: у ній трудяться тисячі продавців, але набір прав у системі N у них однаковий, і для них буде створено лише одну роль. Прийшов у компанію новий продавець - йому автоматично призначено потрібну роль у системі, в якій вже є всі необхідні повноваження. Так само в один клік можна поміняти права для тисячі продавців разом, наприклад, додати нову опцію формування звіту. Не потрібно робити тисячу операцій, прив'язуючи нове право до кожного облікового запису - достатньо внести цю опцію в роль, і вона з'явиться у всіх продавців одночасно.
Ще одна перевага рольового управління - виключення видачі несумісних повноважень. Тобто співробітник, який має певну роль у системі, не може одночасно мати іншу роль, права якої не повинні поєднуватись з правами у першій. Яскравим прикладом є заборона на суміщення функцій введення та контролю фінансової операції.
Всі, кому цікаво, як взагалі з'явилося рольове керування доступом, можуть
пірнути за екскурсом в історію
Якщо звернутися до історії, то вперше ІТ-спільнота замислилася про методи керування доступом ще у 70-х роках XX століття. Хоча програми були тоді досить простими, але, як і зараз, усім дуже хотілося зручно керувати доступом до них. Надавати, змінювати та контролювати права користувачів – просто щоб легше було розуміти, який доступ має кожен з них. Але в той час не існувало жодних загальних стандартів, розроблялися перші системи управління доступом, і кожна компанія ґрунтувалася на своїх власних уявленнях і правилах.
Наразі вже відомо багато різних моделей управління доступом, але з'явилися вони не відразу. Зупинимося на тих, які зробили відчутний внесок у розвиток цього напряму.
Перша і, мабуть, найпростіша модель – Дискреційне (виборче) керування доступом (DAC – Discretionary access control). Ця модель має на увазі спільне використання прав усіма учасниками процесу доступу. Кожен користувач отримує доступ до конкретних об'єктів чи операцій. По суті, тут безліч суб'єктів прав відповідає безлічі об'єктів. Така модель була визнана надто гнучкою та надто складною для супроводу: списки доступу згодом стають величезними та важко контрольованими.
Друга модель – це Мандатне керування доступом (MAC - Mandatory access control). За цією моделлю кожен користувач отримує доступ до об'єкта відповідно до оформленого допуску до того чи іншого рівня конфіденційності даних. Відповідно об'єкти мають бути категоровані за рівнем конфіденційності. На відміну від першої гнучкої моделі, ця, навпаки, виявилася надто суворою та обмежувальною. Її застосування не виправдовує себе, коли в компанії багато різноманітних інформаційних ресурсів: щоб розмежувати доступ до різних ресурсів, доведеться вводити безліч категорій, які не будуть перетинатися.
У зв'язку з очевидною недосконалістю цих двох методів ІТ-спільнота продовжила розробку моделей, гнучкіших і при цьому більш-менш універсальних для підтримки різних типів організаційних політик контролю доступу. І ось тоді з'явилася третя модель керування доступом на основі ролей! Цей підхід виявився найперспективнішим, оскільки він вимагає як авторизації особистості користувача, а й його робочих функцій у системах.
Першу чітко описану структуру рольової моделі запропонували американські вчені Девід Феррайло та Річард Кун з Національного інституту стандартів та технологій США у 1992 році. Тоді вперше з'явився термін RBAC (Role-based access control). Ці дослідження та описи основних компонентів, а також їх взаємозв'язки лягли в основу чинного до сьогодні стандарту INCITS 359-2012, затвердженого Міжнародним комітетом зі стандартів інформаційних технологій (INCITS).
Стандарт визначає роль як "посадову функцію в контексті організації з деякою пов'язаною семантикою щодо повноважень та відповідальності, покладених на користувача, призначеного на роль". Документ встановлює основні елементи RBAC – користувачі, сесії, ролі, дозволи, операції та об'єкти, а також відносини та взаємозв'язки між ними.
У стандарті дана мінімально необхідна структура для побудови рольової моделі – об'єднання прав у ролі, а потім видача доступу користувачам через ці ролі. Позначено механізми складання ролей з об'єктів та операцій, описано ієрархію ролей та успадкування повноважень. Адже в будь-якій компанії є ролі, що поєднують елементарні повноваження, які необхідні всім співробітникам компанії. Це може бути доступ до електронної пошти, СЕД, корпоративного порталу тощо. Ці повноваження можна включити в одну спільну роль під назвою «співробітник», і не потрібно буде в кожній з ролей вищого рівня перераховувати всі елементарні права щоразу. Досить просто вказати ознаку наслідування ролі «співробітник».
Пізніше стандарт був доповнений новими атрибутами доступу, пов'язаними з оточенням, що постійно змінюється. Додалася можливість запровадження статичних та динамічних обмежень. Статичні мають на увазі неможливість поєднання ролей (те саме введення і контроль операцій, що згадувався вище). Динамічні обмеження можуть визначатися мінливими параметрами, наприклад, часом (робочі/неробочі години або дні), місцезнаходженням (офіс/будинок) тощо.
Окремо варто сказати про керування доступом на основі атрибутів (ABAC - Attribute-based access control). Підхід будується на доступі за допомогою правил спільного використання атрибутів. Ця модель може використовуватися окремо, але часто вона активно доповнює класичну рольову: до певної ролі можна додавати атрибути користувачів, ресурсів і пристроїв, а також часу або розташування. Це дозволяє використовувати менше ролей, вводити додаткові обмеження та зробити доступ мінімально достатнім, а отже, підвищити безпеку.
Наприклад, бухгалтеру можна дозволити доступ до рахунків, якщо він працює у певному регіоні. Тоді місцезнаходження фахівця порівнюватиметься з певним еталонним значенням. Або можна дати доступ до рахунків, лише якщо користувач авторизується з пристрою, внесеного в реєстр дозволених. Хороше доповнення до рольової моделі, але самостійно використовується нечасто через необхідність створювати багато правил та таблиць дозволів чи обмежень.
Наведу приклад застосування ABAC із мого «минулого життя». У нашому банку було кілька філій. Співробітники клієнтських офісів у цих філіях виконували абсолютно однакові операції, але мали працювати в основній системі тільки з рахунками свого регіону. Спочатку ми почали створювати окремі ролі для кожного регіону – і таких ролей з функціоналом, що повторюється, але з доступом до різних рахунків вийшло ну дуже багато! Тоді, використовуючи атрибут місцезнаходження для користувача та зв'язавши його з конкретним діапазоном рахунків для перевірки, ми значно зменшили кількість ролей у системі. В результаті залишилися ролі тільки для однієї філії, яка тиражувалася на відповідні посади в усіх інших територіальних підрозділах банку.
А тепер поговоримо про необхідні підготовчі кроки, без яких просто неможливо побудувати працюючу рольову модель.
Крок 1. Створюємо функціональну модель
Почати варто зі створення функціональної моделі – верхньорівневого документа, в якому детально описано функціонал кожного підрозділу та кожної посади. Як правило, інформація до нього потрапляє з різних документів: посадових інструкцій та положень щодо окремих підрозділів – відділів, управлінь, департаментів. Функціональна модель має бути узгоджена з усіма зацікавленими підрозділами (бізнес, внутрішній контроль, безпека) та затверджена керівництвом компанії. Навіщо потрібен цей документ? Для того щоб рольова модель могла на нього посилатися. Наприклад, ви збираєтеся будувати рольову модель на основі вже наявних прав співробітників – вивантажених із системи та «приведених до єдиного знаменника». Тоді за погодженні отриманих ролей з бізнес-власником системи можна послатися на конкретний пункт функціональної моделі, виходячи з якого у роль включається те чи інше право.
Крок 2. Аудуємо ІТ-системи та складаємо план пріорітизації
На другому етапі слід провести аудит ІТ-систем, щоб розібратися, як організовано доступ до них. Наприклад, у моїй фінансовій компанії експлуатувалося кілька сотень інформаційних систем. У всіх системах були деякі зачатки рольового управління, здебільшого – якісь ролі, але в основному на папері або в довіднику системи – вони давно застаріли, і доступ до них лунав за фактичними запитами користувачів. Звичайно, побудувати рольову модель відразу в декількох сотнях систем просто неможливо, треба з чогось починати. Ми здійснили поглиблений аналіз процесу управління доступом, щоб визначити рівень його зрілості. У процесі аналізу виробили критерії пріорітизації інформаційних систем – критичність, готовність, плани щодо виведення з експлуатації тощо. З їх допомогою вибудували черговість розробки/актуалізації рольових моделей для цих систем. А потім включили рольові моделі в план з інтеграції з рішенням Identity Management, щоб автоматизувати керування доступом.
Отже, як визначити критичність системи? Дайте відповідь на такі питання:
- Чи пов'язана система з операційними процесами, від яких залежить основна діяльність підприємства?
- Чи вплине порушення функціонування системи на цілісність активів компанії?
- Яким є максимально допустимий час простою системи, досягнувши якого неможливо відновити діяльність, після переривання?
- Чи може порушення цілісності інформації в системі призвести до незворотних наслідків як фінансових, так і репутаційних?
- Критичність до шахрайства. Наявність функціоналу, за недостатнього контролю якого, можливе здійснення внутрішніх/зовнішніх шахрайських дій;
- Які вимоги законодавства, а також внутрішні правила та процедури до цих систем? Чи будуть штрафи з боку регуляторів за недотримання?
У своїй фінансовій компанії ми провели аудит так. Керівництво розробило процедуру аудиту Access Right Review, щоб розібратися з існуючими користувачами та правами спочатку у тих інформаційних системах, які потрапили до списку найпріоритетніших. Власником цього процесу було призначено підрозділ безпеки. Але для отримання повної картини з правами доступу в компанії необхідно було підключити до підрозділу ІТ і бізнесу. І ось тут почалися суперечки, непорозуміння, а іноді навіть саботаж: ніхто не хоче відриватися від своїх поточних обов'язків та вплутуватися в якісь, на перший погляд, незрозумілі активності.
NB Великі компанії з розвиненими ІТ-процесами, напевно, знайомі з процедурою ІТ-аудиту - IT general controls (ITGС), який дозволяє виявити недоліки в ІТ-процесах і налагодити контроль так, щоб поліпшити процеси відповідно до best practice (ITIL, COBIT, IT Governance та ін.) Такий аудит дозволяє ІТ та бізнесу краще зрозуміти один одного та виробити спільну стратегію розвитку, проаналізувати ризики, оптимізувати витрати, виробити більш ефективні підходи в роботі.
Одним із напрямків аудиту є визначення параметрів логічного та фізичного доступу до інформаційних систем. Отримані дані взяли за основу для подальшого використання при побудові рольової моделі. В результаті такого аудиту у нас з'явився реєстр ІТ-систем, в якому було визначено їхні технічні параметри та надано описи. Крім того, для кожної системи було визначено власника від бізнес-напрямку, на користь якого вона експлуатувалася: саме він відповідав за бізнес-процеси, які ця система обслуговувала. Також було призначено менеджера ІТ-служби, відповідального за технічну реалізацію потреб бізнесу в конкретній ІС. Були зафіксовані найкритичніші для компанії системи та їх технічні параметри, терміни введення та виведення з експлуатації та ін. Ці параметри дуже допомогли у процесі підготовки до побудови рольової моделі.
Крок 3 Створюємо методологію
Запорука успіху будь-якої справи – правильно вибраний метод. Тому і для побудови рольової моделі, і для проведення аудиту нам потрібно створити методологію, в якій ми опишемо взаємодію між підрозділами, закріпимо відповідальність у регламентах компанії тощо.
Для початку потрібно дослідити всі наявні документи, які встановлюють порядок надання доступу та прав. По-хорошому, процеси мають бути документовані на кількох рівнях:
- загальні корпоративні вимоги;
- вимоги до областей ІБ (залежать від напрямів діяльності організації);
- вимоги до технологічних процесів (інструкції, матриці доступу, методичні вказівки, вимоги до конфігурацій).
У своїй фінансовій компанії ми виявили багато застарілих документів – довелося навести їх відповідно до нових процесів, що впроваджуються.
За наказом керівництва було створено робочу групу, до якої увійшли представники напрямів безпеки, ІТ, бізнесу та внутрішнього контролю. У наказі були позначені цілі створення групи, напрямок діяльності, термін існування та відповідальні від кожної сторони. Крім того, ми розробили методику проведення аудиту та порядок побудови рольової моделі: їх узгодили всі відповідальні представники напрямків та затвердило керівництво компанії.
Документи, що описують порядок проведення робіт, терміни, відповідальність тощо. - Запорука того, що на шляху до заповітної мети, яка спочатку не всім очевидна, ні в кого не виникне питань «а для чого ми це робимо, а навіщо це треба і т.п.» і не буде можливості "зіскочити" або загальмувати процес.
Крок 4. Фіксуємо параметри існуючої моделі керування доступом
Складаємо так званий паспорт системи в частині управління доступом. По суті, це опитувальник щодо конкретної інформаційної системи, в якому зафіксовано всі алгоритми керування доступом до неї. Компанії, які вже впроваджували в себе рішення класу IdM, напевно, знайомі з подібним опитувальником, оскільки саме з нього починається дослідження систем.
Частина параметрів про систему та власників перетекла до опитувальника з реєстру ІТ (див. крок 2, аудит), але додалися і нові:
- як здійснюється управління обліковими записами (безпосередньо в БД або через програмні інтерфейси);
- як користувачі виконують вхід до системи (за допомогою окремого облікового запису або з використанням облікового запису AD, LDAP або ін.);
- які рівні доступу до системи використовуються (рівень застосування, системний рівень, використання системою мережевих файлових ресурсів);
- опис та параметри серверів, на яких працює система;
- які операції з управління обліковими записами підтримуються (блокування, перейменування тощо);
- за якими алгоритмами чи правилами формується ідентифікатор користувача системи;
- за яким атрибутом можна встановити зв'язок із записом про співробітника в кадровій системі (ПІБ, табельний номер або ін.);
- всі можливі атрибути облікового запису та правила їх заповнення;
- які права доступу існують у системі (ролі, групи, атомарні права та ін., чи є вкладені чи ієрархічні права);
- механізми поділу прав доступу (за посадами, підрозділами, функціоналом та ін.);
- чи є у системі правила розмежування прав (SOD – Segregation of Duties), і як вони працюють;
- як обробляються у системі події відсутності, перекладу, звільнення, оновлення даних про співробітників тощо.
Цей список можна продовжити з деталізацією за різними параметрами та іншими об'єктами, які задіяні в процесі керування доступом.
Крок 5. Створюємо бізнес-орієнтований опис повноважень
Ще один документ, який нам знадобиться при побудові рольової моделі, – це довідник з усіх можливих повноважень (прав), які можна надати користувачам в інформаційній системі з детальним описом бізнес-функції, яка за цим стоїть. Часто повноваження в системі зашифровані певними найменуваннями, що складаються з літер та цифр, і співробітники бізнесу не можуть розібратися, що за цими символами. Тоді вони йдуть до ІТ-служби, а там… теж не можуть відповісти на запитання, наприклад, з прав, що рідко використовуються. Тоді доводиться проводити додаткове тестування.
Добре, якщо бізнес-опис вже є чи навіть є об'єднання цих прав у групи та ролі. Для деяких додатків найкращою практикою є створення такого довідника ще на етапі їх розробки. Але таке зустрічається нечасто, тому знову йдемо в ІТ-підрозділ, щоб зібрати інформацію про всі можливі права та їх описати. Наш довідник у підсумку міститиме таке:
- найменування повноваження, включаючи об'єкт, до якого застосовується право доступу;
- дію, що дозволяється робити з об'єктом (перегляд, зміна тощо, можливість обмеження, наприклад, за територіальною ознакою або групою клієнтів);
- код повноваження (код та ім'я функції/запиту системи, які можна виконати з використанням повноваження);
- опис повноваження (докладний опис дій у ІС при застосуванні повноваження та їх наслідків для процесу;
- статус повноваження: "Активно" (якщо повноваження призначено хоча б одному користувачеві) або "Не активне" (якщо повноваження не використовується).
Крок 6 Вивантажуємо з систем дані про користувачів та права та зіставляємо з кадровим джерелом
На заключному етапі підготовки потрібно вивантажити дані з інформаційних систем про всіх користувачів та права, які вони мають на даний момент. Тут можливі два сценарії. Перший: підрозділ безпеки має доступ безпосередньо в систему і має засоби вивантаження відповідних звітів, що буває нечасто, але дуже зручно. Другий: надсилаємо запит до ІТ на отримання звітів у потрібному форматі. Практика показує: домовитися з ІТ та отримати необхідні дані з першого разу не вдається. Потрібно зробити кілька підходів, доки інформація буде отримана у потрібному вигляді та форматі.
Які дані необхідно вивантажити:
- Найменування облікового запису
- ПІБ працівника, за яким вона закріплена
- Статус (активна або заблокована)
- Дата створення облікового запису
- Дата останнього використання
- Список доступних прав/груп/ролей
Отже, ми отримали вивантаження із системи з усіма користувачами та з усіма правами, які їм надано. І одразу відклали убік усі заблоковані обліки, оскільки робота з побудови рольової моделі вестиметься лише з активних користувачів.
Потім, якщо у вас в компанії немає автоматизованих засобів закриття доступу звільненим співробітникам (таке нерідко зустрічається) або є клаптева автоматизація, яка не завжди коректно спрацьовує, потрібно виявити всі «мертві душі». Йдеться про облікові записи вже звільнених співробітників, права яких з якоїсь причини не заблоковані – їх треба заблокувати. Для цього зіставляємо вивантажені дані із кадровим джерелом. Кадрове вивантаження теж потрібно попередньо отримати у підрозділу, який веде кадрову базу.
Окремо необхідно відкласти облікові записи, власники яких не знайшлися в кадровій базі, не закріплені ні за ким, тобто безхазяйні. За цим списком нам знадобиться дата останнього використання: якщо вона досить свіжа, то все ж таки доведеться пошукати власників. Сюди можуть ставитися облікові записи зовнішніх підрядників або службові обліки, ні за ким не закріплені, але пов'язані з будь-якими процесами. Для з'ясування належності облік можна розіслати по всіх підрозділах листи з проханням відгукнутися. Коли власники знайдуться, вносимо дані про них у систему: таким чином усі діючі обліки упізнані, а решту блокуємо.
Як тільки наші вивантаження очищені від зайвих записів і залишилися одні активні обліки, можна починати побудову рольової моделі за конкретною інформаційною системою. Але про це я розповім уже у наступній статті.
Автор: Людмила Севастьянова, менеджер з просування Solar inRights
Джерело: habr.com