Capacidades de função JEA

Ao criar um ponto de extremidade JEA, você precisa definir um ou mais recursos de função que descrevam o que alguém pode fazer em uma sessão JEA. Um recurso de função é um arquivo de dados do PowerShell com a .psrc extensão que lista todos os cmdlets, funções, provedores e programas externos disponibilizados para conectar usuários.

Determinar quais comandos permitir

A primeira etapa na criação de um arquivo de recurso de função é considerar o que os usuários precisam acessar. O processo de levantamento de requisitos pode demorar um pouco, mas é importante. Dar aos usuários acesso a poucos cmdlets e funções pode impedi-los de realizar seu trabalho. Permitir o acesso a muitos cmdlets e funções pode permitir que os usuários façam mais do que você pretendia e enfraquecer sua postura de segurança.

A forma como procede este processo depende da sua organização e dos seus objetivos. As dicas a seguir podem ajudar a garantir que você esteja no caminho certo.

1. Identifique os comandos que os usuários estão usando para realizar seus trabalhos. Isso pode envolver o levantamento da equipe de TI, a verificação de scripts de automação ou a análise de transcrições e logs de sessão do PowerShell.
2. Atualize o uso de ferramentas de linha de comando para equivalentes do PowerShell, sempre que possível, para obter a melhor experiência de auditoria e personalização do JEA. Os programas externos não podem ser restringidos de forma tão granular quanto os cmdlets e funções nativos do PowerShell no JEA.
3. Restrinja o escopo dos cmdlets para permitir apenas parâmetros ou valores de parâmetros específicos. Isso é especialmente importante se os usuários devem gerenciar apenas parte de um sistema.
4. Crie funções personalizadas para substituir comandos complexos ou comandos difíceis de restringir no JEA. Uma função simples que envolve um comando complexo ou aplica lógica de validação adicional pode oferecer controle adicional para administradores e simplicidade do usuário final.
5. Teste a lista de escopo de comandos permitidos com seus usuários ou serviços de automação e ajuste conforme necessário.

Exemplos de comandos potencialmente perigosos

A seleção cuidadosa de comandos é importante para garantir que o ponto de extremidade JEA não permita que o usuário eleve suas permissões.

Importante

Informações essenciais necessárias para o sucesso do usuárioOs comandos em uma sessão JEA geralmente são executados com privilégios elevados.

A lista a seguir contém exemplos de comandos que podem ser usados maliciosamente se permitidos em um estado sem restrições. Esta não é uma lista exaustiva e deve ser usada apenas como um ponto de partida de precaução.

• Risco: Conceder ao usuário conectado privilégios de administrador para ignorar o JEA

  Exemplo:

  Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators'
  

  Comandos relacionados:

  • Add-ADGroupMember
  • Add-LocalGroupMember
  • net.exe
  • dsadd.exe

• Risco: executar código arbitrário, como malware, exploits ou scripts personalizados para contornar proteções

  Exemplo:

  Start-Process -FilePath '\\san\share\malware.exe'
  

  Comandos relacionados:

  • Start-Process
  • New-Service
  • Invoke-Item
  • Invoke-WmiMethod
  • Invoke-CimMethod
  • Invoke-Expression
  • Invoke-Command
  • New-ScheduledTask
  • Register-ScheduledJob

Criar um arquivo de recurso de função

Você pode criar um novo arquivo de recurso de função do PowerShell com o cmdlet New-PSRoleCapabilityFile .

New-PSRoleCapabilityFile -Path .\MyFirstJEARole.psrc

Você deve editar o arquivo de recurso de função criado para permitir apenas os comandos necessários para a função. A documentação de ajuda do PowerShell contém vários exemplos de como você pode configurar o arquivo.

Permitindo cmdlets e funções do PowerShell

Para autorizar os usuários a executar cmdlets ou funções do PowerShell, adicione o nome do cmdlet ou da função aos campos VisibleCmdlets ou VisibleFunctions . Se não tiver certeza se um comando é um cmdlet ou função, você pode executar Get-Command <name> e verificar a propriedade CommandType na saída.

VisibleCmdlets = @('Restart-Computer', 'Get-NetIPAddress')

Às vezes, o escopo de um cmdlet ou função específica é muito amplo para as necessidades dos usuários. Um administrador de DNS, por exemplo, pode precisar apenas de acesso para reiniciar o serviço DNS. Em ambientes multilocatário, os locatários têm acesso a ferramentas de gerenciamento de autoatendimento. Os inquilinos devem limitar-se a gerir os seus próprios recursos. Para esses casos, você pode restringir quais parâmetros são expostos a partir do cmdlet ou função.

VisibleCmdlets = @{
    Name       = 'Restart-Computer'
    Parameters = @{ Name = 'Name' }
}

