Для забезпечення безпеки в System Center 2012 R2 Virtual Machine Manager використовується контроль доступу на основі ролей (Role Based Access Control, RBAC). Принцип дії RBAC полягає в наступному:

Є кілька типів ролей користувача. Кожна роль містить у собі певний набір дозволів, об'єднаних в профіль.Ці дозволи можуть бути застосовані до обраної групи об'єктів - області, яка визначається при створенні ролі. Таким чином, роль користувача складається з трьох компонентів:

• Профіль (profile) - визначає набір дій, які доступні користувачам з цією роллю;
• Область (scope) - визначає набір об'єктів, над якими користувач може виробляти дії;
• Власники ролі (members) - користувачі, яким призначено ця роль.Як власників ролі можна вказувати окремі облікові записи користувачів або групи безпеки.

В System Center 2012 R2 Virtual Machine Manager є п'ять типів ролей:

Administrator

Учасники , яким призначено ця роль, мають необмежені права і можуть виробляти будь-які операції c VMM.Роль Administrator автоматично створюється при розгортанні VMM і може бути тільки одна в домені. Обліковий запис користувача, під якою проводилася установка VMM, автоматично додається в адміністратори.

Користувач з роллю Administrator має право додавати інших користувачів в адміністратори, а також створювати ролі Delegated Administrator, Read-Only Administrator, Tenant Administrator і Self -Service User.

Тільки користувачі з роллю Administrator мають право виробляти інтеграцію сервера оновлень WSUS в VMM, для централізованого отримання оновлень, а також додавати хости і кластера Citrix XenServer для їх управління за допомогою VMM.

Delegated Administrator

Учасники, яким призначено ця роль, мають необмежені права і можуть виробляти будь-які операції c VMM, але тільки в межах відведеної їм області, певної при створенні ролі.Як області може виступати група хостів, приватна хмара або сервер бібліотеки.

Роль Delegated Administrator не створюється за замовчуванням, її необхідно створити вручну. Число ролей Delegated Administrator в одному домені необмежена, можна створити будь-яке потрібне їх кількість, або не створювати зовсім.Члени Delegated Administrator можуть додавати нових користувачів та створювати нові ролі Delegated Administrator, Read-Only Administrator і Tenant Administrator, але знову ж тільки в межах відведеної їм області.

Учасники з роллю Delegated Administrator не можуть змінювати загальні налаштування VMM , а також редагувати роль користувача Administrator.

Read-Only Administrator

Роль Read-Only Administrator, як випливає з назви, призначена виключно для перегляду. Користувачі з цією роллю можуть переглядати будь-які налаштування, а також стан і статус виконання адміністративних завдань, але не мають право вносити будь-які зміни.Як і в попередньому випадку, для Read-Only Administrator при створенні ролі визначається область, в якості якої може бути група хостів або приватна хмара.

Tenant Administrator

Ця роль з'явилася в System Center 2012 SP1. Tenant в перекладі означає орендар, відповідно під роллю Tenant Administrator мається на увазі адміністратор клієнта датацентру, що отримав в оренду певний набір ресурсів, об'єднаний в приватне хмара.У відведеному їм хмарі користувачі з роллю Tenant Administrator можуть підключатися до VMM (з консолі або через веб-портал) розгортати і керувати віртуальними машинами, сервісами та мережами віртуальних машин. Також Tenant Administrator може створювати ролі Self-Service User і управляти виділенням для них ресурсів.

Application Administrator (Self-Service User)

Учасники з роллю Self-Service User мають право підключатися до VMM з консолі або через веб-портал та створювати і керувати віртуальними машинами і сервісами в тих межах, які їм відведені вищестоящими адміністраторами. Користувачі Self-Service User не мають прав на створення будь-яких ролей в VMM.

Примітка. Тільки користувачі з роллю Tenant Administrator і Self-Service User можуть підключатися до VMM через веб-портал самоообслужіванія.

Створення ролей

Для створення нової ролі користувача треба відкрити розділ Settings, перейти на вкладку User Roles і потім клікнути на Create User Role.

Запускається майстер створення ролей.У першому вікні вводимо ім'я і опис ролі.

Вибираємо тип ролі, один з чотирьох. Нагадаю, що роль Administrator ми створити не можемо, вона створюється відразу при установці VMM і може бути тільки одна. Процес створення ролей Read-Only Administrator і Delegated Administrator практично нічим не відрізняється, тому в якості першого прикладу візьмемо створення ролі Delegated Administrator.

