Configurações de sessão JEA
Um ponto de extremidade JEA é registrado em um sistema criando e registrando um arquivo de configuração de sessão do PowerShell. As configurações de sessão definem quem pode usar o ponto de extremidade JEA e a quais funções eles têm acesso. Eles também definem configurações globais que se aplicam a todos os usuários da sessão JEA.
Criar um arquivo de configuração de sessão
Para registrar um ponto de extremidade JEA, você deve especificar como esse ponto de extremidade é configurado. Há muitas opções a considerar. As opções mais importantes são:
- Quem tem acesso ao endpoint JEA
- Que funções lhes podem ser atribuídas
- Que identidade a JEA utiliza sob as capas
- O nome do ponto de extremidade JEA
Essas opções são definidas em um arquivo de dados do PowerShell com uma .pssc extensão conhecida como arquivo de configuração de sessão do PowerShell. O arquivo de configuração da sessão pode ser editado usando qualquer editor de texto.
Execute o seguinte comando para criar um arquivo de configuração de modelo em branco.
New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer -Path .\MyJEAEndpoint.pssc
Gorjeta
Apenas as opções de configuração mais comuns são incluídas no arquivo de modelo por padrão. Use o -Full switch para incluir todas as configurações aplicáveis no PSSC gerado.
O -SessionType RestrictedRemoteServer campo indica que a configuração da sessão é usada pelo JEA para gerenciamento seguro. As sessões deste tipo operam no modo NoLanguage e só têm acesso aos seguintes comandos (e aliases) predefinidos:
Clear-Host(cls,clear)Exit-PSSession(exsn,exit)Get-Command(gcm)Get-FormatDataGet-HelpMeasure-Object(measure)Out-DefaultSelect-Object(select)
Nenhum provedor do PowerShell está disponível, nem nenhum programa externo (executáveis ou scripts).
Para obter mais informações sobre modos de idioma, consulte about_Language_modes.
Escolha a identidade JEA
Nos bastidores, o JEA precisa de uma identidade (conta) para usar ao executar os comandos de um usuário conectado. Você define qual identidade o JEA usa no arquivo de configuração da sessão.
Conta Virtual Local
As contas virtuais locais são úteis quando todas as funções definidas para o ponto de extremidade JEA são usadas para gerenciar a máquina local e uma conta de administrador local é suficiente para executar os comandos com êxito. As contas virtuais são contas temporárias que são exclusivas de um usuário específico e duram apenas a duração da sessão do PowerShell. Em um servidor membro ou estação de trabalho, as contas virtuais pertencem ao grupo Administradores do computador local. Em um Controlador de Domínio Ative Directory, as contas virtuais pertencem ao grupo Administradores de Domínio do domínio.
# Setting the session to use a virtual account
RunAsVirtualAccount = $true
Se as funções definidas pela configuração da sessão não exigirem privilégio administrativo total, você poderá especificar os grupos de segurança aos quais a conta virtual pertencerá. Em um servidor membro ou estação de trabalho, os grupos de segurança especificados devem ser grupos locais, não grupos de um domínio.
Quando um ou mais grupos de segurança são especificados, a conta virtual não é atribuída ao grupo de administradores locais ou de domínio.
# Setting the session to use a virtual account that only belongs to the NetworkOperator and NetworkAuditor local groups
RunAsVirtualAccount = $true
RunAsVirtualAccountGroups = 'NetworkOperator', 'NetworkAuditor'
Nota
As contas virtuais recebem temporariamente o direito Logon como serviço na diretiva de segurança do servidor local. Se um dos VirtualAccountGroups especificados já tiver recebido esse direito na política, a conta virtual individual não será mais adicionada e removida da política. Isso pode ser útil em cenários como controladores de domínio em que as revisões da diretiva de segurança do controlador de domínio são auditadas de perto. Isso só está disponível no Windows Server 2016 com o pacote cumulativo de novembro de 2018 ou posterior e no Windows Server 2019 com o pacote cumulativo de janeiro de 2019 ou posterior.
Conta de serviço gerenciada por grupo
Uma conta de serviço gerenciada por grupo (GMSA) é a identidade apropriada a ser usada quando os usuários do JEA precisam acessar recursos de rede, como compartilhamentos de arquivos e serviços da Web. Os GMSAs fornecem uma identidade de domínio que é usada para autenticar com recursos em qualquer máquina dentro do domínio. Os direitos que um GMSA fornece são determinados pelos recursos que você está acessando. Você não tem direitos de administrador em nenhuma máquina ou serviço, a menos que o administrador da máquina ou do serviço tenha concedido explicitamente esses direitos ao GMSA.
# Configure JEA sessions to use the GMSA in the local computer's domain
# with the sAMAccountName of 'MyJEAGMSA'
GroupManagedServiceAccount = 'Domain\MyJEAGMSA'
Os GMSA só devem ser utilizados quando necessário:
É difícil rastrear ações para um usuário ao usar um GMSA. Cada usuário compartilha a mesma identidade de execução. Você deve revisar as transcrições e os logs de sessão do PowerShell para correlacionar usuários individuais com suas ações.
O GMSA pode ter acesso a muitos recursos de rede aos quais o usuário que se conecta não precisa acessar. Sempre tente limitar as permissões efetivas em uma sessão JEA para seguir o princípio do menor privilégio.
Nota
As contas de serviço gerenciado de grupo só estão disponíveis em máquinas associadas ao domínio usando o PowerShell 5.1 ou mais recente.
Para obter mais informações sobre como proteger uma sessão JEA, consulte o artigo de considerações de segurança.
Transcrições das sessões
É recomendável configurar um ponto de extremidade JEA para gravar automaticamente as transcrições das sessões dos usuários. As transcrições de sessão do PowerShell contêm informações sobre o usuário que se conecta, a execução como identidade atribuída a ele e os comandos executados pelo usuário. Eles podem ser úteis para uma equipe de auditoria que precisa entender quem fez uma alteração específica em um sistema.
Para configurar a transcrição automática no arquivo de configuração da sessão, forneça um caminho para uma pasta onde as transcrições devem ser armazenadas.
TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'
As transcrições são gravadas na pasta pela conta Sistema Local, que requer acesso de leitura e gravação ao diretório. Os usuários padrão não devem ter acesso à pasta. Limite o número de administradores de segurança que têm acesso para auditar as transcrições.
Unidade do usuário
Se os usuários conectados precisarem copiar arquivos de ou para o ponto de extremidade JEA, você poderá habilitar a unidade do usuário no arquivo de configuração da sessão. A unidade de usuário é um PSDrive que é mapeado para uma pasta exclusiva para cada usuário conectado. Esta pasta permite que os usuários copiem arquivos de ou para o sistema sem dar-lhes acesso ao sistema de arquivos completo ou expor o provedor FileSystem. O conteúdo da unidade do usuário é persistente entre as sessões para acomodar situações em que a conectividade de rede pode ser interrompida.
MountUserDrive = $true
Por padrão, a unidade do usuário permite armazenar um máximo de 50MB de dados por usuário. Você pode limitar a quantidade de dados que um usuário pode consumir com o campo UserDriveMaximumSize .
# Enables the user drive with a per-user limit of 500MB (524288000 bytes)
MountUserDrive = $true
UserDriveMaximumSize = 524288000
Se não quiser que os dados na unidade do usuário sejam persistentes, você pode configurar uma tarefa agendada no sistema para limpar automaticamente a pasta todas as noites.
Nota
A unidade do usuário só está disponível no PowerShell 5.1 ou mais recente.
Para obter mais informações sobre PSDrives, consulte Gerenciando unidades do PowerShell.
Definições de função
As definições de função em um arquivo de configuração de sessão definem o mapeamento de usuários para funções. Cada usuário ou grupo incluído neste campo recebe permissão para o ponto de extremidade JEA quando ele é registrado.
Cada usuário ou grupo pode ser incluído como uma chave na hashtable apenas uma vez, mas pode ser atribuído a várias funções. O nome da capacidade de função deve ser o nome do arquivo de capacidade de função, sem a .psrc extensão.
RoleDefinitions = @{
'CONTOSO\JEA_DNS_ADMINS' = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
'CONTOSO\JEA_DNS_AUDITORS' = @{ RoleCapabilities = 'DnsAuditor' }
}
Se um usuário pertencer a mais de um grupo na definição de função, ele terá acesso às funções de cada um. Quando duas funções concedem acesso aos mesmos cmdlets, o conjunto de parâmetros mais permissivo é concedido ao usuário.
Ao especificar usuários ou grupos locais no campo de definições de função, certifique-se de usar o nome do computador, não localhost ou curingas. Você pode verificar o nome do computador inspecionando a $env:COMPUTERNAME variável.
RoleDefinitions = @{
'MyComputerName\MyLocalGroup' = @{ RoleCapabilities = 'DnsAuditor' }
}
Ordem de pesquisa de capacidade de função
Como mostrado no exemplo acima, os recursos de função são referenciados pelo nome base do arquivo de capacidade de função. O nome base de um arquivo é o nome do arquivo sem a extensão. Se vários recursos de função estiverem disponíveis no sistema com o mesmo nome, o PowerShell usará sua ordem de pesquisa implícita para selecionar o arquivo de capacidade de função efetiva. O JEA não dá acesso a todos os arquivos de capacidade de função com o mesmo nome.
O JEA usa a $env:PSModulePath variável de ambiente para determinar quais caminhos procurar arquivos de capacidade de função. Dentro de cada um desses caminhos, o JEA procura módulos válidos do PowerShell que contenham uma subpasta "RoleCapabilities". Assim como acontece com a importação de módulos, o JEA prefere os recursos de função fornecidos com o Windows aos recursos de função personalizados com o mesmo nome.
Para todos os outros conflitos de nomenclatura, a precedência é determinada pela ordem na qual o Windows enumera os arquivos no diretório. Não é garantido que a ordem seja alfabética. O primeiro arquivo de recurso de função encontrado que corresponde ao nome especificado é usado para o usuário que se conecta. Como a ordem de pesquisa de recursos de função não é determinística, é altamente recomendável que os recursos de função tenham nomes de arquivo exclusivos.
Regras de acesso condicional
Todos os usuários e grupos incluídos no campo RoleDefinitions recebem automaticamente acesso aos pontos de extremidade JEA. As regras de acesso condicional permitem refinar esse acesso e exigem que os usuários pertençam a grupos de segurança adicionais que não afetam as funções às quais estão atribuídos. Isso é útil quando você deseja integrar uma solução de gerenciamento de acesso privilegiado just-in-time, autenticação de cartão inteligente ou outra solução de autenticação multifator com JEA.
As regras de acesso condicional são definidas no campo RequiredGroups em um arquivo de configuração de sessão. Lá, você pode fornecer uma hashtable (opcionalmente aninhada) que usa as chaves 'E' e 'Ou' para construir suas regras. Eis alguns exemplos de como utilizar este campo:
# 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' }}
Nota
As regras de acesso condicional só estão disponíveis no PowerShell 5.1 ou mais recente.
Outras propriedades
Os arquivos de configuração de sessão também podem fazer tudo o que um arquivo de capacidade de função pode fazer, apenas sem a capacidade de dar aos usuários conectados acesso a comandos diferentes. Se quiser permitir que todos os usuários acessem cmdlets, funções ou provedores específicos, você poderá fazê-lo diretamente no arquivo de configuração da sessão.
Para obter uma lista completa das propriedades suportadas no arquivo de configuração da sessão, execute Get-Help New-PSSessionConfigurationFile -Full.
Testando um arquivo de configuração de sessão
Você pode testar uma configuração de sessão usando o cmdlet Test-PSSessionConfigurationFile . É recomendável testar o arquivo de configuração da sessão se tiver editado manualmente o .pssc arquivo. O teste garante que a sintaxe esteja correta. Se um arquivo de configuração de sessão falhar nesse teste, ele não poderá ser registrado no sistema.
Exemplo de arquivo de configuração de sessão
O exemplo a seguir mostra como criar e validar uma configuração de sessão para JEA. As definições de $roles função são criadas e armazenadas na variável para conveniência e legibilidade. não é um requisito para fazê-lo.
$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
Atualizando arquivos de configuração de sessão
Para alterar as propriedades de uma configuração de sessão JEA, incluindo o mapeamento de usuários para funções, você deve cancelar o registro. Em seguida, registre novamente a configuração da sessão JEA usando um arquivo de configuração de sessão atualizado.
