Partilhar via

Configurações de sessão JEA

Um ponto de extremidade JEA é registado num sistema criando e registando um ficheiro de configuração de sessão do PowerShell. As configurações de sessão definem quem pode usar o endpoint 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 por trás dos bastidores
  • O nome do ponto de extremidade JEA

Essas opções são definidas em um arquivo de dados do PowerShell com uma extensão de .pssc 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

Sugestão

Apenas as opções de configuração mais comuns são incluídas no arquivo de modelo por padrão. Use a opção -Full para incluir todas as configurações aplicáveis no PSSC gerado.

O campo -SessionType RestrictedRemoteServer indica que a configuração da sessão é usada pelo JEA para gerenciamento seguro. Sessões desse tipo operam no modo NoLanguage e só têm acesso aos seguintes comandos predefinidos (e aliases):

  • Clear-Host (cls, clear)
  • Exit-PSSession (exsn, exit)
  • Get-Command (gcm)
  • Get-FormatData
  • Get-Help
  • Measure-Object (measure)
  • Out-Default
  • Select-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 do Active Directory, as contas virtuais pertencem ao grupo Administradores do 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'

Observação

As contas virtuais recebem temporariamente o direito de início de sessão 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. GMSAs fornecem uma identidade de domínio que é usada para autenticar-se 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 as ações de volta para um usuário ao usar um GMSA. Cada utilizador 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.

Observação

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 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 do 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 de utilizador

Se os utilizadores que estão a conectar-se precisarem de copiar ficheiros para ou do ponto de extremidade JEA, pode habilitar o disco do utilizador no ficheiro de configuração da sessão. A unidade do 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 utilizador é conservado entre sessões para lidar com 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.

Observação

A unidade de utilizador só está disponível no PowerShell 5.1 ou superior.

Para obter mais informações sobre PSDrives, consulte gerenciando unidades do PowerShell.

Definições de função

As definições de função num ficheiro de configuração de sessão definem o mapeamento de utilizadores para funções. Cada utilizador ou grupo incluído neste campo recebe permissão para o endpoint JEA quando este é registado. 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 extensão .psrc.

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 ou curingas localhost. Você pode verificar o nome do computador inspecionando a variável $Env:COMPUTERNAME.

RoleDefinitions = @{
    'MyComputerName\MyLocalGroup' = @{ RoleCapabilities = 'DnsAuditor' }
}

Ordem de pesquisa de competência de função

Como mostrado no exemplo acima, as capacidades de função são referenciadas pelo nome base do arquivo de capacidades de função. O nome base de um arquivo é o nome do arquivo sem a extensão. Se várias capacidades de função estiverem disponíveis no sistema com o mesmo nome, o PowerShell usará a sua ordem de pesquisa padrão para selecionar o arquivo de capacidade de função efetiva. O JEA não dá acesso a todos os arquivos de recursos de função com o mesmo nome.

O JEA usa a variável de ambiente $Env:PSModulePath para determinar quais percursos procurar ficheiros de capacidades de funções. 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 utilizadores e grupos incluídos no campo RoleDefinitions recebem automaticamente acesso aos endpoints 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. Aí, 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' }}

Observação

As regras de acesso condicional só estão disponíveis no PowerShell 5.1 ou mais recente.

Outros imóveis

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 arquivo .pssc. 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 função são criadas e armazenadas na variável $roles 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 anular o registo. Em seguida, registrar novamente a configuração de sessão JEA usando um arquivo de configuração de sessão atualizado.

Próximos passos