Далі тиснемо кнопку «Add» і додаємо користувачів, які будуть власниками даної ролі. Можна вказати як локальних, так і доменних користувачів і групи. На мій погляд, тут правильніше буде використовувати доменні групи безпеки, тому я створив в домені групу SC_FullAdmins, яку і призначу власником даної ролі.

Вибираємо область (Scope), в якій діють повноваження створюваної ролі. Можна вказати в якості області приватне хмара, або дозволити доступ до всіх без винятку хостів.

Примітка. Під приватним хмарою в VMM розуміється якийсь абстрактний набір ресурсів (хости, бібліотеки, мережі, сховища і т.п.), об'єднаний з якого небудь спільною ознакою. У VMM немає приватного хмари за замовчуванням, його треба попередньо створити.

Вказуємо сервера бібліотек, якими дозволено користуватися користувачам з цією роллю.

Вказуємо обліковий запис RunAs Account.Можна створити новий обліковий запис RunAs, або вибрати один з існуючих. RunAs Account вдає із себе контейнер для зберігання облікових даних користувача, що має адміністративні повноваження в обраній галузі. Створювати і редагувати RunAs Account мають право тільки користувачі з роллю Administrator або Delegated Administrator.

Перевіряємо сумарну інформацію і тиснемо кнопку «Finish», запускаючи створення ролі. Якщо цікаво, то по кнопці «View Script» можна подивитися \ зберегти команди PowerShell.

Створення ролі Tenant Administrator принципово відрізняється від попереднього прикладу. Для ролей Read-Only і Delegated Administrator ми вибираємо тільки область, а всі повноваження заздалегідь визначені і незмінні.Роль Tenant Administrator навпаки, дозволяє детально налаштовувати дозволу, обмежувати кількість ресурсів і визначати дії, доступні для користувачів з цією роллю.

Для створення ролі також запускаємо майстер, зі списку вибираємо роль Tenant Administrator.

Додаємо користувачів, яким буде призначена ця роль.

Вибираємо область для створюваної ролі. Зверніть увагу, що в якості області для ролі Tenant Administrator можна вказати тільки приватна хмара. Якщо ви хочете дозволити користувачам з цією роллю налаштовувати і використовувати можливості динамічної оптимізації навантаження (Performance and Resource Optimization, PRO), то треба відзначити чекбокс «Show PRO tips».

Визначаємо квоти на використання ресурсів. Квоту можна задати як в кількісному вираженні, прямо вказавши кількість доступних апаратних ресурсів (CPU, Memory, Storage), так і у відносному (Custom quota). Також можна не прив'язуватися до апаратних засобів, а просто обмежити кількість віртуальних машин (Virtual machines), доступних для даної ролі.

Примітка. Custom quota встановлює квоту на ВМ, грунтуючись на окулярах квоти (points). Окуляри вдають із себе довільне значення, яке призначається шаблоном ВМ на підставі її очікуваного розміру.

Всього є два рівня квот - на всю роль цілком (Role level) і на окремого користувача (Member level).Квоти можна комбінувати, наприклад, на рівні користувача встановимо ліміт в 5 ВМ, а на всю роль виділимо 15 віртуальних машин. Нагадаю, що якщо роль призначена на доменну групу, то для всіх членів цієї групи будуть діяти обмеження одного користувача.

Вказуємо мережу, доступну для користувачів з цією роллю.

Визначаємо додаткові ресурси (профілі обладнання, файлові кулі і т.п.), які користувач зможе використовувати.

Зазначаємо, які операції доступні для цієї ролі. Тут є два рівня дозволів - глобальний (Global permissions) і рівень конкретної області.Повноваження створюваної ролі можуть поширюватися на кілька областей, відповідно можна дозволяти все "оптом", або для кожної області налаштувати окремі дозволи.

Наприклад, для нашої ролі заборонимо видалення віртуальних машин в глобальних налаштуваннях

Але дозволимо видаляти ВМ в приватному хмарі Default.

Окремо визначаємо квоту на створення мереж ВМ.

Додаємо RunAs аккаунт.

Перевіряємо сумарну інформацію і тиснемо Finish. Ще одна роль готова