В расширяющейся организации наряду с ростом численности сотрудников непрерывно растёт количество продуктов, число используемых приложений и ресурсов. Как следствие, появляется необходимость систематизации работы сотрудников, обеспечения контроля сохранности данных и оптимизации затрат. Для достижения этих целей, в частности, настраиваются политики доступа к ресурсам.
Принцип наименьших привилегий
В самом начале, при настройке политик доступа, необходимо проанализировать, кто из сотрудников выполняет какие задачи. Затем, уже при назначении опредёленного уровня доступа сотруднику или группе сотрудников, можно руководствоваться одним из принципов, который успел себя хорошо зарекомендовать, – принципом наименьших привилегий (principle of least privilege (PoLP)). Его суть заключается в том, что доступ к модулю, программе, или ресурсу должен предоставляться сотруднику только если он действительно необходим сотруднику для выполнения своей работы. Преимуществом подобного подхода являются следующие факторы:
- Безопасность. Доступ к ключевым компонентам системы будет только у сотрудников, ответственных за обслуживание того или иного ресурса.
- Повышение стабильности системы. В случае, когда сотрудник пользуется или настраивает только тот ресурс, который ему нужен, исключается вероятность того, что он поменяет настройки в той части системы, которая лежит вне зоны его ответственности.
- Фокус. Сотрудники будут видеть только те ресурсы, с которыми им необходимо работать. То есть ничего лишнего. Как следствие, им будет проще изучить и настроить всё нужное.
- Усиление контроля над затратами по аренде ресурсов. Когда управление тарифными планами программ или ресурсов, а также аренда новых ресурсов, осуществляется только сотрудниками, которые осведомлены о стоимости и текущих системных требованиях (то есть о потреблении), нивелируется вероятность того, что из-за неверно выбранного тарифного плана возникнет перерасход.
При работе с Microsoft Azure Portal также необходимо настраивать политики доступа. Для решения этого вопроса портал предоставляет множество подходов. Из достаточно распространённых следует отметить следующие: RBAC (role-based access control) и ABAC (attribute-based access control).
Настройка прав на уровне ролей
Суть данного подхода в том, что в настраиваемой системе пользователю присваивается роль, которая соответствует его бизнес-роли в компании. На основании этой роли пользователь получает доступ к соответствующим ресурсам. Данный подход более прост в настройке и отлично подходит организациям, в которых роли имеют повторяющийся характер и одинаковый набор ресурсов в рамках роли.
Рассмотрим пример. Есть начальник отдела разработки. Ему нужен полный доступ ко всем ресурсам. У него в подчинении находятся другие разработчики в одной и той же бизнес-роли, с одинаковыми задачами. Их задачи не выходят за рамки доступа к какому-то конкретному ресурсу. В этом случае создаются две роли: Начальник разработки и Разработчики. Роль начальника будет предполагать бóльшие права, более широкий доступ.
Настройка прав на уровне атрибутов
Более сложным в настройке, но одновременно и более гибким, является ABAC-подход. Зачастую именно он помогает решать задачи, не решаемые в рамках RBAC. Например, доступ к ресурсу «A» может получить только разработчик (это роль). Но представим, что необходимо ввести дополнительное условие, что доступ к ресурсу может получить только разработчик, который работает в определённом подразделении. При этом одно подразделение может обслуживать ресурс, а другое не должно иметь к нему доступа. То есть для реализации подобного кейса в настройках системы и ресурса необходимо проставить атрибут, указывающий на то, как разработчик соотносится с данным ресурсом. Например, добавить к ресурсу атрибут «Подразделение 1». В результате «Подразделение 1» сможет видеть ресурс «А», а другие подразделения – нет.
С чего начать настройку Azure Portal
Настройка и добавление новых пользователей начинается непосредственно в Azure Active Directory.
В разделе Roles and Administrators с самого начала присутствует достаточно большой список предсозданных ролей. Если среди существующих ролей не найдётся подходящей, AAD (Azure Active Directory) позволяет, на более высоких тарифных планах, создать собственные роли. Затем необходимо привязать пользователя к Management Group, либо к подписке.
При более гранулярном подходе добавление пользователей и назначение им ролей можно осуществлять непосредственно в самом ресурсе: в разделе Access Control самого ресурса. Можно настроить доступ так, чтобы пользователь мог управлять только одним конкретным ресурсом.
В частности для этого можно назначить пользователю одну из следующих популярных ролей:
- Owner – роль, которая подразумевает наличие полного доступа к ресурсам, включая право делегировать доступ другим.
- Contributor – может создавать и управлять всеми типами ресурсов Azure, но не может открывать доступ другим.
- Reader – может просматривать существующие ресурсы Azure.
Если у пользователя есть доступ к ресурсу, в рамках которого созданы другие ресурсы (к примеру, в рамках Management Group, Subscription, Resource Group), тогда все ресурсы в рамках этого ресурса также будут видны пользователю.
В заключение
Для того чтобы более подробно изучить возможные решения, можно обратиться к документации Microsoft.
Ниже представлено несколько статей, которые мы сочли полезными:
What is Azure role-based access control (Azure RBAC)
Managing access to apps
Create a basic group and add members using Azure Active Directory
Assign administrator and non-administrator roles to users with Azure Active Directory
