Возможности роли JEA

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

Определение разрешенных команд

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

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

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

Примеры потенциально опасных команд

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

Это важно

Основные сведения, необходимые для успеха пользователей: Команды в сеансе JEA часто выполняются с повышенными привилегиями.

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

Риск: Предоставление подключающемуся пользователю привилегий администратора для обхода JEA

Пример:
```
Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators'
```
сопутствующие команды:
- Add-ADGroupMember
- Add-LocalGroupMember
- net.exe
- dsadd.exe
риск: выполнение произвольного кода, например вредоносных программ, эксплойтов или пользовательских скриптов для обхода защиты

Пример:
```
Start-Process -FilePath '\\san\share\malware.exe'
```
сопутствующие команды:
- Start-Process
- New-Service
- Invoke-Item
- Invoke-WmiMethod
- Invoke-CimMethod
- Invoke-Expression
- Invoke-Command
- New-ScheduledTask
- Register-ScheduledJob

Создание файла возможностей роли

Вы можете создать новый файл ролевой способности с помощью командлета New-PSRoleCapabilityFile.

New-PSRoleCapabilityFile -Path .\MyFirstJEARole.psrc

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

Разрешение использования командлетов и функций PowerShell

Чтобы авторизовать пользователей для запуска командлетов или функций PowerShell, добавьте имя командлета или функции в поля VisibleCmdlets или VisibleFunctions. Если вы не уверены, является ли команда командлетом или функцией, можно запустить Get-Command <name> и проверить свойство CommandType в выходных данных.

VisibleCmdlets = @('Restart-Computer', 'Get-NetIPAddress')

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

VisibleCmdlets = @{
    Name       = 'Restart-Computer'
    Parameters = @{ Name = 'Name' }
}

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

VisibleCmdlets = @(
    @{
        Name       = 'Restart-Service'
        Parameters = @{ Name = 'Name'; ValidateSet = @('Dns', 'Spooler') }
    }
    @{
        Name       = 'Start-Website'
        Parameters = @{ Name = 'Name'; ValidatePattern = 'HR_*' }
    }
)

Примечание.

распространенные параметры PowerShell всегда разрешены, даже если ограничить доступные параметры. Вы не должны явно перечислять их в поле "Параметры".

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

вариант использования: разрешить пользователю запускать My-Func без каких-либо ограничений на параметры.
```
@{ Name = 'My-Func' }
```
вариант использования: Разрешить пользователю запускать My-Func из модуля MyModule без каких-либо ограничений на параметры.
```
@{ Name = 'MyModule\My-Func' }
```
Сценарий использования: Разрешить пользователю запускать любой командлет или функцию с глаголом My.
```
@{ Name = 'My-*' }
```
Вариант использования: Разрешить пользователю запускать любой командлет или функцию с использованием существительного Func.
```
@{ Name = '*-Func' }
```
Вариант использования: Разрешить пользователю запускать My-Func с параметрами Param1 и Param2. Любое значение можно задать параметрам.
```
@{ Name = 'My-Func'; Parameters = @{ Name = 'Param1'}, @{ Name = 'Param2' }}
```
вариант использования: разрешить пользователю запускать My-Func с параметром Param1. В параметр можно предоставить только Value1 и Value2.
```
@{
    Name       = 'My-Func'
    Parameters = @{ Name = 'Param1'; ValidateSet = @('Value1', 'Value2') }
}
```
вариант использования: разрешить пользователю запускать My-Func с параметром Param1. Любое значение, начиная с contoso, можно указать параметру.
```
@{
    Name       = 'My-Func'
    Parameters = @{ Name = 'Param1'; ValidatePattern = 'contoso.*' }
}
```

Предупреждение

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

Невозможно применить ValidatePattern и ValidateSet к одному командлету или функции.

При этом ValidatePattern переопределяет ValidateSet.

Дополнительные сведения о ValidatePatternсм. этой Hey, Scripting Guy! публикации и справочных содержимого регулярных выражений PowerShell.

Разрешение внешних команд и скриптов PowerShell

Чтобы пользователи могли запускать исполняемые файлы и скрипты PowerShell (.ps1) в сеансе JEA, необходимо добавить полный путь к каждой программе в поле VisibleExternalCommands.

VisibleExternalCommands = @(
    'C:\Windows\System32\whoami.exe'
    'C:\Program Files\Contoso\Scripts\UpdateITSoftware.ps1'
)

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

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

Например, рассмотрим роль администратора файлового сервера, который управляет сетевыми ресурсами, размещенными в системе. Одним из способов управления акциями является использование net share. Однако разрешение net.exe опасно, так как пользователь может использовать команду для получения прав администратора с помощью команды net group Administrators unprivilegedjeauser /add. Более безопасным вариантом является разрешение командлета Get-SmbShare, который достигает того же результата, но имеет гораздо более ограниченную область.

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

Разрешение доступа к поставщикам PowerShell

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

При необходимости вы можете разрешить доступ к поставщикам PowerShell с помощью команды VisibleProviders. Для получения полного списка поставщиков выполните Get-PSProvider.

VisibleProviders = 'Registry'

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

Создание пользовательских функций

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

VisibleFunctions = 'Get-TopProcess'

FunctionDefinitions = @{
    Name        = 'Get-TopProcess'
    ScriptBlock = {
        param($Count = 10)

        Get-Process |
            Sort-Object -Property CPU -Descending |
            Microsoft.PowerShell.Utility\Select-Object -First $Count
    }
}

Это важно

