четверг, 13 августа 2009 г.

Роли, которые мы выбираем…

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

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

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

Помните одиозного помощника лорда Мейса? - «Есть ли у вас план, мистер Фикс? — Есть ли у меня план? Есть ли у меня план? Да у меня целых три плана!». В сущности, он был совершенно прав, имея целых три плана.
А сколько нужно нам для понимания масштабов бедствия и разработки возможных вариантов спасения утопающих, используя силы этих самых утопающих? Все те же 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 варианта: либо удалять, либо вносить изменения в эти роли. Выбор решения в каждом конкретном случае будет зависеть от того, насколько полно производится документирование всех изменений вносимых в конфигурацию. Если действия при внесении изменений в разрешения роли, удалении роли или создании новой роли фиксируются в соответствующей документации, то у вас будет возможность следить за матрицей ролей и целесообразностью предоставляемых полномочий администраторам и пользователям. В противном случае, запутавшись в собственных разрешениях и запретах, можно остаться и без доступа к инфраструктуре.

8 комментариев:

  1. Спасибо, отличная статья!

    ОтветитьУдалить
  2. Прекрасная статья. Спасибо

    ОтветитьУдалить
  3. -комент в плоскости ИБ-
    Проблема ГРАМОТНОГО построения субъектно-объектного доступа существовала, существует и будет существовать пока есть какая-либо СИСТЕМА (будь-то маленькая прикладная система или виртуальная) и наличие персонала (основного и вспмогательного). Конечно, проще всего предоставить пользователю системы максимально полные права /уж точно всё будет работать/, но не будет работать основное требование ИБ - ПРЕДОСТАВЛЕНИЕ МИНИМАЛЬНО НЕОБХОДИМЫХ ПРАВ РАБОТНИКУ ДЛЯ ВЫПОЛНЕНИЯ СВОИХ ОБЯЗАННОСТЕЙ.
    Проблема действительно острая и не теряет своей актуальности, ведь мало настроить - нужно ещё и поддерживать...

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

    Ждем с нетерпением Ваших следующих статей.

    ОтветитьУдалить
  4. Гут. Но для тебя стилистка конечно очень неожиданная.

    Евгений

    ОтветитьУдалить
  5. Друзья, спасибо огромное. Буду стараться и дальше радовать вас интересными статьями.

    ОтветитьУдалить