Em cenários mais avançados, também pode ser necessário restringir os valores que um usuário pode usar com esses parâmetros. Os recursos de função permitem definir um conjunto de valores ou um padrão de expressão regular que determina qual entrada é permitida.

VisibleCmdlets = @(
    @{
        Name       = 'Restart-Service'
        Parameters = @{ Name = 'Name'; ValidateSet = @('Dns', 'Spooler') }
    }
    @{
        Name       = 'Start-Website'
        Parameters = @{ Name = 'Name'; ValidatePattern = 'HR_*' }
    }
)

Nota

Os parâmetros comuns do PowerShell são sempre permitidos, mesmo que você restrinja os parâmetros disponíveis. Você não deve listá-los explicitamente no campo Parâmetros.

A lista abaixo descreve as várias maneiras de personalizar um cmdlet ou função visível. Você pode misturar e combinar qualquer um dos itens abaixo no campo VisibleCmdlets .

• Caso de uso: Permita que o usuário execute My-Func sem restrições nos parâmetros.

  @{ Name = 'My-Func' }
  

• Caso de uso: Permite que o usuário execute My-Func a partir do módulo MyModule sem quaisquer restrições sobre os parâmetros.

  @{ Name = 'MyModule\My-Func' }
  

• Caso de uso: permita que o usuário execute qualquer cmdlet ou função com o verbo My.

  @{ Name = 'My-*' }
  

• Caso de uso: permita que o usuário execute qualquer cmdlet ou função com o substantivo Func.

  @{ Name = '*-Func' }
  

• Caso de uso: permita que o usuário execute My-Func com os Param1 parâmetros e Param2 . Qualquer valor pode ser fornecido para os parâmetros.

  @{ Name = 'My-Func'; Parameters = @{ Name = 'Param1'}, @{ Name = 'Param2' }}
  

• Caso de uso: permita que o usuário execute My-Func com o Param1 parâmetro. Apenas Value1 e Value2 pode ser fornecido para o parâmetro.

  @{
      Name       = 'My-Func'
      Parameters = @{ Name = 'Param1'; ValidateSet = @('Value1', 'Value2') }
  }
  

• Caso de uso: permita que o usuário execute My-Func com o Param1 parâmetro. Qualquer valor começando com contoso pode ser fornecido para o parâmetro.

  @{
      Name       = 'My-Func'
      Parameters = @{ Name = 'Param1'; ValidatePattern = 'contoso.*' }
  }
  

Aviso

Para melhores práticas de segurança, não é recomendável usar curingas ao definir cmdlets ou funções visíveis. Em vez disso, você deve listar explicitamente cada comando confiável para garantir que nenhum outro comando que compartilhe o mesmo esquema de nomenclatura seja autorizado involuntariamente.

Não é possível aplicar um ValidatePattern e um ValidateSet ao mesmo cmdlet ou função.

Se você fizer isso, o ValidatePattern substituirá o ValidateSet.

Para obter mais informações sobre ValidatePattern, confira esta postagem Hey, Scripting Guy! e o conteúdo de referência de Expressões Regulares do PowerShell.

Permitindo comandos externos e scripts do PowerShell

Para permitir que os usuários executem executáveis e scripts do PowerShell (.ps1) em uma sessão JEA, você precisa adicionar o caminho completo para cada programa no campo VisibleExternalCommands .

VisibleExternalCommands = @(
    'C:\Windows\System32\whoami.exe'
    'C:\Program Files\Contoso\Scripts\UpdateITSoftware.ps1'
)

Sempre que possível, use o cmdlet do PowerShell ou equivalentes de função para quaisquer executáveis externos que você autorizar, pois você tem controle sobre os parâmetros permitidos com cmdlets e funções do PowerShell.

Muitos executáveis permitem que você leia o estado atual e, em seguida, alterá-lo fornecendo parâmetros diferentes.

Por exemplo, considere a função de um administrador de servidor de arquivos que gerencia compartilhamentos de rede hospedados em um sistema. Uma maneira de gerenciar ações é usar net shareo . No entanto, permitir net.exe é perigoso porque o usuário pode usar o comando para obter privilégios de administrador com o comando net group Administrators unprivilegedjeauser /add. Uma opção mais segura é permitir o cmdlet Get-SmbShare , que alcança o mesmo resultado, mas tem um escopo muito mais limitado.

Ao disponibilizar comandos externos aos usuários em uma sessão JEA, sempre especifique o caminho completo para o executável. Isso impede a execução de programas com nomes semelhantes e potencialmente mal-intencionados localizados em outro lugar do sistema.

Permitindo acesso a provedores do PowerShell

Por padrão, nenhum provedor do PowerShell está disponível em sessões JEA. Isso reduz o risco de informações confidenciais e definições de configuração serem divulgadas ao usuário que se conecta.

