ВМ с управляемой идентификацией и ограничением IP, кто победит?

Question

У меня мало сомнений в Azure:

1. Если у меня есть 2 виртуальные машины с управляемой идентификацией, настроенные для каждой из них, и если IP-адреса этих 2 виртуальных машин могут общаться друг с другом (то есть NSG имеютправило, разрешающее сетевую связь), но RBAC настроен на запрет доступа в ARM, смогут ли они общаться? Я полагаю, нет, правильно? В угловом сценарии, если VM1 скомпрометирована, правильно ли говорить, что никогда не будет никакого взаимодействия с VM2, потому что RBAC не позволяет.
2. Похоже ли это поведение на то, что происходит с ролями и разрешениями AWS IAM?
3. Если я назначаю роль для VM1, подключаюсь к VM2, а затем в VM2 я запрещаю доступ из VM1, какой операторвыигрывает?

Спасибо !!!

Answer 1

Если VM1 скомпрометирована, правильно ли говорить, что никогда не будет никакого взаимодействия с VM2, потому что RBAC не позволяет

Не совсем, нет. RBAC полностью отделен от доступа к сети. Единственное, что связывает удостоверения со связью, - это то, что иногда вам нужно разрешить доступ к сети, если одному серверу нужно пройти проверку подлинности на другом с использованием принципала Azure Active Directory. Но их не следует путать.

Управляемое удостоверение - это, в основном, учетная запись компьютера, которая находится в Azure AD, точно так же, как учетная запись компьютера существует в вашей стандартной локальной Active Directory, которая необходима для разрешения компьютера. аутентифицировать пользователей, которые пытаются войти на сервер / рабочую станцию. Иногда у вас могут быть процессы, такие как службы Windows, работающие в контексте SYSTEM (выполняющиеся как учетная запись компьютера), которым требуется доступ к сетевым ресурсам, а контроль доступа позволяет предоставлять или запрещать доступ с помощью Active Directory.

Если машина Aимеет сетевой доступ к компьютеру B, и он скомпрометирован из-за уязвимости в IIS, например, вы могли явно запретить все разрешения от компьютера A к компьютеру B, но если на машине B также работает та же версия IIS, и машина A можетподключиться к нему, тогда RBAC не поможет.

Похоже ли это поведение на поведение ролей и разрешений AWS IAM?

Я не специалист по AWS, ноЯ собираюсь сказать, что, вероятно, это то же самое поведение, но опять-таки IAM и контроль доступа к сети - это не одно и то же.

Если я назначу роль VM1, то поговорим с VM2, а затем с VM2. я запрещаю доступ с VM1, какой оператор выигрывает?

На какую роль вы ссылаетесь? Доступ к сети осуществляется в NSG или брандмауэре, и роли распределяются между разрешениями, которые влияют на разрешения Windows в VM2 (разрешения ReFS / NTFS / проверка подлинности Windows и т. Д.). Единственный способ предоставить любой доступ к VM2 из VM1 с ролями - это назначить VM1 роль «Администратор облачного устройства». Любой получатель этой роли добавляется в группу локальных администраторов всех присоединенных компьютеров Azure AD. По умолчанию машина, подключенная к Azure AD, не имеет прав доступа к ресурсам других машин, за исключением, возможно, перечисления общих ресурсов на компьютере. Если у вас есть общий ресурс на компьютере, который разрешает доступ всем или доменным компьютерам, то да, машина может получить к нему доступ, но по умолчанию такие общие папки не открываются на компьютере с Windows.

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

Answer 2

Спасибо. Я согласен, что уровень IAM и IP-сети - это совершенно разные вещи, но только потому, что Azure является однородной экосистемой, любой ресурс Azure, который можно определить в Azure-AD, также можно связать с разрешением / ролью IAM. он расположен поверх сетевых разрешений, предоставляемых списками ACL IP, поэтому в действительности мы имеем двойную защиту. Таким образом, если мы оставим позади пример VM1-VM2 выше, который является угловым случаем, и мы рассмотрим вместо этого другой пример: виртуальная машина VM1, которая взаимодействует с учетной записью хранения SA2. Если VM1 скомпрометирован, мне понадобится и то, и другое, чтобы иметь доступ с правами доступа к роли SA2, такой как " Устройство чтения / записи данных BLOB-объектов хранилища " и IP-доступ из VM1, чтобы получить доступ к данным в SA2,верный? В целом, я думаю, что роли IAM гораздо более детализированы, чем наличие списков ACL IP, поэтому в определения ролей IAM следует вносить дополнительную должную осмотрительность, а IP-адреса используются только на сетевом уровне для предотвращения повсеместного доступа из Интернета.

Если машина A имеет сетевой доступ к машине B, и она скомпрометирована из-за> уязвимости в IIS, например, возможно, вы явно запретили все разрешения> для машины A на машину B, но если машина B также запускает ту же версиюIIS и> машина A могут подключиться к нему, тогда RBAC не поможет.

Что касается этого примера, я не совсем на 100% понимаю, что вы имели в виду: да, если VMB запускает ту же версию IIS, я мог бы такжескомпрометировать этот вариант, но если VMB использует более новую версию, мне все равно потребуются и IP, и IAM (хотя, как вы сказали, особой роли для доступа к виртуальным машинам не существует).