Вопросы безопасности JEA
JEA помогает повысить уровень безопасности за счет сокращения числа постоянных администраторов на компьютерах. JEA использует конфигурацию сеанса PowerShell, чтобы создать новую точку входа пользователей для управления системой. Пользователи, которым требуется повышенный (но не неограниченный) уровень доступа к компьютеру для выполнения административных задач, могут получить доступ к конечной точке JEA. Так как JEA позволяет этим пользователям выполнять административные команды без полного доступа администратора, вы можете удалить этих пользователей из групп безопасности с высоким уровнем привилегий.
Учетная запись запуска от имени
Каждая конечная точка JEA имеет назначенную учетную запись запуска от имени , в которой выполняются действия подключающегося пользователя. Эта учетная запись настраивается в файле конфигурации сеанса, и ее выбор оказывает значительное влияние на безопасность конечной точки.
Рекомендуемым способом настройки учетной записи запуска от имени являются виртуальные учетные записи. Виртуальные учетные записи — это одноразовые временные локальные учетные записи, созданные для использования подключающимся пользователем во время сеанса JEA. После завершения его сеанса виртуальная учетная запись будет уничтожена, а ее дальнейшее использование станет невозможным. Подключающийся пользователь не знает учетные данные для виртуальной учетной записи. Виртуальная учетная запись не может использоваться для доступа к системе другими средствами, такими как удаленный рабочий стол или конечная точка PowerShell без ограничений.
По умолчанию виртуальные учетные записи являются членами локальной группы Администратор istrators на компьютере. Это членство дает им полные права на управление любым элементом в системе, но нет прав на управление ресурсами в сети. Когда пользователь подключается к другим компьютерам из сеанса 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>. Например, если пользователь Alice в домене Contoso перезапускает службы в конечной точке JEA, имя пользователя, связанное с любыми событиями диспетчера служб, будет иметь вид WinRM Virtual Users\WinRM_VA_1_contoso_alice.
Групповые управляемые учетные записи службы (gMSA) полезны, когда рядовому серверу требуется доступ к сетевым ресурсам в сеансе JEA. Примером может быть конечная точка JEA, используемая для управления доступом к службе REST API, размещенной на другом компьютере. Легко писать функции для вызова интерфейсов REST API, но вам потребуется сетевое удостоверение для проверки подлинности в API. Использование групповой управляемой учетной записи службы позволяет сделать "второй прыжок" и при этом управлять доступом компьютеров к этой учетной записи. Членство в группе безопасности (локальном или домене) gMSA определило действующие разрешения для учетной записи gMSA.
Когда конечная точка JEA настроена для использования учетной записи gMSA, действия всех пользователей JEA относятся к одной и той же учетной записи gMSA. Единственный способ отслеживания связи действий с конкретным пользователем заключается в определении набора запущенных команд в записи сеанса PowerShell.
Учетные данные сквозной передачи используются, если не указать учетную запись запуска от имени . PowerShell использует учетные данные подключающегося пользователя для выполнения команд на удаленном сервере. Чтобы использовать сквозные учетные данные, необходимо предоставить пользователю прямой доступ к привилегированным группам управления. Эта конфигурация не рекомендуется для JEA. Если у подключающегося пользователя уже есть права администратора, они могут обойти JEA и управлять системой с помощью других методов доступа.
Стандартные учетные записи запуска от имени позволяют задать любую учетную запись пользователя, с использованием которой будет выполняться весь сеанс PowerShell. Конфигурации сеанса с исправленными учетными записями запуска от имени (с параметром -RunAsCredential) не поддерживают JEA. Определения ролей больше не работают должным образом. Каждому пользователю, авторизованному для доступа к конечной точке, назначается одна и та же роль.
Не следует использовать RunAsCredential на конечной точке JEA из-за сложности определения связи действий с конкретными пользователями и отсутствия поддержки для сопоставления пользователей с ролями.
ACL конечной точки WinRM
Как и в случае с обычными конечными точками удаленного взаимодействия PowerShell, каждая конечная точка JEA имеет отдельный список управления доступом (ACL), который указывает, кто именно может проходить проверку подлинности на базе конечной точки JEA. При неправильной настройке доверенные пользователи могут не иметь доступа к конечной точке JEA, а у ненадежных пользователей может быть доступ. ACL WinRM не влияет на сопоставление пользователей с ролями JEA. Это сопоставление регулируется полем RoleDefinitions в файле конфигурации сеанса, который использовался для регистрации конечной точки.
По умолчанию, когда конечная точка JEA имеет несколько возможностей ролей, ACL WinRM настраивается так, чтобы разрешить доступ всем сопоставленным пользователям. Например, сеанс JEA, настроенный с помощью указанных ниже команд, будет предоставлять полный доступ к CONTOSO\JEA_Lev1 и CONTOSO\JEA_Lev2.
$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
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> для изменения разрешений. Для доступа к конечной точке 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.
Ограничение использования и возможностей поставщиков PowerShell
Ознакомьтесь с тем, как разрешенные поставщики используются для обеспечения того, чтобы не создавать уязвимости в настроенном сеансе.
Предупреждение
Не разрешайте поставщику FileSystem . Если пользователи могут записывать данные в любую часть файловой системы, можно полностью обойти безопасность.
Не разрешайте поставщику сертификатов. С включенным поставщиком пользователь может получить доступ к хранимым закрытым ключам.
Не разрешайте команды, которые могут создавать новые пространства выполнения.
Предупреждение
*-Job Командлеты могут создавать новые пространства выполнения без ограничений.
Не разрешайте Trace-Command командлет.
Предупреждение
Использование Trace-Command приводит все трассированные команды в сеанс.
Не создавайте собственные реализации прокси-сервера для ограниченных команд.
PowerShell содержит набор команд прокси-сервера для сценариев с ограниченным доступом. Эти команды прокси-сервера гарантируют, что входные параметры не могут компрометации безопасности сеанса. Следующие команды имеют ограниченные прокси-серверы:
Exit-PSSessionGet-CommandGet-FormatDataGet-HelpMeasure-ObjectOut-DefaultSelect-Object
Если вы создаете собственную реализацию этих команд, вы можете непреднамеренно разрешить пользователям запускать код, запрещенный командами прокси-сервера JEA.
Отсутствие защиты от администраторов в JEA
Одним из основных принципов JEA является то, что он позволяет неадминистраторам выполнять некоторые административные задачи. JEA не защищает от тех пользователей, кто уже обладает правами администратора. Пользователи, принадлежащие к доменным Администратор, локальным Администратор istrators или другим группам с высоким уровнем привилегий, могут обойти защиту JEA другими способами. Например, они могут войти в систему с помощью протокола удаленного рабочего стола, использовать удаленные консоли MMC или подключиться к конечным точкам PowerShell, не имеющим ограничений. Кроме того, локальный администратор в системе может изменить конфигурации JEA, чтобы добавить дополнительных пользователей или изменить возможность роли, чтобы расширить область того, что пользователь может сделать в своем сеансе JEA. Важно оценить расширенные разрешения пользователей JEA и попытаться определить другие способы, с помощью которых они могут получить привилегированный доступ к системе.
Помимо использования JEA для регулярного ежедневного обслуживания, обычно используется система управления привилегированным доступом. Эти системы позволяют назначенным пользователям временно стать локальным администратором только после завершения рабочего процесса, который документирует использование этих разрешений.
PowerShell
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по