Quando necessário, você pode permitir o acesso aos provedores do PowerShell usando o VisibleProviders comando. Para obter uma lista completa de provedores, execute Get-PSProvider.

VisibleProviders = 'Registry'

Para tarefas simples que exigem acesso ao sistema de arquivos, registro, armazenamento de certificados ou outros provedores confidenciais, considere escrever uma função personalizada que funcione com o provedor em nome do usuário. As funções, cmdlets e programas externos disponíveis em uma sessão JEA não estão sujeitos às mesmas restrições que o JEA. Eles podem acessar qualquer provedor por padrão. Considere também usar a unidade do usuário quando os usuários precisarem copiar arquivos de ou para um ponto de extremidade JEA.

Criação de funções personalizadas

Você pode criar funções personalizadas em um arquivo de capacidade de função para simplificar tarefas complexas para seus usuários finais. As funções personalizadas também são úteis quando você precisa de lógica de validação avançada para valores de parâmetros de cmdlet. Você pode escrever funções simples no campo FunctionDefinitions :

VisibleFunctions = 'Get-TopProcess'

FunctionDefinitions = @{
    Name        = 'Get-TopProcess'
    ScriptBlock = {
        param($Count = 10)

        Get-Process |
            Sort-Object -Property CPU -Descending |
            Microsoft.PowerShell.Utility\Select-Object -First $Count
    }
}

Importante

Não se esqueça de adicionar o nome de suas funções personalizadas ao campo VisibleFunctions para que elas possam ser executadas pelos usuários JEA.

O corpo (bloco de script) das funções personalizadas é executado no modo de idioma padrão para o sistema e não está sujeito às restrições de idioma do JEA. Isso significa que as funções podem acessar o sistema de arquivos e o registro e executar comandos que não foram tornados visíveis no arquivo de capacidade de função. Tome cuidado para evitar a execução de código arbitrário ao usar parâmetros. Evite canalizar a entrada do usuário diretamente para cmdlets como Invoke-Expression.

No exemplo acima, observe que o nome do módulo totalmente qualificado (FQMN) Microsoft.PowerShell.Utility\Select-Object foi usado em vez da abreviação Select-Object. As funções definidas nos arquivos de capacidade de função ainda estão sujeitas ao escopo das sessões JEA, que inclui as funções de proxy que o JEA cria para restringir os comandos existentes.

Por padrão, Select-Object é um cmdlet restrito em todas as sessões JEA que não permite a seleção de propriedades arbitrárias em objetos. Para usar as funções sem restrições Select-Object , você deve solicitar explicitamente a implementação completa usando o FQMN. Qualquer cmdlet restrito em uma sessão JEA tem as mesmas restrições quando invocado de uma função. Para obter mais informações, consulte about_Command_Precedence.

Se você estiver escrevendo várias funções personalizadas, é mais conveniente colocá-las em um módulo de script do PowerShell. Você torna essas funções visíveis na sessão JEA usando o campo VisibleFunctions como faria com módulos internos e de terceiros.

Para que o preenchimento da guia funcione corretamente em sessões JEA, você deve incluir a função tabexpansion2 interna na lista VisibleFunctions .

Disponibilizar os recursos de função para uma configuração

Antes do PowerShell 6, para que o PowerShell encontre um arquivo de capacidade de função, ele deve ser armazenado em uma RoleCapabilities pasta em um módulo do PowerShell. O módulo pode ser armazenado em qualquer pasta incluída na $env:PSModulePath variável de ambiente, no entanto, você não deve colocá-lo em $env:SystemRoot\System32 ou uma pasta onde usuários não confiáveis possam modificar os arquivos.

O exemplo a seguir cria um módulo de script do PowerShell chamado ContosoJEA $env:ProgramFiles no caminho para hospedar o arquivo de recursos de função.

# Create a folder for the module
$modulePath = Join-Path $env:ProgramFiles "WindowsPowerShell\Modules\ContosoJEA"
New-Item -ItemType Directory -Path $modulePath

# Create an empty script module and module manifest.
# At least one file in the module folder must have the same name as the folder itself.
$rootModulePath = Join-Path $modulePath "ContosoJEAFunctions.psm1"
$moduleManifestPath = Join-Path $modulePath "ContosoJEA.psd1"
New-Item -ItemType File -Path $RootModulePath
New-ModuleManifest -Path $moduleManifestPath -RootModule "ContosoJEAFunctions.psm1"

# Create the RoleCapabilities folder and copy in the PSRC file
$rcFolder = Join-Path $modulePath "RoleCapabilities"
New-Item -ItemType Directory $rcFolder
Copy-Item -Path .\MyFirstJEARole.psrc -Destination $rcFolder

Para obter mais informações sobre módulos do PowerShell, consulte Noções básicas sobre um módulo do PowerShell.

