Вопросы безопасности JEA

JEA помогает повысить уровень безопасности, уменьшая количество постоянных администраторов на компьютерах. JEA использует конфигурацию сеанса PowerShell для создания новой точки входа для пользователей для управления системой. Пользователям, которым требуются повышенные привилегии, но не неограниченный доступ к компьютеру для выполнения административных задач, можно предоставить доступ к конечной точке JEA. Так как JEA позволяет этим пользователям выполнять административные команды без полного доступа администратора, вы можете удалить этих пользователей из групп безопасности с высоким уровнем привилегий.

учетная запись Run-As

Каждая конечная точка JEA имеет назначенную учетную запись запуска от имени , в которой выполняются действия подключающегося пользователя. Эта учетная запись настраивается в файле конфигурации сеанса, и выбранная учетная запись имеет значительное влияние на безопасность конечной точки.

Виртуальные учетные записи — это рекомендуемый способ настройки учетной записи запуска от имени . Виртуальные учетные записи — это временные локальные учетные записи, созданные для подключающегося пользователя, которые будут использоваться в течение сеанса JEA. После завершения сеанса виртуальная учетная запись будет уничтожена и больше не может использоваться. Подключающийся пользователь не знает учетные данные для виртуальной учетной записи. Виртуальная учетная запись не может использоваться для доступа к системе с помощью других средств, таких как удаленный рабочий стол или не ограниченная конечная точка PowerShell.

По умолчанию виртуальные учетные записи являются членами локальной группы администраторов на компьютере. Это членство дает им полные права на управление любым элементом в системе, но нет прав на управление ресурсами в сети. Когда пользователь подключается к другим компьютерам из сеанса JEA, контекст пользователя — это учетная запись локального компьютера, а не виртуальная учетная запись.

Контроллеры домена являются особым случаем, так как не существует локальной группы администраторов . Вместо этого виртуальные учетные записи принадлежат администраторам домена и могут управлять службами каталогов на контроллере домена. Идентификация домена по-прежнему ограничена для использования на контроллере домена, где был инстанцирован сеанс JEA. Любой сетевой доступ, как представляется, исходит из объекта компьютера контроллера домена.

В обоих случаях вы можете назначить виртуальную учетную запись определенным группам безопасности, особенно если задача может выполняться без привилегий локального или администратора домена. Если у вас уже есть группа безопасности, определенная для администраторов, предоставьте этой группе членство в виртуальной учетной записи. Членство в группах для виртуальных учетных записей ограничено локальными группами безопасности на рабочих станциях и серверах-членах. На контроллерах домена виртуальные учетные записи должны быть членами групп безопасности домена. После добавления виртуальной учетной записи в одну или несколько групп безопасности она больше не принадлежит группам по умолчанию (локальным или администраторам домена).

В следующей таблице приведены возможные параметры конфигурации и полученные разрешения для виртуальных учетных записей:

Тип компьютера	Конфигурация группы виртуальных учетных записей	Контекст локального пользователя	Контекст сетевого пользователя
Контроллер домена	По умолчанию	Пользователь домена, член `<DOMAIN>\Domain Admins`	Учетная запись компьютера
Контроллер домена	Группы доменов A и B	Пользователь домена, член `<DOMAIN>\A`, `<DOMAIN>\B`	Учетная запись компьютера
Сервер-член или рабочая станция	По умолчанию	Локальный пользователь, член `BUILTIN\Administrators`	Учетная запись компьютера
Сервер-член или рабочая станция	Локальные группы C и D	Местный пользователь, член `<COMPUTER>\C` и `<COMPUTER>\D`	Учетная запись компьютера

При просмотре журналов событий аудита безопасности и приложений вы увидите, что каждый сеанс пользователя JEA имеет уникальную виртуальную учетную запись. Эта уникальная учетная запись помогает отслеживать действия пользователей в конечной точке JEA обратно исходному пользователю, выполнившему команду. Имена виртуальных учетных записей соответствуют форматуWinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName>, например, если пользователь Алиса в домене Contoso перезапускает службу в конечной точке JEA, имя пользователя, связанное с любыми событиями диспетчера управления службами, будет.WinRM Virtual Users\WinRM_VA_1_contoso_alice

Учетные записи служб, управляемые группой (gMSAs), полезны, если сервер-член должен иметь доступ к сетевым ресурсам в сеансе JEA. Например, если конечная точка JEA используется для управления доступом к службе REST API, размещенной на другом компьютере. Легко писать функции для вызова REST API, но для проверки подлинности с помощью API требуется сетевое удостоверение. Использование учетной записи службы, управляемой группой, обеспечивает возможность второго прыжка при сохранении контроля над тем, какие компьютеры могут использовать учетную запись. Членство в группе безопасности (локальном или домене) gMSA определило действующие разрешения для учетной записи gMSA.

Когда конечная точка JEA настроена для использования gMSA, все действия пользователей JEA выглядят так, как будто выполняются под одной и той же учетной записью gMSA. Единственным способом трассировки действий до определенного пользователя является определение набора команд, выполняемых в расшифровке сеанса PowerShell.

Учетные данные pass-through используются, если вы не указываете учетную запись выполнения от имени. PowerShell использует учетные данные подключающегося пользователя для выполнения команд на удаленном сервере. Чтобы использовать сквозные учетные данные, необходимо предоставить пользователю прямой доступ к привилегированным группам управления. Эта конфигурация не рекомендуется для JEA. Если у подключающегося пользователя уже есть права администратора, они могут обойти JEA и управлять системой с помощью других методов доступа.

