Управление доступом на основе ролей
Ключевым аспектом администрирования облачных служб для организации является управление доступом к облачным ресурсам. Это означает, что у пользователей, которым нужен доступ к определенной службе или одному из ее компонентов, есть соответствующие разрешения, а у остальных пользователей нет. Этот процесс называется управлением идентификацией и доступом (IAM). В Azure, AWS и GCP это процесс обеспечивается с помощью метода, известного как управление доступом на основе ролей (RBAC).
С помощью RBAC пользователям и группам пользователей назначается одна или несколько ролей. Каждая роль имеет описательное имя и использует разрешения для определения действий, которые исполнители роли могут выполнять в задействованных ресурсах. Например, пользователь с ролью "Читатель", определенной для группы ресурсов, может просматривать ресурсы в этой группе ресурсов, но не может изменять или удалять их.
Доступ пользователей к ресурсам управляется с помощью:
- назначенных им ролей;
- ролей, назначенных любым группам, к которым принадлежит пользователь;
- областей ресурсов ролей.
Область ресурсов — это уровень в иерархии облачных ресурсов. Например, в Azure роли могут применяться к отдельным ресурсам, группам ресурсов, целым подпискам (в этом случае разрешения ролей применяются ко всем ресурсам, созданным в рамках данной подписки) или группам подписок. Применяя различные роли к разным областям в иерархии ресурсов, вы можете точно контролировать, кому предоставляются разрешения на те или иные действия в организации.
В примере на рисунке 3.6 показан набор ресурсов, подготовленный в облачной подписке и упорядоченный в две группы ресурсов. Группе пользователей с именем "Инженеры" назначается роль "Читатель", которая позволяет участникам группы просматривать все ресурсы, созданные в подписке. При этом пользователю Аурелия Дайер (Aurelia Dyer) назначается роль "Участник", которая позволяет ей изменять любые ресурсы в группе ресурсов А, а также роль "Владелец", которая позволяет ей удалять ресурс веб-приложения в той же группе ресурсов. Предположим, что Аурелия является участником группы инженеров. Эти разрешения позволяют ей:
- просматривать все ресурсы, созданные в подписке;
- изменять два ресурса в группе ресурсов А, например, изменять параметры конфигурации в веб-приложении 1 или изменять параметры репликации для учетной записи хранения 1;
- удалять ресурс веб-приложения 1 в группе ресурсов А.
Хотя Аурелия может просматривать ресурсы в группе ресурсов B, она не может изменять или удалять их.
Рис. 3.6. RBAC и действующие разрешения.
Учитывая, что пользователю может быть назначено несколько ролей, может возникнуть проблема с обработкой конфликтующих привилегий. В настоящее время основные поставщики облачных служб поддерживают возможность разрешения привилегий в реализациях RBAC, но предоставляют небольшую поддержку возможности запрета привилегий или вовсе не поддерживают ее. (Только Azure поддерживает запрещенные привилегии, и только в ограниченном круге контекстов Если запрещенная привилегия конфликтует с разрешенной, приоритет имеет запрещенная привилегия.) Разрешенные привилегии являются аддитивными, поэтому они не могут конфликтовать друг с другом: привилегии пользователя — это просто сумма различных разрешенных привилегий в каждой применимой области.