Главная Security, Virtualization, Без рубрики Роли, которые мы выбираем…
  • Роли, которые мы выбираем…

    VMware Представьте себе ситуацию, кабинет Гиммлера, в него врывается Мюллер и начинает рыскать по шкафам, хватает папку с документами и убегает. Возможно ли такое при правильном сценарии?

    Используй то, что под рукой и не ищи себе другое.

    Если в вашей компании только один администратор, то дальше можете не читать, доверьтесь администратору и спите спокойно (или наоборот беспокойно), ведь он как ходил везде, имея отмычку от всех дверей, так и будет это делать дальше. И плевать ему, что на столе лежит многопудовая связка новеньких ключиков с бирками. А вот если у вас, к примеру, чертова куча серверов и целая толпа унылого вида красноглазых админов всех мастей и размеров? Что делать тогда? А вот тогда – читать дальше.

    Помните одиозного помощника лорда Мейса? – «Есть ли у вас план, мистер Фикс? — Есть ли у меня план? Есть ли у меня план? Да у меня целых три плана!». В сущности, он был совершенно прав, имея целых три плана.
    А сколько нужно нам для понимания масштабов бедствия и разработки возможных вариантов спасения утопающих, используя силы этих самых утопающих?

    Все те же 3 плана, точнее итерации:

    1. Составьте для себя перечень повседневных задач, которые придется решать. Составьте его тщательно, продуманно, взвешенно. Но я ручаюсь, вы все равно что-нибудь да забудете. Впрочем, к этой работе можно будет вернуться еше раз, на второй итерации.

    2. Чтобы выполнить все то, что вы описали ранее – а что КОНКРЕТНО надо делать? Вот так и распишите все как Петька оперу – про ВСЕХ И ОЧЕНЬ ПОДРОБНО.

    3. Когда с первыми этапами покончено – задумайтесь, а КТО и ГДЕ все это будет делать? Это самый важный и сложный момент во всем вашем безумном предприятии.

    Что получилось в итоге? А в итоге мы получили три важных компонента управления доступа – перечень ролей, перечень конкретных привилегий для каждой роли и, о чудо, МАТРИЦУ ДОСТУПА к информации – мечту любого безопасника от мала до велика.

    Три ореха это уже куча или еще не куча?

    Никогда не используйте встроенные роли кроме системных, таких как в VI, так в vSphere всего 3

    -   No Access (по умолчанию для всех пользователей кому в явном виде не прописан доступ)

    Read Only (роль содержит привилегии на просмотр детальной информации на уровне объекта иерархии)

    -   Administrator (роль содержит все привилегии на уровне объекта иерархии).

    Эти роли не подлежат удалению или изменению, так как для инфраструктуры это может окончиться плачевно.

    Обязательно продумайте, какие функции будут выполнять люди, не создавайте 1 роли которая может все. Очень сомнительна роль «все включено», вы же не вытираете со стола и не моете пол одной и той же тряпкой.

    Несколько слов о роли Administrator. Обычно эта роль назначается администраторам виртуальной инфраструктуры. Таких администраторов, скорее всего, будет несколько и каждый из них будет отвечать только за определенный участок работы, а, следовательно, каждый будет иметь полномочия, которые не соответствуют его функциональным задачам (контроль над всеми серверами ESX и возможность назначения полномочий). Хорошим решением в данном случае было бы создание 2 персонифицированных аккаунтов с ролью Administrator (основной и резервный) что называется на исключительный случай, а для повседневной работы создание специальных ролей для каждого администратора с минимально необходимыми привилегиями согласно функциональным задачам.

    Так же в списке ролей существующих по умолчанию есть еще роли, созданные для ознакомления, как примеры и не более того (в терминах компании VMware).

    VI3:

    1. Resource Pool Administrator
    2. Virtual Machine Power User
    3. Virtual Machine User
    4. VMware Consolidated Backup User
    5. Virtual Machine Administrator
    6. Datacenter Administrator

    vSphere:

    1. Resource Pool Administrator
    2. Virtual Machine Power User
    3. Virtual MachineUser
    4. VMware Consolidated Backup User
    5. Datastore Consumer
    6. Network Consumer

    Несколько слов о роли VMware Consolidated Backup User. Согласно технической документации компании VMware изменение или удаление это роли не допускается.

    Если внимательно посмотреть на то, какие полномочия (привилегии) ставятся в соответствие, большинству ролей приведенных для ознакомления, то можно говорить об избыточности полномочий пользователей, которым будут назначены эти роли.

    Рассмотрим на примере:


    Роль Virtual Machine User (обычно назначается всем рядовым пользователям) обладает 15 полномочиями, среди которых – Global – CancelTask, VirtualMachine – ConsoleInteract, VirtualMachine – SetCDMedia, ScheduledTask – Create, ScheduledTask – Run. Вы уверены в том, что эти полномочия необходимы для работы? Это как в театре, если на сцене в первом акте висит ружьё, то в третьем оно непременно выстрелит.

    Аутентификация пользователей должна производиться с использованием доменных учетных записей, аккаунты от локальных учетных записей, как и аккаунты роли Administrator (основной и резервный) необходимо использовать только в исключительных случаях и хранить в бумажном виде в сейфе.

    Любой доступ к объектам инфраструктуры должен производиться с персонифицированной учетной записи, эта мера залог того, что при инциденте вы сумеете точно определить виновное лицо.

    «Разделяй и властвуй» Николо Макиавелли

    Для управления инфраструктурой виртуализации необходимо создавать роли для выполнения конкретных задач и наделенные минимально необходимыми привилегиями для их выполнения.

    Ролевой механизм насчитывает порядка 110 доступных привилегий.

    Не забывайте о том, что роль, назначенная индивидуальному пользователю для данного объекта, будет иметь приоритет над привилегиями, назначенными групповой ролью; а при наличии нескольких ролей на объект пользователю будут суммированы все привилегии назначенных ролей.

    Назначение ролей администраторам должно производиться от самого старшего объекта иерархии (сверху вниз), а пользователям от самого младшего (снизу вверх) с целью регулирования наследования привилегий для дочерних объектов, назначение наследования полномочий для дочерних объектов необходимо рассматривать индивидуально в каждом конкретном случае.

    Возникает вопрос, а что делать с ролями, существующими по умолчанию для ознакомления? Здесь 2 варианта: либо удалять, либо вносить изменения в эти роли. Выбор решения в каждом конкретном случае будет зависеть от того, насколько полно производится документирование всех изменений вносимых в конфигурацию. Если действия при внесении изменений в разрешения роли, удалении роли или создании новой роли фиксируются в соответствующей документации, то у вас будет возможность следить за матрицей ролей и целесообразностью предоставляемых полномочий администраторам и пользователям. В противном случае, запутавшись в собственных разрешениях и запретах, можно остаться и без доступа к инфраструктуре.

    Мария Сидорова

    http://blog.vadmin.ru

Комментарии

  1. Кто автор статьи то? Мария или Антон?

  2. Подозреваю, что Мария. Просто Антон выкладывал, поэтому он вверху значится.

  3. Автор Мария.

  4. Отличная статья.С юмором.Респект девушке.
    А она соавтор itband или vadmin? Эта тема сейчас набирает обороты а толковой информации совсем мало,хотелось бы знать где следить за публикациями.

  5. Мария – соавтор http://blog.vadmin.ru по теме безопасности

  6. Молодец какая Мария.
    По делу и с доступными аналогиями.

  7. Мораль: бедный Петька архитектор и злобный vmware понаделали ролей, которые для себя открыла Маруся и делится радостью со всем миром…

  8. Мария выбирает ролевые игры… 🙂
    Статья написана хорошим и доступным языком-респект Марии.