Конфигурации сеансов JEA
Конечная точка JEA регистрируется в системе путем создания и регистрации файла конфигурации сеанса PowerShell. Конфигурации сеансов определяют, кто может использовать конечную точку JEA и к каким ролям они имеют доступ. Они также определяют глобальные параметры, которые применяются ко всем пользователям сеанса JEA.
Создание файла конфигурации сеанса
Чтобы зарегистрировать конечную точку JEA, необходимо указать, как настроена эта конечная точка. Существует множество вариантов, которые следует рассмотреть. Наиболее важными являются следующие варианты:
- У кого есть доступ к конечной точке JEA
- Какие роли могут быть назначены
- Какую идентичность JEA использует за кулисами
- Имя конечной точки JEA
Эти параметры определены в файле данных PowerShell с расширением .pssc, известным как файл конфигурации сеанса PowerShell. Файл конфигурации сеанса можно изменить с помощью любого текстового редактора.
Выполните следующую команду, чтобы создать пустой файл конфигурации шаблона.
New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer -Path .\MyJEAEndpoint.pssc
Подсказка
По умолчанию в файл шаблона включены только наиболее распространенные параметры конфигурации. Используйте переключатель -Full, чтобы включить все применимые настройки в созданный PSSC.
Поле -SessionType RestrictedRemoteServer указывает, что конфигурация сеанса используется JEA для безопасного управления. Сеансы этого типа работают в режиме NoLanguage и имеют доступ только к следующим командам по умолчанию (и псевдонимам):
-
Clear-Host(cls,clear) -
Exit-PSSession(exsn,exit) -
Get-Command(gcm) Get-FormatDataGet-Help-
Measure-Object(measure) Out-Default-
Select-Object(select)
Поставщики PowerShell недоступны, как и любые внешние программы (исполняемые файлы или скрипты).
Дополнительные сведения о режимах языка см. в about_Language_Modes.
Выберите удостоверение JEA
За кулисами JEA должна использовать учетную запись при выполнении команд подключенного пользователя. Вы определяете, какую идентификацию использует JEA в файле конфигурации сеанса.
Локальная виртуальная учетная запись
Локальные виртуальные учетные записи полезны, если все роли, определенные для конечной точки JEA, используются для управления локальным компьютером, а учетная запись локального администратора достаточно для успешного выполнения команд. Виртуальные учетные записи — это временные учетные записи, уникальные для конкретного пользователя и существующие только в течение сеанса PowerShell. На сервере-члене или рабочей станции виртуальные учетные записи принадлежат администраторам локального компьютера группе. На контроллере домена Active Directory виртуальные учетные записи принадлежат группе администраторы домена.
# Setting the session to use a virtual account
RunAsVirtualAccount = $true
Если роли, определенные конфигурацией сеанса, не требуют полных прав администратора, можно указать группы безопасности, к которым будет принадлежать виртуальная учетная запись. На сервере-члене или рабочей станции указанные группы безопасности должны быть локальными, а не группами из домена.
При указании одной или нескольких групп безопасности виртуальная учетная запись не назначается локальной или группе администраторов домена.
# Setting the session to use a virtual account that only belongs to the NetworkOperator and NetworkAuditor local groups
RunAsVirtualAccount = $true
RunAsVirtualAccountGroups = 'NetworkOperator', 'NetworkAuditor'
Примечание.
Виртуальным учетным записям временно предоставляется право входа как службы в политике безопасности локального сервера. Если какой-либо из указанных VirtualAccountGroups уже имеет это право в политике, то отдельные виртуальные учетные записи больше не будут добавляться или удаляться из политики. Это может быть полезно в таких сценариях, как контроллеры домена, где исправления политики безопасности контроллера домена тщательно проверяются. Это доступно только в Windows Server 2016 с накопительным пакетом обновления за ноябрь 2018 г. или более поздней версией и Windows Server 2019 с накопительным пакетом обновления за январь 2019 г. или более поздней версии.
Сервисная учетная запись, управляемая группой
Управляемая группой учетная запись службы (GMSA) — это соответствующее удостоверение, используемое, когда пользователям JEA требуется доступ к сетевым ресурсам, таким как общие папки и веб-службы. GMSAs предоставляют идентификатор домена, который используется для аутентификации с ресурсами на любой машине в пределах домена. Права, предоставляемые GMSA, определяются ресурсами, к которым вы обращаетесь. У вас нет прав администратора на компьютерах или службах, если только администратор компьютера или службы явно не предоставил эти права GMSA.
# Configure JEA sessions to use the GMSA in the local computer's domain
# with the sAMAccountName of 'MyJEAGMSA'
GroupManagedServiceAccount = 'Domain\MyJEAGMSA'
GMSA следует использовать только при необходимости.
При использовании GMSA трудно отследить действия, выполняемые пользователем. Каждый пользователь использует одно и то же удостоверение для запуска. Чтобы сопоставить отдельных пользователей с действиями, необходимо просмотреть расшифровки и журналы сеансов PowerShell.
GMSA может иметь доступ ко многим сетевым ресурсам, к которым не требуется доступ подключающегося пользователя. Всегда старайтесь ограничить действующие разрешения в сеансе JEA, чтобы следовать принципу наименьших привилегий.
Примечание.
Учетные записи управляемых служб группы доступны только на компьютерах, присоединенных к домену, с помощью PowerShell 5.1 или более поздней версии.
Дополнительные сведения о защите сеанса JEA см. в статье о мерах безопасности.
Расшифровки сеансов
Рекомендуется настроить конечную точку JEA для автоматической записи расшифровок сеансов пользователей. Расшифровки сеансов PowerShell содержат сведения о подключающемся пользователе, используемом имени пользователя и командах, выполняемых пользователем. Они могут быть полезными для группы аудита, которая должна понимать, кто сделал определенное изменение в системе.
Чтобы настроить автоматическое транскрибирование в файле конфигурации сеанса, укажите путь к папке, в которой должны храниться расшифровки.
TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'
Транскрипты записываются в папку с помощью учетной записи локальной системы, для которой требуется доступ на чтение и запись в директорию. У стандартных пользователей нет доступа к папке. Ограничение числа администраторов безопасности, имеющих доступ к аудиту расшифровок.
Диск пользователя
Если пользователям, подключающимся, необходимо скопировать файлы в конечную точку JEA или из нее, можно включить диск пользователя в файле конфигурации сеанса. Диск пользователя — это PSDrive, сопоставленный с уникальной папкой для каждого подключающегося пользователя. Эта папка позволяет пользователям копировать файлы в систему или из нее, не предоставляя им доступ к полной файловой системе и не раскрывая поставщика файловой системы. Содержимое диска пользователя сохраняется в течение сеансов, чтобы обеспечить сохранность данных в случаях, когда сетевое подключение может быть прервано.
MountUserDrive = $true
По умолчанию диск пользователя позволяет хранить не более 50 МБ данных на пользователя. Вы можете ограничить объем данных, которые пользователь может использовать с помощью поля UserDriveMaximumSize.
# Enables the user drive with a per-user limit of 500MB (524288000 bytes)
MountUserDrive = $true
UserDriveMaximumSize = 524288000
Если вы не хотите, чтобы данные на диске пользователя сохранялись, можно настроить запланированную задачу в системе для автоматической очистки папки каждую ночь.
Примечание.
Диск пользователя доступен только в PowerShell 5.1 или более поздней версии.
Дополнительные сведения о PSDrive см. в статье Управление дисками PowerShell.
Определения ролей
Определения ролей в файле конфигурации сеанса определяют сопоставление пользователей с ролями. Каждый пользователь или группа, включенные в это поле, получает разрешение на конечную точку JEA при регистрации.
Каждый пользователь или группа может быть включён в хэш-таблицу только один раз, но им может быть назначено несколько ролей. Название возможности роли должно совпадать с названием файла возможностей роли, но без расширения .psrc.
RoleDefinitions = @{
'CONTOSO\JEA_DNS_ADMINS' = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_AUDITORS' = @{ RoleCapabilities = 'DnsAuditor' }
}
Если пользователь принадлежит нескольким группам в определении роли, они получают доступ к ролям каждой из них. Если две роли предоставляют доступ к одним и тем же командлетам, то пользователю предоставляется наиболее разрешающий набор параметров.
При указании локальных пользователей или групп в поле определений ролей обязательно используйте имя компьютера, а не localhost или подстановочные знаки. Чтобы проверить имя компьютера, проверьте переменную $Env:COMPUTERNAME.
RoleDefinitions = @{
'MyComputerName\MyLocalGroup' = @{ RoleCapabilities = 'DnsAuditor' }
}
Порядок поиска возможностей роли
Как показано в примере выше, возможности ролей определяются по базовому имени файла возможностей роли. Базовое имя файла — это имя файла без расширения. Если в системе доступно несколько возможностей ролей с одинаковым именем, PowerShell использует свой неявный порядок поиска для выбора файла возможностей эффективной роли. JEA не предоставляет доступ ко всем файлам возможностей всех ролей с одинаковым именем.
JEA использует переменную среды $Env:PSModulePath для определения путей проверки файлов возможностей ролей. В каждом из этих путей JEA осуществляет поиск действительных модулей PowerShell, которые содержат подпапку "RoleCapabilities". Как и при импорте модулей, JEA предпочитает возможности ролей, которые поставляются с Windows, вместо пользовательских возможностей ролей с таким же именем.
Для всех других конфликтов именования приоритет определяется порядком перечисления файлов в каталоге Windows. Порядок не гарантируется как алфавитный. Первый файл возможностей ролей, который соответствует указанному имени, используется для пользователя, устанавливающего соединение. Так как порядок поиска возможностей роли не детерминирован, настоятельно рекомендуется , что возможности ролей имеют уникальные имена файлов.
Правила условного доступа
Все пользователи и группы, включенные в поле RoleDefinitions, автоматически получают доступ к конечным точкам JEA. Правила условного доступа позволяют уточнить этот доступ и требовать, чтобы пользователи принадлежали к дополнительным группам безопасности, которые не влияют на роли, к которым они назначены. Это полезно, если вы хотите интегрировать решение для управления привилегированным доступом, проверку подлинности смарт-карт или другое решение многофакторной проверки подлинности с JEA.
Правила условного доступа определяются в поле RequiredGroups в файле конфигурации сеанса. Там можно указать хэш-таблицу (при необходимости вложенную), которая использует ключи «And» и «Or» для создания правил. Ниже приведены некоторые примеры использования этого поля:
# Example 1: Connecting users must belong to a security group called "elevated-jea"
RequiredGroups = @{ And = 'elevated-jea' }
# Example 2: Connecting users must have signed on with 2 factor authentication or a smart card
# The 2 factor authentication group name is "2FA-logon" and the smart card group
# name is "smartcard-logon"
RequiredGroups = @{ Or = '2FA-logon', 'smartcard-logon' }
# Example 3: Connecting users must elevate into "elevated-jea" with their JIT system and
# have logged on with 2FA or a smart card
RequiredGroups = @{ And = 'elevated-jea', @{ Or = '2FA-logon', 'smartcard-logon' }}
Примечание.
Правила условного доступа доступны только в PowerShell 5.1 или более поздней версии.
Другие свойства
Файлы конфигурации сеанса могут выполнять все те же функции, что и файлы возможностей ролей, но не могут предоставлять пользователям доступ к различным командам. Если вы хотите разрешить всем пользователям доступ к определенным командлетам, функциям или поставщикам, это можно сделать прямо в файле конфигурации сеанса.
Чтобы получить полный список поддерживаемых свойств в файле конфигурации сеанса, выполните команду Get-Help New-PSSessionConfigurationFile -Full.
Тестирование файла конфигурации сеанса
Конфигурацию сеанса можно протестировать с помощью командлета Test-PSSessionConfigurationFile. Рекомендуется протестировать файл конфигурации сеанса, если вы вручную редактировали файл .pssc. Тестирование гарантирует правильность синтаксиса. Если файл конфигурации сеанса не проходит этот тест, его нельзя зарегистрировать в системе.
Пример файла конфигурации сеанса
В следующем примере показано, как создать и проверить конфигурацию сеанса для JEA. Определения ролей создаются и хранятся в переменной $roles для удобства и удобства чтения. это не обязательно.
$roles = @{
'CONTOSO\JEA_DNS_ADMINS' = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_AUDITORS' = @{ RoleCapabilities = 'DnsAuditor' }
}
$parameters = @{
SessionType = 'RestrictedRemoteServer'
Path = '.\JEAConfig.pssc'
RunAsVirtualAccount = $true
TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'
RoleDefinitions = $roles
RequiredGroups = @{ Or = '2FA-logon', 'smartcard-logon' }
}
New-PSSessionConfigurationFile @parameters
Test-PSSessionConfigurationFile -Path .\JEAConfig.pssc # should yield True
Обновление файлов конфигурации сеанса
Чтобы изменить свойства конфигурации сеанса JEA, включая сопоставление пользователей с ролями, необходимо отменить регистрацию. Затем повторно зарегистрируйте конфигурацию сеанса JEA с помощью обновленного файла конфигурации сеанса.
Дальнейшие действия
PowerShell