Ограничить RDC для изолированных учетных записей с включенным компьютером в зависимости от входящего IP-адреса - доступ только для чтения или доступ для чтения / записи в зависимости от входящего маршрута

Сообщения

1. Ограничить доступ к удаленному рабочему столу для определенных пользователей определенными серверами в доменной среде?
2. Ограничить доступ RDP по IP-адресу

хорошо объясните, как ограничить доступ к компьютеру в зависимости от того, кто пытается войти в систему. Это не позволяет контролировать, какая учетная запись будет использоваться для входа на локальный компьютер. На этой машине учетная запись только для чтения (для подсистемы) и учетная запись ar / w (для подсистемы).

Как я могу контролировать, какие учетные записи могут использоваться, в зависимости от того, откуда поступает запрос RDC?
Нет никакого центрального контроллера AD и т. Д., Поскольку система управляется разными владельцами.

Кроме того, я нахожу в Интернете бесконечные ресурсы, которые хорошо объясняют, как ограничить доступ к компьютеру, в зависимости от того, кто пытается войти в систему, какое может быть альтернативное решение. К сожалению, это не позволяет контролировать, какая учетная запись будет использоваться для входа на локальный компьютер и что будет сделано на этом компьютере. Этот факт поднимает некоторые проблемы безопасности.
Ситуация такова, что у нас есть программное обеспечение для IPC (промышленных ПК), которое позволяет только контролировать, но также и служебное программное обеспечение, которое позволяет изменять доступность поставляемого оборудования. Поскольку в настоящее время мы не можем гарантировать, что используется только определенная учетная запись или приложение, поскольку нам необходимо войти в систему через клиентский портал / сервер терминалов удаленного доступа, мы должны подавать заявку на разрешение на работу каждый раз, когда мы хотим осуществлять мониторинг системы, даже только для передачи данных регистратора. Установка другого IPC не возможна, так как этот конкретный компьютер находится в оффшоре, поэтому мы хотели бы, чтобы это было решено программно.

Вот что нам нравится осознавать:

1. Локальная учетная запись пользователя для чтения и записи для каждого IPC.
   Некоторые учетные записи разрешают использовать только программное обеспечение только для чтения, например, программное обеспечение для мониторинга. Другие учетные записи позволяют использовать больше функционального программного обеспечения вплоть до пакетов, которые могут отключить оборудование.
   По нашему мнению, использование различных учетных записей является наиболее практичным способом, в противном случае местное стороннее программное обеспечение должно устанавливать разрешение в соответствии с политиками Windows.

2. Укажите, какие учетные записи можно использовать.
   Какая учетная запись локального пользователя (или активная настройка политики) зависит только от того, откуда поступает запрос на удаленный доступ.

3. Локальный сервер управления доступом.
   В настоящее время нет центрального контроллера AD и т. Д., Но при необходимости может существовать главный сервер доступа, например RD Gateway Server или BOMGAR Privileged Access для управления разрешением доступа.

4. изолированная операция
   Наши устройства находятся в изолированной сети, которая находится за сетью клиентов. Собственно, самый сложный момент - это узнать, кто запрашивает доступ к нашей изолированной сети. Пока мы придумали эти идеи:

   1. Клиентская сеть сообщает нашей сети, какая учетная запись используется, но это требует индивидуального уточнения связи.
   2. наша сеть считывает IP-адрес клиента и определяет, является ли он доступом для чтения или записи. Клиент должен убедиться, что к нашей сети есть как минимум два разных компьютера. Один из них предназначен для учетных записей с постоянным доступом, а другие для учетных записей с повышенными правами, что может потребовать дополнительного одобрения доступа со стороны клиента.
   3. Если вы не можете запретить вход в систему в качестве администратора на главный сервер, клиент должен управлять учетной записью администратора.

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

Я создаю рисунок, показывающий все это, надеюсь, это поможет