Не забудьте добавить имя ваших пользовательских функций в поле VisibleFunctions, чтобы пользователи JEA могли их выполнять.

Текст (блок скрипта) пользовательских функций выполняется в языковом режиме по умолчанию для системы и не зависит от ограничений языка JEA. Это означает, что функции могут получить доступ к файловой системе и реестру, а также выполнять команды, которые не были видимы в файле возможностей роли. Старайтесь не выполнять произвольный код при использовании параметров. Избегайте непосредственного перенаправления пользовательского ввода в командлеты, такие как Invoke-Expression.

В приведенном выше примере обратите внимание, что Microsoft.PowerShell.Utility\Select-Object полного имени модуля (FQMN) использовалось вместо сокращенного Select-Object. Функции, определенные в файлах возможностей ролей, по-прежнему подвергаются ограничениям сеансов JEA, включая функции прокси-сервера, которые JEA создает для ограничения существующих команд.

По умолчанию Select-Object — это ограниченный командлет во всех сеансах JEA, которые не позволяют выбирать произвольные свойства для объектов. Чтобы использовать неограниченный Select-Object в функциях, необходимо явно запросить полную реализацию с помощью FQMN. Любой ограниченный командлет в сеансе JEA имеет те же ограничения при вызове функции. Дополнительные сведения см. в разделе about_Command_Precedence.

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

Чтобы завершение вкладки работало правильно в сеансах JEA, необходимо включить встроенную функцию TabExpansion2 в список VisibleFunctions.

Сделать возможности роли доступными для конфигурации

Для того чтобы PowerShell мог найти файл возможностей роли, до версии PowerShell 6 он должен был храниться в папке RoleCapabilities внутри модуля PowerShell. Модуль можно хранить в любой папке, включенной в переменную среды $Env:PSModulePath, однако не следует размещать ее в $Env:SystemRoot\System32 или папке, в которой ненадежные пользователи могут изменять файлы.

В следующем примере создается модуль скрипта PowerShell с именем ContosoJEA в пути $Env:ProgramFiles для размещения файла, определяющего возможности роли.

# Create a folder for the module
$modulePath = Join-Path $Env:ProgramFiles "WindowsPowerShell\Modules\ContosoJEA"
New-Item -ItemType Directory -Path $modulePath

# Create an empty script module and module manifest.
# At least one file in the module folder must have the same name as the folder itself.
$rootModulePath = Join-Path $modulePath "ContosoJEAFunctions.psm1"
$moduleManifestPath = Join-Path $modulePath "ContosoJEA.psd1"
New-Item -ItemType File -Path $RootModulePath
New-ModuleManifest -Path $moduleManifestPath -RootModule "ContosoJEAFunctions.psm1"

# Create the RoleCapabilities folder and copy in the PSRC file
$rcFolder = Join-Path $modulePath "RoleCapabilities"
New-Item -ItemType Directory $rcFolder
Copy-Item -Path .\MyFirstJEARole.psrc -Destination $rcFolder

Дополнительные сведения о модулях PowerShell см. в статье Общие сведения о модуле PowerShell.

Начиная с PowerShell 6, свойство RoleDefinitions было добавлено в файл конфигурации сеанса. Это свойство позволяет указать расположение файла конфигурации роли для определения роли. Примеры см. в New-PSSessionConfigurationFile.

Обновление возможностей роли

Вы можете изменить файл возможностей роли для обновления параметров в любое время. Все новые сеансы JEA, запущенные после обновления возможностей роли, будут отражать измененные возможности.

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

Для администраторов, которые хотят ограничить доступ к функциям роли, убедитесь, что Локальная система имеет доступ только для чтения к файлам функций роли и к модулям, содержащим их.

Как объединяются возможности ролей

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

VisibleCmdlets и VisibleFunctions

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

Ниже приведены правила.

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

Ниже приведен пример объединения ролей в соответствии с этими правилами:

# Role A Visible Cmdlets
$roleA = @{
    VisibleCmdlets = @(
        'Get-Service'
         @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Client' }
        }
    )
}

# Role B Visible Cmdlets
$roleB = @{
    VisibleCmdlets = @(
        @{
            Name       = 'Get-Service';
            Parameters = @{ Name = 'DisplayName'; ValidatePattern = 'DNS.*' }
        }
        @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Server' }
        }
    )
}

# Resulting permissions for a user who belongs to both role A and B
# - The constraint in role B for the DisplayName parameter on Get-Service
#   is ignored because of rule #4
# - The ValidateSets for Restart-Service are merged because both roles use
#   ValidateSet on the same parameter per rule #5
$mergedAandB = @{
    VisibleCmdlets = @(
        'Get-Service'
        @{
            Name = 'Restart-Service';
            Parameters = @{
                Name = 'DisplayName'
                ValidateSet = 'DNS Client', 'DNS Server'
            }
        }
    )
}

ВидимыеВнешниеКоманды, ВидимыеПсевдонимы, ВидимыеПоставщики, СкриптыДляОбработки

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

Будьте осторожны, чтобы совокупный набор поставщиков из одной возможности роли и командлетов/функций/команд из другой не позволял пользователям получить непреднамеренный доступ к системным ресурсам. Например, если одна роль разрешает командлет Remove-Item, а другая роль разрешает поставщика FileSystem, вы подвергаете себя риску того, что пользователь JEA может удалить произвольные файлы на вашем компьютере. Дополнительные сведения об определении эффективных разрешений пользователей можно найти в статье про аудит JEA.

Дальнейшие действия

Создание файла конфигурации сеанса

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

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

Last updated on 2025-06-27