Compartilhar via

Configurações de sessão JEA

Um endpoint JEA é registrado em um sistema por meio da criação e registro de 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 está configurado. Há muitas opções a serem consideradas. As opções mais importantes são:

  • Quem tem acesso ao endpoint JEA
  • Quais funções podem ser atribuídas
  • Qual identidade o JEA usa nos bastidores?
  • 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 um arquivo de configuração de sessão do PowerShell. O arquivo de configuração de sessão pode ser editado usando qualquer editor de texto.

Execute o comando a seguir para criar um arquivo de configuração de modelo em branco.

New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer -Path .\MyJEAEndpoint.pssc

Dica

Somente 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 -SessionType RestrictedRemoteServer campo indica que a configuração da sessão é usada pelo JEA para gerenciamento seguro. As sessões desse tipo operam no modo NoLanguage e só têm acesso aos seguintes comandos padrão (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 programas externos (executáveis ou scripts).

Para obter mais informações sobre modos de linguagem, 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 de sessão.

Conta Virtual Local

Contas virtuais locais são úteis quando todas as funções definidas para o ponto de extremidade JEA são usadas para gerenciar o computador local e uma conta de administrador local é suficiente para executar os comandos com êxito. As contas virtuais são contas temporárias exclusivas para 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 de 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'

Observação

As contas virtuais recebem temporariamente o Logon como um direito de serviço na política 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 na política de segurança do controlador de domínio são auditadas de perto. Isso só está disponível no Windows Server 2016 com o rollup de novembro de 2018 ou posterior e o Windows Server 2019 com o rollup de janeiro de 2019 ou posterior.

Conta de serviço gerenciada por grupo

Uma GMSA (conta de serviço gerenciada por grupo) é a identidade apropriada a ser usada quando os usuários jea precisam acessar recursos de rede, como compartilhamentos de arquivos e serviços Web. Os GMSAs fornecem uma identidade de domínio usada para autenticar com recursos em qualquer computador 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 computadores ou serviços, a menos que o administrador do computador 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 GMSAs só devem ser usados quando necessário:

  • É difícil rastrear as ações de um usuário ao usar uma Conta de Serviço Gerenciada de Grupo (GMSA). Cada usuário compartilha a mesma identidade de execução. Você deve examinar transcrições e 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 de acesso. Sempre tente limitar permissões efetivas em uma sessão JEA para seguir o princípio de privilégios mínimos.

Observação

As contas de serviço gerenciado de grupo só estão disponíveis em computadores ingressados no 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 de sessão

É recomendado que você configure um endpoint JEA para registrar automaticamente transcrições das sessões dos usuários. As transcrições de sessão do PowerShell contêm informações sobre o usuário conectado, a execução como identidade atribuída a eles 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 de sessão, forneça um caminho para uma pasta em que 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.

Drive do usuário

Se os usuários conectados precisarem copiar arquivos de ou para o ponto de extremidade JEA, você poderá habilitar a unidade de usuário no arquivo de configuração de sessão. A unidade de usuário é um PSDrive mapeado em uma pasta exclusiva para cada usuário que conecta. Essa pasta permite que os usuários copiem arquivos de ou para o sistema sem dar a eles acesso ao sistema de arquivos completo ou expor o provedor FileSystem. O conteúdo da unidade do usuário é persistente ao longo das sessões para acomodar situações em que a conectividade de rede pode ser interrompida.

MountUserDrive = $true

Por padrão, a unidade de usuário permite que você armazene no máximo 50 MB 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 você não quiser que os dados na unidade de 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 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

Definições de função em um arquivo de configuração de sessão definem o mapeamento de usuários para funções. Todos os usuários ou grupos incluídos neste campo recebem permissão para o endpoint JEA quando ele é registrado. Cada usuário ou grupo pode ser incluído como uma chave no hashtable apenas uma vez, mas pode receber 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 obterá 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 definições de função, use o nome do computador, não 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

Conforme mostrado no exemplo acima, as capacidades de função são referenciadas 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árias funcionalidades 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 funcionalidade de função válida. O JEA não dá acesso a todos os arquivos de capacidade de função com o mesmo nome.

O JEA usa a variável de ambiente $Env:PSModulePath para determinar quais caminhos escanear para arquivos de capacidade de função. Em cada um desses caminhos, o JEA procura módulos válidos do PowerShell que contêm uma subpasta "RoleCapabilities". Assim como acontece com a importação de módulos, o JEA prefere capacidades de função integradas ao Windows do que capacidades de função personalizadas 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. A ordem não é garantida como alfabética. O primeiro arquivo de capacidade de função encontrado que corresponde ao nome especificado é usado para o usuário conectado. Como a ordem de pesquisa da funcionalidade 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 endpoints JEA. As regras de acesso condicional permitem que você refinar esse acesso e exija que os usuários pertençam a grupos de segurança adicionais que não afetam as funções às quais eles sã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 tabela de hash (opcionalmente aninhada) que usa as chaves 'And' e 'Or' para a construção das suas regras. Aqui estão alguns exemplos de como usar 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.

Outras propriedades

Os arquivos de configuração de sessão também podem fazer tudo o que um arquivo de funcionalidade de função pode fazer, apenas sem a capacidade de fornecer aos usuários conectados acesso a diferentes comandos. Se você quiser permitir que todos os usuários acessem cmdlets, funções ou provedores específicos, você pode fazer isso diretamente no arquivo de configuração de sessão. Para obter uma lista completa das propriedades com suporte no arquivo de configuração de 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 que você teste o arquivo de configuração de 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 neste teste, ele não poderá ser registrado no sistema.

Arquivo de configuração de sessão de exemplo

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 $roles variável para conveniência e legibilidade. não é um requisito fazer isso.

$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.

Próximas etapas

  • Last updated on