WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 23. Управление доступом: методы наиболее успешной практики В этой главе описываются некоторые методы наиболее успешной практики для подготовки ваших разрешений управления доступом. Поскольку у каждой организации есть различный способ осуществить их установки MySQL и контроль, описанные сценарии являются общими руководящими принципами. Следующие сценарии описаны: Открытый: организация с одной или больше DBA. Все пользователи видят, но имеют переменный доступ ко всем проверенным активам. Строгий: организация с несколькими DBA и разработчиками и многими проверенными активами, сгруппированными согласно приложениям и пользователям, которые используют их. У некоторых пользователей в организации есть доступ ко всем проверенным активам, некоторые имеют доступ только к подмножеству активов и не видят актива, который выходит за пределы их обязанностей. Как правило, в этом типе сценария, есть строгое разделение между производством и развитием. Таким образом, у тех ролей, у которых есть полный доступ на активах развития, есть только ограниченный доступ или никакого доступа к производственным активам. Роли, вовлеченные в каждый сценарий, следующие: Database Administrator (DBA): ответственный за правильное функционирование серверов MySQL. По сути, им нужен доступ к данным, собранным по проверенным серверам. В большинстве сценариев DBA может получить доступ к функциональности, такой как советники, обработчики событий и Query Analysis. В то время, как есть роль DBA по умолчанию, включенная в вашу установку, рекомендуется создать отдельную роль DBA-типа для вашей установки. Предопределенная роль DBA существует, чтобы облегчить миграцию от предыдущих версий. Кроме того, невозможно отредактировать роль DBA по умолчанию. В целях этой главы роль DBA взята как SeniorDBA и JuniorDBA. Group/User Administrator: ответственный за пользователя, роль и управление группы. Эта роль определяет, кто имеет доступ к MySQL Enterprise Service Manager и определяет группировку серверов. Пользователи в этой роли DBA типично высокого уровня, системные администраторы или менеджеры проектов. В крупных организациях роль администратора группы может также быть ответственна за управление обработчиками событий, затемнениями событий и Notification Groups. Сильно рекомендуется, чтобы администратора группы назначили во всех установках. Объем разрешений роли администратора группы может измениться, в зависимости от размера организации. В меньших организациях члены этой роли ответственны только за добавление пользователей, ролей и групп. В то время, как в более крупных организациях они также ответственны за управление движением событий с помощью email/SMTP-уведомлений, управление группой и так далее. Роль GroupAdmin это ключевая роль. Это определяется таким способом, которым это не может использоваться самостоятельно. Чтобы добавить группы, пользователей или роли, это должно использоваться в сочетании с ролью, которая дает разрешения верхнего уровня, Server Group и MEM Web Application. Таким образом, для пользователя, чтобы иметь разрешения отредактировать пользователей, роли и группы надо быть членом роли GroupAdmin и другой роли, которая дает зависимые разрешения. Роль GroupAdmin рекомендуется для всех внедрений, кроме самого основного. Developers: ответственный за код, развернутый на активах. По сути, они должны видеть воздействие своего кода по проверенным активам. В производственной среде у разработчиков есть доступ к событиям, Query Analysis, данным графов и так далее. 23.1. Открытые наборы полномочий У открытого внедрения нет определенных для группы ролей. У этого сценария есть следующие ролевые типы: Manager: ответственный за все проверенные активы, конфигурацию советника, конфигурацию группы, анализ запросов, обработку событий и коммуникации. Роль по умолчанию. Полный доступ. DBA: ответственный за проверенные активы, анализ запросов, исследование событий. Следующие пользователи вовлечены в этот сценарий: Manager: ответственный за все проверенные активы. DBA: ответственный за контроль MySQL исследование проблем и решение тех проблем. Роль Manager Эта секция описывает ролевое определение менеджера для открытого внедрения. Пользователи в этой роли это продвинутые пользователи. Они ответственны за формирование всего. Этой роли разрешают выполнить следующие действия: Все возможные действия. Таблица 23.1. Определение роли Manager Доступ Уровень Server Group Administer Экземпляры MySQL Administer Query Analysis Aggregate Data Read-Only Query Analysis Example and Explain Data Read-Only Web Application Login Read-Only MySQL Enterprise Monitor Administer Advisor Configuration Administer Event Blackout Administer Event Handling Administer New Group Creation Administer Settings Administer Users and Roles Administer Пользователи Manager ответственны за формирование порогов советника и определение обработчиков событий и Notification Groups. Notification Groups содержит членов стандартной роли DBA и Senior DBA. У этого пользователя есть разрешение закрыть события из-за Экземпляры MySQL = Administer. Роль DBA Эта секция описывает ролевое определение DBA для открытого внедрения. Пользователи в этой роли контролируют пользователей. Они ответственны за исследование событий и решение вопросов с проверенными серверами MySQL. Этой роли разрешают выполнить следующие действия: Все задачи кроме управления пользователями и редактирования параметров настройки MEM. Таблица 23.2. Определение роли DBA Доступ Уровень Server Group Administer Экземпляры MySQL Administer Query Analysis Aggregate Data Read-Only Query Analysis Example and Explain Data Read-Only Web Application Login Read-Only MySQL Enterprise Monitor Read-Only Advisor Configuration Administer Event Blackout Administer Event Handling Administer New Group Creation Administer Settings None Users and Roles None Возможно в этом открытом внедрении, добавить всех пользователей DBA к роли DBA по умолчанию. Однако, для любой установки рекомендуется иметь четко определенную иерархию пользователей. Особенно для SMTP или уведомлений SNMP, которые, если неуправляемы, могут произвести очень большой объем трафика. Рекомендуется иметь единственную группу старших пользователей, которые управляют советником, обработчиком событий и конфигурацией Notification Group. Все запросы должны пройти тех старших пользователей. Кроме того, невозможно отредактировать роль DBA по умолчанию. Члены роли Пользователей назначают на роли следующим образом: Роль Manager. Координатор/начальник группы. Роль DBA. DBA 23.2. Строгий набор полномочий Строгий сценарий это основанное на группе внедрение. Пользователей назначают на роли с переменным доступом к группам. Этот сценарий сосредотачивается на двух группах, развитии и производстве. Развитие это группа серверов MySQL, где продукт развит и проверен. Производство это группа серверов MySQL, на которых готовое изделие использовано для клиентов. Рис. 23.1. Обзор строгого набора полномочий Пользователи, роли и группы Это внедрение требует следующих групп активов: Development: все активы, используемые развитием и качественными командами, сгруппированы в группе разработки. Production: все активы, использованные для использования клиентом, сгруппированы в производственной группе. Устанавливая агентов, чтобы контролировать активы, критически важно выбрать правильную группу во время процесса установки. Если неправильная группа выбрана или никакая группа не выбрана, активы выходят за пределы объема ролей, определенных здесь, и не могут быть замечены никаким пользователем, кроме тех, кто в ролях SeniorDBA. Это внедрение требует следующих ролевых типов: GroupAdmin: роль в масштабе всей системы. Участники ответственны только за управление пользователями, ролями и группами. Эта роль ограничивается в том смысле, что у нее нет прав Server Group или MEM Web Application. Чтобы получить доступ к UI или создать группы, пользователи, назначенные на эту роль, должны также быть назначены на роли с применимыми разрешениями Server Group (Read-Only или Administer). SeniorDBA: роль в масштабе всей системы. У участников есть доступ ко всем проверенным активам на производстве и группах разработки. Никакие определенные для группы наборы полномочий не заданы. JuniorDBA: у участников есть доступ только для чтения к проверенным активам только в группе разработки. SeniorDev-Development: у участников есть ограниченный доступ к проверенным активам в группе разработки. Членам этой роли нужны разрешения, чтобы смотреть события, данные о Query Analyzer и создать обработчики событий на активах развития. Члены этой роли ответственны за просмотр влияния, которое их код оказывает на работу и существующую функциональность. SeniorDev-Production: те же самые участники, что и SeniorDev-Development, но ограниченные права на проверенных активах. Разрешения только наблюдать, отсутствуют права создавать обработчики событий, устанавливать затемнения или получать доступ к примерам или раскрытию данных в Query Analyzer. Эта роль не включает наблюдения за данными клиентов, но позволяет участникам рассматривать события, произведенные на проверенных активах. Если член этой роли требует, чтобы обработчик событий или порог советника отредактировали на производственной группе, это нужно требовать от члена роли SeniorDBA. JuniorDev-Development: у участников есть доступ только к группе разработки. По большей части их разрешения только для чтения. Они наделены правом смотреть события, данные Query Analyzer и т.д. Это внедрение требует пользователей: DBA Teamlead: управляет командой DBA и имеет полный доступ ко всем проверенным активам. Этот пользователь член ролей SeniorDBA и GroupAdmin. Эта комбинация разрешений предоставляет полный доступ ко всем проверенным активам. Senior DBA: ответственный за проверенные активы. Имеет полный доступ ко всем проверенным активам. Никаких прав управления пользователями. Junior DBA: ответственный за исследование проблем. Права только для чтения на всех активах развития. Никакого доступа к производственным активам. Senior Developers: ответственный за развертывание кода в группе разработки и рассмотрение воздействия на работу и функциональность. Никаких прав управления пользователями, затемнение событий и так далее. Разрешено смотреть события на производственной группе, но не добавлять обработчики событий, группы уведомления и т.п. Junior Developers: ответственный за развертывание кода и просмотр событий в группе разработки. Никакого доступа к производственной группе. Ролевые определения в масштабе всей системы Для каждой из этих ролей выберите System-Wide Permissions во фрейме Core Monitored Assets. Таблица 23.3. Ролевое определение в масштабе всей системы Доступ SeniorDBA GroupAdmin Server Group Administer None Экземпляры MySQL Administer None Query Analysis Aggregate Data Administer None Примеры и раскрытие данных Query Analysis Administer None Web Application Login Read-Only None MySQL Enterprise Monitor Administer None Advisor Configuration Administer None Event Blackout Administer None Event Handling Administer None New Group Creation None Administer Settings Administer None Users and Roles None Administer Членство этих ролей: SeniorDBA: DBA manager и Senior DBA. GroupAdmin: DBA manager и по крайней мере один Senior DBA для избыточности. Роли Development Group Для каждой из этих ролей выберите Group-Specific Permissions во фрейме Core Monitored Assets и Development из выпадающего списка группы. Таблица 23.4. Определение роли Development Group Доступ SeniorDev JuniorDev JuniorDBA Server Group Administer Read-Only Read-Only Экземпляры MySQL Read-Only Read-Only Read-Only Query Analysis Aggregate Data Read-Only Read-Only Read-Only Query Analysis Example and Explain Data Read-Only Read-Only Read-Only Web Application Login Read-Only Read-Only Read-Only MySQL Enterprise Monitor Read-Only Read-Only Read-Only Конфигацрация советников Read-Only Read-Only Read-Only Затенение событий None None None Обработка событий Read-Only None Read-Only Создание новых групп None None None Настройки None None None Пользователи и роли None None None В настоящее время Advisor Configuration и Event Handling глобальные разрешения. Изменения, внесенные на этом уровне, могут затронуть всех пользователей MySQL Enterprise Monitor. По сути, только старшему пользователю с разрешениями в масштабе всей системы, нужно разрешить менять эти настройки. Роли Production Group Для этой роли выберите Group-Specific Permissions во фрейме Core Monitored Assets и Production из выпадающего списка группы. Таблица 23.5. Определение роли Production Group Доступ SeniorDev Server Group Read-Only Экземпляры MySQL Read-Only Query Analysis Aggregate Data None Query Analysis Example and Explain Data None Web Application Login Read-Only MySQL Enterprise Monitor Read-Only Advisor Configuration Read-Only Event Blackout None Event Handling None New Group Creation None Settings None Users and Roles None Распределенные отделы Строгое внедрение также полезно для крупных компаний с глобально распределенными командами, получая доступ к центральным фермам серверов. Это внедрение включает следующее: Ферма серверов компании с DBA и людьми, ответственными за кооперирование с отделами. Отделы с их собственными DBA, разработчиками и так далее. Это внедрение включает следующие отделы, каждый с идентичным набором разрешений: BlueTeam, RedTeam, GreenTeam, YellowTeam и OrangeTeam. Группы должны формироваться для каждого отдела. В этом сценарии BlueGroup, RedGroup, GreenGroup, YellowGroup и OrangeGroup, где каждая группа содержит активы, посвященные своему отделу. Рис. 23.2. Строгий сгруппированный набор полномочий

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.