A partir do PowerShell 6, a propriedade RoleDefinitions foi adicionada ao arquivo de configuração da sessão. Essa propriedade permite especificar o local de um arquivo de configuração de função para sua definição de função. Veja os exemplos em New-PSSessionConfigurationFile.

Atualizando recursos de função

Você pode editar um arquivo de recurso de função para atualizar as configurações a qualquer momento. Quaisquer novas sessões de JEA iniciadas após a atualização da capacidade de função refletirão as capacidades revisadas.

É por isso que controlar o acesso à pasta de recursos de função é tão importante. Somente administradores altamente confiáveis devem ter permissão para alterar arquivos de recursos de função. Se um usuário não confiável puder alterar arquivos de recursos de função, ele poderá facilmente conceder a si mesmo acesso a cmdlets que lhe permitam elevar seus privilégios.

Para administradores que desejam bloquear o acesso aos recursos de função, certifique-se de que o Sistema Local tenha acesso somente leitura aos arquivos de recursos de função e aos módulos que contêm.

Como os recursos de função são mesclados

Os usuários recebem acesso a todos os recursos de função correspondentes no arquivo de configuração da sessão quando entram em uma sessão JEA. JEA tenta dar ao usuário o conjunto mais permissivo de comandos permitidos por qualquer uma das funções.

VisibleCmdlets e VisibleFunctions

A lógica de mesclagem mais complexa afeta cmdlets e funções, que podem ter seus parâmetros e valores de parâmetros limitados no JEA.

As regras são as seguintes:

1. Se um cmdlet for tornado visível apenas em uma função, ele ficará visível para o usuário com quaisquer restrições de parâmetro aplicáveis.
2. Se um cmdlet for tornado visível em mais de uma função e cada função tiver as mesmas restrições no cmdlet, o cmdlet ficará visível para o usuário com essas restrições.
3. Se um cmdlet for tornado visível em mais de uma função e cada função permitir um conjunto diferente de parâmetros, o cmdlet e todos os parâmetros definidos em cada função ficarão visíveis para o usuário. Se uma função não tiver restrições nos parâmetros, todos os parâmetros serão permitidos.
4. Se uma função define um conjunto de validação ou um padrão de validação para um parâmetro de cmdlet e a outra função permite o parâmetro, mas não restringe os valores dos parâmetros, o conjunto ou padrão de validação é ignorado.
5. Se um conjunto de validação for definido para o mesmo parâmetro de cmdlet em mais de uma função, todos os valores de todos os conjuntos de validação serão permitidos.
6. Se um padrão de validação for definido para o mesmo parâmetro de cmdlet em mais de uma função, quaisquer valores que correspondam a qualquer um dos padrões serão permitidos.
7. Se um conjunto de validação for definido em uma ou mais funções e um padrão de validação for definido em outra função para o mesmo parâmetro de cmdlet, o conjunto de validação será ignorado e a regra (6) se aplicará aos padrões de validação restantes.

Abaixo está um exemplo de como as funções são mescladas de acordo com essas regras:

# Role A Visible Cmdlets
$roleA = @{
    VisibleCmdlets = @(
        'Get-Service'
         @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Client' }
        }
    )
}

# Role B Visible Cmdlets
$roleB = @{
    VisibleCmdlets = @(
        @{
            Name       = 'Get-Service';
            Parameters = @{ Name = 'DisplayName'; ValidatePattern = 'DNS.*' }
        }
        @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Server' }
        }
    )
}

# Resulting permissions for a user who belongs to both role A and B
# - The constraint in role B for the DisplayName parameter on Get-Service
#   is ignored because of rule #4
# - The ValidateSets for Restart-Service are merged because both roles use
#   ValidateSet on the same parameter per rule #5
$mergedAandB = @{
    VisibleCmdlets = @(
        'Get-Service'
        @{
            Name = 'Restart-Service';
            Parameters = @{
                Name = 'DisplayName'
                ValidateSet = 'DNS Client', 'DNS Server'
            }
        }
    )
}

VisibleExternalCommands, VisibleAliases, VisibleProviders, ScriptsToProcess

Todos os outros campos no arquivo de capacidade de função são adicionados a um conjunto cumulativo de comandos externos permitidos, aliases, provedores e scripts de inicialização. Qualquer comando, alias, provedor ou script disponível em um recurso de função está disponível para o usuário JEA.

Tenha cuidado para garantir que o conjunto combinado de provedores de um recurso de função e cmdlets/funções/comandos de outro não permitam aos usuários acesso não intencional aos recursos do sistema. Por exemplo, se uma função permitir o Remove-Item cmdlet e outra permitir o provedor, você corre o FileSystem risco de um usuário JEA excluir arquivos arbitrários em seu computador. Informações adicionais sobre como identificar as permissões efetivas dos usuários podem ser encontradas no artigo da JEA de auditoria.

Próximos passos

Criar um arquivo de configuração de sessão