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

Статья
11/08/2024

При создании конечной точки 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

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

При необходимости доступ к поставщикам 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.

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

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

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

Для корректной работы завершения при нажатии клавиши TAB в сеансах JEA необходимо включить встроенную функцию tabexpansion2 в список VisibleFunctions.

Обеспечение доступности возможностей роли для конфигурации

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

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

# 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'
            }
        }
    )
}

VisibleExternalCommands, VisibleAliases, VisibleProviders, ScriptsToProcess

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

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

Следующие шаги

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

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