Учетные записи "стандартного запуска от имени" позволяют указать любую учетную запись пользователя, от имени которой выполняется весь сеанс PowerShell. Конфигурации сеансов, использующие фиксированные учетные записи запуска от имени (с параметром ), не поддерживают JEA. Определения ролей больше не работают должным образом. Каждому пользователю, авторизованному для доступа к конечной точке, назначается одна и та же роль.

Не следует использовать RunAsCredential в конечной точке JEA, так как трудно отслеживать действия с конкретными пользователями и не поддерживает сопоставление пользователей с ролями.

ACL для конечной точки WinRM

Как и в случае с обычными конечными точками удаленного взаимодействия PowerShell, каждая конечная точка JEA имеет отдельный список управления доступом (ACL), который управляет проверкой подлинности с помощью конечной точки JEA. При неправильной настройке доверенные пользователи могут не иметь доступа к конечной точке JEA, а у ненадежных пользователей может быть доступ. ACL WinRM не влияет на сопоставление пользователей с ролями JEA. Сопоставление управляется полем RoleDefinitions в файле конфигурации сеанса, используемом для регистрации конечной точки.

По умолчанию, когда конечная точка JEA имеет несколько возможностей ролей, ACL WinRM настроена для предоставления доступа ко всем сопоставленным пользователям. Например, сеанс JEA, настроенный с помощью следующих команд, предоставляет полный доступ к CONTOSO\JEA_Lev1 и CONTOSO\JEA_Lev2.

$newPSSessionConfigurationFileSplat = @{
    Path = '.\jea.pssc'
    SessionType = 'RestrictedRemoteServer'
    RoleDefinitions = @{
        'CONTOSO\JEA_Lev1' = 'Lev1Role'
        'CONTOSO\JEA_Lev2' = 'Lev2Role'
    }
    RunAsVirtualAccount = $true
}
New-PSSessionConfigurationFile @newPSSessionConfigurationFileSplat
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Вы можете выполнять аудит разрешений пользователей с помощью командлета Get-PSSessionConfiguration .

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

Чтобы изменить доступ пользователей, выполните Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI интерактивный запрос или Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> обновите разрешения. Пользователям необходимы права Invoke для доступа к точке входа JEA.

Можно создать конечную точку JEA, которая не сопоставляет каждому пользователю с доступом заданную роль. Эти пользователи могут начинать сеанс JEA, но имеют доступ только к предусмотренным командлетам по умолчанию. Вы можете проверить разрешения пользователей в конечной точке JEA, выполнив команду Get-PSSessionCapability. Дополнительные сведения см. в разделе "Аудит и отчеты" для JEA.

Роли с наименьшими привилегиями

При разработке ролей JEA важно помнить, что виртуальные и групповые учетные записи служб, работающие за кулисами, могут иметь неограниченный доступ к локальному компьютеру. Возможности роли JEA помогают ограничить команды и приложения, которые могут выполняться в этом привилегированном контексте. Неправильно разработанные роли могут разрешать опасные команды, которые могут позволить пользователю выйти из границ JEA или получить доступ к конфиденциальной информации.

Например, рассмотрим следующую запись возможностей роли:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

Эта возможность роли позволяет пользователям запускать командлет PowerShell с существительным Process из модуля Microsoft.PowerShell.Management. Пользователям может потребоваться доступ к командлетам, чтобы Get-Process посмотреть, какие приложения работают в системе, и Stop-Process завершить работу приложений, которые не отвечают. Однако эта запись также позволяет Start-Processиспользовать для запуска произвольной программы с полными разрешениями администратора. Программа не должна быть установлена локально в системе. Подключенный пользователь может запустить программу из общей папки, которая предоставляет пользователям права локального администратора, запускает вредоносные программы и многое другое.

Более безопасная версия этой же возможности роли будет выглядеть следующим образом:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

Избегайте использования подстановочных знаков в возможностях ролей. Не забудьте регулярно проверять действующие разрешения пользователей, чтобы узнать, какие команды доступны пользователю. Дополнительные сведения см. в разделе " Проверка эффективных прав " статьи "Аудит и отчетность по JEA ".

JEA не защищает от администраторов

Одним из основных принципов JEA является то, что он позволяет неадминистраторам выполнять некоторые административные задачи. JEA не защищает пользователей, у которых уже есть права администратора. Пользователи, которые принадлежат администраторам домена, локальным администраторам или другим группам с высоким уровнем привилегий, могут обойти защиту JEA другими способами. Например, они могут выполнять вход с помощью RDP, использовать удаленные консоли MMC или подключаться к не ограниченным конечным точкам PowerShell. Кроме того, локальный администратор в системе может изменить конфигурации JEA, чтобы добавить дополнительных пользователей или изменить возможность роли, чтобы расширить область действия пользователя в сеансе JEA. Важно оценить расширенные разрешения пользователей JEA, чтобы узнать, существуют ли другие способы получения привилегированного доступа к системе.

Помимо использования JEA для регулярного ежедневного обслуживания, обычно используется система управления привилегированным доступом. Эти системы позволяют назначенным пользователям временно стать локальным администратором только после завершения рабочего процесса, который документирует использование этих разрешений.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-01-26

Поделиться через

Вопросы безопасности JEA

учетная запись Run-As

ACL для конечной точки WinRM

Роли с наименьшими привилегиями

Рекомендации по лучшим практикам

Ограничение использования и возможностей поставщиков PowerShell

Не разрешайте команды, которые могут создавать новые пространства выполнения.

Не разрешайте командлет Trace-Command.

Не создавайте собственные реализации прокси-сервера для ограниченных команд.

JEA не защищает от администраторов

Обратная связь

Дополнительные ресурсы

Не разрешайте командлет `Trace-Command`.